GCE: controllo di salute e prova di Liveness

Quando si crea il pool di destinazione per il bilanciamento del carico di networking, esiste un'opzione di health check .

immettere qui la descrizione dell'immagine

Inoltre c'è una properties; denominata livenessProbe nella livenessProbe del contenitore .

Una sonda di controllo controlla se il contenitore in cui è configurato è ancora in esecuzione. Se la sonda di liveness non riesce, il kubelet uccide il contenitore, che sarà sottoposto alla sua politica di riavvio. Impostare un controllo di liveness configurando la stanza template.spec.containers.livenessprobe di una configuration del pod.

Il controllo di salute è inutile quando il contenitore è configurato con livenessProbe ?

Come capisco, se il contenitore è in discesa, POD verrà riavviato automaticamente. In questo caso, non c'è bisogno di un controllo di salute.

Cosa succede al NODE? Come ho capito, i kubernetes inizieranno il POD in un altro NODE, il che significa che il POD verrà riavviato di nuovo.

Mi sembra, in each caso, che il controllo della salute sia inutile quando livenessProbe è configurato.

  • kubernetes kube-proxy iptables errori
  • Come funziona nodeAffinity in DaemonSets?
  • Servizio Kubernetes esternamente visibile su Azure
  • Kubernetes bloccato su ContainerCreating
  • Arresto grazioso del cluster Kubernetes
  • Come posso triggersre l'HSTS sul Google Load Balancer predefinito che viene fornito con Google Container Engine?
  • Collegamento GKE pod tramite VPN?
  • Come faccio a sapere quando / se / perché un contenitore in un cluster di kubernetes riavvia?
  • One Solution collect form web for “GCE: controllo di salute e prova di Liveness”

    I controlli sanitari per il bilanciatore del carico e per Kubernetes sono separati e probabilmente dovresti avere entrambi.

    I controlli di salute del bilanciatore del carico sono per il bilanciatore del carico di sapere che un particolare back-end VM può servire traffico. Funziona su un livello di VM del motore di calcolo e contrassegna VM specifici come sani o malsani. Quindi, se un nodo scende, non saprà dirigere il traffico in quel particolare nodo. È per il traffico prima di colpire il cluster Kubernetes. Le sonde di vivacità non ti aiuteranno in caso di un nodo che scompare perché funziona solo per il traffico che ha fatto al cluster. Kubernetes può gestire solo il traffico che può vedere.

    Una volta che il traffico lo ha fatto nel cluster Kubernetes dirigerà il traffico ai contenitori le cose sono sane. Se non esiste un controllo di salute, saranno contenitori in stato di esecuzione. Anche se il contenitore potrebbe essere in esecuzione, potrebbe non essere ancora pronto per il traffico. Le sonde di vivacità danno a Kubernetes un modo per sapere i contenitori sono pronti e pronti a servire il traffico.

    Schema di rete

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.