本文獨立博客閱讀地址:https://ryan4yin.space/posts/kubernetes-deployment-using-kubeadm/
本文由個人筆記 ryan4yin/knowledge 整理而來,不保證正確
本文由個人筆記 ryan4yin/knowledge 整理而來,不保證正確
本地 Kubernetes 集群安裝工具
雲上的 Kubernetes 集群,基本上各雲廠商都支持一鍵部署。這里主要關注本地部署,或者叫做裸機(baremetal)部署
本文介紹的方法適合開發測試使用,安全性、穩定性、長期可用性等方案都可能還有問題。
kubernetes 是一個組件化的系統,安裝過程有很大的靈活性,很多組件都有多種實現,這些實現各有特點,讓初學者眼花繚亂。
而且要把這些組件一個個安裝配置好並且能協同工作,也是很不容易的。
因此社區出現了各種各樣的安裝方案,下面介紹下幾種支持裸機(Baremetal)部署的工具:
- kubeadm: 社區的集群安裝工具,目前已經很成熟了。
- 使用難度:簡單
- k3s: 輕量級 kubernetes,資源需求小,部署非常簡單,適合開發測試用或者邊緣環境
- 支持 airgap 離線部署
- 使用難度:超級簡單
- alibaba/sealer: 支持將整個 kubernetes 打包成一個鏡像進行交付,而且部署也非常簡單。
- 使用難度:超級簡單
- 這個項目目前還在發展中,不過貌似已經有很多 toB 的公司在使用它進行 k8s 應用的交付了。
- kubespray: 適合自建生產級別的集群,是一個大而全的 kubernetes 安裝方案,自動安裝容器運行時、k8s、網絡插件等組件,而且各組件都有很多方案可選,但是感覺有點復雜。
- 使用難度:中等
- 支持 airgap 離線部署,但是以前我試用過是有坑,現在不知道咋樣了
- 底層使用了 kubeadm 部署集群
- sealos: 也很方便,一行命令部署
- 其他社區部署方案
- 自己寫腳本,使用各組件的二進制文件進行部署。
筆者為了學習 Kubernetes,下面采用官方的 kubeadm 進行部署,容器運行時使用 containerd,網絡插件則使用目前最潮的基於 eBPF 的 Cilium.
kubernetes 官方介紹了兩種高可用集群的拓撲結構:「堆疊 Etcd 拓撲(Stacked Etcd Topology)」和「外部 Etcd 拓撲(External Etcd Topology)」。
「堆疊 Etcd 拓撲」是指 Etcd 跟 Kubernetes Master 的其他組件部署在同一節點上,而「外部 Etcd 拓撲(External Etcd Topology)」則是指 Etcd 單獨部署,與 Kubernetes Master 分開。
簡單起見,本文使用「堆疊 Etcd 拓撲」結構,創建一個 3 master 的高可用集群。
參考:
- Kubernetes Docs - Installing kubeadm
- Kubernetes Docs - Creating Highly Available clusters with kubeadm
0. 網絡環境的准備
本文行文未考慮國內網絡環境,但是 Kubernetes 用到的很多鏡像都在 gcr.io 上,在國內訪問會有困難。
如果對可靠性要求高,最好是自建私有鏡像倉庫,把鏡像推送到私有倉庫。可以通過如下命令列出所有 kubeadm 需要用到的鏡像地址:
❯ kubeadm config images list --kubernetes-version v1.22.1
k8s.gcr.io/kube-apiserver:v1.22.1
k8s.gcr.io/kube-controller-manager:v1.22.1
k8s.gcr.io/kube-scheduler:v1.22.1
k8s.gcr.io/kube-proxy:v1.22.1
k8s.gcr.io/pause:3.5
k8s.gcr.io/etcd:3.5.0-0
k8s.gcr.io/coredns/coredns:v1.8.4
這里提供三個解決辦法:
- 在家庭路由器上整個代理,實現全局科學的上網。(我就是這么干的)
- 使用 liangyuanpeng 大佬在評論區提供的 gcr 國內鏡像地址,這需要進行如下替換:
- k8s.gcr.io---> lank8s.cn
- 自己維護一個國內鏡像倉庫(或私有鏡像倉庫如 harbor),使用
skopeo
等工具或腳本將上述鏡像列表拷貝到你的私有倉庫
1. 節點的環境准備
首先准備三台 Linux 虛擬機,系統按需選擇,然后調整這三台機器的設置:
- 節點配置:
- master:不低於 2c/3g,硬盤 20G
- 主節點性能也受集群 Pods 個數的影響,上述配置應該可以支撐到每個 Worker 節點跑 100 個 Pod.
- worker:看需求,建議不低於 2c/4g,硬盤不小於 20G,資源充分的話建議 40G 以上。
- master:不低於 2c/3g,硬盤 20G
- 處於同一網絡內並可互通(通常是同一局域網)
- 各主機的 hostname 和 mac/ip 地址以及
/sys/class/dmi/id/product_uuid
,都必須唯一- 這里新手最容易遇到的問題,是 hostname 沖突
- 必須關閉 swap 交換內存,kubelet 才能正常工作
方便起見,我直接使用 ryan4yin/pulumi-libvirt 自動創建了五個 opensuse leap 15.3 虛擬機,並設置好了 ip/hostname.
1.1 iptables 設置
目前 kubernetes 的容器網絡,默認使用的是 bridge 模式,這種模式下,需要使 iptables
能夠接管 bridge 上的流量。
配置如下:
sudo modprobe br_netfilter
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system
1.2 開放節點端口
局域網環境的話,建議直接關閉防火牆。這樣所有端口都可用,方便快捷。
通常我們的雲上集群,也是關閉防火牆的,只是會通過雲服務提供的「安全組」來限制客戶端 ip
Control-plane 節點,也就是 master,需要開放如下端口:
Protocol | Direction | Port Range | Purpose | Used By |
---|---|---|---|---|
TCP | Inbound | 6443* | Kubernetes API server | All |
TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd |
TCP | Inbound | 10250 | kubelet API | Self, Control plane |
TCP | Inbound | 10251 | kube-scheduler | Self |
TCP | Inbound | 10252 | kube-controller-manager | Self |
Worker 節點需要開發如下端口:
Protocol | Direction | Port Range | Purpose | Used By |
---|---|---|---|---|
TCP | Inbound | 10250 | kubelet API | Self, Control plane |
TCP | Inbound | 30000-32767 | NodePort Services† | All |
另外通常我們本地測試的時候,可能更想直接在 80
443
8080
等端口上使用 NodePort
,
就需要修改 kube-apiserver 的 --service-node-port-range
參數來自定義 NodePort 的端口范圍,相應的 Worker 節點也得開放這些端口。
2. 安裝 containerd
首先是環境配置:
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
nf_conntrack
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
sudo modprobe nf_conntrack
# Setup required sysctl params, these persist across reboots.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
# Apply sysctl params without reboot
sudo sysctl --system
安裝 containerd+nerdctl:
wget https://github.com/containerd/nerdctl/releases/download/v0.11.1/nerdctl-full-0.11.1-linux-amd64.tar.gz
tar -axvf nerdctl-full-0.11.1-linux-amd64.tar.gz
# 這里簡單起見,rootless 相關的東西也一起裝進去了,測試嘛就無所謂了...
mv bin/* /usr/local/bin/
mv lib/systemd/system/containerd.service /usr/lib/systemd/system/
systemctl enable containerd
systemctl start containerd
nerdctl
是一個 containerd 的命令行工具,但是它的容器、鏡像與 Kubernetes 的容器、鏡像是完全隔離的,不能互通!
目前只能通過 crictl
來查看、拉取 Kubernetes 的容器、鏡像,下一節會介紹 crictl 的安裝。
3. 安裝 kubelet/kubeadm/kubectl
# 一些全局都需要用的變量
CNI_VERSION="v0.8.2"
CRICTL_VERSION="v1.17.0"
# kubernetes 的版本號
# RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
RELEASE="1.22.1"
# kubelet 配置文件的版本號
RELEASE_VERSION="v0.4.0"
# 架構
ARCH="amd64"
# 安裝目錄
DOWNLOAD_DIR=/usr/local/bin
# CNI 插件
sudo mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
# crictl 相關工具
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
# kubelet/kubeadm/kubectl
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
sudo chmod +x {kubeadm,kubelet,kubectl}
# kubelet/kubeadm 配置
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
sudo mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
systemctl enable --now kubelet
# 驗證 kubelet 啟動起來了,但是目前還沒有初始化配置,過一陣就會重啟一次
systemctl status kubelet
試用 crictl:
export CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/containerd/containerd.sock'
# 列出所有 pods,現在應該啥也沒
crictl pods
# 列出所有鏡像
crictl images
4. 為 master 的 kube-apiserver 創建負載均衡實現高可用
根據 kubeadm 官方文檔 Kubeadm Docs - High Availability Considerations 介紹,要實現 kube-apiserver 的高可用,目前最知名的負載均衡方式是 keepalived+haproxy,另外也可以考慮使用 kube-vip 等更簡單的工具。
簡單起見,我們直接用 kube-vip 吧,參考了 kube-vip 的官方文檔:Kube-vip as a Static Pod with Kubelet.
P.S. 我也見過有的安裝工具會直接拋棄 keepalived,直接在每個節點上跑一個 nginx 做負載均衡,配置里寫死了所有 master 的地址...
首先使用如下命令生成 kube-vip 的配置文件,以 ARP 為例(生產環境建議換成 BGP):
cat <<EOF | sudo tee add-kube-vip.sh
# 你的虛擬機網卡,opensuse/centos 等都是 eth0,但是 ubuntu 可能是 ens3
export INTERFACE=eth0
# 用於實現高可用的 vip,需要和前面的網絡接口在同一網段內,否則就無法路由了。
export VIP=192.168.122.200
# 生成 static-pod 的配置文件
mkdir -p /etc/kubernetes/manifests
nerdctl run --rm --network=host --entrypoint=/kube-vip ghcr.io/kube-vip/kube-vip:v0.3.8 \
manifest pod \
--interface $INTERFACE \
--vip $VIP \
--controlplane \
--services \
--arp \
--leaderElection | tee /etc/kubernetes/manifests/kube-vip.yaml
EOF
bash add-kube-vip.sh
三個 master 節點都需要跑下上面的命令(worker 不需要),創建好 kube-vip 的 static-pod 配置文件。
在完成 kubeadm 初始化后,kubelet 會自動把它們拉起為 static pod.
5. 使用 kubeadm 創建集群
其實需要運行的就是這條命令:
# 極簡配置:
cat <<EOF | sudo tee kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
criSocket: "/var/run/containerd/containerd.sock"
imagePullPolicy: IfNotPresent
---
kind: ClusterConfiguration
apiVersion: kubeadm.k8s.io/v1beta3
kubernetesVersion: v1.22.1
clusterName: kubernetes
certificatesDir: /etc/kubernetes/pki
imageRepository: k8s.gcr.io
controlPlaneEndpoint: "192.168.122.200:6443" # 填 apiserver 的 vip 地址,或者整個域名也行,但是就得加 /etc/hosts 或者內網 DNS 解析
networking:
serviceSubnet: "10.96.0.0/16"
podSubnet: "10.244.0.0/16"
etcd:
local:
dataDir: /var/lib/etcd
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
# 讓 kubelet 從 certificates.k8s.io 申請由集群 CA Root 簽名的 tls 證書,而非直接使用自簽名證書
# 如果不啟用這個, 安裝 metrics-server 時就會遇到證書報錯,后面會詳細介紹。
serverTLSBootstrap: true
EOF
# 查看 kubeadm 默認的完整配置,供參考
kubeadm config print init-defaults > init.default.yaml
# 執行集群的初始化,這會直接將當前節點創建為 master
# 成功運行的前提:前面該裝的東西都裝好了,而且 kubelet 已經在后台運行了
# `--upload-certs` 會將生成的集群證書上傳到 kubeadm 服務器,在兩小時內加入集群的 master 節點會自動拉證書,主要是方便集群創建。
kubeadm init --config kubeadm-config.yaml --upload-certs
kubeadm 應該會報錯,提示你有些依賴不存在,下面先安裝好依賴項。
sudo zypper in -y socat ebtables conntrack-tools
再重新運行前面的 kubeadm 命令,應該就能正常執行了,它做的操作有:
- 拉取控制面的容器鏡像
- 生成 ca 根證書
- 使用根證書為 etcd/apiserver 等一票工具生成 tls 證書
- 為控制面的各個組件生成 kubeconfig 配置
- 生成 static pod 配置,kubelet 會根據這些配置自動拉起 kube-proxy 以及其他所有的 k8s master 組件
運行完會給出三部分命令:
- 將
kubeconfig
放到$HOME/.kube/config
下,kubectl
需要使用該配置文件連接 kube-apiserver - control-plane 節點加入集群的命令:
- 這里由於我們提前添加了 kube-vip 的 static-pod 配置,這里的 preflight-check 會報錯,需要添加此參數忽略該報錯 -
--ignore-preflight-errors=DirAvailable--etc-kubernetes-manifests
kubeadm join 192.168.122.200:6443 --token <token> \ --discovery-token-ca-cert-hash sha256:<hash> \ --control-plane --certificate-key <key> \ --ignore-preflight-errors=DirAvailable--etc-kubernetes-manifests
- 這里由於我們提前添加了 kube-vip 的 static-pod 配置,這里的 preflight-check 會報錯,需要添加此參數忽略該報錯 -
- worker 節點加入集群的命令:
kubeadm join 192.168.122.200:6443 --token <token> \ --discovery-token-ca-cert-hash sha256:<hash>
跑完第一部分 kubeconfig
的處理命令后,就可以使用 kubectl 查看集群狀況了:
k8s-master-0:~/kubeadm # kubectl get no
NAME STATUS ROLES AGE VERSION
k8s-master-0 NotReady control-plane,master 79s v1.22.1
k8s-master-0:~/kubeadm # kubectl get po --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-78fcd69978-6tlnw 0/1 Pending 0 83s
kube-system coredns-78fcd69978-hxtvs 0/1 Pending 0 83s
kube-system etcd-k8s-master-0 1/1 Running 6 90s
kube-system kube-apiserver-k8s-master-0 1/1 Running 4 90s
kube-system kube-controller-manager-k8s-master-0 1/1 Running 4 90s
kube-system kube-proxy-6w2bx 1/1 Running 0 83s
kube-system kube-scheduler-k8s-master-0 1/1 Running 7 97s
現在在其他節點運行前面打印出的加入集群的命令,就可以搭建好一個高可用的集群了。
所有節點都加入集群后,通過 kubectl 查看,應該是三個控制面 master,兩個 worker:
k8s-master-0:~/kubeadm # kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master-0 NotReady control-plane,master 26m v1.22.1
k8s-master-1 NotReady control-plane,master 7m2s v1.22.1
k8s-master-2 NotReady control-plane,master 2m10s v1.22.1
k8s-worker-0 NotReady <none> 97s v1.22.1
k8s-worker-1 NotReady <none> 86s v1.22.1
現在它們都還處於 NotReady 狀態,需要等到我們把網絡插件安裝好,才會 Ready.
現在再看下集群的證書簽發狀態:
❯ kubectl get csr --sort-by='{.spec.username}'
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
csr-95hll 6m58s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q8ivnz <none> Approved,Issued
csr-tklnr 7m5s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q8ivnz <none> Approved,Issued
csr-w92jv 9m15s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q8ivnz <none> Approved,Issued
csr-rv7sj 8m11s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q8ivnz <none> Approved,Issued
csr-nxkgx 10m kubernetes.io/kube-apiserver-client-kubelet system:node:k8s-master-0 <none> Approved,Issued
csr-cd22c 10m kubernetes.io/kubelet-serving system:node:k8s-master-0 <none> Pending
csr-wjrnr 9m53s kubernetes.io/kubelet-serving system:node:k8s-master-0 <none> Pending
csr-sjq42 9m8s kubernetes.io/kubelet-serving system:node:k8s-master-1 <none> Pending
csr-xtv8f 8m56s kubernetes.io/kubelet-serving system:node:k8s-master-1 <none> Pending
csr-f2dsf 8m3s kubernetes.io/kubelet-serving system:node:k8s-master-2 <none> Pending
csr-xl8dg 6m58s kubernetes.io/kubelet-serving system:node:k8s-worker-0 <none> Pending
csr-p9g24 6m52s kubernetes.io/kubelet-serving system:node:k8s-worker-1 <none> Pending
能看到有好幾個 kubernetes.io/kubelet-serving
的證書還處於 pending 狀態,
這是因為我們在 kubeadm 配置文件中,設置了 serverTLSBootstrap: true
,讓 Kubelet 從集群中申請 CA 簽名證書,而不是自簽名導致的。
設置這個參數的主要目的,是為了讓 metrics-server 等組件能使用 https 協議與 kubelet 通信,避免為 metrics-server 添加參數 --kubelet-insecure-tls
.
目前 kubeadm 不支持自動批准 kubelet 申請的證書,需要我們手動批准一下:
# 批准 Kubelet 申請的所有證書
kubectl certificate approve csr-cd22c csr-wjrnr csr-sjq42 csr-xtv8f csr-f2dsf csr-xl8dg csr-p9g24
在未批准這些證書之前,所有需要調用 kubelet api 的功能都將無法使用,比如:
- 查看 pod 日志
- 獲取節點 metrics
- 等等
5.1 常見問題
5.1.1 重置集群配置
創建集群的過程中出現任何問題,都可以通過在所有節點上運行 kubeadm reset
來還原配置,然后重新走 kubeadm 的集群創建流程。
但是要注意幾點:
kubeadm reset
會清除包含 kube-vip 配置在內的所有 static-pod 配置文件,所以 master 節點需要重新跑下前面給的 kube-vip 命令,生成下 kube-vip 配置。kubeadm reset
不會重置網絡接口的配置,master 節點需要手動清理下 kube-vip 添加的 vip:ip addr del 192.168.122.200/32 dev eth0
.- 如果你在安裝了網絡插件之后希望重裝集群,順序如下:
- 通過
kubectl delete -f xxx.yaml
/helm uninstall
刪除所有除網絡之外的其他應用配置 - 刪除網絡插件
- 先重啟一遍所有節點,或者手動重置所有節點的網絡配置
- 建議重啟,因為我不知道該怎么手動重置... 試了
systemctl restart network
並不會清理所有虛擬網絡接口。
- 建議重啟,因為我不知道該怎么手動重置... 試了
- 通過
如此操作后,再重新執行集群安裝,應該就沒啥毛病了。
6. 驗證集群的高可用性
雖然網絡插件還沒裝導致集群所有節點都還沒 ready,但是我們已經可以通過 kubectl 命令來簡單驗證集群的高可用性了。
首先,我們將前面放置在 k8s-master-0 的認證文件 $HOME/.kube/config
以及 kunbectl 安裝在另一台機器上,比如我直接放我的宿主機。
然后在宿主機上跑 kubectl get node
命令驗證集群的高可用性:
- 三個主節點都正常運行時,kubectl 命令也正常
- pause 或者 stop 其中一個 master,kubectl 命令仍然能正常運行
- 再 pause 第二個 master,kubectl 命令應該就會卡住,並且超時,無法使用了
- resume 恢復停掉的兩個 master 之一,會發現 kubectl 命令又能正常運行了
到這里 kubeadm 的工作就完成了,接下來再安裝網絡插件,集群就可用了。
7. 安裝網絡插件
社區有很多種網絡插件可選,比較知名且性能也不錯的,應該是 Calico 和 Cilium,其中 Cilium 主打基於 eBPF 的高性能與高可觀測性。
下面分別介紹這兩個插件的安裝方法。(注意只能安裝其中一個網絡插件,不能重復安裝。)
需要提前在本機安裝好 helm,我這里使用宿主機,因此只需要在宿主機安裝:
# 一行命令安裝,也可以自己手動下載安裝包,都行
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
# 或者 opensuse 直接用包管理器安裝
sudo zypper in helm
7.1 安裝 Cilium
官方文檔:https://docs.cilium.io/en/v1.10/gettingstarted/k8s-install-kubeadm/
cilium 通過 eBPF 提供了高性能與高可觀測的 k8s 集群網絡,
另外 cilium 還提供了比 kube-proxy 更高效的實現,可以完全替代 kube-proxy.
這里我們還是先使用 kube-proxy 模式,先熟悉下 cilium 的使用:
helm repo add cilium https://helm.cilium.io/
helm search repo cilium/cilium -l | head
helm install cilium cilium/cilium --version 1.10.4 --namespace kube-system
可以通過 kubectl get pod -A
查看 cilium 的安裝進度,當所有 pod 都 ready 后,集群就 ready 了~
cilium 也提供了專用的客戶端:
curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-amd64.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz{,.sha256sum}
然后使用 cilium 客戶端檢查網絡插件的狀態:
$ cilium status --wait
/¯¯\
/¯¯\__/¯¯\ Cilium: OK
\__/¯¯\__/ Operator: OK
/¯¯\__/¯¯\ Hubble: disabled
\__/¯¯\__/ ClusterMesh: disabled
\__/
DaemonSet cilium Desired: 5, Ready: 5/5, Available: 5/5
Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2
Containers: cilium Running: 5
cilium-operator Running: 2
Cluster Pods: 2/2 managed by Cilium
Image versions cilium quay.io/cilium/cilium:v1.10.4@sha256:7d354052ccf2a7445101d78cebd14444c7c40129ce7889f2f04b89374dbf8a1d: 5
cilium-operator quay.io/cilium/operator-generic:v1.10.4@sha256:c49a14e34634ff1a494c84b718641f27267fb3a0291ce3d74352b44f8a8d2f93: 2
cilium 還提供了命令,自動創建 pod 進行集群網絡的連接性測試:
❯ cilium connectivity test
ℹ️ Monitor aggregation detected, will skip some flow validation steps
✨ [kubernetes] Creating namespace for connectivity check...
✨ [kubernetes] Deploying echo-same-node service...
✨ [kubernetes] Deploying same-node deployment...
✨ [kubernetes] Deploying client deployment...
✨ [kubernetes] Deploying client2 deployment...
✨ [kubernetes] Deploying echo-other-node service...
✨ [kubernetes] Deploying other-node deployment...
...
ℹ️ Expose Relay locally with:
cilium hubble enable
cilium status --wait
cilium hubble port-forward&
🏃 Running tests...
...
---------------------------------------------------------------------------------------------------------------------
✅ All 11 tests (134 actions) successful, 0 tests skipped, 0 scenarios skipped.
通過 kubectl get po -A
能觀察到,這個測試命令會自動創建一個 cilium-test
名字空間,並在啟動創建若干 pod 進行詳細的測試。
整個測試流程大概會持續 5 分多鍾,測試完成后,相關 Pod 不會自動刪除,使用如下命令手動刪除:
kubectl delete namespace cilium-test
7.2 安裝 Calico
官方文檔:https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises
也就兩三行命令。安裝確實特別簡單,懶得介紹了,看官方文檔吧。
但是實際上 calico 的細節還蠻多的,建議通讀下它的官方文檔,了解下 calico 的架構。
8. 查看集群狀態
官方的 dashboard 個人感覺不太好用,建議直接在本地裝個 k9s 用,特別爽。
sudo zypper in k9s
然后就可以愉快地玩耍了。
9. 安裝 metrics-server
這一步可能遇到的問題:Enabling signed kubelet serving certificates
如果需要使用 HPA 以及簡單的集群監控,那么 metrics-server 是必須安裝的,現在我們安裝一下它。
首先,跑 kubectl 的監控命令應該會報錯:
❯ kubectl top node
error: Metrics API not available
k9s 里面應該也看不到任何監控指標。
現在通過 helm 安裝它:
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm search repo metrics-server/metrics-server -l | head
helm upgrade --install metrics-server metrics-server/metrics-server --version 3.5.0 --namespace kube-system
metrics-server 默認只會部署一個實例,如果希望高可用,請參考官方配置:metrics-server - high-availability manifests
等 metrics-server 啟動好后,就可以使用 kubectl top
命令啦:
❯ kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8s-master-0 327m 16% 1465Mi 50%
k8s-master-1 263m 13% 1279Mi 44%
k8s-master-2 289m 14% 1282Mi 44%
k8s-worker-0 62m 3% 518Mi 13%
k8s-worker-1 115m 2% 659Mi 8%
❯ kubectl top pod
No resources found in default namespace.
❯ kubectl top pod -A
NAMESPACE NAME CPU(cores) MEMORY(bytes)
kube-system cilium-45nw4 9m 135Mi
kube-system cilium-5x7jf 6m 154Mi
kube-system cilium-84sr2 7m 160Mi
kube-system cilium-operator-78f45675-dp4b6 2m 30Mi
kube-system cilium-operator-78f45675-fpm5g 1m 30Mi
kube-system cilium-tkhl4 6m 141Mi
kube-system cilium-zxbvm 5m 138Mi
kube-system coredns-78fcd69978-dpxxk 3m 16Mi
kube-system coredns-78fcd69978-ptd9p 1m 18Mi
kube-system etcd-k8s-master-0 61m 88Mi
kube-system etcd-k8s-master-1 50m 85Mi
kube-system etcd-k8s-master-2 55m 83Mi
kube-system kube-apiserver-k8s-master-0 98m 462Mi
kube-system kube-apiserver-k8s-master-1 85m 468Mi
kube-system kube-apiserver-k8s-master-2 85m 423Mi
kube-system kube-controller-manager-k8s-master-0 22m 57Mi
kube-system kube-controller-manager-k8s-master-1 2m 23Mi
kube-system kube-controller-manager-k8s-master-2 2m 23Mi
kube-system kube-proxy-j2s76 1m 24Mi
kube-system kube-proxy-k6d6z 1m 18Mi
kube-system kube-proxy-k85rx 1m 23Mi
kube-system kube-proxy-pknsc 1m 20Mi
kube-system kube-proxy-xsq4m 1m 15Mi
kube-system kube-scheduler-k8s-master-0 3m 25Mi
kube-system kube-scheduler-k8s-master-1 4m 21Mi
kube-system kube-scheduler-k8s-master-2 5m 21Mi
kube-system kube-vip-k8s-master-0 4m 17Mi
kube-system kube-vip-k8s-master-1 2m 16Mi
kube-system kube-vip-k8s-master-2 2m 17Mi
kube-system metrics-server-559f85484-5b6xf 7m 27Mi
10. 為 etcd 添加定期備份能力
請移步 etcd 的備份與恢復
11. 安裝 Volume Provisioner
在我們學習使用 Prometheus/MinIO/Tekton 等有狀態應用時,它們默認情況下會通過 PVC 聲明需要的數據卷。
為了支持這個能力,我們需要在集群中部署一個 Volume Provisioner.
對於雲上環境,直接接入雲服務商提供的 Volume Provisioner 就 OK 了,方便省事而且足夠可靠。
而對於 bare-metal 環境,比較有名的應該是 rook-ceph,但是這個玩意部署復雜,維護難度又高,不適合用來測試學習。
對於開發、測試環境,或者個人集群,建議使用:
- local 數據卷,適合數據可丟失,且不要求分布式的場景,如開發測試環境
- NFS 數據卷,適合數據可丟失,對性能要求不高,並且要求分布式的場景。比如開發測試環境、或者線上沒啥壓力的應用
- https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
- https://github.com/kubernetes-csi/csi-driver-nfs
- NFS 數據的可靠性依賴於外部 NFS 服務器,企業通常使用群暉等 NAS 來做 NFS 服務器
- 如果外部 NFS 服務器出問題,應用就會崩。
- 直接使用雲上的對象存儲,適合希望數據不丟失、對性能要求不高的場景。
- 直接使用 https://github.com/rclone/rclone mount 模式來保存數據,或者直接同步文件夾數據到雲端(可能會有一定數據丟失)。