KinD 是一個輕量級的 Kubernetes 發行版,方便開發者快速在本地環境建立叢集進行測試和開發。透過簡單的指令即可完成 KinD 的安裝,並使用 kind create cluster 建立單節點叢集。對於更進階的需求,可以透過 YAML 組態檔案定義多節點叢集,並設定網路、控制平面、工作節點等引數。刪除叢集也同樣簡便,使用 kind delete cluster 即可移除。KinD 還支援建立高用性叢集,透過內建的 HAProxy 負載平衡器,將流量分發到多個控制平面節點,確保服務的穩定性。設定高用性叢集時,需要在組態檔案中定義多個控制平面節點,KinD 會自動設定 HAProxy 並將其與控制平面節點連線。透過 kubectl 工具,可以與 KinD 叢集互動,執行各種 Kubernetes 操作。
建立 KinD 叢集
安裝 KinD 二進位檔
安裝 KinD 是一個簡單的過程,可以透過單一命令完成。您可以執行本文儲存函式庫中的指令碼,位於 /chapter4/install-kind.sh。或者,您可以執行以下命令:
GO111MODULE="on" go get sigs.k8s.io/[email protected]
安裝完成後,您可以透過輸入 kind version 來驗證 KinD 是否正確安裝:
kind version
這將傳回已安裝的版本:
kind v0.7.0 go1.13.3 linux/amd64
KinD 可執行檔提供了維護叢集生命週期所需的所有選項。當然,KinD 可執行檔可以建立和刪除叢集,但它還提供了以下功能:
- 能夠建立自定義的基礎映像和節點映像
- 可以匯出
kubeconfig或日誌檔案 - 可以檢索叢集、節點或
kubeconfig檔案 - 可以將映像載入到節點中
建立 KinD 叢集
現在您已經安裝了 KinD 工具,幾乎可以建立您的 KinD 叢集。在執行一些建立叢集的命令之前,我們將解釋 KinD 提供的一些建立選項。
建立簡單叢集
要建立一個簡單的叢集,將控制平面和工作節點執行在單一容器中,您只需要使用 create cluster 選項執行 KinD 可執行檔。
讓我們建立一個快速的單節點叢集,看看 KinD 如何快速建立一個開發叢集。在您的主機上,使用以下命令建立一個叢集:
kind create cluster
這將快速建立一個具有所有 Kubernetes 元件的叢集,在單一 Docker 容器中,使用叢集名稱 kind。它還將為 Docker 容器分配一個名稱 kind-control-plane。如果您想分配一個叢集名稱,而不是預設名稱,您需要在 create cluster 命令中新增 --name <cluster name> 選項:
Creating cluster "kind" ...
Ensuring node image (kindest/node:v1.18.2)
Preparing nodes
Writing configuration
Starting control-plane
Installing CNI
Installing StorageClass
Set kubectl context to "kind-kind"
You can now use your cluster with:
kubectl cluster-info --context kind-kind
create 命令將建立叢集並修改 kubectl 組態檔案。KinD 將新的叢集新增到您的當前 kubectl 組態檔案中,並將新的叢集設定為預設上下文。
驗證叢集建立成功
我們可以透過使用 kubectl 工具列出節點來驗證叢集是否成功建立:
kubectl get nodes
這將傳回執行的節點,對於基本叢集來說,是單一節點:
NAME STATUS ROLES AGE VERSION
kind-control-plane Ready master 130m v1.18.2
佈署這個單節點叢集的主要目的是向您展示 KinD 可以快速建立一個可用於測試的叢集。對於我們的練習,我們希望將控制平面和工作節點分開,以便我們可以使用下一節中的步驟刪除這個叢集。
刪除叢集
當您完成測試後,您可以使用 delete 命令刪除叢集:
kind delete cluster --name <cluster name>
delete 命令將快速刪除叢集,包括您的 kubeconfig 檔案中的任何條目。
建立多節點叢集組態檔
當建立一個多節點叢集,例如具有自定義選項的雙節點叢集時,我們需要建立一個叢集組態檔。組態檔是一個 YAML 檔案,其格式應該很熟悉。在這個檔案中設定值允許您自定義 KinD 叢集,包括節點數量、API 選項等。我們用於為本文建立叢集的組態檔如下所示 - 它包含在本文的儲存函式庫中,位於 /chapter4/cluster01-kind.yaml:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
apiServerAddress: "0.0.0.0"
disableDefaultCNI: true
kubeadmConfigPatches:
- |
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
metadata:
name: config
networking:
serviceSubnet: "10.96.0.1/12"
podSubnet: "192.168.0.0/16"
nodes:
- role: control-plane
- role: worker
extraPortMappings:
- containerPort: 80
hostPort: 80
- containerPort: 443
hostPort: 443
extraMounts:
- hostPath: /usr/src
containerPath: /usr/src
多節點叢集組態
如果您只想要一個多節點叢集而沒有任何額外的選項,您可以建立一個簡單的組態檔案,列出您想要在叢集中的節點數量和型別。 以下組態檔案將建立一個具有三個控制平面節點和三個工作節點的叢集:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: control-plane
- role: control-plane
- role: worker
- role: worker
- role: worker
使用多個控制平面伺服器會引入額外的複雜性,因為我們在組態檔案中只能針對單個主機或 IP。要使此組態可用,我們需要在我們的叢集前面佈署一個負載平衡器。
詳細解說:KinD 組態檔案解析
組態檔案結構
KinD 的組態檔案採用 YAML 格式,主要包含三個部分:叢集基本資訊、網路組態和節點定義。
網路組態詳解
網路組態是 KinD 組態中的重要部分,主要包括以下幾個關鍵引數:
- apiServerAddress:指定 API 伺服器的地址,設定為 “0.0.0.0” 表示監聽所有可用的網路介面。
- disableDefaultCNI:設定為 true 表示停用預設的 CNI(Container Network Interface)外掛,需要自行安裝其他 CNI 外掛。
- serviceSubnet:定義 Kubernetes 服務的 IP 範圍,用於內部服務發現。
- podSubnet:定義 Pod 的 IP 範圍,用於容器之間的通訊。
節點定義詳解
節點定義部分使用 nodes 欄位來描述叢集中的節點角色和數量。例如:
nodes:
- role: control-plane
- role: worker
這段組態定義了一個控制平面節點和一個工作節點。
埠對映組態
extraPortMappings 用於將容器內的埠對映到主機埠,例如:
extraPortMappings:
- containerPort: 80
hostPort: 80
- containerPort: 443
hostPort: 443
這段組態將容器內的 80 和 443 埠分別對映到主機的 80 和 443 埠。
目錄掛載組態
extraMounts 用於將主機目錄掛載到容器內,例如:
extraMounts:
- hostPath: /usr/src
containerPath: /usr/src
這段組態將主機的 /usr/src 目錄掛載到容器的 /usr/src 目錄。
圖表翻譯:KinD 叢集架構圖
圖表翻譯: 此圖示展示了 KinD 叢集的基本架構。主機透過執行 KinD 建立了一個 Kubernetes 叢集,該叢集包含控制平面節點和工作節點。控制平面節點負責叢集的管理和控制,而工作節點則執行實際的工作負載(Pod)。
最佳實踐與注意事項
- 叢集規劃:在建立 KinD 叢集之前,應根據實際需求規劃叢集的規模和組態。
- 網路組態:合理組態網路引數,確保叢集內部通訊和外部存取的順暢。
- 資源分配:根據主機資源情況,合理分配給 KinD 叢集中的各個節點。
- 安全性考慮:注意叢集的安全組態,如埠對映和目錄掛載的安全性。
透過遵循上述和最佳實踐,可以有效地使用 KinD 建立和管理 Kubernetes 叢集,滿足不同的測試和開發需求。
使用 KinD 佈署 Kubernetes 的進階技術
KinD 的高用性架構實作
當使用 KinD 佈署多個控制平面節點時,系統會自動建立一個額外的容器來執行 HAProxy 負載平衡器。這種設計有效地提高了控制平面的可用性。在一個多節點組態中,我們可以觀察到除了節點容器外,還有一個 HAProxy 容器正在執行。
負載平衡組態詳解
由於所有容器都執行在單一主機上,因此每個控制平面節點和 HAProxy 容器都使用唯一的埠。HAProxy 容器的埠是叢集的目標埠。例如,在 Kubernetes 組態檔案中,目標地址可能是 https://127.0.0.1:32791,這正是分配給 HAProxy 容器的埠。
kubectl 命令執行流程
當使用 kubectl 執行命令時,請求會直接傳送到 HAProxy 伺服器。HAProxy 根據 KinD 在建立叢集期間生成的組態檔案,將流量路由到三個控制平面節點之一。以下是一個範例組態:
# generated by kind
global
log /dev/log local0
log /dev/log local1 notice
daemon
defaults
log global
mode tcp
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
frontend control-plane
bind *:6443
default_backend kube-apiservers
backend kube-apiservers
option httpchk GET /healthz
server config2-control-plane 172.17.0.8:6443 check check-ssl verify none
server config2-control-plane2 172.17.0.6:6443 check check-ssl verify none
server config2-control-plane3 172.17.0.5:6443 check check-ssl verify none
組態解讀
在上述組態中,kube-apiservers 後端部分包含了三個控制平面容器的條目。每個條目包含控制平面節點的 Docker IP 地址和埠 6443,指向容器中執行的 API 伺服器。當請求 https://127.0.0.1:32791 時,該請求會到達 HAProxy 容器,並根據組態檔案中的規則路由到三個節點之一。
自定義控制平面和 Kubelet 選項
OIDC 整合範例
要測試諸如 OIDC 整合或 Kubernetes 功能門等功能,可以透過修改 KinD 組態檔案來實作。例如,要將叢集與 OIDC 提供者整合,可以在組態檔案的 kubeadmConfigPatches 部分新增所需的選項:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
kubeadmConfigPatches:
- |
kind: ClusterConfiguration
metadata:
name: config
apiServer:
extraArgs:
oidc-issuer-url: "https://oidc.testdomain.com/auth/idp/k8sIdp"
oidc-client-id: "kubernetes"
oidc-username-claim: sub
oidc-ca-file: /etc/oidc/ca.crt
nodes:
- role: control-plane
- role: control-plane
- role: control-plane
- role: worker
- role: worker
- role: worker
建立自定義 KinD 叢集
建立步驟
- 確保目前目錄位於
chapter4目錄下。 - 使用以下命令建立 KinD 叢集:
kind create cluster --name cluster01 --config cluster01-kind.yaml
該命令將建立名為 cluster01 的叢集,並使用 cluster01-kind.yaml 組態檔案。
#### 內容解密:
--name選項用於設定叢集的名稱。--config選項告訴安裝程式使用指定的組態檔案。- KinD 將根據組態檔案建立叢集,並輸出建立過程中的每個步驟。
KinD 叢集架構圖
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title KinD 叢集建立與高用性組態
package "Kubernetes Cluster" {
package "Control Plane" {
component [API Server] as api
component [Controller Manager] as cm
component [Scheduler] as sched
database [etcd] as etcd
}
package "Worker Nodes" {
component [Kubelet] as kubelet
component [Kube-proxy] as proxy
package "Pods" {
component [Container 1] as c1
component [Container 2] as c2
}
}
}
api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2
note right of api
核心 API 入口
所有操作經由此處
end note
@enduml
圖表翻譯:
此圖展示了 KinD 叢集的高用性架構。客戶端透過 kubectl 命令向 HAProxy 傳送請求,HAProxy 再將請求路由到三個控制平面節點之一。每個控制平面節點都執行著 API Server,負責處理客戶端的請求。這種架構有效地提高了控制平面的可用性和可靠性。