Partager via

GitOps pour Azure Kubernetes Service

Azure Kubernetes Service (AKS)
GitHub

GitOps est un ensemble de principes pour l’exploitation et la gestion d’un système logiciel. Cet article décrit les techniques d’utilisation des principes GitOps pour exploiter et gérer un cluster Azure Kubernetes Services (AKS).

Les logos Flux, Argo CD, OPA Gatekeeper, Kubernetes et Git sont des marques déposées de leurs sociétés respectives. L’utilisation de ces marques n’implique aucune approbation.

Architecture

Deux opérateurs GitOps que vous pouvez utiliser avec AKS sont Flux et Argo CD. Tous deux des projets validés de la Cloud Native Computing Foundation (CNCF) et sont largement utilisés. Les scénarios suivants montrent comment les utiliser.

Scénario 1 : GitOps avec Flux et AKS

Diagramme de GitOps avec Flux v2, GitHub et AKS.

Téléchargez un fichier Visio de cette architecture.

Flux de données pour le scénario 1

Flux est une extension de cluster qui s’intègre en mode natif à AKS. Une extension de cluster fournit une plateforme permettant d’installer et de gérer des solutions sur un cluster AKS. Vous pouvez utiliser le Portail Azure, Azure CLI ou des scripts IaC (Infrastructure As Code), comme des scripts Terraform ou Bicep, pour activer Flux en tant qu’extension d’AKS. Vous pouvez également utiliser Azure Policy pour appliquer des configurations Flux v2 à grande échelle sur des clusters AKS. Pour plus d’informations, consultez Déployer des applications de manière cohérente à grande échelle à l’aide de configurations Flux v2 et d’Azure Policy.

Flux peut déployer des manifestes Kubernetes, des graphiques Helm et des fichiers Kustomization sur AKS. Flux est un processus basé sur les interrogations, qui permet de détecter, d’extraire et de rapprocher les modifications de configuration sans exposer les points de terminaison de cluster à vos agents de build.

Dans ce scénario, les administrateurs Kubernetes peuvent modifier des objets de configuration Kubernetes, comme des secrets et des ConfigMaps, et valider les modifications directement dans un dépôt GitHub.

Le flux de données suivant correspond au diagramme précédent :

  1. Le développeur valide les modifications de configuration dans le dépôt GitHub.

  2. Flux détecte la dérive de configuration dans le référentiel Git et extrait les modifications de configuration.

  3. Flux rapproche l’état dans le cluster Kubernetes.

Alternatives pour le scénario 1

  • Vous pouvez utiliser Flux avec d’autres référentiels Git tels qu’Azure DevOps, GitLab et Bitbucket.

  • Au lieu de dépôts Git, l’API Flux Bucket définit une source pour produire un artefact pour les objets à partir de solutions de stockage telles qu’Amazon S3 et Google Cloud Storage buckets. Vous pouvez également utiliser une solution qui a une API compatible S3. Deux exemples sont MinIO et Alibaba Cloud Object Storage Service (OSS), mais il existe d’autres solutions.

  • Vous pouvez également configurer Flux sur un conteneur Stockage Blob Azure en tant que source pour produire des artefacts. Pour plus d’informations, consultez Configurations GitOps Flux v2 avec AKS et Kubernetes avec Azure Arc.

  • Flux v2 prend en charge l’architecture mutualisée en permettant aux équipes distinctes de déployer des charges de travail dans un seul cluster Kubernetes partagé. Plusieurs référentiels Git qui représentent chacun un locataire différent peuvent être synchronisés avec le cluster. Pour garantir l’isolation des charges de travail entre les équipes, chaque équipe peut avoir son propre namespace ou des namespaces au sein du cluster AKS auquel l’accès est limité via les stratégies de RBAC Kubernetes.

  • Flux peut utiliser un cluster pour gérer les applications dans le même cluster ou d’autres clusters. Un cluster AKS hub avec l’opérateur Flux gère le déploiement continu GitOps d’applications et de charges de travail d’infrastructure vers plusieurs clusters secondaires AKS.

Scénario 2 : Utiliser GitOps avec Flux, GitHub et AKS pour implémenter la CI/CD

Diagramme montrant comment implémenter CI/CD à l’aide de GitOps avec Flux, GitHub et AKS.

Téléchargez un fichier Visio de cette architecture.

Flux de données pour le scénario 2

