Kubernetes集群健康检查全攻略从监控指标到故障维护的完整指南帮助运维人员快速定位问题保障系统高可用

威震华夏关云长

引言

Kubernetes作为容器编排领域的领导者，已被广泛应用于企业级应用部署和管理。随着集群规模的增长和复杂性的提升，确保集群的健康状态变得至关重要。一个健康的Kubernetes集群不仅能够提供稳定的服务，还能在出现问题时快速恢复，保障业务连续性。本文将全面介绍Kubernetes集群健康检查的方法、工具和最佳实践，帮助运维人员构建完善的监控体系，快速定位并解决问题，确保系统的高可用性。

Kubernetes集群监控基础

核心组件和架构

在深入监控之前，我们需要了解Kubernetes集群的核心组件及其架构。一个典型的Kubernetes集群由控制平面（Control Plane）和工作节点（Worker Nodes）组成。

控制平面组件包括：

• kube-apiserver：集群的统一入口，处理RESTful操作
• etcd：分布式键值存储，保存集群所有状态数据
• kube-scheduler：负责Pod调度决策
• kube-controller-manager：运行控制器进程
• cloud-controller-manager：与云服务提供商交互的组件

工作节点组件包括：

• kubelet：确保容器在Pod中运行
• kube-proxy：维护节点网络规则
• 容器运行时：如Docker、containerd等

了解这些组件有助于我们确定监控的关键点和指标。

常见监控指标

Kubernetes集群的监控指标可以分为以下几类：

• CPU使用率：节点和Pod的CPU消耗情况
• 内存使用率：节点和Pod的内存消耗情况
• 磁盘使用率：节点磁盘空间使用情况
• 网络I/O：节点和Pod的网络流量

• 组件运行状态：各核心组件是否正常运行
• API服务器响应时间：API请求的处理延迟
• etcd性能指标：etcd的读写延迟和存储情况

• Pod状态：运行中、待定、失败、成功等状态的数量
• 节点状态：就绪、未就绪、不可达等状态的数量
• Deployment状态：副本数量、可用副本数量、更新状态等
• PVC状态：绑定状态、容量使用情况等

• HTTP请求成功率：应用服务的HTTP响应状态码统计
• 请求延迟：应用服务的响应时间
• 错误率：应用服务的错误请求比例

监控工具与方案

Kubernetes内置监控能力

Kubernetes提供了一些内置的监控能力，可以帮助我们了解集群的基本状态。

kubectl是Kubernetes的命令行工具，通过它可以获取集群的各种状态信息。

2. # 查看集群组件状态
3. kubectl get componentstatuses
5. # 查看节点状态
6. kubectl get nodes
8. # 查看所有命名空间中的Pod状态
9. kubectl get pods --all-namespaces
11. # 查看特定资源详细信息
12. kubectl describe nodes <node-name>
13. kubectl describe pods <pod-name> -n <namespace>
15. # 查看资源使用情况
16. kubectl top nodes
17. kubectl top pods --all-namespaces

复制代码

Metrics Server是Kubernetes内置的资源使用数据收集器，它可以收集节点和Pod的CPU和内存使用情况。

安装Metrics Server：

2. kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

复制代码

安装完成后，可以使用kubectl top命令查看资源使用情况。

第三方监控工具

Prometheus是一个开源的监控和告警系统，特别适合于Kubernetes环境。Grafana则是一个可视化工具，可以创建丰富的仪表板。

部署Prometheus和Grafana：

可以使用Helm来快速部署：

2. # 添加Helm仓库
3. helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
4. helm repo update
6. # 安装Prometheus
7. helm install prometheus prometheus-community/kube-prometheus-stack
9. # 查看部署状态
10. kubectl get pods -n default

复制代码

配置Prometheus监控Kubernetes：

Prometheus可以通过ServiceMonitor资源自动发现和监控Kubernetes资源。以下是一个示例ServiceMonitor配置：

2. apiVersion: monitoring.coreos.com/v1
3. kind: ServiceMonitor
4. metadata:
5.   name: example-app
6.   namespace: monitoring
7. spec:
8.   selector:
9.     matchLabels:
10.       app: example-app
11.   endpoints:
12.   - port: web
13.     interval: 30s
14.     path: /metrics

复制代码

Grafana仪表板：

Grafana提供了许多预置的Kubernetes监控仪表板，可以直接导入使用。一些常用的仪表板ID包括：

• 315：Kubernetes Cluster Monitoring
• 6417：Kubernetes Compute Resources / Pod
• 11074：Kubernetes API Server

除了Prometheus和Grafana，还有其他一些优秀的监控工具：

1. Datadog：提供全面的云原生监控解决方案
2. Sysdig：专注于容器安全和性能监控
3. New Relic：全栈可观测性平台
4. Elastic Stack (ELK)：用于日志收集、搜索和分析

健康检查策略

Pod健康检查

Kubernetes提供了两种Pod健康检查机制：存活探针（Liveness Probe）和就绪探针（Readiness Probe）。

存活探针用于确定容器是否正在运行。如果探针失败，kubelet会杀死容器，并根据重启策略进行重启。

存活探针示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: liveness-pod
6. spec:
7.   containers:
8.   - name: liveness-container
9.     image: k8s.gcr.io/busybox
10.     args:
11.     - /bin/sh
12.     - -c
13.     - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
14.     livenessProbe:
15.       exec:
16.         command:
17.         - cat
18.         - /tmp/healthy
19.       initialDelaySeconds: 5
20.       periodSeconds: 5

复制代码

就绪探针用于确定容器是否准备好接收流量。如果探针失败，Pod将从服务的负载均衡中移除。

就绪探针示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: readiness-pod
6. spec:
7.   containers:
8.   - name: readiness-container
9.     image: k8s.gcr.io/busybox
10.     args:
11.     - /bin/sh
12.     - -c
13.     - touch /tmp/ready; sleep 30; rm -rf /tmp/ready; sleep 600
14.     readinessProbe:
15.       exec:
16.         command:
17.         - cat
18.         - /tmp/ready
19.       initialDelaySeconds: 5
20.       periodSeconds: 5

复制代码

启动探针用于确定容器应用是否已经启动。在启动探针成功之前，其他探针不会生效。

启动探针示例：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: startup-pod
6. spec:
7.   containers:
8.   - name: startup-container
9.     image: k8s.gcr.io/busybox
10.     args:
11.     - /bin/sh
12.     - -c
13.     - sleep 60; touch /tmp/started; sleep 600
14.     startupProbe:
15.       exec:
16.         command:
17.         - cat
18.         - /tmp/started
19.       failureThreshold: 30
20.       periodSeconds: 10

