3、k8s面试题-浅谈k8s的几种探针以及探针检测不通过时会怎样？

1、面试题简答

在 Kubernetes 中，探针（Probe）是用于监控容器健康状态的机制，通过定期执行检测来判断容器是否正常运行。当探针检测不通过时，Kubernetes 会采取相应的自动恢复措施。以下是几种探针及其失败处理机制的详细解析：

一、探针类型

Kubernetes 提供三种探针类型，每种探针有不同的用途：

1. Liveness Probe（存活探针）

• 作用：检测容器是否处于运行状态（Alive）。
• 触发行为：若失败，容器会被重启（Restart）。
• 适用场景：
  • 应用死锁（如数据库连接池耗尽）。
  • 应用陷入无限循环。

2. Readiness Probe（就绪探针）

• 作用：检测容器是否已准备好接收流量（Ready）。
• 触发行为：若失败，容器会被从 Service 的端点列表中移除，不再接收流量。
• 适用场景：
  • 应用启动时需要初始化（如加载配置、预热缓存）。
  • 应用暂时无法处理请求（如数据库连接超时）。

3. Startup Probe（启动探针）

• 作用：检测容器内应用是否已成功启动（Startup Complete）。
• 触发行为：若失败，容器会被重启。
• 适用场景：
  • 慢启动应用（如大型 Java 应用、数据库）。
  • 避免 Liveness Probe 在应用启动期间误判。

二、探针执行方式

每种探针支持三种执行方式，通过exec、httpGet或tcpSocket实现：

1. Exec Action

• 方式：在容器内执行命令，返回状态码 0 表示成功。
• 示例：

  yaml

  livenessProbe:
    exec:
      command:
      - cat
      - /tmp/healthy
  

2. HTTP Get Action

• 方式：向容器发送 HTTP 请求，返回状态码 200-399 表示成功。
• 示例：

  yaml

  readinessProbe:
    httpGet:
      path: /healthz
      port: 8080
      httpHeaders:
      - name: Custom-Header
        value: Awesome
  

3. TCP Socket Action

• 方式：尝试与容器的指定端口建立 TCP 连接，连接成功表示正常。
• 示例：

  yaml

  startupProbe:
    tcpSocket:
      port: 3306
  

三、探针参数配置

探针支持多种参数调整检测行为：

yaml

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15       # 容器启动后等待15秒再开始检测
  periodSeconds: 10             # 每10秒检测一次
  timeoutSeconds: 1             # 超时时间1秒
  successThreshold: 1           # 连续1次成功视为健康
  failureThreshold: 3           # 连续3次失败视为不健康

四、探针检测不通过的处理机制

探针类型	检测失败后的行为	自动恢复机制
Liveness	容器被重启（Restart）	按 Pod 的restartPolicy（默认Always）重启
Readiness	容器从 Service 的 Endpoint 中移除	探针恢复后重新加入 Endpoint
Startup	容器被重启	启动成功前持续重试（直到达到failureThreshold）

五、典型应用场景

1. Liveness Probe 示例

检测 Redis 容器是否响应：

yaml

livenessProbe:
  exec:
    command:
    - redis-cli
    - ping
  initialDelaySeconds: 30
  periodSeconds: 10

2. Readiness Probe 示例

检测应用是否完成初始化：

yaml

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 1

3. Startup Probe 示例

处理慢启动的数据库：

yaml

startupProbe:
  tcpSocket:
    port: 5432
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 20  # 允许较长时间启动（20×5=100秒）

六、注意事项与最佳实践

1. 避免探针冲突：

   • 不要同时使用 Liveness 和 Startup Probe 检测同一指标，可能导致重启循环。
   • 建议对慢启动应用优先使用 Startup Probe。

2. 合理设置参数：

   • initialDelaySeconds应大于应用的最大启动时间。
   • failureThreshold需根据应用特性调整（如数据库操作可能需要更高阈值）。

3. 探针性能影响：

   • 频繁执行探针（如periodSeconds过小）可能增加容器负载。
   • HTTP 探针建议使用轻量级健康检查接口（避免执行复杂业务逻辑）。

4. 探针结果与 Pod 状态：

   • Liveness 失败会导致 Pod 的RestartCount增加。
   • Readiness 失败不影响 Pod 状态，但会影响流量分发。

七、故障排查工具

1. 查看探针状态：

   bash

   kubectl describe pod <pod-name>  # 查看Events中的探针检测结果
   

2. 检查容器重启原因：

   bash

   kubectl get pods  # 查看RestartCount
   kubectl logs <pod-name> --previous  # 查看上一个容器的日志
   

3. 手动测试探针：

   bash

   kubectl exec <pod-name> -- cat /tmp/healthy  # 测试Exec探针
   kubectl port-forward <pod-name> 8080:8080    # 本地访问测试HTTP探针
   

通过合理配置探针，Kubernetes 可以自动处理应用故障、优化流量分发，并提高系统的可用性和稳定性。

2、扩展：可以同时使用Liveness Probe、Readiness Probe和Startup Probe吗？

在 Kubernetes 中，可以同时使用 Liveness Probe、Readiness Probe 和 Startup Probe，但需要根据应用特性合理配置，避免冲突或冗余。以下是详细分析：

一、组合使用的场景与策略

1. 典型场景

• 慢启动应用（如大型 Java 应用、数据库）：

  • Startup Probe：检测应用是否完成启动，避免 Liveness Probe 在启动期间误判重启。
  • Liveness Probe：应用启动后，持续检测运行状态。
  • Readiness Probe：确保应用只在真正就绪时接收流量（如数据库连接池初始化完成）。

• 快速启动但可能崩溃的应用：

  • Liveness Probe：检测应用是否崩溃或陷入死锁。
  • Readiness Probe：处理临时不可用状态（如缓存预热）。

2. 配置示例

yaml

apiVersion: v1
kind: Pod
metadata:
  name: app-with-all-probes
spec:
  containers:
  - name: slow-start-app
    image: my-app:v1
    ports:
    - containerPort: 8080
    
    # 启动探针：允许应用有较长的启动时间
    startupProbe:
      httpGet:
        path: /health
        port: 8080
      failureThreshold: 30  # 允许30次失败（假设每次间隔10秒，即5分钟启动时间）
      periodSeconds: 10
    
    # 存活探针：启动后检测应用是否存活
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 60  # 等待Startup Probe成功后再启动
      periodSeconds: 10
    
    # 就绪探针：检测应用是否准备好接收流量
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5

二、组合使用的注意事项

1. 避免探针冲突

• Startup Probe 与 Liveness Probe：

  • 若同时使用，需确保 Startup Probe 成功后再启用 Liveness Probe（通过initialDelaySeconds设置足够长的延迟）。
  • 否则可能导致 Startup Probe 尚未完成，Liveness Probe 已开始检测并触发重启。

• Readiness Probe 与 Liveness Probe：

  • 两者检测逻辑应不同。例如：
    • Readiness Probe 检查应用是否准备好处理请求（如依赖服务是否连接）。
    • Liveness Probe 检查应用是否基本功能正常（如进程是否响应）。

2. 参数调优策略

• Startup Probe：

  • failureThreshold应设置足够高，允许应用有足够的启动时间。
  • periodSeconds可适当延长（如 10-30 秒），减少启动期间的探测压力。

• Liveness Probe：

  • initialDelaySeconds需大于应用的最大启动时间，避免干扰 Startup Probe。
  • periodSeconds不宜过短（如 < 5 秒），防止频繁检测影响性能。

• Readiness Probe：

  • periodSeconds可设置较短（如 3-5 秒），快速响应应用状态变化。
  • failureThreshold可设为 1，快速将不可用实例从负载均衡中移除。

三、组合使用的潜在问题与解决方案

问题	原因	解决方案
启动循环重启	Startup Probe 未完成，Liveness Probe 已触发检测并失败。	确保 Liveness Probe 的initialDelaySeconds > 应用启动时间 + Startup Probe 的最大检测时间。
流量中断频繁	Readiness Probe 过于敏感，导致实例频繁被移除 / 添加。	增加successThreshold（如 2-3），避免短暂波动导致误判。
资源消耗过高	三个探针同时高频执行，增加容器负载。	合理设置periodSeconds（如 Startup 10s、Liveness 10s、Readiness 5s）。

四、最佳实践总结

1. 优先使用 Startup Probe：对于启动时间不确定的应用，用 Startup Probe 保护启动过程，避免被 Liveness 误杀。
2. 分离检测逻辑：
   • Liveness Probe：检测应用是否存活（如进程响应）。
   • Readiness Probe：检测应用是否能正常服务（如依赖服务是否可用）。
3. 渐进式配置：
   • 先配置 Readiness Probe 确保流量安全。
   • 再添加 Liveness Probe 处理崩溃恢复。
   • 最后按需添加 Startup Probe（仅慢启动应用需要）。
4. 监控与迭代：
   • 通过 Prometheus 监控探针成功率和容器重启率。
   • 根据实际运行情况调整探针参数（如延长initialDelaySeconds）。

通过合理组合和配置三种探针，Kubernetes 可以实现：

• 慢启动应用的可靠初始化。
• 运行时故障的自动恢复。
• 流量的智能分发与隔离。

3、扩展：java应用一般使用哪种探针？具体如何配置？

在 Kubernetes 中部署 Java 应用时，探针（Probe）的配置需要结合 Java 应用的特性（如启动慢、依赖外部资源等）进行优化。以下是针对 Java 应用的探针配置策略和具体实现：

一、Java 应用的探针选择

1. 推荐组合

• Startup Probe：处理 Java 应用的长启动时间（如 Spring Boot 应用可能需要 30 秒至数分钟加载）。
• Liveness Probe：检测应用是否处于健康运行状态（如 JVM 是否响应、关键服务是否可用）。
• Readiness Probe：确保应用只在完全就绪时接收流量（如数据库连接池初始化完成、缓存预热）。

2. 特殊考虑

• 内存泄漏风险：Java 应用可能因内存泄漏导致 OOM，需结合资源限制（resources.limits.memory）和 Liveness Probe 检测。
• 外部依赖：如依赖数据库、Redis，需通过 Readiness Probe 验证连接状态。

二、探针配置实现

1. HTTP 端点检测（推荐方式）

前提条件：Java 应用需暴露健康检查接口（如 Spring Boot Actuator 的/health端点）。

示例配置：

yaml

apiVersion: v1
kind: Pod
metadata:
  name: java-app-pod
spec:
  containers:
  - name: java-app
    image: my-java-app:v1
    ports:
    - containerPort: 8080
    
    # 启动探针：允许较长启动时间
    startupProbe:
      httpGet:
        path: /actuator/health
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 10
      failureThreshold: 15  # 允许150秒启动时间（10×15）
    
    # 存活探针：检测应用是否运行正常
    livenessProbe:
      httpGet:
        path: /actuator/health
        port: 8080
      initialDelaySeconds: 180  # 确保Startup Probe完成后再启动
      periodSeconds: 30
      timeoutSeconds: 5
    
    # 就绪探针：检测应用是否准备好接收流量
    readinessProbe:
      httpGet:
        path: /actuator/health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 5
      successThreshold: 2  # 连续2次成功才认为就绪

2. 自定义执行命令（备选方式）

若应用未暴露 HTTP 端点，可通过exec执行 Java 命令检测。

示例配置：

yaml

livenessProbe:
  exec:
    command:
    - sh
    - -c
    - |
      # 使用jstat检查JVM是否响应
      jstat -gc $(pgrep java) >/dev/null 2>&1 || exit 1
  initialDelaySeconds: 60
  periodSeconds: 30

3. TCP 端口检测（简单场景）

仅验证应用端口是否开放（不验证应用内部状态）。

示例配置：

yaml

readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 20
  periodSeconds: 5

三、高级配置技巧

1. 定制 Spring Boot 健康检查

通过自定义HealthIndicator实现更精细的健康检查：

java

@Component
public class DatabaseHealthIndicator implements HealthIndicator {

    @Autowired
    private DataSource dataSource;

    @Override
    public Health health() {
        try (Connection connection = dataSource.getConnection()) {
            // 验证数据库连接是否正常
            return Health.up().build();
        } catch (SQLException e) {
            return Health.down().withDetail("error", e.getMessage()).build();
        }
    }
}

2. 结合资源限制预防 OOM

yaml

resources:
  requests:
    memory: "512Mi"
    cpu: "200m"
  limits:
    memory: "1Gi"     # 防止Java应用因内存泄漏导致OOM
    cpu: "500m"

3. 使用 Startup Probe 处理类加载延迟

对于大型 Java 应用（如微服务），可增加 Startup Probe 的宽容度：

yaml

startupProbe:
  httpGet:
    path: /actuator/health
    port: 8080
  failureThreshold: 20  # 允许更长启动时间
  periodSeconds: 15    # 降低检测频率，减少资源消耗

四、常见问题与解决方案

问题	原因	解决方案
启动时频繁重启	Startup Probe 超时或 Liveness Probe 过早启动。	增加 Startup Probe 的failureThreshold，并确保 Liveness Probe 的initialDelaySeconds足够大。
流量中断	Readiness Probe 误判（如数据库连接短暂波动）。	增加successThreshold和failureThreshold，避免短暂波动导致实例被移除。
OOM 后未自动恢复	仅设置内存限制，未配置 Liveness Probe。	结合 Liveness Probe 检测 JVM 状态，在内存异常时触发重启。
健康检查消耗过多资源	探针检测频率过高或执行复杂操作。	调整periodSeconds（如 Liveness 30s、Readiness 5s），避免在健康检查中执行耗时操作。

五、最佳实践总结

1. 优先使用 HTTP 端点：通过 Spring Boot Actuator 或自定义 API 暴露健康状态。
2. 分阶段检测：
   • Startup Probe：处理启动延迟（failureThreshold设为 10-20）。
   • Liveness Probe：关注应用核心功能（如数据库连接、服务响应）。
   • Readiness Probe：验证所有依赖是否就绪（如缓存、外部 API）。
3. 参数调优：
   • 避免探针冲突：Liveness 的initialDelaySeconds > Startup 的最大检测时间。
   • 平衡敏感度：Readiness 的failureThreshold设为 2-3，减少误判。
4. 监控与日志：
   • 收集探针成功率指标（如通过 Prometheus）。
   • 记录健康检查失败日志，分析根本原因。

通过合理配置探针，Kubernetes 可以有效管理 Java 应用的生命周期，确保高可用性和弹性伸缩。