microk8s启用ha-cluster不自动提供故障转移，需额外部署负载均衡器并配置健康检查、更新kubeconfig指向lb地址，同时确保etcd成员同步、节点网络互通及worker角色正确。
MicroK8s 集群启用了 ha-cluster 但节点宕机后 API 不可用？
这不是预期行为——ha-cluster 插件本身不提供自动故障转移能力，它只负责部署多副本控制平面（etcd + apiserver），但默认不启用负载均衡或健康探针。API 访问仍指向单个节点 IP，宕机即中断。
实操建议：
- 必须额外部署前端负载均衡器（如
nginx、haproxy或云厂商 LB），将流量打到所有 control plane 节点的16443端口（MicroK8s 默认 apiserver 端口） - LB 后端需配置健康检查：对每个节点的
https://NODE_IP:16443/healthz做周期性探测（注意证书问题，需信任 MicroK8s 自签 CA 或跳过校验） - 客户端
kubeconfig中的server字段必须指向 LB 地址，不能写死某个节点 IP
用 microk8s enable ha-cluster 后发现 etcd 成员没同步？
常见现象是 microk8s status 显示 high-availability: yes，但 microk8s etcd list-members 只返回一个节点。本质是插件未真正完成多节点注册，尤其在非交互式部署或网络延迟场景下容易失败。
实操建议：
- 确保所有节点时间同步（
systemd-timesyncd或chrony），时钟偏差 >1s 会导致 etcd 成员拒绝加入 - 节点间必须能直连通信：
2379（etcd client）、2380（etcd peer）、16443（apiserver）端口全通，防火墙常拦2380 - 手动触发同步：在新增节点上运行
microk8s add-node，然后在主节点执行microk8s join <Token></token>—— 单靠enable ha-cluster不会自动拉起新成员
测试 HA 切换时 kubectl get nodes 卡住或报 connection refused？
说明当前连接的 apiserver 实例已不可达，但客户端没有重试机制或 LB 未及时剔除故障节点。MicroK8s 的 kubectl 客户端完全依赖 kubeconfig 配置，不会自动轮询多个 endpoint。
实操建议：
- 验证 LB 是否生效：用
curl -k https://LB_IP:16443/healthz测试，再逐个 curl 各节点 IP，确认 LB 确实做了健康转发 - 强制刷新本地缓存：
microk8s kubectl config set-cluster microk8s-cluster --server=https://LB_IP:16443 - 避免用
localhost或127.0.0.1当 server 地址——这会让请求绕过 LB 直连本机，失去高可用意义
为什么停掉主节点后，新调度的 Pod 还是卡在 Pending？
MicroK8s 的 HA 模式只保障 control plane（apiserver/scheduler/controller-manager）冗余，不解决 worker 节点失联导致的调度器无法感知资源状态的问题。如果原主节点同时是唯一在线 worker，scheduler 就会因无法更新 node status 而拒绝调度。
实操建议：
- worker 节点必须独立于 control plane 运行；禁用
microk8s disable dns dashboard类命令误关关键组件 - 检查
microk8s kubectl get nodes -o wide，确认所有 worker 的STATUS是Ready，且ROLES包含worker（不是空或control-plane） - 若使用
microk8s enable ha-cluster时未指定--nodes，默认只扩 control plane，worker 需单独加节点并打 label：microk8s kubectl label node NODE_NAME node-role.kubernetes.io/worker=
HA 的复杂点不在启动，而在验证路径是否真正闭环：从客户端 DNS/LB → apiserver endpoint → etcd 成员健康 → scheduler 能读取全部 node status。漏掉任一环，看起来“开了 HA”，实际仍是单点。