Nota di traduzione.: L'autore dell'articolo originale è Théo Chamley, architetto delle soluzioni cloud di Google. In questa pubblicazione per il blog di Google Cloud, ha presentato un breve riassunto di una guida più dettagliata della sua azienda intitolata «». In essa, gli esperti di Google hanno raccolto le migliori pratiche per la gestione dei container nel contesto dell'utilizzo di Google Kubernetes Engine e non solo, affrontando un'ampia gamma di argomenti: dalla sicurezza al monitoraggio e alla registrazione. Quindi, quali pratiche nella gestione dei container sono considerate le più importanti secondo Google?

(servizio basato su Kubernetes per eseguire applicazioni containerizzate in Google Cloud — Nota di traduzione.) — è uno dei migliori modi per eseguire carichi di lavoro che necessitano di scalabilità. Assicurerà il funzionamento impeccabile della maggior parte delle applicazioni, a condizione che siano containerizzate. Ma se desideri che l'applicazione sia facile da gestire e vuoi sfruttare tutti i vantaggi di Kubernetes, è necessario seguire le migliori pratiche. Queste semplificheranno la gestione dell'applicazione, il suo monitoraggio e il debug, aumentando anche la sicurezza.
In questo articolo esamineremo un elenco di ciò che è importante sapere e fare per il funzionamento efficace dei container in Kubernetes. Chi desidera approfondire i dettagli dovrebbe leggere il materiale , e prestare attenzione al nostro sulla build dei container.
1. Utilizza i meccanismi nativi dei container per la registrazione
Se l'applicazione è eseguita in un cluster Kubernetes, non è necessario molto per i log. Un sistema di registrazione centralizzato è probabilmente già integrato nel cluster che stai utilizzando. Nel caso di Kubernetes Engine, ciò è gestito da . (Nota di traduzione.: Nel caso di un'installazione propria di Kubernetes, ti consigliamo di dare un'occhiata alla nostra soluzione open source — .) Non complicarti la vita e utilizza i meccanismi di registrazione nativi dei container. Scrivi i log in stdout e stderr: verranno automaticamente acquisiti, salvati e indicizzati.
Se lo desideri, è possibile scrivere i log anche in . Questo approccio permetterà di aggiungere facilmente metadati. E insieme a questi, in Stackdriver Logging ci sarà la possibilità di cercare nei log utilizzando questi metadati.
2. Assicurati che i container siano stateless e immutable
Per un corretto funzionamento dei contenitori nel cluster Kubernetes, devono essere stateless e immutabili. Quando queste condizioni sono soddisfatte, Kubernetes sarà in grado di svolgere il proprio lavoro, creando e distruggendo entità dell'applicazione quando e dove necessario.
Stateless significa che qualsiasi stato (dati persistenti di qualsiasi tipo) viene memorizzato al di fuori del contenitore. A tal fine, a seconda delle esigenze, possono essere utilizzati diversi tipi di archiviazione esterna: , , , o altre basi di dati gestite. (Nota di traduzione.: Maggiori dettagli sono disponibili anche nel nostro articolo "».)
Immutable significa che il contenitore non sarà modificato durante la sua vita: nessun aggiornamento, patch o modifiche alla configurazione. Se è necessario aggiornare il codice dell'applicazione o applicare una patch, creare una nuova immagine e distribuire. Si consiglia di estrarre la configurazione del contenitore (porta di ascolto, opzioni dell'ambiente di esecuzione, ecc.) all'esterno — in e . Questi possono essere aggiornati senza dover ricostruire la nuova immagine del contenitore. Per una semplice creazione di pipeline con la costruzione di immagini, è possibile utilizzare . (Nota di traduzione.: Per questo scopo utilizziamo uno strumento Open Source chiamato .)

