news 2026/10/8 13:01:59

K8s kube-proxy模式切换性能优化运维实操

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
K8s kube-proxy模式切换性能优化运维实操

K8s kube-proxy模式切换性能优化运维实操

技术栈:Kubernetes v1.32.13 + Rocky Linux 8.6 + Containerd 1.7.x

操作环境 / 对接原理 / 详细步骤 / 完整命令 / 配置文件 / 验证流程 / 排错方案

K8s kube-proxy模式切换性能优化运维实操

操作环境

  • K8s 集群 3 节点:k8s-master(192.168.1.10), k8s-node1(192.168.1.11), k8s-node2(192.168.1.12),K8s 版本 v1.32.13

  • 排障场景:核心组件排障,已部署完整K8s集群,核心组件正常运行,业务Pod已部署,监控告警系统已配置

  • 操作系统 Rocky Linux 8.6,容器运行时 Containerd 1.7.x,网络插件 Calico,存储已配置PVC

  • 已配置kubectl命令行工具,具备集群管理员权限,可访问所有命名空间和资源

  • 已配置监控系统(Prometheus+Grafana),可查看集群指标、日志、事件,便于排障定位

对接原理

K8s kube-proxy模式切换性能优化运维实操是 K8s 生产集群运维排障中的核心操作场景。K8s 集群排障遵循"由表及里、逐层定位、快速恢复、根因根治"的原则:首先通过监控告警和用户反馈发现异常,然后通过集群状态检查、日志分析、事件追踪、资源监控等手段逐层定位故障根因,接着采取应急措施快速恢复业务,最后进行根因修复和预防措施落地。核心组件排障排障的核心目标是确保集群高可用、业务连续性、数据安全性:通过规范化的排障流程缩短故障恢复时间(MTTR),通过深度根因分析避免故障重复发生,通过预防性巡检和监控告警提前发现隐患,通过标准化SOP确保排障操作可复制可追溯。所有排障操作需遵循"先备份后操作、先观察后变更、先灰度后全量"的安全原则,避免排障操作引发二次故障。

详细步骤

1. 故障现象确认与集群状态盘点

# 1. 检查集群整体状态 kubectl get nodes -o wide kubectl get pods -A -o wide | head -50 kubectl get events -A --sort-by='.lastTimestamp' | tail -30 ​ # 2. 检查核心组件状态 kubectl get pods -n kube-system -o wide kubectl get componentstatuses 2>/dev/null || kubectl get --raw='/healthz?verbose' ​ # 3. 检查集群资源使用 kubectl top nodes kubectl top pods -A --sort-by='cpu' | head -20 kubectl top pods -A --sort-by='memory' | head -20 ​ # 4. 检查异常Pod kubectl get pods -A | grep -vE 'Running|Completed|NAME' kubectl get pods -A -o wide | grep -E 'Pending|CrashLoop|Error|ImagePull|Terminating|OOMKilled' ​ # 5. 检查节点状态详情 kubectl describe nodes | grep -A5 'Conditions:' kubectl get nodes -o jsonpath='{.items[*].status.conditions[?(@.type=="Ready")].status}' ​ # 6. 检查集群事件 kubectl get events -A --sort-by='.lastTimestamp' | tail -50 kubectl get events -A --field-selector type=Warning | tail -30 ​ # 7. 检查网络状态 kubectl get svc -A kubectl get endpoints -A kubectl get ingress -A 2>/dev/null ​ # 8. 检查存储状态 kubectl get pv kubectl get pvc -A kubectl get storageclass ​ # 9. 导出当前状态备份 kubectl get all -A -o yaml > /tmp/cluster_state_$(date +%Y%m%d_%H%M%S).yaml kubectl get nodes -o yaml > /tmp/nodes_state_$(date +%Y%m%d_%H%M%S).yaml echo "集群状态已备份到 /tmp/" ​

2. 备份防护与排障方案制定

# 1. 备份关键配置(排障前必做) kubectl get cm -A -o yaml > /tmp/cm_backup_$(date +%Y%m%d_%H%M%S).yaml kubectl get secret -A -o yaml > /tmp/secret_backup_$(date +%Y%m%d_%H%M%S).yaml kubectl get deployment,statefulset,daemonset -A -o yaml > /tmp/workload_backup_$(date +%Y%m%d_%H%M%S).yaml kubectl get svc,ingress -A -o yaml > /tmp/network_backup_$(date +%Y%m%d_%H%M%S).yaml kubectl get pv,pvc -A -o yaml > /tmp/storage_backup_$(date +%Y%m%d_%H%M%S).yaml ​ # 2. 记录故障现象 echo "=== 故障现象记录 $(date) ===" > /tmp/troubleshoot_log.txt echo "故障时间: $(date)" >> /tmp/troubleshoot_log.txt echo "故障现象: " >> /tmp/troubleshoot_log.txt echo "影响范围: " >> /tmp/troubleshoot_log.txt echo "业务影响: " >> /tmp/troubleshoot_log.txt cat /tmp/troubleshoot_log.txt ​ # 3. 制定排障方案 cat > /tmp/troubleshoot_plan.md << 'EOF' # 排障方案 ## 一、故障现象 ## 二、影响范围评估 ## 三、排障步骤与时间窗口 ## 四、应急恢复措施 ## 五、根因定位方法 ## 六、修复方案 ## 七、验证标准 ## 八、回滚方案 ## 九、风险点与应对措施 EOF echo "排障方案模板已创建" ​ # 4. 确认业务窗口 echo "当前时间: $(date)" echo "建议在业务低峰期执行排障操作,避免影响业务" ​ # 5. 通知相关业务方 # echo "K8s集群排障操作通知" | mail -s "集群排障通知" admin@example.com ​

3. 逐层定位与根因分析

# 1. 查看异常Pod详细信息 # kubectl describe pod <pod-name> -n <namespace> # kubectl logs <pod-name> -n <namespace> --tail=100 # kubectl logs <pod-name> -n <namespace> --previous ​ # 2. 查看节点详细信息 # kubectl describe node <node-name> # 检查节点Conditions、资源、污点、标签、事件 ​ # 3. 查看核心组件日志 # kubectl logs -n kube-system <component-pod> --tail=100 # kubectl logs -n kube-system <component-pod> --previous ​ # 4. 查看etcd状态 # kubectl exec -n kube-system etcd-<node> -- etcdctl endpoint health # kubectl exec -n kube-system etcd-<node> -- etcdctl member list # kubectl exec -n kube-system etcd-<node> -- etcdctl endpoint status --write-out=table ​ # 5. 查看网络连通性 # kubectl run -it --rm debug --image=busybox --restart=Never -- sh # 在容器内执行: nslookup, ping, wget, curl 等 ​ # 6. 查看存储挂载 # kubectl describe pvc <pvc-name> -n <namespace> # kubectl describe pv <pv-name> # 登录节点查看挂载: df -h, mount, dmesg ​ # 7. 查看kubelet状态 # 登录节点执行: systemctl status kubelet # journalctl -u kubelet -f --since "10 minutes ago" ​ # 8. 查看容器运行时 # 登录节点执行: crictl ps -a # crictl logs <container-id> # crictl inspect <container-id> ​ # 9. 执行具体排障操作(根据故障类型调整) echo "执行具体排障操作..." echo "请根据排障方案执行具体步骤" ​ # 10. 应用修复配置 # kubectl apply -f /tmp/fix_config.yaml # kubectl rollout restart deployment/<name> -n <namespace> # kubectl rollout status deployment/<name> -n <namespace> --timeout=120s ​

4. 应急恢复与业务验证

# 1. 验证集群状态 kubectl get nodes -o wide # 预期:所有节点 Ready 状态 ​ # 2. 验证核心组件 kubectl get pods -n kube-system -o wide # 预期:所有核心组件 Pod Running,READY 正常 ​ # 3. 验证业务Pod kubectl get pods -A | grep -vE 'Running|Completed|NAME' # 预期:无异常Pod ​ # 4. 验证业务服务 # kubectl get svc -n <namespace> # kubectl get endpoints -n <namespace> # 预期:Service 有对应 Endpoints ​ # 5. 验证网络连通性 # kubectl run -it --rm debug --image=busybox --restart=Never -- nslookup kubernetes.default # 预期:DNS解析正常 # kubectl run -it --rm debug --image=busybox --restart=Never -- wget -O- http://<service-name>.<namespace>.svc.cluster.local # 预期:服务访问正常 ​ # 6. 验证存储 kubectl get pvc -A # 预期:PVC Bound 状态 # kubectl exec -it <pod-with-pvc> -- df -h # 预期:存储挂载正常 ​ # 7. 验证资源使用 kubectl top nodes kubectl top pods -A --sort-by='cpu' | head -10 # 预期:资源使用在合理范围内 ​ # 8. 验证监控告警 # 检查Prometheus Targets状态 # 检查Grafana面板数据 # 检查Alertmanager告警状态 # 预期:监控正常,无异常告警 ​ # 9. 验证业务功能 # 执行业务接口测试 # curl http://<业务地址>/health # 预期:业务接口返回正常 ​ # 10. 清理调试资源 # kubectl delete pod debug --ignore-not-found # kubectl delete -f /tmp/debug_resources.yaml 2>/dev/null echo "验证完成" ​

