MicroK8s add-on enable 失败主因是镜像未预拉取、节点角色冲突及存储校验缺失，常见于 dns/storage/ingress；HA 集群需禁用 auto-healing、确保网络/主机名/时间同步，并注意 add-on 作用域与 etcd 成员状态。
MicroK8s add-on enable 失败：常见卡点和绕过方式
加插件失败不是因为命令写错，而是 MicroK8s 默认不自动拉镜像、不处理节点角色冲突、也不校验本地存储就直接报 failed to apply。最常卡在 dns、storage、ingress 这三个 add-on 上。
实操建议：
- 先确认集群状态：
microk8s status --wait-ready，别在NotReady时硬启 add-on -
microk8s enable dns失败？大概率是 CoreDNS 镜像没提前拉下来——手动执行：microk8s ctr images pull ghcr.io/canonical/microk8s-core-dns:1.10.1（版本号按microk8s version输出对齐） -
microk8s enable storage在单节点默认用hostpath，但若你改过/var/snap/microk8s/common/default-storage或删过 PVC，会静默失败；删掉残留 PV：microk8s kubectl get pv -o name | xargs -r microk8s kubectl delete - 所有 add-on 启用后，检查对应命名空间的 Pod 是否 Running：
microk8s kubectl get po -n kube-system，别只信终端输出的 “enabled”
MicroK8s 高可用集群必须关掉 auto-healing
MicroK8s 自带的 cluster 模式默认启用 auto-healing，它会在节点失联 30 秒后自动驱逐该节点上的所有 Pod 并重调度——这对跨机房或临时网络抖动极不友好，反而导致服务雪崩。
实操建议：
- 初始化集群前，先在每台节点上编辑配置：
/var/snap/microk8s/current/args/kube-apiserver，追加--feature-gates=SelfHosting=false和--disable-admission-plugins=PodDisruptionBudget,NodeRestriction - 加入集群时禁用自动恢复：
microk8s add-node --no-auto-heal（注意：这个参数仅在 v1.28+ 支持，旧版需手动 patch） - 高可用下 etcd 不是主从，而是多成员 raft；节点加入后立刻验证：
microk8s etcd list-members，输出里每个节点的status必须是started，不能是unstarted或空 - 不要复用单节点的
microk8s config去连 HA 集群——HA 的 kubeconfig 默认绑定到 localhost，需用microk8s config > kubeconfig.yaml导出，并替换其中的server:地址为 VIP 或 LB 地址
HA 集群中 add-on 的作用域陷阱
MicroK8s 的 add-on 不是全局生效的。比如你在 node1 上 microk8s enable ingress，只会在 node1 上部署 nginx-ingress-controller 的 DaemonSet，其他节点不会同步——除非你用 --scope=cluster 显式声明（v1.27+ 才支持）。
实操建议：
- 所有 add-on 必须在控制平面节点（即运行
microk8s enable的节点）上执行，且该节点需是control-plane角色（查角色：microk8s kubectl get nodes -o wide看 LABELS 列） - 确认 add-on 是否跨节点部署：
microk8s kubectl get ds -A | grep ingress，如果只有 1 个副本且 NODE-SELECTOR 是空，说明没生效到其他节点 - storage add-on 的
microk8s-hostpathStorageClass 默认只绑定到本机路径，跨节点 PVC 绑定会 Pending；如需共享存储，必须换用microk8s-ceph或外部 CSI 驱动，不能依赖默认 hostpath - dns add-on 的 CoreDNS ConfigMap 是集群级的，但它的 Endpoints 只注册在本节点的 kube-proxy 规则里；若某节点没运行 kube-proxy（比如被误停），该节点 DNS 就会超时——检查：
microk8s kubectl get endpoints -n kube-system kube-dns
用 microk8s join 搭建 HA 模板时的网络假设
MicroK8s 的 microk8s join 默认假设所有节点能直通 UDP 6443（kube-apiserver）、TCP 25000（etcd）、TCP 25001（dqlite）端口，且主机名可解析。一旦用了 NAT、防火墙或容器网络桥接，join 就会卡在 “Waiting for service to start…”。
实操建议：
- join 命令里传的地址必须是其他节点能直接访问的 IP，不是
localhost或 Docker 网桥地址；例如：microk8s join 192.168.1.10:25000/abcdef...，而不是microk8s join 127.0.0.1:25000/... - etcd 成员通信依赖主机名；若
hostname返回的是ubuntu-server，但 DNS 解析不到该名，就会失败；统一设静态主机名并写入/etc/hosts：192.168.1.10 node1 - 云厂商 VPC 内默认禁 UDP，必须显式放行 etcd 的 25000 端口；否则
microk8s etcd list-members会显示部分节点状态为unstarted - 节点时间不同步会导致 etcd raft 报
clock skew detected；强制同步：sudo timedatectl set-ntp on && sudo systemctl restart systemd-timesyncd
HA 模板最难调的永远不是命令拼写，而是各节点间 TCP/UDP 连通性、主机名解析、时间一致性这三件事同时成立——少一个，集群就处于“看起来正常，其实随时脑裂”的状态。
