{"id":39016,"date":"2019-10-31T22:27:21","date_gmt":"2019-10-31T19:27:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google\/"},"modified":"2019-10-31T22:27:21","modified_gmt":"2019-10-31T19:27:21","slug":"7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","title":{"rendered":"7 migliori pratiche per la gestione dei container secondo Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota del traduttore.<\/b>: L'autore dell'articolo originale \u00e8 Th\u00e9o Chamley, architetto di soluzioni cloud di Google. In questo post del blog di Google Cloud ha presentato un breve riassunto di una guida pi\u00f9 dettagliata della sua azienda, intitolata \u00abBest Practices for Operating Containers<\/a><\/noindex>\u00bb. In essa gli esperti di Google hanno raccolto le migliori pratiche per l'operativit\u00e0 dei container nel contesto dell'uso di Google Kubernetes Engine e non solo, affrontando un'ampia gamma di argomenti: dalla sicurezza al monitoraggio e alla registrazione. Quindi, quali pratiche riguardanti i container sono pi\u00f9 importanti secondo Google?<\/i><\/p>\n

\"7<\/a><\/noindex><\/p>\n

Kubernetes Engine<\/a><\/noindex> (un servizio basato su Kubernetes per eseguire applicazioni containerizzate su Google Cloud \u2014 nota del traduttore.<\/b>)<\/i> \u2014 \u00e8 uno dei migliori modi per eseguire carichi di lavoro che necessitano di scalabilit\u00e0. Kubernetes<\/a><\/noindex> garantir\u00e0 il corretto funzionamento della maggior parte delle applicazioni, se sono containerizzate. Ma se si desidera che l'applicazione sia facilmente gestibile e si vogliono sfruttare tutti i vantaggi di Kubernetes, \u00e8 necessario seguire le migliori pratiche. Queste semplificheranno l'operativit\u00e0 dell'applicazione, il suo monitoraggio e debug, e miglioreranno anche la sicurezza.<\/p>\n

In questo articolo esamineremo l'elenco delle cose da sapere e fare per un funzionamento efficace dei container in Kubernetes. Chi desidera approfondire i dettagli dovrebbe leggere il materiale Best Practices for Operating Containers<\/a><\/noindex>, e fare attenzione al nostro post precedente<\/a><\/noindex> sulla creazione dei container.<\/p>\n

1. Utilizza i meccanismi nativi dei container per il logging<\/h2>\n

\nSe l'applicazione \u00e8 in esecuzione in un cluster Kubernetes, non \u00e8 necessario molto per i log. \u00c8 probabile che un sistema di logging centralizzato sia gi\u00e0 integrato nel cluster utilizzato. Nel caso di utilizzo di Kubernetes Engine, questo \u00e8 gestito da Stackdriver Logging<\/a><\/noindex>. (Nota del traduttore.<\/b>: Se stai utilizzando un'installazione autonoma di Kubernetes, ti consigliamo di dare un'occhiata alla nostra soluzione Open Source \u2014 loghouse<\/a><\/noindex>.)<\/i> Non complicarti la vita e utilizza i meccanismi nativi di logging dei container. Scrivi i log in stdout e stderr: verranno automaticamente acquisiti, salvati e indicizzati.<\/p>\n

Se desideri, puoi anche scrivere i log in formato JSON<\/a><\/noindex>. Questo approccio permette di aggiungere facilmente metadati. E insieme a questi, in Stackdriver Logging sar\u00e0 disponibile la funzione di ricerca nei log utilizzando questi metadati.<\/p>\n

2. Assicurati che i container siano stateless e immutabili<\/h2>\n

\nPer garantire il corretto funzionamento dei contenitori nel cluster Kubernetes, devono essere stateless e immutable. Quando queste condizioni sono soddisfatte, Kubernetes pu\u00f2 svolgere il proprio lavoro creando e distruggendo le entit\u00e0 dell'applicazione quando e dove necessario.<\/p>\n

Stateless<\/i> significa che qualsiasi stato (dati persistenti di qualsiasi tipo) viene memorizzato al di fuori del contenitore. A questo scopo, a seconda delle esigenze, possono essere impiegati diversi tipi di archiviazione esterna: Cloud Storage<\/a><\/noindex>, Persistent Disks<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> o altri database gestiti. (Nota del traduttore.<\/b>: Leggi anche il nostro articolo \u00abOperatori per Kubernetes: come avviare applicazioni stateful<\/a><\/noindex>\u00bb.)<\/i><\/p>\n

Immutable<\/i> significa che il contenitore non sar\u00e0 modificato durante la sua vita: nessun aggiornamento, patch o variazione nella configurazione. Se hai bisogno di aggiornare il codice dell'applicazione o applicare una patch, crea una nuova immagine e distribuiscila. \u00c8 consigliabile esternalizzare la configurazione del contenitore (porta da ascoltare, opzioni dell'ambiente di esecuzione, ecc.) in Secrets<\/a><\/noindex> e ConfigMaps<\/a><\/noindex>. Possono essere aggiornati senza la necessit\u00e0 di ricompilare una nuova immagine del contenitore. Per creare pipeline di assemblaggio delle immagini in modo semplice, si pu\u00f2 utilizzare Cloud Build<\/a><\/noindex>. (Nota del traduttore.<\/b>: Per questi scopi utilizziamo uno strumento Open Source dapp<\/a><\/noindex>.)<\/i><\/p>\n

\"7
\nEsempio di aggiornamento della configurazione del Deployment in Kubernetes utilizzando ConfigMap, montato nei pod come configurazione<\/i><\/p>\n

3. Evitare container con privilegi<\/h2>\n

\n\u0412\u044b \u0432\u0435\u0434\u044c \u043d\u0435 \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0435\u0442\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043f\u043e\u0434 root’\u043e\u043c \u043d\u0430 \u0441\u0432\u043e\u0438\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u0445, \u0432\u0435\u0440\u043d\u043e? \u0415\u0441\u043b\u0438 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a \u043f\u0440\u043e\u043d\u0438\u043a\u043d\u0435\u0442 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u043e\u043d \u043f\u043e\u043b\u0443\u0447\u0438\u0442 \u0434\u043e\u0441\u0442\u0443\u043f \u0441 \u043f\u0440\u0430\u0432\u0430\u043c\u0438 root. \u0422\u0435 \u0436\u0435 \u0441\u043e\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0438\u044f \u0441\u043f\u0440\u0430\u0432\u0435\u0434\u043b\u0438\u0432\u044b \u0438 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c \u043f\u0440\u0438\u0432\u0438\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b. \u0415\u0441\u043b\u0438 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0438\u0437\u043c\u0435\u043d\u044f\u0442\u044c \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u043d\u0430 \u0445\u043e\u0441\u0442\u0435, \u043c\u043e\u0436\u043d\u043e \u0432\u044b\u0434\u0430\u0442\u044c \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0443 \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u044b\u0435 capacit\u00e0<\/i> utilizzando l'opzione securityContext<\/code><\/a><\/noindex> in Kubernetes. Se \u00e8 necessario modificare i sysctl<\/i>, Kubernetes ha un'annotazione separata<\/a><\/noindex> per questo. In generale, cerca di utilizzare il pi\u00f9 possibile init-<\/a><\/noindex> e container sidecar per eseguire tali operazioni privilegiate. Non hanno bisogno di essere accessibili n\u00e9 per il traffico interno n\u00e9 per quello esterno.<\/p>\n

Se gestisci un cluster, puoi utilizzare Pod Security Policy<\/a><\/noindex> per le restrizioni sull'uso dei container privilegiate.<\/p>\n

4. Evitare di eseguire come root<\/h2>\n

