Kubernetes 的異質部署模式

本文說明使用 Kubernetes 建立實際運作等級的異質部署的常用模式。本文會檢閱三種應用實例,並說明您可能會用來為其建立部署的架構詳細資料。架構說明包含 Kubernetes 總覽,並著重在 Google Kubernetes Engine (GKE)

異質部署

異質部署通常需要連接兩個以上不同的基礎架構環境或地區,以滿足特定技術或作業需求。視部署特點而定,異質部署有「混合」、「多雲端」或「公開-私密」三種類型。本文章所包含的異質部署有在單一雲端環境中橫跨多個地區的部署、多重公用雲端環境 (「多雲端」型) 的部署,或結合內部部署與公用雲端環境 (「混合」或「公開-私密」型) 的部署。

限定在單一環境或地區進行部署可能會發生多種商業和技術問題:

  • 有限的資源:在任何單一環境中,特別是在內部部署環境,您可能沒有滿足實際運作所需的運算、網路和儲存資源。
  • 有限的地理範圍:單一環境中的部署讓兩個距離遙遠的人存取同一個部署。他們的流量必須經過一段很長的傳輸距離,送到一個中央位置。
  • 有限的可用性:網路規模的流量模式讓應用程式難以維持容錯和彈性。
  • 綁定廠商:廠商層級的平台和基礎架構抽象化讓您無法遷移應用程式。
  • 資源缺乏彈性:您的資源可能受限於一組特定的運算、儲存或網路服務。

異質部署有助於解決這些問題,但必須使用程式輔助的確定性程序來建立架構。一次性部署程序或臨時部署程序會產生脆弱且無法容錯的部署或程序。臨時程序會遺失資料或捨棄流量。良好的部署程序必須可重複執行,並使用經過驗證的方法來管理佈建、設定和維護。

異質部署的三種常見情境為多雲端部署、前置內部部署資料,以及持續整合/持續推送軟體更新 (CI/CD) 程序。

下面各節說明異質部署的一些常見用途、使用 Kubernetes 建立良好架構的方法,以及其他基礎架構資源。

多雲端

多雲端部署中的所有部署都相當類似。多雲端部署是最常搭配 Kubernetes 使用的異質部署模式。

多雲端部署的其中一個用法涉及選擇引導流量的方式。在最簡單的部署中,您可以選擇將特定百分比的傳入流量傳送至特定部署。您可以從內部部署和公用雲端基礎架構建構的部署中,傳送更多流量至雲端基礎架構,以協助更長期的遷移作業或避開受限制的內部部署資源。

多雲端部署的另一個常見用法是設定能承受任何單一環境錯誤的高可用性部署。在這些情境中,您可以將相同的 Kubernetes 部署編排到每一個需要的環境。在任何單一環境失敗時,每個部署應該要能擴充資源,來滿足所有流量的需求。

最後,您可以使用多雲端部署來建立實際地理位置更靠近使用者的部署。將部署安排在盡可能靠近使用者的位置,可降低要求和回應延遲。

引導流量

扎實的多雲端部署使用 DNS 流量管理服務來解析個別部署的 DNS 要求。對於一般流量拆分使用案例,您可以設定 DNS 流量管理機制,按百分比將流量拆分到個別部署。

拆分流量

對於高可用性部署,您可以透過每個環境的自訂健康狀態檢查來設定 DNS 機制。當環境變得不健康時,即會停止傳送健康狀態更新,接著 DNS 機制會將流量移轉至健康的部署。

當使用者遭遇到重大的流量延遲時,DNS 機制會使用傳入要求的 IP 位址來判斷要求的大致位置,然後將流量引導至最接近該地理地區的部署。您可以使用 DNS 基礎架構服務供應商,例如 NS1DynAkamai 等,將流量引導到多個部署。

處理要求

當 DNS 將流量引導至特定部署時,負載平衡器應該會接收連入要求,然後將要求引導至 Kubernetes 叢集。Kubernetes 提供兩種向連入流量公開 Pod 的機制:服務輸入

在 Kubernetes 叢集中部署 Pod 時,叢集內外的其他應用程式或系統無法輕鬆存取這些 Pod。若要讓 Pod 變得可以存取,您必須先建立服務。根據預設,服務會自動接受叢集內部發出的連線,但您也可以設定為接受來自叢集外部的連線。

將服務設定為接受外部要求時,請將服務類型設定為 NodePortLoadBalancer

將服務類型設定為 NodePort 會公開 Kubernetes 叢集中,所有節點上每個服務的專用通訊埠。這個專用通訊埠允許每個節點接受連線,並透過 proxy 傳送負載平衡連入要求至適當的 Pod。

