Configure Liveness, Readiness and Startup Probes | Kubernetes

对官方文档的阅读、理解，做一个记录。

用到哪里看到哪里。

看之前，总结之前，要问自己，是想真的搞懂，还是想应付了事，为了完成而完成，如果是后者，那就不用再继续下去了。

kubelet 使用 livenessProbe 用于判断何时重启容器，可以使用和readinessProbe相同的http方式，但是failureThreshold更长，为的是能够在该容器被hard kill之前是not ready的。

kubelet使用 readinessProbe 用于判断何时准备接受流量，pod中的所有容器都需要ready，才可以作为service 的后端。当pod没有ready时，或者变成not ready时将会从service 负载均衡中移除；

kubelet 使用startupProbe来判断何时容器应用已经启动，直到这个startupProbe执行检测成功之后才会执行livenessProbe/readinessProbe。startupProbe 的使用场景就是那些启动时间较长的应用，避免容器被livenessProbe kill掉。

之所以写这个kubelet就是想说，是kubelet发起的liveness/readiness/startup probe。

实验环境：

1. 如果你有集群，可能使用自己的集群，如果你没有可以使用killcoda：K8s 1.26 Playground | Killercoda

配置一个command 类型的 livenessProbe

有的应用长时间运行可能会转变成不可用状态，需要重启，livenessProbe会检测这种情况，并重启pod；

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:

# liveness 执行探针的一种方式，即执行shell命令的方式，执行成功 返回0，即认为pod alive and healthy，如果执行失败，返回非0值，kubelet将会重启pod；

      exec:

        command:

        - cat

        - /tmp/healthy

#    initialDelaySeconds 代表第一次执行liveness 需要等待的时间，如下为5秒，

      initialDelaySeconds: 5

#    periosSeconds 表示执行liveness的时间间隔，如下为每5秒执行一次；

      periodSeconds: 5
 

配置一个 http request 的livenessProbe

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
 

执行http请求，返回等于200 或者小于400 的status值，即为成功，kubelet 认定容器alive and healthy，如果返回其他status 则认定为失败。就目前的资料来看。不能自定义 success status  

上述配置的/healthz接口，在前10秒内 返回200 ，大于10秒就返回500，返回500 就会重启容器；

配置一个tcp 的livenessProbe

通过建立tcp连接，来确定容器的状态，如果能个创建tcp 连接，则视为健康，如果不能，则会视为失败；

apiVersion: v1

kind: Pod

metadata:

  name: goproxy

  labels:

    app: goproxy

spec:

  containers:

  - name: goproxy

    image: registry.k8s.io/goproxy:0.1

    ports:

    - containerPort: 8080

    readinessProbe:

      tcpSocket:

        port: 8080

      initialDelaySeconds: 5

      periodSeconds: 10

    livenessProbe:

      tcpSocket:

        port: 8080

      initialDelaySeconds: 15

      periodSeconds: 20
 

上述配置中，使用了readiness、liveness两中。
readiness 的配置中，是容器启动后5秒开始探测，如果成功则pod视为ready，kubelet会每10秒钟检测一次。

liveness 的配置中，是容器启动后15秒后开始探测，如果不成功则会restart容器。

配置一个grpc livenessProbe

grpc liveness 需要1.24以及以后版本支持

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
 

使用grpc probe，port必须配置。

# 没看懂。。。。。

If you want to distinguish probes of different types and probes for different features you can use the service field. You can set service to the value liveness and make your gRPC Health Checking endpoint respond to this request differently then when you set service set to readiness. This lets you use the same endpoint for different kinds of container health check (rather than needing to listen on two different ports). If you want to specify your own custom service name and also specify a probe type, the Kubernetes project recommends that you use a name that concatenates those. For example: myservice-liveness (using - as a separator).

grpc 不能按名称指定健康检查端口，也不能配置自定义主机名；

配置问题（configuration problems) 例如错误的端口（port)和服务（service）、为应用健康检查协议，会被认定为探测失败。

# 没看懂

Before Kubernetes 1.23, gRPC health probes were often implemented using grpc-health-probe, as described in the blog post Health checking gRPC servers on Kubernetes. The built-in gRPC probes behavior is similar to one implemented by grpc-health-probe. When migrating from grpc-health-probe to built-in probes, remember the following differences:

