Come posso risolvere i problemi relativi ai probe di attività e idoneità nei miei cluster Amazon EKS?

Breve descrizione

I kubelet in esecuzione sui nodi worker utilizzano i probe per controllare periodicamente lo stato del pod. Kubernetes attualmente supporta tre stati nei probe: successo, fallimento e sconosciuto. Kubelet considera il pod funzionante o integro nelle seguenti condizioni:

• L'applicazione in esecuzione all'interno del container è pronta.
• L'applicazione accetta il traffico e risponde ai probe definiti nel manifesto del pod.

Kubelet considera un pod dell'applicazione come non riuscito o non integro quando il probe non risponde. Kubelet quindi contrassegna questo pod come non integro e gli invia il segnale SIGTERM Si verifica una delle seguenti situazioni in base alla policy del ciclo di vita e alla restartPolicy definite nella distribuzione:

• Il pod viene terminato immediatamente.
• Il pod viene spento normalmente dopo aver smesso di accettare il traffico.

Esempio:

spec:
 containers:
 - name: "example-container"
  image: "example-image"
  lifecycle:
   preStop:
    exec:
     command: ["sh", "-c", "sleep 10"]

In questo esempio, se example-container che viene eseguito all'interno di example-pod diventa non integro non rispondendo ai probe, allora il pod smette di accettare traffico in 10 secondi. Quindi, kubelet spegne il pod normalmente. Se il pod non viene terminato nemmeno dopo 30 secondi, kubelet lo rimuove forzatamente. Kubelet considera il pod dell'applicazione come sconosciuto quando non è in grado di determinarne lo stato utilizzando i probe definiti nel manifesto di distribuzione. In questo caso, kubelet esegue controlli aggiuntivi per determinare lo stato del pod.

Kubernetes fornisce controlli sui probe di attività, di idoneità e di avvio.

• Kubelet utilizza i probe di attività per conoscere lo stato dell'applicazione in esecuzione all'interno del pod.
• Kubelet utilizza i probe di idoneità per sapere quando l'applicazione è pronta per iniziare a servire il traffico in entrata.
• Kubelet utilizza i probe di avvio per le applicazioni che si avviano lentamente all'interno del pod. Quando viene configurato un probe di avvio, i probe di attività e idoneità non controllano il pod fino a quando l'avvio non viene considerato riuscito.

Se nessuno di questi probe è definito sul manifesto del pod, kubelet contrassegna i pod come funzionanti o integri a tempo indeterminato. È possibile configurare uno dei seguenti probe per verificare l'integrità del pod:

• Probe HTTP
• Probe di comando
• Probe socket TCP
• Probe gRPC

Risoluzione

Errori nel controllo dello stato dell'applicazione dovuti ai timeout del client

Quando i probe di attività e idoneità falliscono, vengono visualizzati i seguenti messaggi di errore:

Liveness probe failed: Get "http://podIP:8080/health ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Readiness probe failed: Get "http://podIP:8080/health ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Per risolvere questi errori, completa le seguenti operazioni:

Controlla se hai configurato correttamente i probe di attività e idoneità per i pod dell'applicazione.

Se utilizzi Amazon Virtual Private Cloud (Amazon VPC) CNI versione 1.11.0 o successiva, assicurati che POD_SECURITY_GROUP_ENFORCING_MODE sia impostato su standard in aws-node DaemonSet. Se questa impostazione non è corretta, esegui il seguente comando:

kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard

Assicurati di impostare DISABLE_TCP_EARLY_DEMUX su true per amazon-k8s-cni-init che è il container in initcontainers quando si verificano le seguenti condizioni:

• Stai utilizzando una versione CNI di Amazon VPC precedente alla versione 1.11.0.
• I tuoi pod sono configurati con gruppi di sicurezza.
• ENABLE_POD_ENI è impostato su true (vero).

kubectl patch daemonset aws-node -n kube-system \
-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'

Errori CNI di Amazon VPC

Il tuo aws-node DaemonSet potrebbe fallire per via dei seguenti errori:

Liveness probe failed: OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: read init-p: connection reset by peer: unknown
Warning  Unhealthy  11m (x3 over 12m)    kubelet            Liveness probe failed:
Normal   Killing    11m                  kubelet            Container aws-node failed liveness probe, will be restarted

Readiness probe failed: OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: process_linux.go:99: starting setns process caused: fork/exec /proc/self/exe: resource temporarily unavailable: unknown
Warning  Unhealthy  11m (x9 over 13m)    kubelet            Readiness probe failed:

È possibile risolvere questi errori aumentando il valore di timeoutSeconds a 60 secondi su aws-node DaemonSet.

Per visualizzare i valori correnti dei campi nel CNI di Amazon VPC, esegui il seguente comando:

$kubectl get daemonset aws-node -n kube-system -o yaml

Dovresti visualizzare un output simile al seguente:

"livenessProbe":
          exec:
            command:
            - /app/grpc-health-probe
            -addr=:50051
            -connect-timeout=5s
            -rpc-timeout=5s
          failureThreshold: 3
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 60

Errori di connessione dell'applicazione

Quando si esegue il comando describe sui pod dell'applicazione personalizzata, si ottengono i seguenti errori se i pod non superano i controlli dei probe di attività e idoneità:

2m 25s Warning  Unhealthy  Liveness probe failed: Get "http://podIP:8081/health ": dial tcp 192.168.187.28: 8081: connect: connection refused

2m 25s Warning  Unhealthy   Readiness probe failed: Get "http:// podIP:8081/health": dial tcp 192.168.187.28:8081: connect: connection refused

Warning  Unhealthy  39s (x4 over 2m19s)  kubelet            Liveness probe failed: HTTP probe failed with statuscode: 500

Warning  Unhealthy  29s (x5 over 2m19s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 500

Per risolvere questo errore, procedi come segue:

1.    Esegui manualmente il curl del percorso di controllo dell'integrità definito nel manifesto del pod dal nodo worker.

[ec2-user@ip-10-0-0-11 ~]$ curl -ikv podIP:8081/health

2.    Esegui l'accesso al pod dell'applicazione che non supera i probe di attività o idoneità. Quindi, esegui il curling del percorso di controllo dell'integrità definito nel manifesto del pod:

local@bastion-host ~ % kubectl exec <pod-name> -- curl  -ikv "http://localhost:8081/_cluster/health?"

3.    Controlla i log kubelet del nodo worker in cui è in esecuzione il pod per rilevare eventuali errori:

[ec2-user@ip-10-0-0-11 ~]$ journalctl -u kubelet //optionally 'grep' with pod name

4.    Esegui il comando describe pod sul pod e controlla lo stato corrente dei container in esecuzione nel pod. Inoltre, controlla i log del pod:

$ kubectl describe pod <pod name> -n <namespace>

$ kubectl logs <pod name>

5.    Se ancora non disponi di informazioni sull'errore, valuta la possibilità di aumentare il livello di dettaglio del kubelet sottostante in esecuzione sul nodo worker:

$ sudo systemctl status kubelet
$ vi /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf 
   [Service]
   Environment='KUBELET_ARGS=--node-ip=192.168.31.211 --pod-infra-container-image=602401143452.dkr.ecr.us-east-2.amazonaws.com/eks/pause:3.5 --v=2'

Nel file di configurazione, modifica --v=2 in --v=9, quindi salva il file.

Riavvia il kubelet per rendere effettive le modifiche:

$ sudo systemctl daemon-reload && sudo systemctl restart kubelet && sudo systemctl enable kubelet

Esegui il seguente comando per verificare il livello di dettaglio del kubelet:

$ systemctl status kubelet -l

L'output deve essere simile al seguente:

CGroup: /system.slice/kubelet.service 
       └─5909 /usr/bin/kubelet --cloud-provider aws --config /etc/kubernetes/kubelet/kubelet-config.json --kubeconfig /var/lib/kubelet/kubeconfig --container-runtime docker --network-plugin cni --node-ip=10.0.0.11 --pod-infra-container-image=602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/pause:3.1-eksbuild.1 --v=9

Riavvia il pod che non supera i controlli di attività o idoneità. Quindi, assicurati che questo pod venga distribuito sul nodo worker Amazon EKS in cui sono state apportate le modifiche precedenti. Puoi controllare i log kubelet eseguendo il seguente comando:

$ journalctl -u kubelet //optionally 'grep' with pod name

6.    Esegui la stessa immagine del container sull'host bastione e verifica se puoi eseguire il curling del percorso di controllo dell'integrità definito nei probe nel manifesto. Inoltre, controlla i log del container.

7.    Per i probe HTTP, controlla se l'intestazione http personalizzata è configurata correttamente. Kubelet usa il codice golang che equivale a curl per il test HTTP sul tuo pod.

Esempio:

"livenessProbe":
   httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

8.    Se stai usando un probe exec, controlla se il tuo pod è configurato correttamente. Nell'esempio seguente, il pod passa per 30 secondi e poi fallisce:

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:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

---