Questo articolo si concentra sulle sonde di avvio. Il ruolo della sonda di avvio può precludere altre sonde in sequenza. È essenziale utilizzare inoltre le sonde di avvio insieme alle sonde di Lività e prontezza. Il carico di lavoro non può essere modificato dalla sonda di avvio da solo. In questo articolo, esaminerai come Kubernetes valuta lo stato di salute dell'applicazione attraverso le sonde di avvio e configura i controlli sanitari utilizzando le sonde di avvio.
Cosa sono le sonde Kubernetes?
Le sonde sono anche chiamate controlli sanitari che sono la tecnica per le applicazioni Kubernetes per fornire il monitoraggio dello stato interno dell'applicazione utilizzando le informazioni. Lasciano che il tuo cluster identifichi i baccelli in esecuzione (contenitori) che monitorano la salute di un'applicazione e si assicurano che solo i pod sani servino il traffico.
Le applicazioni possono diventare inaffidabili per una serie di motivi come perdita di connessione temporanea, errori di configurazione ed errori dell'applicazione. Gli sviluppatori monitorano la salute delle loro applicazioni utilizzando le sonde. Le sonde aiutano gli sviluppatori a conoscere lo stato dell'applicazione, l'utilizzo delle risorse e i bug. È facile risolvere i problemi dell'applicazione, la gestione delle risorse e l'organizzazione delle risorse in modo efficace monitorando le informazioni sull'applicazione.
Le sonde vengono utilizzate per rilevare quanto segue:
Quali sono i tipi di sonde Kubernetes?
Esistono tre tipi di sonde Kubernetes. Questi includono:
Sonde di vita
È responsabile riavviare il contenitore se rileva uno stallo e non risponde.
Sonde di prontezza
È considerato un custode della porta per il traffico in arrivo. Questa sonda è responsabile di dire che questo pod è pronto a ricevere il traffico.
Sonde di avvio
È responsabile dell'applicazione che viene distribuita all'interno del contenitore. Indica se l'applicazione è iniziata correttamente.
Cos'è una sonda di avvio?
Kubernetes può determinare se il software, che esegue all'interno di un contenitore all'interno di un pod, ha iniziato correttamente utilizzando le sonde di avvio.
Come puoi vedere nella figura seguente, l'applicazione all'interno del pod Punti chiave delle sonde di avvio Prerequisiti di creare la sonda di avvio Prima di lavorare con la sonda di avvio, i prerequisiti sono un cluster Kubernetes con due nodi che non agiscono come host e software di riga di comando kubectl che devono essere configurati per comunicare tra cluster. Se non hai creato un cluster, puoi utilizzare il minikube per creare un cluster. Ci sono altre opzioni di Kubernetes Playground che sono disponibili online che puoi utilizzare per creare un cluster. Esistono quattro tecniche di base Kubernetes supportate dalle sonde di avvio: Exec: Esegue un comando all'interno del contenitore. Il codice zero indica il successo e gli altri codici indicano un errore. Http: Controlla la salute dell'applicazione utilizzando il comando Get Request. La sonda HTTP è considerata sana se la sua risposta è nell'intervallo di [200-399]. Se l'applicazione non supporta un server HTTP, crea il tuo server HTTP all'interno dell'applicazione e rispondi alla sonda Lives. TCP: Kubernetes apre la connessione tra una porta TCP specifica e un contenitore. Se la connessione ha esito positivo, accetta il traffico. Altrimenti, non riesce a creare una connessione. La porta TCP funziona per conto delle sonde HTTP quando la sonda HTTP non è in grado di funzionare. GRPC: Determina se la sonda ha esito positivo inviando una richiesta di controllo sanitaria GRPC a una porta all'interno del contenitore e utilizzando la risposta. Il criterio di successo per la sonda e la frequenza con cui viene verificata è controllata da alcune variabili fondamentali: InizialDelaysEconds: Specifica la quantità di tempo che deve passare tra il tempo in cui il contenitore inizia e la prima volta che viene utilizzata la sonda (predefinita: 0, minimo: 0). periodi: Definisce la frequenza con cui la sonda viene controllata dopo il ritardo iniziale (impostazione predefinita: 10, minimo: 1). Timeoutheseconds: Indica quanto tempo attendere il completamento della sonda ed essere contrassegnato come fallito dopo aver superato il tempo (impostazione predefinita: 1, minimo: 1). failurethreshold: Kubernetes richiede che il fallimento minimo successivo per la sonda sia considerato malsano se ci sia successo. Il contenitore viene riavviato solo quando le ripetizioni sono malsane (predefinito: 3, minimo: 1). Come creare una sonda di avvio Le sonde di avvio vengono fatte aggiungendo una disciplina startupprobe all'interno delle specifiche.Contenitori parte del distinto di un pod. L'approccio Exec viene utilizzato nell'esempio semplice della sonda di avvio che viene mostrato nel seguente in cui il comando viene eseguito all'interno del contenitore: Utilizzando Kubectl, aggiungi il baccello al cluster con il seguente comando: Come proteggere i contenitori di partenza lenti con sonde di avvio? Attraverso la seguente formula, puoi trovare abbastanza a lungo da coprire il tempo di avvio peggiore: Conclusione La lizza, la prontezza e le sonde di avvio per i tuoi contenitori distribuiti in contenitori Kubernetes devono essere configurati in modo appropriato se si desidera mantenere un cluster sano Kubernetes. Questo post si è concentrato sulla sonda di avvio, il che è cruciale poiché consente ai tuoi contenitori di avvisare i kubernetes quando si avviano e sono pronti a essere valutati per la vita e la prontezza. È bene aggiungere una sonda di avvio quando si utilizzano sondaggi di vivacità e prontezza. Altrimenti, il contenitore può essere riavviato prima di finire l'inizializzazione. Questo articolo implementa l'impostazione di configurazione di base della sonda di avvio e descrive i parametri che possono essere utilizzati dalle sonde.
Path:/Healthz è l'endpoint sanitario di Applicexample-Startup-probation. Il failurethreshold: 12 è il tentativo di Kubernetes nel caso in cui la sonda fallisca. I periodi: 12 è la frequenza con cui viene condotta l'ispezione.> kubectl appliche -f startup-drobe-example.YML
Il contenitore inizia e funziona normalmente. È possibile convalidare questo con i suoi dettagli che vengono visualizzati in Kubectl:> FailurethReshold * periodi
Il tempo di inizio massimo per l'applicazione è di 3 minuti (20 * 10 = 200). Una volta che la sonda startup ha successo per la prima volta, la sonda di lizza procede per offrire una risposta rapida ai deadlock del contenitore. Il contenitore viene interrotto dopo 200 secondi ed è soggetto al RestartPolicy del pod se la sonda di avvio non ha mai successo.