Partager via

Gouverner des solutions de plateforme d’application moderne

  • Article

Le Cloud Adoption Framework fournit une méthodologie permettant d’améliorer de façon systématique et incrémentielle la gouvernance de votre portefeuille Cloud. Cet article explique comment vous pouvez étendre votre approche de gouvernance à des clusters Kubernetes déployés sur Azure ou d’autres clouds publics ou privés.

Fondation de gouvernance initiale

La gouvernance commence par une fondation de gouvernance initiale souvent appelée MVP de gouvernance. Cette fondation déploie les produits Azure de base requis pour assurer la gouvernance dans votre environnement Cloud.

La fondation de gouvernance initiale se concentre sur les aspects suivants de la gouvernance :

  • Réseau hybride et connectivité de base.
  • Contrôle d’accès en fonction du rôle (RBAC) Azure pour l’identité et le contrôle d’accès.
  • Normes d’attribution de noms et de marquage pour une identification cohérente des ressources.
  • Organisation des ressources à l’aide de groupes de ressources, d’abonnements et de groupes d’administration.
  • Utilisez Azure Policy pour appliquer des stratégies de gouvernance.

Ces caractéristiques de la base de gouvernance initiale peuvent être utilisées pour régir les instances de plateforme d’application moderne. Mais tout d’abord, vous devez ajouter quelques composants à la fondation initiale pour appliquer Azure Policy à vos conteneurs. Une fois la configuration effectuée, vous pouvez utiliser Azure Policy et votre fondation de gouvernance initiale pour régir les types de conteneurs suivants :

Se développer sur les disciplines de gouvernance

La fondation de gouvernance initiale permet de développer plusieurs disciplines de gouvernance afin de garantir une approche de déploiement cohérente et stable sur l’ensemble de vos instances Kubernetes.

La gouvernance des clusters Kubernetes peut être examinée avec cinq perspectives distinctes.

Gouvernance des ressources Azure

Le premier facteur est le point de vue des ressources Azure. Veillez à ce que tous les clusters respectent les exigences de votre organisation. Cela comprend les concepts tels que la topologie de réseau, le cluster privé, les rôles RBAC Azure pour les équipes SRE, les paramètres de diagnostic, la disponibilité des régions, les considérations relatives aux pools de nœuds, la gouvernance Azure Container Registry, les options d’Azure Load Balancer, les modules complémentaires AKS, les paramètres de diagnostic, etc. Cette gouvernance garantit la cohérence de l’apparence et de la topologie des clusters de vos organisations. Cela doit également s’étendre à la publication du démarrage du déploiement de cluster, comme les agents de sécurité à installer et la façon dont ils doivent être configurés.

Les clusters Snowflake sont difficiles à gérer dans toutes les capacités centrales. Réduisez les incohérences entre les clusters afin que les stratégies puissent s’appliquer uniformément et les clusters anormaux soient déconseillés et détectables. Cela peut également inclure des technologies utilisées pour déployer les clusters, comme ARM, Bicep ou Terraform.

Azure Policy appliqué au niveau des groupes de gestion/abonnements peut contribuer à la réalisation d’un grand nombre de ces considérations, mais pas toutes.

Gouvernance de la charge de travail Kubernetes

Étant donné que Kubernetes est lui-même une plateforme, le deuxième point concerne la gouvernance au sein d’un cluster. Cela inclut des éléments tels que l’aide sur les espaces de noms, les stratégies réseau, les accès RBAC Kubernetes, les limites et les quotas. Il s’agit d’une gouvernance appliquée surtout aux charges de travail, et dans une moindre mesure, au cluster. Chaque charge de travail sera unique, puisqu’elle résout des problèmes d’entreprise différents et sera implémentée de différentes façons avec différentes technologies. Il se peut qu’il n’y ait pas beaucoup de pratiques de gouvernance « taille unique », mais vous devez envisager une gouvernance sur la création/consommation d’artefacts OCI, les exigences de chaîne d’approvisionnement, l’utilisation du registre de conteneurs publics, le processus de mise en quarantaine d’images, la gouvernance de pipeline.

Envisagez la standardisation autour des outils et des modèles communs, si possible. Insérez des recommandations sur des technologies telles que Helm, le maillage de service, les contrôleurs d’entrée, les opérateurs GitOps, les volumes persistants, etc. L’utilisation d’une identité managée par Pod et des secrets d’approvisionnement à partir de Key Vault est également incluse ici.

Suscitez de fortes attentes autour de l’accès à la télémétrie afin de garantir que les propriétaires de la charge de travail disposent d’un accès approprié aux mesures et aux données dont ils ont besoin pour améliorer leur produit, tout en veillant à ce que les opérateurs de clusters aient accès au système télémétrique pour améliorer leur offre de services. Les données doivent souvent être corrélées entre les deux ; vous devez donc vous assurer que les stratégies de gouvernance sont en place pour garantir un accès approprié si nécessaire.

La mise en application d’Azure Policy pour AKS au niveau du cluster peut vous aider à fournir certaines d’entre elles, mais pas toutes.

Rôles d’opérateur de cluster (DevOps, SRE)

Le troisième point concerne la gouvernance autour des rôles d’opérateur de cluster. Comment les équipes SRE interagissent-elles avec les clusters ? Quelle est la relation entre cette équipe et l’équipe de charge de travail ? Sont-elles identiques ? Les opérateurs de cluster doivent disposer d’un manuel clairement défini pour les activités de triage de cluster, telles que la façon dont ils accèdent aux clusters, leur emplacement d’accès aux clusters, ainsi que les autorisations dont ils disposent sur les clusters et quand ces autorisations sont affectées. Assurez-vous que toutes les distinctions sont indiquées dans la documentation de gouvernance, la stratégie et les supports de formation autour de l’opérateur de charge de travail et de l’opérateur de cluster dans ce contexte. En fonction de votre organisation, elles peuvent être identiques.

Cluster par charge de travail ou plusieurs charges de travail par cluster

Le quatrième point concerne la gouvernance de l’architecture mutualisée. Autrement dit, les clusters contiennent un « regroupement » d’applications appartenant, par définition, à la même équipe de charge de travail et représentent un ensemble unique de composants de charge de travail associés. Ou les clusters doivent être, par conception, multilocataires par nature, avec plusieurs charges de travail et propriétaires de charges de travail distincts ; exécutés et régis comme une offre de service managé au sein de l’organisation. La stratégie de gouvernance est particulièrement différente pour chacun d’eux et, par conséquent, vous devez décider que la stratégie choisie est appliquée. Si vous devez prendre en charge les deux modèles, assurez-vous que votre plan de gouvernance est clairement défini pour savoir quelles stratégies s’appliquent à quels types de clusters.

Ce choix aurait dû être fait au cours de la phase de stratégie, car il a un impact significatif sur le personnel, la budgétisation et l’innovation.

Maintenir les efforts actuels

Le cinquième point concerne les opérations, telles que l’actualisation des images de nœud (mise à jour corrective) et le contrôle de version Kubernetes. Qui est responsable des mises à niveau des images de nœud, du suivi des correctifs appliqués, du suivi et du regroupement des plans de correction pour les vulnérabilités et menaces de sécurité courantes dans Kubernetes et AKS ? Les équipes de la charge de travail doivent être impliquées dans la validation de leur solution sur les mises à niveau de cluster, et si vos clusters ne sont pas à jour, ils ne seront plus pris en charge par Azure. La mise en place d’une gouvernance forte autour des efforts pour « rester à jour » est essentielle pour AKS, et plus encore pour la plupart des autres plateformes d’Azure. Cela nécessitera une relation de travail très étroite avec les équipes d’applications et un temps dédié, au moins mensuellement, pour la validation de la charge de travail afin de garantir la disponibilité des clusters. Assurez-vous que toutes les équipes s’engagent avec Kubernetes comprennent les exigences et le coût de ce travail en cours, qui durera tant qu’elles se trouveront sur la plateforme.

Base de référence de la sécurité

Les meilleures pratiques suivantes peuvent être ajoutées à votre ligne de base de sécurité, afin de prendre en compte la sécurité de vos clusters AKS :

Identité

Il existe de nombreuses meilleures pratiques que vous pouvez appliquer à votre ligne de base d’identité pour garantir la cohérence de la gestion des identités et des accès sur vos clusters Kubernetes :

Étape suivante : Gérer des solutions de plateforme d’application moderne

Les articles vous aideront à trouver des conseils sur des points spécifiques du parcours d’adoption du cloud pour réussir dans le scénario d’adoption du cloud.