這是本節的多頁可打印視圖。
點擊此處打印.
返回此頁面的常規視圖.
快速入門
本節介紹設定與執行 Kubernetes 的各種方式。
安裝 Kubernetes 時，應依據維護難易度、安全性、控制程度、可用資源，以及操作與管理叢集所需的專業能力，選擇適合的安裝方式。
你可以下載 Kubernetes，並將 Kubernetes 叢集部署於本機、雲端，或自有資料中心。
部分 Kubernetes 組件，例如 kube-apiserver 或 kube-proxy，也可以在叢集中以容器映像檔的形式部署。
建議在可行的情況下，將 Kubernetes 組件以容器映像檔的形式執行，並交由 Kubernetes 管理這些組件。
負責執行容器的組件（例如 kubelet）則不適用於此類方式。
若不希望自行管理 Kubernetes 叢集，可以選擇受管服務（managed service），包括經認證的平台。
此外，在各種雲端與裸機環境中，也有多種標準化或客製化的解決方案可供選擇。
學習環境
如果您正在學習 Kubernetes，請使用 Kubernetes 社群支援的工具，
或生態系中的工具，在本機電腦上建立 Kubernetes 叢集。
請參閱學習環境。
正式環境
在評估正式環境的解決方案時，
請考慮在操作 Kubernetes 叢集（或相關抽象）時，哪些部分要自行管理，哪些部分交由提供者處理。
對於自行管理的叢集，官方支援用於部署 Kubernetes 的工具是
kubeadm。
接下來
Kubernetes 的設計是讓其控制平面在 Linux 上運作。
在叢集中，您可以在 Linux 或其他作業系統（包括 Windows）上執行應用程式。
1 - 學習環境
如果您正在學習 Kubernetes，您需要一個練習的環境。本頁面將介紹建立 Kubernetes 環境的各種方式，讓您可以進行實驗與學習。
安裝 kubectl
在建立叢集之前，您需要 kubectl 命令列工具。此工具能讓您與 Kubernetes 叢集通訊，並執行指令。
有關安裝說明，請參閱安裝並設定 kubectl。
設定本機 Kubernetes 環境
在本機執行 Kubernetes 能提供您一個安全的學習與實驗環境。您可以隨時建立與移除叢集，而無需擔心成本或影響正式環境。
kind
kind (Kubernetes IN Docker) 使用 Docker 容器作為節點來執行 Kubernetes 叢集。它的設計輕量，專為測試 Kubernetes 本身而打造，也很適合用於學習。
若要開始使用 kind，請參閱 kind 快速入門。
minikube
minikube 可在本機執行單一節點的 Kubernetes 叢集，支援多種容器執行階段，並可在 Linux、macOS 與 Windows 上運作。
若要開始使用 minikube，請參閱 minikube 入門指南。
其他本機選項
🛇 This item links to a third party project or product that is not part of Kubernetes itself.
More information以下多個第三方工具也能在本機執行 Kubernetes。Kubernetes 專案不提供這些工具的支援，但它們仍可能適合您的學習需求：
有關設定方式與支援資訊，請參閱各工具的文件。
使用線上練習環境
🛇 This item links to a third party project or product that is not part of Kubernetes itself.
More information線上 Kubernetes 練習環境讓您無需在電腦上安裝任何軟體，即可體驗 Kubernetes。這些環境可直接在網頁瀏覽器中使用：
這些平台非常適合用於快速實驗，方便您在不需本機設定的情況下跟著教學操作。
使用接近正式環境的叢集來練習
如果您想練習設定更接近正式環境的叢集，可以使用 kubeadm。使用 kubeadm 設定叢集是一項進階任務，需要多台機器（實體或虛擬），並進行仔細的設定。
若想了解有關正式環境的資訊，請參閱正式環境。
說明：
設定接近正式環境的叢集會比上述的學習環境複雜許多。請先從 kind、minikube 或是線上練習環境開始。
接下來
2 - 正式環境
建立正式環境等級的 Kubernetes 叢集
建立正式環境等級的 Kubernetes 叢集需要事先規劃與準備。
若您的 Kubernetes 叢集需要執行關鍵工作負載，則必須經過適當設定，以具備彈性。
本頁說明如何建立正式環境等級的 Kubernetes 叢集，或將現有叢集調整為可用於正式環境。
若您已熟悉正式環境的設定並只需要相關連結，請直接跳至接下來。
正式環境考量
通常，正式環境中的 Kubernetes 叢集，相較於個人學習、開發或測試環境，會有更多需求。
正式環境可能需要支援多位使用者安全存取、維持穩定的可用性，以及具備因應需求變化的資源。
在決定正式 Kubernetes 環境的部署位置（本地部署或雲端），以及您希望自行管理或交由他人管理的程度時，
請考慮以下因素如何影響您對 Kubernetes 叢集的需求：
- 可用性：單一機器的 Kubernetes 學習環境
存在單點故障的問題。建立高可用叢集時需要考慮：
- 將控制平面與工作節點分開部署。
- 在多個節點上部署控制平面組件的副本
- 對叢集的 API 伺服器 流量進行負載平衡。
- 確保有足夠的工作節點可用，或能在工作負載需求變化時快速擴充。
- 規模：若您預期正式 Kubernetes 環境的需求量維持穩定，或許可以一次性完成所需的容量規劃。
但若您預期需求會隨時間成長，或因季節性或特殊活動等因素而大幅波動，
則需要規劃如何進行擴展，以因應控制平面與工作節點因請求增加所帶來的壓力，或縮減規模以減少閒置資源。
- 安全性與存取管理：在自己的 Kubernetes 學習叢集上，您擁有完整的管理員權限。
但對於承載重要工作負載且有多位使用者的共用叢集，則需要更精細的機制來控管哪些使用者或程序可以存取叢集資源。
您可以使用角色型存取控制（RBAC）及其他安全機制，
確保使用者與工作負載能夠取得所需的資源，同時維持工作負載及叢集本身的安全性。
您可以透過管理政策及
容器資源，
來限制使用者與工作負載可存取的資源。
在自行建立 Kubernetes 正式環境之前，請考慮將部分或全部工作交由雲端整合解決方案提供商
或其他 Kubernetes 合作夥伴處理。可選的方案包括：
- 無伺服器：直接在第三方提供的基礎設施上執行工作負載，無需管理叢集。
費用依 CPU 使用量、記憶體及磁碟請求等計算。
- 受管理的控制平面：由提供商負責管理叢集控制平面的規模與可用性，並處理修補程式和升級作業。
- 受管理的工作節點：設定節點池以符合您的需求，提供商確保節點保持可用，
並在需要時能夠執行升級。
- 整合：部分提供商可將 Kubernetes 與其他所需服務整合，
例如儲存、映像檔儲存庫、身分驗證機制和開發工具。
無論您是自行建立正式 Kubernetes 叢集，或與合作夥伴合作，
請參閱以下章節，以評估與叢集的控制平面、工作節點、使用者存取
及工作負載資源相關的需求。
正式叢集設定
在正式環境等級的 Kubernetes 叢集中，控制平面透過可分散部署於多台電腦上的服務來管理叢集。
每個工作節點則代表一個設定為執行 Kubernetes Pod 的獨立實體。
正式環境控制平面
最簡單的 Kubernetes 叢集是將完整的控制平面和工作節點服務都執行在同一台機器上。
您可以透過新增工作節點來擴展該環境，如
Kubernetes 組件中的示意圖所示。
若叢集僅需在短時間內可用，或在出現嚴重問題時可以直接捨棄，這樣的設定可能已足以滿足您的需求。
但若您需要更持久、高可用的叢集，則應考慮擴展控制平面的方式。
根據設計，執行在單台機器上的控制平面服務並非高可用的。
若維持叢集持續運作、確保出問題時能夠修復對您而言很重要，請考慮以下步驟：
- 管理憑證：控制平面服務之間的安全通訊是透過憑證來實現的。
憑證會在部署期間自動產生，或您也可以使用自己的憑證授權機構來產生。
詳情請參閱 PKI 憑證與需求。
- 為 API 伺服器設定負載平衡器：設定負載平衡器，
將外部 API 請求分散至執行於不同節點上的 apiserver 服務實例。
詳情請參閱建立外部負載平衡器。
- 建立多個控制平面系統：為了實現高可用性，控制平面不應受限於單一機器。
若控制平面服務由 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 與容器數量來確定所需的節點數量。
若您自行管理節點，這可能意味著需要購買並部署自己的實體設備。
- 自動擴縮節點：請閱讀節點自動擴縮，
了解可自動管理節點及其提供之容量的工具。
正式環境使用者管理
在正式環境中，您的使用情境可能會從僅有您或一小組人員存取叢集，
演變為可能有數十甚至數百人需要存取叢集。
在學習環境或平台原型中，您可能僅使用一個管理帳號處理所有操作。
在正式環境中，則通常需要建立多個帳號，並針對不同命名空間設定不同層級的存取權限。
建立正式環境等級的叢集意味著需要決定如何控管其他使用者的存取權限。
具體而言，您需要選擇驗證嘗試存取叢集之使用者身分（身分驗證），
以及判斷其是否具有執行所請求操作之權限（授權）的策略：
- 身分驗證（Authentication）：apiserver 可以使用用戶端憑證、Bearer Token、
身分驗證代理或 HTTP 基本驗證來對使用者進行身分驗證。
您可以選擇要使用的身分驗證方法。
透過外掛程式，apiserver 可以使用您組織現有的身分驗證機制，例如 LDAP 或 Kerberos。
關於驗證 Kubernetes 使用者身分的各種方法，
請參閱身分驗證。
作為在正式環境 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 會使用其命名空間中的預設服務帳號。
關於建立新服務帳號的資訊，請參閱管理服務帳號。
例如，您可能需要：
接下來
3.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 以了解更多資訊，
並學習如何使用它來調整叢集組件的規模，包括叢集關鍵的附加元件。
3.2 - 跨區域執行
本頁面說明如何跨多個區域執行 Kubernetes。
背景
Kubernetes 的設計使單一叢集能夠跨多個故障區（Failure Zone）執行；
這些故障區通常隸屬於一個稱為**「地區」（Region）的邏輯分組。主要的雲端供應商將地區定義為一組故障區，亦稱為可用區（Availability Zone）**，
並提供一致的功能：在同一個地區內，各故障區提供相同的 API 與服務。
典型的雲端架構旨在將單一故障區故障對其他故障區服務的影響降至最低。
控制平面行為
所有控制平面組件都支援以可互換資源池的方式執行，
並為各個組件建立多個副本
當您部署叢集控制平面時，需將控制平面組件的副本分散部署於多個故障區。
若高可用性是重要考量，應選擇至少三個故障區，並為各個控制平面組件（API 伺服器、排程器、etcd、叢集控制器管理器）建立多個副本，分散部署於這些故障區中。
若有使用雲端控制器管理器，也應將它複製到您所選擇的所有故障區中。
說明：
Kubernetes 不會為 API 伺服器端點提供跨故障區的系統韌性。您可以使用多種技術來改善叢集 API 伺服器的可用性，
包括 DNS 輪詢、SRV 記錄，或是具備健康檢查功能的第三方負載平衡方案。
節點行為
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，
請參閱排程與驅逐。