k8s 探针

文章介绍了Kubernetes中的三种探针——存活探针、就绪探针和启动探针,它们分别用于检查容器运行、响应请求及应用程序启动情况。当探针检查失败时,系统会采取相应措施,如重启容器或停止流量调度。文章还通过示例yaml配置展示了如何设置这三种探针,并解释了其在实际操作中的影响。

1.前言

Kubernetes探针(Probe)是用于检查容器运行状况的一种机制。探针可以检查容器是否正在运行,容器是否能够正常响应请求,以及容器内部的应用程序是否正常运行等。在Kubernetes中,探针可以用于确定容器的健康状态,如果容器的健康状态异常,Kubernetes将会采取相应的措施,例如重启容器或将其从服务中删除

2.探针类型

k8s有三种类型的探针分别是Liveness Probe(存活探针)、Readiness Probe(就绪探针)、Startup Probe(启动探针)

Liveness Probe:用于检查容器是否正在运行,如果Liveness Probe检查失败,则Kubernetes将重启容器

Readiness Probe:用于检查容器是否能够正常响应请求,如果Readiness Probe检查失败,则Kubernetes将停止将流量发送到该容器

Startup Probe:用于检查容器内部的应用程序是否已经启动并且已经准备好接受流量,如果Startup Probe检查失败,则Kubernetes将重启容器

总的来说存活探针、启动探针在检测容器的探针失败时重启容器,就绪探针在检测容器的探针失败时禁止将流量调度到该容器,一般都是将就绪探针和存活探针一起使用,启动探针只在启动较慢的容器中结合使用,避免因为容器启动时间较长导致存活探针检测容器以为是不存活而一直重启容器,但是也可以将存活探针的检测时间设置长一点来解决此问题

3.探针的检测流程

同时使用三种探针的情况下

启动探针检测:在容器启动时,Kubernetes 将首先执行启动探针。如果启动探针失败,则 Kubernetes 将重启容器。启动探针只会在容器启动时执行一次

定期检测存活探针:存活探针用于检测容器是否处于运行状态。Kubernetes 将定期执行存活探针来确保容器仍然处于运行状态。如果探针失败,则 Kubernetes 将重启容器

定期检测就绪探针:就绪探针用于检测容器是否已准备好接收流量。Kubernetes 将定期执行就绪探针来确保容器已准备好接收流量。如果探针失败,则 Kubernetes 将从服务的端点中删除该容器,直到探针再次成功

4.探针的使用

 4.1启动探针

编辑yaml文件

vi deployment-nginx.yaml 

apiVersion: apps/v1
kind: Deployment
metadata: 
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 5
  progressDeadlineSeconds: 600
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx:1.21
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        startupProbe:
          httpGet:
            path: /
            port: 81
            scheme: HTTP
          initialDelaySeconds: 20
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
#  type: NodePort
  type: ClusterIP 
  clusterIP:
#  sessionAffinity: ClientIP
  ports:
    - port: 80
      targetPort: 80
#      nodePort: 30001
      protocol: TCP

该yaml的启动探针配置检测一个不存在服务的端口来检测启动探针的效果,执行yaml看看效果

kubectl create -f deployment-nginx.yaml 

kubectl get pod

可以看到因为配置的启动探针探测失败的原因pod一直处于重启的状态,而且也是未准备的状态,未准备的状态,集群是不会调度流量到这些pod上面的

kubectl get svc

curl 10.98.231.214

也可以通过查看pod的详细信息查看状态

 

 4.2就绪探针

编辑yaml文件

vi deployment-nginx.yaml 

apiVersion: apps/v1
kind: Deployment
metadata: 
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 5
  progressDeadlineSeconds: 600
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx:1.21
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:   #配置探测的http信息
            path: /
            port: 81
            scheme: HTTP     
          initialDelaySeconds: 2  #首次发出探测请求的延迟时间,即多少秒后才开始探测
          periodSeconds: 5    #探测频率,默认为10秒
          timeoutSeconds: 5   #探测超时时间,默认为1秒
          successThreshold: 1  #处于失败状态时,需要探测成功多少次才算成功
          failureThreshold: 5   #处于成功状态时,需要探测失败多少次才算失败,默认为3

