如何利用 knest 構建資料中心的 Kubernetes as a Service?

SmartX超融合發表於2023-01-10

隨著越來越多的企業和應用轉向雲原生架構,對 Kubernetes 叢集的需求也日趨多樣化和靈活化。出於故障隔離的考慮,企業的資料中心往往需要多個獨立的 Kubernetes 叢集來承載不同的業務,而不是全部署在一個共享 Kubernetes 叢集上。

此外,由於業務負載普遍具有動態變化的特點,因此每個 Kubernetes 叢集的規模也存在動態變化的需求,以適應增長的業務負載,並在業務負載降低時能及時釋放計算資源以節省開銷。這些 Kubernetes 叢集運維的需求可以統一歸類到 Kubernetes as a service,即 KaaS 服務。

在主流公有云上,KaaS 是其中非常重要和核心的組成。公有云的 KaaS 可以快速便捷地為其使用者建立生產就緒的高可用 Kubernetes 叢集,並且提供後續為叢集擴容、縮容的運維操作。通常來說,公有云 KaaS 提供的 Kubernetes 叢集的節點都是虛擬機器,以提高物理資源的利用率。

在私有的企業資料中心,KaaS 需要企業 IT 部門從零構建,包括虛擬化平臺、Kubernetes 管理平臺、使用者終端等多套系統的採購和整合,往往耗時又耗錢。此外,傳統主流的虛擬化平臺往往因需要支援廣泛的虛擬化場景而整合了過多的功能,在單純支援 Kubernetes 叢集的場景下,顯得笨重而低效。

為此,SmartX 開源了基於 Cloud Hypervisor 的 Kubernetes 原生輕量虛擬化平臺 ,並且在 Virtink 基礎上進一步開源了 knest 命令列工具,幫助使用者一鍵式地在 Virtink 上建立和運維 Kubernetes 叢集,以更直接、更簡單、更高效的方式為私有資料中心提供 KaaS 的能力基礎。本文將詳細介紹 knest 的功能和使用,幫助使用者認識和了解 knest。

準備 Kubernetes 主機叢集

就如上面我們提到的,Virtink 是 Kubernetes 原生的虛擬化平臺,意味著它需要部署執行在一個 Kubernetes 叢集上。為避免混淆,在接下來的內容中,我們這個 Kubernetes 叢集稱為 Kubernetes 主機叢集,而將部署在 Virtink 虛擬機器上的 Kubernetes 叢集稱為 Kubernetes 虛擬機器叢集。

值得注意的是,Kubernetes 主機叢集的節點並不要求一定是物理機,也可以是支援巢狀虛擬化的虛擬機器。如果您的手頭已有一個現成的 Kubernetes 叢集,可以選擇將其作為接下來的主機叢集,但需要確保叢集的每個節點都支援 KVM。

如果您目前沒有可用的 Kubernetes 叢集,那麼可以選擇用 minikube 在您的本地建立一個臨時的 Kubernetes 叢集作為主機叢集,例如:

minikube start --memory 6g --cni calico.yaml


這裡我們選擇不使用 minikube 預設的 CNI 而使用 Calico,是因為接下來要建立的 Kubernetes 虛擬機器叢集中的 Calico 需要 Kubernetes 主機叢集的 CNI 支援 pod 中的 IPIP 包。Minikube 預設的 CNI 並不支援這個功能,因為選擇使用 Calico。並且,Calico 預設是關閉這個功能的,我們需要增加一個環境變數來開啟這個功能:

curl -LO
sed -i '/^            # Use Kubernetes API as the backing datastore.$/i \ \ \ \ \ \ \ \ \ \ \ \ - name: FELIX_ALLOWIPIPPACKETSFROMWORKLOADS\n              value: "true"' calico.yaml


使用 knest 建立 Kubernetes 虛擬機器叢集

首先,如果您還沒有安裝 knest 的話,請在專案的最新 release 中選擇對應平臺的二進位制檔案,並安裝,例如:

curl -LO
sudo install knest-linux-amd64 /usr/local/bin/knest


接下來,使用 knest 建立 Kubernetes 虛擬機器叢集:

knest create demo --pod-network-cidr 10.245.0.0/16 --service-cidr 10.112.0.0/12


值得注意的是,Kubernetes 虛擬機器叢集的 pod 網路段和 service 網路段必須和 Kubernetes 主機叢集的區分開,網路段之間不能有重疊。

如果您的 Kubernetes 主機叢集是 minikube,那麼 minikube 預設的 pod 網路段和 service 網路段分別是 10.244.0.0/16 和 10.96.0.0/12,因此這裡選擇分別往上走一個網路段作為 Kubernetes 虛擬機器叢集的 pod 網路段和 service 網路段。

擴容 Kubernetes 虛擬機器叢集

上面建立的 Kubernetes 虛擬機器叢集僅包含一個 control plane 節點,且無 worker 節點。如果您的 Kubernetes 主機叢集有足夠的計算資源,可以選擇用 knest 的擴容命令為其新增更多的 control plane 節點和 worker 節點。

而如果您使用的是 minikube 作為 Kubernetes 主機叢集,且本地有至少 10G 的可以記憶體,那麼可以選擇將 minikube 叢集的內容擴大到 10G,然後用 knest 為 Kubernetes 虛擬機器叢集新增一個 worker 節點:


knest scale demo --worker-machine-count 1


建立持久化的 Kubernetes 虛擬機器叢集

透過上面建立的 Kubernetes 虛擬機器叢集預設使用 Virtink 的 ContainerRootfs 型別的儲存。ContainerRootfs 儲存能夠將 Docker image 中的目錄作為虛擬機器的 rootfs,因此能夠完全利用 Docker 的工具鏈來構建虛擬機器的映象,但它無法持久化。

如果虛擬機器關機後再次啟動,其 rootfs 會重新從 Docker image 構建,即無法持久化在虛擬機器執行過程中儲存到 rootfs 中的檔案。如果您希望您的 Kubernetes 虛擬機器叢集的每個節點都是持久化的,knest 也支援建立持久化的 Kubernetes 虛擬機器叢集,例如:

knest create demo --pod-network-cidr 10.245.0.0/16 --service-cidr 10.112.0.0/12 --persistent --host-cluster-cni calico --machine-addresses 10.244.0.100-10.244.0.110


值得注意的是,考慮到 Kubernetes 虛擬機器叢集節點需要固定 IP,因此建議 Kubernetes 主機叢集的 CNI 選擇支援固定 IP 的 CNI,例如 Calico 和 kube-ovn。

在使用 knest 建立持久化的 Kubernetes 虛擬機器叢集時,需要透過 --host-cluster-cni 引數提供 Kubernetes 主機叢集的 CNI 型別,以使 knest 能夠將 IP 以適當的方式標註到 VM 上,使其最終能透過 CNI 正確獲得固定 IP。

此外,您也需要透過 --machine-addresses 引數提供一定數量的固定 IP,以滿足 Kubernetes 虛擬機器叢集的固定 IP 分配需要。

總結

在企業資料中心構建 Kubernetes as a Service 並非一件容易的事,其中涉及到虛擬化平臺、Kubernetes 管理運維平臺、使用者終端等多個平臺的整合。SmartX 開源的 knest 工具,基於其另一個開源的 Kubernetes 原生輕量虛擬化引擎 Virtink 專案,提供一鍵式建立和運維高效、安全、低開銷的 Kubernetes 虛擬化叢集,是資料中心 KaaS 較為理想的基礎構件。 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69974533/viewspace-2931585/,如需轉載,請註明出處,否則將追究法律責任。

相關文章