k8s之Pod健康检测

对于Pod的健康状态检测，kubernetes提供了两类探针(Probes)来执行对Pod的健康状态检测：LivenessProbe和ReadinessProb。

LivenessProbe：用于判断容器是否存活，即running状态，如果LivenessProbe探针探测到容器不健康，则kubelet将kill掉容器，并根据容器的重启策略是否重启，如果一个容器不包含LivenessProbe探针，则Kubelet认为容器的LivenessProbe探针的返回值永远成功。
ReadinessProbe探针：用于判断容器是否启动完成，即容器的Ready是否为True，可以接收请求，如果ReadinessProbe探测失败，则Pod的状态将被修改，控制器将此Pod的Endpoint从 对应的service的Endpoint列表中移除，从此以后不再调度此Pod上。

每类探针都支持三种探测方法：

  • exec: 通过执行命令来检查服务是否正常，针对复杂检测或无HTTP接口的服务，如果该命令的返回值为0表示，则表示容器健康。
  • httpGet：通过http请求方式检查服务是否正常，返回200-399状态码则容器健康。
  • tcpSocket：通过容器的IP和Port执行TCP检查，如果能够建立TCP连接，则表明容器健康。

探针探测的结果有以下三者之一：

  • Success：Container通过了检查。
  • Failure：Container未通过检查。
  • Unknown：未能执行检查，因此不采取任何措施。

示例一：通过exec方式做健康探测

exec-liveness.yaml
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

在该配置文件中，对容器执行livenessProbe检查，periodSeconds字段指定kubelet每5s执行一次检查，检查的命令为cat /tmp/healthy，initialDelaySeconds字段告诉kubelet应该在执行第一次检查之前等待5秒，
如果命令执行成功，则返回0，那么kubelet就认为容器是健康的，如果为非0，则Kubelet会Kill掉容器并根据重启策略来决定是否需要重启。

当容器启动时，它会执行以下命令：

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

对于容器的前30秒，有一个/tmp/healthy文件。因此，在前30秒内，该命令cat /tmp/healthy返回成功代码。30秒后，cat /tmp/healthy返回失败代码。

创建Pod：

      kubectl create -f https://k8s.io/examples/pods/probe/exec-liveness.yaml

在30秒内，查看Pod事件：

 kubectl describe pod liveness-exec

输出表明尚未探测到失败：

   FirstSeen    LastSeen    Count   From            SubobjectPath           Type        Reason      Message
--------- --------    -----   ----            -------------           --------    ------      -------
24s       24s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e

35秒后，再次查看Pod事件：

kubectl describe pod liveness-exec

在输出的中显示探测失败，并且容器已被杀死并重新创建。

FirstSeen LastSeen    Count   From            SubobjectPath           Type        Reason      Message
--------- --------    -----   ----            -------------           --------    ------      -------
37s       37s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e
2s        2s      1   {kubelet worker0}   spec.containers{liveness}   Warning     Unhealthy   Liveness probe failed: cat: can‘t open ‘/tmp/healthy‘: No such file or directory

再等30秒，确认Container已重新启动：

kubectl get pod liveness-exec

下面输出中RESTARTS的次数已增加：

AME            READY     STATUS    RESTARTS   AGE
liveness-exec   1/1       Running   1          1m

示例二：通过HTTP方式做健康检查

pods/probe/http-liveness.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

在配置文件中，使用k8s.gcr.io/liveness镜像，创建出一个Pod，其中periodSeconds字段指定kubelet每3秒执行一次探测，initialDelaySeconds字段告诉kubelet延迟等待3秒，探测方式为向容器中运行的服务发送HTTP GET请求，请求8080端口下的/healthz, 任何大于或等于200且小于400的代码表示成功。任何其他代码表示失败。

创建此Pod

kubectl create -f https://k8s.io/examples/pods/probe/http-liveness.yaml

10秒后，查看Pod事件以验证liveness探测失败并且Container已重新启动：

kubectl describe pod liveness-http

示例三：通过HTTP方式做健康检查
Kubelet将尝试在指定的端口上打开容器上的套接字，如果能建立连接，则表明容器健康。

pods/probe/tcp-liveness-readiness.yaml
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

TCP检查方式和HTTP检查方式非常相似，示例中两种探针都使用了，在容器启动5秒后，kubelet将发送第一个readinessProbe探针，这将连接到容器的8080端口，
如果探测成功，则该Pod将被标识为ready，10秒后，kubelet将进行第二次连接。
除此之后，此配置还包含了livenessProbe探针，在容器启动15秒后，kubelet将发送第一个livenessProbe探针，仍然尝试连接容器的8080端口，如果连接失败则重启容器。
创建：

kubectl create -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml

15秒后，查看Pod事件以验证活动探测：

kubectl describe pod goproxy

当容器有多个端口时，通常会给每个端口命名，所以在使用探针探测时，也可以直接写自定义的端口名称

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

ReadinessProbe探针的配置：
有的时候应用程序可能暂时无法接受请求，比如在容器应用程序启动期间加载一些数据或配置文件，在这种情况下，不希望终止应用程序也不让它处理请求，则使用ReadinessProbe探针。
ReadinessProbe探针探测容器是否已准备就绪，如果未准备就绪则kubernetes不会将流量转发给此Pod。

ReadinessProbe探针的配置与livenessProbe的配置方式相似，只不过是将livenessProbe字段修改为ReadinessProbe。

 readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

ReadinessProbe探针的HTTP、TCP的探测方式也与livenessProbe的基本一致。

配置探针(Probe)相关属性

