{"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\/fr\/blog\/administrirovanie\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","title":{"rendered":"7 meilleures pratiques d'exploitation des conteneurs selon Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Note de traduction.<\/b>: L'auteur de l'article original est Th\u00e9o Chamley, architecte de solutions cloud chez Google. Dans cette publication pour le blog Google Cloud, il pr\u00e9sente un bref aper\u00e7u d'un guide plus d\u00e9taill\u00e9 de son entreprise, intitul\u00e9 \"Meilleures pratiques pour l'exploitation des conteneurs<\/a><\/noindex>\u00bb. Dans ce guide, des experts de Google ont rassembl\u00e9 les meilleures pratiques pour l'exploitation des conteneurs dans le contexte de l'utilisation de Google Kubernetes Engine et au-del\u00e0, abordant une large gamme de sujets : de la s\u00e9curit\u00e9 \u00e0 la surveillance et \u00e0 la journalisation. Quelles sont donc, selon Google, les pratiques les plus importantes \u00e0 suivre lors de l'utilisation des conteneurs ?<\/i><\/p>\n

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

Kubernetes Engine<\/a><\/noindex> (un service bas\u00e9 sur Kubernetes pour ex\u00e9cuter des applications conteneuris\u00e9es dans Google Cloud \u2014 Note de traduction.<\/b>)<\/i> \u2014 est l'un des meilleurs moyens de d\u00e9ployer des charges de travail n\u00e9cessitant une mise \u00e0 l'\u00e9chelle. Kubernetes<\/a><\/noindex> Cela garantira le bon fonctionnement de la plupart des applications, \u00e0 condition qu'elles soient conteneuris\u00e9es. Mais si vous souhaitez que votre application soit facile \u00e0 g\u00e9rer et que vous souhaitiez tirer parti de tous les avantages de Kubernetes, il est n\u00e9cessaire de suivre les meilleures pratiques. Celles-ci faciliteront l'exploitation de l'application, sa surveillance et son d\u00e9pannage, tout en am\u00e9liorant la s\u00e9curit\u00e9.<\/p>\n

Dans cet article, nous passerons en revue les \u00e9l\u00e9ments \u00e0 conna\u00eetre et \u00e0 mettre en \u0153uvre pour le fonctionnement efficace des conteneurs dans Kubernetes. Pour ceux qui souhaitent approfondir les d\u00e9tails, nous vous encourageons \u00e0 lire le mat\u00e9riel Meilleures pratiques pour l'exploitation des conteneurs<\/a><\/noindex>, ainsi qu'\u00e0 jeter un \u0153il \u00e0 notre article pr\u00e9c\u00e9dent<\/a><\/noindex> sur la cr\u00e9ation de conteneurs.<\/p>\n

1. Utilisez les m\u00e9canismes natifs des conteneurs pour la journalisation<\/h2>\n

\nSi l'application s'ex\u00e9cute dans un cluster Kubernetes, il n'y a pas besoin de beaucoup de log. Un syst\u00e8me de journalisation centralis\u00e9 est probablement d\u00e9j\u00e0 int\u00e9gr\u00e9 dans le cluster utilis\u00e9. Dans le cas de Kubernetes Engine, cela est g\u00e9r\u00e9 par Stackdriver Logging<\/a><\/noindex>. (Note de traduction.<\/b>: Et dans le cas d'une installation Kubernetes autonome, nous recommandons d'explorer notre solution open source \u2014 loghouse<\/a><\/noindex>.)<\/i> Ne vous compliquez pas la vie et utilisez les m\u00e9canismes de journalisation natifs des conteneurs. \u00c9crivez les logs dans stdout et stderr \u2014 ils seront automatiquement r\u00e9cup\u00e9r\u00e9s, stock\u00e9s et index\u00e9s.<\/p>\n

Si vous le souhaitez, vous pouvez \u00e9galement \u00e9crire les logs au format JSON<\/a><\/noindex>. Cette approche permettra d'ajouter facilement des m\u00e9tadonn\u00e9es. Et avec celles-ci, il sera possible de rechercher dans Stackdriver Logging les logs en utilisant ces m\u00e9tadonn\u00e9es.<\/p>\n

2. Assurez-vous que les conteneurs sont sans \u00e9tat et immuables<\/h2>\n

\nPour un fonctionnement correct des conteneurs dans un cluster Kubernetes, ceux-ci doivent \u00eatre sans \u00e9tat et immuables. Lorsque ces conditions sont remplies, Kubernetes sera capable de remplir sa fonction en cr\u00e9ant et d\u00e9truisant des entit\u00e9s d'application quand et o\u00f9 cela est n\u00e9cessaire.<\/p>\n

Sans \u00e9tat<\/i> signifie que tout \u00e9tat (donn\u00e9es permanentes de tout type) est stock\u00e9 en dehors du conteneur. Pour cela, selon les besoins, diff\u00e9rents types de stockage externe peuvent \u00eatre utilis\u00e9s : Stockage Cloud<\/a><\/noindex>, Disques Persistants<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> ou d'autres bases de donn\u00e9es g\u00e9r\u00e9es. (Note de traduction.<\/b>: Pour en savoir plus, consultez \u00e9galement notre article \u00abOp\u00e9rateurs pour Kubernetes : comment ex\u00e9cuter des applications stateful<\/a><\/noindex>\u00bb.)<\/i><\/p>\n

Immuable<\/i> signifie que le conteneur ne sera pas modifi\u00e9 durant sa vie : pas de mises \u00e0 jour, de correctifs, ou de modifications de configuration. Si vous devez mettre \u00e0 jour le code de l'application ou appliquer un correctif, cr\u00e9ez une nouvelle image et d\u00e9ployez-la. Il est recommand\u00e9 de sortir la configuration du conteneur (port d'\u00e9coute, options de l'environnement d'ex\u00e9cution, etc.) \u00e0 l'ext\u00e9rieur \u2014 dans Secrets<\/a><\/noindex> et ConfigMaps<\/a><\/noindex>. Ceux-ci peuvent \u00eatre mis \u00e0 jour sans avoir besoin de reconstruire une nouvelle image de conteneur. Pour cr\u00e9er facilement des pipelines de construction d'images, vous pouvez utiliser Cloud Build<\/a><\/noindex>. (Note de traduction.<\/b>: Pour ces objectifs, nous utilisons l'outil Open Source dapp<\/a><\/noindex>.)<\/i><\/p>\n

\"7
\nExemple de mise \u00e0 jour de la configuration Deployment dans Kubernetes \u00e0 l'aide de ConfigMap, mont\u00e9 dans les pods comme configuration<\/i><\/p>\n

3. \u00c9vitez les conteneurs privil\u00e9gi\u00e9s<\/h2>\n

\nVous ne lancez pas d'applications sous root sur vos serveurs, n'est-ce pas ? Si un attaquant parvient \u00e0 p\u00e9n\u00e9trer dans l'application, il obtiendra un acc\u00e8s avec des droits root. Les m\u00eames consid\u00e9rations s'appliquent pour ne pas ex\u00e9cuter de conteneurs privil\u00e9gi\u00e9s. Si vous devez modifier les param\u00e8tres sur l'h\u00f4te, vous pouvez donner au conteneur des droits sp\u00e9cifiques. des capacit\u00e9s<\/i> avec l'option securityContext<\/code><\/a><\/noindex> dans Kubernetes. Si vous devez modifier les sysctls<\/i>, Kubernetes dispose d une annotation distincte<\/a><\/noindex> pour cela. En g\u00e9n\u00e9ral, essayez d'utiliser au maximum les init-<\/a><\/noindex> et les conteneurs sidecar pour effectuer des op\u00e9rations privil\u00e9gi\u00e9es similaires. Ils n'ont pas besoin d'\u00eatre accessibles ni pour le trafic interne, ni pour le trafic externe.<\/p>\n

Si vous administrez un cluster, vous pouvez utiliser la Politique de S\u00e9curit\u00e9 des Pods<\/a><\/noindex> pour restreindre l'utilisation de conteneurs privil\u00e9gi\u00e9s.<\/p>\n

4. \u00c9vitez de lancer en tant que root<\/h2>\n

\nIl a d\u00e9j\u00e0 \u00e9t\u00e9 question des conteneurs privil\u00e9gi\u00e9s, mais il serait encore mieux de ne pas ex\u00e9cuter d'applications sous root \u00e0 l'int\u00e9rieur d'un conteneur. Si un attaquant trouve une vuln\u00e9rabilit\u00e9 \u00e0 distance avec ex\u00e9cution de code dans une application tournant sous root, puis qu'il parvient \u00e0 sortir du conteneur par une vuln\u00e9rabilit\u00e9 encore inconnue, il obtiendra l'acc\u00e8s root sur l'h\u00f4te.<\/p>\n

Le meilleur moyen d'\u00e9viter cela est, en premier lieu, de ne rien ex\u00e9cuter sous root. Pour cela, vous pouvez utiliser la directive. UTILISATEUR<\/code> dans Dockerfile<\/code> ou runAsUser<\/code> dans Kubernetes. L'administrateur du cluster peut \u00e9galement configurer un comportement forc\u00e9 \u00e0 l'aide de la Politique de S\u00e9curit\u00e9 des Pods<\/a><\/noindex>.<\/p>\n

5. Rendez l'application facile \u00e0 surveiller<\/h2>\n

\nTout comme le journalisation, la surveillance est une partie int\u00e9grante de la gestion de l'application. Une solution populaire de surveillance dans la communaut\u00e9 Kubernetes est Prometheus<\/a><\/noindex> \u2014 un syst\u00e8me qui d\u00e9couvre automatiquement les pods et les services n\u00e9cessitant une surveillance. (Note de traduction.<\/b>: Voir \u00e9galement notre rapport d\u00e9taill\u00e9<\/a><\/noindex> sur la surveillance avec Prometheus et Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> peut surveiller les clusters Kubernetes et inclut sa propre version de Prometheus pour la surveillance des applications.<\/p>\n

\"7
\nLe tableau de bord Kubernetes dans Stackdriver<\/i><\/p>\n

Prometheus s'attend \u00e0 ce que l'application expose des m\u00e9triques sur un endpoint HTTP. Pour cela, des biblioth\u00e8ques clientes Prometheus<\/a><\/noindex>sont disponibles. Un format similaire est utilis\u00e9 par d'autres outils comme OpenCensus<\/a><\/noindex> et Istio<\/a><\/noindex>.<\/p>\n

6. Rendez l'\u00e9tat de sant\u00e9 de l'application accessible<\/h2>\n

\nLa gestion d'une application en production est aid\u00e9e par sa capacit\u00e9 \u00e0 communiquer son \u00e9tat \u00e0 l'ensemble du syst\u00e8me. L'application est-elle en cours d'ex\u00e9cution ? Est-elle en bon \u00e9tat ? Pr\u00eate \u00e0 recevoir du trafic ? Comment se comporte-t-elle ? La mani\u00e8re la plus courante de r\u00e9soudre ce probl\u00e8me est de mettre en \u0153uvre des contr\u00f4les de sant\u00e9 (health checks)<\/i>. Kubernetes a deux types : liveness et readiness probes<\/a><\/noindex>.<\/p>\n

Pour un liveness probe (contr\u00f4le de l'\u00e9tat de vie)<\/i> l'application doit avoir un endpoint HTTP renvoyant une r\u00e9ponse \u00ab 200 OK \u00bb si elle fonctionne et que ses principales d\u00e9pendances sont satisfaites. Pour un readiness probe (contr\u00f4le de la disponibilit\u00e9)<\/i> L'application doit avoir un autre point de terminaison HTTP renvoyant une r\u00e9ponse \u00ab 200 OK \u00bb si l'application est en bonne sant\u00e9, que les \u00e9tapes d'initialisation sont compl\u00e9t\u00e9es et qu'aucune requ\u00eate valide ne conduit \u00e0 une erreur. Kubernetes dirigera le trafic vers le conteneur uniquement lorsque l'application est pr\u00eate selon ces v\u00e9rifications. Les deux points de terminaison peuvent \u00eatre combin\u00e9s s'il n'y a pas de diff\u00e9rence entre les \u00e9tats de vivacit\u00e9 (liveness) et de pr\u00e9paration (readiness).<\/p>\n

Pour en savoir plus, vous pouvez lire l'article correspondant de Sandeep Dinesh, Developer Advocate chez Google : \u00abMeilleures pratiques Kubernetes : Configuration des v\u00e9rifications de sant\u00e9 avec des sondes de pr\u00e9paration et de viabilit\u00e9<\/a><\/noindex>\u00bb.<\/p>\n

7. Choisissez attentivement la version de l'image<\/h2>\n

\nLa plupart des images publiques et priv\u00e9es utilisent un syst\u00e8me de balisage similaire \u00e0 celui d\u00e9crit dans Meilleures pratiques pour construire des conteneurs<\/a><\/noindex>. Si l'image applique un syst\u00e8me proche de la version s\u00e9mantique<\/a><\/noindex>, il faut tenir compte des sp\u00e9cificit\u00e9s du balisage. Par exemple, la balise latest<\/code> peut souvent \u00eatre d\u00e9plac\u00e9e d'une image \u00e0 l'autre \u2014 elle ne peut pas \u00eatre fiable si vous avez besoin de constructions et d'installations pr\u00e9visibles et reproductibles.<\/p>\n

Vous pouvez utiliser la balise X.Y.Z<\/code> (elles sont presque toujours constantes), mais dans ce cas, suivez tous les correctifs et mises \u00e0 jour de l'image. Si l'image utilis\u00e9e a la balise X.Y<\/code>, c'est une bonne option de compromis. En choisissant celle-ci, vous obtenez automatiquement des correctifs tout en vous appuyant sur une version stable de l'application.<\/p>\n

P.S. de l'auteur<\/h2>\n

\nLisez aussi dans notre blog :<\/p>\n