5. 根因修复与预防配置

# 1. 配置监控告警 # 检查Prometheus告警规则 # kubectl get cm -n monitoring prometheus-rules -o yaml 2>/dev/null | head -100 ​ # 2. 配置日志采集 # 检查日志采集配置 # kubectl get cm -n logging -o name 2>/dev/null | head -10 ​ # 3. 配置资源限制 # 检查Deployment资源限制 # kubectl get deployment -n <namespace> -o jsonpath='{.items[*].spec.template.spec.containers[*].resources}' ​ # 4. 配置高可用 # 检查副本数和反亲和性 # kubectl get deployment -n <namespace> -o jsonpath='{.items[*].spec.replicas}' # kubectl get deployment -n <namespace> -o jsonpath='{.items[*].spec.template.spec.affinity}' ​ # 5. 配置备份策略 # 检查etcd备份 # kubectl get cronjob -A 2>/dev/null | grep -i backup # 检查PV快照 # kubectl get volumesnapshot -A 2>/dev/null ​ # 6. 配置安全策略 # 检查RBAC权限 # kubectl get clusterrolebinding -o name | head -20 # 检查网络策略 # kubectl get networkpolicy -A 2>/dev/null ​ # 7. 配置节点维护 # 检查节点污点和标签 # kubectl get nodes -o jsonpath='{.items[*].spec.taints}' # kubectl get nodes --show-labels ​ # 8. 配置升级策略 # 检查集群版本 # kubectl version --short # 检查节点版本 # kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.kubeletVersion}' ​

6. 最终验证与排障报告

# 1. 最终验证集群状态 kubectl get nodes -o wide kubectl get pods -A -o wide | grep -vE 'Running|Completed|NAME' | wc -l # 预期:异常Pod数为0 ​ # 2. 验证核心组件健康 kubectl get --raw='/healthz?verbose' 2>/dev/null | head -20 # 预期:所有健康检查通过 ​ # 3. 验证业务服务 # kubectl get svc -A # kubectl get endpoints -A # 预期:所有Service有对应Endpoints ​ # 4. 验证监控数据 # 检查Prometheus指标 # kubectl port-forward -n monitoring svc/prometheus 9090:9090 & # sleep 5 # curl -s 'http://localhost:9090/api/v1/query?query=up' | jq '.data.result | length' # 预期:指标数据正常 ​ # 5. 验证日志 # 检查日志采集 # kubectl logs -n logging <fluentd-pod> --tail=10 2>/dev/null # 预期:日志正常采集 ​ # 6. 生成排障报告 echo "=== 排障报告 ===" > /tmp/troubleshoot_report.txt echo "排障时间: $(date)" >> /tmp/troubleshoot_report.txt echo "故障现象: " >> /tmp/troubleshoot_report.txt echo "根因分析: " >> /tmp/troubleshoot_report.txt echo "修复措施: " >> /tmp/troubleshoot_report.txt echo "验证结果: " >> /tmp/troubleshoot_report.txt echo "预防措施: " >> /tmp/troubleshoot_report.txt echo "经验总结: " >> /tmp/troubleshoot_report.txt cat /tmp/troubleshoot_report.txt ​ # 7. 清理临时文件 # rm -f /tmp/debug_*.yaml /tmp/troubleshoot_*.txt 2>/dev/null # echo "临时文件已清理" ​ # 8. 清理port-forward # pkill -f "port-forward" 2>/dev/null echo "排障完成" ​

验证流程

