K8S系列之探针

K8S的探针包括存活探针(Liveness)检查容器是否需要重启,就绪探针(Readiness)确认容器是否能提供服务,启动探针(Startup)则监控容器启动状态。探针可通过脚本、HTTP、TCP或gRPC方式执行检测,确保应用和服务的稳定性和效率。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

什么是探针

探针是一种用于探测、检测、测量或监测某些物理或化学性质的工具或设备,通常由一个或多个传感器和一个数据采集和处理单元组成。探针可以被用于各种应用,例如对生物体进行检测、监测环境污染、测试材料性能等。在计算机领域中,探针也可以指一种用于监测应用程序或系统性能的工具。

K8S的3大探针

Liveness

存活探针可以检查容器是否存活,是否需要重新启动容器;有助于提高应用的可用性。

Readiness

就绪探针只有等容器可以提供服务了,才会使用K8S的服务注册机制提供服务,例如:service后端的pod,只有就绪探针没有问题才能提供服务。(如果应用有自己的注册中心,这个配置估计达不到想象中的效果)

Startup

启动探针可以了解容器何时准备启动,如果配置了这类探针,你就可以控制容器在启动成功后再进行存活性和就绪态检查, 确保这些存活、就绪探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测,避免它们在启动运行之前就被杀掉。

K8S探针探测的4大形式

脚本

定义一组需要容器内执行的脚本命令

apiVersion: v1

kind: Pod

metadata:

  labels:

    test: liveness

  name: liveness-exec

spec:

  containers:

  - name: liveness

    image: registry.k8s.io/busybox

    args:

    - /bin/sh

    - -c

    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600

    livenessProbe:

      exec:

        command:

        - cat

        - /tmp/healthy

      initialDelaySeconds: 5

      periodSeconds: 5

执行如下命令

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"

http

container需要提供http get接口,kubelet会调用http请求,根据response status来判断之后的操作。

apiVersion: v1

kind: Pod

metadata:

  labels:

    test: liveness

  name: liveness-http

spec:

  containers:

  - name: liveness

    image: registry.k8s.io/liveness

    args:

    - /server

    livenessProbe:

      httpGet:

        path: /healthz

        port: 8080

        httpHeaders:

        - name: Custom-Header

          value: Awesome

      initialDelaySeconds: 3

      periodSeconds: 3

tcp

测试端口的连通性,判断进程是否可用

apiVersion: v1

kind: Pod

metadata:

  labels:

    test: liveness

  name: liveness-http

spec:

  containers:

  - name: liveness

    image: registry.k8s.io/liveness

    args:

    - /server

    livenessProbe:

      httpGet:

        path: /healthz

        port: 8080

        httpHeaders:

        - name: Custom-Header

          value: Awesome

      initialDelaySeconds: 3

      periodSeconds: 3

gRPC

开启GRPCContainerProbe来支持grpc调用

apiVersion: v1

kind: Pod

metadata:

  name: etcd-with-grpc

spec:

  containers:

  - name: etcd

    image: registry.k8s.io/etcd:3.5.1-0

    command: [ "/usr/local/bin/etcd", "--data-dir",  "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"]

    ports:

    - containerPort: 2379

    livenessProbe:

      grpc:

        port: 2379

      initialDelaySeconds: 10

总览

在这里插入图片描述

