準備用於實際工作的 Google Kubernetes Engine 環境

透過本解決方案提供的藍圖和方法,您將瞭解如何以更安全可靠且具經濟效益的方式讓工作負載在 Google Kubernetes Engine 中上線。本解決方案亦提供叢集的管理及網路權限設定指南。本篇文章假設您已經對 Kubernetes 資源和叢集管理有一定的瞭解,並且熟悉 Google Cloud Platform (GCP) 網路功能。

建構專案、虛擬私人雲端 (VPC) 網路及叢集

下圖顯示的是專案、VPC 網路、地區、子網路、區域及叢集的最佳結構。

專案、網路及叢集架構

專案

GCP 會在專案實體中建立所有資源。專案為一計費單位,並且允許管理員將使用者與 Cloud Identity and Access Management (Cloud IAM) 角色相連結。在專案層級套用角色時,該角色將會套用至專案內的所有資源。

您應以專案方式來封裝各種操作環境。例如,您可能有營運團隊專屬的 productionstaging 專案,以及開發人員專屬的 test-dev 專案。您可以針對處理重要機密資料和工作負載的專案套用較精細且嚴格的政策,同時針對 test-dev 環境套用較寬鬆且彈性的政策,以方便開發人員進行實驗。

叢集

一個專案可包含多個叢集。若您需要部署多個負載,可選擇要使用單一共用叢集或是多個獨立叢集來處理這些負載。您可以在選擇 GKE 叢集的大小和範圍一文中參考我們的最佳方案,以判斷要使用哪一種做法。

網路與子網路

在每個專案中您都可以擁有一個或多個 VPC 網路,即實體網路的虛擬版本。每個 VPC 網路都是一個全球資源,其中包含其他的網路相關資源,如子網路、外部 IP 位址、防火牆規則、路徑、您的 VPN 及 Cloud Router。在 VPC 網路中,您可以使用子網路 (屬於地區資源) 在 GKE 叢集之間隔離和控制進出每個地區的流量。

每個專案都配有一個預設的網路。您可以根據現有的外部 IP 位址管理 (IPAM) 規範來建立和設定其他網路,並針對此網路套用防火牆規則,過濾進出 GKE 節點的流量。預設情況下,所有連至您 GKE 節點的網際網路流量都會被拒絕。

為了要控制子網路之間的通訊,您需要建立防火牆規則,允許流量在子網路之間傳遞。請在建立叢集或節點集區時,使用 --tags 標記來確實標記您的 GKE 節點,以便使防火牆規則生效。您也可以視需要使用標記在子網路之間建立路徑。

多區域叢集和地區叢集

預設情況下,叢集在建立時,會在您指定的單個區域中建立叢集主要執行個體和節點。您可以透過建立「多區域叢集」或「地區叢集」,來提高叢集的可用性和恢復能力。多區域叢集和地區叢集會在單一地區的多個區域間分配 Kubernetes 資源。

多區域叢集:

  • 在一個區域中建立單一叢集主要執行個體。
  • 在多個區域中建立多個節點。

地區叢集:

  • 在三個區域中建立三個叢集主要執行個體。
  • 根據預設,您可以視需要在三個,甚至更多個區域內建立多個節點。

地區叢集和多區域叢集間的主要差異在於:地區叢集會建立三個主要執行個體,而多區域叢集僅會建立一個。請注意在這兩種情況下,跨區域的節點到節點流量都將需付費。

您可以在建立叢集時選擇要建立「地區叢集」或是「多區域叢集」。您「可以」增加新區域至現有叢集,使其成為多區域叢集架構。但是,您「無法」將現有叢集更改為地區叢集。您也無法將地區叢集更改為非地區叢集。

如要進一步瞭解多區域叢集與地區叢集,請參閱 GKE 說明文件

管理身分與存取權

專案層級存取權

前一章節指出了您可以在專案層級將 IAM 角色與使用者綁定。除了授與角色給單個使用者,您也可以使用群組來簡化角色的應用。

下圖呈現了依據最低權限原則設計的 IAM 政策,分別套用至供開發人員開發、測試新功能及修正錯誤的 dev 專案,以及用於處理實際流量的 prod 專案:

身分與存取權管理

如下表所示,在組織中分四組具不同等級權限的使用者,在兩專案中透過 IAM 角色授與其權限:

團隊角色 IAM 角色 專案 權限
開發人員 container.developer dev 可以為專案現存的叢集建立 Kubernetes 資源,但不允許新增或刪除叢集。
營運人員 container.admin prod 擁有完整管理權限,可管理專案中執行的叢集與 Kubernetes 資源。
安全性管理 container.viewer
security.admin
prod 可以建立、修改和刪除防火牆規則與 SSL 憑證,以及查看各個叢集中建立的資源,包含執行中 pod 的記錄。
網路管理 network.admin prod 可以建立、修改和刪除網路資源,防火牆規則和 SSL 憑證除外。

