Partager via

Forum aux questions – Kubernetes avec Azure Arc et GitOps

  • Article

Cet article traite des questions fréquemment posées sur Kubernetes avec Azure Arc et GitOps.

Quelle est la différence entre Kubernetes avec Azure Arc et Azure Kubernetes Service (AKS) ?

AKS est l’offre de Kubernetes managé fournie par Azure. AKS simplifie le déploiement d’un cluster Kubernetes managé dans Azure en déchargeant une grande partie de la complexité et de la surcharge opérationnelle sur Azure. Sachant que les maîtres Kubernetes sont gérés par Azure, seules la gestion et la maintenance des nœuds agents vous incombent.

Kubernetes avec Azure Arc vous permet d’étendre les fonctionnalités de gestion d’Azure telles qu’Azure Monitor et Azure Policy en connectant des clusters Kubernetes à Azure. Vous conservez le cluster Kubernetes sous-jacent.

Dois-je connecter à Azure Arc mes clusters AKS qui s’exécutent sur Azure ?

Actuellement, la connexion d’un cluster Azure Kubernetes Service (AKS) à Azure Arc n’est pas nécessaire pour la plupart des scénarios. Vous pouvez connecter un cluster pour exécuter certains services avec Azure Arc, tels que App Services et Data Services, au-dessus du cluster. Pour ce faire, vous pouvez utiliser la fonctionnalité d’emplacements personnalisés de Kubernetes avec Azure Arc.

Dois-je connecter mon cluster AKS-HCI et les clusters Kubernetes sur Azure Stack Hub à Azure Arc ?

Oui, la connexion de votre cluster AKS-HCI ou de vos clusters Kubernetes sur Azure Stack Edge à Azure Arc fournit des clusters avec une représentation de ressources dans Azure Resource Manager. Cette représentation des ressources étend des fonctionnalités telles que la configuration de cluster, Azure Monitor et Azure Policy (Gatekeeper) aux clusters Kubernetes connectés.

Si le cluster Kubernetes avec Azure Arc est sur Azure Stack Edge, AKS sur Azure Stack HCI (>= mise à jour d’avril 2021) ou AKS sur Windows Server 2019 Datacenter (>= mise à jour d’avril 2021), la configuration de Kubernetes est incluse gratuitement.

Comment traiter des ressources Kubernetes avec Azure Arc ?

L’identité managée affectée par le système et associée à votre cluster Kubernetes avec Azure Arc est uniquement utilisée par les agents Azure Arc pour communiquer avec les services Azure Arc. Le certificat que le système associe à cette identité managée a une fenêtre d’expiration de 90 jours, et les agents tenteront de le renouveler entre les 46e et 90e jours. Pour éviter que votre certificat d’identité managée n’expire, veillez à ce que le cluster soit mis en ligne au moins une fois entre le 46e et le 90e jour afin que le certificat puisse être renouvelé.

Si le certificat d’identité managée expire, la ressource est considérée comme Expired et toutes les fonctionnalités d’Azure Arc (telles que la configuration, la surveillance et la stratégie) cessent de fonctionner sur le cluster.

Pour savoir quand le certificat d’identité managée d’un cluster donné doit expirer, exécutez la commande suivante :

az connectedk8s show -n <name> -g <resource-group>

Dans la sortie, la valeur managedIdentityCertificateExpirationTime indique la date d’expiration du certificat d’identité managée (marque 90D Mark pour ce certificat).

Si la valeur managedIdentityCertificateExpirationTime indique un horodatage (timestamp) passé, le champ connectivityStatus dans la sortie ci-dessus est défini sur Expired. Dans de tels cas, pour que votre cluster Kubernetes fonctionne à nouveau avec Azure Arc :

  1. Supprimez la ressource Kubernetes avec Azure Arc et les agents sur le cluster.

    az connectedk8s delete -n <name> -g <resource-group>

  2. Recréez la ressource Kubernetes avec Azure Arc en déployant des agents sur le cluster.

    az connectedk8s connect -n <name> -g <resource-group>

Remarque

az connectedk8s delete va également supprimer les configurations et les extensions de cluster sur le cluster. Après avoir exécuté az connectedk8s connect, recréez les configurations et les extensions de cluster sur le cluster, manuellement ou à l’aide d’Azure Policy.

Si j’utilise déjà des pipelines CI/CD, puis-je continuer à utiliser Kubernetes avec Azure Arc et les configurations AKS et GitOps ?

Oui, vous pouvez toujours utiliser les configurations sur un cluster recevant des déploiements via un pipeline CI/CD. Comparées aux pipelines CI/CD classiques, les configurations GitOps offrent quelques avantages supplémentaires.

Rapprochement de dérive

Le pipeline CI/CD n’applique les modifications qu’une seule fois pendant l’exécution du pipeline. Toutefois, l’opérateur GitOps du cluster interroge en permanence le référentiel Git pour extraire l’état souhaité des ressources Kubernetes sur le cluster. Si l’opérateur GitOps détermine que l’état souhaité des ressources est différent de l’état réel des ressources sur le cluster, cette dérive est rapprochée.

Appliquer GitOps à grande échelle

Les pipelines CI/CD sont utiles pour les déploiements basés sur les événements sur votre cluster Kubernetes (par exemple un envoi (push) vers un dépôt Git). Toutefois, déployez la même configuration sur tous vos clusters Kubernetes, vous devez configurer manuellement les informations d’identification de chaque cluster Kubernetes sur le pipeline CI/CD.

Pour Kubernetes avec Azure Arc, dans la mesure où Azure Resource Manager gère vos configurations GitOps, vous pouvez automatiser la création d’une configuration identique sur toutes les ressources Kubernetes avec Azure Arc et AKS via Azure Policy, dans l’étendue d’un abonnement ou d’un groupe de ressources. Cette fonctionnalité peut même s’appliquer aux ressources Kubernetes compatibles avec Azure Arc et AKS créées après l’attribution de la stratégie.

Cette fonctionnalité applique des configurations de base de référence (par exemple des stratégies réseau, des liaisons de rôles et des stratégies de sécurité des pods) à l’ensemble de l’inventaire de clusters Kubernetes pour répondre aux impératifs de conformité et de gouvernance.

Conformité du cluster

L’état de conformité de chaque configuration GitOps est renvoyé à Azure. Cela vous permet d’effectuer le suivi de tous les déploiements ayant échoué.

Kubernetes avec Azure Arc stocke-t-il des données client en dehors de la région du cluster ?

La fonctionnalité permettant le stockage de données client dans une seule région n’est actuellement disponible que dans la région Asie Sud-Est (Singapour) de la zone géographique Asie-Pacifique, et la région Brésil Sud (État de Sao Paulo) de la zone géographique Brésil. Pour toutes les autres régions, les données client sont stockées dans Zone géographique. Cela s’applique aux extensions de fournisseur de secrets Open Service Mesh et Azure Key Vault compatibles avec Azure Arc, prises en charge dans Kubernetes compatible avec Azure Arc. Pour les autres extensions de cluster, consultez leur documentation pour comprendre comment ils stockent les données client. Pour plus d’informations, consultez le Centre de gestion de la confidentialité.

Étapes suivantes