{"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 di traduzione.<\/b>: L'autore dell'articolo originale \u00e8 Th\u00e9o 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\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 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\u00f9 importanti secondo Google?<\/i><\/p>\n

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

Kubernetes Engine<\/a><\/noindex> (servizio basato su Kubernetes per eseguire applicazioni containerizzate in Google Cloud \u2014 Nota di traduzione.<\/b>)<\/i> \u2014 \u00e8 uno dei migliori modi per eseguire carichi di lavoro che necessitano di scalabilit\u00e0. Kubernetes<\/a><\/noindex> Assicurer\u00e0 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, \u00e8 necessario seguire le migliori pratiche. Queste semplificheranno la gestione dell'applicazione, il suo monitoraggio e il debug, aumentando anche la sicurezza.<\/p>\n

In questo articolo esamineremo un elenco di ci\u00f2 che \u00e8 importante sapere e fare per il funzionamento efficace dei container in Kubernetes. Chi desidera approfondire i dettagli dovrebbe leggere il materiale Best Practices for Operating Containers<\/a><\/noindex>, e prestare attenzione al nostro post precedente<\/a><\/noindex> sulla build dei container.<\/p>\n

1. Utilizza i meccanismi nativi dei container per la registrazione<\/h2>\n

\nSe l'applicazione \u00e8 eseguita in un cluster Kubernetes, non \u00e8 necessario molto per i log. Un sistema di registrazione centralizzato \u00e8 probabilmente gi\u00e0 integrato nel cluster che stai utilizzando. Nel caso di Kubernetes Engine, ci\u00f2 \u00e8 gestito da Stackdriver Logging<\/a><\/noindex>. (Nota di traduzione.<\/b>: Nel caso di un'installazione propria 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 di registrazione nativi dei container. Scrivi i log in stdout e stderr: verranno automaticamente acquisiti, salvati e indicizzati.<\/p>\n

Se lo desideri, \u00e8 possibile scrivere i log anche in formato JSON<\/a><\/noindex>. Questo approccio permetter\u00e0 di aggiungere facilmente metadati. E insieme a questi, in Stackdriver Logging ci sar\u00e0 la possibilit\u00e0 di cercare nei log utilizzando questi metadati.<\/p>\n

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

\nPer un corretto funzionamento dei contenitori nel cluster Kubernetes, devono essere stateless e immutabili. Quando queste condizioni sono soddisfatte, Kubernetes sar\u00e0 in grado di svolgere il proprio lavoro, creando e distruggendo 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 tal fine, a seconda delle esigenze, possono essere utilizzati diversi tipi di archiviazione esterna: Cloud Storage<\/a><\/noindex>, Persistent Disks<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> o altre basi di dati gestite. (Nota di traduzione.<\/b>: Maggiori dettagli sono disponibili anche nel nostro articolo \"Operatori per Kubernetes: come eseguire 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 modifiche alla configurazione. Se \u00e8 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 \u2014 in Secrets<\/a><\/noindex> e ConfigMaps<\/a><\/noindex>. Questi possono essere aggiornati senza dover ricostruire la nuova immagine del contenitore. Per una semplice creazione di pipeline con la costruzione di immagini, \u00e8 possibile utilizzare Cloud Build<\/a><\/noindex>. (Nota di traduzione.<\/b>: Per questo scopo utilizziamo uno strumento Open Source chiamato 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 i contenitori privilegiati<\/h2>\n

\nNon stai lanciando applicazioni come root sui tuoi server, giusto? Se un attaccante riesce a penetrare nell'applicazione, avr\u00e0 accesso con privilegi di root. Le stesse considerazioni si applicano anche per evitare di eseguire contenitori con privilegi elevati. Se \u00e8 necessario modificare le impostazioni sull'host, puoi fornire al contenitore specifici capabilities<\/i> utilizzando l'opzione securityContext<\/code><\/a><\/noindex> in Kubernetes. Se \u00e8 necessario modificare sysctls<\/i>, Kubernetes ha un'annotazione separata<\/a><\/noindex> per questo. In generale, cerca di utilizzare il pi\u00f9 possibile init-<\/a><\/noindex> e contenitori 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 limitazioni nell'applicazione di contenitori privilegiati.<\/p>\n

4. Evitare l'esecuzione come root<\/h2>\n

\nDi contenitori privilegiati si \u00e8 gi\u00e0 parlato, ma sarebbe ancora meglio se oltre a questo non eseguissi applicazioni come root all'interno del contenitore. Se un attaccante trova un'implementazione remota vulnerabile con privilegi di root, con la possibilit\u00e0 di eseguire codice, e riesce a uscire dai limiti del contenitore tramite una vulnerabilit\u00e0 ancora sconosciuta, otterr\u00e0 accesso come root sull'host.<\/p>\n

Il modo migliore per evitare ci\u00f2 \u00e8, prima di tutto, non eseguire nulla come root. A tal fine, puoi utilizzare la direttiva UTENTE<\/code> in Dockerfile<\/code> o runAsUser<\/code> in Kubernetes. L'amministratore del cluster pu\u00f2 anche impostare un comportamento forzato usando Pod Security Policy<\/a><\/noindex>.<\/p>\n

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

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

\"7
\nLa dashboard di monitoraggio di Kubernetes in Stackdriver<\/i><\/p>\n

Prometheus si aspetta che l'applicazione esponga metriche su un endpoint HTTP. A questo scopo sono disponibili librerie client di Prometheus<\/a><\/noindex>. Lo stesso formato \u00e8 utilizzato anche 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 capacit\u00e0 di un'applicazione di comunicare il proprio stato all'intero sistema aiuta nella gestione dell'applicazione in produzione. L'applicazione \u00e8 in esecuzione? \u00c8 in ordine? \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 ha due tipi di controlli di salute: liveness e readiness probes<\/a><\/noindex>.<\/p>\n

Per il liveness probe (controllo di vitalit\u00e0)<\/i> 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)<\/i> l'applicazione deve avere un altro endpoint HTTP che restituisca la risposta \u00ab200 OK\u00bb, se l'applicazione \u00e8 in uno stato sano, sono stati eseguiti tutti i passaggi di inizializzazione e qualsiasi richiesta valida non causa errori. Kubernetes instrader\u00e0 il traffico al contenitore solo se l'applicazione \u00e8 pronta secondo queste verifiche. Due endpoint possono essere combinati se non c'\u00e8 differenza tra gli stati di vitalit\u00e0 (liveness) e di prontezza (readiness).<\/p>\n

Per ulteriori dettagli, puoi leggere l'articolo corrispondente di Sandeep Dinesh, Developer Advocate di Google: \u00abKubernetes best practices: Impostare controlli di salute con sonde di prontezza e vitalit\u00e0<\/a><\/noindex>\u00bb.<\/p>\n

7. Scegli con attenzione 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 utilizza un sistema simile a versionamento semantico<\/a><\/noindex>, \u00e8 necessario considerare le specificit\u00e0 del tagging. Ad esempio, il tag latest<\/code> pu\u00f2 spesso spostarsi da un'immagine all'altra: non si pu\u00f2 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 invariabili), ma in tal caso segui tutti i patch e aggiornamenti per l'immagine. Se l'immagine utilizzata ha un tag X.Y<\/code>, \u00e8 una buona opzione intermedia. Scegliendolo, ottieni automaticamente i patch e allo stesso tempo ti basi su una versione stabile dell'applicazione.<\/p>\n

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

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