除了有權存取 prod 專案的 3 個團隊之外,另外還有一個服務帳戶擁有 prodcontainer.developer 角色,能夠建立、表列及刪除叢集內的資源。服務帳戶用於讓自動指令碼或部署框架得以代表使用者執行操作。部署至實際工作環境之專案及叢集的動作應透過自動化管道完成。

dev 專案中,會有多個開發人員在同一叢集處理相同應用程式。這可以透過叢集使用者建立的命名空間實現。每個開發人員都可以在自己的命名空間內建立資源,從而避免命名衝突。他們也能針對部署內容重複利用相同的 YAML 設定檔,以便在開發疊代期間讓設定盡可能保持相似。命名空間還可用於建立叢集中的 CPU、記憶體及儲存空間用量配額,以確保個別開發人員不會占用叢集中過多的資源。下一節將討論如何限制使用者在特定命名空間內執行作業。

RBAC 授權

若 GKE 叢集執行 1.6 版以上的 Kubernetes,將可以進一步限制使用者在個別叢集有權執行的動作。Cloud IAM 能為使用者提供叢集與其中資源的完整存取權限,但 Kubernetes 依據角色的存取權控管 (RBAC) 允許您使用 Kubernetes API 來對使用者可在叢集中執行的操作做進階管控。

叢集管理員可以利用 RBAC,為叢集中各個命名空間或整個叢集套用完善的細部政策。Kubernetes 指令列介面 kubectl 使用 gcloud 工具中的有效憑證,以允許叢集管理員將角色對應至 GCP 身分 (使用者和服務帳戶) 做為 RoleBindings 的主體。

以下圖為例,user-auser-b 這兩個使用者在 app-a 命名空間中分別被授予 config-readerpod-reader 角色。

RBAC 授權

又例如,GCP 專案層級的 IAM 角色可以為特定使用者授予專案中所有叢集的存取權。如果再透過 RBAC 加入個別命名空間和叢集層級的角色繫結,即可針對特定叢集或命名空間內的資源微調存取權限。

IAM 角色繫結

Kubernetes 包含一些預設的角色,然而做為叢集管理員,您可以根據組織需求自行建立角色。以下是一個範例角色,僅允許使用者查看、編輯和更新 ConfigMaps 但無法將其刪除,因其中並無包含 delete 動作。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

定義角色後,可透過繫結將這些角色套用於叢集或命名空間。繫結可將角色與其使用者、群組或服務帳戶建立關聯。以下範例將我們先前建立的角色 (config-editor) 繫結至 bob@example.org 使用者與 development 命名空間。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

如要進一步瞭解 RBAC,請參閱 GKE 說明文件

映像檔存取與共用

Container Registry 裡的映像檔會儲存在 Cloud Storage 中。本節將探討共用映像檔的兩種方法。一種方法是將映像檔設為公開,另一種方法是在專案之間共用映像檔。

將映像檔設為公開

將支援映像檔的物件及值區調整為公開,即可將映像檔設為公開。如需更詳細的操作說明,請參閱 Container Registry 存取權控管說明文件

跨專案存取映像檔

確保 Kubernetes 節點使用服務帳戶,以在專案間共用容器映像檔。與您的專案互相關聯的預設服務帳戶格式為 [PROJECT_ID]-compute@developer.gserviceaccount.com。有了這個 ID 後,您可以授予存取權,使其於您希望使用 Container Registry 的專案,擁有storage.viewer的權限。然而,由於預設服務帳戶具有可存取整個專案的編輯者權限,因此建議您使用已限制相關權限的自訂服務帳戶。

如要為您的叢集使用不同的服務帳戶,請在建立叢集或節點集區時,使用 --service-account 標記提供服務帳戶。例如,如要在 my-project 專案中使用 gke-sa 服務帳戶:

gcloud container clusters create west --service-account \
  gke-sa@my-project.google.com.iam.gserviceaccount.com

設定網路功能

Kubernetes 具備服務抽象化功能,可對叢集中的 pod 組合和叢集外執行的舊系統提供負載平衡及服務探索的功能。下列各節將說明 Kubernetes pod 之間及 Kubernetes pod 和其他系統 (包含其他 Kubernetes 叢集) 之間的最佳通訊實務。

同叢集內部通訊

服務探索

Kubernetes 可讓您定義服務,並依據標籤的組成,對叢集中執行的 pod 劃分群組。只要使用 DNS,即可在叢集中找到這個 pod 群組。如要進一步瞭解如何在 Kubernetes 中探索服務,請參閱透過服務連接應用程式

