紅帽今年開始加強OpenShift容器平臺對於兩大新興開源技術Knative與Istio的支援,這麼做的原因,紅帽產品與技術總裁Paul Cormier親口告訴iThome記者:「不只是搶攻混合雲,OpenShift還要落地成為一個邊緣運算平臺。」 (攝影/余至浩)

在今年紅帽高峰會上,紅帽開始加強對於兩大新興開源技術Knative與Istio的支援,讓Kubernetes也可以在OpenShift平臺上調度和管理無伺服器(Serverless)與微服務(Microservices)應用,但紅帽沒說的是,藏在Kubernetes背後的更大企圖,直到活動第二天的一場亞太媒體記者會上,紅帽產品與技術總裁Paul Cormier才親口告訴iThome記者:「不只是搶攻混合雲,OpenShift還要落地成為一個邊緣運算平臺。」而Knative與Istio正是用來加速Kubernetes落地邊緣的兩大關鍵開源技術。

紅帽擴大混合雲戰地,要靠Kubernetes通吃雲端與邊緣

早在今年2月,紅帽技術長Chris Wright在自家官網發布的一篇文章就可看出端倪,他在這篇文章中,不只提出未來兩年新興開源技術的最新觀察,甚至也揭露該公司將大力推動發展兩大新興開源技術專案,正是Knative與Istio,並將這兩者視為是Kubernetes容器平臺推動的下一個技術發展方向。

雖然與AWS、Azure、Google同樣是從雲端切進邊緣運算,但不同的地方是,紅帽是專攻Kubernetes層管理需求,要把混合雲上容器管理與調度能力,更進一步延伸到邊緣端,要讓Kubernetes也開始具備有邊緣運算裝置應用的管理能力,不只管雲端,也能向下更擴大延伸至邊緣端,未來除了可提供各種Serverless邊緣應用管理,也能將大量微服務納管,甚至是管更複雜AI或ML推論模型等。

Knative是由Google去年7月開源釋出的一項無伺服器管理專案,該專案目的,是要方便開發者在Kubernetes上建立、部署和管理Serverless函數應用程式。不只Google、GitLab先後採用,甚至連紅帽、SAP 、Pivotal以及IBM都力拱,要將它打造新一代開源無伺服器應用框架,未來更有機會成為業界採用的開源Serverless商用標準。不只有科技廠商先後投入,Knative也與開源FaaS框架社群合作,如OpenWhisk、riff和Kyma等,來加快Knative的發展步伐,推出至今,不到半年,Knative已經發行4個版本,持續提高對Serverless技術支援與增加叢集擴充力。

Knative包含3個部分,建立(Build)、事件(Eventing),以及服務(Serving)。Build 主要提供事件來源到容器建立的整體資源調度;Eventing 則是提供Serverless管理與事件交付,最後的Serving,則是依據事件請求提供可立即擴充的運算力,並在事件結束後,迅速自動移除,如此一來,便能更快速地在Kubernetes上開發出基於容器的Serverless功能或應用。

OpenShift新版現在可以調度和管理Azure無伺服器應用了

紅帽去年就開始布局Serverless,但是直到今年的紅帽用戶大會上,正式支援Knative後,對於Serverless布局才開始有了更具體的戰略,就是搶攻邊緣運算,而用來切進邊緣運算的關鍵利器,就是當家主力混合雲平臺OpenShift 。

儘管Knative仍在發展初期,但紅帽相當看好Knative未來應用發展的潛力,因此,該公司在推出新版OpenShift 4時,也開始支援了Knative,雖然僅是開發者預覽,但OpenShift結合Serverless後,現在已能透過Knative將Serverless以容器打包後,並在Kubernetes平臺上,部署和管理Serverless應用程式,或是FaaS應用服務功能,Knative不只支援公有雲,也能用於多雲、混合雲環境上,再利用Kubernetes來提供Serverless叢集的管理。

借助Knative,紅帽表示,使用者能在OpenShift 4上,以隨需擴充的方式,動態建立Serverless叢集,並在Kubernetes環境執行這些無伺服器應用,而透過Knative上的事件框架,可以輕易在Kubernetes上開發以Serverless事件觸發為主的原生容器應用。

Knative還整合了服務網格技術的Istio和Kiali,來幫助管理容器化的Serverless叢集架構,另外還加入Strimzi,可以更容易地在OpenShift或Kubernetes上使用開源分散式串流分析工具Apache Kafka,還可通過Red Hat AMQ Streams來提供更可靠的事件處理機制。新增的Apache Camel輕量級框架Camel-K,也能讓開發者以編寫Serverless函數的方式,自行定義事件觸發條件,此後程式便會在條件滿足時自動執行無伺服器應用程式,並且自動水平擴展。

Paul Cormier解釋,OpenShift開始支援Serverless有兩個主因,一來這是開發者最想用來開發原生容器應用的一大功能;二來,則是要解決Serverless技術容易被特定廠商所綁定的棘手難題。他進一步說明,雖然現在許多雲端廠商,都有提供無伺服器運算服務,如AWS Lambda或微軟Azure Functions等,「但是,這些無伺服器運算平臺,彼此並不相通,因此,只能在單一雲端廠商所提供的雲端環境來執行Serverless應用程式,在其他家就會沒辦法用,因為彼此無法相容,得先重新編寫成符合其他雲端環境能夠運作的Serverless執行程式,才能拿來用,也增加了開發人員應用開發的一大負擔。

因為Knative本身具備相容多異質雲端平臺的特性,所以,紅帽的第一步,就是開始支援Knative,一方面,可以減少企業用戶被特定廠商綁定的情況,讓Serverless應用可以在不同雲端環境中執行相關運算與事件觸發任務;另一方面,也簡化Serverless開發與部署,開發者現在只須編寫一次程式,就能搬上不同雲端平臺上,不需要每換一朵雲,就要對Serverless叢集重新編寫,才能加以執行,也因此,大大加快Serverless應用程式的開發、部署的工作。

紅帽這次還與微軟聯手推出Azure Functions in OpenShift服務,通過兩家合推的KEDA無伺服器應用專案,讓Azure Functions無伺服器服務也能在紅帽OpenShift容器平臺上執行,可以做為Azure 、混合雲、本地端管理,或是可用來實現雲端FaaS服務。不過目前仍是開發者預覽版。

透過支援Istio服務網格技術,讓K8s也可管大量容器化的微服務

除了Knative以外,另一個同樣值得關注的技術則是更早一年,由Google、IBM及Lyft主推的微服務平臺Istio,在新版OpenShift 4推出時,已經可以透過Istio服務網格技術,在Kubernetes上來管理微服務叢集,用以解決大量容器化應用網路溝通問題。

而且不只公有雲或混合雲能用,Istio同樣適用於邊緣運算的應用情境,讓應用程式可以小規模方式,部署在運算能力普通的硬體裝置上執行,以微服務化架構建立邊緣運算叢集。紅帽不只在OpenShift開始支援Istio,還整合開源分散式追蹤工具Jaeger與紅帽自行開發的服務網格管理工具Kial,可以透過服務網格的架構,來管理龐大的微服務群,讓開發團隊可以專注在開發執行商業邏輯的應用程式。

紅帽今年在進行混合雲技術展示時,也首次示範以OpenShift平臺、OpenStack技術,以及RHEL OS自行打造一個邊緣運算平臺,就近在裸機上執行環境監測與狀態更新回報等功能。


Advertisement

更多 iThome相關內容