Kubernetes en control de salud de la vaina

1. ¿Qué es un chequeo de salud

arquitectura Kubernetes, cada nodo tendrá un kubeletchequeo de salud contenedor (Container Probe) tarea es una Kubeletejecución periódica.

Kubelet Pod llamando al recipiente Handlerpara llevar a cabo la operación de inspección, Handlerexisten los siguientes tres tipos:

• ExecAction: ejecutar comandos específicos en un recipiente, salidas de comandos con 0 (valor de retorno de comandos :? $) Indica el éxito
• TCPSocketAction: una dirección IP TCP y comprobar el recipiente de acuerdo con un puerto específico, el acceso al puerto / / abierta expuesta para el éxito
• HTTPGetAction: HTTP petición de iniciar un recipiente según IP, puertos y caminos de acceso, devolver un código de estado que indica el éxito si se encuentra entre 200-400

Cada acciones de inspección son propensos a tener tres tipos de estados de retorno:

• Éxito: representado por el control de estado
• Fallo: que no hay controles de salud
• Desconocido: Hora de la acción representa un fracaso

2, la clasificación sonda

Cuando se crea una vaina, por livenessy readinessoperación de dos maneras para detectar el contenido de la vaina.

2,1, sonda LivenessProbe (viabilidad sonda)

Determinación de si la salud del contenedor (estado de funcionamiento) y de nuevo alimentado a Kubelet. De hecho, hay muchas aplicaciones durante mucho tiempo poco a poco en el fondo después de ejecutar un estado inutilizable, y sólo se pueden restaurar mediante el reinicio de la operación de la vaina, el 存活性mecanismo de la sonda se puede encontrar en este tipo de cuestiones, combinada con la estrategia de reinicio en base al resultado de la detección para activar la ejecución subsiguiente .

kubernetes viabilidad soporte de la sonda de detección en tres: ExecAction, TCPSocketAction y HTTPGetAction

Si un recipiente no es LivenessProbe sonda, entonces kubelet pensarán sonda LivenessProbe del valor de retorno de contenedores será siempre el éxito.

2,2, sonda ReadinessProbe (sonda-ready)

servicio de contenedores juez está disponible (estado Listo) puede proporcionar servicios sólo alcanzados Pod listo para recibir estado de petición, cuando el buque corrió el negocio hasta el estado del contenedor está listo, cargo que la sonda de contenedor falla, si falla la sonda , el sistema de back-end lista Punto final de servicio quitar su IP Pod, seguimiento y luego volverá al estado lista, la sonda será su éxito Pod extremos IP vuelve a añadir a la lista.

3, la aplicación de la sonda

LivenessProbeY ReadinessProbepuede ser configurado para alcanzar el siguiente sonda de tres maneras:

ReadinessProbeConfiguración y LivenessProbede manera similar, simplemente YAML es livenessProberevisado parareadinessProbe

3.1 Recipiente Exec

Crear un contenedor, comprobando si existe un archivo para determinar si el funcionamiento normal del buque, si existe el archivo volverá código de estado de 0, 30 segundos después de la ejecución del vaso, se elimina el archivo, comprobación LivenessProbe no se reiniciará buque.

apiVersion: v1
kind: Pod
metadata:
  name: exec
spec:
  containers:
    - name: nginx
      image: nginx:1.13
      ports:
        - containerPort: 80
      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

Detecta no existe el directorio

[root@k8s-master01 health]# kubectl describe pod exec  |grep "Liveness"
    Liveness:       exec [cat /tmp/healthy] delay=5s timeout=1s period=5s #success=1 #failure=3
  Warning  Unhealthy  4s (x3 over 14s)  kubelet, k8s-node01  Liveness probe failed: cat: /tmp/healthy: No such file or directory

3.2, Registro de HTTP

Nginx crear un contenedor, accediendo /index.html para determinar si la supervivencia del servicio, eliminar el archivo manualmente, cheque puede conducir al fracaso, poniendo en funcionamiento nuevamente el contenedor

apiVersion: v1
kind: Pod
metadata:
  name: httpget
spec:
  containers:
    - name: nginx
      image: nginx:1.13
      ports:
        - containerPort: 80
      livenessProbe:
        httpGet:
          path: /index.html # 访问路径
          port: 80          # 容器端口
        initialDelaySeconds: 5
        periodSeconds: 5

Nginx archivo index.html quitar manualmente el contenedor

[root@k8s-master01 health]# kubectl exec -it httpget bash
root@httpget:/# mv /usr/share/nginx/html/index.html  /tmp/

Cuando se accede a index.html no devuelve un código de estado 200, el contenedor se reiniciará

[root@k8s-master01 health]# kubectl describe pod httpget |grep "Liveness"
    Liveness:       http-get http://:80/index.html delay=5s timeout=1s period=5s #success=1 #failure=3
  Warning  Unhealthy  59s (x3 over 69s)   kubelet, k8s-node01  Liveness probe failed: HTTP probe failed with statuscode: 404

3.3, Socket TCP Comprobar

A través de la dirección IP (dirección IP de destino solicita una conexión, el valor predeterminado es Pod IP) para realizar un número de control, el puerto TCP y, si se puede establecer una conexión TCP, y luego pensar en un recipiente sana, será más eficiente relación método de detección basado en HTTP (HTTP siete capa, TCP es de cuatro), más la conservación de los recursos, pero la exactitud de baja micro, se puede construir un exitoso no significa que la página se puede mostrar.

apiVersion: v1
kind: Pod
metadata:
  name: tcpSocket
spec:
  containers:
    - name: nginx
      image: nginx:1.13
      ports:
        - containerPort: 80
      livenessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 3
        periodSeconds: 3

4, el sondeo parámetros de comportamiento

initiaDelaySeconds // 容器启动之后多久开始检测，默认为0秒
periodSeconds      // 每隔多久检测一次，默认为10秒，最小为1秒
failureThreshold   // 检测失败几次后则认为健康检测失败，默认为3次
successThreshold   // 从检测错误到成功需要几次才认为健康检测成功，默认为1次
timeoutSeconds     // 执行检测命令的最长时间，默认为1秒，最小为1秒

httpGet的属性
		host：主机名或IP
		scheme：链接类型，HTTP或HTTPS，默认为HTTP
		path：请求路径
		httpHeaders：自定义请求头
		port：请求端口