kubernetes Pod Lifecycle生命周期与livenessProbe、 readinessProbe探测方法

简介: kubernetes Pod Lifecycle生命周期与livenessProbe、 readinessProbe探测方法

kuberenetes pod Liveness, Readiness and Startup Probes

tags: Pod,探针,健康检测

文章目录

kuberenetes pod Liveness, Readiness and Startup Probes

1. Pod 状态

2. Pod 生命周期条件

3. 容器探针

4. 什么时候应该使用活动或就绪探针?

5. 配置技巧

5.1 使用命名端口

5.2 使用启动探测器保护慢启动容器

6. 探测方法

6.1 http 探测

6.2 cmd 探测

6.3 TCP 探测

1. Pod 状态

Pod的status字段是 PodStatus 对象,其中包含一个phase字段。

1670824666103.png

2. Pod 生命周期条件

Pod具有PodStatus,该状态具有PodConditions数组 ,该Pod已通过或未通过。PodCondition数组的每个元素都有六个可能的字段:


该lastProbeTime字段提供上次探测Pod条件的时间戳。

该lastTransitionTime字段提供Pod上一次从一种状态转换为另一种状态的时间戳。

该message字段是人类可读的消息,指示有关过渡的详细信息。

该reason字段是条件最后一次转换的唯一单词CamelCase原因。

该status字段是一个字符串,可能的值为“ True”,“ False”和“ Unknown”。

该type字段是具有以下可能值的字符串:

PodScheduled:Pod已调度到一个节点;
Ready:Pod能够处理请求,应将其添加到所有匹配服务的负载平衡池中;
Initialized:所有初始化容器 已成功启动;
Unschedulable:例如,由于缺乏资源或其他限制,调度程序无法立即调度Pod;
ContainersReady:Pod中的所有容器已准备就绪。

3. 容器探针

有三种类型的处理程序:


ExecAction:在Container中执行指定的命令。如果命令以状态代码0退出,则认为诊断成功。

TCPSocketAction:对指定端口上的容器的IP地址执行TCP检查。如果端口打开,则认为诊断成功。

HTTPGetAction:对指定端口和路径上的容器的IP地址执行HTTP

Get请求。如果响应的状态码大于或等于200且小于400,则认为诊断成功。

每个探针具有以下三个结果之一:

  • 成功:容器通过了诊断。
  • 失败:容器无法通过诊断。
  • 未知:诊断失败,因此不应采取任何措施。

kubelet可以选择对正在运行的Container进行两种探测并对其做出反应:

livenessProbe:指示容器是否正在运行。如果活动探针失败,则kubelet将杀死Container,并且Container将接受其重新启动策略。如果容器未提供活动性探针,则默认状态为Success。

readinessProbe:指示容器是否准备好服务请求。如果就绪探针失败,则端点控制器将从与Pod匹配的所有服务的端点中删除Pod的IP地址。初始延迟之前的默认就绪状态为Failure。如果容器未提供就绪探测器,则默认状态为Success。

4. 什么时候应该使用活动或就绪探针?

如果您的Container中的进程在遇到问题或变得不正常时能够自行崩溃,则不一定需要进行活动调查;kubelet将根据Pod的自动执行正确的操作restartPolicy。


如果您希望在探测失败时杀死并重启容器,请指定活动探测,并指定restartPolicyAlways或OnFailure。


如果您仅想在探测成功后才开始向Pod发送流量,请指定就绪探测器。在这种情况下,就绪探针可能与活动探针相同,但是规范中存在就绪探针意味着Pod将在不接收任何流量的情况下启动,并且仅在探针开始成功之后才开始接收流量。如果您的容器需要在启动过程中加载大型数据,配置文件或迁移,请指定准备情况探针。


如果希望您的Container能够自行进行维护,则可以指定一个就绪探针,以检查特定于与活跃探针不同的就绪端点。


请注意,如果您只想在删除Pod时便能够清空请求,则不一定需要准备就绪探测器;删除后,无论是否准备就绪探针,Pod都会自动将自己置于未就绪状态。等待Pod中的Container停止时,Pod仍处于未就绪状态。

5. 配置技巧

5.1 使用命名端口

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080
livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port

5.2 使用启动探测器保护慢启动容器

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080
livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10
startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