Ce scénario est un pipeline DevOps basé sur l’extraction pour une application web classique. Le pipeline utilise GitHub Actions pour la génération. Pour le déploiement, il utilise Flux comme opérateur GitOps pour extraire et synchroniser l’application.

Le flux de données suivant correspond au diagramme précédent :

  1. Le code de l’application est développé à l’aide d’un environnement de développement intégré (IDE) tel que Visual Studio Code.

  2. Le code de l’application est commité dans un dépôt GitHub.

  3. GitHub Actions génère une image conteneur à partir du code de l’application et pousse l’image conteneur sur Azure Container Registry.

  4. GitHub Actions met à jour un fichier de déploiement de manifeste Kubernetes avec la version actuelle de l'image qui repose sur le numéro de version de l'image de conteneur dans le registre de conteneurs.

  5. L’opérateur Flux détecte la dérive de configuration dans le dépôt Git et extrait les modifications de configuration.

  6. Flux utilise des fichiers manifeste pour déployer l’application sur le cluster AKS.

Scénario 3 : GitOps avec Argo CD, dépôt GitHub et AKS

Diagramme de GitOps avec Argo CD, GitHub et AKS.

Téléchargez un fichier Visio de cette architecture.

Flux de données pour le scénario 3

Vous pouvez activer Argo CD en tant qu’extension de cluster dans AKS. Dans ce scénario, les administrateurs Kubernetes peuvent modifier des objets de configuration Kubernetes, comme des secrets et des ConfigMaps, et valider les modifications directement dans le dépôt GitHub.

Le flux de données suivant correspond au diagramme précédent :

  1. L’administrateur Kubernetes apporte des modifications de configuration dans les fichiers YAML et les valide dans le dépôt GitHub.

  2. Argo CD effectue un tirage des modifications à partir du dépôt Git.

  3. Argo CD rapproche les modifications de configuration apportées au cluster AKS.

Argo CD n’a pas besoin de synchroniser automatiquement l’état cible souhaité avec le cluster AKS. Il est implémenté en tant que contrôleur Kubernetes qui surveille en permanence les applications en cours d’exécution. Il compare l’état actif actuel du cluster AKS à l’état cible souhaité spécifié dans le référentiel Git. Argo CD signale et visualise les différences et fournit des outils pour synchroniser automatiquement ou manuellement l’état en direct avec l’état cible souhaité.

Argo CD fournit une interface utilisateur basée sur un navigateur. Vous pouvez l’utiliser pour ajouter des configurations d’application, observer l’état de synchronisation par rapport au cluster et lancer la synchronisation sur le cluster. Vous pouvez également utiliser la ligne de commande Argo CD pour effectuer ces tâches. L’interface utilisateur et l’interface de ligne de commande fournissent des fonctionnalités permettant d’afficher l’historique des modifications de configuration et de restaurer une version précédente.

Par défaut, l’interface utilisateur Argo CD et le serveur d’API ne sont pas exposés. Pour y accéder, nous vous recommandons de créer un contrôleur d’entrée qui a une adresse IP interne. Vous pouvez également utiliser un équilibreur de charge interne pour les exposer.

Alternatives pour le scénario 3

Tout dépôt compatible avec Git, y compris Azure DevOps, peut servir de référentiel source de configuration.

Scénario 4 : Utiliser GitOps avec Argo CD, GitHub Actions et AKS pour implémenter CI/CD

Diagramme montrant comment implémenter CI/CD à l’aide de GitOps avec Argo CD, GitHub et AKS.

Téléchargez un fichier Visio de cette architecture.

Flux de données pour le scénario 4

Ce scénario est un pipeline DevOps basé sur l’extraction pour une application web classique. Le pipeline utilise GitHub Actions pour la génération. Pour le déploiement, il utilise Argo CD comme opérateur GitOps pour tirer et synchroniser l’application.

Le flux de données suivant correspond au diagramme précédent :

  1. Le code d’application est développé à l’aide d’un IDE, comme Visual Studio Code.

  2. Le code de l’application est commité dans un dépôt GitHub.

  3. GitHub Actions génère une image conteneur à partir du code de l’application et envoie (push) l’image conteneur vers Container Registry.

  4. GitHub Actions met à jour un fichier de déploiement de manifeste Kubernetes avec la version actuelle de l'image qui repose sur le numéro de version de l'image de conteneur dans le registre de conteneurs.

  5. Argo CD effectue un tirage à partir du dépôt Git.

  6. Argo CD déploie l’application sur le cluster AKS.

