前言

Kubernetes（k8s） 憑借著其優良的架構，靈活的擴展能力，豐富的應用編排模型，成為了容器編排領域的事實標準。越來越多的企業擁抱這一趨勢，選擇 k8s 作為容器化應用的基礎設施，逐漸將自己的核心服務遷移到 k8s 之上。

可用性對基礎設施而言至關重要。各大云計算廠商紛紛推出了高可用、可擴展的 k8s 托管服務，其中比較有代表性的有?Amazon EKS、Azure Kubernetes Service (AKS)、Google Kubernetes Engine、阿里云容器服務 Kubernetes 版等。

雖然公有云托管的 k8s 服務百花齊放，但很多企業仍有自建集群的需求。正是這樣的原因，促進了一大批出色的 k8s 集群部署方案的誕生，他們的特點如下表所示。

部署方案特點

Kubeadm	1. 官方出品的部署工具，提供了 k8s 集群生命周期管理的領域知識。 2. 旨在成為更高級別工具的可組合構建塊。
Kubespray	1. 支持在裸機和 AWS、GCE、Azure 等眾多云平臺上部署 k8s。 2. 基于 Ansible Playbook 定義 k8s 集群部署任務。 3. 支持大部分流行的 Linux 發行版。
Kops	1. 僅支持在 AWS、GCE 等少數云平臺上部署 k8s。 2. 建立在狀態同步模型上，用于 dry-run 和自動冪等性。 3. 能夠自動生成 Terraform 配置。
Rancher Kubernetes Engine（RKE）	1. 著名的開源企業級容器管理平臺?Rancher?提供的輕量級 k8s 安裝工具。 2. 支持在裸機、虛擬機、公有云上部署和管理 k8s 集群。

上述方案中，RKE 在易用性和靈活性上占有優勢。本文接下來將介紹如何通過 RKE 部署一套高可用 k8s 集群，文中使用的 RKE 版本為v0.2.2。

高可用 k8s 集群架構

首先需要了解高可用 k8s 集群的架構特點，下圖是官方推薦的高可用集群架構圖。

其核心思想是讓 k8s master 節點中的各類組件具備高可用性，消除單點故障。

• kube-apiserver?- 對外暴露了 k8s API，是整個集群的訪問入口。由于 apiserver 本身無狀態，可以通過啟動多個實例并結合負載均衡器實現高可用。
• etcd?- 用于存儲 k8s 集群的網絡配置和對象的狀態信息，是整個集群的數據中心。可以通過啟動奇數個 etcd 實例建立一個冗余的，可靠的數據存儲層。
• kube-scheduler?- 為新創建的 pod 選擇一個供他們運行的節點。一個集群只能有一個活躍的 kube-scheduler 實例，可以同時啟動多個 kube-scheduler 并利用領導者選舉功能實現高可用。
• kube-controller-manager?- 集群內部的管理控制中心。一個集群只能有一個活躍的 kube-controller-manager 實例，可以同時啟動多個 kube-controller-manager 并利用領導者選舉功能實現高可用。

此外，構建集群的時還需要注意下列問題。

• 節點上 k8s 進程的可靠性。需要讓 kubelet、kube-scheduler、kube-controller-manager 等進程在出現故障后能自動重啟。
• 為 worker node 中的非 pod 進程預留資源，防止他們將與 pod 爭奪資源導致節點資源短缺。

使用 RKE 構建高可用 k8s 集群

節點規劃

構建集群的第一步是將擁有的服務器按節點功能進行劃分，下表展示了筆者環境下的節點規劃情況。

IP角色

192.168.0.10	部署節點
192.168.0.11	k8s master - api-server, etcd, scheduler, controller-manager
192.168.0.12	k8s master - api-server, etcd, scheduler, controller-manager
192.168.0.13	k8s master - api-server, etcd, scheduler, controller-manager
192.168.0.14	k8s worker - kubelet, kube-proxy
192.168.0.15	k8s worker - kubelet, kube-proxy
192.168.0.16	k8s worker - kubelet, kube-proxy
192.168.0.17	k8s worker - kubelet, kube-proxy

規劃說明：

單獨選擇了一臺機器192.168.0.10作為部署節點。如果機器數不多，可以將部署節點加入到 k8s 集群中。

為了保證可用性，擇了三臺機器部署 k8s master 組件。如果有條件，可以將 etcd 和 master 中的其他組件分開部署，這樣可以根據需要更靈活地控制實例個數。例如，在訪問壓力不大但對數據可靠性要求比較高的情況下，可以專門選擇 5 臺機器部署 etcd，另外選擇 3 臺機器部署 master 中的其他組件。

剩余四臺機器作為 k8s worker 節點。節點個數需要根據實際情況動態調整。當有 pod 因資源不足一直處于 pending 狀態時，可以對 worker 進行擴容。當 node 的資源利用率較低時，且此 node 上存在的 pod 都能被重新調度到其他 node 上運行時，可以對 worker 進行縮容。

環境準備

在完成節點規劃后，需要進行環境準備工作，主要包含以下內容：

安裝 RKE - 需要在部署節點（192.168.0.10）上安裝 RKE 二進制包，具體安裝方法可參考?download-the-rke-binary。

配置 SSH 免密登錄 - 由于 RKE 通過 SSH tunnel 安裝部署 k8s 集群，需要配置 RKE 所在節點到 k8s 各節點的 SSH 免密登錄。如果 RKE 所在節點也需要加入到 k8s 集群中，需要配置到本機的 SSH 免密登錄。

安裝 docker - 由于 RKE 通過 docker 鏡像rancher/hyperkube啟動 k8s 組件，因此需要在 k8s 集群的各個節點（192.168.0.11 ~ 192.168.0.17 這 7 臺機器）上安裝 docker。

關閉 swap - k8s 1.8 開始要求關閉系統的 swap，如果不關閉，默認配置下 kubelet 將無法啟動。這里需要關閉所有 k8s worker 節點的 swap。

配置 cluster.yml

在完成環境準備后，需要通過 cluster.yml 描述集群的組成和 k8s 的部署方式。

配置集群組成

配置文件 cluster.yml 中的 nodes 配置項用于描述集群的組成。根據節點規劃，對于 k8s master 節點，指定其角色為controlplane和etcd。對于 k8s worker 節點，指定其角色為worker。

nodes:- address: 192.168.0.1user: adminrole:- controlplane- etcd...- address: 192.168.0.7user: adminrole:- worker

設置資源預留

K8s 的 worker node 除了運行 pod 類進程外，還會運行很多其他的重要進程，包括 k8s 管理進程，如 kubelet、dockerd，以及系統進程，如 systemd。這些進程對整個集群的穩定性至關重要，因此需要為他們專門預留一定的資源。

筆者環境中的 worker 設置如下：

• 節點擁有 32 核 CPU，64Gi 內存和 100Gi 存儲。
• 為 k8s 管理進程預留了 1 核 CPU，2Gi 內存和 1Gi 存儲。
• 為系統進程預留了 1 核 CPU，1Gi 內存和 1Gi 存儲。
• 為內存資源設置了 500Mi 的驅逐閾值，為磁盤資源設置了 10% 的驅逐閾值。

在此場景下，節點可分配的 CPU 資源是 29 核，可分配的內存資源是 60.5Gi，可分配的磁盤資源是 88Gi。對于不可壓縮資源，當 pod 的內存使用總量超過 60.5Gi 或者磁盤使用總量超過 88Gi 時，QoS 較低的 pod 將被優先驅逐。對于可壓縮資源，如果節點上的所有進程都盡可能多的使用 CPU，則 pod 類進程加起來不會使用超過 29 核的 CPU 資源。

上述資源預留設置在 cluster.yml 中具體形式如下。

services:kubelet:extra_args:cgroups-per-qos: Truecgroup-driver: cgroupfskube-reserved: cpu=1,memory=2Gi,ephemeral-storage=1Gikube-reserved-cgroup: /runtime.servicesystem-reserved: cpu=1,memory=1Gi,ephemeral-storage=1Gisystem-reserved-cgroup: /system.sliceenforce-node-allocatable: pods,kube-reserved,system-reservedeviction-hard: memory.available<500Mi,nodefs.available<10%

關于資源預留更詳細的內容可參考文章?Reserve Compute Resources for System Daemons。

部署 k8s 集群

當 cluster.yml 文件配置完成后，可以通過命令rke up完成集群的部署任務。下圖展示了通過 RKE 部署的 k8s 集群架構圖。

該架構有如下特點：

集群中的各個組件均通過容器方式啟動，并且設置重啟策略為always。這樣當他們出現故障意外退出后，能被自動拉起。

Master 節點上的 kube-scheduler、kube-controller-manager 直接和本機的 API server 通信。

Worker 節點上的 nginx-proxy 擁有 API server 的地址列表，負責代理 kubelet、kube-proxy 發往 API server 的請求。

為了讓集群具有災備能力，master 節點上的 etcd-rolling-snapshots 會定期保存 etcd 的快照至本地目錄/opt/rke/etcd-snapshots中。

配置負載均衡器

在完成了集群部署后，可以通過 API server 訪問 k8s。由于環境中啟動了多個 kube-apiserver 實例以實現高可用，需要為這些實例架設一個負載均衡器。這里在192.168.0.10上部署了一臺 nginx 實現了負載均衡的功能，nginx.conf 的具體配置如下。

... stream {upstream apiserver {server 192.168.0.11:6443 weight=5 max_fails=3 fail_timeout=60s;server 192.168.0.12:6443 weight=5 max_fails=3 fail_timeout=60s;server 192.168.0.13:6443 weight=5 max_fails=3 fail_timeout=60s;}server {listen 6443;proxy_connect_timeout 1s;proxy_timeout 10s;proxy_pass apiserver;} } ...

這時，通過負載均衡器提供的端口訪問 API server 會出現異常Unable to connect to the server: x509: certificate is valid for xxx, not 192.168.0.10。這里需要將負載均衡器的 IP 地址或域名加入到 API server 的 PKI 證書中，可以通過 cluster.yml 中的 authentication 配置項完成此功能。

authentication:strategy: x509sans:- "192.168.0.10"

修改完 cluster.yml 后，運行命令rke cert-rotate。

驗證

在完成上述所有步驟后，可以通過命令kubectl get nodes查看節點狀態。如果所有節點的狀態均為 Ready，則表示集群部署成功。

NAME STATUS ROLES AGE VERSION 192.168.0.11 Ready controlplane,etcd 1d v1.13.5 192.168.0.12 Ready controlplane,etcd 1d v1.13.5 192.168.0.13 Ready controlplane,etcd 1d v1.13.5 192.168.0.14 Ready worker 1d v1.13.5 192.168.0.15 Ready worker 1d v1.13.5 192.168.0.16 Ready worker 1d v1.13.5 192.168.0.17 Ready worker 1d v1.13.5

總結

Rancher Kubernetes Engine（RKE）為用戶屏蔽了創建 k8s 集群的復雜細節，簡化了部署步驟，降低了構建門檻。對于那些有自建 k8s 集群需求的企業是一個不錯的選擇。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的高可用 kubernetes 集群部署实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。