kubeadm部署的K8s集群api-server与controller-manager启动失败（绑定异常）

我来帮你一步步拆解这个问题——既然之前降级Docker到17.09后集群能正常运行，那问题大概率出在后续的环境变化、配置误改或者端口冲突上，咱们从最常见的原因开始排查：

• 先确认端口是否被占用
  绑定异常最直接的诱因就是目标端口被其他进程抢了。你在主节点上执行这两条命令，检查api-server默认的6443端口、controller-manager默认的10252端口的占用情况：

  netstat -tulpn | grep 6443
  netstat -tulpn | grep 10252
  

  如果发现有非K8s相关的进程占用，要么停掉该进程，要么修改静态Pod配置文件（路径一般是/etc/kubernetes/manifests/下的kube-apiserver.yaml和kube-controller-manager.yaml），调整对应的端口参数：api-server改--secure-port，controller-manager改--port或--secure-port。

• 检查Docker网络配置是否出问题
  虽然降级后曾正常运行，但重启Docker或节点可能导致网络配置漂移。你可以做这两项检查：

  • 执行docker network inspect bridge，确认Docker网桥的子网和K8s的Pod子网没有重叠冲突；
  • 查看静态Pod配置里的hostNetwork字段，如果设为true，Pod会直接用宿主机网络栈，端口冲突的影响更直接；如果是false，要确认Pod网络插件（比如flannel、calico）是否正常运行。

• 核对静态Pod配置文件的完整性
  有时候配置文件可能被误编辑，导致绑定参数出错。你可以重点检查：

  • api-server的--bind-address是否设为0.0.0.0（允许所有地址绑定）或者正确的主节点IP；
  • controller-manager的--bind-address配置是否正确，有没有重复的端口配置项。
    如果有之前正常运行时的配置备份，直接对比差异会更高效。

• 查看容器日志获取详细错误信息
  单纯的“绑定异常”提示太笼统，你可以通过Docker直接拉取这两个组件的日志：

  # 查看api-server容器日志，自动匹配容器名称
  docker logs $(docker ps -q -f name=kube-apiserver)
  # 查看controller-manager容器日志
  docker logs $(docker ps -q -f name=kube-controller-manager)
  

  日志里可能会给出更具体的原因，比如是绑定特定IP失败、权限不足（虽然高位端口一般不会有这个问题），还是网络命名空间的问题。

• 检查kubelet的运行状态
  静态Pod是由kubelet直接管理的，kubelet异常也会导致Pod启动失败。执行systemctl status kubelet看服务是否正常，或者用journalctl -u kubelet -f实时查看kubelet日志，排查是否有读取配置文件失败、容器启动网络错误等提示。

• 排查安全模块的限制
  SELinux或AppArmor这类安全模块可能会阻止容器绑定端口。你可以临时执行setenforce 0关闭SELinux测试，如果Pod能正常启动，再调整SELinux策略，允许相关端口的绑定操作。

内容的提问来源于stack exchange，提问作者lunatikz