Partager via

Disciplines CI/CD et GitOps avec Kubernetes avec Azure Arc

  • Article

En tant que construction native Cloud, Kubernetes nécessite une approche native Cloud du déploiement et des opérations. Avec GitOps, vous déclarez l’état souhaité de vos déploiements basés sur une application dans des fichiers qui sont stockés dans des référentiels Git. Les applications ont des objets Kubernetes qu’elles doivent exécuter, notamment des déploiements, des programmes de mise à l’échelle automatique des pods horizontaux, des services et ConfigMaps. Les opérateurs Kubernetes s’exécutent dans les clusters et rapprochent continuellement chaque état du cluster avec l’état souhaité déclaré dans votre référentiel Git. Ces opérateurs tirent (pull) les fichiers de vos référentiels Git et appliquent l’état souhaité à vos clusters. Les opérateurs s’assurent également en continu que votre cluster reste à l’état souhaité.

L’implémentation de GitOps offre les avantages suivants :

  • Améliorez la visibilité globale de l’état et de la configuration de votre cluster Kubernetes.
  • Disposez d’un simple historique d’audit et de version des modifications de votre cluster via l’historique des modifications Git qui indique l’utilisateur ayant apporté des modifications, ainsi que la date et le motif de celles-ci.
  • Corrigez automatiquement la dérive éventuelle de votre cluster.
  • Restaurez votre configuration Kubernetes à partir d’une version précédente via les commandes Restaurer Git ou Rétablir Git. La recréation du déploiement de cluster pour les scénarios de récupération d’urgence devient également un processus rapide et simple, car la configuration du cluster Kubernetes souhaitée est stockée dans Git.
  • Améliorez la sécurité en réduisant le nombre de comptes de service nécessaires pour être autorisé à effectuer un déploiement sur votre cluster.
  • Implémentez un pipeline CI/CD pour le déploiement des applications sur votre cluster.

GitOps sur Kubernetes avec Azure Arc utilise Flux, un ensemble d’outils open source populaire. Flux est un opérateur qui automatise les déploiements de configuration GitOps dans votre cluster. Flux prend en charge les sources de fichiers courantes (dépôts Git, dépôts Helm, compartiments) et les types de modèles (YAML, Helm et Kustomize). Flux prend également en charge la gestion des dépendances multilocataire et de déploiement, entre autres fonctionnalités.

Architecture

Les diagrammes suivants illustrent une architecture de référence conceptuelle qui met en évidence le provisionnement et l’installation de l’extension de cluster Flux dans un cluster, le processus de configuration GitOps pour un cluster Kubernetes avec Azure Arc et le flux GitOps.

Processus de provisionnement de l’extension de cluster Flux v2 :

Diagram that shows Flux extension installation.

Processus de configuration GitOps :

Diagram that shows how to configure GitOps.

Flux GitOps montrant une mise à jour de l’application :

Diagram that shows a typical GitOps workflow.

Considérations sur la conception

Passez en revue les considérations de conception suivantes quand vous prévoyez d’implémenter GitOps pour Kubernetes avec Azure Arc.

Configuration

Prenez en compte les différentes couches de configuration dans votre cluster Kubernetes et les responsabilités que leur provisionnement implique.

Couches de configuration

  • Configuration de l’application nécessaire pour déployer une application et les objets Kubernetes associés sur le cluster, comme les ressources Déploiement, Service, HPA et ConfigMap. Les configurations d’application s’appliquent généralement à une configuration GitOps au niveau de l’espace de noms. Les composants d’application doivent donc être configurés uniquement au sein d’un même espace de noms.
  • Configuration à l’échelle du cluster pour la création d’objets Kubernetes comme Namespaces, ServiceAccounts, Roles et RoleBindings, ainsi que d’autres stratégies à l’échelle du cluster.
  • Composants à l’échelle du cluster comme un contrôleur d’entrée, la supervision et la pile de sécurité, ainsi que divers agents qui fonctionnent sur le cluster.

Responsabilités

  • Les développeurs d’applications sont chargés d’envoyer (push) leur code source, de déclencher des builds et de créer des images conteneur.
  • Les opérateurs d’application sont chargés de la maintenance des référentiels d’applications, des configurations, des variables d’environnement, des graphiques Helm spécifiques à l’application, des Kustomizations, etc.
  • Les opérateurs de cluster sont chargés de la configuration de la ligne de base de votre cluster. Ils s’occupent généralement de la configuration des composants et des stratégies à l’échelle du cluster. Ils gèrent un ou plusieurs répertoires Git contenant des outils d’infrastructure courants comme Namespaces, Service Accounts, RoleBindings, les CRD, les stratégies à l’échelle du cluster, les composants d’entrée, etc.

