Comment établir une stratégie de gouvernance pour Kubernetes

Mettre en œuvre la gouvernance de Kubernetes

Il s’agit d’appliquer des politiques d’allocation, de déploiement, de redéploiement et de mise à l’échelle des clusters Kubernetes. Ces actions peuvent être définies en réponse à des réglementations externes, à des politiques d’entreprise, ou à des besoins de performances, de haute disponibilité ou de qualité de service.

Lorsque la gouvernance de Kubernetes implique une justification du budget IT, ces règles peuvent également servir à garantir le respect de l’analyse de rentabilité.

Les trois éléments de la stratégie de gouvernance

Trois éléments interviennent dans une stratégie de mise en œuvre de la gouvernance de Kubernetes : les cibles, le périmètre et les directives stratégiques.

1. Les cibles sont les objectifs spécifiques que la stratégie doit atteindre. Les cibles directes, les objectifs de gouvernance et les cibles dérivées représentent les mesures internes que les équipes IT doivent prendre pour que l’organisation atteigne ces cibles définies. L’équipe opérationnelle (Ops) définit généralement ces cibles comme la première étape de la création d’un cadre de gouvernance.
2. Le champ d’application est l’ensemble des éléments auquel les politiques doivent être appliquées pour répondre aux cibles, et doit concerner tous les composants visibles de Kubernetes. De nombreuses organisations dérivent le champ d’application depuis le sommet, en commençant par les divisions organisationnelles et les sites.
3. Les directives de politique utilisent les capacités de Kubernetes pour adresser les politiques de gouvernance à travers les périmètres spécifiés aux cibles directes et dérivées. Les directives de politique constituent l’étape finale de l’établissement de la gouvernance de Kubernetes. En général, ces directives représentent le principal objectif des projets de gouvernance.

Les types de cibles de gouvernance de Kubernetes

Les organisations peuvent répartir les cibles de gouvernance Kubernetes dans les catégories suivantes :

• La sécurité
• Les contrôles des images de conteneurs
• Les contrôles et les configurations du réseau
• Le déploiement, le redéploiement et la mise à l’échelle des applications.

Les équipes attribuent un champ d’application aux cibles de chaque catégorie. Les administrateurs IT utilisent les combinaisons de cibles et de champ d’application pour créer des directives spécifiques.

La gouvernance de la sécurité pour Kubernetes est normalement appliquée à l’aide d’outils tiers, tels que Open Policy Agent, KubeLinter, kube-bench et cube-hunter. Les maillages de services comme Istio peuvent également être utilisés pour les microservices conteneurisés. Sélectionnez les outils avec soin, car certains outils de sécurité peuvent également appliquer des politiques dans d’autres catégories cibles. En règle générale, moins il y a d’outils, mieux c’est.

Les contrôles de l’image de conteneur concernent le processus de développement et de test, ainsi que les pratiques nécessaires pour faire passer le logiciel d’un environnement de test à un autre en production. La gouvernance est appliquée ici par le biais des outils associés et des processus globaux de développement et de test.

La plupart des organisations appliquent des contraintes plus granulaires, sur le développement et les tests, que celles qui sont normalement considérées comme faisant partie de la gouvernance. Commencez par des exigences de gouvernance spécifiques. Par exemple, il peut être intéressant de mettre en place des flux de test particuliers, ainsi qu’un nombre d’avertissements attendus. Ces exigences peuvent être affinées avec des règles de développement supplémentaires afin de créer un cadre qui fonctionne pour la gouvernance, ainsi que pour le développement et le contrôle de la qualité des logiciels.

L’outil de réseau virtuel choisi doit être le principal mécanisme de contrôle du réseau de l’orchestrateur. Kubernetes présume que les nœuds d’un cluster sont mutuellement adressables à partir de l’espace d’adressage du cluster, mais tout ce qui est adressé de l’extérieur doit être exposé explicitement.

La décision d’exposer un élément ou un autre est prise lors de la conception de l’application. Pour améliorer sa sécurité, il est recommandé de ne rendre disponibles que les éléments nécessaires. Il est possible de contrôler l’adressabilité au sein d’un cluster en utilisant des fonctionnalités de réseau virtuel. Attention, car cela peut être source de confusion lors de la maintenance du cluster. La pratique doit être documentée avec soin.

Les politiques de configuration limitent les ressources de cluster que les organisations ou les individus peuvent allouer dans le cloud lorsqu’il y a un coût incrémental à prendre en compte. Elles peuvent également empêcher les équipes d’utiliser plus de ressources de calcul et de stockage qu’elles ne sont en droit de le faire. Ce type de contrôle est accessible directement via les fonctionnalités de gestion de Kubernetes.

Les caractéristiques de Kubernetes

Le déploiement, le redéploiement et la mise à l’échelle des applications sont les catégories de politiques Kubernetes les plus familières. Elles gèrent la question fondamentale de l’orchestration : comment les pods sont alloués aux nœuds et comment ces allocations évoluent dans le temps.

Quatre fonctionnalités Kubernetes sont généralement impliquées dans l’allocation des pods :

• Les affinités, qui décrivent les attracteurs, attirent les pods vers des nœuds particuliers. Cela permet de spécifier les composants applicatifs connexes à garder ensemble pour des raisons de performance.
• Les marquages (« taints » en anglais) – contrairement aux affinités – repoussent les pods des nœuds. En concordance avec un mécanisme de tolérance, cela permet de s’assurer que des pods ne sont pas associés à un nœud inapproprié. Ceci est utile lorsque les réglementations locales sur les types de données et de contenu rendent indésirable l’hébergement d’informations sur un nœud particulier. L’on peut aussi empêcher les applications à faible priorité d’utiliser les ressources nécessaires aux applications à plus haute priorité.
• Les tolérances permettent un contrôle granulaire des allocations de pods aux nœuds. Les pods ayant une tolérance pour un marquage particulier sont les seuls qui peuvent être programmés sur le nœud associé. Cela permet une application graduelle des taints, plutôt que de forcer une décision binaire, de type oui ou non.
• L’autoscaling horizontal des pods est une fonctionnalité de Kubernetes qui contrôle la réponse d’un pod donné à la demande. En cas de charge, un pod donné peut s’étendre en affectant davantage de nœuds aux répliques du pod, ou se rétracter en supprimant les affectations de répliques. Cela permet de contrôler si une application donnée subit des coûts variables pour faire correspondre la charge de travail aux ressources, ce qui peut facilement conduire à des dépassements de coûts massifs.

Lorsqu’elles travaillent avec l’une de ces catégories de politiques, les équipes informatiques doivent prendre en compte tous leurs objectifs de gouvernance afin d’éviter les redondances ou les contradictions. La cohérence est essentielle au succès de toute stratégie de gouvernance et au maintien de Kubernetes en particulier.