• Built-in probes run against the pod IP address, unlike grpc-health-probe that often runs against 127.0.0.1. Be sure to configure your gRPC endpoint to listen on the Pod's IP address.
• Built-in probes do not support any authentication parameters (like -tls).
• There are no error codes for built-in probes. All errors are considered as probe failures.
• If ExecProbeTimeout feature gate is set to false, grpc-health-probe does not respect the timeoutSeconds setting (which defaults to 1s), while built-in probe would fail on timeout.

使用已命名的接口

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port

给启动慢的容器 ，配置startup 探针

与liveness/readiness probe 配置上的区别是，有更长的failureThreshold * periodSeconds

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

 上述配置的startupProbe 有 30 * 10 = 600秒（5分钟）的时间来启动。一旦startupprobe检测成功，livenessProbe 就会接管接下的探测工作，如果执行不成功，那么就在5分钟后，根据pod 的重启策略进行 pod重启；

定义一个 readinessProbe

如果readinessProbe检测不通过，该pod不会作为service 的endpoint接受流量，处理请求；
readinessProbe运作与容器的整个生命周期；
与livenessProbe的区别，就是使用readinessProbe定义：

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

 配置readinessProbe和livenessProbe的方式基本相同；

livenessProbe和readinessProbe并行使用，保证当pod执行livenessProbe/readinessProbe执行失败后，不接收流量，处理请求，并且重启容器；

probe参数说明

initialDelaySeconds： 容器启动多久执行startup/liveness/readiness 探针，默认0秒，最小0秒；

periodSeconds：间隔多久执行一次探针，默认10秒，最小1秒；

timeoutSeconds： 探测超时后的时间，单位秒，默认1秒，最小1秒，1.20以后版本生效；

successThreshold： 探测失败后被视为成功的最少连续成功次数。默认值1，liveness和startup必须是1，最小值是1；

failureThreshold： 失败次数，失败多少次被认定为失败

terminationGracePeriodSeconds：重启的等待时间，默认是继承 Pod-level 的 terminationGracePeriodSeconds 值（如果不指定则为 30 秒），最小值是1；

httpProbe参数

host：请求的地址；

scheme： http /https ,默认http

path：请求的路径，默认/;

httpHeaders: 自定义header；

port： 端口；可以是端口名，也可以是端口号；取值范围 1-65535；

tcpProbe

对于 TCP 探测，kubelet 在节点而不是 pod 中建立探测连接，这意味着您不能在主机参数中使用服务名称，因为 kubelet 无法解析它

probe-level terminationGracePeriodSeconds

1.21 版本以后，pod-level terminationGracePeriodSeconds被用来在liveness/startup  probe 检测失败后终止容器。当terminationGracePeriodSeconds被设置以后，会导致失败的容器会费特别长的时间来重新启动。

在1.25及以上版本，可以在probe-level 配置terminationGracePeriodSeconds。当pod_level和probe-level都配置的时候kubelet 会使用probe-level 的值；

注意事项：
1.25 版本以后，ProbeTerminationGracePeriod 默认开启，如果不想开启这个功能，需要注意：

1. ProbeTerminationGracePeriod 功能门控仅在 API 服务器上可用。如果 Pod 上存在探测级别的 terminationGracePeriodSeconds 字段，则 kubelet 始终遵守该字段。

2. 如果您有设置了 terminationGracePeriodSeconds 字段的现有 Pod，并且您不再希望使用每个探测器的终止宽限期，则必须删除这些现有的 Pod。 

3. 当您（或控制平面或其他组件）创建替换 Pod 时，功能门 ProbeTerminationGracePeriod 被禁用，那么 API server会忽略 Probe 级别的 terminationGracePeriodSeconds 字段，即使 Pod 或 Pod 模板指定了它。

 

spec:
  terminationGracePeriodSeconds: 3600  # pod-level
  containers:
  - name: test
    image: ...

    ports:
    - name: liveness-port
      containerPort: 8080
      hostPort: 8080

    livenessProbe:
      httpGet:
        path: /healthz
        port: liveness-port
      failureThreshold: 1
      periodSeconds: 60
      # Override pod-level terminationGracePeriodSeconds #
      terminationGracePeriodSeconds: 60

不能为就绪探测设置探测级终止GracePeriodSeconds。它将被 API 服务器拒绝。