复制代码

节点健康检查

节点健康检查是确保Kubernetes集群稳定运行的重要环节。Kubernetes通过kubelet和节点控制器来监控节点状态。

2. # 查看节点状态
3. kubectl get nodes
5. # 查看节点详细信息
6. kubectl describe node <node-name>
8. # 查看节点上的资源使用情况
9. kubectl top node <node-name>

复制代码

节点问题检测器是一个守护程序，用于监控节点的健康状况，并以事件的形式报告问题。

部署节点问题检测器：

2. apiVersion: v1
3. kind: DaemonSet
4. metadata:
5.   name: node-problem-detector
6.   namespace: kube-system
7. spec:
8.   selector:
9.     matchLabels:
10.       app: node-problem-detector
11.   template:
12.     metadata:
13.       labels:
14.         app: node-problem-detector
15.     spec:
16.       containers:
17.       - name: node-problem-detector
18.         image: k8s.gcr.io/node-problem-detector:v0.8.7
19.         command:
20.         - "/bin/node-problem-detector"
21.         - "--logtostderr"
22.         - "--system-log-monitors=/config/kernel-monitor.json,/config/docker-monitor.json"
23.         volumeMounts:
24.         - name: log
25.           mountPath: /var/log
26.         - name: config
27.           mountPath: /config
28.       volumes:
29.       - name: log
30.         hostPath:
31.           path: /var/log/
32.       - name: config
33.         configMap:
34.           name: node-problem-detector-config

复制代码

集群组件健康检查

集群组件的健康检查对于确保整个集群的正常运行至关重要。

2. # 查看控制平面组件状态
3. kubectl get componentstatuses
5. # 检查API服务器连接
6. kubectl cluster-info
8. # 检查etcd健康状态
9. kubectl get --raw='/healthz?verbose'
11. # 检查各个命名空间中的Pod状态
12. kubectl get pods --all-namespaces -o wide

复制代码

Kubernetes控制平面组件提供了健康检查端点，可以通过HTTP请求来检查其状态：

2. # API服务器健康检查
3. curl -k https://<api-server-ip>:6443/healthz
5. # etcd健康检查
6. curl -L http://<etcd-ip>:2379/health
8. # 调度器健康检查
9. curl -L http://<scheduler-ip>:10251/healthz
11. # 控制器管理器健康检查
12. curl -L http://<controller-manager-ip>:10252/healthz

复制代码

日志管理与分析

日志收集策略

在Kubernetes环境中，日志收集是故障排查的重要手段。由于Pod是短暂的，日志需要被持久化和集中管理。

Kubernetes默认会将容器的标准输出和错误输出保存到节点的/var/log/containers目录下。可以通过以下命令查看Pod日志：

2. # 查看Pod日志
3. kubectl logs <pod-name> -n <namespace>
5. # 查看特定容器的日志
6. kubectl logs <pod-name> -c <container-name> -n <namespace>
8. # 查看最近几行日志
9. kubectl logs --tail=100 <pod-name> -n <namespace>
11. # 查看并跟踪日志输出
12. kubectl logs -f <pod-name> -n <namespace>
14. # 查看之前实例的日志（Pod重启后）
15. kubectl logs --previous <pod-name> -n <namespace>

复制代码

使用DaemonSet在每个节点上部署日志收集代理是常见的做法。以下是使用Fluentd作为日志收集代理的示例：

2. apiVersion: v1
3. kind: ServiceAccount
4. metadata:
5.   name: fluentd
6.   namespace: kube-system
7. ---
8. apiVersion: rbac.authorization.k8s.io/v1
9. kind: ClusterRole
10. metadata:
11.   name: fluentd
12. rules:
13. - apiGroups: [""]
14.   resources:
15.   - namespaces
16.   - pods
17.   verbs: ["get", "list", "watch"]
18. ---
19. apiVersion: rbac.authorization.k8s.io/v1
20. kind: ClusterRoleBinding
21. metadata:
22.   name: fluentd
23. roleRef:
24.   kind: ClusterRole
25.   name: fluentd
26.   apiGroup: rbac.authorization.k8s.io
27. subjects:
28. - kind: ServiceAccount
29.   name: fluentd
30.   namespace: kube-system
31. ---
32. apiVersion: apps/v1
33. kind: DaemonSet
34. metadata:
35.   name: fluentd
36.   namespace: kube-system
37.   labels:
38.     k8s-app: fluentd-logging
39.     version: v1
40. spec:
41.   selector:
42.     matchLabels:
43.       k8s-app: fluentd-logging
44.   template:
45.     metadata:
46.       labels:
47.         k8s-app: fluentd-logging
48.         version: v1
49.     spec:
50.       serviceAccount: fluentd
51.       tolerations:
52.       - key: node-role.kubernetes.io/master
53.         effect: NoSchedule
54.       containers:
55.       - name: fluentd
56.         image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch
57.         env:
58.           - name:  FLUENT_ELASTICSEARCH_HOST
59.             value: "elasticsearch-logging"
60.           - name:  FLUENT_ELASTICSEARCH_PORT
61.             value: "9200"
62.           - name: FLUENT_ELASTICSEARCH_SCHEME
63.             value: "http"
64.           - name: FLUENTD_SYSTEMD_CONF
65.             value: "disable"
66.         resources:
67.           limits:
68.             memory: 512Mi
69.           requests:
70.             cpu: 100m
71.             memory: 200Mi
72.         volumeMounts:
73.         - name: varlog
74.           mountPath: /var/log
75.         - name: varlibdockercontainers
76.           mountPath: /var/lib/docker/containers
77.           readOnly: true
78.       terminationGracePeriodSeconds: 30
79.       volumes:
80.       - name: varlog
81.         hostPath:
82.           path: /var/log
83.       - name: varlibdockercontainers
84.         hostPath:
85.           path: /var/lib/docker/containers

复制代码

日志分析工具

EFK（Elasticsearch + Fluentd + Kibana）是Kubernetes环境中常用的日志分析解决方案。

部署Elasticsearch：

