Kubernetes 3 Master + 3 Worker 高可用集群部署记录

本文按本次实际搭建成功的环境重新整理，重点修正了 containerd 2.x 的 pause 配置、kube-vip 的 kubeconfig 挂载、静态 Pod 备份文件、节点加入权限以及 Calico 镜像替换问题。

本文从以下前提开始：6 台 Ubuntu 主机已完成固定 IP、主机名、SSH、containerd、kubelet、kubeadm、kubectl 的安装。

1. 环境规划

角色主机名IP 地址
控制节点 1k8s-master01192.168.89.101
控制节点 2k8s-master02192.168.89.102
控制节点 3k8s-master03192.168.89.103
工作节点 1k8s-worker01192.168.89.104
工作节点 2k8s-worker02192.168.89.105
工作节点 3k8s-worker03192.168.89.106
控制面虚拟 IPVIP192.168.89.100

本次使用的主要版本和配置：

Ubuntu：24.04.4 LTS
Kubernetes：v1.36.3
containerd：2.2.1
containerd 配置版本：version = 3
控制面 VIP：192.168.89.100
控制面端口：6443
主机网卡：ens33
Pod 网段：10.244.0.0/16
Kubernetes 国内镜像仓库：registry.aliyuncs.com/google_containers
pause 镜像：registry.aliyuncs.com/google_containers/pause:3.10.2
kube-vip：v1.2.1
Calico：v3.32.1

192.168.89.100 必须是当前未被其他机器占用的地址，并且应与三台 Master 位于同一二层网段。

2. 六台机器统一检查

以下操作在 6 台机器上分别执行：

hostname
ip -br addr
kubeadm version -o short
kubelet --version
kubectl version --client
containerd --version

确认主机名和 IP 一一对应，并确认 6 台机器的 Kubernetes 版本一致。

建议在 6 台机器的 /etc/hosts 中都存在以下映射：

192.168.89.100 k8s-api-vip
192.168.89.101 k8s-master01
192.168.89.102 k8s-master02
192.168.89.103 k8s-master03
192.168.89.104 k8s-worker01
192.168.89.105 k8s-worker02
192.168.89.106 k8s-worker03

3. 六台机器统一进行系统准备

3.1 关闭 Swap

sudo swapoff -a
sudo sed -ri '/[[:space:]]swap[[:space:]]/s/^#?/#/' /etc/fstab
swapon --show

swapon --show 没有输出即可。

3.2 加载内核模块

cat <<'EOF' | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

检查：

lsmod | grep -E 'overlay|br_netfilter'

3.3 配置内核网络参数

cat <<'EOF' | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system

检查：

sysctl net.bridge.bridge-nf-call-iptables
sysctl net.bridge.bridge-nf-call-ip6tables
sysctl net.ipv4.ip_forward

三项都应为 1。

4. 六台机器统一配置 crictl

cat <<'EOF' | sudo tee /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false
EOF

检查：

sudo crictl info >/dev/null && echo "crictl 连接 containerd 成功"

crictl 主要用于直接查看本机 containerd 中的 Pod 沙箱、容器、镜像和日志。

5. 六台机器统一配置 containerd

5.1 确认 containerd 配置版本

sudo grep -nE '^version[[:space:]]*=|pinned_images|sandbox[[:space:]]*=|sandbox_image' \
  /etc/containerd/config.toml

本次环境应看到类似：

version = 3

[plugins.'io.containerd.cri.v1.images'.pinned_images]
  sandbox = 'registry.k8s.io/pause:3.10.2'

本次使用的是 containerd 2.x、version = 3 配置，pause 字段是 pinned_images 下的 sandbox，不是旧配置中的 sandbox_image。

5.2 确认 systemd cgroup

sudo grep -n 'SystemdCgroup' /etc/containerd/config.toml

应为：

SystemdCgroup = true

如果显示为 false，执行：

sudo sed -ri \
  's#^([[:space:]]*)SystemdCgroup[[:space:]]*=[[:space:]]*false#\1SystemdCgroup = true#' \
  /etc/containerd/config.toml

5.3 确认 Kubernetes 需要的 pause 版本

先在任意一台机器执行一次：

K8S_VERSION="$(kubeadm version -o short)"

kubeadm config images list \
  --kubernetes-version="${K8S_VERSION}" \
  | grep pause

本次结果为：

registry.k8s.io/pause:3.10.2

5.4 修改国内 pause 镜像

以下在 6 台机器分别执行：

export MIRROR_PAUSE="registry.aliyuncs.com/google_containers/pause:3.10.2"

echo "pause 镜像：${MIRROR_PAUSE}"

备份配置时，备份文件可以放在 /etc/containerd/，不要放到 Kubernetes 静态 Pod 目录：

sudo cp /etc/containerd/config.toml \
  /etc/containerd/config.toml.before-k8s

修改 containerd 2.x 的 sandbox：

sudo sed -ri \
  "s#^([[:space:]]*)sandbox[[:space:]]*=.*#\1sandbox = '${MIRROR_PAUSE}'#" \
  /etc/containerd/config.toml

检查文件内容：

grep -nA2 'pinned_images' /etc/containerd/config.toml

应看到：

[plugins.'io.containerd.cri.v1.images'.pinned_images]
  sandbox = 'registry.aliyuncs.com/google_containers/pause:3.10.2'

5.5 重启并预拉取 pause 镜像

sudo systemctl restart containerd
sudo systemctl restart kubelet

sudo crictl pull "${MIRROR_PAUSE}"

在执行 kubeadm init 或 kubeadm join 之前，kubelet 可能处于 activating 或反复重启状态，这是因为它还没有获得集群配置，不能据此判断 pause 配置失败。

5.6 每台机器的精简验证

echo "=== containerd 实际加载的 pause 配置 ==="
sudo containerd config dump | grep -A2 'pinned_images'

echo "=== containerd 状态 ==="
sudo systemctl is-active containerd

echo "=== 本机 pause 镜像 ==="
sudo crictl images | grep pause

正确结果应包含：

sandbox = 'registry.aliyuncs.com/google_containers/pause:3.10.2'
active
registry.aliyuncs.com/google_containers/pause  3.10.2

不需要再执行下面的默认标签命令：

# 本次不需要
# sudo ctr -n k8s.io images tag "${MIRROR_PAUSE}" "${DEFAULT_PAUSE}"

因为 containerd 已经直接配置为使用国内 pause 镜像。

6. 三台 Master 预拉取控制面镜像

以下分别在 k8s-master01、k8s-master02、k8s-master03 执行：

export K8S_VERSION="$(kubeadm version -o short)"
export K8S_IMAGE_REPO="registry.aliyuncs.com/google_containers"

sudo kubeadm config images list \
  --kubernetes-version="${K8S_VERSION}" \
  --image-repository="${K8S_IMAGE_REPO}"

确认输出包括：

kube-apiserver
kube-controller-manager
kube-scheduler
kube-proxy
coredns
pause
etcd

开始拉取：

sudo kubeadm config images pull \
  --kubernetes-version="${K8S_VERSION}" \
  --image-repository="${K8S_IMAGE_REPO}"

工作节点不需要提前拉取 apiserver、scheduler、etcd 等控制面镜像。

7. 在 master01 生成 kube-vip 静态 Pod

仅在 k8s-master01 执行。

7.1 设置变量

export VIP="192.168.89.100"
export INTERFACE="ens33"
export KVVERSION="v1.2.1"
export KVIP_IMAGE="m.daocloud.io/ghcr.io/kube-vip/kube-vip:${KVVERSION}"

ip -br addr

确认 192.168.89.101 位于 ens33 网卡上。

7.2 拉取 kube-vip 镜像

sudo ctr images pull "${KVIP_IMAGE}"

7.3 生成控制面 VIP 清单

sudo mkdir -p /etc/kubernetes/manifests

sudo ctr run --rm --net-host \
  "${KVIP_IMAGE}" \
  kube-vip-manifest \
  /kube-vip manifest pod \
  --interface "${INTERFACE}" \
  --address "${VIP}" \
  --controlplane \
  --arp \
  --leaderElection \
  | sudo tee /etc/kubernetes/manifests/kube-vip.yaml >/dev/null

本次 kube-vip 只负责控制面 VIP，因此没有添加 --services。

修改拉取策略：

sudo sed -ri \
  's#imagePullPolicy:[[:space:]]*Always#imagePullPolicy: IfNotPresent#' \
  /etc/kubernetes/manifests/kube-vip.yaml

如果生成清单中的镜像不是国内地址，执行：

sudo sed -ri \
  "s#^([[:space:]]*)image:[[:space:]].*kube-vip.*#\1image: ${KVIP_IMAGE}#" \
  /etc/kubernetes/manifests/kube-vip.yaml

7.4 初始化前只修改 hostPath

Kubernetes 1.29 及以上，在 kubeadm init 初始化期间，需要让宿主机路径临时使用：

