Bonnes pratiques

• 1: Considérations pour les grands clusters
• 2: Exécution sur plusieurs zones
• 3: Valider la configuration du nœud
• 4: Application des normes de sécurité des Pods
• 5: Certificats PKI et exigences

1 - Considérations pour les grands clusters

Un cluster est un ensemble de nœuds (machines physiques ou virtuelles) exécutant des agents Kubernetes, et gérés par le plan de contrôle.

Kubernetes v1.36 prend en charge des clusters pouvant aller jusqu’à 5 000 nœuds. Plus précisément, Kubernetes est conçu pour fonctionner avec des configurations respectant toutes les limites suivantes :

• Pas plus de 110 pods par nœud
• Pas plus de 5 000 nœuds
• Pas plus de 150 000 pods au total
• Pas plus de 300 000 conteneurs au total

Vous pouvez faire évoluer votre cluster en ajoutant ou en supprimant des nœuds. La manière de procéder dépend du mode de déploiement de votre cluster.

Quotas de ressources des fournisseurs cloud

Pour éviter de rencontrer des problèmes de quotas chez les fournisseurs cloud lors de la création d’un cluster comportant de nombreux nœuds, il est recommandé de :

• Demander une augmentation de quota pour les ressources cloud telles que :
  • Instances de calcul
  • CPU
  • Volumes de stockage
  • Adresses IP utilisées
  • Jeux de règles de filtrage réseau
  • Nombre de load balancers
  • Sous-réseaux
  • Flux de logs
• Limiter les opérations de montée en charge du cluster en créant les nouveaux nœuds par lots, avec des pauses entre chaque lot, car certains fournisseurs cloud appliquent des limitations de débit sur la création d’instances.

Composants du plan de contrôle

Pour un grand cluster, vous devez disposer d’un plan de contrôle avec suffisamment de ressources de calcul et autres.

En général, il est recommandé d’exécuter une ou deux instances de plan de contrôle par zone de disponibilité, en commençant par un dimensionnement vertical, puis en passant à un dimensionnement horizontal lorsque les gains de performance deviennent faibles.

Vous devez exécuter au moins une instance par zone de disponibilité pour assurer la tolérance aux pannes. Les nœuds Kubernetes ne redirigent pas automatiquement le trafic vers les points de terminaison du plan de contrôle situés dans la même zone de défaillance ; cependant, votre fournisseur cloud peut proposer ses propres mécanismes pour cela.

Par exemple, avec un load balancer managé, vous pouvez configurer celui-ci pour diriger le trafic provenant du kubelet et des pods d’une zone de défaillance A uniquement vers les nœuds du plan de contrôle situés dans la même zone A. Si un nœud du plan de contrôle ou une zone entière devient indisponible, le trafic du plan de contrôle pour cette zone est alors redirigé entre zones. Exécuter plusieurs instances du plan de contrôle dans chaque zone réduit ce risque.

Stockage etcd

Pour améliorer les performances des grands clusters, vous pouvez stocker les objets Event dans une instance etcd dédiée séparée.

Lors de la création d’un cluster, vous pouvez (via des outils personnalisés) :

• démarrer et configurer une instance etcd supplémentaire
• configurer le serveur API pour l’utiliser pour le stockage des événements

Voir Exploiter des clusters etcd pour Kubernetes et Configurer un cluster etcd haute disponibilité avec kubeadm pour plus de détails sur la configuration et la gestion d’etcd pour un grand cluster.

Ressources des addons

Les limites de ressources Kubernetes permettent de réduire l’impact des fuites mémoire et d’autres comportements des pods et conteneurs sur les autres composants. Ces limites s’appliquent également aux ressources des addons comme elles s’appliquent aux charges de travail applicatives.

Par exemple, vous pouvez définir des limites CPU et mémoire pour un composant de logging :

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

Les limites par défaut des addons sont généralement basées sur l’expérience des clusters de petite ou moyenne taille. Dans les grands clusters, les addons consomment souvent plus de ressources que prévu. Sans ajustement, ils peuvent être constamment redémarrés en raison des limites mémoire, ou fonctionner avec de mauvaises performances à cause des restrictions CPU.

Pour éviter ces problèmes, lors de la création d’un cluster avec de nombreux nœuds, il est recommandé de :

