從零開始建置 Kubernetes

從原始碼建置 Kubernetes 適合用來研究或測試修補過的元件。正式環境叢集還需要受支援的升級路徑、憑證輪替、備份復原、網路、儲存、監控與事件處理程序。

物件模型與 API 路徑 #

Kubernetes 將叢集作業建模為對資源執行 CRUD。每個物件都有 UID、型別、該型別內唯一的名稱、用於索引選取的標籤，以及用於非識別中繼資料的註解。

資源分組至 API 群組：

• 核心群組暴露於 /api/v1；
• 命名群組暴露於 /apis/<group>/<version>。

GET /api、GET /apis 與 /openapi/v3 等探索端點會描述叢集支援的資源。資源清單項目會暴露標準名稱、kind、命名空間範圍、動詞，以及 pvc 等簡短名稱。

常見動詞對應至 HTTP 方法：

• get、list 與 watch 使用 GET；
• create 使用 POST；
• update 使用 PUT；
• patch 使用 PATCH；
• delete 與 deletecollection 使用 DELETE。

由於採用此物件模型，Service 是由許多 Pod 支援的穩定端點，而 Pod 本身仍是暫時性的，重新建立時會取得新的網路識別。

建置並記錄二進位檔 #

使用有文件說明的 Go 工具鏈，從標記的 Kubernetes 原始碼版本建置。記錄每個二進位檔的來源提交、工具鏈版本、建置旗標與校驗和。使用 make WHAT=... 建置選定的命令，或使用發行版建置流程；不要將任意二進位檔下載到控制平面主機。

建立控制平面 #

奇數大小的 etcd 仲裁組會儲存 API 狀態。使用 TLS 保護對等端與用戶端流量，測試快照復原，並限制直接用戶端存取。依相依性順序啟動控制平面：

1. 建立 etcd、憑證、服務帳戶簽署金鑰與網路可達性。
2. 使用服務憑證、etcd 用戶端認證資料、服務 CIDR、准入設定與稽核原則啟動 kube-apiserver。
3. 使用個別識別啟動 kube-controller-manager 與 kube-scheduler。
4. 僅為初始引導設定管理用 kubeconfig。
5. 安裝 CNI 實作，然後加入 kubelet。

kubelet 需要節點識別、API 端點、相容 CRI 的執行階段、CNI 設定，以及一致的 Pod CIDR 假設。服務路由由 kube-proxy 或替代資料平面實作。

控制平面元件各自負責不同工作：

• etcd 儲存叢集狀態；
• kube-apiserver 是所有已驗證請求的入口；
• kube-controller-manager 將期望狀態協調為實際狀態；
• kube-scheduler 為擱置中的 Pod 選擇節點；
• kubelet 讓一個節點與 API 伺服器保持一致；
• kube-proxy 在每個節點上實作服務路由。

保護 API 請求 #

API 伺服器接受 HTTPS 請求。請求路徑如下：

1. 驗證，透過用戶端憑證、服務帳戶權杖或 OIDC 將請求關聯至使用者名稱、UID、群組與可選的額外屬性；
2. 授權，評估識別、動詞、資源、命名空間與名稱；
3. 准入，驗證或變更請求；
4. 請求改變叢集狀態時，持久化至 etcd。

除非已設計明確的替代方案，否則啟用 Node 與 RBAC 授權。停用匿名存取，避免使用靜態權杖檔案，分離元件識別，並將私密金鑰置於原始碼控制之外。在將叢集視為可運作前，驗證 /readyz、DNS、服務路由、資源限制、節點遺失、憑證更新與 etcd 復原。