/etc/kubernetes/super-admin.conf

但是容器内部挂载位置仍然必须是：

/etc/kubernetes/admin.conf

只修改 path:，不要修改 mountPath:：

sudo sed -ri \
  's#^([[:space:]]*)path: /etc/kubernetes/admin.conf$#\1path: /etc/kubernetes/super-admin.conf#' \
  /etc/kubernetes/manifests/kube-vip.yaml

检查：

sudo grep -nE 'image:|imagePullPolicy:|mountPath:|path:' \
  /etc/kubernetes/manifests/kube-vip.yaml

初始化前必须是：

image: m.daocloud.io/ghcr.io/kube-vip/kube-vip:v1.2.1
imagePullPolicy: IfNotPresent
mountPath: /etc/kubernetes/admin.conf
path: /etc/kubernetes/super-admin.conf

严禁使用下面这种全局替换：

# 错误示例，不要执行
sed -i 's#/etc/kubernetes/admin.conf#/etc/kubernetes/super-admin.conf#g' kube-vip.yaml

该命令会把 mountPath 也错误改成 super-admin.conf，导致 kube-vip 找不到 kubeconfig 后退出。

7.5 静态 Pod 目录禁止保存普通备份文件

不要在以下目录中保存 kube-vip.yaml.bak：

/etc/kubernetes/manifests/

如需备份，放到其他目录：

sudo mkdir -p /etc/kubernetes/backup
sudo cp /etc/kubernetes/manifests/kube-vip.yaml \
  /etc/kubernetes/backup/kube-vip.before-init.yaml

检查静态 Pod 目录：

sudo ls -la /etc/kubernetes/manifests/

如果已经存在以下文件：

kube-vip.yaml.bak

立即移出：

sudo mkdir -p /etc/kubernetes/backup
sudo mv /etc/kubernetes/manifests/kube-vip.yaml.bak \
  /etc/kubernetes/backup/

8. 在 master01 初始化 Kubernetes

仅在 k8s-master01 执行：

export K8S_VERSION="$(kubeadm version -o short)"
export K8S_IMAGE_REPO="registry.aliyuncs.com/google_containers"

sudo kubeadm init \
  --kubernetes-version="${K8S_VERSION}" \
  --apiserver-advertise-address="192.168.89.101" \
  --control-plane-endpoint="192.168.89.100:6443" \
  --image-repository="${K8S_IMAGE_REPO}" \
  --pod-network-cidr="10.244.0.0/16" \
  --cri-socket="unix:///run/containerd/containerd.sock" \
  --upload-certs

成功后，终端会输出两类加入命令：

  1. 包含 --control-plane 和 --certificate-key：给 master02、master03 使用。
  2. 不包含上述两个参数：给 3 台 Worker 使用。

把两类命令保存到本地私密文件中，不要公开 token 和 certificate-key。

9. master01 配置 kubectl

使用当前普通用户 leecurry 执行：

mkdir -p "${HOME}/.kube"

sudo cp -f /etc/kubernetes/admin.conf \
  "${HOME}/.kube/config"

sudo chown "$(id -u):$(id -g)" \
  "${HOME}/.kube/config"

检查：

kubectl get nodes -o wide

安装 CNI 前，master01 暂时显示 NotReady 是正常现象。

10. kubeadm init 成功后修正 kube-vip kubeconfig

初始化完成后，将 kube-vip 的宿主机路径从 super-admin.conf 切回正式的 admin.conf：

sudo sed -ri \
  's#^([[:space:]]*)path: /etc/kubernetes/super-admin.conf$#\1path: /etc/kubernetes/admin.conf#' \
  /etc/kubernetes/manifests/kube-vip.yaml

检查：

sudo grep -nE 'mountPath:|path:' \
  /etc/kubernetes/manifests/kube-vip.yaml

最终两项都应为：

mountPath: /etc/kubernetes/admin.conf
path: /etc/kubernetes/admin.conf

重启 kubelet：

sudo systemctl restart kubelet
sleep 15

检查 kube-vip：

sudo crictl ps --name kube-vip
ip addr show ens33 | grep 192.168.89.100

正常应看到：

STATE: Running
inet 192.168.89.100/32 ... ens33

地址后出现 deprecated 不代表故障，不影响 VIP 使用。

查看最新日志：

CID="$(sudo crictl ps -a --name kube-vip -q | head -n 1)"

if [ -n "${CID}" ]; then
  sudo crictl logs "${CID}" | tail -n 50
fi

