EKS从1.19升级至1.21后应用出现延迟，求排查解决步骤
2026-7-28
EKS 1.19升级到1.21后应用延迟排查步骤
一、网络层面排查
- 检查CNI插件版本：EKS升级后Amazon VPC CNI可能同步更新，执行
kubectl describe daemonset aws-node -n kube-system查看当前CNI版本，对比EKS官方兼容矩阵，若版本不匹配则升级到对应兼容版本。 - 验证Pod网络策略：1.21版本中网络策略的规则解析逻辑有细节调整，执行
kubectl get networkpolicy --all-namespaces列出所有策略，逐一检查是否存在误拦截应用流量的规则。 - 测试节点间网络延迟：在跨节点的Pod内执行
ping <target-pod-ip>或mtr <target-pod-ip>，确认底层EC2节点间网络是否存在波动，同时检查节点所在AZ是否有网络故障通知。 - 排查kube-proxy模式变化：1.19到1.21期间kube-proxy的默认模式可能从iptables切换为IPVS，执行
kubectl describe daemonset kube-proxy -n kube-system查看模式，若为IPVS则用ipvsadm -Ln验证服务转发规则是否正常。
二、容器运行时与资源配置排查
- 核对容器运行时版本：EKS 1.21默认采用containerd，若升级前使用docker，需检查containerd配置是否合理，执行
crictl info查看运行时状态，对比原docker的镜像缓存、资源限制配置是否有差异。 - 检查Pod QoS等级：1.21对QoS调度优先级的处理更严格，若应用Pod未设置
resources.requests，会被划为BestEffort等级，导致资源分配优先级低，执行kubectl describe pod <pod-name>查看QoS Class。 - 监控节点资源使用率：执行
kubectl top nodes和kubectl top pods，检查节点CPU、内存、磁盘IO是否存在瓶颈，即使无Pod重启，内存或CPU压力也可能导致应用卡顿。
三、EKS核心组件变更排查
- 验证kubelet配置：升级后kubelet版本从1.19升至1.21，部分参数默认值变更（如
--serialize-image-pulls），执行kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.kubeletVersion}'确认版本，登录节点查看/var/lib/kubelet/config.yaml中的参数是否影响性能。 - 检查CoreDNS配置：1.21配套的CoreDNS版本可能升级，执行
kubectl get configmap coredns -n kube-system -o yaml查看配置，在Pod内用nslookup <domain>测试DNS解析耗时，确认是否存在解析延迟。 - 核对AWS Load Balancer Controller版本：若应用使用ALB/NLB，需确认控制器版本兼容EKS 1.21，执行
kubectl get deployment aws-load-balancer-controller -n kube-system查看版本，必要时升级到兼容版本。
四、应用兼容性排查
- 检查K8s API版本依赖：1.19到1.21有多个API被弃用（如
extensions/v1beta1Ingress、apps/v1beta1Deployment），执行kubectl logs <pod-name>搜索API调用报错，确认应用是否仍在使用已弃用的API。 - 测试应用本地性能：在Pod内直接调用应用端口（如
curl localhost:<port>），测试响应时间，确认是否是应用自身在新环境下的性能问题。 - 排查连接池配置：升级后网络环境变化可能导致后端（数据库、缓存）连接池耗尽，查看应用日志中是否有连接超时、连接池满的报错，调整连接池大小配置。
五、深度监控与追踪
- 查看kube-apiserver日志：执行
kubectl logs -n kube-system -l component=kube-apiserver搜索rate limiting关键词，确认是否存在API请求被限流的情况。 - 分析Prometheus监控指标：重点查看
apiserver_request_duration_seconds（API请求延迟）、container_cpu_usage_seconds_total（容器CPU使用率）、network_transmit_bytes_total（网络传输）等指标，定位瓶颈点。 - 节点抓包分析：在Pod所在节点执行
tcpdump -i any host <pod-ip> -w traffic.pcap抓取流量包，用Wireshark分析数据包的传输耗时，定位网络延迟具体环节。
内容的提问来源于stack exchange，提问作者Bhagavat Bhise
相关产品推荐
相关产品推荐