DNS

kube-dns 是部署在每個 GKE 業集中的本機叢集 DNS 伺服器,負責將服務名稱對應至健康狀態良好的 pod IP。Kubernetes DNS 伺服器預設回傳的是服務所屬的叢集 IP 位址。服務的整個生命週期中,此 IP 皆為靜態位址。對此 IP 位址傳送流量時,節點上的 iptable 會針對與服務選擇器相符且準備就緒的 pod 進行封包的負載平衡。iptable 由執行於每個端點上的 kube-proxy 服務自動編寫程式。

如果您需要服務探索及狀態監控功能,但希望 DNS 服務傳回 pod 的 IP 而不是虛擬 IP,那麼您在佈建服務時可以將 ClusterIP 欄位設定為「None」,如此一來服務就會成為無頭服務 (headless)。在這個情況下,DNS 伺服器會回傳一個 A 記錄清單,這些 A 記錄會將服務的 DNS 名稱對應至準備就緒的 pod 的 A 記錄,且這些 pod 必須符合服務定義的標籤選擇器。回應中的記錄會不斷輪換,以在各個 pod 之間散布負載。有些用戶端 DNS 解析器可能會將 DNS 回覆的內容快取,導致 A 記錄輪換失效。採用 ClusterIP 的優點,列舉在 Kubernetes 相關文獻

無頭服務其中一個典型的用途是使用 StatefulSets。如果您的有狀態應用程式需要針對備用資源提供穩定的儲存及網路連線效能,就非常適合使用 StatefulSets 來執行。這種類型的部署提供具有穩定網路識別的 pod,這表示可在叢集中解析出其主機名稱。雖然 pod 的 IP 位址可能會變更,但其主機名稱的 DNS 項目會一律保持在最新狀態且可以解析。

封包傳輸流:ClusterIP

下圖顯示了一個標準 Kubernetes 服務的 DNS 回應與封包傳輸流。雖然 pod IP 位址可從叢集外部透過路由傳送,但服務的叢集 IP 位址只能在叢集內部存取。這些虛擬 IP 位址是在各個 Kubernetes 節點中執行目標網路位址轉譯 (DNAT) 而實作出的。在每個節點上執行的 kube-proxy 服務會讓每個節點上的轉送規則保持在最新狀態,以便將叢集 IP 位址對應到叢集中健康狀態良好的 pod IP 位址。若在本機節點上存在著執行該服務的 pod,則使用該 pod,否則將在叢集中隨機選擇一個。

叢集 IP 服務

如要進一步瞭解實作服務 IP,請參閱 Kubernetes 相關文獻。如要深入瞭解 GKE 網路,請觀看 YouTube 頻道上的 Next 2017 演講:

無頭服務

以下是無頭服務的 DNS 回應及流量模式的範例,Pod IP 位址可透過預設的 GCP 子網路路由表導向,並由您的應用程式直接存取。

無頭服務的 DNS 回應及流量模式範例

網路政策

您可以使用 Kubernetes Engine 的「強制執行網路政策」來控制叢集的 Pod 和服務之間的通訊。若要定義 Kubernetes Engine 的網路政策,您可以使用「Kubernetes Network Policy API」來建立 Pod 層級的防火牆規則。這類防火牆規則會決定同一叢集內的哪些 Pod 和服務可相互存取。

網路政策是一種深度防禦,可以增強叢集上執行的工作負載的安全性。例如,您可以建立網路政策,確保應用程式中遭駭的前端服務不會直接與往下數層的計費或會計服務直接通訊。

網路政策也能用於隔離屬於不同用戶群的工作負載。例如,您可以為每個命名空間定義一個用戶群模型,提供安全的多用戶群架構。在這樣的模型中,網路政策規則可確保特定命名空間的 Pod 和服務無法存取其他命名空間的 Pod 和服務。

如要進一步瞭解網路政策,請參閱 GKE 說明文件

從 Google Cloud Platform 內部連線至 GKE 叢集

若要在 GCP 網路的非公開 IP 空間中,由叢集外部連線到您的服務,請使用內部負載平衡。在 Kubernetes 中使用 type: Load Balancercloud.google.com/load-balancer-type: Internal 註解來建立服務時,您的 GCP 專案中會產生一個內部網路負載平衡器,用來處理 pod 之間的 TCP 和 UDP 流量分配。

由叢集內部連線至外部服務

在許多情況下,會需要將在 Kubernetes 內執行的應用程式與叢集外部的服務、資料庫或是應用程式連線。您有 3 個選項,如下所述。

Stub 網域

