為生產準備 Google Kubernetes Engine (GKE) 環境
本文檔介紹如何以更安全可靠、更經濟實惠的方式將自己的容器化工作負載添加到 Google Kubernetes Engine (GKE)。它提供了為集群配置管理和網絡訪問權限的指南。 本文假定您對 Kubernetes 資源和集群管理有一定的瞭解，並熟悉 Google Cloud 網絡功能。
示例架構
下圖展示了用於部署 GKE 集群的靈活和高可用性結構範例。
項目
Google Cloud 在項目實體中創建其所有資源。
您可以使用項目表示各種操作環境。例如，您的運營團隊可能擁有 production 和 staging 項目，而開發者可能擁有 development 項目。您可以對包含最關鍵、最敏感的數據和工作負載的項目應用更精細、更嚴格的政策。然後，您可以為 development 環境中的開發者應用更寬松和靈活的政策進行實驗。
集群
一個項目可以包含多個集群。如果要部署多個工作負載，可選擇為這些工作負載使用一個共用集群或多個單獨集群。
網絡和子網
在每個項目中，您可以擁有一個或多個 VPC 網絡，這些網絡是物理網絡的虛擬版本。每個 VPC 網絡都是一個全域資源，包含其他與網絡相關的資源，例如子網、外部 IP 位址、防火牆規則、路由、VPN 和 Cloud Router。在 VPC 網絡中，您可以使用子網（地區性資源）來隔離和控制進出 GKE 集群間每個地區的流量。
每個項目都配有一個默認網絡。您可以創建和配置其他網絡以映射到現有的 IP 位址管理 (IPAM) 慣例。然後，您可以為此網絡應用防火牆規則，以過濾進出 GKE 節點的流量。默認情況下，系統會拒絕進入您的 GKE 節點的所有外部流量。
如需控制子網之間的通信，您必須創建防火牆規則以允許流量在子網之間傳遞。在集群或節點池創建期間使用 --tags 標誌適當地標記 GKE 節點，使防火牆規則生效。如果需要，您還可以使用標記在子網之間創建路由。
地區和集群
您可以創建標準集群和 Autopilot 集群。Autopilot 集群是地區級集群。標準集群是地區級集群或區域級集群。區域級集群可以是單區域集群，也可以是多區域集群。多地區和區域性集群在一個區域內的多個地區中分佈資源，從而提高集群的可用性和彈性。
區域級集群具有以下屬性：
創建在單個地區中運行的控制層面的單個副本。
如果為多地區集群，則在多個地區中運行節點。
地區級集群具有以下屬性：
在三個地區中複製控制層面。
可以在多個地區或單個地區中運行節點，具體取決於配置的節點位置。
您可以在創建集群時選擇創建區域級或地區級集群。您也可以將新可用區添加到現有集群，以使其成為多可用區級集群。但是，您無法將現有可用區級集群更改為區域級集群，也無法將區域級集群更改為可用區級集群。
Compute Engine 服務等級協議 (SLA) 涵蓋 GKE 管理的集群中節點的服務可用性。
如需詳細瞭解區域級和地區級集群，請參閱 GKE 文檔。
管理身份和訪問權限
Identity and Access Management (IAM) 角色和群組
下圖是一個 IAM 政策佈局，它顯示為 dev 項目和 prod 項目提供最小權限原則；其中第一個項目設置供開發者用來開發和測試他們即將推出的功能和問題修復，第二個項目用於處理生產流量：
如下表所示，組織中有 4 組用戶，分別具有 2 個項目中不同級別的許可權，這些許可權通過 IAM 角色授予：
團隊 | IAM 角色 | 項目 | 許可權 |
開發者 | roles/container.developer | dev | 可以為專案中的現有集群創建 Kubernetes 資源，但不允許創建或刪除集群。 |
運維 | roles/container.admin | prod | 對專案中運行的集群和 Kubernetes 資源有完整的管理員許可權。 |
安全 | roles/container.viewer roles/compute.securityAdmin | prod | 創建、修改和刪除防火牆規則和 SSL 證書，以及查看在每個集群中創建的資源，包括正在運行的 pod 的日誌。 |
網路 | roles/compute.networkAdmin | prod | 創建、修改和刪除網路資源，防火牆規則和 SSL 證書除外。 |
除了有權訪問 prod 項目的 3 個團隊之外，還有一個額外的服務帳號被授予了 prod 專案的 container.developer 角色，這樣，該服務帳號就可以創建、列出和刪除集群中的資源。服務帳號可用於為自動腳本或部署框架提供代表您執行操作的能力。 對生產項目和集群的部署應該通過自動化流水線進行。
在 dev 項目中，有多個開發者在同一個集群中處理同一個應用。集群用戶可以通過創建命名空間來實現此操作。如此一來，每個開發者都可以在自己的命名空間中創建資源，從而避免命名衝突。此外，他們還可以為其部署重複使用相同的 YAML 設定檔，以使開發反覆運算期間的配置盡可能相似。
不僅如此，命名空間還可用于為集群創建 CPU、記憶體和存儲空間配額，確保一個開發者不會在集群中使用太多資源。如需詳細瞭解如何使用命名空間，請參閱 Kubernetes 最佳做法：在 YAML 中指定命名空間。
下一部分介紹對用戶在某些命名空間中的操作實施的限制。
基於角色的存取權限控制
運行 Kubernetes 1.6 及更高版本的 GKE 集群可採用進一步的措施來限制用戶在各集群中有權執行的操作。IAM 可以為用戶提供對完整集群及其中資源的存取權限，但通過 Kubernetes 基於角色的存取權限控制 (RBAC)，您可使用 Kubernetes API 進一步限制用戶在其集群中可執行的操作。
通過 RBAC，集群管理員可以將精細政策應用于其集群中的各個命名空間或整個集群。Kubernetes kubectl 工具使用 gcloud CLI 中的有效憑據，使集群管理員能夠將角色映射到 Google Cloud 身份（使用者、服務帳號和 Google 群組）作為 RoleBinding 中的主體。
借助 Google RBAC 群組，您可以將群組與 Kubernetes RBAC 搭配使用。要使用此功能，您必須配置 Google 工作區 Google 群組，創建啟用了該功能的集群，然後使用 RoleBinding 將您的群組與您要將它們綁定到的角色相關聯。如需瞭解詳情，請參閱基於角色的存取權限控制。
例如，下圖中有兩名用戶 user-a 和 user-b，他們已在 app-a 命名空間中被授予 config-reader 和 pod-reader 角色。
還有一個例子是 Google Cloud 項目級的 IAM 角色，它使特定用戶能夠訪問項目中的所有集群。此外，通過 RBAC 添加單獨的命名空間和集群級層角色綁定，可以實現對特定集群或命名空間內的資源的精細訪問。
Kubernetes 包含一些默認角色，但作為集群管理員，您可以自行創建與您組織的需求更加貼合的角色。以下示例角色僅允許用戶查看、修改和更新 ConfigMap，但由於不包含 delete 謂詞，因此禁止刪除：
kind: Role apiVersion: rbac.authorization.k8s.io/v1 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/v1 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 或 Artifact Registry 中的映射存儲在 Cloud Storage 中。
本部分介紹共用映射的以下方法：
公開映射。
在項目之間共用映射。
注意：由於 Artifact Registry 是管理容器映射的推薦服務，因此本文檔中的以下部分將僅重點介紹 Artifact Registry。
如果啟用了專用集群，則使用 Artifact Registry 非常重要。在專用集群中，除非您設置 Cloud NAT，否則集群的容器運行時無法直接從外部容器註冊表中拉取容器映射。容器運行時可以從專用集群中的 Artifact Registry 中拉取映射，而無需 Cloud NAT 或專用 Google 訪問通道。如果節點需要直接與 Artifact Registry 通信（例如，節點需要創建新工件並將其存儲在 Artifact Registry 中），則必須將節點放置在啟用了專用 Google 訪問通道的子網中。如需瞭解詳情，請參閱從映射註冊表中拉取容器映射。
在 Artifact Registry 中公開映射
您可以通過在 Artifact Registry 中公開其物件和存儲分區來公開映射。如需瞭解詳細說明，請參閱 Artifact Registry 存取權限控制文檔。
如果必須使用公共映射，請考慮驗證可部署到集群中的公共映射集。（如需瞭解詳情，請參閱 Binary Authorization 部分。）
在 Artifact Registry 中跨專案訪問映射
確保 Kubernetes 節點使用服務帳號後，您可以在項目間共用容器映射。您可以向服務帳號授予存取權限作為astorage.viewer使用 Artifact Registry 的專案。使用具有受限許可權的自訂服務帳號，因為預設服務帳號對整個專案擁有 Editor 存取權限。
如需為集群使用其他服務帳號，請在創建集群或節點池時使用 --service- account 標誌提供服務帳號。
如需瞭解詳情，請參閱配置存取權限控制。
確定正確的映射拉取政策
Kubernetes 中的 imagePullPolicy 屬性確定 kubelet 是否會在啟動 pod 時嘗試拉取映射。配置適當的 imagePullPolicy 設置，以指定容器映射。例如，您可以指定以下映射拉取政策：
imagePullPolicy: IfNotPresent
在這種情況下，Kubelet 僅當映射在節點的緩存中不可用時才檢索映射的副本。
如需詳細瞭解您可以指定的潛在映射拉取政策，請參閱 Kubernetes 文檔中的容器映射。
使用動態管理控制器來強制執行政策
動態准入控制器是 Kubernetes 控制平面的一部分。它們可以攔截向 API 伺服器發出的傳入請求。准入控制器是一款強大的工具，可幫助您在 GKE 集群中強制執行特定於企業的自訂政策。
Kubernetes 支援兩種類型的准入控制器：更改准入控制器和驗證准入控制器。
更改准入控制器會攔截准入請求，並且會更改請求。然後將請求傳遞到 API 伺服器。
驗證准入控制器可以檢查請求，並根據您指定的規則確定請求是否有效。如果在集群中配置任何驗證准入控制器，則會在 API 伺服器驗證請求後調用它們。驗證准入控制器可以拒絕請求，以確保符合控制器中定義的政策。
例如，您可使用更改准入控制器來強制即時映射拉取政策，確保無論提交 pod 創建請求的開發者指定的 imagePullPolicy 設置如何，該政策均設置為 Always。
使用 Google Cloud Marketplace 中的預封裝應用
您還可以考慮從 Google Cloud Marketplace 部署預封裝的 Kubernetes 應用。Google Cloud Marketplace 上列出的 Kubernetes 應用已經過 Google 測試和審核，其中包括適用於維護和支援的漏洞掃描以及合作夥伴協定。
此外，請務必採用良好的映射版本控制做法：使用良好的標記慣例，並在適用的情況下考慮使用摘要（而不是標記）。
使用 Workload Identity 與 Google Cloud 服務 API 進行交互
通常，企業架構涉及跨雲服務（雲代管式服務和託管式服務）的架構組件。它是 GKE 應用或服務與 Google Cloud 代管式服務（如 Cloud Storage 和 BigQuery）通信的常用模式。例如，在通過 GKE 中的批量作業將客戶記錄處理到 BigQuery 中供後續分析之後，您可能需要存儲這些記錄。
Workload Identity 允許 GKE 集群中的 Kubernetes 服務帳號充當 IAM 服務帳號。訪問 Google Cloud API 時，使用已配置 Kubernetes 服務帳號的 Pod 會自動作為 IAM 服務帳號進行身份驗證。請注意，這假設您已授予訪問 Google Cloud 服務帳號所需的服務存取權限級別。
管理集群安全
安全是一項多方面的準則，在 GKE 集群的企業部署中至關重要。本部分介紹了可用於強化集群安全的幾個因素。
映射的漏洞掃描
Artifact Registry 可以掃描映射中是否存在已知的安全性漏洞。支持的映射包括 Ubuntu、Debian、RedHat 等（如需查看完整列表，請參閱漏洞來源）。我們建議您掃描您計畫在 GKE 集群中使用的映射。
如果可能，請啟用 Container Analysis，以進一步降低安全風險。
如需查看映射的漏洞，請參閱自動掃描映射。
如果對 Artifact Registry 代碼庫進行更改，您的組織將能夠從自動跟蹤通知和接收通知中受益。例如，您可以在創建新映射或刪除映射時收到通知。您可以構建流水線，其中應用偵聽器可訂閱 Artifact Registry 事件發佈到的 Pub/Sub 主題。然後，您可以使用這些事件觸發構建或自動部署。如需瞭解詳情，請參閱 Artifact Registry 文檔。
Binary Authorization
使用 Kubernetes 時，您必須確定映射是否應以及何時可用于部署到集群。對於此任務，您可以使用 Binary Authorization。這是一種部署時構造，它讓您定義一個工作流，該工作流必須強制執行簽名，才能為您的集群部署簽名（證明）。
工作流根據政策進行定義。當您通過 CI/CD 流水線移動代碼並因此移動容器映射時，Binary Authorization 會對 Binary Authorization 政策中定義的每個階段記錄證明。這些證明用於驗證映射已成功傳遞定義的里程碑。
Binary Authorization 與 GKE 部署 API 集成，並可確保映射的部署受擁有全部所需證明的映射的約束。系統會自動記錄失敗的部署嘗試，而且集群管理員可以查看和審核。
如需查看教程瞭解如何使用 Cloud Build 為 GKE 實現 Binary Authorization，請參閱使用 Cloud Build 和 GKE 實現 Binary Authorization。
在 GKE Sandbox 中使用 gVisor 安全訪問
容器有一層安全和內核隔離，但可能仍然容易遭到攻擊，進而導致攻擊者獲得對主機作業系統 (OS) 的存取權限。要在容器與其主機作業系統之間實現安全隔離，更靈活的一種方法是另外創建一個分離層。一種方法是使用 GKE Sandbox。
GKE Sandbox 使用 gVisor，它是 Google 發佈的開源容器運行時。gVisor 在內部創建容器與之互動的虛擬內核，即可抽象出容器與主機內核的覆蓋率。此外，它還控制容器可以執行的檔操作和網路操作。
由於 GKE Sandbox 會產生額外的隔離層，因此可能會需要額外的記憶體和產生額外的 CPU 開銷。在使用 GKE Sandbox 之前，請考慮哪些工作負載需要這種高級別的安全措施。通常情況下，最好選擇基於外部映射的服務。
如需瞭解如何創建啟用了 GKE 的節點池，請參閱使用 GKE Sandbox 強化工作負載隔離。
審核日誌記錄
Kubernetes 審核日誌記錄會記錄對 Kubernetes API 伺服器發出的所有 API 請求。此日誌記錄有助於您檢測異常情況以及異常的訪問和配置設置模式。以下是您可能想要查看和提醒的示例：
刪除部署。
附加或使用 exec 來訪問具有特權存取權限的容器。
修改 ClusterRole 對象或為集群角色創建角色綁定。
在 kube-system 命名空間中創建服務帳號。
GKE 將 Kubernetes 審核日誌記錄與 Cloud Audit Logs 和 Cloud Logging 集成。訪問這些日誌的方式與訪問 Cloud 專案中運行的資源的日誌的方式相同。可以記錄向 Kubernetes API 伺服器發出的 API 請求，您可以使用這些請求來查看 API 活動模式。
Kubernetes API 伺服器捕獲的每個請求（事件）都會使用您定義的一個或多個政策進行處理。這些政策可以是 Kubernetes 審核政策（確定記錄哪些事件），也可以是 Google Kubernetes Engine 審核政策（確定事件是記錄在管理員活動日誌中還是記錄在資料日誌中）。管理員活動日誌預設啟用。如果需要記錄有關集群中讀取或寫入的中繼資料和資料的詳細資訊，您還可以啟用資料訪問日誌記錄。請注意，啟用資料訪問日誌記錄可能會產生額外費用。如需瞭解詳情，請參閱價格文檔。
Pod 安全政策
一種常見的攻擊途徑是部署擁有已升級特權的 pod 來試圖訪問 Kubernetes 集群。Gatekeeper 是一種准入控制器，它使用的政策概述了 Pod 可執行的操作。您可以使用它來限制對命名空間的使用方式、卷類型的使用方式以及底層作業系統功能的存取權限。
容器安全注意事項
Kubernetes 服務的基礎構件是容器。這使得容器安全在規劃集群安全和政策時成為關鍵因素。請仔細注意下列各項：
從中構建容器的映射。
您分配給容器的特權。
容器與主機作業系統和其他服務的對話模式。
容器訪問和記錄敏感資訊的方式。
管理集群中容器的生命週期的方式。
配置網路
Kubernetes 提供了服務抽象，其中包含集群內多組 pod 以及集群外運行的舊系統之間的負載平衡和服務發現。以下部分介紹了在 Kubernetes pod 之間以及與其他系統（包括其他 Kubernetes 集群）之間進行通信的最佳做法。
VPC 原生集群與基於路由的集群的對比
根據 GKE 集群將流量從一個 pod 路由到另一個 pod 的方式，這些集群可以分為兩類。
使用別名 IP 位址範圍路由流量的集群；這稱為 VPC 原生集群。
使用 Google Cloud 路由的集群稱為基於路由的集群。
VPC 原生集群使用 pod 網路的別名 IP 地址範圍。這意味著控制平面會自動管理 pod 的路由配置，而不是為 GKE 集群中的每個節點配置和維護靜態路由。借助別名 IP 位址範圍，您可以配置多個內部 IP 位址來表示虛擬機器中託管的容器或應用，無需定義單獨的網路介面。Google Cloud 將自動安裝 VPC 網路路由，以便為主要網路介面的子網獲得主要和別名 IP 地址範圍。這大幅簡化了 pod 之間的流量路由。
此外，VPC 原生集群不受路由配額的限制。在集群結構中利用別名 IP 位址範圍可直接訪問 Google 服務，例如 Cloud Storage 和 BigQuery；否則，只能通過 NAT 閘道進行訪問。
讓 GKE 集群與本地的應用和服務生態系統安全地通信是企業採用的一種常見模式。別名 IP 位址範圍允許這樣做，因為別名 IP 位址可以通過 Cloud VPN 或 Cloud Interconnect 發現。這有助於為您的本地基礎架構和 Google Cloud 基礎架構提供安全連接。
您需要確定哪種集群類型最適合您的網路拓撲。主要因素是網路中 IP 位址的可用性、企業中的集群（節點）擴展計畫，以及與生態系統中其他應用的連線性。VPC 原生集群在網路中往往會消耗更多的 IP 位址，因此您應考慮到這一點。請注意，您無法在創建並將基於路由的集群遷移到 VPC 原生集群後再將 VPC 原生集群遷移到基於路由的集群，因此請務必瞭解所選選項的影響，然後再實現它。
控制平面訪問的授權網路
授權網路選項限制從您指定的 CIDR 範圍存取控制層面端點（API 伺服器），並確保只有您網路中的團隊才能管理您的集群。
這些功能具有以下要求：
僅允許指定 50 個 CIDR 範圍。
如果您使用的是 CI/CD 流水線，若要允許 CI/CD 工具訪問集群的 API 伺服器，則必須將其 IP 地址或 CIDR 範圍添加到許可名單（請參閱 VPC 防火牆規則概覽。
專用集群
預設情況下，GKE 集群中的所有節點都具有公共 IP 位址。一個好的做法是創建專用集群，使所有工作器節點僅獲得專用 RFC 1918 IP 地址。專用集群會強制執行網路隔離，從而降低集群面臨的風險。使用專用集群意味著在預設情況下，只有網路中的用戶端才能訪問集群中的服務。為了允許外部服務訪問集群中的服務，您可以使用 HTTP(S) 負載等化器或網路負載等化器。
如果要開放對 VPC 網路外部控制層面的存取權限，您可以將專用集群用於已獲授權的網路。啟用授權網路後，集群控制層面端點將獲得兩個 IP 地址：一個內部（專用）位址和一個公共位址。內部 IP 位址可供同一地區中您網路內部的任何內容使用。控制平面的公共 IP 位址可供您網路外部的任何使用者或進程使用，這些使用者或進程來自允許的 CIDR 範圍或 IP 地址。您還可以將此功能與 Cloud Interconnect 或 Cloud VPN 結合使用，以便僅從私有資料中心存取控制平面。
數據滲漏防護
此外，您還可以使用 VPC Service Controls 來説明降低數據滲漏的風險。通過 VPC Service Controls，可定義用於訪問這些服務的服務邊界，從而説明您保護一個或多個專案中的代管式 Google Cloud 服務。您可以設置適當的存取權限級別，向 GKE 集群中運行的應用授予訪問這些代管式服務的許可權。您還可以使用 VPC Service Controls 來保護 GKE 集群創建控制平面。
在同一集群中進行通信
服務發現
Kubernetes 允許您根據一組標籤來定義對集群中運行的 pod 分組的服務。使用 DNS 可以在集群中發現此組 pod。如需詳細瞭解 Kubernetes 中的服務發現，請轉至連接應用和服務文檔。
DNS
本地集群 DNS 伺服器 kube-dns 部署在每個 GKE 集群中，用於將服務名稱映射到運行狀況良好的 pod IP 地址。預設情況下，Kubernetes DNS 伺服器返回服務的集群 IP 位址。 此 IP 位址在服務的整個生命週期內是靜態的。向此 IP 地址發送流量時，節點上的 iptables 將在與服務選擇器匹配的就緒 pod 中對資料包進行負載均衡。這些 iptables 由每個節點上運行的 kube-proxy 服務自動編寫。
數據包流：ClusterIP
下圖展示了標準 Kubernetes 服務的 DNS 回應和資料包流。雖然 pod IP 位址可從集群外部路由，但服務的集群 IP 位址只能在集群中訪問。這些虛擬 IP 位址通過在每個 Kubernetes 節點中執行目的網路位址轉譯 (DNAT) 來實現。 在每個節點上運行的 kube-proxy 服務使每個節點上的轉發規則保持最新，以將集群 IP 位址映射到集群中運行狀況良好的 pod 的 IP 位址。如果本地節點上運行了該服務的 pod，則使用該 pod，否則將隨機選擇集群中的某個 pod。
如需詳細瞭解如何實現 ClusterIP，請轉到 Kubernetes 文檔。
無頭服務
如果您要使用服務發現和運行狀況監控，但卻要 DNS 服務返回 pod 的 IP 位址而不是虛擬 IP 位址，您可將 ClusterIP 欄位設置為 None，這會將該服務預配為無頭服務。
在這種情況下，DNS 伺服器返回 A 記錄清單，此清單將服務的 DNS 名稱映射到與服務定義的標籤選擇器匹配的就緒 pod 的 A 記錄。回應中的記錄進行輪替以便在各個 pod 上傳播負載。但請注意，某些用戶端 DNS 解析器可能會緩存 DNS 應答，導致 A 記錄輪替無效。如需瞭解使用 ClusterIP 的優點，請參閱 Kubernetes 文檔。如需詳細瞭解如何在 GKE 中使用 ClusterIP，請參閱使用 Service 公開應用。
無頭服務的一個典型使用場景是 StatefulSets。StatefulSets 非常適合運行必須為其副本提供穩定存儲空間和網路連接的有狀態應用。此類部署預配具有穩定網路標識的 pod，這意味著其主機名稱可以在集群中進行解析。雖然 pod 的 IP 位址可能會更改，但其主機名稱 DNS 條目會保持最新且可解析。
以下是無頭服務的 DNS 回應和流量模式的示例。通過默認 Google Cloud 子網路由表即可路由 Pod IP 位址，您的應用還可直接訪問這些位址。
網路政策
您可以使用 GKE 網路政策強制執行功能來控制集群的 pod 與 Service 之間的通信。要在 GKE 上定義網路政策，可以使用 Kubernetes Network Policy API 創建 Pod 級層的防火牆規則。這些防火牆規則確定了哪些 pod 和 Service 可以在集群內相互訪問。
網路政策可增強集群上運行的工作負載的安全性。例如，您可以創建網路政策，以確保應用中受侵的前端服務無法直接與低了幾個級層的結算或記帳服務進行通信。
您還可以使用網路政策來隔離屬於不同租戶的工作負載。例如，您可以通過定義一個模型，使每個命名空間都有一個租戶，來提供安全的多租戶。在此類模型中，網路政策規則可確保給定命名空間中的 Pod 和服務無法訪問其他命名空間中的其他 Pod 或服務。
從 Google Cloud 內部連接到 GKE 集群
如需從集群外部但在 Google Cloud 網路的專用 IP 位址空間內連接到您的服務，請使用內部負載均衡。在 Kubernetes 中創建具有 type: Load Balancer 和 cloud.google.com/load-balancer-type: Internal 注釋的服務時，系統會在您的 Google 項目中創建內部網路負載平衡器，並將其配置為在 pod 之間分配 TCP 和 UDP 流量。
從集群內部連接到外部服務
在許多情況下，有必要將在 Kubernetes 內運行的應用與集群外部的服務、資料庫或應用連接起來。您有 3 種選擇，如以下部分所述。
選項 | 說明 |
存根網域 | 在 Kubernetes 1.6 及更高版本中，您可以配置集群內部 DNS 服務 (kube-dns) 以將特定網域的 DNS 查詢轉發到外部 DNS 伺服器。如果您擁有授權 DNS 伺服器，並應從中查詢 Kubernetes pod 必須使用的網域時，這會非常有用。 |
外部名稱服務 | 外部名稱服務允許您將 DNS 記錄映射到集群中的服務名稱。在這種情況下，集群內服務的 DNS 查找會返回您選擇的 CNAME 記錄。如果您只有幾條記錄需要映射回現有的 DNS 服務，請使用此方法。 |
無選擇器的服務 | 您可以創建無選擇器的服務，然後手動向其添加端點，以使用正確的值填充服務發現。此方案允許您為集群內的服務使用相同的服務發現機制，同時確保仍可通過 DNS 訪問沒有服務發現的系統。雖然這種方法最靈活，但從長遠來看，它需要最多的配置和維護。 |
如需詳細瞭解 DNS，請轉到 Kubernetes DNS Pod 和服務文檔頁面。
在 Kubernetes 中配置服務以接收互聯網流量
您可以使用 NodePort、ClusterIP 和 LoadBalancer 公開 Kubernetes 服務。
但是，如果您有許多面向外部的服務，則可以考慮使用 Kubernetes Ingress 資源。Ingress 為集群提供了入口點，並允許您定義路由規則，以將傳入請求路由到集群中的一個或多個後端服務。在 GKE 中，GKE Ingress 控制器將 Ingress 資源實現為 Google Cloud HTTP(S) 負載等化器，並根據 Ingress 資源及其關聯服務中的資訊對其進行配置。 如需瞭解詳情，請參閱配置 Ingress 以進行外部負載均衡。
只有在應用通過 HTTP(S) 處理流量時，才能使用 Kubernetes Ingress 資源。如果後端服務使用 TCP 或 UDP 協定，則必須改為使用網路負載平衡器。例如，如果您需要將資料庫作為服務公開，可能就需要這樣做。
後端配置
BackendConfig 是一種自訂資源定義，可以提供 Kubernetes Ingress 控制器使用的其他規範配置。在 GKE 集群中部署 Ingress 對象時，Kubernetes Ingress 控制器將配置 HTTP(S) 負載平衡器，以便將傳入請求路由到您在 Ingress 清單中指定的後端服務。
您可以使用如下規範補充負載平衡器的配置：
使用 Cloud CDN 啟用緩存。
使用 Google Cloud Armor 添加 IP 地址或 CIDR 許可名單。
使用 Identity-Aware Proxy (IAP) 控制應用級存取權限。
為受集群中 Ingress 物件約束的服務配置服務超時和連接排空超時。
如需詳細瞭解如何在 GKE 中配置 BackendConfig 自訂資源，請參閱 Ingress 功能。
使用服務網格
服務網格提供了一種統一的方式來連接、保護和管理 Kubernetes 集群中運行的微服務。例如，您可作為 GKE 外掛程式添加的 Istio 服務網格可以管理服務到服務的身份驗證和通信、強制執行訪問政策，還能收集可用於審核和管理 GKE 集群的豐富的遙測資料點。
服務網格提供的主要功能包括：
流量管理。借助服務網格，您可以定義精細的規則來確定流量的路由方式，並在若干服務之間或在同一服務的不同版本之間拆分流量。這樣可以更輕鬆地發佈 Canary 版部署和藍綠部署。
內置可觀測性。網格以統一方式記錄網路流量（第 4 層和第 7 層）指標，無需您編寫代碼來檢測服務。
安全。網格實現了服務之間的雙向 TLS (mTLS)。它不僅為傳輸中的資料提供秘密頻道，還可説明您管理網格中服務的身份驗證和授權。
總之，通過 Istio 等服務網格，您可以將系統級任務委託給網格基礎架構，這有助於提高 Kubernetes 集群中運行的服務的整體敏捷性、穩健性以及鬆散耦合。
如需瞭解如何將服務網格與 Anthos 搭配使用，請參閱關於 Anthos Service Mesh。
防火牆
GKE 節點在 Compute Engine 中配置為實例。因此，它們遵循與其他實例相同的有狀態防火牆機制。這些防火牆規則通過使用標記在您的網路中應用於實例。每個節點池都將收到自己的一組標記，你可在規則中使用這些標記。預設情況下，屬於節點池的每個實例都會收到一個標記，該標記標識此節點池所屬的特定 Kubernetes Engine 集群。此標記用於 Kubernetes Engine 自動為您創建的防火牆規則。您可以使用 gcloud CLI 中的 --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。當通過只能使用特權網路（如訪問公司資料中心的 VPN）或從專案中的其他集群進行訪問的 NodePort 公開服務時，這會非常有用。
連接到本地資料中心
您可以使用 Cloud Interconnect 或 Cloud VPN 連接到本地資料中心。這些方案不是互斥的，因此您可以根據工作負載和需求來組合使用：相關選項如下所示：
使用專用互連在網路之間傳輸大量資料，延遲低。
如果您的資料中心不在專用互連對接網點中，請使用合作夥伴互連。Google 擁有超過 100 個連接到世界各地服務提供者的接入點 (PoP)。
對於需要專用頻寬、對延遲時間敏感，且需要訪問 Google Workspace 和受支持的 Google API 的工作負載，請使用直接對等互連。直接對等互連是第 3 層連接，通過交換 BGP 路由完成，因此需要已註冊的 ASN。
如果您沒有已註冊的 ASN，或者已與偏好的服務提供者建立關係，請使用運營商對等互連。運營商對等互連，與直接對等互連相同，但通過服務提供者完成。
如果需要 IPSec 加密，或者希望將私人網路絡擴展到專用 Compute Engine 網路，請使用 Cloud VPN。Cloud VPN 通過第 3 層互連和互聯網方案（1、2 和 3）進行配置。
管理集群可操作性
本部分介紹在管理和操作 GKE 集群時需要考慮的關鍵因素。
資源配額
Kubernetes 資源配額提供的限制條件會限制集群中每個命名空間的總體允許資源消耗量。如果您的集群具有隔離業務功能或開發階段的 Kubernetes 命名空間，則可以使用配額來限制各種資源，例如 CPU 利用率、記憶體或可在命名空間內創建的 pod 數量和服務數量。為了確保 GKE 集群的控制平面的穩定性，Kubernetes 會自動將默認的不可替換的資源配額應用於任何具有 5 個或更少節點的 GKE 集群中的每個命名空間。
資源限制
您可以使用 Kubernetes LimitRange 對象對創建容器和 pod 的最小和最大資源邊界實施精細限制。以下示例展示了如何使用 LimitRange：
apiVersion: v1 kind: LimitRange metadata: name: sample-limits spec: limits: - max: cpu: "400m" memory: "1Gi" defaultRequest: cpu: "200m" memory: "500Mi" type: Container |
Pod 中斷預算
Pod 中斷預算 (PDB) 有助於防止您的團隊自願刪除或意外刪除 pod 或部署。PDB 無法防止由節點關閉或重啟而導致的非自願中斷。通常，操作員為應用創建一個 PDB，用於定義應用的 pod 的最小副本數。
如果在某家企業中開發者要處理多個應用，那麼錯誤不可避免，而且開發者或管理員可能會意外運行用於刪除 pod 或部署（也就是刪除 Kubernetes 資源）的腳本。但是，通過定義 PDB，您可以始終確保為 Kubernetes 應用維持一組最低限度的有效資源。
GKE 升級期間會採用您為 GKE 集群配置的 PDB。這意味著，您可以在升級期間控制應用的可用性。以下示例展示了如何配置 PDB。
apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: nginx-pdb spec: minAvailable: 4 selector: matchLabels: app: nginx |
管理 Kubernetes 升級
將 GKE 上的 Kubernetes 集群更新為符合您要求的最新版的 Kubernetes。您可以選擇自動升級控制層面或節點，也可以自行控制升級。
您可以在控制台、Anthos 安全公告和集群升級通知中查看升級通知。如果您要手動升級節點，我們建議您在查看發佈內容並在沙箱化的運行集群中測試應用後，觸發版本升級。
當區域級集群的控制層面正在進行升級時，它不可用。這意味著您無法與 API 伺服器進行互動來在集群中添加或移除資源。如果您無法忍受升級控制層面的停機時間，則可以通過部署地區性 GKE 集群來使控制層面具有高可用性。通過這種方法，您可以跨區域分佈多個控制平面。當一個控制層面升級時，對 API 伺服器的任何控制層面請求都會路由到其他控制層面。
當應用升級時，GKE 都會對工作器節點應用滾動更新：當有新的替換節點可用於回應傳入的請求時，它會系統地排空、關閉和升級一個節點。
節點自動修復
GKE 節點自動修復功能用於管理 GKE 節點的健康檢查。如果發現任何節點運行狀況不佳，GKE 會啟動節點修復進程。
如果您的 GKE 集群具有多個節點池，則自動修復功能可讓您精確控制要為其啟用節點自動修復功能的節點池。
自動擴縮 GKE 集群
對於在其 Kubernetes 集群中運行的應用，企業經常會遇到不同的傳入負載。為了回應這些業務驅動的更改，您可以使 GKE 集群能夠自動做出回應，並根據指標進行擴縮。
自動擴縮包括多個維度，如以下幾個部分所述。
集群自動擴縮器
GKE 集群自動擴縮器會根據您的工作負載需求自動添加和移除集群節點。為單個節點池啟用集群自動擴縮器。對於每個節點池，GKE 會檢查是否有由於容量不足而等待調度的 pod。如果有，集群自動擴縮器會將節點添加到該節點池中。
集群自動擴縮程式會根據資源請求進行擴縮。如果節點利用率過低，並且正在運行的 pod 可被安排到具有容量的其他節點上，則利用率低下的節點會被排空並終止。
通過指定集群自動擴縮器可調節到的最小和最大節點數，您可以為節點池設置邊界。
節點自動預配
通過節點自動預配功能，GKE 集群自動擴縮器能夠在自動擴縮器確定需要其他節點池時自動預配這些節點池。如果這些節點池中沒有節點，集群自動擴縮器也可以刪除自動預配的節點池。
如果您的 GKE 集群中運行各種工作負載，則節點自動預配功能非常有用。例如，如果您的 GKE 集群具有依賴於 GPU 的工作負載，則您可以在預配了支持 GPU 的節點的專用節點池中運行該集群。您可以指定最小和最大節點池大小來定義節點池擴縮邊界。
如需詳細瞭解節點自動預配功能以及啟用時機，請參閱使用節點自動預配。
Pod 橫向自動擴縮
借助 Kubernetes，您可以創建橫向 Pod 自動擴縮器，用於配置 Kubernetes 部署或 ReplicaSet 擴縮的方式以及擴縮決策應依據的指標。預設情況下，Pod 橫向自動擴縮程式控制器根據 CPU 利用率作出自動擴縮決策。但是，Pod 橫向自動擴縮程式控制器還可以根據自訂指標（例如 HTTP 請求數）來計算 pod 應該如何擴縮。要讓橫向 Pod 自動擴縮程式回應自訂指標，通常還需要其他監控插樁。
如需瞭解詳情，請參閱 Kubernetes 和 GKE 文檔。
Pod 縱向自動擴縮
借助 GKE 集群中的縱向 Pod 自動擴縮 功能，您可將為容器指定最佳 CPU 和記憶體請求的任務進行分流。必要時，Pod 縱向自動擴縮功能會調整對集群中容器的資源配置量。通過 Pod 縱向自動擴縮功能，您可以在每個節點的容器級層進行優化，從而優化集群的資源利用率。此外，這還將為您節省維護資源所需的管理時間。
Pod 縱向自動擴縮功能與下一部分中介紹的節點自動預配功能配合使用。
由於 Kubernetes 的限制，pod 上的資源請求只能在 pod 重啟時更改。因此，要進行更改，Pod 縱向自動擴縮會逐出 Pod。如需瞭解詳情，請參閱 GKE 和 Kubernetes 文檔。
Autopilot
Autopilot 表示 GKE 代表您預配和管理集群的底層基礎架構。使用 Autopilot 時管理以下項：
節點和節點池
資源預配
節點映射類型
網路功能，例如集群類型和 CIDR 範圍
Workload Identity 或安全強化型虛擬機器等安全功能
如果您要減少操作負載，並且不需要為更複雜的工作負載配置特定項，則 Autopilot 非常有用。
Comments