Alternatives pour le scénario 4

Tout dépôt compatible avec Git, y compris Azure DevOps, peut servir de référentiel source de configuration.

Détails du scénario

GitOps est un ensemble de principes pour l’exploitation et la gestion d’un système logiciel.

  • Il utilise le contrôle de code source comme source unique de vérité pour le système.

  • Il applique des pratiques de développement telles que le contrôle de version, la collaboration, la conformité et l’intégration continue et le déploiement continu (CI/CD) à l’automatisation de l’infrastructure.

  • Vous pouvez l’appliquer à n’importe quel système logiciel.

GitOps est souvent utilisé pour la gestion de cluster Kubernetes et la livraison d’applications.

Selon les principes GitOps, l’état souhaité d’un système géré par GitOps doit répondre aux critères suivants :

  • Déclaratif: Un système que GitOps gère doit avoir son état souhaité exprimé de manière déclarative. La déclaration est généralement stockée dans un référentiel Git.

  • Versionné et immuable : L’état souhaité est stocké de manière à appliquer l’immuabilité et le versionnage, et conserve un historique de version complet.

  • Extrait automatiquement : Les agents logiciels extrayent automatiquement les déclarations d’état souhaitées à partir de la source.

  • Rapprochement continu : Les agents logiciels observent en permanence l’état du système réel et tentent d’appliquer l’état souhaité.

Dans GitOps, IaC utilise du code pour déclarer l’état souhaité des composants d’infrastructure tels que les machines virtuelles, les réseaux et les pare-feu. Ce code fait l’objet d’une gestion de version et peut être audité.

Kubernetes décrit tout, de l’état du cluster aux déploiements d’applications de manière déclarative à l’aide de manifestes. GitOps pour Kubernetes place l’état souhaité de l’infrastructure du cluster sous une gestion de version. Un composant du cluster, généralement appelé opérateur, synchronise en permanence l’état déclaratif. Cette approche permet d’examiner et d’auditer les modifications de code qui affectent le cluster. Il améliore la sécurité en prenant en charge le principe du privilège minimum (PoLP).

Les agents GitOps rapprochent en continu l’état du système avec l’état souhaité stocké dans votre référentiel de code. Certains agents GitOps peuvent rétablir des opérations effectuées en dehors du cluster, comme la création manuelle d’objets Kubernetes. Par exemple, les contrôleurs d’admission appliquent des stratégies sur les objets pendant les opérations de création, de mise à jour et de suppression. Vous pouvez les utiliser pour vous assurer que les déploiements changent uniquement si le code de déploiement dans le référentiel source change.

Vous pouvez combiner des outils de gestion et d’application des stratégies avec GitOps pour appliquer des stratégies et fournir des commentaires sur les modifications de stratégie proposées. Vous pouvez configurer des notifications pour les équipes individuelles afin de les informer de l’état GitOps actuel. Par exemple, vous pouvez envoyer des notifications de réussites de déploiement et d’échecs de rapprochement.

GitOps comme source unique de vérité

GitOps fournit une cohérence et une normalisation de l’état du cluster et peut contribuer à améliorer la sécurité. Vous pouvez également utiliser GitOps pour garantir la cohérence de l’état entre plusieurs clusters. Par exemple, GitOps peut appliquer la même configuration sur les clusters principaux et de récupération d’urgence (DR) ou sur une batterie de clusters.

Pour appliquer GitOps comme seule méthode pour modifier l’état du cluster, limitez l’accès direct au cluster. Pour définir cette configuration, utilisez le contrôle d’accès en fonction du rôle Azure (Azure RBAC), les contrôleurs d’admission ou d’autres outils.

Utiliser GitOps pour démarrer la configuration initiale

Parfois, le déploiement de cluster AKS est requis dans le cadre de la configuration de la base de référence. Par exemple, vous devrez peut-être déployer des services partagés ou des configurations au niveau du système avant de déployer des charges de travail d’application. Ces services partagés peuvent configurer les modules complémentaires et outils suivants :

Vous pouvez activer Flux en tant qu’extension appliquée lorsque vous créez un cluster AKS. Flux peut ensuite démarrer la configuration de base sur le cluster. L’architecture de base d’un cluster AKS vous recommande d’utiliser GitOps pour l’amorçage. Si vous utilisez l’extension Flux, vous pouvez démarrer des clusters peu après le déploiement.

Autres outils et modules complémentaires GitOps

