這是本節的多頁可打印視圖。 點擊此處打印.

返回此頁面的常規視圖.

正式環境

建立正式環境等級的 Kubernetes 叢集

建立正式環境等級的 Kubernetes 叢集需要事先規劃與準備。 若您的 Kubernetes 叢集需要執行關鍵工作負載，則必須經過適當設定，以具備彈性。 本頁說明如何建立正式環境等級的 Kubernetes 叢集，或將現有叢集調整為可用於正式環境。 若您已熟悉正式環境的設定並只需要相關連結，請直接跳至接下來。

正式環境考量

通常，正式環境中的 Kubernetes 叢集，相較於個人學習、開發或測試環境，會有更多需求。 正式環境可能需要支援多位使用者安全存取、維持穩定的可用性，以及具備因應需求變化的資源。

在決定正式 Kubernetes 環境的部署位置（本地部署或雲端），以及您希望自行管理或交由他人管理的程度時， 請考慮以下因素如何影響您對 Kubernetes 叢集的需求：

  • 可用性：單一機器的 Kubernetes 學習環境 存在單點故障的問題。建立高可用叢集時需要考慮：
    • 將控制平面與工作節點分開部署。
    • 在多個節點上部署控制平面組件的副本
    • 對叢集的 API 伺服器 流量進行負載平衡。
    • 確保有足夠的工作節點可用，或能在工作負載需求變化時快速擴充。
  • 規模：若您預期正式 Kubernetes 環境的需求量維持穩定，或許可以一次性完成所需的容量規劃。 但若您預期需求會隨時間成長，或因季節性或特殊活動等因素而大幅波動， 則需要規劃如何進行擴展，以因應控制平面與工作節點因請求增加所帶來的壓力，或縮減規模以減少閒置資源。
  • 安全性與存取管理：在自己的 Kubernetes 學習叢集上，您擁有完整的管理員權限。 但對於承載重要工作負載且有多位使用者的共用叢集，則需要更精細的機制來控管哪些使用者或程序可以存取叢集資源。 您可以使用角色型存取控制（RBAC）及其他安全機制， 確保使用者與工作負載能夠取得所需的資源，同時維持工作負載及叢集本身的安全性。 您可以透過管理政策及 容器資源， 來限制使用者與工作負載可存取的資源。

在自行建立 Kubernetes 正式環境之前，請考慮將部分或全部工作交由雲端整合解決方案提供商 或其他 Kubernetes 合作夥伴處理。可選的方案包括：

  • 無伺服器：直接在第三方提供的基礎設施上執行工作負載，無需管理叢集。 費用依 CPU 使用量、記憶體及磁碟請求等計算。
  • 受管理的控制平面：由提供商負責管理叢集控制平面的規模與可用性，並處理修補程式和升級作業。
  • 受管理的工作節點：設定節點池以符合您的需求，提供商確保節點保持可用， 並在需要時能夠執行升級。
  • 整合：部分提供商可將 Kubernetes 與其他所需服務整合， 例如儲存、映像檔儲存庫、身分驗證機制和開發工具。

無論您是自行建立正式 Kubernetes 叢集，或與合作夥伴合作， 請參閱以下章節，以評估與叢集的控制平面、工作節點、使用者存取 及工作負載資源相關的需求。

正式叢集設定

在正式環境等級的 Kubernetes 叢集中，控制平面透過可分散部署於多台電腦上的服務來管理叢集。 每個工作節點則代表一個設定為執行 Kubernetes Pod 的獨立實體。

正式環境控制平面

最簡單的 Kubernetes 叢集是將完整的控制平面和工作節點服務都執行在同一台機器上。 您可以透過新增工作節點來擴展該環境，如 Kubernetes 組件中的示意圖所示。 若叢集僅需在短時間內可用，或在出現嚴重問題時可以直接捨棄，這樣的設定可能已足以滿足您的需求。

但若您需要更持久、高可用的叢集，則應考慮擴展控制平面的方式。 根據設計，執行在單台機器上的控制平面服務並非高可用的。 若維持叢集持續運作、確保出問題時能夠修復對您而言很重要，請考慮以下步驟：

  • 選擇部署工具：您可以使用 kubeadm、kops 和 kubespray 等工具來部署控制平面。 請參閱使用部署工具安裝 Kubernetes， 了解如何使用各種部署方法建立正式環境等級的叢集。 您的部署也可以搭配不同的容器執行階段。
  • 管理憑證：控制平面服務之間的安全通訊是透過憑證來實現的。 憑證會在部署期間自動產生，或您也可以使用自己的憑證授權機構來產生。 詳情請參閱 PKI 憑證與需求。
  • 為 API 伺服器設定負載平衡器：設定負載平衡器， 將外部 API 請求分散至執行於不同節點上的 apiserver 服務實例。 詳情請參閱建立外部負載平衡器。
  • 分離並備份 etcd 服務：etcd 服務可以與其他控制平面服務部署於相同的機器上， 也可以部署於獨立的機器上，以提升安全性與可用性。 由於 etcd 儲存叢集的設定資料，應定期備份 etcd 資料庫，以確保在需要時能夠進行修復。 關於設定與使用 etcd 的詳情，請參閱 etcd FAQ。 更多細節請參閱為 Kubernetes 操作 etcd 叢集 及使用 kubeadm 建立高可用 etcd 叢集。
  • 建立多個控制平面系統：為了實現高可用性，控制平面不應受限於單一機器。 若控制平面服務由 init 服務（例如 systemd）執行，每個服務至少應在三台機器上執行。 不過，將控制平面服務以 Pod 的方式在 Kubernetes 中執行， 可以確保所需的服務副本數量始終可用。 排程器應具備容錯能力，但不需要具備高可用性。 某些部署工具會使用 Raft 共識演算法進行 Kubernetes 服務的領導者選舉。 若主要服務失效，其他服務會自行選舉並接管。
  • 跨多個可用區部署：若確保叢集隨時可用至關重要， 請考慮建立跨多個資料中心的叢集（在雲端環境中稱為可用區）。 多個可用區的集合稱為區域。 將叢集分散至同一區域的多個可用區，可以提高在某個可用區發生故障時叢集仍能持續運作的可能性。 詳情請參閱在多個可用區中執行。
  • 持續維護叢集：若您計劃長期維護叢集，需要執行一些工作來維持其健康與安全。 例如，若您使用 kubeadm 安裝，有相關指示可協助您完成 憑證管理 及升級 kubeadm 叢集。 如需更完整的 Kubernetes 管理任務清單，請參閱管理叢集。

如需了解執行控制平面服務時的可用選項，請參閱 kube-apiserver、 kube-controller-manager 及 kube-scheduler 組件參考頁面。 如需高可用控制平面的範例，請參閱 高可用拓撲選項、 使用 kubeadm 建立高可用叢集 及為 Kubernetes 操作 etcd 叢集。 關於 etcd 備份計畫，請參閱 備份 etcd 叢集。

正式工作節點

正式環境等級的工作負載需要具備彈性，其所依賴的組件（例如 CoreDNS）也需要具備彈性。 無論您是自行管理控制平面，或由雲端提供者代為管理， 都需要考慮如何管理工作節點（有時也簡稱為節點）。

  • 設定節點：節點可以是實體機或虛擬機。若您想自行建立並管理節點， 可以安裝受支援的作業系統，然後部署並執行適當的節點服務。請考慮：
    • 在設定節點時，提供符合工作負載需求的記憶體、CPU 及磁碟速度與儲存容量。
    • 通用電腦系統是否足夠，或您的工作負載是否需要 GPU 處理器、Windows 節點或 VM 隔離。
  • 驗證節點：請參閱有效的節點設定， 了解如何確保節點符合加入 Kubernetes 叢集的需求。
  • 將節點加入叢集：若您自行管理叢集，可以透過設定機器並手動加入， 或讓機器自動向叢集的 apiserver 註冊來新增節點。 請參閱節點章節， 了解如何設定 Kubernetes 以這些方式新增節點。
  • 擴縮節點：制定擴充叢集容量的計畫，因為叢集最終會需要這項能力。 請參閱大規模叢集的注意事項， 依據需要執行的 Pod 與容器數量來確定所需的節點數量。 若您自行管理節點，這可能意味著需要購買並部署自己的實體設備。
  • 自動擴縮節點：請閱讀節點自動擴縮， 了解可自動管理節點及其提供之容量的工具。
  • 設定節點健康狀態檢查：對於重要的工作負載，您需要確保節點以及在其上執行的 Pod 都處於健康狀態。 透過使用 Node Problem Detector 常駐程式， 您可以確保節點維持健康。

正式環境使用者管理

在正式環境中，您的使用情境可能會從僅有您或一小組人員存取叢集， 演變為可能有數十甚至數百人需要存取叢集。 在學習環境或平台原型中，您可能僅使用一個管理帳號處理所有操作。 在正式環境中，則通常需要建立多個帳號，並針對不同命名空間設定不同層級的存取權限。

建立正式環境等級的叢集意味著需要決定如何控管其他使用者的存取權限。 具體而言，您需要選擇驗證嘗試存取叢集之使用者身分（身分驗證）， 以及判斷其是否具有執行所請求操作之權限（授權）的策略：

  • 身分驗證（Authentication）：apiserver 可以使用用戶端憑證、Bearer Token、 身分驗證代理或 HTTP 基本驗證來對使用者進行身分驗證。 您可以選擇要使用的身分驗證方法。 透過外掛程式，apiserver 可以使用您組織現有的身分驗證機制，例如 LDAP 或 Kerberos。 關於驗證 Kubernetes 使用者身分的各種方法， 請參閱身分驗證。

  • 授權（Authorization）：為一般使用者設定授權時，您可能需要在 RBAC 與 ABAC 之間做選擇。 請參閱授權概述， 了解授權使用者帳號（以及服務帳號存取叢集）的不同模式：

    • 角色型存取控制（RBAC）： 透過向已通過身分驗證的使用者授予特定的權限集合，以控制叢集的存取。 權限可以針對特定命名空間（Role）或整個叢集（ClusterRole）進行設定。 接著使用 RoleBinding 與 ClusterRoleBinding，可以將這些權限繫結至特定使用者。
    • 基於屬性的存取控制（ABAC）： 讓您能根據叢集中資源的屬性建立政策，並依據這些屬性決定允許或拒絕存取。 政策檔案的每一行都包含版本屬性（apiVersion 與 kind）以及 spec 屬性的對應， 用於比對主體（使用者或群組）、資源屬性、非資源屬性（/version 或 /apis）及唯讀屬性。 詳情請參閱範例。

作為在正式環境 Kubernetes 叢集上設定身分驗證與授權的負責人，以下是一些需要考慮的事項：

  • 設定授權模式：當 Kubernetes API 伺服器 （kube-apiserver）啟動時， 必須透過 --authorization-config 檔案或 --authorization-mode 旗標來設定受支援的授權模式。 例如，在 kube-adminserver.yaml 檔案（位於 /etc/kubernetes/manifests）中， 可將該旗標設定為 Node,RBAC，以對已通過身分驗證的請求啟用 Node 與 RBAC 授權。
  • 建立使用者憑證與角色繫結（RBAC）：若您使用 RBAC 授權， 使用者可以建立 CertificateSigningRequest（CSR），由叢集 CA 進行簽署。 接著可以將 Role 與 ClusterRole 繫結至各個使用者。 詳情請參閱憑證簽署請求。
  • 建立結合屬性的政策（ABAC）：若您使用 ABAC 授權， 可以指定屬性組合來形成政策，授權特定使用者或群組存取特定資源（例如 Pod）、 命名空間或 apiGroup。詳情請參閱範例。
  • 考慮准入控制器：針對透過 API 伺服器傳入的請求，還有其他形式的授權機制， 例如 Webhook 令牌身分驗證。 Webhook 與其他特殊授權類型需要透過在 API 伺服器中啟用 准入控制器來支援。

設定工作負載資源限制

正式環境中的工作負載可能會對 Kubernetes 控制平面內外造成壓力。 在為叢集的工作負載進行設定時，請考慮以下項目：

  • 建立額外的服務帳號：使用者帳號決定使用者在叢集上可以執行的操作， 而服務帳號則定義特定命名空間中 Pod 的存取權限。 預設情況下，Pod 會使用其命名空間中的預設服務帳號。 關於建立新服務帳號的資訊，請參閱管理服務帳號。 例如，您可能需要：

接下來