Sonda de preparación

Después de que se crea un nuevo Pod, el Servicio puede seleccionarlo inmediatamente y reenviar la solicitud al Pod. Entonces surge el problema. Por lo general, un Pod tarda en iniciarse. Si el Pod aún no está listo (puede llevar tiempo cargar la configuración) O datos, o es posible que deba realizar un procedimiento de preparación o similar). Si la solicitud se transfiere al Pod en este momento, el Pod no puede procesarla, lo que hace que la solicitud falle.

La forma en que Kubernetes resuelve este problema es agregar una sonda de preparación del servicio al pod y solo permitir que el servicio transfiera la solicitud al pod después de detectar que el pod está listo.

Readiness Probe también detecta periódicamente el Pod, y luego determina si el Pod está listo según la respuesta. Al igual que Liveness Probe, Readiness Probe también admite los siguientes tres tipos.

Exec: Probe ejecuta el comando en el contenedor y verifica el código de estado del comando exit, si el código de estado es 0, está listo.
HTTP GET: Envía una solicitud HTTP GET a la IP: Puerto del contenedor, si Probe recibe 2xx o 3xx, está listo.
Socket TCP: Intente establecer una conexión TCP con el contenedor, si se puede establecer la conexión, está listo.

Cómo funciona la sonda de preparación

El efecto de Readiness Probe se puede lograr a través de Endpoints. Cuando el Pod no está listo, borre la IP del Pod: Port de los Endpoints y luego agregue el Pod a los Endpoints cuando esté listo, como se muestra en la siguiente figura.

Figura 1 El principio de realización de Readiness Probe

Sonda de preparación

Ejecutivo

El método Exec es coherente con el método HTTP GET. Como se muestra a continuación, esta sonda ejecuta el comando ls / ready . Si el archivo existe, devuelve 0, lo que indica que el pod está listo; de lo contrario, devuelve otros códigos de estado.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:      # Readiness Probe
          exec:              # 定义 ls /ready 命令
            command:
            - ls
            - /ready
      imagePullSecrets:
      - name: default-secret

Guarde la definición de la implementación anterior en el archivo deploy-read.yaml, elimine la implementación creada anteriormente y use deploy-read.yaml para crear esta implementación.

# kubectl delete deploy nginx
deployment.apps "nginx" deleted

# kubectl create -f deploy-read.yaml
deployment.apps/nginx created

Aquí, dado que la imagen nginx no contiene el archivo / ready, el contenedor no está en el estado Listo después de que se completa la creación, como se muestra a continuación. Tenga en cuenta que el valor de la columna READY es 0/1, lo que significa que el contenedor no está Listo.

# kubectl get po
NAME                     READY     STATUS    RESTARTS   AGE
nginx-7955fd7786-686hp   0/1       Running   0          7s
nginx-7955fd7786-9tgwq   0/1       Running   0          7s
nginx-7955fd7786-bqsbj   0/1       Running   0          7s

Crear servicio.

apiVersion: v1
kind: Service
metadata:
  name: nginx        
spec:
  selector:          
    app: nginx
  ports:
  - name: service0
    targetPort: 80   
    port: 8080       
    protocol: TCP    
  type: ClusterIP

Mirando el Servicio, se encuentra que el valor de la línea de Endpoints está vacío, lo que indica que no hay Endpoints.

$ kubectl describe svc nginx
Name:              nginx
......
Endpoints:         
......

Si crea un archivo / ready en el contenedor en este momento y deja que Readiness Probe tenga éxito, el contenedor estará en el estado Listo. Al revisar el Pod y los Endpoints nuevamente, encontré que el contenedor donde se creó el archivo / ready está Listo y se han agregado los Endpoints.

# kubectl exec nginx-7955fd7786-686hp -- touch /ready

# kubectl get po -o wide
NAME                     READY     STATUS    RESTARTS   AGE       IP
nginx-7955fd7786-686hp   1/1       Running   0          10m       192.168.93.169 
nginx-7955fd7786-9tgwq   0/1       Running   0          10m       192.168.166.130
nginx-7955fd7786-bqsbj   0/1       Running   0          10m       192.168.252.160

# kubectl get endpoints
NAME       ENDPOINTS           AGE
nginx      192.168.93.169:80   14d

HTTP GET

La configuración de la sonda de preparación es la misma que la sonda de vida. Está en los contenedores de la plantilla de pod. Como se muestra a continuación, esta sonda de preparación envía una solicitud HTTP al pod. Cuando la sonda recibe 2xx o 3xx, significa que el pod está listo. .

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:           # readinessProbe
          httpGet:                # HTTP GET定义
            path: /read
            port: 80
      imagePullSecrets:
      - name: default-secret

Conector TCP

De manera similar, la sonda de tipo TCP Socket se muestra a continuación.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:alpine
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        readinessProbe:             # readinessProbe
          tcpSocket:                # TCP Socket定义
            port: 80
      imagePullSecrets:
      - name: default-secret

Configuración avanzada de Readiness Probe

Al igual que Liveness Probe, Readiness Probe también tiene las mismas opciones de configuración avanzada. El comando describe del nginx Pod anterior tiene la siguiente línea en el eco.

Readiness: exec [ls /var/ready] delay=0s timeout=1s period=10s #success=1 #failure=3

Esta línea representa la configuración de parámetros específicos de Readiness Probe, y su significado es el siguiente:

delay = 0s significa que la detección comienza inmediatamente después de que se inicia el contenedor, no hay tiempo de retraso
timeout = 1s significa que el contenedor debe dar la retroalimentación correspondiente a la sonda dentro de 1s; de lo contrario, se considerará una falla de detección
period = 10s significa detectar una vez cada 10s
# éxito = 1 significa que la detección es exitosa por 1 vez consecutiva, lo que indica éxito
# failure = 3 significa que el contenedor se reiniciará después de que la sonda falle tres veces seguidas.
Estos son los valores predeterminados cuando se crean, y también puede configurarlos manualmente, como se muestra a continuación.

        readinessProbe:      # Readiness Probe
          exec:              # 定义 ls /readiness/ready 命令
            command:
            - ls
            - /readiness/ready
          initialDelaySeconds: 10    # 容器启动后多久开始探测
          timeoutSeconds: 2          # 表示容器必须在2s内做出相应反馈给probe，否则视为探测失败
          periodSeconds: 30          # 探测周期，每30s探测一次
          successThreshold: 1        # 连续探测1次成功表示成功
          failureThreshold: 3        # 连续探测3次失败表示失败