你是否曾經想嘗試使用K3s的高可用模式？但是苦於沒有3個“備用節點”，或者沒有設定相同數量的虛擬機器所需的時間？那麼k3d這個方案也許你十分需要噢！ 如果你對k3d尚不瞭解，它的名字或許可以給你一個瞭解它的切入口：K3s in Docker。k3d是一個輕量級封裝程式，用於在Docker中執行k3s。藉助k3d，可以輕鬆在Docker內建立單節點或多節點的k3s叢集，用於Kubernetes上的本地開發。 K3d允許你在短時間內啟動k3s叢集。此外，你可以快速學會其少量但十分有用的命令。K3d執行在Docker內，這意味著你可以擴充套件或減少節點而不需要進行多餘的設定。在本文中，我們將介紹如何使用k3d設定單節點K3s叢集以及如何使用k3d在高可用模式下設定k3s。 本文的兩個主要目的是介紹k3d作為部署K3s叢集的工具，以及展示K3s高可用性如何抵抗“節點退化（nodes degradation）”。而且，我們還將瞭解k3s預設在叢集中部署了哪些元件。 # 前期準備 在作業系統（Linux、MacOS、Windows）方面，大家都有自己的偏好。所以在我們檢查用於本篇文章的設定之前，僅有兩個必要的要求：Docker和Linux shell。 如果你使用的系統是MacOS或者Windows，Docker Desktop是Dcoker的首選解決方案。對於Linux來說，你可以獲取Docker engine以及CLIs，詳細資訊如下： https://www.docker.com/products/docker-desktop Linux shell、MacOS以及Linux都會有所涉及。對於Windows系統而言，最簡單快捷的解決方案是WSL2，我們也會在demo中用到它。 以下是我們將會用到的設定： - OS：Windows 10 version 2004（build：19041） - OS 元件：虛擬化機器平臺以及Linux的Windows子系統 - 安裝步驟： - https://docs.microsoft.com/en-us/windows/wsl/install-win10 - WLS2發行版：Ubuntu - Windows商店地址： - https://www.microsoft.com/en-us/p/ubuntu/9nblggh4msv6#activetab=pivot:overviewtab - 【可選】使用的控制檯：Windows Terminal - Windows商店地址： - https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701 # Step1：從安裝開始 訪問下方連結即可瞭解如何安裝k3d： https://k3d.io/#installation 在本文中，我們將以curl的方式安裝。 >請注意：直接從URL執行指令碼存在很嚴重的安全問題。所以在執行任意指令碼之前，確保源是專案的網站或git線上repository。 以下是安裝步驟： 訪問：https://k3d.io/#installation 複製“curl“安裝命令並且在你的terminal內執行它： **curl -s https://raw.githubusercontent.com/rancher/k3d/main/install.sh | bash**  >請注意：該截圖顯示了兩個命令： - **k3d version**：提供已安裝的k3d版本 - **k3d –help**：列出可用於k3d的命令 現在k3d已經安裝完成並且準備開始使用。 # Step2：從單節點叢集開始 在我們建立一個HA叢集之前，讓我們從單節點叢集開始以理解命令（“grammar”）並且檢視預設情況下k3d部署了什麼。 首先，語法。在V3，k3d在命令的使用方式上做了很大的改變。我們不深入研究以前的命令是怎麼做的，我們將使用V3的語法。 K3s遵循“名詞+動詞”的句法。首先指定我們要使用的東西（叢集或節點），然後指定我們要應用的操作（create、delete、start、stop）。 ## 建立一個單節點叢集 我們將藉助k3d使用預設值建立一個單節點叢集： **k3d cluster create **  請注意：k3d cluster create命令的輸出建議執行另一條命令來檢查叢集是否在執行並且可以訪問：**kubectl cluster-info** 現在叢集已經啟動並且在執行啦！ ## 窺視內部結構 我們還可以從不同的角度看看到底部署了什麼。 讓我們從頭開始，看看K3s叢集裡面有什麼（pods、服務、部署等）： **kubectl get all --all-namespaces**  我們可以看到，除了Kubernetes服務外，當我們使用預設值時，K3s還部署了DNS、metrics和ingress（traefik）服務。 現在讓我們從不同的視角檢視節點。 首先，我們從叢集的視角檢查它： **kubectl get nodes --output wide**  如我們所料，僅看到了一個節點。現在讓我們從k3d的視角檢視： **k3d node list**  現在我們有兩個節點。這裡有一個比較智慧的實現是，當叢集執行在它的節點**k3d-k3s-default-server-0**上時，有另一個“節點”作為負載均衡器。雖然這可能對單節點叢集沒有太大作用，但在我們的HA叢集中，它將為我們節省很多精力。 最後，我們從Docker看到兩個節點：**docker ps**  ## 清理資源 我們的單節點叢集可以幫助我們理解k3d的機制和命令。現在，我們需要在部署HA叢集之前清理資源：**k3d cluster delete**  *請注意*：出於demo的目的，我們在上方截圖中添加了以下命令： - **k3d cluster list**：列出活躍的k3d叢集 - **kubectl cluster-info**：檢查叢集的連線 - **docker ps**：檢查活躍的容器 現在，我們已經使用k3d建立、檢查並刪除了一個單節點叢集。下一步，我們開始嘗試HA。 # Step3：歡迎來到HA的世界 在我們開啟命令列之前，讓我們對我們即將要部署的東西有一個基本的瞭解並且瞭解一些其他額外的要求。 首先，Kubernetes HA有兩個可能的設定：嵌入式或外部資料庫。我們將採用嵌入式資料庫的設定。 其次，K3s有兩種不同的技術用於嵌入式資料庫的HA：一種是基於dqlite（K3s v1.18），另一種是基於etcd（K3s v1.19+）。 這意味著etcd是當前K3s穩定版中的預設版本，也是本文將使用的版本。Dqlite已經棄用。 在撰寫本文時，k3d預設使用k3s v1.18.9-k3s1的版本。你可以通過k3d version來檢查：  那麼這是否意味著我們需要重新安裝支援K3s v1.19的k3d嗎？當然不需要！ 我們可以使用當前已經安裝的k3d版本並且依舊支援K3s v1.19，因為： - k3d可以讓我們指定一個特定的k3s docker映象來使用 - 所有的k3s版本都是以容器映象的形式釋出的 基於以上原因，我們可以假設一個K3s v1.19作為一個容器映象儲存在Docker Hub中： https://hub.docker.com/r/rancher/k3s/tags?page=1&name=v1.19 現在，讓我們用k3d建立第一個K3s HA叢集。 ## 三個控制平面 根據Kubernetes HA的最佳實踐，我們應該使用至少3個控制平面來建立一個HA叢集。 在k3d中我們使用以下命令即可： **k3d cluster create --servers 3 --image rancher/k3s:v1.19.3-k3s2**  瞭解命令： 基礎命令：**k3d cluster create** 選項： - **server 3**：請求用角色伺服器建立三個節點。 - **image rancher/k3s:v1.19.3-k3s2**:指定要使用的K3S映象 現在我們可以從不同的角度檢查我們已經建立的叢集 **kubectl get nodes --output wide**  如你所見，我們從不同方面進行檢查以確保我們的節點正常執行。 如果我們看到元件已經部署完成，那麼我們的daemonset現在有3個副本，而不是1個： **kubectl get all --all-namespaces**  最後一項檢查是看pods在哪個節點上執行： **kubectl get podes --all-namespaces --output wide**  現在我們有了HA叢集的基礎。讓我們新增額外的控制平面節點，並故意對其進行破壞，看看叢集的表現。 ## 擴充套件叢集 由於k3d以及我們的叢集執行在頂部容器的事實，我們可以快速模擬在HA叢集中增加另一個控制平面節點： **k3d node create extraCPnode --role=server --image=rancher/k3s:v1.19.3-k3s2**  **瞭解命令：** 基礎命令：**k3d node create** 選項： **extraCPnode**：k3d用於建立最終節點名稱的基本名稱。 **role=server**：設定節點的角色為控制平面。 **image rancher/k3s:v1.19.3-k3s2**：指定要使用的K3s映象。 從這裡可以看出，我們從不同的角度進行檢查以確保新的控制平面節點正常執行。 增加了這個額外的節點之後，我們就可以進行最後的測試了：降低node0！ # HA：重型裝甲防撞車 node0通常是我們的KUBECONFIG所指的節點（用IP或主機名錶示），因此我們的kubectl應用程式試圖連線到它來執行不同的命令。 由於我們正在使用容器，所以“破壞“一個節點的最好方法是直接停止容器。 **docker stop k3d-k3s-default-server-0**  >請注意：Docker和k3d命令會立即顯示狀態變化。然而，Kubernetes叢集需要很短的時間才能看到狀態變化為NotReady。 此外，我們的叢集仍然使用Kubectl響應我們的命令。 現在是時候再次參考負載均衡器k3d所用的時間，以及它對於讓我們繼續訪問K3s叢集的重要性。 從外部連線的角度來看，雖然負載均衡器內部切換到了下一個可用節點，但我們仍使用相同的IP/主機。這種抽象為我們節省了很多經理，並且這是k3d最有用的功能之一。 讓我們看一下叢集的狀態： **kubectl get all --all-namespaces**  一切看起來正常。如果我們再具體看一下Pods，那麼我們會發現，K3s通過在其他節點上重新建立執行在故障節點上的pods來自動自愈： **kubectl get pods --all-namespaces --output wide**  最終，為了展示HA的強大以及k3s如何管理它，讓我們重啟node0，然後我們會看到它被重新納入叢集，好像什麼都沒有發生。 **docker start k3d-k3s-default-server-0**  我們的叢集是穩定的並且所有節點都再次正常執行。 ## 再次清理資源 現在我們可以刪除本地HA叢集，因為它已經完成了它的使命。此外，我們知道我們可以輕鬆建立一個新的叢集。 使用以下命令即可清理我們的HA叢集： **k3d cluster delete**  # 總 結 雖然我們在本地、容器中建立了單節點和HA叢集，我們仍然可以看到K3s在新的etcd嵌入式DB下的表現，如果我們在裸機或虛擬機器上部署K3s，其作用方式相同。 也就是說，k3d在管理方面幫助很大。它預設建立了一個負載均衡器，允許永久連線到K3s叢集，同時抽象了所有的任務。如果它部署在容器外，我們需要手動完成這一步驟。 在本文中，我們已經看到了使用k3d設定高可用性K3s叢集是多麼容易。如果你尚未嘗試，強烈推薦你根據本教程進行實踐，它們都是開源且易