跳转至

K8s 相关问题集锦（五）

8 实战问题

8.1 如果一个 Pod 需要访问另一个 Pod，应该怎么做？

使用 Kubernetes Service 创建稳定的访问入口，或者配置 Ingress 规则。

以下是实现 Pod 之间相互访问的步骤和对应的命令示例：

1. 创建两个 Pod

先创建两个 Pod，假设第一个 Pod 运行 nginx，另一个 Pod 运行一个简单的 HTTP 服务器。

创建 nginx Pod

使用以下命令来创建一个运行 nginx 的 Pod：

bash kubectl run nginx-pod --image=nginx --port=80

创建 HTTP 服务器 Pod

使用 Python 创建一个简单的 HTTP 服务器：

bash kubectl run http-server-pod --image=hashicorp/http-echo -- -text="Hello from http-server-pod"

2. 创建 Service 为 nginx Pod 暴露服务

为了让其他 Pod 可以访问到 nginx-pod，我们需要为它创建一个 Service。

创建 ClusterIP Service

bash kubectl expose pod nginx-pod --port=80 --target-port=80 --name=nginx-service

这将为 nginx-pod 创建一个名为 nginx-service 的 ClusterIP 类型的 Service。其他 Pod 可以通过 nginx-service 的 DNS 名称来访问它。

3. 访问 nginx Pod

进入 http-server-pod，使用 curl 来访问 nginx-service：

bash kubectl exec -it http-server-pod -- /bin/sh

在 Pod 的终端中，使用 curl 命令来访问 nginx-service：

sh curl http://nginx-service

这会返回 nginx 的默认首页内容。

总结

  1. 创建 Pod：通过 kubectl run 创建所需的 Pod。
  2. 暴露服务：通过 kubectl expose 创建一个 Service 来提供稳定的访问入口。
  3. 通过 DNS 名称访问：Pod 之间可以使用 Service 名称作为 DNS 来互相访问。

8.2 如何在生产环境中保证 Kubernetes 应用的高可用性和稳定性？

讨论滚动更新策略、健康检查（Liveness 和 Readiness Probe）、日志监控和自动扩展。

在生产环境中，保证 Kubernetes 应用的高可用性和稳定性非常重要。可以从多个方面入手，包括滚动更新策略、健康检查、日志监控和自动扩展等。以下是这些策略的详细介绍：

1. 滚动更新策略（Rolling Update）

滚动更新是一种无缝更新应用程序的方式，在不中断服务的情况下逐步替换旧版本的 Pod，以保证应用的高可用性和稳定性。

  • 使用 Rolling Update：

  • 默认情况下，Kubernetes 使用滚动更新来更新 Deployment 中的 Pod。

  • 在滚动更新过程中，会逐个替换旧的 Pod，以避免服务中断。

  • 如何设置滚动更新策略：

  • maxUnavailable：设置更新时最多可以不可用的 Pod 数量，可以是绝对数（如 1）或百分比（如 25%）。

  • maxSurge：设置更新时可以额外创建的新 Pod 数量，避免在升级期间缩容太快导致服务不可用。

示例：Deployment 中滚动更新配置

yaml apiVersion: apps/v1 kind: Deployment metadata: name: example-deployment spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: example spec: containers: - name: example-container image: example/image:latest

2. 健康检查（Liveness 和 Readiness Probe）

健康检查用于确保应用程序在生产环境中的稳定性，并及时处理故障。

  • Liveness Probe：

  • 用于检测应用程序是否卡死或失去响应。

  • 如果 Liveness Probe 检测到应用异常，Kubernetes 将重新启动该容器。

  • Readiness Probe：

  • 用于检测应用程序是否可以正常接收流量。

  • 如果 Readiness Probe 失败，则该 Pod 不会接收来自 Service 的流量，从而避免将请求发送给不健康的实例。

示例：Liveness 和 Readiness Probe 配置

yaml apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: example/image:latest livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 3 periodSeconds: 10 readinessProbe: httpGet: path: /readiness port: 8080 initialDelaySeconds: 3 periodSeconds: 10

  • initialDelaySeconds：容器启动后等待多长时间开始探测。
  • periodSeconds：探测的间隔时间。

3. 日志监控

为了及时发现问题和异常，需要对应用程序进行日志监控和实时告警。

  • 日志收集和集中化管理：

  • 在 Kubernetes 中，Pod 的日志可以通过 kubectl logs 命令查看，但在生产环境中需要集中化的日志管理。

  • 通过工具如 ELK（Elasticsearch, Logstash, Kibana） 或 EFK（Elasticsearch, Fluentd, Kibana） 堆栈将日志集中收集、存储和分析。

  • 监控系统：

  • 可以使用 Prometheus + Grafana 来对应用程序进行监控。

  • Prometheus 可以采集应用的指标数据，Grafana 用于展示和告警。

  • 日志轮转（Log Rotation）：

  • Kubernetes 不会自动管理日志文件的大小和历史数据。可以通过 logrotate 等工具管理日志的轮转，避免日志文件占用大量磁盘空间。

4. 自动扩展（Horizontal Pod Autoscaler, Vertical Pod Autoscaler）

为了应对负载的变化，Kubernetes 提供了自动扩展功能。

  • 水平自动扩展（Horizontal Pod Autoscaler, HPA）：
  • HPA 可以根据 CPU 使用率或自定义指标来自动增加或减少 Pod 的数量，从而适应不同的负载。
  • 例如，当 CPU 使用率超过设定的阈值时，HPA 会增加 Pod 的副本数，保证服务的高可用性。

示例：HPA 配置

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: example-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: example-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80

  • minReplicas 和 maxReplicas：定义 Pod 的最小和最大数量。
  • averageUtilization：当 CPU 使用率超过 80% 时，HPA 会开始扩容。

  • 垂直自动扩展（Vertical Pod Autoscaler, VPA）：

  • VPA 可以自动调整 Pod 中容器的资源请求（CPU 和内存），从而适应应用程序的需求。

  • VPA 主要用于确保资源分配的合理性，避免资源的过度使用或不足。

5. 总结

在生产环境中，保障 Kubernetes 应用高可用性和稳定性的几种有效措施：

  • 滚动更新策略：通过设置 maxUnavailable 和 maxSurge 确保应用平滑升级，避免中断。
  • 健康检查（Liveness 和 Readiness Probe）：通过配置探针确保应用运行状况良好，并及时恢复故障。
  • 日志监控：使用 ELK/EFK 堆栈集中管理日志，结合 Prometheus 和 Grafana 实现可视化监控和告警。
  • 自动扩展：通过 HPA 和 VPA 自动调整应用的副本数量和资源分配，应对负载变化。

8.3 如何处理集群中某个节点频繁重启的问题？

需要检查节点日志、分析 kubelet 和 kube-proxy 的运行状态，可能需要诊断操作系统和硬件问题。

要处理 Kubernetes 集群中某个节点频繁重启的问题，需要进行全面的故障排查，以找出问题的根本原因。以下是可能的步骤和要检查的细节：

1. 检查节点日志

查看系统日志

节点频繁重启时，首先需要检查系统级别的日志。通过 SSH 连接到出问题的节点上，查看系统日志，以确定是否存在内核崩溃、内存不足、硬件故障等问题。

  • 使用 journalctl 查看系统日志：

bash journalctl -xe

  • 可以通过 journalctl 检查系统启动失败的原因以及内核相关的错误。

查看 Docker / Containerd 日志

Kubernetes 节点使用容器运行时来管理容器（例如 Docker 或 Containerd）。可以通过查看容器运行时的日志来确定节点问题。

  • 查看 Docker 日志：

bash journalctl -u docker - 查看 Containerd 日志：

bash journalctl -u containerd

这些日志可以帮助确定容器运行时是否遇到错误，例如因为资源限制而频繁重启容器。

2. 分析 kubelet 状态

kubelet 是 Kubernetes 集群中负责管理和监控 Pod 的核心组件，如果它出现问题，节点的稳定性也会受到影响。

  • 检查 kubelet 状态：

bash systemctl status kubelet

  • 确保 kubelet 正在正常运行，如果有任何错误信息，通常会在输出中显示。
  • 还可以使用 journalctl -u kubelet 查看 kubelet 的日志，了解详细的错误信息。

  • 常见问题：

  • 节点不可调度：检查 kubelet 是否因为节点资源不足而停止调度 Pod。

  • 内存不足：如果节点内存不足，kubelet 可能会尝试驱逐 Pod。
  • 磁盘压力：当磁盘压力很大时，kubelet 会停止调度新容器以避免更多磁盘写入。

3. 检查 kube-proxy 状态

kube-proxy 负责管理节点的网络代理和负载均衡。如果 kube-proxy 出现故障，可能会影响节点的网络访问和服务流量。

  • 查看 kube-proxy 的运行状态：

bash systemctl status kube-proxy - 查看 kube-proxy 日志：

bash journalctl -u kube-proxy - 检查网络配置：

  • 查看节点的网络设置，确认 iptables 或 ipvs 规则是否正常。
  • 检查节点上是否存在 IP 冲突或者防火墙规则错误等问题。

4. 诊断操作系统和硬件问题

如果节点频繁重启，并且不是由 Kubernetes 组件引起的，则可能与操作系统或者硬件问题相关。

  • 内存不足（OOM）：

  • 如果节点上的应用程序或 Pod 占用了太多内存，可能会导致系统 OOM（内存不足）并重启。

  • 可以通过以下命令检查是否有 OOM 相关的日志：

    bash dmesg | grep -i oom - 磁盘问题：

  • 检查磁盘使用情况，确保没有磁盘空间不足的问题：

    bash df -h - 磁盘 I/O 问题也可能导致节点重启。 - 硬件问题：

  • 如果是物理服务器，可以检查硬件监控工具（例如 Dell iDRAC 或 HP iLO）查看硬件是否出现故障。

  • 如果是云服务器，可以联系云供应商检查底层硬件状态。

5. 检查 Kubernetes 事件

Kubernetes 事件中会记录集群和节点相关的状态和警告信息，这可以帮助分析节点频繁重启的原因。

  • 查看节点事件：

bash kubectl describe node <node-name>

  • 通过 kubectl describe 可以看到与该节点相关的事件日志，其中可能包含节点重启的原因（例如内存不足、磁盘压力等）。

6. 检查资源使用情况

可以使用监控工具（例如 Prometheus 和 Grafana）来监控节点的 CPU、内存和磁盘使用情况，帮助确定节点是否因为资源耗尽而重启。

  • 使用 top 查看资源使用：

bash top - 使用 kubectl top 查看节点资源使用情况：

bash kubectl top nodes kubectl top pods --namespace=<namespace>

7. 最后措施：隔离节点

如果问题一直无法解决，可以将问题节点从集群中隔离出来，停止调度新的 Pod 到该节点，直到问题彻底排查完成。

  • 隔离节点：

bash kubectl cordon <node-name>

  • 通过 cordon 命令可以将节点标记为不可调度。
  • 如果需要迁移 Pod，可以使用 kubectl drain 命令将 Pod 迁移到其他节点。

总结

  1. 检查节点日志：通过 journalctl 查看系统日志、Docker/Containerd 日志和 kubelet 日志，以确定问题的根本原因。
  2. 分析 kubelet 和 kube-proxy 状态：确保这些核心组件正常运行。
  3. 诊断操作系统和硬件问题：检查内存、磁盘和硬件故障。
  4. 查看 Kubernetes 事件：通过 kubectl describe node 查看与节点相关的事件。
  5. 监控资源使用情况：利用监控工具和 kubectl top 确认是否因资源问题导致节点重启。
  6. 隔离节点：必要时，将节点从集群中隔离，避免影响整个集群的稳定性。