该yaml的就绪探针配置检测一个不存在服务的端口来检测就绪探针的效果,执行yaml看看效果

 kubectl get pod

 可以看到因为配置的就绪探针探测失败的原因,虽然pod状态是running,但是pod都是未准备的,接下来访问一下pod服务看看

kubectl get svc

curl 10.100.21.201

可以看到是拒绝连接的,所以因为就绪探针的原因,是没有流量调度 到这些pod上的 

也可以通过describe命令去查看pod的详细信息

 4.3存活探针

编辑yaml文件

vi deployment-nginx.yaml 

apiVersion: apps/v1
kind: Deployment
metadata: 
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 5
  progressDeadlineSeconds: 600
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx:1.21
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 81
            scheme: HTTP
          initialDelaySeconds: 30  #首次发出探测请求的延迟时间,即多少秒后才开始探测,可以根据自己的项目适当调大存活探针的首次探测时间,以免服务需要启动得时间较长,导致服务还没启动就被判定检测失败
          periodSeconds: 3          #探测频率,默认为10秒
          successThreshold: 1    #处于失败状态时,需要探测成功多少次才算成功
          timeoutSeconds: 2        #探测超时时间,默认为1秒
          failureThreshold: 3    #处于成功状态时,需要探测失败多少次才算失败,默认为3
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx
#  type: NodePort
  type: ClusterIP 
  clusterIP:
#  sessionAffinity: ClientIP
  ports:
    - port: 80
      targetPort: 80
#      nodePort: 30001
      protocol: TCP

该yaml的存活探针配置检测一个不存在服务的端口来检测存活探针的效果,执行yaml看看效果

kubectl create -f deployment-nginx.yaml 

kubectl get pod

可以看到因为存活探针检测失败得问题pod一直在重启

 也可以通过查看pod得详细信息来看到

kubectl describe pod nginx-ffcf76b97-6xplz

 