\n\u041e \u043f\u0440\u0438\u0432\u0438\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430\u0445 \u0443\u0436\u0435 \u0441\u043a\u0430\u0437\u0430\u043d\u043e, \u043d\u043e \u0431\u0443\u0434\u0435\u0442 \u0435\u0449\u0451 \u043b\u0443\u0447\u0448\u0435, \u0435\u0441\u043b\u0438 \u0432 \u0434\u043e\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043a \u044d\u0442\u043e\u043c\u0443 \u0432\u044b \u043d\u0435 \u0431\u0443\u0434\u0435\u0442\u0435 \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c \u043f\u043e\u0434 root’\u043e\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0415\u0441\u043b\u0438 \u0437\u043b\u043e\u0443\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0438\u043a \u043d\u0430\u0439\u0434\u0451\u0442 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0438 \u0441 \u043f\u0440\u0430\u0432\u0430\u043c\u0438 root \u0443\u0434\u0430\u043b\u0451\u043d\u043d\u0443\u044e \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c \u0441 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0438\u0441\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043a\u043e\u0434\u0430, \u043f\u043e\u0441\u043b\u0435 \u0447\u0435\u0433\u043e \u0441\u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u0439\u0442\u0438 \u0438\u0437 \u043f\u0440\u0435\u0434\u0435\u043b\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043a\u0430 \u0435\u0449\u0451 \u043d\u0435\u0438\u0437\u0432\u0435\u0441\u0442\u043d\u0443\u044e \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c, \u0442\u043e \u043f\u043e\u043b\u0443\u0447\u0438\u0442 root’\u0430 \u043d\u0430 \u0445\u043e\u0441\u0442\u0435.<\/p>\n

\u041b\u0443\u0447\u0448\u0438\u0439 \u043f\u0443\u0442\u044c \u0438\u0437\u0431\u0435\u0436\u0430\u0442\u044c \u044d\u0442\u043e\u0433\u043e \u2014 \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u043d\u0435 \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c \u043d\u0438\u0447\u0435\u0433\u043e \u043f\u043e\u0434 root’\u043e\u043c. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u0436\u043d\u043e \u0432\u043e\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c\u0441\u044f \u0434\u0438\u0440\u0435\u043a\u0442\u0438\u0432\u043e\u0439 UTENTE<\/code> in Dockerfile<\/code> o runAsUser<\/code> in Kubernetes. L'amministratore del cluster pu\u00f2 anche configurare un comportamento forzato utilizzando Pod Security Policy<\/a><\/noindex>.<\/p>\n

5. Rendi l'applicazione facile da monitorare<\/h2>\n

\nCome la registrazione, il monitoraggio \u00e8 una parte fondamentale della gestione dell'applicazione. Una soluzione popolare per il monitoraggio nella comunit\u00e0 Kubernetes \u00e8 Prometheus<\/a><\/noindex> \u2014 un sistema che rileva automaticamente i pod e i servizi che necessitano di monitoraggio. (Nota del traduttore.<\/b>: Vedi anche il nostro rapporto dettagliato<\/a><\/noindex> sul monitoraggio con Prometheus e Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> \u00e8 in grado di monitorare i cluster Kubernetes e include una propria versione di Prometheus per il monitoraggio delle applicazioni.<\/p>\n

\"7
\nIl cruscotto Kubernetes in Stackdriver<\/i><\/p>\n

Prometheus si aspetta che l'applicazione esponga le metriche su un endpoint HTTP. A tal fine, sono disponibili librerie client di Prometheus<\/a><\/noindex>. Lo stesso formato \u00e8 utilizzato da altri strumenti come OpenCensus<\/a><\/noindex> e Istio<\/a><\/noindex>.<\/p>\n

6. Rendi disponibile lo stato di salute dell'applicazione<\/h2>\n

