DIY：使用 Kubernetes 建立您自己的雲端 (第 1 部分)

在 Ænix，我們對 Kubernetes 懷有深厚的感情，並夢想所有現代技術很快將開始利用其卓越的模式。

您是否曾想過建立自己的雲端？我敢肯定您有。但是，是否有可能僅使用現代技術和方法，而不離開舒適的 Kubernetes 生態系統來做到這一點？我們開發 Cozystack 的經驗要求我們深入研究它。

您可能會爭辯說 Kubernetes 並非用於此目的，以及為何不直接為裸機伺服器使用 OpenStack，並按預期在其內部執行 Kubernetes。但是，這樣做只會將責任從您手中轉移到 OpenStack 管理員手中。這至少會在您的生態系統中增加一個龐大而複雜的系統。

為何讓事情複雜化？ - 畢竟，Kubernetes 此時已經擁有一切運行租戶 Kubernetes 叢集所需的功能。

我想與您分享我們在開發基於 Kubernetes 的雲端平台方面的經驗，重點介紹我們自己使用的開源專案，並認為這些專案值得您關注。

在本系列文章中，我將告訴您我們如何僅使用開源技術從裸機準備託管 Kubernetes 的故事。從資料中心準備的基本層級開始，運行虛擬機器、隔離網路、設定容錯儲存，到佈建具有動態磁碟區佈建、負載平衡器和自動擴展的全功能 Kubernetes 叢集。

在本文中，我將開始一個由幾個部分組成的系列

• 第 1 部分：為您的雲端準備基礎。在裸機上準備和運作 Kubernetes 期間面臨的挑戰，以及佈建基礎架構的現成配方。
• 第 2 部分：網路、儲存和虛擬化。如何將 Kubernetes 變成啟動虛擬機器的工具，以及為此需要什麼。
• 第 3 部分：Cluster API 以及如何按一下按鈕開始佈建 Kubernetes 叢集。自動擴展如何運作、磁碟區的動態佈建和負載平衡器。

我將嘗試盡可能獨立地描述各種技術，但同時，我也將分享我們的經驗以及我們為何得出某個解決方案。

首先，讓我們了解 Kubernetes 的主要優勢，以及它如何改變使用雲端資源的方法。

重要的是要了解在雲端和裸機中使用 Kubernetes 是不同的。

雲端中的 Kubernetes

當您在雲端中運作 Kubernetes 時，您不必擔心持久性磁碟區、雲端負載平衡器或節點佈建程序。所有這些都由您的雲端供應商處理，他們以 Kubernetes 物件的形式接受您的請求。換句話說，伺服器端對您完全隱藏，您真的不想知道雲端供應商究竟如何實作，因為這不在您的責任範圍內。

Kubernetes 提供在任何地方都以相同方式運作的便利抽象概念，讓您可以在任何雲端中的任何 Kubernetes 上部署您的應用程式。

在雲端中，您通常有幾個獨立的實體：Kubernetes 控制平面、虛擬機器、持久性磁碟區和負載平衡器作為不同的實體。使用這些實體，您可以建立高度動態的環境。

由於 Kubernetes，虛擬機器現在僅被視為利用雲端資源的實用實體。您不再將資料儲存在虛擬機器中。您可以隨時刪除所有虛擬機器並重新建立它們，而不會中斷您的應用程式。Kubernetes 控制平面將繼續保留有關叢集中應執行哪些內容的資訊。負載平衡器將繼續將流量發送到您的工作負載，只需變更端點即可將流量發送到新節點。而您的資料將安全地儲存在雲端提供的外部持久性磁碟區中。

在雲端中使用 Kubernetes 時，這種方法是基本的。其原因是顯而易見的：系統越簡單，它就越穩定，為了這種簡單性，您去雲端購買 Kubernetes。

裸機上的 Kubernetes

在雲端中使用 Kubernetes 非常簡單方便，但裸機安裝就不能這麼說了。在裸機世界中，相反地，Kubernetes 變得難以忍受地複雜。首先，因為整個網路、後端儲存、雲端負載平衡器等通常不是在外部運行，而是在您的叢集內部運行。因此，這樣的系統更難以更新和維護。

自己判斷：在雲端中，若要更新節點，您通常會刪除虛擬機器（甚至使用 kubectl delete node），並讓您的節點管理工具根據不可變映像建立一個新節點。新節點將加入叢集，並像節點一樣「正常運作」；遵循 Kubernetes 世界中非常簡單且常用的模式。許多叢集每隔幾分鐘就會訂購新的虛擬機器，僅僅因為他們可以使用更便宜的現貨執行個體。但是，當您擁有實體伺服器時，您不能只是刪除並重新建立它，首先是因為它通常運行一些叢集服務、儲存資料，而且其更新程序要複雜得多。

有不同的方法可以解決此問題，範圍從 kubeadm、kubespray 和 k3s 完成的原地更新，到透過 Cluster API 和 Metal3 完全自動化佈建實體節點。

我喜歡 Talos Linux 提供的混合方法，您的整個系統都在單一組態檔案中描述。此檔案的大多數參數都可以在不重新啟動或重新建立節點的情況下應用，包括 Kubernetes 控制平面組件的版本。但是，它仍然保持 Kubernetes 的最大宣告式本質。這種方法在更新裸機節點時，最大限度地減少對叢集服務的不必要影響。在大多數情況下，您不需要遷移虛擬機器並在次要更新時重建叢集檔案系統。

為您未來的雲端準備基礎

因此，假設您已決定建立自己的雲端。若要從某處開始，您需要一個基礎層。您不僅需要考慮如何在伺服器上安裝 Kubernetes，還需要考慮如何更新和維護它。請考慮這樣一個事實，您將必須考慮諸如更新核心、安裝必要的模組以及套件和安全性修補程式之類的事情。現在您必須考慮更多在使用現成的雲端 Kubernetes 時不必擔心的事項。

當然，您可以使用 Ubuntu 或 Debian 等標準發行版，或者您可以考慮 Flatcar Container Linux、Fedora Core 和 Talos Linux 等專用發行版。每個都有其優點和缺點。

我們呢？在 Ænix，我們使用相當多的特定核心模組，例如 ZFS、DRBD 和 OpenvSwitch，因此我們決定採用預先形成具有所有必要模組的系統映像的路徑。在這種情況下，Talos Linux 對我們來說是最方便的。例如，這樣的組態足以建立具有所有必要核心模組的系統映像

arch: amd64
platform: metal
secureboot: false
version: v1.6.4
input:
  kernel:
    path: /usr/install/amd64/vmlinuz
  initramfs:
    path: /usr/install/amd64/initramfs.xz
  baseInstaller:
    imageRef: ghcr.io/siderolabs/installer:v1.6.4
  systemExtensions:
    - imageRef: ghcr.io/siderolabs/amd-ucode:20240115
    - imageRef: ghcr.io/siderolabs/amdgpu-firmware:20240115
    - imageRef: ghcr.io/siderolabs/bnx2-bnx2x:20240115
    - imageRef: ghcr.io/siderolabs/i915-ucode:20240115
    - imageRef: ghcr.io/siderolabs/intel-ice-firmware:20240115
    - imageRef: ghcr.io/siderolabs/intel-ucode:20231114
    - imageRef: ghcr.io/siderolabs/qlogic-firmware:20240115
    - imageRef: ghcr.io/siderolabs/drbd:9.2.6-v1.6.4
    - imageRef: ghcr.io/siderolabs/zfs:2.1.14-v1.6.4
output:
  kind: installer
  outFormat: raw

然後我們使用 docker 命令列工具來建立 OS 映像

cat config.yaml | docker run --rm -i -v /dev:/dev --privileged "ghcr.io/siderolabs/imager:v1.6.4" - 

結果，我們獲得了一個包含我們所需一切的 Docker 容器映像，我們可以使用它在我們的伺服器上安裝 Talos Linux。您可以執行相同的操作；此映像將包含所有必要的韌體和核心模組。

但問題出現了，您如何將新形成的映像交付到您的節點？

我一直在思考 PXE 開機的想法很長一段時間了。例如，我兩年前撰寫了一篇關於 Kubefarm 專案的文章完全是使用這種方法建構的。但不幸的是，它確實可以幫助您部署您的第一個父叢集，該叢集將容納其他叢集。因此，現在您已經準備好一個解決方案，可以幫助您使用 PXE 方法執行相同的操作。

基本上，您需要做的就是在容器內運行臨時 DHCP 和 PXE 伺服器。然後您的節點將從您的映像開機，您可以使用簡單的 Debian 風格腳本來幫助您引導您的節點。

該 talos-bootstrap 腳本的原始碼可在 GitHub 上取得。