LoadBalancer 服務類型是 NodePort 的超集。除了在每個節點提供通訊埠設定外,將類型設為 LoadBalancer 會自動佈建外部負載平衡器,並設定為將流量引導至叢集和後續的 Pod。

Kubernetes 中的服務屬於第 4 層建構,表示這些服務支援僅透過 IP 位址和通訊埠編號存取。「輸入」屬於 HTTP(S) (第 7 層) 負載平衡機制。「輸入」是一組規則,允許傳入連線連到後端 Kubernetes 叢集服務。您可以設定輸入機制,為服務提供額外的應用層功能,例如,允許外部連線的網址、傳入流量負載平衡、安全資料傳輸層 (SSL) 終止,或以名稱為基礎的虛擬主機。您可以使用 HTTP 主機標頭或 HTTP 網址路徑,將傳入流量引導到透過服務公開的 Pod。

將流量引導到 Pod

共用服務

執行多雲端部署時,您可能需要在每個部署中執行一或多個共用服務,例如資料庫。共用服務之間的通訊必須使用低延遲且安全的連線。

在低延遲、高頻寬的連線中,您可以使用直接對等互連或第三方代管的網路互連,連接每個部署中的基礎網路。GCP 藉由在任一可用的網路邊緣位置直接與 Google對等互連,提供直接連線能力。要達成直接對等互連,需要滿足一些技術需求。若無法滿足這些需求,可改用 Cloud Interconnect。您可以透過 Cloud Interconnect 服務供應商,以企業級連線能力連線到 Google 的網路邊緣。

建立連線後,下一步是使用 VPN 保護各環境之間的連結。在每個部署中,您需要使用 VPN 閘道來保護部署之間的流量。在 GCP 中,Cloud VPN 會使用 IPSec VPN 連線來保護流量。Cloud VPN 支援透過多個 VPN 通道來匯總頻寬,並支援使用 Cloud Router 進行靜態或動態轉送。

叢集管理

在多雲端部署中,您或許想將各 Kubernetes 叢集當做個別實體來管理和控制。若要這麼做,您必須在每個叢集中手動建立 Pod 及服務。這樣做的好處是,雖然每個部署可能會有一些共用應用程式和服務,但也會包含只適合自身使用的應用程式和服務。

例如,您需要將部署分佈在不同的地理位置,但某些國家或地區專用的服務不適合所有的地理位置。

如果部署的流量拆分未平均分佈,則需要在每個叢集中部署 Pod 和服務,確保能夠妥善處理傳入流量和要求。

服務探索

多雲端部署應使用服務探索,以確保不同的應用程式和服務可在執行階段輕鬆找到彼此。服務探索讓您不需要在部署之前,瞭解複雜或易出錯的命名配置或慣例。服務探索機制必須對來源和目的地應用程式公開。在多雲端部署中,這些機制必須要讓應用程式和服務探索在本機執行和在其他叢集中遠端執行的服務。

在以獨立式個別叢集進行架構和配置的部署中,服務探索機制必須是「資料中心感知」。亦即,這些機制必須以協調的分散式系統進行操作,能夠依據傳入要求、本機可用性及負載容量,將傳送要求至適當叢集。第三方系統如 ConsulLinkerd 等,可以透過多雲端 Kubernetes 部署來協助跨叢集及跨環境服務探索。

Kubernetes 支援解析 Kubernetes 叢集中的私人 DNS 區域。此支援適合用於混合或多雲端情境,因為在這些情境中已知其他叢集的完整網域名稱,可以將流量輕鬆轉送至這些叢集。您可以使用 ConfigMap 設定私人「虛設常式」網域的存取權。您可以使用解析私人 DNS 區域的 Kubernetes 支援做為傳送要求至特定 Kubernetes 叢集的獨立機制,或與外部系統 (例如 Consul) 一起使用。

架構

下圖顯示範例多雲端部署架構。

多雲端部署

前置內部部署資料

您可以架構雲端部署,在私人或內部部署中的可用功能之外,擴展其他功能。例如,您可以架構和部署可存取私人資料系統或基礎架構的雲端應用程式。

前面提過,私人或內部部署的可用性、可攜性或資源彈性受到限制,而遷移至雲端部署可以解決這些限制,但也可能會因為舊的架構、安全規範或其他軟體需求問題而無法解決。在這種情境下,您可以在彈性或功能性都優於私人或內部部署環境的雲端環境中建構和部署新的應用程式。

架構

下圖中的範例架構說明雲端應用程式的前置內部部署資料基礎架構。

前置內部部署資料

網路

