每位工程师都会遇到的 10 个 Kubernetes 问题（及解决方法）【转】

Kubernetes 看起来简单 - 直到它崩溃。

无论您部署了多少次，Kubernetes 总是能找到方法来考验您的耐心。

Pod 被卡住。容器崩溃。服务消失。

本文梳理了 10 个最常见的 Kubernetes 问题，它们的原因，最重要的是 - 如何快速解决它们。

无论您是新接触 K8s 还是运行生产集群，请收藏这篇文章 - 它将为您节省数小时的调试时间。

问题 1：Pod 处于 Pending 状态

我还记得我的第一个“Pending”Pod - 我认为 Kubernetes 坏了。

原来，我的节点没有足够的资源。

我花了数小时挖掘，才发现只是缺少 CPU 请求。

症状：

• Pod 状态显示“Pending”
• 应用程序无法启动

可能的原因和解决方案：

1. 资源不足：

# 检查节点资源
kubectl describe nodes
kubectl top nodes
# 检查 Pod 事件
kubectl describe pod <pod-name># 查找“Insufficient cpu”或“Insufficient memory”错误# 解决方案：添加更多节点或减少资源请求

2. PVC 未绑定：

# 检查 PVC 状态
kubectl get pvc# 检查 PV 可用性
kubectl get pv# 解决方案：创建 PV 或修复 PVC 配置

3. 没有匹配的节点：

# 检查节点标签
kubectl get nodes --show-labels# 检查 Pod nodeSelector
kubectl get pod <pod-name> -o yaml | grep -A5 nodeSelector# 解决方案：标记节点或删除 nodeSelector
kubectl label nodes <node-name> key=value

4. Taints 和 Toleration：

# 检查节点 Taints
# kubectl describe node <node-name> | grep Taintstolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

问题 2：Pod 处于 CrashLoopBackOff 状态

我曾经重新部署了一个微服务五次，以为它会神奇地工作。

每次它都崩溃了。

罪魁祸首？一个指向死端点的错误环境变量。

Kubernetes 像忠诚的看门犬一样不断重启它。

症状：

• Pod 不断重启
• 状态显示“CrashLoopBackOff”

故障排除步骤：

# 检查 Pod 日志
kubectl logs <pod-name>
kubectl logs <pod-name> --previous  # 之前实例# 检查 Pod 事件
kubectl describe pod <pod-name># 检查资源限制
kubectl describe pod <pod-name> | grep -A10 Limits# 检查容器退出代码
kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

常见原因：

1. 应用程序错误：

• 检查日志中的应用程序错误
• 修复应用程序代码或配置

2. 缺少依赖项：

# 添加 init 容器等待依赖项
initContainers:
- name: wait-for-db
  image: busybox
  command: ['sh', '-c', 'until nc -z postgres-service 5432; do sleep 2; done']

3. 命令/参数错误：

# 验证 Pod 规范中的命令
kubectl get pod <pod-name> -o yaml | grep -A5 command

4. liveness 探测失败：

# 调整探测时间
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60  # 增加延迟
  periodSeconds: 10
  failureThreshold: 3

问题 3：服务不可访问

这个问题困扰了我几个小时。

一切看起来都正常 - Pod、服务、端点。

但我的应用无法连接。

原来，我在 Service YAML 中使用了错误的 targetPort。

从那以后，我变得对 YAML 进行三重检查。

症状：

• 无法从集群内部或外部访问服务
• 连接超时或被拒绝

故障排除步骤：

# 1. 验证服务存在
kubectl get svc <service-name>
# 2. 检查服务端点
kubectl get endpoints <service-name>
# 如果为空，selector 与任何 Pod 都不匹配
# 3. 验证 Pod 标签
kubectl get pods --show-labels
# 4. 从集群内部测试
kubectl run test-pod --image=busybox --rm -it -- wget -O- <service-name>:<port>
# 5. 检查服务类型
kubectl describe svc <service-name>
# 6. 对于 NodePort，检查节点端口是否可访问
kubectl get svc <service-name> -o jsonpath='{.spec.ports[0].nodePort}'
# 7. 检查 NetworkPolicy
kubectl get networkpolicy
kubectl describe networkpolicy <policy-name>
# 8. 检查 DNS
kubectl run test-dns --image=busybox --rm -it -- nslookup <service-name>

