AWS EC2上使用kubectl时周期性出现连接拒绝错误
2026-7-11
问题原因分析
- kube-apiserver进程异常：6443是Kubernetes API Server的专属端口，连接被拒绝最直接的原因是该进程未正常监听端口。周期性出现问题大概率是apiserver因内存/CPU过载被系统OOM Killer终止，或进程自身崩溃，之后kubelet自动重启进程，所以一段时间后恢复。
- 网络组件波动：Calico插件的bird、felix进程若出现周期性异常，可能导致节点网络规则紊乱，阻断6443端口的流量；另外AWS EC2节点的网络偶尔出现短暂中断，也会引发此类连接问题。
- 磁盘/存储瓶颈：API Server依赖etcd存储集群状态，若etcd所在的EBS磁盘IOPS不足、读写延迟过高，或磁盘空间耗尽，会导致apiserver响应超时甚至挂起，引发周期性连接失败。
- kubelet服务异常：kubelet负责管控API Server等核心组件的生命周期，若kubelet自身出现周期性故障，会导致apiserver被频繁重启或无法正常启动。
解决建议
排查组件日志
- 实时查看API Server日志：
journalctl -u kube-apiserver -f，重点排查是否有OOM、进程崩溃的报错信息 - 查看kubelet运行日志：
journalctl -u kubelet -f，确认是否存在重启API Server的记录 - 检查Calico组件状态：
kubectl logs -n kube-system -l k8s-app=calico-node，排查网络插件进程是否有异常
- 实时查看API Server日志：
监控资源与存储状态
- 用
top/htop实时监控CPU、内存占用，重点关注kube-apiserver、etcd、calico-node等进程的资源消耗 - 部署metrics-server后，通过
kubectl top nodes和kubectl top pods定期查看组件资源使用情况，确认是否存在资源耗尽触发OOM的情况 - 用
iostat -x 1检查EBS磁盘的读写延迟，排查IO瓶颈；用df -h确认/var/lib/etcd、/var/lib/kubelet所在分区的磁盘空间是否充足
- 用
验证网络与端口状态
- 问题出现时，执行
ss -tulpn | grep 6443，确认API Server是否在监听6443端口 - 检查iptables规则：
iptables-save | grep 6443，确保没有阻断该端口流量的规则 - 本地测试连接：
curl -k https://localhost:6443/version，若本地能连通但外部（或kubectl用公网IP连接）失败，需排查AWS安全组或节点路由配置
- 问题出现时，执行
调整组件资源配置
- 查看API Server的资源限制：
kubectl describe pod kube-apiserver-<你的节点名> -n kube-system，若未设置合理的requests/limits，建议添加资源配置避免被OOM Killer终止 - 同步检查etcd的资源配置，确保其拥有足够的CPU、内存资源稳定运行
- 查看API Server的资源限制：
优化网络插件版本
- 当前使用的Calico 3.23与Kubernetes 1.28.1可能存在兼容性问题，建议升级到适配K8s 1.28的Calico版本，避免因版本不匹配引发的周期性网络异常
内容的提问来源于stack exchange，提问作者Yaya
相关产品推荐
相关产品推荐