<think>好的,我现在要解释一下Kubernetes中的readinessGates。首先,我需要回忆一下Kubernetes中的Pod生命周期和相关探针的概念。readinessGates听起来像是一种控制Pod就绪状态的机制,可能和就绪探针(readinessProbe)有关,但可能有所不同。 我记得Pod的就绪状态通常由就绪探针决定,用来判断Pod是否准备好接收流量。如果探针失败,Pod就不会被添加到服务的端点列表中。那readinessGates是什么呢?根据名称,"gate"可能意味着额外的条件,需要满足这些条件才能认为Pod就绪。 可能需要查阅Kubernetes的文档或者相关资料。根据之前的了解,readinessGates是在Pod的spec中定义的一个字段,允许用户指定一系列条件,这些条件必须全部满足,Pod才会被认为是就绪的。这些条件可能由外部系统设置,比如节点控制器或者其他自定义的控制器。 举个例子,假设Pod需要满足两个条件:一个是传统的就绪探针通过,另一个是某个自定义的条件(如外部系统的健康检查)。这时候,readinessGates就可以用来添加这个额外的条件,确保两者都满足后Pod才被视为就绪。 需要确认的是,readinessGates的工作方式是否和节点就绪条件类似。节点就绪条件需要满足所有指定的条件才能使节点就绪。同样,Pod的readinessGates可能也需要所有指定的条件状态为True,Pod才会就绪。 另外,可能需要了解如何配置readinessGates。比如,在Pod的spec中添加readinessGates字段,指定条件类型。然后,这些条件的状态由控制器更新到Pod的status字段中。只有当所有readinessGates的条件都为True时,加上原有的就绪探针通过,Pod才会处于就绪状态。 还需要考虑使用场景。比如,在混合环境中,Pod可能需要等待外部负载均衡器配置完成,或者等待某些存储卷准备好。这时,通过readinessGates可以确保这些外部条件满足后才开始接收流量。 需要注意的是,readinessGates是Kubernetes 1.14版本引入的功能,所以需要确认用户使用的集群版本是否支持。此外,正确设置这些条件的状态是关键,可能需要编写自定义的控制器或者使用现有的解决方案来管理这些条件。 总结一下,readinessGates扩展了Pod的就绪判定机制,允许引入外部或自定义条件作为就绪状态的前提。这样增加了灵活性,适用于复杂的部署场景,确保Pod在满足所有必要条件后才开始服务流量。</think>在Kubernetes中,`readinessGates` 是一种扩展Pod就绪状态判断的机制。以下为逐步说明: --- ### **1. 核心作用** `readinessGates` 允许为Pod定义**额外的就绪条件**(Readiness Conditions),这些条件必须全部满足,Pod才会被标记为就绪(`Ready`)。 👉 **与传统就绪探针(`readinessProbe`)的关系**: - 传统探针通过内部检查(如HTTP请求、命令执行)判断Pod是否就绪 - `readinessGates` 提供**外部条件**补充,例如依赖外部系统状态或自定义逻辑 --- ### **2. 配置方式** 在Pod的`spec`中定义`readinessGates`字段,例如: ```yaml apiVersion: v1 kind: Pod metadata: name: my-pod spec: readinessGates: - conditionType: "example.com/custom-condition" # 自定义条件类型 containers: - name: nginx image: nginx ``` --- ### **3. 条件状态管理** - **条件类型(ConditionType)**:需符合格式 `<域名>/<条件名称>`(如`example.com/lb-ready`) - **状态更新**:由外部控制器或自定义控制器通过Kubernetes API更新Pod的`status.conditions`字段,例如: ```yaml status: conditions: - type: "example.com/custom-condition" status: "True" # 或 "False" lastProbeTime: null lastTransitionTime: "2023-10-05T08:00:00Z" ``` --- ### **4. 就绪判定逻辑** Pod的总体就绪状态需满足: 1. **所有容器通过`readinessProbe`检查**(如果配置了探针) 2. **所有`readinessGates`中定义的条件状态均为`True`** ❗ 任意条件不满足时,Pod的`Ready`状态为`False`,不会加入Service的Endpoint列表。 --- ### **5. 典型使用场景** - **依赖外部系统**:等待负载均衡器配置完成 - **资源同步**:确保配置文件或密钥从外部存储加载完毕 - **自定义健康检查**:集成非Kubernetes原生的健康检查逻辑 --- ### **6. 操作示例** 假设定义了一个条件`cloud-provider.com/lb-attached`: 1. Pod创建后,Kubernetes等待该条件变为`True` 2. 负载均衡器控制器完成配置后,将此条件状态更新为`True` 3. 当所有`readinessGates`条件通过,且容器探针成功,Pod标记为就绪 --- ### **7. 注意事项** - **版本要求**:Kubernetes 1.14+ - **条件更新责任**:需自行实现控制器更新条件状态,否则Pod可能卡在未就绪状态 - **调试工具**:使用`kubectl describe pod <pod-name>`查看`Conditions`字段状态 --- 通过`readinessGates`,Kubernetes提供了更灵活的就绪状态控制能力,适用于复杂环境中的精细化部署管理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值