解决方案：

1. 修复标签选择器：

# 确保服务选择器与 Pod 标签匹配
selector:
  app: myapp  # 必须匹配 Pod 标签

2. 检查目标端口：

ports:
- port: 80          # 服务端口
  targetPort: 8080  # 必须匹配容器端口

3. 验证防火墙规则（对于 NodePort/LoadBalancer）：

# 检查安全组/防火墙规则是否允许流量

问题 4：高内存/CPU 使用率

我还记得我们早期的生产部署，一半的 Pod 不断被 OOMKilled。仪表盘上一切看起来都正常，但日志却讲述了另一个故事 - 我们的 Node.js 应用程序在吞噬内存。

原来，我们从未设置资源限制。集群在呼救，但我们没有倾听。

通过 kubectl top pods 设置适当的 requests 和 limits，启用 Vertical Pod Autoscaler (VPA)，情况发生了翻天覆地的变化。

症状：

• Pod 被 OOMKilled
• 性能下降
• 节点压力大

故障排除：

# 检查资源使用情况
kubectl top pods
kubectl top nodes# 检查 Pod 资源限制
kubectl describe pod <pod-name> | grep -A10 Limits# 检查 OOMKilled 事件
kubectl get events --field-selector reason=OOMKilled# 查看详细的 Pod 指标
kubectl describe node <node-name>

解决方案：

1. 增加资源限制：

resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "1000m"

2. 实施资源配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-quota
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

3. 设置限制范围：

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 500m
    defaultRequest:
      memory: 256Mi
      cpu: 250m
    type: Container

4. 启用垂直 Pod 自动扩展器 (VPA)：

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  updatePolicy:
    updateMode: "Auto"

问题 5：ImagePullBackOff / ErrImagePull

这个在我周末部署期间咬了我一口（当然）。新的镜像，新的标签，一切看起来都准备好了 - 除了 Pod 从未启动。

“ImagePullBackOff” 状态像地狱般的错误信息一样盯着我。

20 分钟的恐慌后，我发现罪魁祸首是标签名称错误 - 有人在构建推送时打错了。

一旦修复，一切就立即启动起来。

现在，我总是运行 kubectl describe pod <pod-name> 并仔细检查注册表凭据和标签。因为没有什么比镜像标签中的冒号错误更能破坏部署信心。

症状：

• Pod 处于 ImagePullBackOff 状态
• 无法拉取容器镜像

故障排除：

# 检查 Pod 事件
kubectl describe pod <pod-name># 常见错误消息：
# - "image not found"
# - "unauthorized"
# - "manifest unknown"

解决方案：

1. 验证镜像名称：

# 检查镜像名称和标签
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].image}'

2. 检查镜像拉取密钥（对于私有注册表）：

# 创建密钥
kubectl create secret docker-registry regcred \
  --docker-server=<registry-url> \
  --docker-username=<username> \
  --docker-password=<password># 添加到 Pod 规范
imagePullSecrets:
- name: regcred

3. 检查镜像拉取策略：

containers:
- name: app
  image: myapp:latest
  imagePullPolicy: Always  # 或 IfNotPresent, Never

问题 6：DNS 解析失败

一个阳光明媚的早晨，服务开始神秘地失败。API 无法访问数据库，日志充满了“未知主机”错误 - 混乱不堪。

起初，我怀疑是应用程序的问题，但一切正常。然后我突然想到，CoreDNS 可能崩溃了。

果然，kubectl logs -n kube-system -l k8s-app=kube-dns 显示了一个崩溃循环。重启 CoreDNS 并修复了一个小的配置错误，集群恢复了生机。

