Conseils pour la configuration des conteneurs

Lorsque cela est possible, vous devriez essayer d’utiliser un système d’exploitation de base pour conteneurs commun.

Des distributions plus petites telles qu’Alpine et BusyBox réduisent la taille de l’image du conteneur et présentent généralement une surface d’attaque et de vulnérabilité réduite.

Des distributions populaires telles qu’Ubuntu, Fedora et CentOS sont plus éprouvées sur le terrain et offrent plus de fonctionnalités.

Si votre microservice est un binaire statique autonome, vous devriez utiliser un conteneur FROM scratch.

Le conteneur FROM scratch est une image Docker officielle qui est vide afin que vous puissiez l’utiliser pour concevoir des images minimales.

Cela aura la plus petite surface d’attaque et la plus petite taille d’image.

Lorsque cela est possible, utilisez un utilisateur non privilégié lors de l’exécution de processus dans votre conteneur. Bien que les environnements d’exécution de conteneurs offrent une isolation, des vulnérabilités et des attaques sont toujours possibles. Des montages d’hôte involontaires ou accidentels peuvent également être affectés si le conteneur s’exécute en tant que root. Pour des détails sur la configuration d’un contexte de sécurité pour un pod ou un conteneur, référez-vous aux docs Kubernetes.

Appliquez des limites d’UC et de mémoire à vos pods. Cela peut aider à gérer les ressources sur vos nœuds de travail et à éviter qu’un microservice défaillant n’impacte d’autres microservices.

Dans Kubernetes standard, vous pouvez définir des limites de ressources au niveau de l’espace de noms. Dans Rancher, vous pouvez définir des limites de ressources au niveau du projet et elles se propageront à tous les espaces de noms au sein du projet. Pour plus de détails, consultez la documentation de Rancher .

Lors de la définition des quotas de ressources, si vous définissez quoi que ce soit lié à l’UC ou à la mémoire (c’est-à-dire des limites ou des réservations) sur un projet ou un espace de noms, tous les conteneurs devront avoir un champ d’UC ou de mémoire respectif défini lors de leur création. Pour éviter de définir ces limites sur chaque conteneur lors de la création de la charge de travail, une limite de ressources par défaut pour les conteneurs peut être spécifiée au niveau de l’espace de noms.

La documentation de Kubernetes contient plus d’informations sur la façon dont les limites de ressources peuvent être définies au niveau du conteneur et au niveau de l’espace de noms.

Vous devez appliquer des exigences d’UC et de mémoire à vos pods. C’est crucial pour informer le planificateur du type de nœud de calcul sur lequel votre pod doit être placé, et pour s’assurer qu’il ne sur-provisionne pas ce nœud. Dans Kubernetes, vous pouvez définir une exigence de ressource en définissant resources.requests dans le champ des demandes de ressources dans la spécification du conteneur d’un pod. Pour plus de détails, consultez les documents Kubernetes.

Il est recommandé de définir les exigences en matière de ressources au niveau du conteneur, car sinon, le planificateur fait des hypothèses qui ne seront probablement pas utiles à votre application lorsque le cluster subit une charge.

Configurez des contrôles de vivacité et de disponibilité pour votre conteneur. À moins que votre conteneur ne plante complètement, Kubernetes ne saura pas qu’il est en mauvaise santé à moins que vous ne créiez un point de terminaison ou un mécanisme capable de signaler l’état du conteneur. Alternativement, assurez-vous que votre conteneur s’arrête et plante s’il est en mauvaise santé.

La documentation de Kubernetes montre comment configurer des contrôles de vivacité et de disponibilité pour les conteneurs.