正常日志会包含类似：

Successfully acquired lease
New leader leader=k8s-master01
layer 2 broadcaster starting IP=192.168.89.100 device=ens33

再次检查 API：

kubectl get nodes -o wide
kubectl get pods -n kube-system -o wide

11. 安装 Calico 网络插件

建议在加入其他节点前先安装 CNI。即使先加入节点也不会破坏集群，只是节点会暂时显示 NotReady。

仅在 master01 执行。

11.1 下载 Calico 清单

curl -fL \
  https://files.m.daocloud.io/raw.githubusercontent.com/projectcalico/calico/v3.32.1/manifests/calico.yaml \
  -o calico.yaml

检查：

ls -lh calico.yaml
head -n 5 calico.yaml

11.2 正确替换 Calico 镜像地址

先查看实际镜像：

grep 'image:' calico.yaml | sort -u

本次 Calico 使用的是：

quay.io/calico/cni:v3.32.1
quay.io/calico/kube-controllers:v3.32.1
quay.io/calico/node:v3.32.1

因此应替换 quay.io/calico/，不是 docker.io/calico/：

sed -i -E \
  's#^([[:space:]]*image:[[:space:]]*)quay\.io/calico/#\1m.daocloud.io/quay.io/calico/#' \
  calico.yaml

检查：

grep 'image:' calico.yaml | sort -u

正确结果应为：

image: m.daocloud.io/quay.io/calico/cni:v3.32.1
image: m.daocloud.io/quay.io/calico/kube-controllers:v3.32.1
image: m.daocloud.io/quay.io/calico/node:v3.32.1

确认没有遗漏：

grep -E '^[[:space:]]*image:[[:space:]]+quay\.io/calico/' calico.yaml

该命令应没有输出。

本次通过 kubeadm 指定了：

--pod-network-cidr=10.244.0.0/16

Calico 可以从运行中的 kubeadm 配置自动识别 Pod CIDR，因此本次不需要手工修改 CALICO_IPV4POOL_CIDR。

11.3 部署 Calico

kubectl apply -f calico.yaml

观察状态：

watch -n 2 'kubectl get pods -n kube-system -o wide'

刚开始看到以下状态属于正常初始化过程：

ContainerCreating
Init:0/3
Init:2/3

最终应变为：

calico-node-*               1/1 Running
calico-kube-controllers-*   1/1 Running
coredns-*                   1/1 Running

按 Ctrl+C 退出 watch，然后检查：

kubectl get nodes -o wide

master01 应变为 Ready。

12. master02 加入控制面

12.1 在 master02 检查 VIP

nc -zv 192.168.89.100 6443

能连接后，执行 kubeadm init 输出的控制节点加入命令，并在最前面加 sudo：

sudo kubeadm join 192.168.89.100:6443 \
  --token <TOKEN> \
  --discovery-token-ca-cert-hash sha256:<CA_CERT_HASH> \
  --control-plane \
  --certificate-key <CERTIFICATE_KEY>

kubeadm join 必须使用 root 权限。出现 user is not running as root 时，不要忽略检查，直接在命令前加 sudo。

加入成功后，在 master01 检查：

kubectl get nodes -o wide

应看到 k8s-master02。

12.2 将 kube-vip 清单复制到 master02

在 master01 执行：

scp /etc/kubernetes/manifests/kube-vip.yaml \
  leecurry@192.168.89.102:/tmp/kube-vip.yaml

第一次 SSH 连接会询问：

Are you sure you want to continue connecting (yes/no/[fingerprint])?

确认目标确实是 master02 后输入：

yes

然后在 master02 执行：

ip -br addr

确认实际网卡也是 ens33。如果不是，需要先把 /tmp/kube-vip.yaml 中的 vip_interface 改成实际网卡名。

放入静态 Pod 目录：

sudo mv /tmp/kube-vip.yaml \
  /etc/kubernetes/manifests/kube-vip.yaml

sudo systemctl restart kubelet
sleep 15

sudo crictl ps --name kube-vip

13. master03 加入控制面

在 master03 执行与 master02 相同的控制节点加入命令：

sudo kubeadm join 192.168.89.100:6443 \
  --token <TOKEN> \
  --discovery-token-ca-cert-hash sha256:<CA_CERT_HASH> \
  --control-plane \
  --certificate-key <CERTIFICATE_KEY>

加入成功后，在 master01 复制 kube-vip：

scp /etc/kubernetes/manifests/kube-vip.yaml \
  leecurry@192.168.89.103:/tmp/kube-vip.yaml