在雲端應用程式是前置內部部署資料基礎架構的部署中,您需要安全、低延遲的連線,以減少使用者的應用程式整體回應時間。您可以使用 Cloud Interconnect直接對等互連,將延遲時間縮到最短,並將內部部署及雲端環境之間的可用頻寬提升至最大。建立連線後,每個部署都必須有一個 VPN 閘道來保護部署之間的流量。在 GCP 中,Cloud VPN 會透過 IPSec VPN 連線來保護流量。Cloud VPN 支援使用多個 VPN 通道來匯總頻寬,且支援使用 Cloud Router 進行靜態或動態轉送。因為安全性對使用前置內部部署資料基礎架構來說十分重要,所以您應設定 路徑和內部部署防火牆,只允許來自特定 GCP 執行個體組的流量。

雲端架構

在這類混合性部署的雲端部分,架構元件必須包含適當的負載平衡器、應用程式託管基礎架構、VPN 閘道及服務探索機制。負載平衡器的選擇需視使用者所使用的應用程式需求而定。對於在 GCP 上的部署,Cloud Load Balancing 支援 HTTP(S)、TCP 與 UDP 搭配一個全域可用的 Anycast IP。

在這類混合情境中,您可以在 GKE 上部署 Pod 和服務。GKE 是 GCP 中的代管 Kubernetes 部署,會將傳出流量引導到內部部署基礎架構。GKE 使用 Cloud VPN 來保護流量,並使用 Cloud Router 來設定靜態或動態路徑。此設定可確保只有來自 GKE 叢集的流量能透過 VPN 連線傳送。

內部部署架構

此部署的內部部署部分包含支援雲端應用程式的資料基礎架構。對於具有此性質的大部分部署而言,在資料系統前部署 CRUD API 有許多好處。

如果資料系統需要高層級的安全或法規遵循,CRUD API 有助於稽核和記錄傳入連線和查詢。如果資料基礎架構在舊版系統上執行,CRUD API 可為較新的應用程式提供較新的連線選項供應用程式使用。

在這兩種情況下,CRUD API 皆可協助將內建資料庫驗證和授權機制與應用程式所需的驗證和機制脫鉤,只提供應用程式所需的 CRUD 功能。具體而言,如果只需要向下游應用程式公開一部分資料,則非常適合使用 API 來管理資料的存取權。

透過稽核連線和查詢,API 也有助於定義基礎資料的長期遷移策略。如果只需要一部分資料,且這部分的資料不受嚴格的安全或法規遵循政策限制,則可將該資料遷移至雲端平台。

上面的架構圖顯示在內部部署執行的 Kubernetes 中託管的 CRUD API。技術上您不需要在內部部署使用 Kubernetes,但在內部部署使用 Kubernetes 有下列優點:隨著更多團隊將 Kubernetes 視為雲端基礎架構中的部署目標,開發人員可以因學習使用和操作系統所需的額外專業知識而受益。

內部部署基礎架構必須設定 VPN 閘道和防火牆,只允許已知來源的流量傳送至 CRUD API,以減少潛在的安全問題。

服務探索

在混合部署的情境中,您應使用服務探索來確保不同應用程式和服務可在執行階段輕鬆地相互連結。隨著時間推移,可能會部署其他的雲端應用程式,使用內部部署 CRUD API 的不同元件。CRUD API 可能會隨著時間新增額外的功能,例如工作專用 API 或前置於其他內部部署資料基礎架構的 API。在這幾類的部署情境中,雲端應用程式與內部部署 CRUD 功能的發佈週期可能大不相同。使用外部服務探索機制 (例如 ConsulLinkerd) 可以提供資源和版本的鬆散耦合,這樣資源和版本就可以在每個環境中分開疊代。

如果您計劃只在 GKE 或 Kubernetes 中部署雲端應用程式,您可以設定內部 Kubernetes DNS 機制 kube-dns,以便將私人 DNS 網域解析到內部部署環境中的私人 IP 位址。在該設定中,在雲端環境中執行的 Pod 可以使用標準 DNS 查詢,輕鬆存取在內部部署環境中執行的服務。詳情請參閱在 Kubernetes 中設定私人 DNS 區域和上游名稱伺服器

CI/CD 工作負載

將更重要的工作負載遷移至雲端環境,有益於來自現有內部部署的部署的多雲端工作負載。

持續整合 (CI) 工作負載是遷移的理想選擇,因為雲端環境具有自動調整運算資源配置的能力,有助於縮短從完成程式碼到建構成果的時間。

在雲端環境中執行也可有益於持續推送軟體更新 (CD) 工作負載,因為這使得測試環境中的佈建和部署變得更輕鬆。遷移可為單元測試增加平行建構程序的數量。另一個潛在的好處是為端對端整合測試和其他自動化測試增加測試部署的數量。

以雲端為基礎、以容器為中心的 CI/CD 工作負載通常使用下列高階程序:

  • 開發。 開發人員會修訂程式碼,並將程式碼變更推送至本機或遠端託管的原始碼存放區。
  • 建構。 建構服務會持續輪詢原始碼存放區。只要看見新的變更,服務就會啟動建構處理。
  • 單元測試。此程序會建構來源、執行單元測試,以及建構成果容器映像檔。
  • 整合測試。此程序會建立測試叢集、部署容器映像檔及其相關成果,以及執行整合測試。
  • 製作。 成功完成時,容器映像檔會使用發佈版本中繼資料加上標記。
  • 部署。 開發人員或管理員可以選擇將新的成果部署到實際工作環境。

用途

最常搭配 GCP 使用的 CI/CD 工具是 JenkinsSpinnaker。Jenkins 是一個常見的開放原始碼 CI/CD 系統,可以部署在獨立的運算執行個體上,或做為 Kubernetes 中的一系列 Pod 和服務進行部署。Spinnaker 是一個持續推送軟體更新的開放原始碼系統,能夠協調和自動遞送軟體到多個目標。Spinnaker 可以使用持續整合系統 (例如 Jenkins) 或其他工具 (例如 Cloud Build)。

Jenkins 與 Kubernetes

如要瞭解使用 Jenkins 搭配 Kubernetes 的 CI/CD 工作負載,請參閱下列說明文件,其中說明最佳做法、常用的設定模式及協調持續推送軟體更新:

Spinnaker

Spinnaker 是一個持續推送軟體更新的開放原始碼多雲端平台,可以協調軟體部署工作流程和叢集管理。Spinnaker 的叢集管理功能可讓您佈建和控制雲端資源,例如執行個體群組、執行個體、防火牆及負載平衡器。軟體部署工作流程由管道組成,每個管道都是由一連串的動作組成,這些動作稱為「階段」。Spinnaker 管道中的一個階段可以將參數傳送至下一階段。您可以手動或透過自動觸發條件啟動管道,例如外部持續整合系統、cron 指令碼或其他管道。Spinnaker 隨附幾種預先封裝的階段,用於製作映像檔、部署映像檔、用於執行個體群組和要求使用者輸入。下列映像檔說明 Spinnaker 管道如何發佈軟體。

Spinnaker 管道

軟體在建構後會進行測試。如果通過所有測試,則會製作不可變更的映像檔,然後在雲端提供。有可供使用的映像檔後,系統即會將映像檔部署到叢集,以更新叢集的執行軟體。

架構

使用容器部署時,Spinnaker 會使用外部持續整合系統 (例如,Jenkins 或 Cloud Build) 來執行建構、測試和製作步驟。然後,Spinnaker 會使用標準管道階段協調目標部署。下列映像檔顯示這類系統的架構。

Spinnaker 搭配 Jenkins

如要瞭解在 GCP 上部署 Spinnaker,請參閱在 Compute Engine 上執行 Spinnaker

使用 Jenkins 建構

Jenkins 能利用 Spinnaker 對使用觸發條件啟動管道的支援。您可以使用 Jenkins 建構來自動觸發 Spinnaker 管道。在 Spinnaker 管道中,Jenkins 指令碼階段可以執行測試並製作發佈程序的各個階段。Spinnaker 的內建叢集管理階段可協調目標部署。詳情請參閱 Spinnaker Hello 部署範例。

使用 Cloud Build 建構

Cloud Build 是一種全代管的 GCP 服務,可在快速、一致且穩定的環境中建構容器映像檔。Cloud Build 會直接整合 Cloud Source Repositories,根據來源或存放區的標記變更,自動觸發建構。Cloud Build 會在 Docker 容器中執行建構,且可支援任何能夠在容器中封裝的自訂建構步驟。Cloud Build 中的建構提供深度自訂,並支援步驟排序和並行處理。建構程序的狀態變更會自動發佈到 Cloud Pub/Sub 主題。

雖然 Spinnaker 不直接支援 Cloud Build,但卻支援 Container Registry。Cloud Build 會自動使用 Container Registry 這個容器註冊資料庫。您可以設定 Spinnaker 來輪詢 Container Registry,並依據偵測到的更新容器映像檔版本或標記來啟動管道。在這類應用情境中,您應設定 Cloud Build 來執行發佈程序的建構、測試和製作階段。如要深入瞭解如何設定 Spinnaker 以利用 Container Registry,請參閱 Spinnaker 說明文件

協調 Kubernetes 部署

Spinnaker 的內建叢集管理機制支援 Kubernetes。Spinnaker 中的伺服器群組和負載平衡器分別對應到 Kubernetes 中的備用資源集與服務。

下列說明文件介紹設定 Spinnaker 以將 Pod 和服務部署到 Kubernetes 的必要步驟:

後續步驟

  • 自行試用其他 Google Cloud Platform 功能。請參考我們的教學課程
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
解決方案