那天我学到：当一切都同时崩溃时，从 DNS 开始 - 它总是 DNS。

症状：

• Pod 无法解析服务名称
• “nslookup: 无法解析”错误

故障排除：

# 1. 检查 CoreDNS Pod
kubectl get pods -n kube-system -l k8s-app=kube-dns# 2. 检查 CoreDNS 日志
kubectl logs -n kube-system -l k8s-app=kube-dns# 3. 测试 DNS 解析
kubectl run test-dns --image=busybox --rm -it -- nslookup kubernetes.default# 4. 检查 DNS 服务
kubectl get svc -n kube-system kube-dns# 5. 检查 Pod DNS 配置
kubectl get pod <pod-name> -o yaml | grep -A10 dnsPolicy

解决方案：

1. 重启 CoreDNS：

kubectl rollout restart deployment/coredns -n kube-system

2. 检查 CoreDNS ConfigMap：

kubectl get configmap coredns -n kube-system -o yaml

3. 设置 DNS 策略：

spec:
  dnsPolicy: ClusterFirst  # 或 Default, ClusterFirstWithHostNet
  dnsConfig:
    nameservers:
    - 8.8.8.8
    searches:
    - default.svc.cluster.local
    - svc.cluster.local
    - cluster.local

问题 7：持久卷问题

一个周五部署，我的 PVC 被卡在 Pending 状态。数小时后，我发现罪魁祸首 - 存储类不匹配。

快速修复 PVC 和 PV 名称的匹配问题，一切立即挂载。

从那以后，我在每次部署前都会仔细检查存储配置。是细节破坏大事。

症状：

• PVC 处于 Pending 状态
• Pod 无法挂载卷
• Pod 重新启动后数据丢失

故障排除：

# 检查 PVC 状态
kubectl get pvc# 检查 PV 状态
kubectl get pv# 描述 PVC
kubectl describe pvc <pvc-name># 检查存储类
kubectl get storageclass# 检查 Pod 事件
kubectl describe pod <pod-name>

解决方案：

1. PVC 未绑定：

# 确保匹配存储类
kubectl get pvc <pvc-name> -o yaml | grep storageClassName
kubectl get pv -o yaml | grep storageClassName# 检查访问模式匹配
# PVC: ReadWriteOnce, ReadOnlyMany, ReadWriteMany
# PV 必须支持相同的访问模式

2. 手动 PV 绑定：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: manual-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: my-pvc
    namespace: default

3. 修复卷挂载错误：

# 检查挂载路径冲突
# 确保容器用户有权限
# 验证节点上的卷存在（对于 hostPath）

问题 8：网络连接问题

Pod 健康但无法相互通信 — 纯粹的沉默。原来有人应用了一个 NetworkPolicy 阻断了所有流量。

临时允许入站流量后，事情又恢复了正常。

学到的教训：当 Pod 互相“消失”时，归咎于网络。

症状：

• Pod 无法相互通信
• 外部流量无法到达 Pod

故障排除：

# 1. 检查 Pod IP
kubectl get pod <pod-name> -o wide# 2. 测试 Pod 到 Pod 连接性
kubectl exec <source-pod> -- ping <destination-pod-ip># 3. 检查 NetworkPolicy
kubectl get networkpolicy# 4. 检查 CNI 插件
kubectl get pods -n kube-system | grep -E 'calico|flannel|weave|cilium'# 5. 检查 kube-proxy
kubectl get pods -n kube-system | grep kube-proxy
kubectl logs -n kube-system <kube-proxy-pod>

解决方案：

1. 修复 NetworkPolicy：

# 允许所有入站流量（用于测试）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - {}

2. 重启 CNI 插件：

# 示例：Calico
kubectl rollout restart daemonset/calico-node -n kube-system

问题 9：证书/TLS 问题

