Skip to main content

第 1 章：生產環境規劃和準備

安裝 Kubernetes 生產環境​

  • kubeadm
  • kops
    • 自動化群集配置工具
  • kubespray
    • 提供 Ansible Playbook、清單、 配置工具和通用 OS/Kubernetes 叢集組態管理任務

生產環境考量​

  • 可用性：一個單機的 Kubernetes 具有單點失效特性。 建立高可用的叢集需要考慮
    • 將 master node 與 worker node 分開
    • 在多個節點上提供 Control plane 組件的副本
    • 為針對叢集的 API 伺服器 的流量提供負載平衡
    • 隨著負載的合理需要，提供足夠的可用的（或能夠迅速變為可用的）工作節點
  • 規模：如果預期生產用 Kubernetes 環境要承受固定量的請求， 可以針對所需的容量來一次完成安裝。 不過，如果預期服務請求會隨著時間增長，需要規劃如何處理請求上升時對 Control plane 和工作節點的壓力，或者如何縮減集群規模以減少未使用資源的消耗
  • 安全性與存取管理：在你自己的學習環境 Kubernetes 叢集上，你擁有完全的管理員特權。 但對運行著重要工作負載的共享集群，用戶帳戶不只一兩個時， 就需要更細粒度的方案來確定或哪些主體可以存取集群資源。 你可以使用基於角色的存取控制（RBAC） 和其他安全機制來確保使用者和負載能夠存取所需的資源， 同時確保工作負載及叢集本身仍然是安全的。 你可以透過管理策略和容器資源來針對使用者和工作負載所可存取的資源設定約束

在自行建置 Kubernetes 生產環境之前， 請考慮將此任務的部分或全部交給雲端方案承包服務提供者或其他 Kubernetes 合作夥伴。 選項有：

  • 無伺服器服務：僅在第三方設備上運行負載，完全不必管理叢集本身。 你需要為 CPU 用量、記憶體和磁碟請求等付費。
  • 託管 Control plane：決定叢集 Control plane 的規模和可用性，並負責打補丁和升級等操作
  • 託管 Control plane ：配置一個節點池來滿足你的需要，由供應商確保節點始終可用，並在需要的時候完成升級
  • 集成：有一些供應商能夠將 Kubernetes 與一些你可能需要的其他服務集成， 這類服務包括存儲、容器鏡像倉庫、身份認證方法以及開發工具等

生產用 Control plane​

最簡單的 Kubernetes 叢集中，整個 Control plane 和工作節點服務都運行在同一台機器上。 你可以透過加入工作節點來提升環境運算能力，如 Kubernetes 元件示意圖所示。 如果只需要叢集在很短的一段時間內可用，或者可以在某些事物出現嚴重問題時直接丟棄， 這種配置可能符合你的需要。

如果你需要一個更持久的、高可用的集群，那麼就需要考慮擴展 Control plane 的方式。 根據設計，運行在一台機器上的單機 Control plane 服務不是高可用的。

  • 選擇部署工具：使用類似 kubeadm、kops 和 kubespray 這類工具來部署 Control plane
  • 管理憑證：Control plane 服務之間的安全通訊是透過憑證來完成的。 憑證是在部署期間自動產生的
  • 為 API 伺服器設定負載平衡：設定負載平衡器來將外部的 API 請求散佈給執行在不同節點上的 API 服務實例
  • 分離並備份 etcd 服務：etcd 服務可以運行於其他 Control plane 服務所在的機器上， 也可以運行在不同的機器上以獲得更好的安全性和可用性。 因為 etcd 儲存著叢集的配置數據
  • 建立多 Control plane 系統：為了實現高可用性，Control plane不應被限制在一台機器上。 如果Control plane 服務是使用某 init 服務（例如 systemd）來運作的，則每個服務應該至少運作在三台機器上。 不過，將 Control plane 作為服務運行在 Kubernetes Pod 中可以確保你所要求的數量的服務始終保持可用
  • 跨多個可用區：如果保持你的叢集一直可用這一點非常重要，可以考慮建立一個跨多個資料中心的叢集； 在雲端環境中，這些資料中心被視為可用區。 若干個可用區在一起可構成地理區域。
  • 管理演進中的特性：如果你打算長時間保留你的集群，就需要執行一些維護其健康和安全的任務。 例如，如果你採用 kubeadm 安裝的集群， 則有一些可以幫助你完成 憑證管理 和升級 kubeadm 集群 的指令

生產用工作節點​