幸亏有启动探测,应用程序将会有最多 5 分钟(30 * 10 = 300s) 的时间来完成它的启动。 一旦启动探测成功一次,存活探测任务就会接管对容器的探测,对容器死锁可以快速响应。 如果启动探测一直没有成功,容器会在 300 秒后被杀死,并且根据 restartPolicy 来设置 Pod 状态。

b41705914ab149ed906428aa9032a946.gif

6. 探测方法

6.1 http 探测

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - /server
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        # when "host" is not defined, "PodIP" will be used
        # host: my-host
        # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      periodSeconds: 3
      timeoutSeconds: 1
    name: liveness

periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。 kubelet 会向容器内运行的服务(服务会监听 8080 端口)发送一个 HTTP GET 请求来执行探测。 如果服务器上 /healthz 路径下的处理程序返回成功代码,则 kubelet 认为容器是健康存活的。 如果处理程序返回失败代码,则 kubelet 会杀死这个容器并且重新启动它。


任何大于或等于 200 并且小于 400 的返回代码标示成功,其它返回代码都标示失败。

6.2 cmd 探测

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0,kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值,kubelet 会杀死这个容器并重新启动它。

6.3 TCP 探测

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20


下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。 这会尝试连接 goproxy 容器的 8080 端口。 如果探测成功,这个 Pod 会被标记为就绪状态,kubelet 将继续每隔 10 秒运行一次检测。


除了就绪探测,这个配置包括了一个存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 就像就绪探测一样,会尝试连接 goproxy 容器的 8080 端口。 如果存活探测失败,这个容器会被重新启动。

参考:

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
5天前
|
Perl
|
2月前
|
存储 Kubernetes Docker
【赵渝强老师】Kubernetes中Pod的基础容器
Pod 是 Kubernetes 中的基本单位,代表集群上运行的一个进程。它由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。基础容器负责维护 Pod 的网络空间,对用户透明。文中附有图片和视频讲解,详细介绍了 Pod 的组成结构及其在网络配置中的作用。
【赵渝强老师】Kubernetes中Pod的基础容器
|
2月前
|
Prometheus Kubernetes 监控
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
|
2月前
|
运维 Kubernetes Shell
【赵渝强老师】K8s中Pod的临时容器
Pod 是 Kubernetes 中的基本调度单位,由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。临时容器用于故障排查和性能诊断,不适用于构建应用程序。当 Pod 中的容器异常退出或容器镜像不包含调试工具时,临时容器非常有用。文中通过示例展示了如何使用 `kubectl debug` 命令创建临时容器进行调试。
|
2月前
|
Kubernetes 调度 容器
【赵渝强老师】K8s中Pod中的业务容器
Pod 是 Kubernetes 中的基本调度单元,由一个或多个容器组成。除了业务容器,Pod 还包括基础容器、初始化容器和临时容器。本文通过示例介绍如何创建包含业务容器的 Pod,并提供了一个视频讲解。示例中创建了一个名为 "busybox-container" 的业务容器,并使用 `kubectl create -f firstpod.yaml` 命令部署 Pod。
|
应用服务中间件 调度 nginx
Kubernetes-项目中pod调度使用法则
前言kubernetes中部署的pod默认根据资源使用情况自动调度到某个节点。可在实际项目的使用场景中都会有更细粒度的调度需求,比如:某些pod调度到指定主机、某几个相关的服务的pod最好调度到一个节点上、Master节点不允许某些pod调度等。
2066 0
|
Kubernetes 应用服务中间件 调度
Kubernetes之Pod调度
Kubernetes调度器根据特定的算法与策略将pod调度到工作节点上。在默认情况下,Kubernetes调度器可以满足绝大多数需求,例如调度pod到资源充足的节点上运行,或调度pod分散到不同节点使集群节点资源均衡等。
1477 0
|
Kubernetes 应用服务中间件 调度
Kubernetes之Pod调度
本文讲的是Kubernetes之Pod调度【编者的话】Kubernetes调度器根据特定的算法与策略将pod调度到工作节点上。在默认情况下,Kubernetes调度器可以满足绝大多数需求,例如调度pod到资源充足的节点上运行,或调度pod分散到不同节点使集群节点资源均衡等。
2810 0
|
2天前
|
缓存 容灾 网络协议
ACK One多集群网关:实现高效容灾方案
ACK One多集群网关可以帮助您快速构建同城跨AZ多活容灾系统、混合云同城跨AZ多活容灾系统,以及异地容灾系统。
|
15天前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。