Esempio di aggiornamento della configurazione del Deployment in Kubernetes utilizzando ConfigMap, montato nei pod come configurazione
3. Evitare i contenitori privilegiati
Non esegui certamente applicazioni come root sui tuoi server, giusto? Se un malintenzionato dovesse penetrare nell'applicazione, otterrebbe accesso con diritti di root. Le stesse considerazioni sono valide per evitare di eseguire contenitori privilegiati. Se è necessario modificare le impostazioni sull'host, è possibile concedere al contenitore specifici capabilities utilizzando l'opzione in Kubernetes. Se è necessario modificare sysctls, Kubernetes ha per questo. In generale, cerca di utilizzare il più possibile e contenitori sidecar per eseguire tali operazioni privilegiate. Non hanno bisogno di essere accessibili né per il traffico interno né per quello esterno.
Se gestisci un cluster, puoi utilizzare per le limitazioni nell'applicazione di contenitori privilegiati.
4. Evitare l'esecuzione come root
È già stato detto sui contenitori privilegiati, ma sarebbe ancora meglio se in aggiunta a questo non eseguissi applicazioni all'interno del contenitore come root. Se un aggressore trova una vulnerabilità remota nell'applicazione con diritti root che consente di eseguire codice, può poi uscire dai limiti del contenitore attraverso una vulnerabilità ancora sconosciuta, ottenendo così i diritti di root sull'host.
Il modo migliore per evitarlo è, prima di tutto, non eseguire nulla come root. A tal fine, puoi utilizzare la direttiva UTENTE in Dockerfile o runAsUser in Kubernetes. L'amministratore del cluster può anche impostare un comportamento forzato usando .
5. Rendi l'applicazione facile da monitorare
Come il logging, il monitoraggio è una parte essenziale della gestione dell'applicazione. Una soluzione popolare per il monitoraggio nella comunità di Kubernetes è — un sistema che rileva automaticamente i pod e i servizi che necessitano di monitoraggio. (Nota di traduzione.: Vedi anche il nostro sul monitoraggio con Prometheus e Kubernetes.) può monitorare i cluster Kubernetes e include la sua versione di Prometheus per il monitoraggio delle applicazioni.

La dashboard di monitoraggio di Kubernetes in Stackdriver
Prometheus si aspetta che l'applicazione esponga metriche su un endpoint HTTP. A questo scopo sono disponibili . Lo stesso formato è utilizzato anche da altri strumenti come e .
6. Rendi disponibile lo stato di salute dell'applicazione
La capacità di un'applicazione di comunicare il proprio stato all'intero sistema aiuta nella gestione dell'applicazione in produzione. L'applicazione è in esecuzione? È in ordine? È pronta a ricevere traffico? Come si comporta? Il modo più comune per affrontare questo problema è implementare controlli di salute (health checks). Kubernetes ha due tipi di controlli di salute: .
Per il liveness probe (controllo di vitalità) l'applicazione deve avere un endpoint HTTP che restituisca una risposta "200 OK" se sta funzionando e le sue dipendenze principali sono soddisfatte. Per il readiness probe (controllo di prontezza) l'applicazione deve avere un altro endpoint HTTP che restituisca una risposta «200 OK» se l'applicazione è in buona salute, i passaggi di inizializzazione sono stati completati e qualsiasi richiesta valida non causa errori. Kubernetes indirizzerà il traffico al contenitore solo se l'applicazione è pronta in base a questi controlli. I due endpoint possono essere uniti se non c'è differenza tra gli stati di vitalità (liveness) e di prontezza (readiness).
Per ulteriori dettagli, puoi leggere l'articolo corrispondente di Sandeep Dinesh, Developer Advocate di Google: «».
7. Scegli con attenzione la versione dell'immagine
La maggior parte delle immagini pubbliche e private utilizza un sistema di tagging simile a quello descritto in . Se l'immagine utilizza un sistema simile a , è necessario considerare le specificità del tagging. Ad esempio, il tag latest può spesso spostarsi da un'immagine all'altra: non si può fare affidamento su di esso se hai bisogno di build e installazioni prevedibili e riproducibili.
Puoi utilizzare il tag X.Y.Z (sono quasi sempre invariabili), ma in tal caso segui tutti i patch e aggiornamenti per l'immagine. Se l'immagine utilizzata ha un tag X.Y, è una buona opzione intermedia. Scegliendolo, ottieni automaticamente i patch e allo stesso tempo ti basi su una versione stabile dell'applicazione.
P.S. dal traduttore
Leggi anche nel nostro blog:
- «»;
- «»;
- «»;
- «» (panoramica e video del relatori);
- «» (panoramica e video del relatori);
- «» (panoramica e video del relatori);
- «» (panoramica e video del relatori);
- «».
Fonte: habr.com