\nLa gestione di un'applicazione in produzione \u00e8 facilitata dalla sua capacit\u00e0 di comunicare il proprio stato all'intero sistema. L'applicazione \u00e8 in esecuzione? Va bene? \u00c8 pronta a ricevere traffico? Come si comporta? Il modo pi\u00f9 comune per affrontare questo problema \u00e8 implementare controlli di salute (health checks)<\/i>. Kubernetes ne ha due tipi: probe di liveness e probe di readiness<\/a><\/noindex>.<\/p>\n

Per la liveness probe (controllo di vitalit\u00e0)<\/i> l'applicazione deve avere un endpoint HTTP che restituisca la risposta \"200 OK\" se funziona e se le sue principali dipendenze sono soddisfatte. Per la readiness probe (controllo di prontezza)<\/i> \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043e\u043b\u0436\u043d\u043e \u0438\u043c\u0435\u0442\u044c \u0434\u0440\u0443\u0433\u043e\u0439 HTTP endpoint, \u0432\u043e\u0437\u0432\u0440\u0430\u0449\u0430\u044e\u0449\u0438\u0439 \u043e\u0442\u0432\u0435\u0442 \u00ab200 OK\u00bb, \u0435\u0441\u043b\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0432 \u0437\u0434\u043e\u0440\u043e\u0432\u043e\u043c \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0438, \u0448\u0430\u0433\u0438 \u043f\u043e \u0438\u043d\u0438\u0446\u0438\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u044b \u0438 \u043b\u044e\u0431\u043e\u0439 \u043a\u043e\u0440\u0440\u0435\u043a\u0442\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441 \u043d\u0435 \u043f\u0440\u0438\u0432\u043e\u0434\u0438\u0442 \u043a \u043e\u0448\u0438\u0431\u043a\u0435. Kubernetes \u0431\u0443\u0434\u0435\u0442 \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u044f\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a \u043d\u0430 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0433\u043e\u0442\u043e\u0432\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u0438 \u0441 \u044d\u0442\u0438\u043c\u0438 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0430\u043c\u0438. \u0414\u0432\u0430 endpoint’\u0430 \u043c\u043e\u0433\u0443\u0442 \u043e\u0431\u044a\u0435\u0434\u0438\u043d\u0435\u043d\u044b, \u0435\u0441\u043b\u0438 \u0440\u0430\u0437\u043d\u0438\u0446\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f\u043c\u0438 \u0436\u0438\u0437\u043d\u0435\u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u0438 (liveness) \u0438 \u0433\u043e\u0442\u043e\u0432\u043d\u043e\u0441\u0442\u0438 (readiness) \u043d\u0435\u0442.<\/p>\n

Puoi leggere di pi\u00f9 a riguardo nell'articolo corrispondente di Sandeep Dinesh, Developer Advocate di Google: \"Kubernetes best practices: Impostare controlli di salute con probe di prontezza e vivibilit\u00e0<\/a><\/noindex>\u00bb.<\/p>\n

7. Scegli attentamente la versione dell'immagine<\/h2>\n

\nLa maggior parte delle immagini pubbliche e private utilizza un sistema di tagging simile a quello descritto in Best Practices for Building Containers<\/a><\/noindex>. Se l'immagine applica un sistema vicino a versionamento semantico<\/a><\/noindex>, \u00e8 necessario tenere conto delle specifiche di tagging. Ad esempio, il tag latest<\/code> pu\u00f2 muoversi frequentemente da un'immagine a un'altra \u2014 non puoi fare affidamento su di esso se hai bisogno di build e installazioni prevedibili e riproducibili.<\/p>\n

Puoi utilizzare il tag X.Y.Z<\/code> (sono quasi sempre invariati), ma in tal caso monitora tutte le patch e gli aggiornamenti per l'immagine. Se l'immagine che stai usando ha un tag X.Y<\/code>, \u00e8 una buona opzione di compromesso. Scegliendola, ricevi automaticamente le patch e allo stesso tempo fai affidamento su una versione stabile dell'applicazione.<\/p>\n

P.S. dal traduttore<\/h2>\n

\nLeggete anche nel nostro blog:<\/p>\n