生產品質的工作負載需要是彈性的；它們所依賴的其他元件（例如 CoreDNS）也需要是彈性的。 無論你是自行管理 Control plane 還是讓雲端供應商來管理，你都需要考慮如何管理工作節點 （有時也簡稱為節點）。

  • 配置節點：節點可以是實體機器或虛擬機器。 如果你希望自行建立和管理節點， 你可以安裝一個受支援的作業系統，之後新增並執行適當的節點服務。 考慮：安裝節點時要透過配置適當的記憶體、CPU 和磁碟讀寫速率、儲存容量來滿足你的負載的需求。
  • 驗證節點：參閱驗證節點配置以了解如何確保節點滿足加入 Kubernetes 叢集的需求。 將節點新增至集群：如果你自行管理你的集群，你可以透過安裝配置你的機器， 之後或手動加入集群，或者讓它們自動註冊到集群的API 伺服器。 請參閱節點節，了解如何設定 Kubernetes 以便以這些方式來新增節點
  • 擴充節點：制定一個擴充叢集容量的規劃，你的叢集最終會需要這項能力。 請參閱大規模叢集考察事項 以確定你所需的節點數； 這一規模是基於你要執行的 Pod 和容器個數來決定的。 如果你自行管理叢集節點，這可能意味著要購買和安裝你自己的實體設備
  • 節點自動擴縮容：大多數雲端供應商支援 叢集自動擴縮器（Cluster Autoscaler） 以便取代不健康的節點、根據需求來增加或縮減節點個數。 請參閱常見問題 了解自動擴縮器的工作方式，並參閱 Deployment 以了解不同雲端供應商是如何實作叢集自動擴縮器的。 對於本地集群，有一些虛擬化平台可以透過腳本來控制按需啟動新節點。
  • 安裝節點健康檢查：對於重要的工作負載，你會希望確保節點以及在節點上運行的 Pod 處於健康狀態。 透過使用 Node Problem Detector， 你可以確保你的節點是健康的。

生產級使用者環境​

在生產環境中，情況可能不再是你或一群人在訪問集群，而是幾十上百人需要訪問集群。 在學習環境或平台原型環境中，你可能有一個可以執行任何操作的管理帳號。 在生產環境中，你會需要對不同名字空間具有不同存取權限等級的許多帳號。

建立一個生產層級的叢集意味著你需要決定如何選擇性地允許其他使用者存取叢集。 具體而言，你需要選擇驗證嘗試存取叢集的人的身份識別（身份認證）， 並確定他們是否被許可執行他們所請求的操作（識別）：

  • 認證（Authentication）：API 伺服器可以使用用戶端憑證、持有者令牌、 身分認證代理程式或 HTTP 基本認證機制來完成身分認證作業。 你可以選擇你要使用的認證方法。 透過使用插件， API 伺服器可以充分利用你所在組織的現有身分認證方法， 例如 LDAP 或 Kerberos
  • 鑑權（Authorization）：當你準備為一般使用者執行權限判定時， 你可能會需要在 RBAC 和 ABAC 鑑權機制之間做出選擇。 請參閱鑑權概述， 了解對使用者帳戶（以及存取您的叢集的服務帳戶）執行鑑權的不同模式
  • 基於角色的存取控制（RBAC）： 讓你透過為通過身分認證的使用者授權特定的授權集合來控制叢集存取。 存取許可可以針對某特定名字空間（Role）或針對整個叢集（ClusterRole）。 透過使用 RoleBinding 和 ClusterRoleBinding 對象，這些存取許可可以被關聯到特定的使用者身上。 基於屬性的存取控制（ABAC）： 讓你能夠基於叢集中資源的屬性來建立存取控制策略，基於對應的屬性來決定允許或拒絕存取。 策略檔案的每一行都會給出版本屬性（apiVersion 和 kind）以及一個規約屬性的映射， 用來匹配主體（使用者或群組）、資源屬性、非資源屬性（/version 或 /apis）和唯讀屬性。 請參閱範例以了解細節。 身為在你的生產用 Kubernetes 叢集中安裝身分認證和鑑權機制的負責人，要考慮的事情如下：
    • 設定鑑權模式：當 Kubernetes API 伺服器（kube-apiserver）啟動時， 所支援的鑑權模式必須使用 --authorization-mode 標誌配置。 例如，kube-apiserver.yaml（位於 /etc/kubernetes/manifests 下）對應的標誌可以設定為 Node,RBAC。 這樣就會針對已完成身分認證的請求執行 Node 和 RBAC 鑑權。
    • 建立使用者憑證和角色綁定（RBAC）：如果你在使用 RBAC 鑑權，使用者可以建立由叢集 CA 簽署的 CertificateSigningRequest（CSR）。 接下來你就可以將 Role 和 ClusterRole 綁定到每個使用者身上。 請參閱憑證簽署要求了解細節。
    • 建立組合屬性的策略（ABAC）：如果你在使用ABAC 鑑權， 你可以設定屬性組合以建構策略對所選使用者或使用者群組執行鑑權， 判定他們是否可存取特定的資源（例如Pod）、名字 空間或者apiGroup。 進一步的詳細資訊可參閱範例。
    • 考慮準入控制器：針對指向 API 伺服器的請求的其他鑑權形式還包括 Webhook 令牌認證。 Webhook 和其他特殊的鑑權類型需要透過向 API 伺服器新增准入控制器來啟用。

為負載資源設定約束​

生產環境負載的需求可能對 Kubernetes 的 Control plane 內外造成壓力。 在針對你的叢集的負載執行配置時，請考慮以下條目：

  • 設定 Namespace 限制：為每個 Namespace 的記憶體和 CPU 設定配額。
  • 為 DNS 請求做準備：如果希望工作負載能夠完成大規模擴展，DNS 服務也必須能夠擴大規模
  • 建立額外的服務帳戶：使用者帳戶決定使用者可以在叢集上執行的操作，服務帳號則定義的是在特定 Namespace 中 Pod 的存取權限

大規模集群的注意事項​

叢集是運行 Kubernetes 代理程式的、 由 Control plane 管理的一組節點（實體機或虛擬機器）

Kubernetes 限制​

  • 每個節點的 Pod 數量不超過 110
  • 節點數不超過 5,000
  • Pod 總數不超過 150,000
  • 容器總數不超過 30 萬

你可以透過新增或刪除節點來擴展叢集。 集群擴縮的方式取決於集群的部署方式。

雲端供應商資源配額​

為避免遇到雲端供應商配額問題，在建立具有大規模節點的叢集時，請考慮以下事項：

  • 請求增加雲端資源的配額，例如：
  • 計算實例
  • CPU
  • 儲存磁碟區
  • 使用中的 IP 位址
  • 封包過濾規則集
  • 負載平衡數量
  • 網路子網路
  • 日誌流

由於某些雲端供應商限制了建立新執行個體的速度，因此透過分批啟動新節點來控制叢集擴展操作，並在各批次之間有一個暫停

Control plane​

對於大型集群，你需要一個具有足夠運算能力和其他資源的控制平面。

通常，你將在每個故障區域運行一個或兩個控制平面實例， 先垂直縮放這些實例，然後在到達下降點（垂直）後再水平縮放。

你應該在每個故障區域至少應運行一個實例，以提供容錯能力。 Kubernetes 節點不會自動將流量引向相同故障區域的控制平面端點。 但是，你的雲端供應商可能有自己的機制來執行此操作。

例如，使用託管的負載平衡器時，你可以設定負載平衡器發送源自故障區域 A 中的 kubelet 和 Pod 的流量， 並將該流量僅定向到也位於區域 A 中的控制平面主機。 如果單一控制平面主機或端點故障區域 A 離線，則表示區域 A 中的節點的所有控制平面流量現在都在區域之間傳送。 在每個區域中執行多個控制平面主機能降低這種結果的可能性。

etcd 存儲​

為了提高大規模叢集的效能，你可以將事件物件儲存在單獨的專用 etcd 實例中。

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

  • 啟動並配置額外的 etcd 實例
  • 配置 API 伺服器，將它用於儲存事件

插件資源​

Kubernetes 資源限制 有助於最大程度地減少記憶體洩漏的影響以及 Pod 和容器可能對其他元件的其他方式的影響。 這些資源限制適用於插件資源， 就像它們適用於應用程式工作負載一樣。

例如，你可以對日誌元件設定 CPU 和記憶體限制：

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

插件的預設限制通常基於從中小規模 Kubernetes 叢集上運行每個插件的經驗收集的資料。 當插件在大規模叢集上運行時，某些資源消耗常常比其預設限制更多。 如果在不調整這些值的情況下部署了大規模集群，則插件可能會不斷被殺死，因為它們不斷達到記憶體限制。 或者，插件可能會運行，但由於 CPU 時間片的限製而導致效能不佳。

為避免遇到叢集插件資源問題，在建立大規模叢集時，請考慮以下事項：

  • 部分垂直擴充插件：總有一個插件副本服務於整個叢集或服務整個故障區域。 對於這些附加元件，請在擴大叢集時加大資源請求和資源限制。 許多水平擴充插件 ：你可以透過運行更多的 Pod 來增加容量——但是在大規模叢集下， 可能還需要稍微提高 CPU 或記憶體限制。 VerticalPodAutoscaler 可以在 recommender 模式下運行， 以提供有關請求和限制的建議數字。 一些插件在每個節點上運行一個副本，並由 DaemonSet 控制： 例如，節點級日誌聚合器。 與水平擴充插件的情況類似， 你可能還需要稍微提高 CPU 或記憶體限制。 VerticalPodAutoscaler：是一種自訂資源，你可以將其部署到叢集中，幫助你管理 Pod 的資源請求和資源限制。 了解有關 Vertical Pod Autoscaler 的更多信息，了解如何用它擴展集群組件（包括對集群至關重要的插件）的信息。
  • 叢集自動擴縮器：與許多雲端供應商整合在一起，幫助你在你的叢集中，按照資源需求等級運行正確數量的節點。
  • addon resizer：可協助你在叢集規模變更時自動調整插件的大小。