在AWS EC2实例上自建K8S集群失败：kube-apiserver无法正常启动

我之前在AWS EC2上手动搭建K8S集群时也碰到过几乎一模一样的问题，结合你提供的日志和环境信息，咱们一步步来定位问题：

1. 先确认Docker与Kubelet的Cgroup驱动是否一致 #

这是自建K8S最容易踩的坑之一，K8S 1.24版本默认使用systemd作为cgroup驱动，如果Docker用的是cgroupfs，会导致kubelet和容器的资源管理冲突，进而引发apiserver重启。

• 查看Docker的cgroup驱动：

  docker info | grep -i cgroup
  

• 查看kubelet的cgroup驱动配置：

  cat /var/lib/kubelet/config.yaml | grep cgroupDriver
  

如果两者不一致，修改Docker配置：

1. 编辑/etc/docker/daemon.json（如果没有就新建），添加：

   {
     "exec-opts": ["native.cgroupdriver=systemd"]
   }
   

2. 重启Docker和kubelet：

   systemctl daemon-reload
   systemctl restart docker
   systemctl restart kubelet
   

2. 检查Kube-apiserver的详细日志（核心排查步骤） #

你的日志显示apiserver反复被杀死重启，且探针返回500/连接拒绝，最直接的方式是看apiserver的具体报错：

• 如果kubectl还能临时连接（或者用master节点本地的kubeconfig）：

  kubectl logs kube-apiserver-master -n kube-system --tail=100
  

• 如果kubectl完全连不上，直接用Docker查看容器日志：

  # 先找到apiserver的容器ID
  docker ps | grep kube-apiserver
  # 查看日志
  docker logs <容器ID> --tail=100
  

常见的报错原因包括：无法连接etcd、证书问题、端口被占用、配置参数错误等。比如如果日志里出现etcdserver: request timed out，那就是etcd集群（这里是单节点etcd）有问题，需要进一步排查etcd的状态和日志。

3. 检查Etcd的状态与日志 #

Kube-apiserver完全依赖etcd存储集群数据，如果etcd故障，apiserver必然无法正常运行：

• 查看etcd pod状态：

  kubectl get pods -n kube-system | grep etcd
  

• 查看etcd日志：

  kubectl logs etcd-master -n kube-system --tail=100
  

如果etcd启动失败，常见原因包括：磁盘空间不足、证书错误、内核参数未配置等。AWS EC2实例默认磁盘可能不大，先检查磁盘使用情况：df -h。

4. 验证EC2实例的内核参数与模块配置 #

K8S运行需要特定的内核模块和sysctl参数，缺失会导致网络或容器运行异常：

• 检查必要内核模块是否加载：

  lsmod | grep br_netfilter
  lsmod | grep overlay
  

如果没加载，手动加载并设置开机自启：

modprobe br_netfilter
modprobe overlay
echo "br_netfilter" >> /etc/modules-load.d/k8s.conf
echo "overlay" >> /etc/modules-load.d/k8s.conf

• 检查sysctl参数：

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

如果返回值不是1，修改并持久化：

sysctl -w net.bridge.bridge-nf-call-iptables=1
sysctl -w net.ipv4.ip_forward=1
echo "net.bridge.bridge-nf-call-iptables=1" >> /etc/sysctl.d/k8s.conf
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.d/k8s.conf
sysctl --system

5. 再次确认AWS网络配置（虽然你说内网，但别漏了） #

• 安全组：master节点的安全组必须允许**自身（或整个内网CIDR）**访问6443端口，同时允许worker节点访问6443；另外，master节点的outbound规则要允许访问自身的2379/2380端口（etcd通信）。
• 网络ACL：AWS的网络ACL是双向的， inbound和outbound都要允许内网CIDR的所有必要端口（6443、2379、2380、10250等）。
• 实例内部防火墙：有些EC2镜像自带firewalld或ufw，检查是否有规则限制了6443端口：

  # 查看firewalld状态
  systemctl status firewalld
  # 如果开启了，临时关闭测试
  systemctl stop firewalld
  

6. 检查Kubelet的运行状态与日志 #

kubelet是节点上的核心组件，它负责管理容器，apiserver的探针失败也可能是kubelet本身有问题：

• 查看kubelet状态：

  systemctl status kubelet
  

• 实时查看kubelet日志：

  journalctl -u kubelet -f
  

如果日志里出现Failed to start container或Cgroup error之类的信息，回到步骤1检查cgroup驱动。

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