Structure du dépôt

Prenez en compte les compromis lors du choix de la structure du référentiel Git. La structure choisie définit l’état de votre cluster Kubernetes, qui comprend des applications et des composants à l’échelle du cluster. En fonction des responsabilités et des personnages que vous identifiez, il est important de prendre en compte toute collaboration ou l’indépendance de l’équipe souhaitée qui sont nécessaires pour les différentes options de structure du référentiel.

Vous pouvez utiliser toute stratégie de création de branche souhaitée pour vos référentiels de code, car elle sert uniquement à votre processus CI (intégration continue).

Pour vos référentiels de configuration GitOps, tenez compte des stratégies suivantes en fonction des besoins métier, de la taille et des outils de votre organisation :

  • Référentiel unique (branche par environnement) :
    • Offre une flexibilité maximale pour contrôler les stratégies et autorisations Git dans chaque branche représentant un environnement.
    • L’inconvénient de cette solution est que la configuration commune n’est partagée avec aucun environnement, car les outils comme Kustomize ne fonctionnent pas avec les branches GIT.
  • Référentiel unique (répertoire par environnement) :
    • Vous pouvez implémenter cette approche à l’aide d’outils comme Kustomize, ce qui vous permet de définir une configuration de base pour les objets Kubernetes et un ensemble d’artefacts (par exemple des correctifs) pour votre environnement qui remplace les configurations dans la base.
    • Cette approche permet de réduire les fichiers YAML dupliqués dans chaque environnement, mais elle réduit également la séparation de la configuration entre les différents environnements. Une seule modification apportée dans le référentiel peut affecter tous les environnements simultanément. Il est donc nécessaire de bien comprendre et de prendre en compte l’effet des modifications des répertoires de base.
  • Plusieurs référentiels (chacun servant un objectif spécifique) :
    • Cette solution permet de séparer les référentiels de configuration pour chaque application, équipe, couche ou locataire.
    • Ainsi, les équipes disposent d’un contrôle plus indépendant. Toutefois, vous vous éloignez du principe consistant à définir l’état de votre système dans un référentiel unique afin d’améliorer la configuration centrale, la visibilité et le contrôle des déploiements sur un cluster.
    • La configuration de plusieurs référentiels doit être envisagée pour les besoins multilocataires. Un contrôle d’accès en fonction du rôle (RBAC) et une sécurité sont intégrés pour limiter la configuration qu’une équipe/locataire affectée à un référentiel spécifique peut appliquer, comme l’autorisation de déploiement sur certains espaces de noms uniquement.

Découvrez d’autres manières de structurer votre référentiel dans le Guide consacré à Flux.

Configuration de l’application et de la plateforme

Les opérateurs de plateforme et les opérateurs d’application disposent de plusieurs options pour gérer la configuration Kubernetes :

  • Les fichiers YAML Kubernetes bruts qui représentent les spécifications YAML pour chaque objet d’API Kubernetes que vous déployez peuvent fonctionner correctement dans des environnements uniques. Les fichiers YAML bruts présentent l’inconvénient que la personnalisation devient difficile quand vous commencez à incorporer plusieurs environnements, car vous devez alors dupliquer les fichiers YAML et il n’existe aucune bonne méthode de réutilisation.
  • Helm est un outil de gestion de package pour les objets Kubernetes. Il s’agit d’une option valide que les opérateurs de cluster peuvent utiliser pour installer des applications du commerce. Veillez à ne pas trop utiliser le templating en tant qu’outil de gestion de la configuration pour les applications internes, car la gestion peut devenir compliquée à mesure que la taille de vos modèles augmente.
    • Si vous utilisez Helm, Flux inclut un contrôleur Helm qui vous permet de gérer de manière déclarative les versions de Helm Chart avec des manifestes Kubernetes. Vous pouvez créer un objet HelmRelease pour gérer ce processus.
  • Kustomize est un outil de gestion de la configuration native Kubernetes qui permet de personnaliser la configuration de l’application sans modèle.
    • Si vous utilisez Kustomize, Flux inclut un contrôleur Kustomize spécialisé dans l’exécution de pipelines de livraison continue pour l’infrastructure et des charges de travail définies avec des manifestes Kubernetes et assemblés avec Kustomize. Vous pouvez créer un objet Kustomization pour gérer ce processus.
  • Avec Kubernetes avec Azure Arc, vous pouvez utiliser une liste des extensions disponibles gérées et prises en charge par Microsoft au lieu de gérer vous-même le cycle de vie et la prise en charge des composants. Ces extensions sont managées via Azure Resource Manager. Certaines de ces extensions, comme le fournisseur de secrets Azure Key Vault, présentent des alternatives open source. La gestion des composants en dehors du processus de l’extension vous offre un meilleur contrôle sur les composants. Toutefois, cela entraîne une surcharge en termes de prise en charge et de gestion du cycle de vie.

