最佳實務

• 1: 大型叢集的考量事項
• 2: 跨區域執行
• 3: 驗證節點架設
• 4: 強制實施 Pod 安全標準
• 5: PKI 憑證與需求

1 - 大型叢集的考量事項

叢集是由一組執行 Kubernetes 代理程式的節點 （實體機器或虛擬機器）所組成，並由控制平面進行管理。 Kubernetes v1.35 支援最多 5,000 個節點的叢集。 更具體來說，Kubernetes 的設計可支援符合以下所有準則的配置：

• 每個節點不超過 110 個 Pod
• 不超過 5,000 個節點
• Pod 總數不超過 150,000
• 容器總數不超過 300,000

您可以透過新增或移除節點來調整叢集規模。具體作法取決於叢集的部署方式。

雲端供應商資源配額

為了避免碰到雲端供應商的配額問題，在建立多個節點的叢集時，建議考量：

• 申請提高雲端資源的配額，例如：
  • 運算執行個體
  • CPU
  • 儲存卷
  • 使用中的 IP 位址
  • 封包過濾規則
  • 負載平衡器的數量
  • 子網路
  • 日誌串流
• 控制叢集的擴展流程，分批啟動新節點，並在各批之間加入間隔， 因為部分雲端供應商會限制新執行個體的建立速率。

控制平面組件

對於大型叢集，您需要一個具備足夠運算及其他資源的控制平面。

通常您會在每個故障區執行一到兩個控制平面執行個體，並優先對這些執行個體進行垂直擴展； 直到垂直擴展達到邊際效益遞減的臨界點後，再進行水平擴展。

您應該在每個故障區執行至少一個執行個體來提供容錯能力。 Kubernetes 節點不會自動將流量導向位於相同故障區的控制平面端點；然而， 您的雲端供應商可能有其獨有的機制來做到這一點。

例如，使用託管的負載平衡器時， 您可以設定此負載平衡器將源於故障區 A 的 kubelet 與 Pod 流量僅導向同樣位於故障區 A 的控制平面主機。 如果故障區 A 內的單一控制平面主機或端點離線，這意味著 A 區節點的所有控制平面流量現在都將改為跨區傳輸。 在每個區域中執行多個控制平面主機可以降低發生這種情況的可能性。

etcd 儲存

為了提升大型叢集的效能，您可以將 Event 物件儲存於一個獨立且專屬的 etcd 執行個體中。

您可以使用自訂工具，在建立叢集時：

• 啟動並設定額外的 etcd 執行個體
• 設定 API 伺服器將 Event 儲存在該執行個體中

請參閱針對 Kubernetes 維運 etcd 叢集 與使用 kubeadm 架設高可用性 etcd 叢集， 以了解為大型叢集設定與管理 etcd 的詳細資訊。

附加元件資源

Kubernetes 資源限制有助於將記憶體洩漏， 以及 Pod 與容器對其他組件的影響降至最低。 這些資源限制同樣適用於附加元件的資源， 也適用於應用程式工作負載。

例如，您可以為日誌組件設定 CPU 與記憶體限制：

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

附加元件的預設限制，通常是基於在小型或中型 Kubernetes 叢集上執行各個附加元件的經驗所蒐集的資料。 當在大型叢集上執行時，某些資源的使用量可能會超過預設限制。若在部署大型叢集時未調整這些數值， 附加元件可能會因為不斷觸及記憶體限制而反覆被終止；或者，附加元件雖能維持執行， 但會受 CPU 時間切片限制影響而效能低落。

為了避免遇到叢集附加元件的資源問題，在建立包含多個節點的叢集時，建議考量以下事項：

• 部分附加元件採垂直擴展 — 整個叢集或每個故障區僅執行一個附加元件副本。 對於此類附加元件，當您擴展叢集規模時，請增加其資源請求與限制。
• 許多附加元件採水平擴展 — 透過增加 Pod 數量來提升容量；但在超大型叢集中，您可能仍需稍微提高 CPU 或記憶體限制。 Vertical Pod Autoscaler 可以以recommender 模式執行，以提供資源請求與限制的建議值。
• 部分附加元件以每個節點一個副本的方式執行，並由 DaemonSet 進行控制： 例如節點級別的日誌聚合器。與水平擴展的附加元件類似，您可能也需要稍微調高 CPU 或記憶體限制。

優先處理叢集關鍵組件

為了確保叢集的必要組件（例如 CoreDNS、metrics-server 與其他關鍵附加元件）優先於其他工作負載進行排程，且不會被較低優先權的 Pod 搶佔， 請使用系統的 PriorityClass 來設定這些組件的優先順序， 例如 system-cluster-critical 或 system-node-critical。

接下來

• VerticalPodAutoscaler 是一個您可以部署到叢集中的自訂資源，用來協助您管理 Pod 的資源請求與限制。 請參閱 Vertical Pod Autoscaler 以了解更多資訊， 並學習如何使用它來調整叢集組件的規模，包括叢集關鍵的附加元件。

• 請參閱節點自動擴展

• addon resizer 可協助您隨著叢集規模的變化， 自動調整附加元件的資源配置。

2 - 跨區域執行

本頁面說明如何跨多個區域執行 Kubernetes。

背景

Kubernetes 的設計使單一叢集能夠跨多個故障區（Failure Zone）執行； 這些故障區通常隸屬於一個稱為**「地區」（Region）的邏輯分組。主要的雲端供應商將地區定義為一組故障區，亦稱為可用區（Availability Zone）**， 並提供一致的功能：在同一個地區內，各故障區提供相同的 API 與服務。

典型的雲端架構旨在將單一故障區故障對其他故障區服務的影響降至最低。

控制平面行為

所有控制平面組件都支援以可互換資源池的方式執行， 並為各個組件建立多個副本

當您部署叢集控制平面時，需將控制平面組件的副本分散部署於多個故障區。 若高可用性是重要考量，應選擇至少三個故障區，並為各個控制平面組件（API 伺服器、排程器、etcd、叢集控制器管理器）建立多個副本，分散部署於這些故障區中。 若有使用雲端控制器管理器，也應將它複製到您所選擇的所有故障區中。

節點行為

Kubernetes 會自動將工作負載資源 （例如 Deployment 或 StatefulSet） 的 Pod 分散部署於叢集中的不同節點。這種分散部署有助於降低故障造成的影響。

當節點啟動時，每個節點上的 kubelet 會自動在 Kubernetes API 中代表此特定節點的 Node 物件加上標籤。 這些標籤可以包含區域資訊。

如果您的叢集跨越多個故障區或地區，您可以結合使用節點標籤與 Pod 拓撲散佈限制， 來控制 Pod 在叢集中的各個故障域（地區、故障區，甚至特定節點）之間的分佈方式。 這些提示可讓排程器將 Pod 排程到更有利於可用性的位置， 從而降低相關故障影響整個工作負載的風險。

例如，您可以設定一項限制：確保在可行的情況下，一個 StatefulSet 的 3 個副本分別執行於不同的故障區 您可以透過宣告式的方式來定義此限制，不需要為每個工作負載明確指定使用哪些可用區。

跨區域分散節點

Kubernetes 核心本身不會為您建立節點；您需要自行建立， 或使用像是 Cluster API 的工具來代為管理節點。

透過使用 Cluster API 等工具，您可以定義一組機器，將其分散在多個故障域中作為叢集的工作節點執行， 並定義規則，在發生整個區域的服務中斷時自動修復叢集。

手動為 Pod 指定區域

您可以套用節點選擇器限制到您建立的 Pod， 以及 Deployment、StatefulSet 或 Job 等工作負載資源中的 Pod 模板。

區域的儲存存取

當建立持久卷時，Kubernetes 會自動為連結至特定故障區的 PersistentVolume 加上區域標籤。 接著排程器會透過 NoVolumeZoneConflict 預選規則， 確保使用該 PersistentVolume 的 Pod 只會被排程到與該卷相同的故障區。

請注意到區域標籤的新增方式可能取決於您使用的雲端供應商與儲存佈建器。 請務必參考適用於您環境的特定文件，確保配置正確。

您可以為 PersistentVolumeClaims 指定一個StorageClass， 用來指定該類別中的儲存空間可以使用的故障域（區域）。 要了解配置能夠感知到故障域或區域的 StorageClass，請參閱允許的拓撲。

網路

Kubernetes 本身並不包含故障區感知的網路功能。 您可以使用網路外掛來配置叢集網路， 而選用的網路解決方案可能包含與特定故障區相關的設定。例如，如果您的雲端供應商支援 type=LoadBalancer 的 Service， 負載平衡器可能只會將流量傳送至與處理此連線的負載平衡器位於相同區域的 Pod。請查看您的雲端供應商文件以瞭解詳情。

對於自訂或本地端部署，類似的考量同樣適用。 Service 與 Ingress 的行為，包含對不同故障區的處理方式， 會根據您叢集的實際部署方式而有所不同。

故障復原

當您架設叢集時，還需要考慮：若某個地區內的所有故障區同時離線，您的架構是否能恢復服務，以及應如何恢復。 例如，是否仰賴某個故障區中至少有一個節點能夠執行 Pod？ 請確保任何叢集關鍵的修復工作，都不依賴叢集中至少有一個健康節點。例如：如果所有節點皆處於不健康狀態， 您可能需要執行一個帶有特殊 容許 的修復 Job， 使修復能順利完成，並讓至少一個節點恢復運作。

Kubernetes 並未提供此問題的解法；但在規劃時仍需納入考量。

接下來

若想了解排程器如何在叢集中依照設定的限制來排程 Pod， 請參閱排程與驅逐。

3 - 驗證節點架設

節點一致性測試

節點一致性測試是一個容器化的測試框架，為節點提供系統驗證與功能測試。 此測試會驗證節點是否符合 Kubernetes 的最低要求；通過測試的節點就有資格加入 Kubernetes 叢集。

節點先決條件

要執行節點一致性測試，節點必須滿足與標準 Kubernetes 節點相同的先決條件。 節點應至少安裝以下背景程式：

• 相容 CRI 的容器執行環境：例如 Docker、containerd 與 CRI-O
• kubelet

執行節點一致性測試

若要執行節點一致性測試，請執行以下步驟：

1. 確認 kubelet 的 --kubeconfig 選項的值；例如：--kubeconfig=/var/lib/kubelet/config.yaml。 由於測試框架會啟動一個本地控制平面來測試 kubelet，要使用 http://localhost:8080 作為 API 伺服器的網址。 此外，還有一些您可能需要使用的 kubelet 命令列參數：

   • --cloud-provider：如果您目前使用 --cloud-provider=gce，執行測試時應移除此命令列參數。

1. 使用以下指令執行節點一致性測試：

   # $CONFIG_DIR 是您 kubelet 的 Pod 設定檔路徑。
   # $LOG_DIR 是測試結果的輸出路徑。
   sudo docker run -it --rm --privileged --net=host \
     -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
     registry.k8s.io/node-test:0.2
   

執行其他架構的節點一致性測試

Kubernetes 也為其他架構提供了節點一致性測試的 Docker 映像檔：

執行選定的測試

要執行特定的測試，需使用您想執行的測試正規表達式來覆寫環境變數 FOCUS。

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Only run MirrorPod test
  registry.k8s.io/node-test:0.2

若要跳過特定測試，請使用您想跳過的測試正則表達式來覆寫環境變數 SKIP。

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test
  registry.k8s.io/node-test:0.2

節點一致性測試是 node e2e test 的容器化版本。 在預設情況下，它會執行所有的一致性測試。

理論上，只要您正確配置容器並掛載必要的卷，您就能執行任何節點端對端測試。 但強烈建議僅執行一致性測試，因為執行非一致性測試所需的配置要複雜得多。