在 Kubernetes 1.6 及更新的版本中,您可以設定叢集內部 DNS 服務 (kube-dns) 以將特定網域的 DNS 查詢轉送到外部 DNS 伺服器。當您擁有權威 DNS 伺服器,且需要針對 Kubernetes pod 使用的網域查詢該伺服器時,尤其適合做此設定。

外部名稱服務

外部名稱服務允許您將 DNS 記錄對應到叢集中的服務名稱。如此一來,叢集內服務的 DNS 查詢作業將會傳回您選擇的 CNAME 記錄。如果您只有少數要對應回現有 DNS 服務的記錄,則應使用此選項。

無選擇器服務

您可以在沒有選擇器的情況下建立服務,然後手動為其加上端點,以使用正確的值來填入服務探索。這允許您對叢集內服務皆使用相同的服務探索機制,同時確保無法透過 DNS 進行服務探索的系統仍可被存取。雖然此種方法最具彈性,但從長遠來看,也需要最多的設定和維護。

如要進一步瞭解 DNS,請參閱 Kubernetes DNS Pod 與服務說明文件頁面。

接收由網際網路發送至叢集的流量

來自網際網路的流量可以透過兩種不同的方法,導向到您在 Kubernetes 中執行的服務,方法分別為網路負載平衡和 HTTP(s) 負載平衡。

Kubernetes 服務應建立為 LoadBalancer 類型,以用於外部 TCP/UDP 負載平衡。Kubernetes 會在您的 GCP 專案中建立網路負載平衡器,並將其對應至您 Kubernetes Engine 叢集的節點。這是使用最少設定的情況下為 TCP 和 UDP 工作負載實現負載平衡的簡便方法。網路負載平衡器的範圍是地區性的,只能平衡在同一地區內執行的 pod 流量。

地區 us-west1 中的網路負載平衡器

針對 HTTP(S) 負載平衡,您可以利用 Google 的全域 HTTP(S) 負載平衡器,使用單一 anycast IP 位址對多個地區的流量進行負載平衡處理。在 Kubernetes 中,您可以建立 Ingress 資源,以便將主機名和路徑對應到叢集中的服務。您必須使用 type: NodePort 建立您的服務,Ingress 才能正常運作。

橫跨多個地區的負載平衡

防火牆

GKE 節點做為執行個體部署於 Compute Engine 中。因此,其遵循與其他執行個體相同的有狀態防火牆機制。這些防火牆規則使用標記透過您的網路套用到執行個體上。每個節點集區都會收到一組可在規則中使用的標記。預設情形下,節點集區中的每個執行個體都會收到一個標記,該標記代表此節點集區所屬的特定 Kubernetes Engine 叢集。此標記用於 Kubernetes Engine 自動建立的防火牆規則,您可以在 gcloud 指令列中使用 --tags 標記,在建立叢集或節點集區時加入自訂標記。

例如,要允許內部負載均衡器存取所有節點上的 8080 埠,您可以使用以下指令:

gcloud compute firewall-rules create \
  allow-8080-fwr --target-tags allow-8080 --allow tcp:8080 \
  --network gke --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

以下範例顯示兩個經過標記的叢集,其中一個叢集允許網際網路流量經由通訊埠 30000 存取節點,另一個叢集則允許流量從 VPN 流向通訊埠 40000。若您透過 NodePort 公開服務,這項功能非常有用,NodePort 只能使用受權限控管的網路存取,像是以 VPN 連回公司的資料中心,或是從您專案中的其他叢集連線。

以不同方式標記兩個叢集

連線至內部部署的資料中心

有數種 Cloud Interconnect 選項可用於連線至內部部署的資料中心。這些選項並不會互相牴觸,因此您可以根據工作負載及需求來組合這些選項:

  1. 針對非資料密集型或不易受到延遲影響的工作負載,使用網際網路。Google 有超過 100 個網路連接點 (PoP) 連接到世界各地的服務供應商。
  2. 直接對等互連,用於需要專用頻寬,易受到延遲影響,而且需要存取所有 Google 服務 (包含 GCP 產品完整套件) 的工作負載。直接對等互連屬於第 3 層連接,透過交換 BGP 路徑達成,因此需要已註冊的 ASN。
  3. 電信業者對等互連與直接對等互連相同,差別在此為透過服務供應商達成。若您沒有已註冊的 ASN,或是與偏好的服務供應商已有商業關係,這是個較佳的選擇。
  4. 雲端 VPN 透過第 3 層互連及網際網路選項 (1、2 和 3) 設定,若需要 IPsec 加密,或是想把私人網路擴展到私人 Compute Engine 網路的話,可參考此項。

後續步驟

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

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

這個網頁
解決方案