我们的 HTTPS 突然毫无预兆地停止工作了。原因？过期的 TLS 证书在一个被遗忘的密钥中。

重新创建证书并使用 cert-manager 自动续订。永远不会再手动追逐到期日期。

症状：

• HTTPS 无法工作
• 证书验证错误
• Ingress TLS 失败

故障排除：

# 检查密钥
kubectl get secret <tls-secret> -o yaml# 验证证书
kubectl get secret <tls-secret> -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text# 检查 Ingress TLS 配置
kubectl describe ingress <ingress-name>

解决方案：

1. 创建正确的 TLS 密钥：

kubectl create secret tls <secret-name> --cert=path/to/cert.crt --key=path/to/key.key

2. 使用 Cert-Manager（自动证书管理）：

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml

问题 10：节点问题

在高流量期间，一个 Node NotReady 警报突然出现。kubelet 因 磁盘压力 而崩溃。

释放空间，重启 kubelet，解除节点的封锁。现在我像日常卫生一样对待节点清理 - 如果跳过一次，就会带来混乱。

症状：

• 节点状态 NotReady
• Pod 无法调度
• 节点压力条件

故障排除：

# 检查节点状态
kubectl get nodes# 描述节点
kubectl describe node <node-name># 检查 kubelet 状态（在节点上）
systemctl status kubelet# 检查 kubelet 日志（在节点上）
journalctl -u kubelet -f

常见节点条件：

• MemoryPressure：节点内存不足
• DiskPressure：节点磁盘空间不足
• PIDPressure：进程过多
• NetworkUnavailable：网络未配置

解决方案：

1. MemoryPressure：

# 驱逐 Pod，添加内存或添加节点
kubectl drain <node-name> --ignore-daemonsets

2. DiskPressure：

# 在节点上清理
docker system prune -a  # 如果使用 Docker
crictl rmi --prune      # 如果使用 containerd

3. 重启 Kubelet：

systemctl restart kubelet

4. 解除节点封锁：

kubectl uncordon <node-name>

 

转自

https://mp.weixin.qq.com/s/xVD9qbKwvpkqbac7qUogqw

Kubernetes 看起来简单 - 直到它崩溃。

无论您部署了多少次，Kubernetes 总是能找到方法来考验您的耐心。

Pod 被卡住。容器崩溃。服务消失。

本文梳理了 10 个最常见的 Kubernetes 问题，它们的原因，最重要的是 - 如何快速解决它们。

无论您是新接触 K8s 还是运行生产集群，请收藏这篇文章 - 它将为您节省数小时的调试时间。

问题 1：Pod 处于 Pending 状态

我还记得我的第一个“Pending”Pod - 我认为 Kubernetes 坏了。

原来，我的节点没有足够的资源。

我花了数小时挖掘，才发现只是缺少 CPU 请求。

症状：

• Pod 状态显示“Pending”
• 应用程序无法启动

可能的原因和解决方案：

1. 资源不足：

# 检查节点资源
kubectl describe nodes
kubectl top nodes
# 检查 Pod 事件
kubectl describe pod <pod-name># 查找“Insufficient cpu”或“Insufficient memory”错误# 解决方案：添加更多节点或减少资源请求

2. PVC 未绑定：

# 检查 PVC 状态
kubectl get pvc# 检查 PV 可用性
kubectl get pv# 解决方案：创建 PV 或修复 PVC 配置

3. 没有匹配的节点：

# 检查节点标签
kubectl get nodes --show-labels# 检查 Pod nodeSelector
kubectl get pod <pod-name> -o yaml | grep -A5 nodeSelector# 解决方案：标记节点或删除 nodeSelector
kubectl label nodes <node-name> key=value

4. Taints 和 Toleration：

# 检查节点 Taints
# kubectl describe node <node-name> | grep Taintstolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

问题 2：Pod 处于 CrashLoopBackOff 状态

我曾经重新部署了一个微服务五次，以为它会神奇地工作。

每次它都崩溃了。