然后在 master03 执行：

ip -br addr

sudo mv /tmp/kube-vip.yaml \
  /etc/kubernetes/manifests/kube-vip.yaml

sudo systemctl restart kubelet
sleep 15

sudo crictl ps --name kube-vip

在 master01 检查三台控制节点：

kubectl get nodes -o wide
kubectl get pods -n kube-system -o wide | grep kube-vip

应看到 3 个 kube-vip Pod，分别运行在三台 Master 上。

ARP Leader Election 模式下，通常只有当前 Leader 的网卡上能看到 VIP：

ip addr | grep 192.168.89.100

如果当前 Leader 宕机，VIP 会漂移到另一台运行正常的 Master。

14. 证书密钥或 token 过期时重新生成

控制面证书上传后通常只保留约 2 小时。如果 master02 或 master03 加入时报证书不存在，在已经正常运行的控制节点执行：

sudo kubeadm init phase upload-certs --upload-certs

记录新输出的 certificate-key。

如需生成新的控制节点完整加入命令：

sudo kubeadm token create \
  --print-join-command \
  --certificate-key <新的_CERTIFICATE_KEY>

如只需生成 Worker 加入命令：

sudo kubeadm token create --print-join-command

15. 三台 Worker 加入集群

分别在以下节点执行：

k8s-worker01
k8s-worker02
k8s-worker03

使用 kubeadm init 输出的 Worker 加入命令，最前面必须加 sudo：

sudo kubeadm join 192.168.89.100:6443 \
  --token <TOKEN> \
  --discovery-token-ca-cert-hash sha256:<CA_CERT_HASH>

Worker 命令中不应包含：

--control-plane
--certificate-key

Worker 节点不需要复制 kube-vip.yaml。

每加入一台后，在 master01 检查：

kubectl get nodes -o wide

Worker 的 ROLES 显示 <none> 是正常现象。

16. 最终检查

16.1 检查 6 台节点

kubectl get nodes -o wide

最终应为：

k8s-master01   Ready   control-plane
k8s-master02   Ready   control-plane
k8s-master03   Ready   control-plane
k8s-worker01   Ready   <none>
k8s-worker02   Ready   <none>
k8s-worker03   Ready   <none>

16.2 检查全部 Pod

kubectl get pods -A -o wide

重点确认以下组件为 Running：

calico-node
calico-kube-controllers
coredns
etcd
kube-apiserver
kube-controller-manager
kube-scheduler
kube-proxy
kube-vip

16.3 检查 kube-vip

kubectl get pods -n kube-system -o wide | grep kube-vip

应看到三条记录，分别位于三台 Master。

检查 VIP 连通性：

ping -c 4 192.168.89.100
nc -zv 192.168.89.100 6443

16.4 可选：重新分布 CoreDNS

在至少两台新节点加入且集群稳定后，可以执行：

kubectl -n kube-system rollout restart deployment coredns
kubectl -n kube-system rollout status deployment coredns

17. 本次遇到的问题和最终修正

17.1 containerd pause 字段写错

错误做法：

sandbox_image = "..."

该写法适用于旧版 containerd 配置，不适用于本次 version = 3。

本次正确写法：

[plugins.'io.containerd.cri.v1.images'.pinned_images]
  sandbox = 'registry.aliyuncs.com/google_containers/pause:3.10.2'

最可靠的验证命令：

sudo containerd config dump | grep -A2 pinned_images

17.2 kube-vip 同时修改了 mountPath 和 path

初始化期间正确配置：

mountPath: /etc/kubernetes/admin.conf
path: /etc/kubernetes/super-admin.conf

初始化完成后的最终配置：

mountPath: /etc/kubernetes/admin.conf
path: /etc/kubernetes/admin.conf

只应修改 path:，不能全局替换两个路径。

17.3 将 kube-vip.yaml.bak 放进 manifests 目录

错误目录：

/etc/kubernetes/manifests/kube-vip.yaml.bak

正确做法：

/etc/kubernetes/backup/kube-vip.yaml.bak

kubelet 会扫描静态 Pod 目录中所有非点号开头的文件，并不只读取 .yaml 文件。备份文件可能导致旧配置继续生效。

17.4 kubeadm join 没有使用 sudo

错误信息：

[ERROR IsPrivilegedUser]: user is not running as root

正确处理：

sudo kubeadm join ...

不要通过 --ignore-preflight-errors=IsPrivilegedUser 忽略该检查。

17.5 Calico 替换了错误的镜像前缀