2. apiVersion: apps/v1
3. kind: StatefulSet
4. metadata:
5.   name: elasticsearch
6.   namespace: kube-system
7. spec:
8.   serviceName: elasticsearch
9.   replicas: 1
10.   selector:
11.     matchLabels:
12.       app: elasticsearch
13.   template:
14.     metadata:
15.       labels:
16.         app: elasticsearch
17.     spec:
18.       containers:
19.       - name: elasticsearch
20.         image: docker.elastic.co/elasticsearch/elasticsearch:7.10.1
21.         ports:
22.         - containerPort: 9200
23.           name: http
24.           protocol: TCP
25.         - containerPort: 9300
26.           name: transport
27.           protocol: TCP
28.         env:
29.           - name: discovery.type
30.             value: single-node
31.         resources:
32.           limits:
33.             cpu: 1000m
34.             memory: 2Gi
35.           requests:
36.             cpu: 100m
37.             memory: 1Gi
38.         volumeMounts:
39.         - name: data
40.           mountPath: /usr/share/elasticsearch/data
41.   volumeClaimTemplates:
42.   - metadata:
43.       name: data
44.     spec:
45.       accessModes: [ "ReadWriteOnce" ]
46.       resources:
47.         requests:
48.           storage: 10Gi
49. ---
50. apiVersion: v1
51. kind: Service
52. metadata:
53.   name: elasticsearch
54.   namespace: kube-system
55. spec:
56.   ports:
57.   - port: 9200
58.     name: http
59.   selector:
60.     app: elasticsearch

复制代码

部署Kibana：

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: kibana
6.   namespace: kube-system
7. spec:
8.   replicas: 1
9.   selector:
10.     matchLabels:
11.       app: kibana
12.   template:
13.     metadata:
14.       labels:
15.         app: kibana
16.     spec:
17.       containers:
18.       - name: kibana
19.         image: docker.elastic.co/kibana/kibana:7.10.1
20.         ports:
21.         - containerPort: 5601
22.         env:
23.           - name: ELASTICSEARCH_HOSTS
24.             value: http://elasticsearch:9200
25.         resources:
26.           limits:
27.             cpu: 1000m
28.             memory: 1Gi
29.           requests:
30.             cpu: 100m
31.             memory: 512Mi
32. ---
33. apiVersion: v1
34. kind: Service
35. metadata:
36.   name: kibana
37.   namespace: kube-system
38. spec:
39.   ports:
40.   - port: 5601
41.     protocol: TCP
42.     targetPort: 5601
43.   selector:
44.     app: kibana
45.   type: LoadBalancer

复制代码

Loki是一个受Prometheus启发的日志聚合系统，与Grafana集成良好，提供了轻量级的日志解决方案。

部署Loki：

2. apiVersion: v1
3. kind: ConfigMap
4. metadata:
5.   name: loki-config
6.   namespace: monitoring
7. data:
8.   loki.yaml: |
9.     auth_enabled: false
10.     server:
11.       http_listen_port: 3100
12.     ingester:
13.       lifecycler:
14.         ring:
15.           kvstore:
16.             store: inmemory
17.           replication_factor: 1
18.     schema_config:
19.       configs:
20.         - from: 2020-10-24
21.           store: boltdb-shipper
22.           object_store: filesystem
23.           schema: v11
24.           index:
25.             prefix: index_
26.             period: 24h
27.     storage_config:
28.       boltdb_shipper:
29.         active_index_directory: /data/loki/index
30.         cache_location: /data/loki/cache
31.         cache_ttl: 24h
32.         shared_store: filesystem
33.       filesystem:
34.         directory: /data/loki/chunks
35.     limits_config:
36.       enforce_metric_name: false
37.       reject_old_samples: true
38.       reject_old_samples_max_age: 168h
39.     chunk_store_config:
40.       max_look_back_period: 0s
41.     table_manager:
42.       retention_deletes_enabled: false
43.       retention_period: 0s
44.     compactor:
45.       working_directory: /data/loki/compactor
46.       shared_store: filesystem
47. ---
48. apiVersion: apps/v1
49. kind: StatefulSet
50. metadata:
51.   name: loki
52.   namespace: monitoring
53. spec:
54.   replicas: 1
55.   selector:
56.     matchLabels:
57.       app: loki
58.   template:
59.     metadata:
60.       labels:
61.         app: loki
62.     spec:
63.       containers:
64.       - name: loki
65.         image: grafana/loki:2.4.0
66.         args:
67.         - -config.file=/etc/loki/loki.yaml
68.         ports:
69.         - containerPort: 3100
70.           name: http
71.         volumeMounts:
72.         - name: config
73.           mountPath: /etc/loki
74.         - name: storage
75.           mountPath: /data
76.       volumes:
77.       - name: config
78.         configMap:
79.           name: loki-config
80.   volumeClaimTemplates:
81.   - metadata:
82.       name: storage
83.     spec:
84.       accessModes: [ "ReadWriteOnce" ]
85.       resources:
86.         requests:
87.           storage: 10Gi
88. ---
89. apiVersion: v1
90. kind: Service
91. metadata:
92.   name: loki
93.   namespace: monitoring
94. spec:
95.   ports:
96.   - port: 3100
97.     name: http
98.   selector:
99.     app: loki

复制代码

部署Promtail（日志收集代理）：

2. apiVersion: v1
3. kind: ConfigMap
4. metadata:
5.   name: promtail-config
6.   namespace: monitoring
7. data:
8.   promtail.yaml: |
9.     server:
10.       http_listen_port: 9080
11.       grpc_listen_port: 0
12.     positions:
13.       filename: /tmp/positions.yaml
14.     clients:
15.       - url: http://loki:3100/loki/api/v1/push
16.     scrape_configs:
17.     - job_name: kubernetes-pods
18.       kubernetes_sd_configs:
19.       - role: pod
20.       pipeline_stages:
21.       - docker: {}
22.       relabel_configs:
23.       - source_labels:
24.         - __meta_kubernetes_pod_label_app
25.         target_label: app
26.       - source_labels:
27.         - __meta_kubernetes_pod_node_name
28.         target_label: node
29.       - source_labels:
30.         - __meta_kubernetes_namespace
31.         target_label: namespace
32.       - source_labels:
33.         - __meta_kubernetes_pod_name
34.         target_label: pod
35.       - source_labels:
36.         - __meta_kubernetes_pod_container_name
37.         target_label: container
38.       - source_labels:
39.         - __meta_kubernetes_pod_label_app_kubernetes_io_component
40.         target_label: component
41. ---
42. apiVersion: apps/v1
43. kind: DaemonSet
44. metadata:
45.   name: promtail
46.   namespace: monitoring
47. spec:
48.   selector:
49.     matchLabels:
50.       app: promtail
51.   template:
52.     metadata:
53.       labels:
54.         app: promtail
55.     spec:
56.       serviceAccount: promtail
57.       containers:
58.       - name: promtail
59.         image: grafana/promtail:2.4.0
60.         args:
61.         - -config.file=/etc/promtail/promtail.yaml
62.         ports:
63.         - containerPort: 9080
64.           name: http
65.         volumeMounts:
66.         - name: config
67.           mountPath: /etc/promtail
68.         - name: containers
69.           mountPath: /var/lib/docker/containers
70.           readOnly: true
71.         - name: pods
72.           mountPath: /var/log/pods
73.           readOnly: true
74.       volumes:
75.       - name: config
76.         configMap:
77.           name: promtail-config
78.       - name: containers
79.         hostPath:
80.           path: /var/lib/docker/containers
81.       - name: pods
82.         hostPath:
83.           path: /var/log/pods

复制代码

故障诊断与排查

常见故障类型

Kubernetes集群中常见的故障类型包括：

节点故障可能由硬件问题、系统崩溃或网络问题引起。表现为节点状态为NotReady。

排查步骤：

2. # 检查节点状态
3. kubectl get nodes
5. # 查看节点详细信息
6. kubectl describe node <node-name>
8. # 检查节点上的kubelet日志
9. ssh <node-name> 'journalctl -u kubelet -f'
11. # 检查节点资源使用情况
12. kubectl top node <node-name>

复制代码

Pod故障可能由资源不足、镜像问题、配置错误等引起。表现为Pod状态为Pending、CrashLoopBackOff或Error。

排查步骤：

2. # 检查Pod状态
3. kubectl get pods -n <namespace>
5. # 查看Pod详细信息
6. kubectl describe pod <pod-name> -n <namespace>
8. # 查看Pod日志
9. kubectl logs <pod-name> -n <namespace>
11. # 如果Pod重启，查看前一实例日志
12. kubectl logs --previous <pod-name> -n <namespace>
14. # 检查Pod事件
15. kubectl get events -n <namespace> --field-selector involvedObject.name=<pod-name>

复制代码

网络故障可能导致Pod间通信失败、服务不可访问等问题。

排查步骤：

2. # 检查Pod IP
3. kubectl get pods -n <namespace> -o wide
5. # 检查服务状态
6. kubectl get svc -n <namespace>
8. # 检查端点状态
9. kubectl get endpoints -n <namespace>
11. # 进入Pod测试网络连接
12. kubectl exec -it <pod-name> -n <namespace> -- /bin/bash
13. # 在Pod内执行
14. ping <target-ip>
15. nslookup <service-name>
16. curl <service-url>
18. # 检查网络插件状态
19. kubectl get pods -n kube-system | grep -E 'calico|flannel|weave|cilium'

复制代码

存储故障可能导致PVC无法绑定、Pod无法挂载卷等问题。

排查步骤：

2. # 检查PVC状态
3. kubectl get pvc -n <namespace>
5. # 检查PV状态
6. kubectl get pv
8. # 查看PVC详细信息
9. kubectl describe pvc <pvc-name> -n <namespace>
11. # 检查存储类
12. kubectl get storageclass
14. # 检查存储提供者状态
15. kubectl get pods -n kube-system | grep -E 'csi|provisioner'

复制代码

故障排查流程

一个系统化的故障排查流程可以帮助快速定位和解决问题。

首先确定问题是影响整个集群、单个节点还是特定应用。

2. # 检查集群整体状态
3. kubectl cluster-info
5. # 检查节点状态
6. kubectl get nodes
8. # 检查核心组件状态
9. kubectl get pods -n kube-system

复制代码

收集与问题相关的日志、事件和指标。

2. # 查看集群事件
3. kubectl get events --all-namespaces --sort-by='.metadata.creationTimestamp'
5. # 查看资源使用情况
6. kubectl top nodes
7. kubectl top pods --all-namespaces
9. # 收集节点信息
10. kubectl get nodes -o wide

复制代码

根据收集的信息分析可能的原因。

2. # 检查Pod状态
3. kubectl get pods --all-namespaces -o wide
5. # 检查未调度的Pod
6. kubectl get pods --all-namespaces --field-selector spec.nodeName=
8. # 检查失败的Pod
9. kubectl get pods --all-namespaces --field-selector status.phase=Failed

复制代码

根据分析结果实施相应的解决方案。

2. # 重启Pod
3. kubectl delete pod <pod-name> -n <namespace>
5. # 扩容Deployment
6. kubectl scale deployment <deployment-name> --replicas=<new-replica-count> -n <namespace>
8. # 排空节点
9. kubectl cordon <node-name>
10. kubectl drain <node-name> --ignore-daemonsets --delete-local-data

复制代码

验证问题是否已解决。

2. # 检查Pod状态
3. kubectl get pods -n <namespace>
5. # 检查服务可用性
6. kubectl get svc -n <namespace>
7. curl <service-url>
9. # 检查应用日志
10. kubectl logs <pod-name> -n <namespace>

复制代码

实用排查命令和工具

2. # 查看集群信息
3. kubectl cluster-info
5. # 查看资源详细信息
6. kubectl describe <resource-type> <resource-name>
8. # 查看资源YAML配置
9. kubectl get <resource-type> <resource-name> -o yaml
11. # 查看资源标签
12. kubectl get <resource-type> --show-labels
14. # 根据标签选择资源
15. kubectl get <resource-type> -l <label-key>=<label-value>
17. # 查看资源注解
18. kubectl get <resource-type> <resource-name> -o jsonpath='{.metadata.annotations}'
20. # 查看Pod容器镜像
21. kubectl get pods <pod-name> -n <namespace> -o jsonpath='{.spec.containers[*].image}{"\n"}'
23. # 查看Pod资源请求和限制
24. kubectl get pods <pod-name> -n <namespace> -o jsonpath='{.spec.containers[*].resources}{"\n"}'

复制代码

2. # 创建调试Pod
3. kubectl run debug-pod --image=busybox -- sleep 3600
5. # 进入Pod
6. kubectl exec -it debug-pod -- /bin/sh
8. # 在Pod内安装网络工具
9. # 在Pod内执行
10. apt-get update && apt-get install -y iputils-ping dnsutils curl telnet
12. # 测试DNS解析
13. nslookup kubernetes.default
14. nslookup <service-name>.<namespace>.svc.cluster.local
16. # 测试网络连接
17. ping <target-ip>
18. curl <target-url>
19. telnet <target-host> <target-port>
21. # 检查路由表
22. ip route

复制代码

2. # 查看节点资源分配
3. kubectl describe nodes | grep -i "allocated resources"
5. # 查看命名空间资源使用情况
6. kubectl describe quota -n <namespace>
8. # 查看资源限制范围
9. kubectl get limitrange -n <namespace>
11. # 查看Pod资源使用历史（需要Metrics Server）
12. kubectl top pods --all-namespaces --sort-by=cpu
13. kubectl top pods --all-namespaces --sort-by=memory

复制代码

自动化运维与告警

告警策略设计

有效的告警策略可以帮助运维人员及时发现并处理问题，避免小问题演变成大故障。

建议设计以下告警级别：

1. 紧急（Critical）：影响核心业务，需要立即处理核心服务不可用数据丢失风险安全漏洞
2. 核心服务不可用
3. 数据丢失风险
4. 安全漏洞
5. 高（High）：影响业务功能，需要尽快处理非核心服务不可用性能严重下降资源即将耗尽
6. 非核心服务不可用
7. 性能严重下降
8. 资源即将耗尽
9. 中（Medium）：潜在风险，需要关注资源使用率过高错误率增加备份失败
10. 资源使用率过高
11. 错误率增加
12. 备份失败
13. 低（Low）：信息性告警，需要记录配置变更计划内维护性能轻微下降
14. 配置变更
15. 计划内维护
16. 性能轻微下降

紧急（Critical）：影响核心业务，需要立即处理

• 核心服务不可用
• 数据丢失风险
• 安全漏洞

高（High）：影响业务功能，需要尽快处理

• 非核心服务不可用
• 性能严重下降
• 资源即将耗尽

中（Medium）：潜在风险，需要关注

• 资源使用率过高
• 错误率增加
• 备份失败

低（Low）：信息性告警，需要记录

• 配置变更
• 计划内维护
• 性能轻微下降

使用Prometheus配置告警规则的示例：

2. groups:
3. - name: kubernetes-apps
4.   rules:
5.   - alert: PodCrashLooping
6.     expr: kube_pod_container_status_restarts_total > 2
7.     for: 15m
8.     labels:
9.       severity: critical
10.     annotations:
11.       summary: "Pod {{ $labels.pod }} is crash looping (namespace {{ $labels.namespace }})"
12.       description: "Pod {{ $labels.pod }} (namespace {{ $labels.namespace }}) has restarted {{ $value }} times in the last 15 minutes."
14.   - alert: PodNotReady
15.     expr: sum by (namespace, pod) (kube_pod_status_ready{condition="false"}) == 1
16.     for: 10m
17.     labels:
18.       severity: high
19.     annotations:
20.       summary: "Pod {{ $labels.pod }} is not ready (namespace {{ $labels.namespace }})"
21.       description: "Pod {{ $labels.pod }} (namespace {{ $labels.namespace }}) has been in a non-ready state for more than 10 minutes."
23. - name: kubernetes-resources
24.   rules:
25.   - alert: NodeMemoryUsage
26.     expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
27.     for: 5m
28.     labels:
29.       severity: high
30.     annotations:
31.       summary: "Node memory usage is high (instance {{ $labels.instance }})"
32.       description: "Node memory usage is above 85% (current value: {{ $value }}%)"
34.   - alert: NodeDiskUsage
35.     expr: (1 - (node_filesystem_avail_bytes / node_filesystem_size_bytes)) * 100 > 85
36.     for: 5m
37.     labels:
38.       severity: high
39.     annotations:
40.       summary: "Node disk usage is high (instance {{ $labels.instance }})"
41.       description: "Node disk usage is above 85% (current value: {{ $value }}%)"

复制代码

自动化恢复机制

自动化恢复可以减少人工干预，提高问题解决速度。

Kubernetes默认提供了Pod自动重启机制，可以通过配置重启策略来控制：

2. apiVersion: v1
3. kind: Pod
4. metadata:
5.   name: restart-pod
6. spec:
7.   restartPolicy: OnFailure  # 可选值：Always、OnFailure、Never
8.   containers:
9.   - name: restart-container
10.     image: busybox
11.     command: ["sh", "-c", "exit 1"]

复制代码

HPA可以根据CPU使用率或其他指标自动调整Deployment的副本数量：

2. apiVersion: autoscaling/v2beta2
3. kind: HorizontalPodAutoscaler
4. metadata:
5.   name: app-hpa
6. spec:
7.   scaleTargetRef:
8.     apiVersion: apps/v1
9.     kind: Deployment
10.     name: app-deployment
11.   minReplicas: 2
12.   maxReplicas: 10
13.   metrics:
14.   - type: Resource
15.     resource:
16.       name: cpu
17.       target:
18.         type: Utilization
19.         averageUtilization: 50
20.   - type: Resource
21.     resource:
22.       name: memory
23.       target:
24.         type: Utilization
25.         averageUtilization: 70

复制代码

VPA可以自动调整Pod的资源请求和限制：

2. apiVersion: autoscaling.k8s.io/v1
3. kind: VerticalPodAutoscaler
4. metadata:
5.   name: app-vpa
6. spec:
7.   targetRef:
8.     apiVersion: "apps/v1"
9.     kind:       Deployment
10.     name:       app-deployment
11.   updatePolicy:
12.     updateMode: "Auto"
13.   resourcePolicy:
14.     containerPolicies:
15.     - containerName: "*"
16.       minAllowed:
17.         cpu: "100m"
18.         memory: "50Mi"
19.       maxAllowed:
20.         cpu: "1"
21.         memory: "500Mi"
22.       controlledResources: ["cpu", "memory"]

复制代码

使用Kubernetes Operator或自定义控制器可以实现更复杂的自动化恢复逻辑。以下是一个简单的自定义控制器示例，用于自动重启失败的Pod：

2. package main
4. import (
5.         "context"
6.         "fmt"
7.         "time"
9.         corev1 "k8s.io/api/core/v1"
10.         metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
11.         "k8s.io/client-go/kubernetes"
12.         "k8s.io/client-go/rest"
13. )
15. func main() {
16.         // 创建Kubernetes客户端
17.         config, err := rest.InClusterConfig()
18.         if err != nil {
19.                 panic(err.Error())
20.         }
21.         clientset, err := kubernetes.NewForConfig(config)
22.         if err != nil {
23.                 panic(err.Error())
24.         }
26.         // 监控所有命名空间中的Pod
27.         for {
28.                 pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{})
29.                 if err != nil {
30.                         panic(err.Error())
31.                 }
33.                 // 检查每个Pod的状态
34.                 for _, pod := range pods.Items {
35.                         if pod.Status.Phase == corev1.PodFailed {
36.                                 fmt.Printf("发现失败的Pod: %s/%s\n", pod.Namespace, pod.Name)
37.                                
38.                                 // 删除失败的Pod，让Deployment或StatefulSet重新创建
39.                                 err := clientset.CoreV1().Pods(pod.Namespace).Delete(context.TODO(), pod.Name, metav1.DeleteOptions{})
40.                                 if err != nil {
41.                                         fmt.Printf("删除Pod失败: %v\n", err)
42.                                 } else {
43.                                         fmt.Printf("已删除失败的Pod: %s/%s\n", pod.Namespace, pod.Name)
44.                                 }
45.                         }
46.                 }
48.                 // 等待一段时间后再次检查
49.                 time.Sleep(30 * time.Second)
50.         }
51. }

复制代码

最佳实践与案例分析

健康检查最佳实践

• 存活探针：用于检测应用是否存活，设置适当的初始延迟和检查间隔
• 就绪探针：用于检测应用是否准备好接收流量，避免过早将流量导向未就绪的Pod
• 启动探针：对于启动时间较长的应用，使用启动探针避免在应用启动期间被存活探针杀死

2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: app-deployment
6. spec:
7.   replicas: 3
8.   template:
9.     spec:
10.       containers:
11.       - name: app-container
12.         image: myapp:1.0
13.         ports:
14.         - containerPort: 8080
15.         startupProbe:
16.           httpGet:
17.             path: /health
18.             port: 8080
19.           failureThreshold: 30
20.           periodSeconds: 10
21.         livenessProbe:
22.           httpGet:
23.             path: /health
24.             port: 8080
25.           initialDelaySeconds: 60
26.           periodSeconds: 10
27.         readinessProbe:
28.           httpGet:
29.             path: /ready
30.             port: 8080
31.           initialDelaySeconds: 5
32.           periodSeconds: 5

复制代码

• 监控集群基础设施（节点、网络、存储）
• 监控Kubernetes组件（API服务器、调度器、控制器管理器等）
• 监控应用性能和可用性
• 设置合理的告警阈值和通知策略

2. # Prometheus监控配置示例
3. apiVersion: v1
4. kind: ConfigMap
5. metadata:
6.   name: prometheus-config
7. data:
8.   prometheus.yml: |
9.     global:
10.       scrape_interval: 15s
11.       evaluation_interval: 15s
12.    
13.     scrape_configs:
14.     - job_name: 'kubernetes-apiservers'
15.       kubernetes_sd_configs:
16.       - role: endpoints
17.       scheme: https
18.       tls_config:
19.         ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
20.       bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
21.       relabel_configs:
22.       - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
23.         action: keep
24.         regex: default;kubernetes;https
25.    
26.     - job_name: 'kubernetes-nodes'
27.       kubernetes_sd_configs:
28.       - role: node
29.       scheme: https
30.       tls_config:
31.         ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
32.       bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
33.       relabel_configs:
34.       - action: labelmap
35.         regex: __meta_kubernetes_node_label_(.+)
36.       - target_label: __address__
37.         replacement: kubernetes.default.svc:443
38.       - source_labels: [__meta_kubernetes_node_name]
39.         regex: (.+)
40.         target_label: __metrics_path__
41.         replacement: /api/v1/nodes/${1}/proxy/metrics
42.    
43.     - job_name: 'kubernetes-pods'
44.       kubernetes_sd_configs:
45.       - role: pod
46.       relabel_configs:
47.       - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
48.         action: keep
49.         regex: true
50.       - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
51.         action: replace
52.         target_label: __metrics_path__
53.         regex: (.+)
54.       - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
55.         action: replace
56.         regex: ([^:]+)(?::\d+)?;(\d+)
57.         replacement: $1:$2
58.         target_label: __address__
59.       - action: labelmap
60.         regex: __meta_kubernetes_pod_label_(.+)
61.       - source_labels: [__meta_kubernetes_namespace]
62.         action: replace
63.         target_label: kubernetes_namespace
64.       - source_labels: [__meta_kubernetes_pod_name]
65.         action: replace
66.         target_label: kubernetes_pod_name

复制代码

• 集中收集所有组件和应用的日志
• 使用结构化日志格式，便于查询和分析
• 设置日志保留策略，平衡存储成本和查询需求
• 实现日志告警，及时发现异常模式

2. # Fluentd日志收集配置示例
3. apiVersion: v1
4. kind: ConfigMap
5. metadata:
6.   name: fluentd-config
7. data:
8.   fluent.conf: |
9.     <source>
10.       @type tail
11.       path /var/log/containers/*_{{.Release.Namespace}}_{{.Chart.Name}}-*.log
12.       pos_file /var/log/fluentd-containers.log.pos
13.       tag kubernetes.*
14.       format json
15.       time_format %Y-%m-%dT%H:%M:%S.%NZ
16.     </source>
18.     <filter kubernetes.**>
19.       @type kubernetes_metadata
20.     </filter>
22.     <match kubernetes.**>
23.       @type elasticsearch
24.       host elasticsearch-logging
25.       port 9200
26.       index_name fluentd
27.       type_name _doc
28.     </match>

复制代码

• 使用自动扩缩容应对负载变化
• 配置自动故障恢复机制
• 实现自动化部署和回滚
• 建立自愈系统，减少人工干预

2. # 自动扩缩容配置示例
3. apiVersion: autoscaling/v2beta2
4. kind: HorizontalPodAutoscaler
5. metadata:
6.   name: app-hpa
7. spec:
8.   scaleTargetRef:
9.     apiVersion: apps/v1
10.     kind: Deployment
11.     name: app-deployment
12.   minReplicas: 2
13.   maxReplicas: 10
14.   metrics:
15.   - type: Resource
16.     resource:
17.       name: cpu
18.       target:
19.         type: Utilization
20.         averageUtilization: 50
21.   behavior:
22.     scaleDown:
23.       stabilizationWindowSeconds: 300
24.       policies:
25.       - type: Percent
26.         value: 10
27.         periodSeconds: 60
28.     scaleUp:
29.       stabilizationWindowSeconds: 60
30.       policies:
31.       - type: Percent
32.         value: 100
33.         periodSeconds: 60
34.       - type: Pods
35.         value: 2
36.         periodSeconds: 60
37.       selectPolicy: Max

复制代码

真实故障案例分析

问题描述：集群中的多个Pod一直处于Pending状态，无法调度到任何节点。

排查过程：

1. 检查Pod状态：

2. kubectl get pods --all-namespaces | grep Pending

复制代码

1. 查看Pod详细信息，发现事件中显示”0/3 nodes are available: 3 Insufficient cpu”或”3 Insufficient memory”。
2. 检查节点资源使用情况：

查看Pod详细信息，发现事件中显示”0/3 nodes are available: 3 Insufficient cpu”或”3 Insufficient memory”。

检查节点资源使用情况：

2. kubectl top nodes
3. kubectl describe nodes | grep -A 5 "Allocated resources"

复制代码

1. 发现节点CPU和内存使用率均超过90%，剩余资源不足以调度新的Pod。

解决方案：

1. 短期解决方案：手动扩容节点或删除不必要的Pod释放资源。

2. # 删除测试或非关键Pod
3. kubectl delete pod <pod-name> -n <namespace>
5. # 手动扩容节点（如果使用云服务）
6. # 例如，在AWS上增加节点组大小
7. aws autoscaling set-desired-capacity --auto-scaling-group-name <asg-name> --desired-capacity <new-size>

复制代码

1. 长期解决方案：配置集群自动扩缩容（Cluster Autoscaler）设置资源请求和限制，避免资源浪费实施Pod优先级和抢占机制，确保关键应用优先获得资源
2. 配置集群自动扩缩容（Cluster Autoscaler）
3. 设置资源请求和限制，避免资源浪费
4. 实施Pod优先级和抢占机制，确保关键应用优先获得资源

• 配置集群自动扩缩容（Cluster Autoscaler）
• 设置资源请求和限制，避免资源浪费
• 实施Pod优先级和抢占机制，确保关键应用优先获得资源

2. # 集群自动扩缩容配置示例
3. apiVersion: v1
4. kind: ServiceAccount
5. metadata:
6.   name: cluster-autoscaler
7.   namespace: kube-system
8. ---
9. apiVersion: rbac.authorization.k8s.io/v1
10. kind: ClusterRole
11. metadata:
12.   name: cluster-autoscaler
13. rules:
14. - apiGroups: [""]
15.   resources: ["events", "endpoints"]
16.   verbs: ["create", "patch"]
17. - apiGroups: [""]
18.   resources: ["pods/eviction"]
19.   verbs: ["create"]
20. - apiGroups: [""]
21.   resources: ["pods/status"]
22.   verbs: ["update"]
23. - apiGroups: [""]
24.   resources: ["nodes"]
25.   verbs: ["watch", "list", "get", "update"]
26. - apiGroups: [""]
27.   resources: ["namespaces"]
28.   verbs: ["watch", "list", "get"]
29. - apiGroups: ["coordination.k8s.io"]
30.   resources: ["leases"]
31.   verbs: ["create"]
32. - apiGroups: ["coordination.k8s.io"]
33.   resources: ["leases"]
34.   resourceNames: ["cluster-autoscaler"]
35.   verbs: ["get", "update"]
36. ---
37. apiVersion: rbac.authorization.k8s.io/v1
38. kind: Role
39. metadata:
40.   name: cluster-autoscaler
41.   namespace: kube-system
42. rules:
43. - apiGroups: [""]
44.   resources: ["configmaps"]
45.   verbs: ["create","list","watch"]
46. - apiGroups: [""]
47.   resources: ["configmaps"]
48.   resourceNames: ["cluster-autoscaler-status"]
49.   verbs: ["delete","get","update","watch"]
50. ---
51. apiVersion: rbac.authorization.k8s.io/v1
52. kind: ClusterRoleBinding
53. metadata:
54.   name: cluster-autoscaler
55. roleRef:
56.   apiGroup: rbac.authorization.k8s.io
57.   kind: ClusterRole
58.   name: cluster-autoscaler
59. subjects:
60. - kind: ServiceAccount
61.   name: cluster-autoscaler
62.   namespace: kube-system
63. ---
64. apiVersion: rbac.authorization.k8s.io/v1
65. kind: RoleBinding
66. metadata:
67.   name: cluster-autoscaler
68.   namespace: kube-system
69. roleRef:
70.   apiGroup: rbac.authorization.k8s.io
71.   kind: Role
72.   name: cluster-autoscaler
73. subjects:
74. - kind: ServiceAccount
75.   name: cluster-autoscaler
76.   namespace: kube-system
77. ---
78. apiVersion: apps/v1
79. kind: Deployment
80. metadata:
81.   name: cluster-autoscaler
82.   namespace: kube-system
83. spec:
84.   replicas: 1
85.   selector:
86.     matchLabels:
87.       app: cluster-autoscaler
88.   template:
89.     metadata:
90.       labels:
91.         app: cluster-autoscaler
92.     spec:
93.       serviceAccountName: cluster-autoscaler
94.       containers:
95.       - image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.22.0
96.         name: cluster-autoscaler
97.         resources:
98.           limits:
99.             cpu: 100m
100.             memory: 300Mi
101.           requests:
102.             cpu: 100m
103.             memory: 300Mi
104.         command:
105.         - ./cluster-autoscaler
106.         - --balance-similar-node-groups
107.         - --expander=priority
108.         - --skip-nodes-with-system-pods=false
109.         - --cloud-provider=aws
110.         - --nodes=<min-nodes>:<max-nodes>:<node-group-name>

复制代码

问题描述：Kubernetes API服务器响应时间显著增加，kubectl命令执行缓慢，Pod创建和更新操作超时。

排查过程：

1. 检查API服务器状态：

2. kubectl get componentstatuses

复制代码

1. 检查API服务器日志：

2. kubectl logs -n kube-system <kube-apiserver-pod-name>

复制代码

1. 检查etcd集群状态：

2. kubectl get pods -n kube-system | grep etcd
3. kubectl exec -it <etcd-pod-name> -n kube-system -- etcdctl --endpoints=https://[127.0.0.1]:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endpoint health

复制代码

1. 发现etcd集群响应时间过长，部分请求超时。
2. 检查etcd性能指标：

发现etcd集群响应时间过长，部分请求超时。

检查etcd性能指标：

2. kubectl exec -it <etcd-pod-name> -n kube-system -- etcdctl --endpoints=https://[127.0.0.1]:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endpoint status --write-out=table

复制代码

1. 发现etcd数据库大小过大，导致性能下降。

解决方案：

1. 短期解决方案：压缩etcd历史数据，减少数据库大小。

2. # 在etcd节点上执行
3. ETCDCTL_API=3 etcdctl --endpoints=https://[127.0.0.1]:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key defrag

复制代码

1. 长期解决方案：增加etcd节点资源（CPU、内存、磁盘）优化etcd配置，调整心跳间隔和选举超时实施etcd监控和告警，提前发现性能问题定期备份和压缩etcd数据
2. 增加etcd节点资源（CPU、内存、磁盘）
3. 优化etcd配置，调整心跳间隔和选举超时
4. 实施etcd监控和告警，提前发现性能问题
5. 定期备份和压缩etcd数据

• 增加etcd节点资源（CPU、内存、磁盘）
• 优化etcd配置，调整心跳间隔和选举超时
• 实施etcd监控和告警，提前发现性能问题
• 定期备份和压缩etcd数据

2. # etcd优化配置示例
3. apiVersion: v1
4. kind: Pod
5. metadata:
6.   name: etcd
7.   namespace: kube-system
8. spec:
9.   containers:
10.   - name: etcd
11.     image: k8s.gcr.io/etcd:3.4.13-0
12.     command:
13.     - etcd
14.     - --name=etcd-0
15.     - --data-dir=/var/lib/etcd
16.     - --listen-client-urls=https://0.0.0.0:2379
17.     - --advertise-client-urls=https://<node-ip>:2379
18.     - --listen-peer-urls=https://0.0.0.0:2380
19.     - --initial-advertise-peer-urls=https://<node-ip>:2380
20.     - --initial-cluster=etcd-0=https://<node-ip>:2380
21.     - --initial-cluster-token=my-etcd-token
22.     - --initial-cluster-state=new
23.     - --client-cert-auth=true
24.     - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
25.     - --cert-file=/etc/kubernetes/pki/etcd/server.crt
26.     - --key-file=/etc/kubernetes/pki/etcd/server.key
27.     - --peer-client-cert-auth=true
28.     - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
29.     - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
30.     - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
31.     # 优化参数
32.     - --heartbeat-interval=300
33.     - --election-timeout=2000
34.     - --max-snapshots=5
35.     - --max-wals=5
36.     - --quota-backend-bytes=4294967296
37.     - --auto-compaction-retention=1
38.     resources:
39.       requests:
40.         cpu: 200m
41.         memory: 1Gi
42.       limits:
43.         cpu: 1000m
44.         memory: 4Gi
45.     volumeMounts:
46.     - name: etcd-data
47.       mountPath: /var/lib/etcd
48.   volumes:
49.   - name: etcd-data
50.     hostPath:
51.       path: /var/lib/etcd
52.       type: DirectoryOrCreate

复制代码

问题描述：集群中的Pod无法相互通信，服务无法访问，应用功能异常。

排查过程：

1. 检查Pod状态和网络配置：

2. kubectl get pods --all-namespaces -o wide

复制代码

1. 检查服务状态：

2. kubectl get svc --all-namespaces
3. kubectl get endpoints --all-namespaces

复制代码

1. 检查网络插件状态：

2. kubectl get pods -n kube-system | grep -E 'calico|flannel|weave|cilium'

复制代码

1. 检查网络插件日志：

2. kubectl logs -n kube-system <network-plugin-pod-name>

复制代码

1. 创建测试Pod进行网络连通性测试：

2. kubectl run test-pod --image=busybox -- sleep 3600
3. kubectl exec -it test-pod -- /bin/sh
4. # 在Pod内执行
5. ping <target-pod-ip>
6. nslookup <service-name>

复制代码

1. 发现网络插件Pod异常重启，节点间网络配置不正确。

解决方案：

1. 短期解决方案：重启网络插件Pod，修复配置问题。

2. # 重启网络插件Pod
3. kubectl delete pod -n kube-system -l k8s-app=<network-plugin-name>
5. # 检查网络配置
6. # 对于Calico
7. kubectl get ippools.crd.projectcalico.org -o yaml
8. # 对于Flannel
9. kubectl get configmap -n kube-system kube-flannel-cfg -o yaml

复制代码

1. 长期解决方案：实施网络插件监控和告警定期检查网络配置和状态准备网络插件故障的应急响应计划考虑使用多网络插件或网络策略提高可靠性
2. 实施网络插件监控和告警
3. 定期检查网络配置和状态
4. 准备网络插件故障的应急响应计划
5. 考虑使用多网络插件或网络策略提高可靠性

• 实施网络插件监控和告警
• 定期检查网络配置和状态
• 准备网络插件故障的应急响应计划
• 考虑使用多网络插件或网络策略提高可靠性

2. # 网络插件监控配置示例
3. apiVersion: v1
4. kind: ConfigMap
5. metadata:
6.   name: network-plugin-monitoring
7.   namespace: monitoring
8. data:
9.   network-rules.yml: |
10.     groups:
11.     - name: network-plugin
12.       rules:
13.       - alert: NetworkPluginPodDown
14.         expr: up{job="network-plugin"} == 0
15.         for: 5m
16.         labels:
17.           severity: critical
18.         annotations:
19.           summary: "Network plugin pod is down"
20.           description: "Network plugin pod {{ $labels.pod }} has been down for more than 5 minutes."
21.       
22.       - alert: NetworkConnectivityFailure
23.         expr: probe_success{job="network-connectivity"} == 0
24.         for: 5m
25.         labels:
26.           severity: critical
27.         annotations:
28.           summary: "Network connectivity test failed"
29.           description: "Network connectivity test between pods failed for more than 5 minutes."

复制代码

总结与展望

Kubernetes集群健康检查是确保系统高可用性的关键环节。通过本文的介绍，我们了解了从监控指标到故障维护的完整流程，包括监控工具的选择、健康检查策略的实施、日志管理与分析、故障诊断与排查、自动化运维与告警，以及最佳实践和案例分析。

有效的健康检查体系应该包括：

1. 全面的监控覆盖：从基础设施到应用层的全方位监控
2. 合理的健康检查策略：根据应用特点设计合适的探针
3. 集中的日志管理：实现日志的收集、存储、分析和告警
4. 系统化的故障排查：建立标准化的故障处理流程
5. 智能化的自动化运维：减少人工干预，提高故障恢复速度

随着云原生技术的发展，Kubernetes集群健康检查也在不断演进。未来，我们可以期待以下发展趋势：

1. AI驱动的预测性维护：利用机器学习算法分析监控数据，预测潜在问题
2. 更精细的故障定位：通过分布式追踪等技术，实现请求级别的故障定位
3. 自适应的健康检查：根据系统负载和状态动态调整检查策略
4. 跨集群的健康管理：在多云和混合云环境下实现统一的健康检查
5. 更强大的自愈能力：实现更复杂的自动化故障恢复机制

作为运维人员，我们需要不断学习和实践，构建完善的健康检查体系，确保Kubernetes集群的稳定运行，为业务提供可靠的基础设施支持。通过本文提供的方法和工具，相信大家能够更好地管理和维护Kubernetes集群，快速定位并解决问题，保障系统的高可用性。