Vous pouvez étendre les scénarios décrits à d’autres outils GitOps. Jenkins X est un autre outil GitOps qui fournit des instructions pour l’intégration à Azure. Vous pouvez utiliser des outils de livraison progressive, comme Flagger, pour le déplacement progressif des charges de travail de production déployées via GitOps.

Cas d’usage potentiels

Cette solution bénéficie aux organisations qui souhaitent déployer des applications et iaC et maintenir une piste d’audit de chaque modification.

GitOps simplifie la gestion des conteneurs pour les développeurs, ce qui améliore la productivité. Les développeurs peuvent continuer à utiliser des outils familiers, comme Git, pour gérer les mises à jour et les nouvelles fonctionnalités.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Si un cluster devient indisponible, GitOps doit être utilisé dans le cadre de la création d’un cluster. Il utilise le référentiel Git comme source unique de vérité pour la configuration Kubernetes et la logique d’application. Il peut créer et appliquer la configuration du cluster et le déploiement d’application en tant qu’unité d’échelle et peut établir le modèle Tampons de déploiement .

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Avec l’approche de GitOps, les développeurs ou administrateurs individuels n’accèdent pas directement aux clusters Kubernetes pour appliquer des modifications ou des mises à jour. Au lieu de cela, les utilisateurs poussent les modifications vers un référentiel Git et l’opérateur GitOps, tels que Flux ou Argo CD, lit les modifications et les applique au cluster. Cette approche permet de respecter les meilleures pratiques en matière de sécurité d’accès minimal en n’accordant pas aux équipes DevOps d’autorisations d’écriture sur l’API Kubernetes. Au cours des scénarios de diagnostic ou de résolution des problèmes, vous pouvez octroyer des autorisations de cluster pendant une durée limitée au cas par cas.

Outre la configuration des autorisations de référentiel, envisagez d’implémenter les mesures de sécurité suivantes dans les référentiels Git qui se synchronisent avec des clusters AKS :

  • Protection de branche : empêcher l’envoi direct des modifications aux branches représentant l’état des clusters Kubernetes. Utilisez des requêtes de tirage (PR) pour apporter des modifications et faites en sorte qu'au moins une autre personne examine chaque requête de tirage. Utilisez également les pull requests pour réaliser des vérifications automatiques.

  • Révision des demandes de tirage : Exiger que les demandes de tirage aient au moins un réviseur pour appliquer le principe des quatre yeux. Vous pouvez également utiliser la fonctionnalité des propriétaires du code GitHub pour définir des personnes ou des équipes chargées de la révision de fichiers spécifiques dans un référentiel.

  • Historique immuable : n’autorisez que les nouvelles validations en plus des modifications existantes. L’historique immuable est particulièrement important pour les audits.

  • Mesures de sécurité supplémentaires : demandez à vos utilisateurs GitHub d’activer l’authentification à deux facteurs. Autorisez uniquement les validations signées pour empêcher les modifications.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

  • Le niveau gratuit AKS fournit la gestion gratuite des clusters. Les coûts sont limités aux ressources de calcul, de stockage et de mise en réseau utilisées par AKS pour héberger des nœuds. Le niveau gratuit AKS n’inclut pas de contrat de niveau de service (SLA) et n’est pas recommandé pour les charges de travail de production.

  • GitHub fournit un service gratuit, mais pour utiliser des fonctionnalités avancées liées à la sécurité telles que les propriétaires de code ou les réviseurs requis, vous avez besoin du plan d’équipe. Pour plus d’informations, consultez la tarification GitHub.

  • Azure DevOps fournit un niveau gratuit que vous pouvez utiliser pour certains scénarios.

  • Utiliser la calculatrice de prix Azure pour estimer les coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

GitOps peut augmenter la productivité de DevOps. L’une des fonctionnalités les plus utiles est la possibilité de restaurer rapidement les modifications qui se comportent de manière inattendue en effectuant des opérations Git. Le graphique de validation contient toujours toutes les validations, ce qui permet d’obtenir de l’aide sur l’analyse rétrospective.

Les équipes GitOps gèrent souvent plusieurs environnements pour la même application. Il est normal que plusieurs étapes d’une application soient déployées sur différents clusters ou espaces de noms Kubernetes. Le référentiel Git, qui est la seule source de vérité, indique les versions des applications actuellement déployées sur un cluster.

Déployer un scénario

Pour plus d’informations sur le déploiement des cinq scénarios, consultez les ressources suivantes :

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes