本文独立博客阅读地址：https://ryan4yin.space/posts/kubernetes-deployemnt-using-kubeadm/
本文由个人笔记 ryan4yin/knowledge 整理而来，不保证正确
云上的 Kubernetes 集群，基本上各云厂商都支持一键部署。这里主要关注本地部署，或者叫做裸机(baremetal)部署
本文介绍的方法适合开发测试使用，安全性、稳定性、长期可用性等方案都可能还有问题。
本文主要参考官方文档，与其他大部分的集群安装文档，内容应该都差不多。不过会多提几句 metrics-server(HPA 需要)、etcd 备份、volume provider(如果你需要 PV)相关内容.
本文未考虑国内网络环境，建议在路由器上整个科学代理，或者自行调整文中的部分命令。
kubernetes 是一个组件化的系统，安装过程有很大的灵活性，很多组件都有多种实现，这些实现各有特点，让初学者眼花缭乱。
而且要把这些组件一个个安装配置好并且能协同工作，也是很不容易的。
因此社区出现了各种各样的安装方案，下面介绍下几种支持裸机（Baremetal）部署的工具：
笔者为了学习 Kubernetes，下面采用官方的 kubeadm 进行部署（不要问为啥不二进制部署，问就是懒），容器运行时使用 containerd，网络插件则使用目前最潮的基于 eBPF 的 Cilium.
kubernetes 官方介绍了两种高可用集群的拓扑结构：「Stacked etcd topology」和「External etcd topology」，简单起见，本文使用第一种「堆叠 Etcd 拓扑」结构，创建一个三 master 的高可用集群。
参考：
首先准备三台 Linux 虚拟机，系统按需选择，然后调整这三台机器的设置：
/sys/class/dmi/id/product_uuid，都必须唯一方便起见，我直接使用 ryan4yin/pulumi-libvirt 自动创建了五个虚拟机，并设置好了 ip/hostname.
本文使用了 opensuse leap 15.3 的 KVM cloud image 进行安装测试。
目前 kubernetes 的容器网络，默认使用的是 bridge 模式，这种模式下，需要使 iptables 能够接管 bridge 上的流量。
配置如下：
sudo modprobe br_netfiltercat <<EOF | sudo tee /etc/modules-load.d/k8s.confbr_netfilterEOFcat <<EOF | sudo tee /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1EOFsudo sysctl --system局域网环境的话，建议直接关闭防火墙。这样所有端口都可用，方便快捷。
通常我们的云上集群，也是关闭防火墙的，只是会通过云服务提供的「安全组」来限制客户端 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 节点也得开放这些端口。
首先是环境配置：
cat <<EOF | sudo tee /etc/modules-load.d/containerd.confoverlaybr_netfilternf_conntrackEOFsudo modprobe overlaysudo modprobe br_netfiltersudo modprobe nf_conntrack# Setup required sysctl params, these persist across reboots.cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.confnet.bridge.bridge-nf-call-iptables = 1net.ipv4.ip_forward = 1net.bridge.bridge-nf-call-ip6tables = 1EOF# Apply sysctl params without rebootsudo sysctl --system安装 containerd+nerdctl:
wget https://github.com/containerd/nerdctl/releases/download/v0.11.1/nerdctl-full-0.11.1-linux-amd64.tar.gztar -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 containerdsystemctl start containerdnerdctl 是一个 containerd 的命令行工具，但是它的容器、镜像与 Kubernetes 的容器、镜像是完全隔离的，不能互通！
目前只能通过 crictl 来查看、拉取 Kubernetes 的容器、镜像，下一节会介绍 crictl 的安装。
# 一些全局都需要用的变量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/bincurl -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/kubectlcd $DOWNLOAD_DIRsudo 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.servicesudo mkdir -p /etc/systemd/system/kubelet.service.dcurl -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.confsystemctl enable --now kubelet# 验证 kubelet 启动起来了，但是目前还没有初始化配置，过一阵就会重启一次systemctl status kubelet试用 crictl:
export CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/containerd/containerd.sock'# 列出所有 pods，现在应该啥也没crictl pods# 列出所有镜像crictl images根据 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 可能是 ens3export INTERFACE=eth0# 用于实现高可用的 vip，需要和前面的网络接口在同一网段内，否则就无法路由了。export VIP=192.168.122.200# 生成 static-pod 的配置文件mkdir -p /etc/kubernetes/manifestsnerdctl 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.yamlEOFbash add-kube-vip.sh三个 master 节点都需要跑下上面的命令（worker 不需要），创建好 kube-vip 的 static-pod 配置文件。
在完成 kubeadm 初始化后，kubelet 会自动把它们拉起为 static pod.
其实需要运行的就是这条命令：
# 极简配置：cat <<EOF | sudo tee kubeadm-config.yamlapiVersion: kubeadm.k8s.io/v1beta3kind: InitConfigurationnodeRegistration: criSocket: "/var/run/containerd/containerd.sock" imagePullPolicy: IfNotPresent---kind: ClusterConfigurationapiVersion: kubeadm.k8s.io/v1beta3kubernetesVersion: v1.22.1clusterName: kubernetescertificatesDir: /etc/kubernetes/pkiimageRepository: k8s.gcr.iocontrolPlaneEndpoint: "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/v1beta1kind: KubeletConfigurationcgroupDriver: systemd# 让 kubelet 从 certificates.k8s.io 申请由集群 CA Root 签名的 tls 证书，而非直接使用自签名证书# 如果不启用这个， 安装 metrics-server 时就会遇到证书报错，后面会详细介绍。serverTLSBootstrap: trueEOF# 查看 kubeadm 默认的完整配置，供参考kubeadm config print init-defaults > init.default.yaml# 执行集群的初始化，这会直接将当前节点创建为 master# 成功运行的前提：前面该装的东西都装好了，而且 kubelet 已经在后台运行了# `--upload-certs` 会将生成的集群证书上传到 kubeadm 服务器，在两小时内加入集群的 master 节点会自动拉证书，主要是方便集群创建。kubeadm init --config kubeadm-config.yaml --upload-certskubeadm 应该会报错，提示你有些依赖不存在，下面先安装好依赖项。
sudo zypper in -y socat ebtables conntrack-tools再重新运行前面的 kubeadm 命令，应该就能正常执行了，它做的操作有：
运行完会给出三部分命令：
kubeconfig 放到 $HOME/.kube/config 下，kubectl 需要使用该配置文件连接 kube-apiserver--ignore-preflight-errors=DirAvailable--etc-kubernetes-manifestskubeadm 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-manifestskubeadm join 192.168.122.200:6443 --token <token> \ --discovery-token-ca-cert-hash sha256:<hash> 跑完第一部分 kubeconfig 的处理命令后，就可以使用 kubectl 查看集群状况了：
k8s-master-0:~/kubeadm # kubectl get noNAME STATUS ROLES AGE VERSIONk8s-master-0 NotReady control-plane,master 79s v1.22.1k8s-master-0:~/kubeadm # kubectl get po --all-namespacesNAMESPACE NAME READY STATUS RESTARTS AGEkube-system coredns-78fcd69978-6tlnw 0/1 Pending 0 83skube-system coredns-78fcd69978-hxtvs 0/1 Pending 0 83skube-system etcd-k8s-master-0 1/1 Running 6 90skube-system kube-apiserver-k8s-master-0 1/1 Running 4 90skube-system kube-controller-manager-k8s-master-0 1/1 Running 4 90skube-system kube-proxy-6w2bx 1/1 Running 0 83skube-system kube-scheduler-k8s-master-0 1/1 Running 7 97s现在在其他节点运行前面打印出的加入集群的命令，就可以搭建好一个高可用的集群了。
所有节点都加入集群后，通过 kubectl 查看，应该是三个控制面 master，两个 worker：
k8s-master-0:~/kubeadm # kubectl get nodeNAME STATUS ROLES AGE VERSIONk8s-master-0 NotReady control-plane,master 26m v1.22.1k8s-master-1 NotReady control-plane,master 7m2s v1.22.1k8s-master-2 NotReady control-plane,master 2m10s v1.22.1k8s-worker-0 NotReady <none> 97s v1.22.1k8s-worker-1 NotReady <none> 86s v1.22.1现在它们都还处于 NotReady 状态，需要等到我们把网络插件安装好，才会 Ready.
现在再看下集群的证书签发状态：
? kubectl get csr --sort-by='{.spec.username}'NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITIONcsr-95hll 6m58s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q8ivnz <none> Approved,Issuedcsr-tklnr 7m5s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q8ivnz <none> Approved,Issuedcsr-w92jv 9m15s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q8ivnz <none> Approved,Issuedcsr-rv7sj 8m11s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:q8ivnz <none> Approved,Issuedcsr-nxkgx 10m kubernetes.io/kube-apiserver-client-kubelet system:node:k8s-master-0 <none> Approved,Issuedcsr-cd22c 10m kubernetes.io/kubelet-serving system:node:k8s-master-0 <none> Pendingcsr-wjrnr 9m53s kubernetes.io/kubelet-serving system:node:k8s-master-0 <none> Pendingcsr-sjq42 9m8s kubernetes.io/kubelet-serving system:node:k8s-master-1 <none> Pendingcsr-xtv8f 8m56s kubernetes.io/kubelet-serving system:node:k8s-master-1 <none> Pendingcsr-f2dsf 8m3s kubernetes.io/kubelet-serving system:node:k8s-master-2 <none> Pendingcsr-xl8dg 6m58s kubernetes.io/kubelet-serving system:node:k8s-worker-0 <none> Pendingcsr-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 的功能都将无法使用，比如：
如果你没有科学环境，kubeadm 默认的镜像仓库在国内是拉不了的。
如果对可靠性要求高，最好是自建私有镜像仓库，把镜像推送到私有仓库。
可以通过如下命令列出所有需要用到的镜像地址：
? kubeadm config images list --kubernetes-version v1.22.1k8s.gcr.io/kube-apiserver:v1.22.1k8s.gcr.io/kube-controller-manager:v1.22.1k8s.gcr.io/kube-scheduler:v1.22.1k8s.gcr.io/kube-proxy:v1.22.1k8s.gcr.io/pause:3.5k8s.gcr.io/etcd:3.5.0-0k8s.gcr.io/coredns/coredns:v1.8.4使用 skopeo 等工具或脚本将上述镜像拷贝到你的私有仓库，或者图方便（测试环境）也可以考虑网上找找别人同步好的镜像地址。将镜像地址添加到 kubeadm-config.yaml 中再部署。
创建集群的过程中出现任何问题，都可以通过在所有节点上运行 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 并不会清理所有虚拟网络接口。如此操作后，再重新执行集群安装，应该就没啥毛病了。
虽然网络插件还没装导致集群所有节点都还没 ready，但是我们已经可以通过 kubectl 命令来简单验证集群的高可用性了。
首先，我们将前面放置在 k8s-master-0 的认证文件 $HOME/.kube/config 以及 kunbectl 安装在另一台机器上，比如我直接放我的宿主机。
然后在宿主机上跑 kubectl get node 命令验证集群的高可用性：
到这里 kubeadm 的工作就完成了，接下来再安装网络插件，集群就可用了。
社区有很多种网络插件可选，比较知名且性能也不错的，应该是 Calico 和 Cilium，其中 Cilium 主打基于 eBPF 的高性能与高可观测性。
下面分别介绍这两个插件的安装方法。（注意只能安装其中一个网络插件，不能重复安装。）
需要提前在本机安装好 helm，我这里使用宿主机，因此只需要在宿主机安装:
# 一行命令安装，也可以自己手动下载安装包，都行curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash# 或者 opensuse 直接用包管理器安装sudo zypper in helm官方文档：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 | headhelm 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.sha256sumsudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/binrm 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/5Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2Containers: cilium Running: 5 cilium-operator Running: 2Cluster Pods: 2/2 managed by CiliumImage versions cilium quay.io/cilium/cilium:v1.10.4@sha256:7d354052ccf2a7445101d78cebd14444c7c40129ce7889f2f04b89374dbf8a1d: 5 cilium-operator quay.io/cilium/operator-generic:v1.10.4@sha256:c49a14e34634ff1a494c84b718641f27267fb3a0291ce3d74352b44f8a8d2f93: 2cilium 还提供了命令，自动创建 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官方文档：https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises
也就两三行命令。安装确实特别简单，懒得介绍了，看官方文档吧。
但是实际上 calico 的细节还蛮多的，建议通读下它的官方文档，了解下 calico 的架构。
官方的 dashboard 个人感觉不太好用，建议直接在本地装个 k9s 用，特别爽。
sudo zypper in k9s然后就可以愉快地玩耍了。
这一步可能遇到的问题：Enabling signed kubelet serving certificates
如果需要使用 HPA 以及简单的集群监控，那么 metrics-server 是必须安装的，现在我们安装一下它。
首先，跑 kubectl 的监控命令应该会报错：
? kubectl top nodeerror: Metrics API not availablek9s 里面应该也看不到任何监控指标。
现在通过 helm 安装它：
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/helm search repo metrics-server/metrics-server -l | headhelm upgrade --install metrics-server metrics-server/metrics-server --version 3.5.0 --namespace kube-systemmetrics-server 默认只会部署一个实例，如果希望高可用，请参考官方配置：metrics-server - high-availability manifests
等 metrics-server 启动好后，就可以使用 kubectl top 命令啦：
? kubectl top nodeNAME 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 podNo resources found in default namespace.? kubectl top pod -ANAMESPACE 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 请移步 etcd 的备份与恢复
在我们学习使用 Prometheus/MinIO/Tekton 等有状态应用时，它们默认情况下会通过 PVC 声明需要的数据卷。
为了支持这个能力，我们需要在集群中部署一个 Volume Provisioner.
对于云上环境，直接接入云服务商提供的 Volume Provisioner 就 OK 了，方便省事而且足够可靠。
而对于 bare-metal 环境，比较有名的应该是 rook-ceph，但是这个玩意部署复杂，维护难度又高，不适合用来测试学习，也不适合生产环境。
对于开发、测试环境，或者个人集群，建议使用：