Liveness, readiness and startup probes

liveness：

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 -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
      ```
 among  initialDelaySeconds: 5 It means to wait for five seconds before starting the first detection ,periodSeconds: 5 Test every five seconds 
 Before the life of the container  30  Seconds , There is one /tmp/healthy file . therefore , before  30  Seconds , The order will cat /tmp/healthy Return a success code .30  Seconds later ,cat /tmp/healthy Return failure code 

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: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
 Here's a definition http Activity detection , If the handler returns a failure code ,kubelet  Will kill the container and restart it .
 Any greater than or equal to  200  And less than  400  All the codes indicate success . Any other code means failure 

Readiness：

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  Check the configuration and  HTTP  The inspection is very similar . This example uses both ready and active probes .
kubelet  Will start in the container  5  Send the first ready probe... In seconds . This will try to connect to goproxy port  8080  On 
 The container of . If the probe is successful ,Pod  Will be marked as ready .kubelet  Will continue every  10  Run this check once per second 

Startup Probes：

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10
 
 Applications will have the most  5  minute  (30 * 10 = 300s)  To complete its startup . Once the probe is started, it's a success , active 
 Degree detection will take over to provide a quick response to container deadlocks . If the start probe never succeeds , Then the container is  300  second 
 After being killed and subject to  pod  Of restartPolicy,   If such a probe is configured , It will disable activity and readiness checks , Until success , Ensure that these probes do not interfere with application startup 
( It is mainly used when the starting time is too long )

Field explanation ：

initialDelaySeconds： The number of seconds after the container starts before starting the activity or ready probe . The default is 0 second . The minimum value is 0.
periodSeconds： Frequency of detection （ In seconds ）. The default is 10 second . The minimum value is 1.
timeoutSeconds: The number of seconds the probe timed out . The default is 1 second . The minimum value is 1.
successThreshold： The minimum number of consecutive successes that are considered successful after a probe fails . The default is 1. about liveness and startup Probes, It has to be for 1. The minimum value is 1.
failureThreshold： When a probe fails ,Kubernetes Will try to failureThreshold many times , Then give up. . stay liveness probe Giving up means restarting the container . In the case of ready detection ,Pod Will be marked as not ready . The default is 3. individual