注意事項

• 測試會在節點上留下一些 Docker 映像檔，包括節點一致性測試的映像檔，以及功能測試中所使用的容器映像檔。
• 測試會在節點上留下已停止的容器。這些容器是在功能測試期間所建立的。

4 - 強制實施 Pod 安全標準

本頁面提供關於強制實施 Pod 安全標準 的最佳實務概述。

使用內建的 Pod 安全存取控制器

Pod 安全存取控制器 旨在取代已棄用的 PodSecurityPolicies。

配置所有叢集命名空間

完全沒有任何配置的命名空間，應被視為叢集安全模型中的重大漏洞。 我們建議花時間分析每個命名空間中執行的工作負載類型， 並參考 Pod 安全標準為其中每一個決定合適的層級。未被標籤的命名空間應僅代表它尚未被評估。

在所有命名空間中的所有工作負載都具有相同安全需求的情境下， 我們提供了一個範例， 說明如何批量套用 PodSecurity 標籤。

採用最小權限原則

在理想的情況下，每個命名空間中的每個 Pod 都應符合 restricted 政策的要求。 然而，這既不可能也不切實際，因為某些工作負載基於合理的理由仍需要提升權限。

• 允許 privileged 工作負載的命名空間，應建立並強制實施適當的存取控制。
• 對於在這些權限較為寬鬆的命名空間中執行的工作負載，應維護關於其獨特安全需求的文件。 若情況允許，應考量該如何進一步限制這些需求。

採用多重模式策略

Pod 安全標準存取控制器的 audit 與 warn 模式，讓您能輕鬆收集關於 Pod 的重要安全深入分析， 且不會中斷現有的工作負載。

為所有命名空間啟用這些模式是一項良好的做法，將其設定為最終會切換成 enforce 模式的目標層級與版本。 在這個階段產生的警告與審計註解，可以指引您達成此目標狀態。 若您預期工作負載的作者會配合修改以符合目標層級，請啟用 warn 模式。 若您預期透過審計日誌來監控或推動變更以符合目標層級，請啟用 audit 模式。

當您已將 enforce 模式設定至目標層級時，這些模式在以下幾個方面仍能發揮作用：

• 透過將 warn 設定為與 enforce 相同的層級， 當使用者嘗試建立未通過驗證的 Pod（或有 Pod 樣板的資源）時，將會收到警告。 這能協助他們更新這些資源以符合規範。
• 在 enforce 固定於特定非最新版本的命名空間中， 若將 audit 與 warn 模式設定為與 enforce 相同的層級，但版本設為 latest， 可讓您發現那些雖然在舊版本中被允許、但根據目前最佳實務已不再被允許的設定。

第三方替代方案

Kubernetes 生態系中也在開發其他用於強制實施安全設定檔的替代方案：

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

選擇使用內建方案（例如 Pod 安全存取控制器）還是第三方工具，完全視您的實際情況而定。 在評估任何方案時，對供應鏈的信任至關重要。 總之，採用上述任何一種做法，都比完全不做來得更好。

5 - PKI 憑證與需求

Kubernetes 需要 PKI 憑證來透過 TLS 進行驗證。 如果您使用 kubeadm 安裝 Kubernetes， 叢集所需的憑證會自動產生。您也可以自行產生憑證 —— 例如，為了提升私鑰安全性而不將它儲存在 API 伺服器上。 本頁面說明了您的叢集所需的各類憑證。

憑證在您的叢集中的使用方式

Kubernetes 在進行下列操作時，需要使用 PKI：

伺服器憑證

• API 伺服器端點的伺服器憑證
• etcd 伺服器的伺服器憑證
• 每個 kubelet 的伺服器憑證 （每個節點都執行一個 kubelet）
• 前端代理的可選用伺服器憑證

用戶端憑證