• Certains addons sont scalés verticalement (une seule instance pour tout le cluster ou par zone de disponibilité). Dans ce cas, augmentez les requests et limits à mesure que le cluster grandit.
• De nombreux addons scalent horizontalement (plus de pods ajoutés), mais peuvent aussi nécessiter une augmentation légère des ressources dans les très grands clusters. Le Vertical Pod Autoscaler peut être utilisé en mode recommender pour proposer des valeurs.
• Certains addons s’exécutent en une instance par nœud via un DaemonSet (ex : collecte de logs). Ils peuvent également nécessiter un ajustement des ressources.

Priorisation des composants essentiels du cluster

Pour garantir que les composants essentiels du cluster (comme CoreDNS, metrics-server et autres addons critiques) soient planifiés avant les autres charges de travail et ne soient pas préemptés, ils doivent être exécutés avec une PriorityClass système, comme system-cluster-critical ou system-node-critical.

A suivre

• VerticalPodAutoscaler est une ressource personnalisée que vous pouvez déployer dans votre cluster pour vous aider à gérer les requests et limits des pods.
  En savoir plus sur le Vertical Pod Autoscaler et comment l’utiliser pour dimensionner les composants du cluster, y compris les addons critiques.

• Lire sur l’autoscaling des nœuds

• Le addon resizer vous aide à redimensionner automatiquement les addons en fonction de la taille de votre cluster.

2 - Exécution sur plusieurs zones

Cette page décrit l’exécution de Kubernetes sur plusieurs zones.

Contexte

Kubernetes est conçu pour qu’un seul cluster Kubernetes puisse fonctionner sur plusieurs zones de défaillance, généralement regroupées au sein d’une entité logique appelée région. Les principaux fournisseurs cloud définissent une région comme un ensemble de zones de défaillance (également appelées zones de disponibilité) qui fournissent un ensemble cohérent de fonctionnalités : dans une région, chaque zone expose les mêmes API et services.

Les architectures cloud typiques visent à réduire au maximum le risque qu’une panne dans une zone affecte également les services d’une autre zone.

Comportement du plan de contrôle

Tous les composants du plan de contrôle peuvent fonctionner comme un ensemble de ressources interchangeables, répliquées par composant.

Lors du déploiement d’un plan de contrôle Kubernetes, placez les réplicas des composants du plan de contrôle sur plusieurs zones de défaillance. Si la disponibilité est un critère important, sélectionnez au moins trois zones de défaillance et répliquez chaque composant du plan de contrôle (API server, scheduler, etcd, controller manager) sur au moins trois zones de défaillance. Si vous utilisez un cloud controller manager, vous devez également le répliquer dans toutes les zones sélectionnées.

Comportement des nœuds

Kubernetes répartit automatiquement les Pods des ressources de charge de travail (telles que Deployment ou StatefulSet) sur différents nœuds du cluster. Cette répartition permet de réduire l’impact des défaillances.

Lors de leur démarrage, les kubelets sur chaque nœud ajoutent automatiquement des labels à l’objet Node représentant ce kubelet dans l’API Kubernetes. Ces labels peuvent inclure des informations de zone (zone information).

Si votre cluster s’étend sur plusieurs zones ou régions, vous pouvez utiliser ces labels avec des contraintes de répartition topologique des Pods pour contrôler la distribution des Pods entre les domaines de défaillance : régions, zones et même nœuds spécifiques. Ces indications permettent au scheduler de placer les Pods de manière à améliorer la disponibilité et réduire le risque qu’une panne corrélée affecte l’ensemble de votre charge de travail.

Par exemple, vous pouvez définir une contrainte pour vous assurer que les 3 réplicas d’un StatefulSet sont répartis sur des zones différentes lorsque cela est possible. Cela peut être défini de manière déclarative sans avoir à spécifier explicitement les zones utilisées pour chaque workload.

Répartition des nœuds entre les zones

Le cœur de Kubernetes ne crée pas de nœuds pour vous ; vous devez le faire vous-même, ou utiliser un outil comme le Cluster API pour gérer les nœuds à votre place.

Avec des outils comme Cluster API, vous pouvez définir des ensembles de machines exécutées comme nœuds de travail répartis sur plusieurs domaines de défaillance, ainsi que des règles permettant de réparer automatiquement le cluster en cas de panne complète d’une zone.

Attribution manuelle des zones aux Pods

Vous pouvez appliquer des sélecteurs de nœuds aux Pods que vous créez, ainsi qu’aux templates de Pods dans les ressources de type Deployment, StatefulSet ou Job.

Accès au stockage par zone

Lors de la création de volumes persistants, Kubernetes ajoute automatiquement des labels de zone aux PersistentVolumes liés à une zone spécifique. Le scheduler s’assure ensuite, via le prédicat NoVolumeZoneConflict, que les pods utilisant un PersistentVolume donné sont planifiés uniquement dans la même zone que ce volume.

Notez que la manière d’ajouter ces labels dépend du fournisseur cloud et du provisionneur de stockage utilisé. Consultez toujours la documentation de votre environnement pour garantir une configuration correcte.

Vous pouvez spécifier une StorageClass qui définit les domaines de défaillance (zones) dans lesquels le stockage peut être créé. Pour en savoir plus, consultez les topologies autorisées.

Réseau

Kubernetes n’intègre pas nativement de prise en charge du réseau par zone. Vous pouvez utiliser un plugin réseau pour configurer la connectivité du cluster, et cette solution peut inclure des éléments dépendant des zones. Par exemple, si votre fournisseur cloud prend en charge les Services de type LoadBalancer, le load balancer peut diriger le trafic uniquement vers les Pods situés dans la même zone que l’instance traitant la connexion.

Consultez la documentation de votre fournisseur cloud pour plus de détails.

Pour les déploiements sur site ou personnalisés, des considérations similaires s’appliquent. Le comportement des Service et Ingress, notamment en matière de zones, dépend de la configuration de votre cluster.

Récupération en cas de panne

Lors de la configuration du cluster, vous devez également envisager la manière dont votre système peut restaurer le service si toutes les zones d’une région deviennent indisponibles simultanément. Par exemple, votre système dépend-il de la présence d’au moins un nœud actif dans une zone ?

Assurez-vous que les opérations de réparation critiques ne dépendent pas de la disponibilité d’un nœud sain dans le cluster. Par exemple, si tous les nœuds sont défaillants, vous devrez peut-être exécuter une tâche de réparation avec une tolérance spéciale afin de permettre la remise en service d’au moins un nœud.

Kubernetes ne fournit pas de solution complète à ce problème, mais il s’agit d’un point important à prendre en compte.

A suivre

Pour comprendre comment le scheduler place les Pods dans un cluster en respectant les contraintes configurées, consultez la section Planification et éviction.

3 - Valider la configuration du nœud

Test de conformité des nœuds

Le test de conformité des nœuds est un framework de test conteneurisé qui fournit une vérification système ainsi qu’un test fonctionnel d’un nœud. Ce test permet de vérifier si le nœud respecte les exigences minimales de Kubernetes ; un nœud qui réussit ce test est considéré comme apte à rejoindre un cluster Kubernetes.

Prérequis du nœud

Pour exécuter le test de conformité des nœuds, un nœud doit satisfaire les mêmes prérequis qu’un nœud Kubernetes standard. Au minimum, le nœud doit disposer des daemons suivants installés :

• Des runtimes de conteneurs compatibles CRI tels que Docker, containerd et CRI-O
• kubelet

Exécution du test de conformité des nœuds

Pour exécuter le test de conformité des nœuds, procédez comme suit :

1. Déterminez la valeur de l’option --kubeconfig du kubelet ; par exemple : --kubeconfig=/var/lib/kubelet/config.yaml.

   Comme le framework de test démarre un plan de contrôle local pour tester le kubelet, utilisez http://localhost:8080 comme URL de l’API server.

   Vous pouvez également utiliser certains autres paramètres en ligne de commande du kubelet :

   • --cloud-provider : si vous utilisez --cloud-provider=gce, vous devez supprimer ce flag pour exécuter le test.

2. Exécutez le test de conformité des nœuds avec la commande suivante :

   # $CONFIG_DIR est le chemin des manifests pods du kubelet.
   # $LOG_DIR est le répertoire de sortie des logs du test.
   sudo docker run -it --rm --privileged --net=host \
     -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
     registry.k8s.io/node-test:0.2
   

Exécution du test de conformité des nœuds sur d’autres architectures

Kubernetes fournit également des images Docker de test de conformité des nœuds pour d’autres architectures :

Exécution de tests sélectionnés

Pour exécuter des tests spécifiques, remplacez la variable d’environnement FOCUS par l’expression régulière des tests que vous souhaitez exécuter.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Exécute uniquement le test MirrorPod
  registry.k8s.io/node-test:0.2

Le test de conformité des nœuds est une version conteneurisée des tests e2e des nœuds. Par défaut, il exécute tous les tests de conformité.

En théorie, vous pouvez exécuter n’importe quel test e2e des nœuds si vous configurez correctement le conteneur et montez les volumes requis. Cependant, il est fortement recommandé de n’exécuter que les tests de conformité, car l’exécution de tests non conformes nécessite une configuration beaucoup plus complexe.

Limitations

• Le test laisse certaines images Docker sur le nœud, notamment l’image du test de conformité des nœuds ainsi que les images des conteneurs utilisés dans les tests fonctionnels.
• Le test laisse des conteneurs arrêtés sur le nœud. Ces conteneurs sont créés pendant les tests fonctionnels.

4 - Application des normes de sécurité des Pods

Cette page présente une vue d’ensemble des bonnes pratiques pour l’application des Pod Security Standards.

Utiliser le contrôleur d’admission Pod Security intégré

Le contrôleur d’admission Pod Security a vocation à remplacer les PodSecurityPolicies désormais obsolètes.

Configurer tous les namespaces du cluster

Les namespaces sans aucune configuration doivent être considérés comme des failles importantes dans le modèle de sécurité de votre cluster. Nous recommandons de prendre le temps d’analyser les types de charges de travail présents dans chaque namespace et, en vous appuyant sur les Pod Security Standards, de définir un niveau de sécurité approprié pour chacun d’eux. Les namespaces non étiquetés doivent uniquement indiquer qu’ils n’ont pas encore été évalués.

Dans le cas où toutes les charges de travail de tous les namespaces ont les mêmes exigences de sécurité, nous proposons un exemple montrant comment appliquer les labels PodSecurity en masse.

Appliquer le principe du moindre privilège

Dans un monde idéal, chaque pod dans chaque namespace respecterait les exigences de la politique restricted. Cependant, ce n’est ni possible ni pratique, car certaines charges de travail nécessitent des privilèges élevés pour des raisons légitimes.

• Les namespaces autorisant des charges de travail privileged doivent mettre en place et appliquer des contrôles d’accès appropriés.
• Pour les charges de travail exécutées dans ces namespaces permissifs, maintenez une documentation décrivant leurs exigences de sécurité spécifiques. Si possible, cherchez à restreindre davantage ces exigences.

Adopter une stratégie multi-modes

Les modes audit et warn du contrôleur d’admission des Pod Security Standards facilitent la collecte d’informations de sécurité importantes sur vos pods sans perturber les charges de travail existantes.

Il est recommandé d’activer ces modes pour tous les namespaces, en les configurant au niveau et à la version ciblés que vous souhaitez finalement appliquer (enforce). Les avertissements et annotations d’audit générés durant cette phase peuvent vous guider vers cet objectif. Si vous attendez des développeurs qu’ils adaptent leurs charges de travail au niveau souhaité, activez le mode warn. Si vous prévoyez d’utiliser les logs d’audit pour suivre et piloter ces changements, activez le mode audit.

Une fois le mode enforce défini au niveau souhaité, ces modes restent utiles de plusieurs façons :

• En configurant warn au même niveau que enforce, les utilisateurs recevront des avertissements lorsqu’ils tenteront de créer des Pods (ou des ressources contenant des templates de Pod) non conformes. Cela les aidera à corriger leurs ressources.
• Dans les namespaces où enforce est fixé à une version spécifique non la plus récente, configurer audit et warn au même niveau que enforce, mais avec la version latest, permet de détecter les paramètres autrefois autorisés mais désormais déconseillés selon les bonnes pratiques actuelles.

Alternatives tierces

D’autres solutions permettant d’appliquer des profils de sécurité sont en cours de développement dans l’écosystème Kubernetes :

• Kubewarden
• Kyverno
• OPA Gatekeeper

Le choix entre une solution intégrée (comme le contrôleur PodSecurity) et un outil tiers dépend entièrement de votre contexte. Lors de l’évaluation d’une solution, la confiance dans votre chaîne d’approvisionnement est essentielle. Dans tous les cas, utiliser l’une de ces approches reste préférable à l’absence totale de contrôle.

5 - Certificats PKI et exigences

Kubernetes nécessite des certificats PKI pour l’authentification via TLS. Si vous installez Kubernetes avec kubeadm, les certificats requis par votre cluster sont générés automatiquement. Vous pouvez également générer vos propres certificats — par exemple, pour mieux sécuriser vos clés privées en évitant de les stocker sur le serveur API. Cette page explique les certificats nécessaires à votre cluster.

Utilisation des certificats par votre cluster

Kubernetes utilise la PKI pour les opérations suivantes :

Certificats serveur

• Certificat serveur pour le point de terminaison du serveur API
• Certificat serveur pour le serveur etcd
• Certificats serveur pour chaque kubelet (chaque nœud exécute un kubelet)
• Certificat serveur optionnel pour le front-proxy

Certificats client

• Certificats client pour chaque kubelet, utilisés pour s’authentifier auprès du serveur API en tant que client de l’API Kubernetes
• Certificat client pour chaque serveur API, utilisé pour s’authentifier auprès d’etcd
• Certificat client pour le controller manager afin de communiquer de manière sécurisée avec le serveur API
• Certificat client pour le scheduler afin de communiquer de manière sécurisée avec le serveur API
• Certificats client, un pour chaque nœud, pour que kube-proxy s’authentifie auprès du serveur API
• Certificats client optionnels pour les administrateurs du cluster afin de s’authentifier auprès du serveur API
• Certificat client optionnel pour le front-proxy

Certificats serveur et client du kubelet

Pour établir une connexion sécurisée et s’authentifier auprès du kubelet, le serveur API nécessite une paire certificat/clé client.

Dans ce scénario, deux approches sont possibles :

• Certificats partagés : le kube-apiserver peut utiliser la même paire certificat/clé que celle utilisée pour authentifier ses clients. Cela signifie que les certificats existants, comme apiserver.crt et apiserver.key, peuvent être utilisés pour communiquer avec les serveurs kubelet.

• Certificats distincts : le kube-apiserver peut générer une nouvelle paire certificat/clé client pour s’authentifier auprès des serveurs kubelet. Dans ce cas, un certificat distinct nommé kubelet-client.crt ainsi que sa clé privée kubelet-client.key sont créés.

etcd implémente également le TLS mutuel pour authentifier les clients et les pairs.

Emplacement des certificats

Si vous installez Kubernetes avec kubeadm, la plupart des certificats sont stockés dans /etc/kubernetes/pki. Tous les chemins de cette documentation sont relatifs à ce répertoire, à l’exception des certificats des comptes utilisateurs que kubeadm place dans /etc/kubernetes.

Configuration manuelle des certificats

Si vous ne souhaitez pas que kubeadm génère les certificats requis, vous pouvez les créer en utilisant une seule autorité de certification (CA) racine ou en fournissant tous les certificats. Voir Certificats pour plus de détails. Voir également Gestion des certificats avec kubeadm.

CA racine unique

Vous pouvez créer une CA racine unique, contrôlée par un administrateur. Cette CA peut ensuite créer plusieurs CA intermédiaires.

CA requises :

En plus des autorités de certification mentionnées ci-dessus, il est également nécessaire d'obtenir une paire de clés publique/privée pour la gestion des comptes de service : les fichiers sa.key et sa.pub. L'exemple suivant illustre les fichiers de clé et de certificat de l'autorité de certification présentés dans le tableau précédent :

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

Tous les certificats

Vous pouvez générer tous les certificats vous-même si vous ne souhaitez pas copier les clés privées de la CA.

Certificats requis :

où kind correspond à une ou plusieurs utilisations de la clé x509, également documentées dans le fichier .spec.usages d'une CertificateSigningRequest type :

Chemins des certificats

Les certificats doivent être placés dans un chemin recommandé (comme utilisé par kubeadm). Les chemins doivent être spécifiés à l’aide des arguments indiqués, quel que soit leur emplacement.

Les mêmes considérations s’appliquent à la paire de clés des comptes de service :

L’exemple suivant illustre les chemins des fichiers issus des tableaux précédents que vous devez fournir si vous générez vous-même l’ensemble de vos clés et certificats :

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

Configuration des certificats pour les comptes utilisateurs

Vous devez configurer manuellement les comptes administrateurs et les comptes de service :

1. Pour chaque configuration, générez une paire certificat/clé x509 avec le Common Name (CN) et l’Organization (O) indiqués.

2. Exécutez kubectl comme suit pour chaque configuration :

   KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
   KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
   KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
   KUBECONFIG=<filename> kubectl config use-context default-system
   

   Ces fichiers sont utilisés comme suit :

Les fichiers suivants illustrent les chemins complets des fichiers listés dans le tableau précédent :

/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf