网站导航
> 技术文档 > k8s的service、deployment、探针详解

k8s的service、deployment、探针详解

网友: 技术文档 2025-07-26 20:03:38

 1.k8s组成图

 2.service和deployment的流量转发图

# Deployment 定义容器端口apiVersion: apps/v1kind: Deploymentmetadata: name: myappspec: template: spec: containers: - name: nginx image: nginx ports: - containerPort: 80 # 容器监听 80  name: http # 端口命名（可选）---# Service 定义端口映射apiVersion: v1kind: Servicemetadata: name: my-servicespec: ports: - port: 8080 # Service 暴露 8080 targetPort: http # 转发到容器中名为 \"http\" 的端口（即80） selector: app: myapp

3.pod的生命周期

Pending

- Pod 已被 API Server 接收，但尚未被调度到节点
- 可能原因：资源不足、镜像下载中、节点选择器不匹配

kubectl describe pod web1 查看 Events 中的具体原因（如 Insufficient cpu/memory）

Init:0/1

- 初始化容器正在执行（示例中总共有1个初始化容器，当前完成0个）
- 数字格式：完成数/总数

检查初始化容器的日志：
kubectl logs web1 -c

PodInitializing

- 所有初始化容器已成功完成
- 主容器正在启动（但尚未进入 Ready 状态）

通常短暂（秒级），若长时间卡在此状态，检查主容器的镜像拉取或启动命令问题

Running

- 主容器已成功启动并持续运行
- 1/1 表示：1个容器已就绪，共1个容器

可通过 kubectl exec 进入容器调试

4.容器的探针执行流程

1. Deployment 的局限性

Deployment 主要解决以下问题：

  • 副本管理：确保指定数量的 Pod 副本运行（通过 replicas 字段）。

  • 滚动更新：支持无缝升级和回滚。

  • 故障恢复：当 Pod 完全崩溃时，Deployment 会重新创建 Pod。

但它无法解决：

  • 应用逻辑层面的健康状态：Pod 进程可能正在运行，但应用内部已死锁或无响应。

  • 依赖就绪问题：Pod 已启动，但依赖的数据库/缓存尚未准备好。

  • 启动顺序问题：应用需要较长时间初始化（如 Java 应用启动慢）。

2. 探针的核心作用

探针弥补了 Deployment 的不足，提供细粒度的健康控制：

探针类型 解决的问题 示例场景 Liveness Probe 解决\"进程在但服务挂\"的问题，触发重启。 线程池耗尽、内存泄漏、死锁等故障导致无响应 Readiness Probe 解决\"临时不可用\"的问题，控制流量。 要加载大量的配置文件、建立数据库连接池、初始化缓存等操作 Startup Probe 保护慢启动应用，避免被 Liveness Probe 误杀。 某个模型启动需要较长的时间加载 
containers:- name: myapp # 存活探针（Liveness Probe）：检测容器是否处于运行但不可用的状态（如死锁），失败时会重启容器 livenessProbe: httpGet:  # 使用 HTTP GET 请求检测 path: /internal/health # 健康检查接口路径（需由应用实现） port: 8080  # 检测的容器端口 failureThreshold: 3 # 连续失败 3 次才判定为故障（默认值） # initialDelaySeconds: 0 # （未显式设置）容器启动后立即开始检测（生产环境建议设置缓冲时间） # periodSeconds: 10 # （未显式设置）默认每10秒检测一次 # timeoutSeconds: 1 # （未显式设置）默认检测超时时间为1秒 # 就绪探针（Readiness Probe）：检测容器是否准备好接收流量，失败时从 Service 负载均衡中移除该 Pod readinessProbe: httpGet: path: /api/ready # 就绪检查接口路径（可与健康检查分开） port: 8080 periodSeconds: 5 # 每 5 秒检测一次（比存活探针更频繁） # successThreshold: 1 # （未显式设置）默认成功1次即标记为就绪 # failureThreshold: 3 # （未显式设置）默认连续失败3次才判定为未就绪 # 启动探针（Startup Probe）：保护慢启动应用，避免在初始化期间被存活探针误杀 startupProbe: httpGet: path: /internal/health # 通常与存活探针使用相同接口 port: 8080 failureThreshold: 30 # 允许的最大失败次数（30次） periodSeconds: 10 # 每 10 秒检测一次 # 总启动时间 = failureThreshold × periodSeconds = 30 × 10 = 300秒（5分钟） # 在此期间，存活探针和就绪探针不会执行
网络标签：

相关问题