diff --git a/content/it/docs/concepts/containers/container-lifecycle-hooks.md b/content/it/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000..59140ec333 --- /dev/null +++ b/content/it/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,128 @@ +--- +title: Container Lifecycle Hooks +content_type: concept +weight: 30 +--- + + +Questa pagina descrive come i Container gestiti con kubelet possono utilizzare il lifecycle +hook framework dei Container per l'esecuzione di codice eseguito in corrispondenza di alcuni +eventi durante il loro ciclo di vita. + + + +## Overview + +Analogamente a molti framework di linguaggi di programmazione che hanno degli hooks legati al ciclo di +vita dei componenti, come ad esempio Angular, Kubernetes fornisce ai Container degli hook legati al loro ciclo di +vita dei Container. +Gli hook consentono ai Container di essere consapevoli degli eventi durante il loro ciclo di +gestione ed eseguire del codice implementato in un handler quando il corrispondente hook viene +eseguito. + +## Container hooks + +Esistono due tipi di hook che vengono esposti ai Container: + +`PostStart` + +Questo hook viene eseguito successivamente alla creazione del container. +Tuttavia, non vi è garanzia che questo hook venga eseguito prima dell'ENTRYPOINT del container. +Non vengono passati parametri all'handler. + +`PreStop` + +Questo hook viene eseguito prima della terminazione di un container a causa di una richiesta API o +di un evento di gestione, come ad esempio un fallimento delle sonde di liveness/startup, preemption, +risorse contese e altro. Una chiamata all'hook di `PreStop` fallisce se il container è in stato +terminated o completed e l'hook deve finire prima che possa essere inviato il segnale di TERM per +fermare il container. Il conto alla rovescia per la terminazione del Pod (grace period) inizia prima dell'esecuzione +dell'hook `PreStop`, quindi indipendentemente dall'esito dell'handler, il container terminerà entro +il grace period impostato. Non vengono passati parametri all'handler. + +Una descrizione più dettagliata riguardante al processo di terminazione dei Pod può essere trovata in +[Terminazione dei Pod](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). + +### Implementazione degli hook handler + +I Container possono accedere a un hook implementando e registrando un handler per tale hook. +Ci sono due tipi di handler che possono essere implementati per i Container: + +* Exec - Esegue un comando specifico, tipo `pre-stop.sh`, all'interno dei cgroup e namespace del Container. +Le risorse consumate dal comando vengono contate sul Container. +* HTTP - Esegue una richiesta HTTP verso un endpoint specifico del Container. + +### Esecuzione dell'hook handler + +Quando viene richiamato l'hook legato al lifecycle del Container, il sistema di gestione di Kubernetes +esegue l'handler secondo l'azione dell'hook, `httpGet` e `tcpSocket` vengono eseguiti dal processo kubelet, +mentre `exec` è eseguito nel Container. + +Le chiamate agli handler degli hook sono sincrone rispetto al contesto del Pod che contiene il Container. +Questo significa che per un hook `PostStart`, l'ENTRYPOINT e l'hook si attivano in modo asincrono. +Tuttavia, se l'hook impiega troppo tempo per essere eseguito o si blocca, il container non può raggiungere lo +stato di `running`. + +Gli hook di `PreStop` non vengono eseguiti in modo asincrono dall'evento di stop del container; l'hook +deve completare la sua esecuzione prima che l'evento TERM possa essere inviato. Se un hook di `PreStop` +si blocca durante la sua esecuzione, la fase del Pod rimarrà `Terminating` finchè il Pod non sarà rimosso forzatamente +dopo la scadenza del suo `terminationGracePeriodSeconds`. Questo grace period si applica al tempo totale +necessario per effettuare sia l'esecuzione dell'hook di `PreStop` che per l'arresto normale del container. +Se, per esempio, il `terminationGracePeriodSeconds` è di 60, e l'hook impiega 55 secondi per essere completato, +e il container impiega 10 secondi per fermarsi normalmente dopo aver ricevuto il segnale, allora il container +verrà terminato prima di poter completare il suo arresto, poiché `terminationGracePeriodSeconds` è inferiore al tempo +totale (55+10) necessario perché queste due cose accadano. + +Se un hook `PostStart` o `PreStop` fallisce, allora il container viene terminato. + +Gli utenti dovrebbero mantenere i loro handler degli hook i più leggeri possibili. +Ci sono casi, tuttavia, in cui i comandi di lunga durata hanno senso, +come il salvataggio dello stato del container prima della sua fine. + +### Garanzia della chiamata dell'hook + +La chiamata degli hook avviene *almeno una volta*, il che significa +che un hook può essere chiamato più volte da un dato evento, come per `PostStart` +o `PreStop`. +Sta all'implementazione dell'hook gestire correttamente questo aspetto. + +Generalmente, vengono effettuate singole chiamate agli hook. +Se, per esempio, la destinazione di hook HTTP non è momentaneamente in grado di ricevere traffico, +non c'è alcun tentativo di re invio. +In alcuni rari casi, tuttavia, può verificarsi una doppia chiamata. +Per esempio, se un kubelet si riavvia nel mentre dell'invio di un hook, questo potrebbe essere +chiamato per una seconda volta dopo che il kubelet è tornato in funzione. + +### Debugging Hook handlers + +I log di un handler di hook non sono esposti negli eventi del Pod. +Se un handler fallisce per qualche ragione, trasmette un evento. +Per il `PostStart`, questo è l'evento di `FailedPostStartHook`, +e per il `PreStop`, questo è l'evento di `FailedPreStopHook`. +Puoi vedere questi eventi eseguendo `kubectl describe pod `. +Ecco alcuni esempi di output di eventi dall'esecuzione di questo comando: + +``` +Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 + 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 + 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 + 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" + 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook +``` + + + +## {{% heading "whatsnext" %}} + + +* Approfondisci [Container environment](/docs/concepts/containers/container-environment/). +* Esegui un tutorial su come + [definire degli handlers per i Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). +