探针(Probe)有许多可选字段，可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe)

  • initialDelaySeconds: Pod启动后延迟多久才进行检查，单位：秒
  • periodSeconds: 检查的间隔时间，默认为10，单位：秒
  • timeoutSeconds，默认为1，单位秒。
  • successThreshold：探测失败后认为成功的最小连接成功次数，默认为1，在Liveness探针中必须为1，最小值为1.
  • failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，在readiness探针中，Pod会被标记为未就绪，默认为3，最小值为1。

httpGe探测方式 t有如下可选的控制字段：

  • host：要连接的主机名，默认为Pod IP，可以在http request head中设置host头部。
  • scheme: 用于连接host的协议，默认为HTTP。
  • path：http服务器上的访问URI
  • httpHeaders：自定义HTTP请求headers，HTTP允许重复headers.
  • port： 容器上要访问端口的号或名称。
    对于HTTP的检查方式，Kubelet发送HTTP请求到指定的path和port, kubelet发送给host(默认为Pod IP).

原文地址：http://blog.51cto.com/newfly/2137136

时间： 2024-07-30 15:15:56

k8s之Pod健康检测的相关文章

k8s探测机制之pod健康检查

一:需求来源: 首先来看一下,整个需求的来源:当把应用迁移到 Kubernetes 之后,要如何去保障应用的健康与稳定呢?其实很简单,可以从两个方面来进行增强: 1,首先是提高应用的可观测性:2,第二是提高应用的可恢复能力. 从可观测性上来讲,可以在三个方面来去做增强: 1,首先是应用的健康状态上面,可以实时地进行观测:2,第二个是可以获取应用的资源使用情况:3,第三个是可以拿到应用的实时日志,进行问题的诊断与分析. 当出现了问题之后,首先要做的事情是要降低影响的范围,进行问题的调试与诊断.最后

k8s健康检测

8. 健康检测 健康 检测机制liveness和readiness 好处,避免0停机部署.避免无效镜像.更加安全回滚 restartPolicy规则,默认always,Onfailure 1.livenness使用.(程序异常,但是并没有退出) 分析判断容器健康条件,如果失败就重启 案例 cat headlth.yml apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness spec: restartPol

kubernetes之pod健康检查

目录 kubernetes之pod健康检查 1.概述和分类 2.LivenessProbe探针(存活性探测) 3.ReadinessProbe探针(就绪型探测) 4.探针的实现方式 4.1.ExecAction 4.2.HTTPGetAction 4.3.TCPSocketAction 5.探测行为属性 6.扩展的探测机制 kubernetes之pod健康检查 1.概述和分类 pod通过两类探针来检查容器的健康状态.分别是LivenessProbe(存活性探测)和ReadinessProbe(就

K8s之Pod进阶

注意此篇文章接上篇:K8s之Pod资源管理及创建Harbor私有镜像仓库https://blog.51cto.com/14464303/2471369 一.资源限制: pod和container的资源请求和限制: spec.containers[].resources.limits.cpu #cpu上限 spec.containers[].resources.limits.memory #内存上限 spec.containers[].resources.requests.cpu #创建时分配的基

集群及系统扩展之三：持久连接及健康检测

一.FWM FWM: firewall mark iptables/netfilter: filter, nat, mangle, raw mangle: 防火墙标记 前提:在ipvs生效之前的netfilter的某hook function上定义iptables规则,实现给报文打上防火墙标记: 定义方法: (1) 打标:在Director上mangle表的PREROUTING链上实现 # iptables -t mangle -A PREROUTING -d $vip -p $protocol

lvs的健康检测脚本

lvs的健康检测脚本 写得不怎么样,基本实现吧,因为基本不会用到,有时间再改进了,嘻嘻 1 #!/bin/bash 2 3 rs=('192.168.61.130' '192.168.61.132') 4 vip="192.168.61.100" 5 dip="192.168.61.131" 6 checkcount=1 7 checkloop=4 8 i=1 9 10 11 while [ $i -lt 2 ];do 12     #sorry server检测,

nginx下后端realserver健康检测模块ngx_http_upstream_check_module

想用Nginx或者Tengine替代LVS,即能做七层的负载均衡,又能做监控状态检测,一旦发现后面的realserver挂了就自动剔除,恢复后自动加入服务池里,可以用Tengine的ngx_http_upstream_check_module模块.本文主要介绍在工作中,搭建遇到问题及处理方法,便以后查询. 首先,我们大多数站点都是nginx+tomcat这个比较常见模式,其实nginx本身也有自己的健康检测模块,本人觉得不好用,故使用ngx_http_upstream_check_module.

部署AlwaysOn第三步：集群资源组的健康检测和故障转移

资源组是由一个或多个资源组成的组,WSFC的故障转移是以资源组为单位的,资源组中的资源是相互依赖的.一个资源所依赖的其他资源必须和该资源处于同一个资源组,跨资源组的依赖关系是不存在的.在任何时刻,每个资源组都仅属于集群中的一个结点,该结点就是资源组的活跃结点(Active Node),由活跃结点为应用程序提供服务.AlwaysOn建立在WSFC的健康检测和故障转移的特性之上,和故障转移集群有了不可分割的关系,因此,从底层的集群资源来理解可用性组,知其然知,其所以然,有助于更好地维护AlwaysO

K8s的POD连接数据库时报错

[[email protected] xxxx]# ./showlog.sh dr iff-dr-1128668949-lb90g 2017-09-29 03:21:57,575 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 2017-09-29 03:21:57,612 INFO [org.wildfly.s