# 1. 集群状态验证 kubectl get nodes -o wide # 预期:所有节点 Ready ​ # 2. 核心组件验证 kubectl get pods -n kube-system -o wide # 预期:所有核心组件 Running ​ # 3. 业务Pod验证 kubectl get pods -A | grep -vE 'Running|Completed|NAME' # 预期:无异常Pod ​ # 4. 服务连通性验证 # kubectl run -it --rm debug --image=busybox --restart=Never -- nslookup kubernetes.default # 预期:DNS正常 ​ # 5. 资源使用验证 kubectl top nodes kubectl top pods -A --sort-by='cpu' | head -10 # 预期:资源合理 ​ # 6. 监控告警验证 # 检查Prometheus/Grafana/Alertmanager状态 # 预期:监控正常 ​ # 7. 业务功能验证 # curl http://<业务地址>/health # 预期:业务正常 ​ # 8. 排障报告验证 cat /tmp/troubleshoot_report.txt # 预期:报告完整 ​

排错方案

  • kube-apiserver 异常:检查Pod状态、日志、证书、RBAC、请求超时、负载均衡、etcd连通性、资源限制、端口监听

  • kube-controller-manager 异常:检查Pod状态、日志、leader选举、队列堆积、资源限制、证书、API连通性、控制器状态

  • kube-scheduler 异常:检查Pod状态、日志、leader选举、调度队列、抢占策略、优先级配置、资源限制、调度延迟

  • etcd 异常:检查集群健康、成员状态、数据备份、磁盘IO、证书、leader选举、数据一致性、压缩碎片、空间配额

  • kubelet 异常:检查服务状态、日志、配置文件、证书、资源阈值、PLEG、容器运行时、节点状态、Pod生命周期

  • kube-proxy 异常:检查服务状态、日志、iptables/ipvs规则、模式配置、端口监听、网络连通性、规则堆积、性能

  • CoreDNS 异常:检查Pod状态、日志、解析配置、上游DNS、缓存、转发规则、服务发现、网络策略、资源限制

  • 核心组件证书过期:检查证书有效期、自动轮换、CA证书、服务证书、客户端证书、kubeconfig、密钥管理、轮换流程

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/8 13:01:38

别再信“只差一刀”!拼多多砍价算法背后的产品设计与用户心理

“只差一刀”这四个字&#xff0c;我估计很多人都被它折磨过。明明进度条已经走到99.9%&#xff0c;系统提示再邀请1人就能免费拿&#xff0c;结果你连发十几个列表好友&#xff0c;进度条纹丝不动&#xff0c;甚至最后“间隔期未到”直接让你白忙活一晚上。作为一个常年在各种…

作者头像 李华
网站建设 2026/10/8 13:00:52

高分宝宝起名案例参考,好听顺口寓意上乘

前阵子吾身边有个同事家里刚添了个健康的男宝宝&#xff0c;他们全家为了给孩子起个合适的名字&#xff0c;愁得连饭都吃不下&#xff0c;最终真实没辙&#xff0c;找了个懂起名门道的专业老师&#xff0c;起出来的名字不光喊着顺口好听&#xff0c;寓意还格外真实不飘&#xf…

作者头像 李华
网站建设 2026/10/8 13:00:31

eFuse+MCU实现智能电源保护:基于TPS259483与MK24FN256VDC12的设计

板子第一次上电&#xff0c;我最紧张的不是代码编译不过&#xff0c;而是电源路径上哪个小角落突然冒烟。做嵌入式这几年&#xff0c;挨过的板子多了之后你会发现&#xff0c;MCU再聪明、传感器再贵&#xff0c;电源一旦出问题&#xff0c;前面的努力全白费。这次项目核心就一件…

作者头像 李华
网站建设 2026/10/8 13:00:16

TPS259483AYWPR与PIC24EP512GU810协同实现工业级电源路径保护

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/10/8 13:00:13

php smarty的预保留变量总结

前言 严格说&#xff0c;Smarty 里并没有一个叫「预保留变量」的官方分类。这个说法指的是一组以 $smarty 为前缀、由 Smarty 自己在模板里提供的内置数据&#xff1a;常量、配置项、循环信息、请求参数镜像、当前模板信息等等。它们的共同点是&#xff1a;不需要你 assign()&a…

作者头像 李华