Environnement de production | Kubernetes

Un cluster Kubernetes de qualité production nécessite une planification et une préparation. Si votre cluster Kubernetes doit exécuter des charges de travail critiques, il doit être configuré pour être résilient. Cette page explique les étapes que vous pouvez suivre pour mettre en place un cluster prêt pour la production, ou pour faire évoluer un cluster existant vers un usage en production. Si vous êtes déjà familier avec la mise en place en production et souhaitez accéder directement aux liens, passez à Étapes suivantes.
En général, un environnement Kubernetes de production a plus d’exigences qu’un environnement personnel d’apprentissage, de développement ou de test. Un environnement de production peut nécessiter un accès sécurisé pour de nombreux utilisateurs, une disponibilité constante, ainsi que des ressources capables de s’adapter à des besoins changeants.
Lorsque vous décidez où héberger votre environnement Kubernetes de production (sur site ou dans le cloud) et du niveau de gestion que vous souhaitez assumer ou déléguer, réfléchissez à l’impact des éléments suivants sur les exigences de votre cluster Kubernetes :
Disponibilité : Un environnement Kubernetes mono-machine (environnement d’apprentissage) présente un point unique de défaillance. Mettre en place un cluster hautement disponible implique de considérer :
Mise à l’échelle : Si vous prévoyez une demande stable pour votre environnement Kubernetes de production, vous pouvez dimensionner votre infrastructure une fois pour toutes. Cependant, si la demande est susceptible d’augmenter avec le temps ou de varier fortement (selon les saisons ou des événements), vous devez planifier la montée en charge pour absorber une augmentation des requêtes vers le plan de contrôle et les nœuds, ou au contraire réduire les ressources inutilisées.
Sécurité et gestion des accès : Vous disposez de tous les privilèges administrateur sur votre cluster Kubernetes d’apprentissage. En revanche, les clusters partagés avec des charges critiques et plusieurs utilisateurs nécessitent une gestion plus fine des accès aux ressources. Vous pouvez utiliser le contrôle d’accès basé sur les rôles (RBAC) ainsi que d’autres mécanismes de sécurité pour garantir que les utilisateurs et les charges de travail accèdent uniquement aux ressources nécessaires, tout en assurant la sécurité globale du cluster. Vous pouvez également limiter les ressources accessibles via des politiques et la gestion des ressources des conteneurs.
Avant de construire vous-même un environnement Kubernetes de production, vous pouvez envisager de déléguer tout ou partie de cette tâche à des fournisseurs de solutions cloud clé en main ou à d’autres partenaires Kubernetes. Les options incluent :
Que vous construisiez votre cluster Kubernetes de production vous-même ou avec des partenaires, consultez les sections suivantes pour évaluer vos besoins concernant le plan de contrôle, les nœuds de travail, les accès utilisateurs et les ressources des charges de travail.
Dans un cluster Kubernetes de qualité production, le plan de contrôle gère le cluster à partir de services pouvant être répartis sur plusieurs machines de différentes manières. Chaque nœud de travail, en revanche, représente une entité unique configurée pour exécuter des pods Kubernetes.
Le cluster Kubernetes le plus simple exécute l’ensemble des services du plan de contrôle et des nœuds de travail sur une seule machine. Vous pouvez faire évoluer cet environnement en ajoutant des nœuds de travail, comme illustré dans le diagramme de Composants Kubernetes. Si le cluster est destiné à être utilisé sur une courte période, ou peut être abandonné en cas de problème majeur, cela peut suffire à vos besoins.
Cependant, si vous avez besoin d’un cluster plus durable et hautement disponible, vous devez envisager d’étendre le plan de contrôle. Par conception, des services de plan de contrôle exécutés sur une seule machine ne sont pas hautement disponibles. Si le maintien du cluster en fonctionnement et sa capacité à être réparé en cas de problème sont importants, envisagez les étapes suivantes :
Choisir des outils de déploiement : Vous pouvez déployer un plan de contrôle à l’aide d’outils tels que kubeadm, kops et kubespray. Consultez Installer Kubernetes avec des outils de déploiement pour obtenir des conseils sur des déploiements de qualité production avec chacun de ces outils. Différents runtimes de conteneurs sont disponibles pour vos déploiements.
Gérer les certificats : Les communications sécurisées entre les services du plan de contrôle reposent sur des certificats. Ceux-ci peuvent être générés automatiquement lors du déploiement ou créés via votre propre autorité de certification. Consultez Certificats PKI et exigences pour plus de détails.
Configurer un équilibreur de charge pour l’API server : Configurez un load balancer afin de répartir les requêtes API externes vers les instances du serveur API exécutées sur différents nœuds. Voir Créer un load balancer externe pour plus d’informations.
Séparer et sauvegarder le service etcd : Les services etcd peuvent s’exécuter sur les mêmes machines que les autres composants du plan de contrôle ou sur des machines distinctes pour améliorer la sécurité et la disponibilité. Étant donné qu’etcd stocke les données de configuration du cluster, il est recommandé d’effectuer des sauvegardes régulières afin de pouvoir restaurer ces données si nécessaire. Consultez la FAQ etcd pour plus d’informations sur sa configuration et son utilisation. Voir également Exploiter des clusters etcd pour Kubernetes et Mettre en place un cluster etcd hautement disponible avec kubeadm.
Créer plusieurs instances du plan de contrôle : Pour assurer la haute disponibilité, le plan de contrôle ne doit pas être limité à une seule machine. Si les services sont gérés par un système d’init (comme systemd), chaque service devrait être exécuté sur au moins trois machines. Toutefois, exécuter les services du plan de contrôle sous forme de p