此腳本可讓您在五分鐘內在裸機上部署 Kubernetes 並取得用於存取它的 kubeconfig。但是，仍有許多未解決的問題擺在眼前。

交付系統組件

在此階段，您已經擁有一個能夠運行各種工作負載的 Kubernetes 叢集。但是，它尚未完全運作。換句話說，您需要設定網路和儲存，以及安裝必要的叢集擴充功能，例如用於運行虛擬機器的 KubeVirt，以及監控堆疊和其他系統範圍的組件。

傳統上，這是透過將 Helm charts 安裝到您的叢集中來解決的。您可以透過在本機運行 helm install 命令來執行此操作，但是當您想要追蹤更新時，以及如果您有多個叢集並且想要保持它們的統一性時，此方法會變得不方便。實際上，有很多方法可以宣告式地執行此操作。為了解決這個問題，我建議使用最佳 GitOps 實務。我的意思是像 ArgoCD 和 FluxCD 這樣的工具。

雖然 ArgoCD 以其圖形介面和中央控制平面更方便用於開發目的，但另一方面，FluxCD 更適合用於建立 Kubernetes 發行版。使用 FluxCD，您可以指定應啟動哪些具有哪些參數的圖表，並描述依賴關係。然後，FluxCD 將為您處理一切。

建議在新建立的叢集中執行 FluxCD 的一次性安裝，並為其提供組態。這將安裝所有必要的組件，使叢集達到預期狀態。

透過在新建立的叢集中執行 FluxCD 的單次安裝並相應地設定它，您可以使其自動部署所有必要的組件。這將允許您的叢集將自身升級到所需的狀態。例如，在安裝我們的平台後，您將看到下一個預先設定的 Helm charts 以及系統組件

NAMESPACE                        NAME                        AGE    READY   STATUS
cozy-cert-manager                cert-manager                4m1s   True    Release reconciliation succeeded
cozy-cert-manager                cert-manager-issuers        4m1s   True    Release reconciliation succeeded
cozy-cilium                      cilium                      4m1s   True    Release reconciliation succeeded
cozy-cluster-api                 capi-operator               4m1s   True    Release reconciliation succeeded
cozy-cluster-api                 capi-providers              4m1s   True    Release reconciliation succeeded
cozy-dashboard                   dashboard                   4m1s   True    Release reconciliation succeeded
cozy-fluxcd                      cozy-fluxcd                 4m1s   True    Release reconciliation succeeded
cozy-grafana-operator            grafana-operator            4m1s   True    Release reconciliation succeeded
cozy-kamaji                      kamaji                      4m1s   True    Release reconciliation succeeded
cozy-kubeovn                     kubeovn                     4m1s   True    Release reconciliation succeeded
cozy-kubevirt-cdi                kubevirt-cdi                4m1s   True    Release reconciliation succeeded
cozy-kubevirt-cdi                kubevirt-cdi-operator       4m1s   True    Release reconciliation succeeded
cozy-kubevirt                    kubevirt                    4m1s   True    Release reconciliation succeeded
cozy-kubevirt                    kubevirt-operator           4m1s   True    Release reconciliation succeeded
cozy-linstor                     linstor                     4m1s   True    Release reconciliation succeeded
cozy-linstor                     piraeus-operator            4m1s   True    Release reconciliation succeeded
cozy-mariadb-operator            mariadb-operator            4m1s   True    Release reconciliation succeeded
cozy-metallb                     metallb                     4m1s   True    Release reconciliation succeeded
cozy-monitoring                  monitoring                  4m1s   True    Release reconciliation succeeded
cozy-postgres-operator           postgres-operator           4m1s   True    Release reconciliation succeeded
cozy-rabbitmq-operator           rabbitmq-operator           4m1s   True    Release reconciliation succeeded
cozy-redis-operator              redis-operator              4m1s   True    Release reconciliation succeeded
cozy-telepresence                telepresence                4m1s   True    Release reconciliation succeeded
cozy-victoria-metrics-operator   victoria-metrics-operator   4m1s   True    Release reconciliation succeeded

結論

結果，您獲得了一個高度可重複的環境，您可以將其提供給任何人，並且知道它完全按照預期運作。這實際上是 Cozystack 專案的作用，您可以完全免費試用。

在接下來的文章中，我將討論如何準備 Kubernetes 以運行虛擬機器和如何按一下按鈕運行 Kubernetes 叢集。敬請關注，這將很有趣！

• ←上一篇
下一篇→