错误匹配：

docker.io/calico/

本次实际镜像来自：

quay.io/calico/

因此正确替换为：

m.daocloud.io/quay.io/calico/

17.6 安装 CNI 前节点 NotReady

在 Calico 尚未部署时：

Node：NotReady
CoreDNS：Pending 或 ContainerCreating

属于正常现象。Calico 正常后，节点会逐渐变为 Ready。

18. 常用排错命令

查看节点和 Pod

kubectl get nodes -o wide
kubectl get pods -A -o wide

查看某个 Pod 详情

kubectl describe pod -n <命名空间> <Pod名称>

查看 kube-vip 容器

sudo crictl ps -a --name kube-vip

查看最新 kube-vip 日志

CID="$(sudo crictl ps -a --name kube-vip -q | head -n 1)"

if [ -n "${CID}" ]; then
  sudo crictl logs "${CID}"
else
  echo "当前没有找到 kube-vip 容器"
fi

查看 kubelet 日志

sudo journalctl -u kubelet \
  --since "20 minutes ago" \
  --no-pager \
  | tail -n 200

查看 containerd 状态

sudo systemctl status containerd --no-pager -l
sudo containerd config dump | grep -A2 pinned_images
sudo crictl images

查看 API Server 是否监听 6443

sudo ss -lntp | grep ':6443'

查看 VIP 当前在哪台 Master

分别在三台 Master 执行：

ip addr | grep 192.168.89.100

通常只有当前 kube-vip Leader 能看到该 VIP。

19. 高可用说明

三台 Master 都必须存在：

/etc/kubernetes/manifests/kube-vip.yaml

如果 kube-vip 只运行在 master01，那么 master01 宕机后 VIP 就无法继续使用。

三台 Master 都运行 kube-vip 后：

master01 持有 VIP
master02 待命
master03 待命

当当前 Leader 宕机时，另一台 Master 会通过 Leader Election 接管：

192.168.89.100:6443

3 节点 etcd 集群允许同时故障 1 台并维持多数派；如果同时故障 2 台，etcd 会失去多数派，即使 VIP 存在，控制面也无法正常完成写操作。

20. 安全注意事项

以下内容属于敏感凭据，不要截图公开或写入公开文档：

kubeadm token
--certificate-key
/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/pki 中的私钥

如果 token 已公开，可以在控制节点查看并删除：

sudo kubeadm token list
sudo kubeadm token delete <TOKEN_ID>

然后重新生成：

sudo kubeadm token create --print-join-command

super-admin.conf 绕过常规授权控制，只应用于初始化或紧急恢复。集群正常运行后，kube-vip 应使用 admin.conf。

21. 最终成功标准

同时满足以下条件，即可认为本次集群主体部署成功：

  • 3 台 Master 都为 Ready。
  • 3 台 Worker 都为 Ready。
  • 3 台 Master 都运行 kube-vip 静态 Pod。
  • VIP 192.168.89.100:6443 可以访问。
  • 3 个 etcd 实例均为 Running。
  • Calico Node 在 6 台机器上均为 Running。
  • Calico Controller 为 Running。
  • CoreDNS 为 Running。
  • kubectl get pods -A 没有长期存在的 CrashLoopBackOff、ImagePullBackOff、Init:Error。

最终检查命令：

kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get pods -n kube-system -o wide | grep kube-vip
nc -zv 192.168.89.100 6443
# kubernetes # 容器 # 云原生 # k8s
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

基于STM32的全屋环境智能监测与预警终端设计

avatar 亚马逊云科技技术品牌专区

Keras：面向人类的深度学习库

Keras3支持多后端（TensorFlow、PyTorch、JAX），通过设置环境变量切换，兼容指定版本。pip安装后可用Sequential API快速构建CNN模型，如MNIST分类示例，实

avatar 亚马逊云科技技术品牌专区

AI行业日报｜2026-09-25：5个热点事件

本期行业动态聚焦于端侧算力重构、自主智能体工作流、开发工具经济模型、网络隔离架构设计与公共部门合规审查。以下结合一线技术场景进行结构化梳理，供 AI 研究员与软件工程团队参考。 PrismML 正将其轻量级语言模型适配至搭载高通处理器的智能眼镜终端 1 。该平台的核心战略指向开源权重模型的本地化运行，旨在最大化挖掘穿戴设备现有算力的利用效率 1 。对于嵌入式与边缘计算开发者而言，此类微型模型向低功

avatar 亚马逊云科技技术品牌专区