• 每個 kubelet 的用戶端憑證，用於作為 Kubernetes API 的用戶端向 API 伺服器進行驗證
• 每個 API 伺服器的用戶端憑證，用於向 etcd 進行驗證
• 控制器管理器的用戶端憑證，用於與 API 伺服器進行安全通訊
• 排程器的用戶端憑證，用於與 API 伺服器進行安全通訊
• 每個節點各一個用戶端憑證，讓 kube-proxy 向 API 伺服器進行驗證
• 叢集管理員使用的可選用用戶端憑證，用於向 API 伺服器進行驗證
• 前端代理的可選用用戶端憑證

Kubelet 的伺服器與用戶端憑證

為了建立安全連線並向 kubelet 驗證其身分，API 伺服器需要一組用戶端憑證與金鑰對。

在此情境下，憑證的使用有兩種做法：

• 共用憑證：kube-apiserver 可以使用與其驗證用戶端時相同的憑證與金鑰對。 這意味著現有的憑證，例如 apiserver.crt 與 apiserver.key 可被用於與 kubelet 伺服器通訊。

• 獨立憑證：另一種做法是，kube-apiserver 可以產生一組新的用戶端憑證與金鑰對， 用於驗證其與 kubelet 伺服器之間的通訊。在此情況下， 會建立名為 kubelet-client.crt 的專屬憑證及其對應的私鑰 kubelet-client.key。

etcd 也實作了雙向 TLS 來驗證用戶端與對等節點。

憑證的儲存位置

如果您使用 kubeadm 安裝 Kubernetes，大部分的憑證都會儲存在 /etc/kubernetes/pki。 本文件中的所有路徑皆相對於此目錄，除了 kubeadm 放在 /etc/kubernetes 中的使用者帳號憑證之外。

手動配置憑證

如果您不希望由 kubeadm 產生所需的憑證，您可以使用單一根憑證授權機構（Root CA）來建立憑證，或是提供完整的所有憑證。 關於建立自有憑證授權機構的詳細資訊，請參閱憑證。 若要深入了解如何管理憑證，請參閱使用 kubeadm 管理憑證。

單一的根 CA

您可以建立一個由管理員控管的單一根 CA。此根 CA 可再建立多個中間 CA， 並將後續所有的憑證建立工作委派給 Kubernetes 本身。

所需的 CA 如下：

除了上述的 CA 之外，還需要一組用於服務帳號（Service Account）管理的公鑰/私鑰對， 即 sa.key 與 sa.pub。以下範例展示了前表中所列的 CA 金鑰及憑證檔案：

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

所有憑證

如果您不希望將 CA 私鑰複製到您的叢集中，您可以自行產生所有的憑證。

所需的憑證如下：

其中 kind 對應到一或多個 x509 金鑰用途（key usage）， 這在 CertificateSigningRequest 類型的 .spec.usages 欄位中也有詳細說明：

憑證路徑

憑證應放置在建議的路徑中（就像 kubeadm 所用的）。 不論實際位置為何，都應透過指定參數來明確指出路徑。

同樣的考量也適用於服務帳號的金鑰對：

以下範例說明了來自先前表格的檔案路徑， 如果您是自行產生所有的金鑰與憑證，則需要提供這些檔案：

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

配置使用者帳號的憑證

您必須手動配置這些管理員帳號與服務帳號：

1. 對於每項配置，產生一個具有給定通用名稱（CN）與組織（O）的 x509 憑證/金鑰對。

2. 為每項配置按照以下方式執行 kubectl：

   KUBECONFIG=<檔案名稱> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <Kubernetes CA 路徑> --embed-certs
   KUBECONFIG=<檔案名稱> kubectl config set-credentials <憑證名稱> --client-key <金鑰路徑>.pem --client-certificate <憑證路徑>.pem --embed-certs
   KUBECONFIG=<檔案名稱> kubectl config set-context default-system --cluster default-cluster --user <憑證名稱>
   KUBECONFIG=<檔案名稱> kubectl config use-context default-system
   

這些檔案按照以下方式使用：

以下檔案說明了前述表格中所列檔案的完整路徑：

/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf