Kubernetes 部署的運作方式
無人機追蹤應用程式有數個彼此分開部署的元件。 設定這些元件在叢集上的部署是您的工作。 在這裡,您會看到可供部署這些元件的一些部署選項。
Pod 部署選項
使用 kubectl
時,有數個選項可管理 Kubernetes 叢集中的 Pod 部署。 選項是:
- Pod 範本
- 複寫控制器
- 複本集
- 部署
您可使用這四個 Kubernetes 物件類型定義中的任一項來部署一或多個 Pod。 這些檔案都使用 YAML 來描述將部署的一或多個 Pod 的預期狀態。
什麼是 Pod 範本?
Pod 範本可供定義所要部署的 Pod 設定。 此範本包含容器映像名稱等資訊,以及要用於擷取映像的容器登錄。 此範本也會包含執行階段設定資訊,例如要使用的連接埠。 範本是使用 YAML 來定義,與建立 Docker 檔案時的方式相同。
您可使用範本來手動部署 Pod。 不過,手動部署的 Pod 在失敗、刪除或終止之後不會重新啟動。 若要管理 Pod 的生命週期,則需要建立較高層級的 Kubernetes 物件。
什麼是複寫控制器?
複寫控制器會使用 Pod 範本,並定義必須執行的指定 Pod 數目。 控制器可協助您執行同一 Pod 的多個執行個體,並確保 Pod 一律會在叢集的一或多個節點上執行。 如果 Pod 失敗、刪除或終止,控制器就會以此方式使用新的 Pod 來取代正在執行的 Pod。
例如,假設您部署無人機追蹤前端網站,而使用者開始存取該網站。 如果所有 Pod 因任何原因而失敗,除非啟動新的 Pod,否則使用者即無法使用該網站。 複寫控制器可協助確保網站一律可供使用。
什麼是複本集?
複本集可取代複寫控制器作為部署複本的慣用方式。 複本集包含與複寫控制器相同的功能,但有額外的設定選項可包含選取器值。
選取器可讓複本集識別在其下執行的所有 Pod。 使用此功能,您可以管理標籤值與選取器值相同,但不是以複本集建立的 Pod。
什麼是部署?
部署會建立層級高於複本集的管理物件,並可供部署及管理叢集中的 Pod 更新。
假設您在叢集中部署了五個應用程式執行個體。 有五個 Pod 執行應用程式的 1.0.0 版。
若您決定手動更新應用程式,您可以移除所有 Pod,然後啟動執行應用程式 2.0.0 版的新 Pod。 使用此策略,應用程式會經歷停機。
您會想要改為執行輪流更新,先啟動新版應用程式的 Pod,再移除舊版應用程式的 Pod。 輪流更新會一次啟動一個 Pod,而不是一次關閉所有舊的 Pod。 部署會遵循描述複本集相關資訊一節中所設定的複本數目。 在將舊 Pod 取代為新 Pod 時,會維持複本集所指定的 Pod 數目。
根據預設,部署會提供輪流更新策略以更新 Pod。 您也可以使用重新建立策略。 此策略會先終止 Pod,再啟動新 Pod。
部署也會提供復原策略,您可使用 kubectl
來執行此策略。
部署會使用 YAML 型定義檔以方便管理部署。 請記住,部署可供對叢集套用任何變更。 例如,您可部署新版的應用程式、更新標籤,以及執行其他 Pod 複本等。
當使用 kubectl run
命令部署 Pod 時,kubectl
有能夠自動建立部署的便利語法。 此命令會以所需複本集和 Pod 來建立部署。 不過,此命令不會建立定義檔。 最佳做法是使用部署定義檔管理所有部署,然後使用版本控制系統追蹤變更。
部署考量
Kubernetes 對如何設定叢集的網路與儲存體有特定要求。 您設定這兩個層面的方式,將會影響在叢集網路上公開應用程式,以及儲存資料的方式。
例如,無人機追蹤應用程式的每項服務對使用者存取、處理序間網路存取,以及資料儲存體都有特定要求。 現在讓我們看看 Kubernetes 叢集的這些層面,以及這些層面影響應用程式部署的方式。
Kubernetes 網路
假設您有一個具備一個控制平面和兩個節點的叢集。 當將節點新增至 Kubernetes 時,系統會自動為每個節點指派一個內部私人網路範圍的 IP 位址。 例如,假設本機網路範圍是 192.168.1.0/24。
您部署的每個 Pod 都會獲派一個 IP 位址集區 IP。 例如,假設設定使用 10.32.0.0/12 網路範圍,如以下影像所示。
根據預設,Pod 與節點無法使用不同的 IP 位址範圍互相通訊。
如果您還有印象,Pod 是暫時性的,這使得情況更為複雜。 Pod IP 位址是暫時的,且無法用來重新連線到新建立的 Pod。 此設定會影響應用程式與其內部元件通訊的方式,以及您與服務在外部與應用程式的互動方式。
為了簡化通訊,Kubernetes 會預期您以符合下列條件的方式設定網路功能:
- Pod 彼此之間不用網路位址轉譯 (NAT) 即可跨節點通訊。
- 節點不使用 NAT 即可與所有 Pod 通訊,反之亦然。
- 節點上的代理程式可與所有節點和 Pod 通訊。
Kubernetes 提供數個可安裝的網路選項,其可供設定網路。 例如,Antrea、Cisco Application Centric Infrastructure (ACI)、Cilium、Flannel、Kubenet、VMware NSX-T 及 Weave Net。
雲端提供者也會提供其網路解決方案。 例如,Azure Kubernetes Service (AKS) 支援「Azure 虛擬網路」容器網路介面 (CNI)、Kubenet、Flannel、Cilium 及 Antrea。
Kubernetes 服務
Kubernetes 服務是為 Pod 提供穩定網路的 Kubernetes 物件。 Kubernetes 服務可讓叢集內外的節點、Pod 及應用程式使用者互相通訊。
Kubernetes 會像對節點或 Pod 一樣,在建立服務時為其指派 IP 位址。 這些位址會從服務叢集的 IP 範圍指派;例如,10.96.0.0/12。 服務也會獲指派一個以服務名稱為基礎的 DNS 名稱,以及一個 IP 連接埠。
在無人機追蹤應用程式中,網路通訊如下:
叢集外的使用者可存取網站和 RESTful API。
前端與 RESTful API 可分別存取記憶體內快取和訊息佇列服務,但外部使用者不行。
訊息佇列需要存取資料處理服務,但外部使用者不需要。
記憶體內快取和資料處理服務可存取 NoSQL 資料庫,但外部使用者不行。
為支援這些案例,您可設定三種類型的服務,以公開應用程式的元件。
服務 | 說明 |
---|---|
ClusterIP | 指派給服務,以讓叢集內一組服務可以存取該服務的位址。 例如,您應用程式前端與後端元件之間的通訊。 |
NodePort | Kubernetes 控制平面指派給服務的節點連接埠,介於 30000 到 32767 之間;例如 clusters01 上的 192.169.1.11。 接著,在想要公開的 Pod 上,設定服務的目標連接埠。 例如,在執行其中一個前端的 Pod 上設定連接埠 80。 您現在已可透過節點 IP 與連接埠位址存取前端。 |
LoadBalancer | 允許在執行應用程式的節點間分散負載,以及向公用網路存取公開 Pod 的負載平衡器。 一般會在使用雲端提供者時設定負載平衡器。 在此情況下,外部負載平衡器流量會導向執行應用程式的 Pod。 |
在無人機追蹤應用程式中,您可能會決定透過 LoadBalancer 來公開追蹤網站及 RESTful API,以及透過 ClusterIP 公開資料處理服務。
Pod 的分組方式
依據 IP 位址來管理 Pod 並不切實際。 Pod IP 位址會隨著控制器重新建立 Pod 而變更,而您正在執行的 Pod 數目可能不定。
服務物件可供使用選取器標籤,以叢集中的特定 Pod 作為目標並加以管理。 您要在服務定義中設定選取器標籤以符合 Pod 定義檔中定義的 Pod 標籤。
例如,假設有許多正在執行的 Pod。 這些 Pod 只有幾個位在前端,且您想要設定只以前端 Pod 為目標的 LoadBalancer 服務。 您可在服務的定義檔中,將 Pod 標籤當成選取器值參考,以套用服務來公開這些 Pod。 服務只會分組這些符合標籤的 Pod。 如果移除某個 Pod 後又重新建立,則新 Pod 會透過其相符標籤自動新增至服務群組。
Kubernetes 儲存體
Kubernetes 使用的儲存磁碟區概念與您使用 Docker 時所發現概念相同。 與 Kubernetes 磁碟區相比,Docker 磁碟區的受控程度較低,因為 Docker 磁碟區存留期並不受控。 Kubernetes 磁碟區其存留期是與 Pod 存留期相符的明確存留期。 此存留期相符意謂著磁碟區的存留時間會比在 Pod 中執行的容器長。 不過,如果將 Pod 移除,磁碟區也會一併被移除。
Kubernetes 提供使用 PersistentVolumes 來佈建永續性儲存體的選項。 您也可以使用 PersistentVolumeClaims 為 Pod 要求特定的儲存體。
部署需要訊息佇列和資料庫等永續性儲存體的應用程式元件時,請記住這些選項。
雲端整合考量
Kubernetes 不會決定您在雲端原生應用程式中使用的技術堆疊。 在 Azure 等雲端環境中,您可使用數個 Kubernetes 叢集外的服務。
請回想一下,Kubernetes 不會提供下列任何服務:
- 中介軟體
- 資料處理架構
- 資料庫
- 快取
- 叢集儲存系統
在無人機追蹤解決方案中,有三項服務提供中介軟體功能:NoSQL 資料庫、記憶體內部快取服務,以及訊息佇列。 您可選擇使用 MongoDB Atlas 作為 NoSQL 解決方案、使用 Redis 管理記憶體內部快取,以及根據訊息佇列的需求使用 RabbitMQ 或 Kafka。
使用 Azure 等雲端環境時,最佳做法是使用 Kubernetes 叢集外的服務。 此決策可簡化叢集的設定與管理。 例如,您可以使用 Azure Cache for Redis 作為記憶體內快取服務、使用「Azure 服務匯流排傳訊」作為訊息佇列,以及使用 Azure Cosmos DB 作為 NoSQL 資料庫。