7 meilleures pratiques d'exploitation des conteneurs selon Google

Note de traduction.: L'auteur de l'article original est Théo Chamley, architecte de solutions cloud chez Google. Dans cette publication pour le blog Google Cloud, il présente un bref aperçu d'un guide plus détaillé de son entreprise, intitulé "Meilleures pratiques pour l'exploitation des conteneurs». Dans ce guide, des experts de Google ont rassemblé les meilleures pratiques pour l'exploitation des conteneurs dans le contexte de l'utilisation de Google Kubernetes Engine et au-delà, abordant une large gamme de sujets : de la sécurité à la surveillance et à la journalisation. Quelles sont donc, selon Google, les pratiques les plus importantes à suivre lors de l'utilisation des conteneurs ?

Kubernetes Engine (un service basé sur Kubernetes pour exécuter des applications conteneurisées dans Google Cloud — Note de traduction.) — est l'un des meilleurs moyens de déployer des charges de travail nécessitant une mise à l'échelle. Kubernetes Cela garantira le bon fonctionnement de la plupart des applications, à condition qu'elles soient conteneurisées. Mais si vous souhaitez que votre application soit facile à gérer et que vous souhaitiez tirer parti de tous les avantages de Kubernetes, il est nécessaire de suivre les meilleures pratiques. Celles-ci faciliteront l'exploitation de l'application, sa surveillance et son dépannage, tout en améliorant la sécurité.

Dans cet article, nous passerons en revue les éléments à connaître et à mettre en œuvre pour le fonctionnement efficace des conteneurs dans Kubernetes. Pour ceux qui souhaitent approfondir les détails, nous vous encourageons à lire le matériel Meilleures pratiques pour l'exploitation des conteneurs, ainsi qu'à jeter un œil à notre article précédent sur la création de conteneurs.

1. Utilisez les mécanismes natifs des conteneurs pour la journalisation

Si l'application s'exécute dans un cluster Kubernetes, il n'y a pas besoin de beaucoup de log. Un système de journalisation centralisé est probablement déjà intégré dans le cluster utilisé. Dans le cas de Kubernetes Engine, cela est géré par Stackdriver Logging. (Note de traduction.: Et dans le cas d'une installation Kubernetes autonome, nous recommandons d'explorer notre solution open source — loghouse.) Ne vous compliquez pas la vie et utilisez les mécanismes de journalisation natifs des conteneurs. Écrivez les logs dans stdout et stderr — ils seront automatiquement récupérés, stockés et indexés.

Si vous le souhaitez, vous pouvez également écrire les logs au format JSON. Cette approche permettra d'ajouter facilement des métadonnées. Et avec celles-ci, il sera possible de rechercher dans Stackdriver Logging les logs en utilisant ces métadonnées.

2. Assurez-vous que les conteneurs sont sans état et immuables

Pour un fonctionnement correct des conteneurs dans un cluster Kubernetes, ceux-ci doivent être sans état et immuables. Lorsque ces conditions sont remplies, Kubernetes sera capable de remplir sa fonction en créant et détruisant des entités d'application quand et où cela est nécessaire.

Sans état signifie que tout état (données permanentes de tout type) est stocké en dehors du conteneur. Pour cela, selon les besoins, différents types de stockage externe peuvent être utilisés : Stockage Cloud, Disques Persistants, Redis, Cloud SQL ou d'autres bases de données gérées. (Note de traduction.: Pour en savoir plus, consultez également notre article «Opérateurs pour Kubernetes : comment exécuter des applications stateful».)

Immuable signifie que le conteneur ne sera pas modifié durant sa vie : pas de mises à jour, de correctifs, ou de modifications de configuration. Si vous devez mettre à jour le code de l'application ou appliquer un correctif, créez une nouvelle image et déployez-la. Il est recommandé de sortir la configuration du conteneur (port d'écoute, options de l'environnement d'exécution, etc.) à l'extérieur — dans Secrets et ConfigMaps. Ceux-ci peuvent être mis à jour sans avoir besoin de reconstruire une nouvelle image de conteneur. Pour créer facilement des pipelines de construction d'images, vous pouvez utiliser Cloud Build. (Note de traduction.: Pour ces objectifs, nous utilisons l'outil Open Source dapp.)

Exemple de mise à jour de la configuration Deployment dans Kubernetes à l'aide de ConfigMap, monté dans les pods comme configuration

3. Évitez les conteneurs privilégiés

Vous ne lancez pas vos applications en tant que root sur vos serveurs, n'est-ce pas ? Si un attaquant pénètre dans l'application, il obtiendra l'accès avec les droits root. Les mêmes considérations s'appliquent pour ne pas lancer de conteneurs privilégiés. Si vous devez modifier des paramètres sur l'hôte, vous pouvez donner au conteneur des des capacités avec l'option securityContext dans Kubernetes. Si vous devez modifier les sysctls, Kubernetes dispose d une annotation distincte pour cela. En général, essayez d'utiliser au maximum les init- et les conteneurs sidecar pour effectuer des opérations privilégiées similaires. Ils n'ont pas besoin d'être accessibles ni pour le trafic interne, ni pour le trafic externe.

Si vous administrez un cluster, vous pouvez utiliser la Politique de Sécurité des Pods pour restreindre l'utilisation de conteneurs privilégiés.

4. Évitez de lancer en tant que root

Il a déjà été question des conteneurs privilégiés, mais il serait encore mieux que vous ne lanciez pas d'applications en tant que root à l'intérieur du conteneur. Si un attaquant trouve une vulnérabilité à distance dans une application exécutée avec des droits root, lui permettant d'exécuter du code, puis réussit à sortir des limites du conteneur via une vulnérabilité encore inconnue, il obtiendra des droits root sur l'hôte.

Le meilleur moyen d'éviter cela est avant tout de ne rien exécuter en tant que root. Pour cela, vous pouvez utiliser la directive UTILISATEUR dans Dockerfile ou runAsUser dans Kubernetes. L'administrateur du cluster peut également configurer un comportement forcé à l'aide de la Politique de Sécurité des Pods.

5. Rendez l'application facile à surveiller

Tout comme le journalisation, la surveillance est une partie intégrante de la gestion de l'application. Une solution populaire de surveillance dans la communauté Kubernetes est Prometheus — un système qui découvre automatiquement les pods et les services nécessitant une surveillance. (Note de traduction.: Voir également notre rapport détaillé sur la surveillance avec Prometheus et Kubernetes.) Stackdriver peut surveiller les clusters Kubernetes et inclut sa propre version de Prometheus pour la surveillance des applications.

Le tableau de bord Kubernetes dans Stackdriver

Prometheus s'attend à ce que l'application expose des métriques sur un endpoint HTTP. Pour cela, des bibliothèques clientes Prometheussont disponibles. Un format similaire est utilisé par d'autres outils comme OpenCensus et Istio.

6. Rendez l'état de santé de l'application accessible

La gestion d'une application en production est aidée par sa capacité à communiquer son état à l'ensemble du système. L'application est-elle en cours d'exécution ? Est-elle en bon état ? Prête à recevoir du trafic ? Comment se comporte-t-elle ? La manière la plus courante de résoudre ce problème est de mettre en œuvre des contrôles de santé (health checks). Kubernetes a deux types : liveness et readiness probes.

Pour un liveness probe (contrôle de l'état de vie) l'application doit avoir un endpoint HTTP renvoyant une réponse « 200 OK » si elle fonctionne et que ses principales dépendances sont satisfaites. Pour un readiness probe (contrôle de la disponibilité) L'application doit avoir un autre point de terminaison HTTP, renvoyant une réponse « 200 OK », si l'application est en bon état, que les étapes d'initialisation sont terminées et qu'aucune requête correcte ne génère d'erreur. Kubernetes dirigera le trafic vers le conteneur uniquement lorsque l'application sera prête selon ces vérifications. Les deux points de terminaison peuvent être combinés si l'écart entre les états de viabilité (liveness) et de préparation (readiness) n'existe pas.

Pour en savoir plus, vous pouvez lire l'article correspondant de Sandeep Dinesh, Developer Advocate chez Google : «Meilleures pratiques Kubernetes : Configuration des vérifications de santé avec des sondes de préparation et de viabilité».

7. Choisissez attentivement la version de l'image

La plupart des images publiques et privées utilisent un système de balisage similaire à celui décrit dans Meilleures pratiques pour construire des conteneurs. Si l'image applique un système proche de la version sémantique, il faut tenir compte des spécificités du balisage. Par exemple, la balise latest peut souvent être déplacée d'une image à l'autre — elle ne peut pas être fiable si vous avez besoin de constructions et d'installations prévisibles et reproductibles.

Vous pouvez utiliser la balise X.Y.Z (elles sont presque toujours constantes), mais dans ce cas, suivez tous les correctifs et mises à jour de l'image. Si l'image utilisée a la balise X.Y, 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.S. de l'auteur

Lisez aussi dans notre blog :

• «Nouvelles statistiques de la CNCF sur les conteneurs, le cloud natif et Kubernetes»;
• «7 principes de conception d'applications basées sur des conteneurs»;
• «11 façons de (ne pas) devenir une victime de hacking dans Kubernetes»;
• «Notre expérience avec Kubernetes dans de petits projets» (aperçu et vidéo de la présentation);
• «Surveillance et Kubernetes» (aperçu et vidéo de la présentation);
• «Création d'images Docker pour CI/CD rapidement et facilement avec dapp» (aperçu et vidéo de la présentation);
• «Pratiques de livraison continue avec Docker» (aperçu et vidéo de la présentation);
• «La mort de la folie des microservices en 2018».

Source : habr.com