Flux d’intégration continue et de livraison continue (CI/CD)

Les sections suivantes présentent des considérations concernant le processus de mise à jour de votre pipeline d’application et des composants.

Pipeline d’application

  • Prenez en compte le build de l’application, les tests et les validations que vous devez inclure dans votre processus CI (intégration continue). Il peut s’agir du linting et des tests liés à la sécurité, à l’intégration et aux performances, qui sont nécessaires pour créer une version finale (RC) pour les déploiements d’environnement.
  • Vous pouvez utiliser une méthode de déploiement traditionnelle de type envoi (push) pour la continuité entre une image conteneur de build dans votre pipeline CI et son déploiement dans un cluster en appelant l’API Kubernetes directement à partir de votre pipeline de déploiement.

Pour éviter les modifications manuelles de configuration de votre dépôt GitOps, vous pouvez exécuter votre pipeline CD en tant que compte de service, qui est autorisé à ouvrir des demandes de tirage (pull requests) ou à valider (commit) une nouvelle modification d’image conteneur directement dans un référentiel de configuration. Ces modifications permettent également de provisionner tous les objets YAML nécessaires à votre application.

Le diagramme de processus suivant illustre le processus CI d’application traditionnel incorporé avec des modifications prenant en charge GitOps.

Diagram that shows the standard GitOps process.

Processus de mise à jour des composants à l’échelle du cluster

  • Les opérateurs de cluster doivent gérer les composants à l’échelle du cluster. Cette opération ne provient probablement pas du pipeline CD utilisé pour déployer vos applications et services. Envisagez de définir un processus de promotion spécifique aux opérateurs de cluster pour vous assurer de la transition fluide des modifications d’un environnement à un autre.
  • Si vous devez appliquer une configuration GitOps identique à vos clusters Kubernetes avec Azure Arc à grande échelle, envisagez d’appliquer une stratégie Azure Policy qui est en mesure d’installer automatiquement l’extension Flux et d’appliquer votre configuration GitOps à des clusters Kubernetes avec Azure Arc existants ou à de nouveaux clusters à mesure qu’ils sont intégrés à Azure Arc.

Quand vous mettez à jour votre configuration, vous souhaitez probablement vérifier que les modifications ont été correctement appliquées à l’environnement souhaité. Vous pouvez définir des notifications dans Flux pour les intégrer à vos outils CI/CD, e-mail ou outils ChatOps et envoyer automatiquement des alertes concernant les modifications effectuées avec succès et les échecs de déploiement. Vous trouverez également des informations sur l’état du déploiement dans le portail Azure et via l’interface CLI k8s-configuration et l’API ARM.

Considérations relatives à la sécurité

Passez en revue les considérations de sécurité suivantes quand vous prévoyez d’implémenter GitOps pour Kubernetes avec Azure Arc.

Authentification du référentiel

  • Vous pouvez utiliser un référentiel Git public ou privé avec GitOps. Toutefois, en raison de la nature sensible des configurations Kubernetes, nous vous recommandons d’utiliser un référentiel privé qui nécessite l’authentification par clé SSH ou clé API. GitOps fonctionne également avec les référentiels Git qui sont accessibles uniquement au sein d’un réseau privé, à condition que votre cluster Kubernetes y ait accès. Cependant, cette configuration limite votre capacité à utiliser des fournisseurs Git basés sur le cloud, comme Azure Repos ou GitHub.
  • Les protocoles HTTPS et SSH offrent tous les deux une connexion fiable et sécurisée pour vous connecter à votre outil de contrôle de code source. Toutefois, le protocole HTTPS est souvent plus facile à configurer et il utilise un port qui vous oblige rarement à ouvrir davantage de ports dans vos pare-feu.

Sécurité des référentiels et des branches

  • Définissez les stratégies et autorisations de branche pour votre référentiel de configuration. Étant donné que votre dépôt Git devient l’élément central de vos déploiements Kubernetes, il est essentiel de configurer des autorisations pour contrôler les utilisateurs qui peuvent lire et mettre à jour le code dans une branche. Vous devez également implémenter des stratégies pour appliquer la gestion des changements et la qualité du code de votre équipe. Dans le cas contraire, votre flux de travail GitOps peut envoyer du code qui ne satisfait pas aux normes de votre organisation.
  • Les pipelines de demande de tirage (pull request) peuvent utiliser vos stratégies de branche pour valider la configuration YAML et/ou déployer des environnements de test selon vos besoins. Les portes permettent d’éliminer les erreurs de configuration et d’accroître la sécurité et la confiance du déploiement.
  • Quand vous attribuez des autorisations d’accès, tenez compte des utilisateurs de votre organisation qui doivent disposer d’un accès en lecture au référentiel, d’un accès pour la création de PR (demandes de tirage) et d’un accès d’approbation de PR (demandes de tirage).

Gestion des secrets

  • Évitez de stocker des secrets codés en texte brut ou en base64 dans votre référentiel Git. Envisagez plutôt d’utiliser un fournisseur de secrets externes comme Azure Key Vault. Le fournisseur Azure Key Vault pour le pilote Secrets Store CSI vous permet d’intégrer Azure Key Vault comme magasin de secrets à un cluster AKS (Azure Kubernetes Service) via un volume CSI. Ce service est disponible via l’extension Kubernetes avec Azure Arc. HashiCorp Vault est une alternative de fournisseur de secrets managé tiers.
  • Une autre façon de gérer les secrets consiste à utiliser les Secrets scellés Bitnami, qui existent depuis le début du concept de clés publiques et privées. Cela permet aux opérateurs de stocker un secret chiffré unidirectionnel à l’aide d’une clé publique dans Git, qui ne peut être déchiffrée que par le biais de la clé privée, elle-même utilisée par un contrôleur SealedSecrets s’exécutant dans votre cluster.

Recommandations de conception

Passez en revue les recommandations de conception suivantes quand vous prévoyez d’implémenter GitOps pour Kubernetes avec Azure Arc.

Le diagramme suivant présente une architecture de référence qui illustre les responsabilités, référentiels et pipelines nécessaires pour implémenter un processus GitOps à l’aide de l’extension Flux Kubernetes avec Azure Arc.

Diagram that shows a GitOps Reference flow.

Référentiels

Trois référentiels Git sont inclus dans la conception :

  • Référentiel du code de l’application
    • Ce référentiel stocke le code de l’application et les scripts de définition et de configuration du pipeline.
    • Utilisez une stratégie de création de branche de développement qui est facile à comprendre et qui limite le nombre de branches de longue durée indésirables.
  • Référentiel de configuration de l’application
    • Ce référentiel stocke les configurations de l’application, notamment les objets Kubernetes comme les objets ConfigMaps, Déploiements, Services et HPA. Structurez ce référentiel avec différents répertoires pour chaque application. Flux synchronise les modifications de ce référentiel et de cette branche cible vers votre cluster.
    • Incorporez des outils qui aident les opérateurs et développeurs d’applications à créer des configurations initiales par environnement. Les opérateurs d’application doivent définir une configuration d’application spécifique à Kubernetes qui utilise des gestionnaires de package comme Helm ou des outils de configuration comme Kustomize pour simplifier la configuration.
    • Créez une branche pour représenter chaque type d’environnement. Cela permet un contrôle précis des modifications dans chaque environnement spécifique, comme les environnements de production et hors production.
    • Quand une application est déployée sur un espace de noms particulier, utilisez la fonctionnalité d’étendue d’espace de noms au sein de la configuration GitOps pour appliquer la configuration à un seul espace de noms.
  • Référentiel de configuration à l’échelle du cluster
    • Définissez des composants à l’échelle du cluster comme le contrôleur d’entrée, les espaces de noms, le contrôle d’accès en fonction du rôle, la supervision et la pile de sécurité pour la gestion de l’opérateur de cluster. Flux synchronise les modifications de ce référentiel et de cette branche cible vers votre cluster.
    • Structurez ce référentiel avec différents répertoires représentant différents composants.
    • Créez une branche pour représenter chaque type d’environnement. Cela permet un contrôle précis des modifications dans chaque environnement spécifique, comme les environnements de production et hors production.
    • Les opérateurs de cluster doivent utiliser des gestionnaires de packages comme Helm ou des outils de configuration comme les superpositions Kustomize pour simplifier la configuration.

Processus de mise à jour de configuration et CI/CD

Mises à jour d’images conteneur et CI/CD

  • Pipeline CI (intégration continue)
    • Les équipes de développement doivent définir un pipeline CI via un processus qui inclut la génération, le linting, les tests et l’envoi (push) d’une application vers votre registre de conteneurs.
  • Pipeline CD (déploiement continu)
    • Créez un pipeline CD qui exécute un script ciblant les modifications sur votre référentiel de configuration de l’application. Ce script crée une branche temporaire provenant de votre environnement cible, apporte une modification à la version d’étiquette d’image, valide la modification (commit) et ouvre une demande de tirage (pull request) sur votre branche d’environnement cible. Ce pipeline CD peut avoir des phases d’environnement avec des variables d’environnement appropriées pour cibler la branche et le référentiel de configuration GitOps appropriés.
    • Définissez des étapes d’approbation manuelle pour les phases d’environnement afin de limiter les demandes de tirage (pull requests) indésirables sur tous les environnements.
  • Autorisez les stratégies de branche sur votre référentiel de configuration de l’application à appliquer les approbations ou l’évaluation par les pairs pour les environnements. Cette opération peut impliquer un nombre minimal de révisions requises ou une approbation automatique pour les environnements inférieurs. Prenez également en compte les intégrations et approbations tierces si nécessaire afin de satisfaire aux normes de votre organisation.

Mises à jour de la configuration de l’application et à l’échelle du cluster

  • Les opérateurs de cluster et les opérateurs d’application définissent chaque configuration dans leurs référentiels de configuration respectifs. Ces utilisateurs n’ont pas besoin d’outils de pipeline pour envoyer (push) des configurations. Ils utilisent plutôt des processus Git natifs de validation (commit) et de PR (pull request) pour définir une configuration et envoyer (push) des modifications à une branche représentant un environnement.
  • Pour les nouvelles définitions de configuration, commencez par définir la configuration dans des environnements inférieurs, comme l’environnement Développement, avant de la promouvoir vers des environnements plus élevés par le biais de fusions et de demandes de tirage (pull requests). Mises à jour de configuration Cherry-pick spécifiques à certains environnements selon les besoins.

Commentaires et alertes

  • Configurez les Notifications Flux pour l’envoi d’alertes quand les configurations GitOps ne peuvent pas effectuer la synchronisation ou lèvent des erreurs. Les opérateurs d’application doivent configurer des alertes pour déterminer quand un déploiement d’application a réussi et est sain. Les opérateurs de cluster doivent configurer des alertes permettant de déterminer quand le rapprochement des composants à l’échelle du cluster a échoué et quand des problèmes de synchronisation avec votre référentiel Git se produisent.
  • Implémentez GitOps Connector pour intégrer les commentaires de l’agent Flux à vos outils CI/CD.

Recommandations de sécurité

  • Passez en revue les recommandations de gouvernance et de sécurité pour vos clusters Kubernetes avec Azure Arc.
  • Évitez les accès indésirables à toute configuration de cluster en utilisant un référentiel Git privé avec authentification et autorisation que vous pouvez utiliser pour définir n’importe quel référentiel de configuration.
  • Accédez à votre référentiel Git via le protocole SSH et une clé SSH si votre fournisseur Git les prend en charge. Si le protocole SSH ne peut pas être utilisé en raison de restrictions de connectivité sortante ou si votre fournisseur Git ne prend pas en charge les bibliothèques SSH requises, utilisez un compte de service dédié et associez une clé API à ce compte que Flux doit utiliser. Si vous avez besoin d’une alternative au protocole SSH lors de l’utilisation de GitHub, vous pouvez Créer un jeton d’accès personnel pour l’authentification.
  • Configurez des autorisations et des stratégies de branche qui correspondent aux responsabilités de votre cluster. Définissez un nombre minimal de réviseurs pour approuver les modifications.
  • Configurez un pipeline PR (demande de tirage) pour valider les configurations et la syntaxe YAML, voire pour déployer un cluster Kubernetes de test. Configurez une stratégie de branche qui nécessite que ce pipeline s’exécute correctement avant que toute fusion puisse être acceptée.
  • Implémentez des secrets à l’aide du Fournisseur Azure Key Vault pour le pilote Secrets Store CSI Driver, ce qui permet d’intégrer Azure Key Vault comme magasin de secrets à un cluster Kubernetes avec Azure Arc via un volume CSI.
  • L’extension Flux prend en charge les configurations étendues à l’espace de noms et au cluster. Choisissez l’étendue de l’espace de noms quand l’accès de votre configuration doit être limité à un espace de noms unique.

Étapes suivantes

Pour plus d’informations sur votre parcours cloud hybride et multicloud, consultez les articles suivants.