罪魁祸首？一个指向死端点的错误环境变量。

Kubernetes 像忠诚的看门犬一样不断重启它。

症状：

• Pod 不断重启
• 状态显示“CrashLoopBackOff”

故障排除步骤：

# 检查 Pod 日志
kubectl logs <pod-name>
kubectl logs <pod-name> --previous  # 之前实例# 检查 Pod 事件
kubectl describe pod <pod-name># 检查资源限制
kubectl describe pod <pod-name> | grep -A10 Limits# 检查容器退出代码
kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

常见原因：

1. 应用程序错误：

• 检查日志中的应用程序错误
• 修复应用程序代码或配置

2. 缺少依赖项：

# 添加 init 容器等待依赖项
initContainers:
- name: wait-for-db
  image: busybox
  command: ['sh', '-c', 'until nc -z postgres-service 5432; do sleep 2; done']

3. 命令/参数错误：

# 验证 Pod 规范中的命令
kubectl get pod <pod-name> -o yaml | grep -A5 command

4. liveness 探测失败：

# 调整探测时间
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60  # 增加延迟
  periodSeconds: 10
  failureThreshold: 3

问题 3：服务不可访问

这个问题困扰了我几个小时。

一切看起来都正常 - Pod、服务、端点。

但我的应用无法连接。

原来，我在 Service YAML 中使用了错误的 targetPort。

从那以后，我变得对 YAML 进行三重检查。

症状：

• 无法从集群内部或外部访问服务
• 连接超时或被拒绝

故障排除步骤：

# 1. 验证服务存在
kubectl get svc <service-name># 2. 检查服务端点
kubectl get endpoints <service-name>
# 如果为空，selector 与任何 Pod 都不匹配# 3. 验证 Pod 标签
kubectl get pods --show-labels# 4. 从集群内部测试
kubectl run test-pod --image=busybox --rm -it -- wget -O- <service-name>:<port># 5. 检查服务类型
kubectl describe svc <service-name># 6. 对于 NodePort，检查节点端口是否可访问
kubectl get svc <service-name> -o jsonpath='{.spec.ports[0].nodePort}'# 7. 检查 NetworkPolicy
kubectl get networkpolicy
kubectl describe networkpolicy <policy-name># 8. 检查 DNS
kubectl run test-dns --image=busybox --rm -it -- nslookup <service-name>

解决方案：

1. 修复标签选择器：

# 确保服务选择器与 Pod 标签匹配
selector:
  app: myapp  # 必须匹配 Pod 标签

2. 检查目标端口：

ports:
- port: 80          # 服务端口
  targetPort: 8080  # 必须匹配容器端口

3. 验证防火墙规则（对于 NodePort/LoadBalancer）：

# 检查安全组/防火墙规则是否允许流量

问题 4：高内存/CPU 使用率

我还记得我们早期的生产部署，一半的 Pod 不断被 OOMKilled。仪表盘上一切看起来都正常，但日志却讲述了另一个故事 - 我们的 Node.js 应用程序在吞噬内存。

原来，我们从未设置资源限制。集群在呼救，但我们没有倾听。

通过 kubectl top pods 设置适当的 requests 和 limits，启用 Vertical Pod Autoscaler (VPA)，情况发生了翻天覆地的变化。

症状：

• Pod 被 OOMKilled
• 性能下降
• 节点压力大

故障排除：

# 检查资源使用情况
kubectl top pods
kubectl top nodes# 检查 Pod 资源限制
kubectl describe pod <pod-name> | grep -A10 Limits# 检查 OOMKilled 事件
kubectl get events --field-selector reason=OOMKilled# 查看详细的 Pod 指标
kubectl describe node <node-name>

解决方案：

1. 增加资源限制：

resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "1000m"

2. 实施资源配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-quota
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

3. 设置限制范围：

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 500m
    defaultRequest:
      memory: 256Mi
      cpu: 250m
    type: Container

4. 启用垂直 Pod 自动扩展器 (VPA)：

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  updatePolicy:
    updateMode: "Auto"

问题 5：ImagePullBackOff / ErrImagePull

这个在我周末部署期间咬了我一口（当然）。新的镜像，新的标签，一切看起来都准备好了 - 除了 Pod 从未启动。

“ImagePullBackOff” 状态像地狱般的错误信息一样盯着我。

20 分钟的恐慌后，我发现罪魁祸首是标签名称错误 - 有人在构建推送时打错了。

一旦修复，一切就立即启动起来。

现在，我总是运行 kubectl describe pod <pod-name> 并仔细检查注册表凭据和标签。因为没有什么比镜像标签中的冒号错误更能破坏部署信心。

症状：

• Pod 处于 ImagePullBackOff 状态
• 无法拉取容器镜像

故障排除：

# 检查 Pod 事件
kubectl describe pod <pod-name># 常见错误消息：
# - "image not found"
# - "unauthorized"
# - "manifest unknown"

解决方案：

1. 验证镜像名称：

# 检查镜像名称和标签
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].image}'

2. 检查镜像拉取密钥（对于私有注册表）：

# 创建密钥
kubectl create secret docker-registry regcred \
  --docker-server=<registry-url> \
  --docker-username=<username> \
  --docker-password=<password># 添加到 Pod 规范
imagePullSecrets:
- name: regcred

3. 检查镜像拉取策略：

containers:
- name: app
  image: myapp:latest
  imagePullPolicy: Always  # 或 IfNotPresent, Never

问题 6：DNS 解析失败

一个阳光明媚的早晨，服务开始神秘地失败。API 无法访问数据库，日志充满了“未知主机”错误 - 混乱不堪。

起初，我怀疑是应用程序的问题，但一切正常。然后我突然想到，CoreDNS 可能崩溃了。

果然，kubectl logs -n kube-system -l k8s-app=kube-dns 显示了一个崩溃循环。重启 CoreDNS 并修复了一个小的配置错误，集群恢复了生机。

那天我学到：当一切都同时崩溃时，从 DNS 开始 - 它总是 DNS。

症状：

• Pod 无法解析服务名称
• “nslookup: 无法解析”错误

故障排除：

# 1. 检查 CoreDNS Pod
kubectl get pods -n kube-system -l k8s-app=kube-dns# 2. 检查 CoreDNS 日志
kubectl logs -n kube-system -l k8s-app=kube-dns# 3. 测试 DNS 解析
kubectl run test-dns --image=busybox --rm -it -- nslookup kubernetes.default# 4. 检查 DNS 服务
kubectl get svc -n kube-system kube-dns# 5. 检查 Pod DNS 配置
kubectl get pod <pod-name> -o yaml | grep -A10 dnsPolicy

解决方案：

1. 重启 CoreDNS：

kubectl rollout restart deployment/coredns -n kube-system

2. 检查 CoreDNS ConfigMap：

kubectl get configmap coredns -n kube-system -o yaml

3. 设置 DNS 策略：

spec:
  dnsPolicy: ClusterFirst  # 或 Default, ClusterFirstWithHostNet
  dnsConfig:
    nameservers:
    - 8.8.8.8
    searches:
    - default.svc.cluster.local
    - svc.cluster.local
    - cluster.local

问题 7：持久卷问题

一个周五部署，我的 PVC 被卡在 Pending 状态。数小时后，我发现罪魁祸首 - 存储类不匹配。

快速修复 PVC 和 PV 名称的匹配问题，一切立即挂载。

从那以后，我在每次部署前都会仔细检查存储配置。是细节破坏大事。

症状：

• PVC 处于 Pending 状态
• Pod 无法挂载卷
• Pod 重新启动后数据丢失

故障排除：

# 检查 PVC 状态
kubectl get pvc# 检查 PV 状态
kubectl get pv# 描述 PVC
kubectl describe pvc <pvc-name># 检查存储类
kubectl get storageclass# 检查 Pod 事件
kubectl describe pod <pod-name>

解决方案：

1. PVC 未绑定：

# 确保匹配存储类
kubectl get pvc <pvc-name> -o yaml | grep storageClassName
kubectl get pv -o yaml | grep storageClassName# 检查访问模式匹配
# PVC: ReadWriteOnce, ReadOnlyMany, ReadWriteMany
# PV 必须支持相同的访问模式

2. 手动 PV 绑定：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: manual-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: my-pvc
    namespace: default

3. 修复卷挂载错误：

# 检查挂载路径冲突
# 确保容器用户有权限
# 验证节点上的卷存在（对于 hostPath）

问题 8：网络连接问题

Pod 健康但无法相互通信 — 纯粹的沉默。原来有人应用了一个 NetworkPolicy 阻断了所有流量。

临时允许入站流量后，事情又恢复了正常。

学到的教训：当 Pod 互相“消失”时，归咎于网络。

症状：

• Pod 无法相互通信
• 外部流量无法到达 Pod

故障排除：

# 1. 检查 Pod IP
kubectl get pod <pod-name> -o wide# 2. 测试 Pod 到 Pod 连接性
kubectl exec <source-pod> -- ping <destination-pod-ip># 3. 检查 NetworkPolicy
kubectl get networkpolicy# 4. 检查 CNI 插件
kubectl get pods -n kube-system | grep -E 'calico|flannel|weave|cilium'# 5. 检查 kube-proxy
kubectl get pods -n kube-system | grep kube-proxy
kubectl logs -n kube-system <kube-proxy-pod>

解决方案：

1. 修复 NetworkPolicy：

# 允许所有入站流量（用于测试）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - {}

2. 重启 CNI 插件：

# 示例：Calico
kubectl rollout restart daemonset/calico-node -n kube-system

问题 9：证书/TLS 问题

我们的 HTTPS 突然毫无预兆地停止工作了。原因？过期的 TLS 证书在一个被遗忘的密钥中。

重新创建证书并使用 cert-manager 自动续订。永远不会再手动追逐到期日期。

症状：

• HTTPS 无法工作
• 证书验证错误
• Ingress TLS 失败

故障排除：

# 检查密钥
kubectl get secret <tls-secret> -o yaml# 验证证书
kubectl get secret <tls-secret> -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text# 检查 Ingress TLS 配置
kubectl describe ingress <ingress-name>

解决方案：

1. 创建正确的 TLS 密钥：

kubectl create secret tls <secret-name> --cert=path/to/cert.crt --key=path/to/key.key

2. 使用 Cert-Manager（自动证书管理）：

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml

问题 10：节点问题

在高流量期间，一个 Node NotReady 警报突然出现。kubelet 因 磁盘压力 而崩溃。

释放空间，重启 kubelet，解除节点的封锁。现在我像日常卫生一样对待节点清理 - 如果跳过一次，就会带来混乱。

症状：

• 节点状态 NotReady
• Pod 无法调度
• 节点压力条件

故障排除：

# 检查节点状态
kubectl get nodes# 描述节点
kubectl describe node <node-name># 检查 kubelet 状态（在节点上）
systemctl status kubelet# 检查 kubelet 日志（在节点上）
journalctl -u kubelet -f

常见节点条件：

• MemoryPressure：节点内存不足
• DiskPressure：节点磁盘空间不足
• PIDPressure：进程过多
• NetworkUnavailable：网络未配置

解决方案：

1. MemoryPressure：

# 驱逐 Pod，添加内存或添加节点
kubectl drain <node-name> --ignore-daemonsets

2. DiskPressure：

# 在节点上清理
docker system prune -a  # 如果使用 Docker
crictl rmi --prune      # 如果使用 containerd

3. 重启 Kubelet：

systemctl restart kubelet

4. 解除节点封锁：

kubectl uncordon <node-name>