<think>嗯,用户这次想深入了解Kubernetes探针机制,特别是工作原理配置方法。从对话历史看,用户之前已经了解过K8s的层级结构规模管理,现在转向更具体的运维功能,可能是为了优化应用稳定性。 用户引用了5个站内资料片段,其中[1][4][5]直接讨论探针,[2]提到Deployment配置,[3]涉及HTTPS代理(虽然不相关但说明用户可能关注生产环境配置)。需要重点整合[1][4][5]的技术点:就绪探针的服务隔离功能、存活探针的重启机制、启动探针的延迟保护,以及三者的协同逻辑。 用户没有明确场景,但引用中多次出现"滚动更新""资源优化""企业级应用"等关键词,推测可能是运维人员或架构师,需要解决线上服务的健康管理问题。深层需求或许是避免服务中断或优化资源利用率。 回答框架考虑分三部分:先讲清三种探针的差异(用表格对比会更直观),再解析工作流程(特别是kubelet的执行机制),最后给出配置示例(突出关键参数如initialDelaySeconds的调优)。需要强调实际陷阱,比如存活探针配置不当导致的循环重启——引用[4]提到的启动探针冲突正是典型场景。 用户引用的资料里有个细节值得展开:[1]提到就绪探针能提升资源利用率,这其实关联到Service的流量分配机制,可以补充说明Endpoint Controller如何根据探针结果更新Endpoint。另外[5]指出存活探针不依赖就绪探针结果,这点需要明确强调避免误解。 最后生成的延伸问题要引导用户深入:探针调优必然涉及资源配额(如CPU限制对检测超时的影响),而大规模集群的探测风暴则是高级挑战,正好衔接用户之前问过的容器规模管理问题。</think>Kubernetes 探针(Probe)是确保容器应用**健康性**与**可用性**的核心机制,通过定期执行诊断操作来判断容器状态。以下是其工作原理、配置方法及最佳实践的详解: --- ### 一、探针类型与工作原理 | **探针类型** | **触发条件** | **核心作用** | **典型场景** | |--------------------|------------------------------|------------------------------------------------|-----------------------------------------------------------------------------| | **存活探针**<br>(Liveness Probe) | 容器运行中周期性检测 | 检测容器**是否崩溃**<br>失败时**重启容器** | 应用死锁、资源耗尽假死、进程卡死但未退出 | | **就绪探针**<br>(Readiness Probe) | 容器启动后周期性检测 | 检测容器**是否准备好接收流量**<br>失败时**从Service端点移除** | 应用启动依赖初始化(加载配置/连接数据库)、临时过载(高CPU)、滚动更新预热阶段 | | **启动探针**<br>(Startup Probe) | 容器**启动初期**一次性检测 | 保护慢启动容器<br>成功后**才启用其他探针** | Java应用加载JVM、大数据服务初始化数据集 | > **关键机制**: > - **kubelet** 在节点上执行探针(默认每10秒检测一次) > - 根据 `successThreshold`/`failureThreshold` 累计成功/失败次数决策 > - 探针结果直接影响 Pod 的 `Ready` 状态 Endpoint 列表[^1][^5] --- ### 二、探针配置方法(YAML示例) #### 1. 基础配置模板 ```yaml containers: - name: my-app livenessProbe: # 存活探针 httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 # 容器启动后等待时间 periodSeconds: 10 # 检测间隔 failureThreshold: 3 # 连续失败3次判定为故障 readinessProbe: # 就绪探针 tcpSocket: port: 8080 initialDelaySeconds: 5 timeoutSeconds: 1 # 检测超时时间 startupProbe: # 启动探针K8s v1.18+) exec: command: ["cat", "/app/initialized"] failureThreshold: 30 # 允许最多检测30次(300秒) ``` #### 2. 三种检测方式 | **方式** | 配置示例 | 适用场景 | |----------------|----------------------------------|----------------------------------| | **HTTP GET** | `httpGet: { path: /status, port: 80 }` | Web服务状态检测(返回2xx/3xx为成功) | | **TCP Socket** | `tcpSocket: { port: 3306 }` | 数据库端口连通性检测 | | **Exec命令** | `exec: { command: ["pg_isready", "-U", "postgres"] }` | 执行自定义脚本或CLI工具 | --- ### 三、最佳实践与避坑指南 1. **启动顺序优化** ```yaml startupProbe: # 先配置启动探针保护初始化 failureThreshold: 30 periodSeconds: 10 livenessProbe: # 延迟存活探针启动 initialDelaySeconds: 60 # 避免与启动阶段冲突[^4] ``` 2. **参数调优建议** - **`initialDelaySeconds`**:必须 > 容器启动时间(观察日志确定) - **`periodSeconds`**:检测频率(高频探针增加节点负载) - **`failureThreshold`**:根据应用容忍度设置(如3次失败=30秒不可用) 3. **生产环境注意事项** - ❌ 避免仅用 `livenessProbe` 检测轻量级操作(如 `/ping`),可能导致频繁重启 - ✅ 就绪探针失败时,结合 `HPA` 自动扩容缓解流量压力 - 🔒 对HTTPS服务需配置 `scheme: HTTPS` `caBundle`[^3] --- ### 四、探针工作流程示意图 ```mermaid graph TD A[容器启动] --> B{Startup Probe 检测} B -- 成功 --> C[启用 Liveness/Readiness Probe] B -- 失败 --> D[重启容器] C --> E{Readiness Probe} E -- 成功 --> F[加入 Service 负载均衡] E -- 失败 --> G[从 Endpoint 移除] C --> H{Liveness Probe} H -- 失败 --> I[重启容器] ``` > **关键点**:启动探针通过前,存活/就绪探针**不会执行**,避免误杀慢启动容器[^4][^5]。 --- ### 五、常见问题排查 - **Q:Pod 反复重启?** → 检查 `livenessProbe` 配置是否过于敏感(如检测路径响应慢) → 配合 `kubectl describe pod` 查看 `Events` 中的探针失败记录 - **Q:Service 流量不到达 Pod?** → 确认 `readinessProbe` 是否返回成功(失败时 Pod 处于 `NotReady` 状态) - **Q:探针检测超时?** → 调整 `timeoutSeconds`(默认1秒)或优化应用响应速度 通过合理配置探针Kubernetes 实现了**零停机滚动更新**、**故障自愈****流量精细调度**,成为生产环境的核心保障机制[^1][^2][^5]。 --- ####
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值