Résolution des problèmes liés à Kubernetes avec Azure Arc et GitOps

Article
03/14/2023
23 minutes de lecture

Ce document fournit des guides de dépannage pour les problèmes liés à la connectivité, aux autorisations et aux agents Kubernetes avec Azure Arc. Il fournit également des guides de dépannage pour Azure GitOps, qui peuvent être utilisés dans les clusters Kubernetes avec Azure Arc ou Azure Kubernetes Service (AKS).

Résolution générale des problèmes

Azure CLI

Avant d’utiliser les commandes CLI az connectedk8s ou az k8s-configuration, vérifiez qu’Azure CLI est configuré pour fonctionner avec l’abonnement Azure approprié.

az account set --subscription 'subscriptionId'
az account show

Agents Azure Arc

Tous les agents pour Kubernetes avec Azure Arc sont déployés en tant que pods dans l’espace de noms azure-arc. Tous les pods doivent être en cours d’exécution et réussir leurs contrôles d’intégrité.

Tout d’abord, vérifiez la version de Azure Arc Helm Chart :

$ helm --namespace default status azure-arc
NAME: azure-arc
LAST DEPLOYED: Fri Apr  3 11:13:10 2020
NAMESPACE: default
STATUS: deployed
REVISION: 5
TEST SUITE: None

Si la version de Helm Chart est introuvable ou manquante, essayez de reconnecter le cluster à Azure Arc.

Si la version de Helm Chart est présente avec STATUS: deployed, vérifiez l’état des agents à l’aide de kubectl :

$ kubectl -n azure-arc get deployments,pods
NAME                                       READY  UP-TO-DATE  AVAILABLE  AGE
deployment.apps/clusteridentityoperator     1/1       1          1       16h
deployment.apps/config-agent                1/1       1          1       16h
deployment.apps/cluster-metadata-operator   1/1       1          1       16h
deployment.apps/controller-manager          1/1       1          1       16h
deployment.apps/flux-logs-agent             1/1       1          1       16h
deployment.apps/metrics-agent               1/1       1          1       16h
deployment.apps/resource-sync-agent         1/1       1          1       16h

NAME                                            READY   STATUS  RESTART  AGE
pod/cluster-metadata-operator-7fb54d9986-g785b  2/2     Running  0       16h
pod/clusteridentityoperator-6d6678ffd4-tx8hr    3/3     Running  0       16h
pod/config-agent-544c4669f9-4th92               3/3     Running  0       16h
pod/controller-manager-fddf5c766-ftd96          3/3     Running  0       16h
pod/flux-logs-agent-7c489f57f4-mwqqv            2/2     Running  0       16h
pod/metrics-agent-58b765c8db-n5l7k              2/2     Running  0       16h
pod/resource-sync-agent-5cf85976c7-522p5        3/3     Running  0       16h

Tous les pods doivent indiquer que le STATUS est Running avec 3/3 ou 2/2 sous la colonne READY. Récupérez les journaux et décrivez les pods qui retournent Error ou CrashLoopBackOff. Si des pods sont bloqués à l’état Pending, cela est peut-être dû à un manque de ressources sur les nœuds de cluster. Effectuez un scale-up de votre cluster pour permettre à ces pods de passer à l’état Running.

Connexion de clusters Kubernetes à Azure Arc

La connexion de clusters à Azure Arc nécessite l’accès à un abonnement Azure et l’accès de cluster-admin à un cluster cible. Si vous ne pouvez pas joindre le cluster ou si vous disposez d’autorisations insuffisantes, la connexion du cluster à Azure Arc ne pourra pas s’effectuer. Assurez-vous que vous avez satisfait à toutes les conditions préalables pour connecter un cluster.

Conseil

Pour obtenir un guide visuel sur la résolution de ces problèmes, consultez Diagnostiquer les problèmes de connexion pour les clusters Kubernetes avec Arc.

Problèmes de résolution du DNS

Si vous obtenez un message d’erreur à propos d’un problème de résolution DNS sur votre cluster, vous pouvez essayer plusieurs méthodes pour diagnostiquer et résoudre le problème.

Pour plus d’informations, consultez Débogage de la résolution DNS.

Problèmes de connectivité réseau sortante

Des problèmes de connectivité réseau sortante sur le cluster peuvent survenir pour différentes raisons. Tout d’abord, vérifiez que toutes les exigences réseau ont été respectées.

Si vous rencontrez ce problème et que votre cluster se trouve derrière un serveur proxy sortant, vérifiez que vous avez transmis les paramètres de proxy pendant l’intégration de votre cluster et que le proxy est correctement configuré. Pour plus d’informations, consultez Se connecter à l’aide d’un serveur proxy sortant.

Impossible de récupérer le certificat MSI

Les problèmes de récupération du certificat MSI sont généralement dus à des problèmes réseau. Vérifiez que toutes les exigences réseau ont été respectées, puis réessayez.

Autorisations du cluster insuffisantes

Si le fichier kubeconfig fourni ne dispose pas des autorisations suffisantes pour installer les agents Azure Arc, la commande Azure CLI renvoie une erreur.

az connectedk8s connect --resource-group AzureArc --name AzureArcCluster

Ensure that you have the latest helm version installed before proceeding to avoid unexpected errors.
This operation might take a while...

Error: list: failed to list: secrets is forbidden: User "myuser" cannot list resource "secrets" in API group "" at the cluster scope

Pour résoudre ce problème, l’utilisateur qui connecte le cluster à Azure Arc doit se voir attribuer le rôle cluster-admin sur le cluster.

Impossible de connecter le cluster OpenShift à Azure Arc

Si az connectedk8s connect arrive à expiration et échoue lors de la connexion d’un cluster OpenShift à Azure Arc :

Assurez-vous que le cluster OpenShift respecte les conditions préalables de version : 4.5.41+, 4.6.35+ ou 4.7.18+.

Avant d’exécuter az connectedk8s connnect, exécutez cette commande sur le cluster :

oc adm policy add-scc-to-user privileged system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa

Délai d’installation

La connexion d’un cluster Kubernetes à Kubernetes avec Azure Arc nécessite l’installation d’agents Azure Arc sur le cluster. Si le cluster s’exécute sur une connexion Internet lente, l’extraction de l’image conteneur pour les agents peut dépasser le délai d’expiration d’Azure CLI.

az connectedk8s connect --resource-group AzureArc --name AzureArcCluster

Ensure that you have the latest helm version installed before proceeding to avoid unexpected errors.
This operation might take a while...

Erreur de délai d’attente Helm

Vous pouvez voir l’erreur de délai d’expiration Helm suivante :

az connectedk8s connect -n AzureArcTest -g AzureArcTest

Unable to install helm release: Error: UPGRADE Failed: time out waiting for the condition

Pour résoudre ce problème, essayez les étapes suivantes :

Exécutez la commande suivante :
```
kubectl get pods -n azure-arc
```

Vérifiez si les pods clusterconnect-agent ou config-agent affichent crashloopbackoff, ou si tous les conteneurs ne sont pas en cours d’exécution :

NAME                                        READY   STATUS             RESTARTS   AGE
cluster-metadata-operator-664bc5f4d-chgkl   2/2     Running            0          4m14s
clusterconnect-agent-7cb8b565c7-wklsh       2/3     CrashLoopBackOff   0          1m15s
clusteridentityoperator-76d645d8bf-5qx5c    2/2     Running            0          4m15s
config-agent-65d5df564f-lffqm               1/2     CrashLoopBackOff   0          1m14s

Si le certificat ci-dessous n’est pas présent, l’identité managée affectée par le système n’a pas été installée.
```
kubectl get secret -n azure-arc -o yaml | grep name:
```
```
name: azure-identity-certificate
```
Pour résoudre ce problème, essayez de supprimer le déploiement Arc en exécutant la commande az connectedk8s delete et en le réinstallant. Si le problème persiste, il peut s’agir d’un problème avec vos paramètres proxy. Dans ce cas, essayez de connecter votre cluster à Azure Arc via un proxy pour connecter votre cluster à Arc via un proxy. Vérifiez également si tous les prérequis réseau sont satisfaits.
Si les pods clusterconnect-agent et config-agent sont en cours d’exécution, mais que le pod kube-aad-proxy est manquant, vérifiez vos stratégies de sécurité des pods. Ce pod utilise le compte de service azure-arc-kube-aad-proxy-sa, qui ne dispose pas d’autorisations d’administrateur, mais qui nécessite l’autorisation de monter le chemin d’hôte.
Si le pod kube-aad-proxy est bloqué à l’état ContainerCreating, vérifiez si le certificat kube-aad-proxy a été téléchargé sur le cluster.
```
kubectl get secret -n azure-arc -o yaml | grep name:
```
```
name: kube-aad-proxy-certificate
```
Si le certificat est manquant, supprimez le déploiement et procédez à une nouvelle intégration avec un autre nom pour le cluster. Si le problème persiste, contactez le support.

Erreur de validation Helm

La version v3.3.0-rc.1 de Helm présente un problème : l’installation/la mise à niveau de Helm (utilisée par l’extension CLI connectedk8s) entraîne l’exécution de tous les hooks, ce qui donne lieu à l’erreur suivante :

az connectedk8s connect -n AzureArcTest -g AzureArcTest

Ensure that you have the latest helm version installed before proceeding.
This operation might take a while...

Please check if the azure-arc namespace was deployed and run 'kubectl get pods -n azure-arc' to check if all the pods are in running state. A possible cause for pods stuck in pending state could be insufficientresources on the Kubernetes cluster to onboard to arc.
ValidationError: Unable to install helm release: Error: customresourcedefinitions.apiextensions.k8s.io "connectedclusters.arc.azure.com" not found

Pour résoudre ce problème, procédez comme suit :

Supprimez la ressource Kubernetes avec Azure Arc dans le portail Azure.

Exécutez les commandes suivantes sur votre ordinateur :

kubectl delete ns azure-arc
kubectl delete clusterrolebinding azure-arc-operator
kubectl delete secret sh.helm.release.v1.azure-arc.v1

Installez une version stable de Helm 3 sur votre ordinateur à la place de la version Release Candidate.
Exécutez la commande az connectedk8s connect avec les valeurs appropriées pour connecter le cluster à Azure Arc.

Erreur du module CryptoHash

Lorsque vous tentez d’intégrer des clusters Kubernetes à la plateforme Azure Arc, l’environnement local (par exemple, votre console cliente) peut retourner le message d’erreur suivant :

Cannot load native module 'Crypto.Hash._MD5'

Parfois, les modules dépendants ne peuvent pas être téléchargés correctement lors de l’ajout des extensions connectedk8s et k8s-configuration via Azure CLI ou Azure PowerShell. Pour résoudre ce problème, supprimez manuellement les extensions, puis ajoutez-les dans l’environnement local.

Pour supprimer les extensions, utilisez :

az extension remove --name connectedk8s

az extension remove --name k8s-configuration

Pour ajouter les extensions, utilisez :

az extension add --name connectedk8s

az extension add --name k8s-configuration

Gestion de GitOps

Flux v1 - Général

Notes

À terme, Azure cessera de prendre en charge GitOps avec Flux v1. Commencez donc à utiliser Flux v2 dès que possible.

Pour permettre la résolution des problèmes liés à la ressource sourceControlConfigurations (Flux v1), exécutez ces commandes Azure CLI avec le paramètre --debug spécifié :

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration create <parameters> --debug

Flux v1 - Créer des configurations

Les autorisations d’accès en écriture sur la ressource Kubernetes avec Azure Arc (Microsoft.Kubernetes/connectedClusters/Write) sont nécessaires et suffisantes pour créer des configurations sur ce cluster.

`sourceControlConfigurations` remains `Pending` (Flux v1)

kubectl -n azure-arc logs -l app.kubernetes.io/component=config-agent -c config-agent
$ k -n pending get gitconfigs.clusterconfig.azure.com  -o yaml
apiVersion: v1
items:
- apiVersion: clusterconfig.azure.com/v1beta1
  kind: GitConfig
  metadata:
    creationTimestamp: "2020-04-13T20:37:25Z"
    generation: 1
    name: pending
    namespace: pending
    resourceVersion: "10088301"
    selfLink: /apis/clusterconfig.azure.com/v1beta1/namespaces/pending/gitconfigs/pending
    uid: d9452407-ff53-4c02-9b5a-51d55e62f704
  spec:
    correlationId: ""
    deleteOperator: false
    enableHelmOperator: false
    giturl: git@github.com:slack/cluster-config.git
    helmOperatorProperties: null
    operatorClientLocation: azurearcfork8s.azurecr.io/arc-preview/fluxctl:0.1.3
    operatorInstanceName: pending
    operatorParams: '"--disable-registry-scanning"'
    operatorScope: cluster
    operatorType: flux
  status:
    configAppliedTime: "2020-04-13T20:38:43.081Z"
    isSyncedWithAzure: true
    lastPolledStatusTime: ""
    message: 'Error: {exit status 1} occurred while doing the operation : {Installing
      the operator} on the config'
    operatorPropertiesHashed: ""
    publicKey: ""
    retryCountPublicKey: 0
    status: Installing the operator
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Flux v2 - Général

Pour permettre la résolution des problèmes liés à la ressource fluxConfigurations (Flux v2), exécutez ces commandes Azure CLI avec le paramètre --debug spécifié :

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug

Flux v2 - Erreurs de webhook ou de test

Si vous constatez un échec de rapprochement de Flux avec une erreur telle que dry-run failed, error: admission webhook "<webhook>" does not support dry run, vous pouvez résoudre le problème en recherchant ValidatingWebhookConfiguration ou MutatingWebhookConfiguration, et en définissant sideEffects sur None ou NoneOnDryRun :

Pour plus d’informations, consultez Comment résoudre les erreurs webhook does not support dry run ?.

Flux v2 - Erreur lors de l’installation de l’extension `microsoft.flux`

L’extension microsoft.flux installe les contrôleurs Flux et les agents Azure GitOps dans vos clusters Kubernetes avec Azure Arc ou Azure Kubernetes Service (AKS). Si l’extension n’est pas déjà installée dans un cluster et que vous créez une ressource de configuration GitOps pour ce cluster, elle est installée automatiquement.

Si vous rencontrez une erreur pendant l’installation ou si l’extension est dans un état d’échec, exécutez un script pour enquêter. Le paramètre cluster-type peut avoir la valeur connectedClusters pour un cluster avec Azure Arc ou managedClusters pour un cluster AKS. Le nom de l’extension microsoft.flux sera « flux » si l’extension a été installée automatiquement lors de la création d’une configuration GitOps. Pour plus d’informations, consultez l’objet « statuses ».

Exemple :

az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>

"statuses": [
    {
      "code": "InstallationFailed",
      "displayStatus": null,
      "level": null,
      "message": "unable to add the configuration with configId {extension:flux} due to error: {error while adding the CRD configuration: error {Operation cannot be fulfilled on extensionconfigs.clusterconfig.azure.com \"flux\": the object has been modified; please apply your changes to the latest version and try again}}",
      "time": null
    }
  ]

Autre exemple :

az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>

"statuses": [
    {
      "code": "InstallationFailed",
      "displayStatus": null,
      "level": null,
      "message": "Error: {failed to install chart from path [] for release [flux]: err [cannot re-use a name that is still in use]} occurred while doing the operation : {Installing the extension} on the config",
      "time": null
    }
  ]

Autre exemple du portail :

{'code':'DeploymentFailed','message':'At least one resource deployment operation failed. Please list 
deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.
','details':[{'code':'ExtensionCreationFailed', 'message':' Request failed to https://management.azure.com/
subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ContainerService/
managedclusters/<CLUSTER_NAME>/extensionaddons/flux?api-version=2021-03-01. Error code: BadRequest. 
Reason: Bad Request'}]}

Dans tous ces cas, les actions correctives possibles sont de forcer la suppression de l’extension, de désinstaller la version Helm et de supprimer l’espace de noms flux-system du cluster.

az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>

helm uninstall flux -n flux-system
kubectl delete namespaces flux-system

Autres aspects à prendre en compte :

Pour le cluster AKS, assurez-vous que l’abonnement a l’indicateur de fonctionnalité Microsoft.ContainerService/AKS-ExtensionManager activé.
```
az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager
```
Assurez-vous que le cluster n’a pas de stratégies qui limitent la création de l’espace de noms flux-system ou de ressources dans cet espace de noms.

Après avoir accompli ces actions, vous pouvez recréer une configuration de flux qui installe automatiquement l’extension flux, ou réinstaller l’extension flux manuellement.

Flux v2 - Installation de l’extension `microsoft.flux` dans un cluster avec Azure AD Pod Identity activé

Si vous tentez d’installer l’extension Flux dans un cluster où Azure Active Directory (Azure AD) Pod Identity est activé, une erreur peut se produire dans le pod extension-agent.

{"Message":"2021/12/02 10:24:56 Error: in getting auth header : error {adal: Refresh request failed. Status Code = '404'. Response body: no azure identity found for request clientID <REDACTED>\n}","LogType":"ConfigAgentTrace","LogLevel":"Information","Environment":"prod","Role":"ClusterConfigAgent","Location":"westeurope","ArmId":"/subscriptions/<REDACTED>/resourceGroups/<REDACTED>/providers/Microsoft.Kubernetes/managedclusters/<REDACTED>","CorrelationId":"","AgentName":"FluxConfigAgent","AgentVersion":"0.4.2","AgentTimestamp":"2021/12/02 10:24:56"}

L’état de l’extension retourne également « Failed » (échec).

"{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"ExtensionCreationFailed\",\"message\":\" error: Unable to get the status from the local CRD with the error : {Error : Retry for given duration didn't get any results with err {status not populated}}\"}]}}",

Le pod extension-agent tente de récupérer son jeton auprès d’IMDS sur le cluster pour communiquer avec le service d’extension dans Azure, mais cette demande de jeton est interceptée par l’identité de pod.

Vous pouvez résoudre ce problème en effectuant une mise à niveau vers la dernière version de l’extension microsoft.flux . Pour la version 1.6.1 ou antérieure, la solution de contournement consiste à créer un qui indique à Azure AD Pod Identity d’ignorer AzurePodIdentityException les demandes de jeton provenant des pods d’extension de flux.

apiVersion: aadpodidentity.k8s.io/v1
kind: AzurePodIdentityException
metadata:
  name: flux-extension-exception
  namespace: flux-system
spec:
  podLabels:
    app.kubernetes.io/name: flux-extension

Flux v2 - Installation de l’extension `microsoft.flux` dans un cluster avec Kubenet Identity activé

Lorsque vous travaillez avec des clusters Azure Kubernetes, l’une des options d’authentification est l’identité kubelet à l’aide d’une identité managée affectée par l’utilisateur. L’utilisation de l’identité kubelet peut réduire la surcharge opérationnelle et augmenter la sécurité lors de la connexion à des ressources Azure telles que Azure Container Registry.

Pour permettre à Flux d’utiliser l’identité kubelet, ajoutez le paramètre --config useKubeletIdentity=true lors de l’installation de l’extension Flux. Cette option est prise en charge à partir de la version 1.6.1 de l’extension.

az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config useKubeletIdentity=true

Flux v2 : limites du processeur et de la mémoire d’installation d’extension `microsoft.flux`

Les contrôleurs installés dans votre cluster Kubernetes avec l’extension Microsoft Flux nécessitent les limites de ressources processeur et mémoire suivantes pour planifier correctement sur les nœuds de cluster Kubernetes.

Nom du conteneur	Limite UC	Limite de mémoire
fluxconfig-agent	50m	150Mi
fluxconfig-controller	100m	150Mi
fluent-bit	20m	150Mi
helm-controller	1000m	1Gi
source-controller	1000m	1Gi
kustomize-controller	1000m	1Gi
notification-controller	1000m	1Gi
image-automation-controller	1000m	1Gi
image-reflector-controller	1000m	1Gi

Si vous avez activé une stratégie Azure Gatekeeper Policy personnalisée ou intégrée, par exemple Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits, qui limite les ressources pour les conteneurs sur des clusters Kubernetes, vous devez vous assurer que les limites de ressources de la stratégie sont supérieures aux limites indiquées ci-dessus ou que l’espace de noms flux-system fait partie du paramètre excludedNamespaces dans l’attribution de stratégie.

Surveillance

Azure Monitor pour conteneurs exige que son DaemonSet soit exécuté en mode privilégié. Pour configurer correctement un cluster Kubernetes Charmed Canonical pour la supervision, exécutez la commande suivante :

juju config kubernetes-worker allow-privileged=true

Connexion au cluster

Ancienne version des agents utilisée

Certaines versions antérieures de l’agent ne prenaient pas en charge la fonctionnalité Cluster Connect. Si vous utilisez l’une de ces versions, vous pouvez voir cette erreur :

az connectedk8s proxy -n AzureArcTest -g AzureArcTest

Hybrid connection for the target resource does not exist. Agent might not have started successfully.

Assurez-vous d’utiliser l’extension d’Azure CLI connectedk8s version >= 1.2.0 et reconnectez votre cluster à Azure Arc. Vérifiez également que vous avez respecté tous les prérequis réseau pour Kubernetes avec Arc.

Si votre cluster se trouve derrière un proxy ou un pare-feu sortants, vérifiez que les connexions websocket sont activées pour *.servicebus.windows.net, ce qui est requis spécifiquement pour la fonctionnalité Connexion de cluster.

Fonctionnalité Connexion de cluster désactivée

Si les pods clusterconnect-agent et kube-aad-proxy sont manquants, la fonctionnalité de connexion de cluster est probablement désactivée sur le cluster et az connectedk8s proxy ne parvient pas à établir une session avec le cluster.

az connectedk8s proxy -n AzureArcTest -g AzureArcTest

Cannot connect to the hybrid connection because no agent is connected in the target arc resource.

Pour résoudre cette erreur, activez la fonctionnalité Connexion de cluster sur votre cluster.

az connectedk8s enable-features --features cluster-connect -n $CLUSTER_NAME -g $RESOURCE_GROUP

Activer les emplacements personnalisés à l’aide du principal de service

Lorsque vous connectez votre cluster à Azure Arc ou que vous activez des emplacements personnalisés sur un cluster existant, vous pouvez voir l'avertissement suivant :

Unable to fetch oid of 'custom-locations' app. Proceeding without enabling the feature. Insufficient privileges to complete the operation.

Cet avertissement se produit lorsque vous utilisez un principal de service pour vous connecter à Azure. Ce principal de service n’a pas les autorisations nécessaires pour obtenir des informations sur l’application utilisée par le service Azure Arc. Pour empêcher cette erreur, exécutez les étapes suivantes :

Connectez-vous à Azure CLI à l’aide de votre compte d’utilisateur. Récupérez l’ID d’objet de l’application Azure AD utilisée par le service Azure Arc :
```
az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query objectId -o tsv
```
Connectez-vous à Azure CLI à l’aide du principal de service. Utilisez la valeur <objectId> de l’étape ci-dessus pour activer les emplacements personnalisés sur le cluster :
- Pour activer des emplacements personnalisés lors de la connexion du cluster à Arc, exécutez la commande suivante :
```
az connectedk8s connect -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId>   
```
- Pour activer les emplacements personnalisés sur un cluster Kubernetes avec Azure Arc existant, exécutez la commande suivante :
```
az connectedk8s enable-features -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId> --features cluster-connect custom-locations
```

Open Service Mesh avec Azure Arc

Les étapes ci-dessous fournissent une aide concernant la validation du déploiement de tous les composants de l’extension Open Service Mesh (OSM) sur votre cluster.

Vérifier le déploiement du contrôleur OSM

kubectl get deployment -n arc-osm-system --selector app=osm-controller

Si le contrôleur OSM est sain, vous obtiendrez une sortie similaire à la sortie suivante :

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
osm-controller   1/1     1            1           59m

Vérifier le pod du contrôleur OSM

kubectl get pods -n arc-osm-system --selector app=osm-controller

Si le contrôleur OSM est sain, vous obtiendrez une sortie similaire à la sortie suivante :

NAME                            READY   STATUS    RESTARTS   AGE
osm-controller-b5bd66db-wglzl   0/1     Evicted   0          61m
osm-controller-b5bd66db-wvl9w   1/1     Running   0          31m

Même si un contrôleur a été expulsé à un moment donné, il en existe un autre qui est READY 1/1 et Running avec 0 des redémarrages. Si la colonne READY indique un résultat différent de 1/1, le maillage de services est en panne. La colonne READY avec 0/1 indique que le conteneur du plan de contrôle se bloque. Utilisez la commande suivante pour inspecter les journaux de contrôleur :

kubectl logs -n arc-osm-system -l app=osm-controller

La colonne READY avec un nombre supérieur à 1 après le signe / indique que des side-cars sont installés. Le contrôleur OSM ne fonctionnera probablement pas si des side-cars lui sont attachés.

Vérifier le service du contrôleur OSM

kubectl get service -n arc-osm-system osm-controller

Si le contrôleur OSM est sain, vous obtiendrez la sortie suivante :

NAME             TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)              AGE
osm-controller   ClusterIP   10.0.31.254   <none>        15128/TCP,9092/TCP   67m

Notes

La valeur CLUSTER-IP sera différente. Les NAME et PORT(S) du service doivent être identiques à ceux affichés dans la sortie.

Vérifier les points de terminaison du contrôleur OSM

kubectl get endpoints -n arc-osm-system osm-controller

Si le contrôleur OSM est sain, vous obtiendrez une sortie similaire à la sortie suivante :

NAME             ENDPOINTS                              AGE
osm-controller   10.240.1.115:9092,10.240.1.115:15128   69m

Si le cluster de l’utilisateur n’a pas de ENDPOINTS pour osm-controller, le plan de contrôle n’est pas sain. Cet état non sain peut être dû au blocage du pod du contrôleur OSM, ou le pod n’a peut-être jamais été déployé correctement.

Vérifier le déploiement de l’injecteur OSM

kubectl get deployments -n arc-osm-system osm-injector

Si l’injecteur OSM est sain, vous obtiendrez une sortie similaire à la sortie suivante :

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
osm-injector   1/1     1            1           73m

Vérifier le pod de l’injecteur OSM

kubectl get pod -n arc-osm-system --selector app=osm-injector

Si l’injecteur OSM est sain, vous obtiendrez une sortie similaire à la sortie suivante :

NAME                            READY   STATUS    RESTARTS   AGE
osm-injector-5986c57765-vlsdk   1/1     Running   0          73m

La colonne READY doit être 1/1. Toute autre valeur indiquerait un pod osm-injector non sain.

Vérifier le service de l’injecteur OSM

kubectl get service -n arc-osm-system osm-injector

Si l’injecteur OSM est sain, vous obtiendrez une sortie similaire à la sortie suivante :

NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
osm-injector   ClusterIP   10.0.39.54   <none>        9090/TCP   75m

Vérifiez que l’adresse IP indiquée pour le service osm-injector est 9090. Il ne doit y avoir aucun EXTERNAL-IP.

Vérifier les points de terminaison de l’injecteur OSM

kubectl get endpoints -n arc-osm-system osm-injector

Si l’injecteur OSM est sain, vous obtiendrez une sortie similaire à la sortie suivante :

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

Pour qu’OSM fonctionne, il doit y avoir au moins un point de terminaison pour osm-injector. L’adresse IP de vos points de terminaison d’injecteur OSM sera différente. Le port 9090 doit être le même.

Vérifier les webhooks Validating et Mutating

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Si le webhook de validation est sain, vous verrez une sortie similaire à ce qui suit :

NAME                     WEBHOOKS   AGE
osm-validator-mesh-osm   1          81m

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Si le webhook de mutation est sain, vous verrez une sortie similaire à ce qui suit :

NAME                  WEBHOOKS   AGE
arc-osm-webhook-osm   1          102m

Rechercher le service et le bundle d’autorité de certification du webhook de validation en utilisant la commande suivante :

kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'

Une configuration de webhook de validation bien faite aura une sortie similaire à celle-ci :

{
  "name": "osm-config-validator",
  "namespace": "arc-osm-system",
  "path": "/validate",
  "port": 9093
}

Rechercher le service et le bundle d’autorité de certification du webhook de mutation en utilisant la commande suivante :

kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq '.webhooks[0].clientConfig.service'

Une configuration de webhook de mutation bien faite aura une sortie similaire à celle-ci :

{
  "name": "osm-injector",
  "namespace": "arc-osm-system",
  "path": "/mutate-pod-creation",
  "port": 9090
}

Vérifiez si le contrôleur OSM a donné au webhook de validation (ou de mutation) un pack d’autorité de certification à l’aide de la commande suivante :

kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq -r '.webhooks[0].clientConfig.caBundle' | wc -c

kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq -r '.webhooks[0].clientConfig.caBundle' | wc -c

Exemple de sortie :

Le nombre dans la sortie indique le nombre d’octets ou la taille du pack de l’autorité de certification. S’il est vide, égal à 0 ou inférieur à 1000, le pack de l’autorité de certification n’est pas correctement approvisionné. Si le pack d’autorité de certification n'est pas correct, ValidatingWebhook générera une erreur.

Vérifiez la `osm-mesh-config` ressource

Vérifiez l’existence de la ressource :

kubectl get meshconfig osm-mesh-config -n arc-osm-system

Vérifiez le contenu de la MeshConfig OSM :

kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml

apiVersion: config.openservicemesh.io/v1alpha1
kind: MeshConfig
metadata:
  creationTimestamp: "0000-00-00A00:00:00A"
  generation: 1
  name: osm-mesh-config
  namespace: arc-osm-system
  resourceVersion: "2494"
  uid: 6c4d67f3-c241-4aeb-bf4f-b029b08faa31
spec:
  certificate:
    certKeyBitSize: 2048
    serviceCertValidityDuration: 24h
  featureFlags:
    enableAsyncProxyServiceMapping: false
    enableEgressPolicy: true
    enableEnvoyActiveHealthChecks: false
    enableIngressBackendPolicy: true
    enableMulticlusterMode: false
    enableRetryPolicy: false
    enableSnapshotCacheMode: false
    enableWASMStats: true
  observability:
    enableDebugServer: false
    osmLogLevel: info
    tracing:
      enable: false
  sidecar:
    configResyncInterval: 0s
    enablePrivilegedInitContainer: false
    logLevel: error
    resources: {}
  traffic:
    enableEgress: false
    enablePermissiveTrafficPolicyMode: true
    inboundExternalAuthorization:
      enable: false
      failureModeAllow: false
      statPrefix: inboundExtAuthz
      timeout: 1s
    inboundPortExclusionList: []
    outboundIPRangeExclusionList: []
    outboundPortExclusionList: []
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

osm-mesh-config Valeurs de ressources :

Clé	Type	Valeur par défaut	Exemples de commandes patch Kubectl
spec.traffic.enableEgress	bool	`false`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"enableEgress":false}}}' --type=merge`
spec.traffic.enablePermissiveTrafficPolicyMode	bool	`true`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"enablePermissiveTrafficPolicyMode":true}}}' --type=merge`
spec.traffic.outboundPortExclusionList	tableau	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge`
spec.traffic.outboundIPRangeExclusionList	tableau	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundIPRangeExclusionList":["10.0.0.0/32","1.1.1.1/24"]}}}' --type=merge`
spec.traffic.inboundPortExclusionList	tableau	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"inboundPortExclusionList":[6379,8080]}}}' --type=merge`
spec.certificate.serviceCertValidityDuration	string	`"24h"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"certificate":{"serviceCertValidityDuration":"24h"}}}' --type=merge`
spec.observability.enableDebugServer	bool	`false`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"enableDebugServer":false}}}' --type=merge`
spec.observability.osmLogLevel	string	`"info"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"osmLogLevel": "info"}}}}' --type=merge`
spec.observability.tracing.enable	bool	`false`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"enable":true}}}}' --type=merge`
spec.sidecar.enablePrivilegedInitContainer	bool	`false`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"enablePrivilegedInitContainer":true}}}' --type=merge`
spec.sidecar.logLevel	string	`"error"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"logLevel":"error"}}}' --type=merge`
spec.featureFlags.enableWASMStats	bool	`"true"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableWASMStats":"true"}}}' --type=merge`
spec.featureFlags.enableEgressPolicy	bool	`"true"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEgressPolicy":"true"}}}' --type=merge`
spec.featureFlags.enableMulticlusterMode	bool	`"false"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableMulticlusterMode":"false"}}}' --type=merge`
spec.featureFlags.enableSnapshotCacheMode	bool	`"false"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableSnapshotCacheMode":"false"}}}' --type=merge`
spec.featureFlags.enableAsyncProxyServiceMapping	bool	`"false"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableAsyncProxyServiceMapping":"false"}}}' --type=merge`
spec.featureFlags.enableIngressBackendPolicy	bool	`"true"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableIngressBackendPolicy":"true"}}}' --type=merge`
spec.featureFlags.enableEnvoyActiveHealthChecks	bool	`"false"`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEnvoyActiveHealthChecks":"false"}}}' --type=merge`

Vérifiez les espaces de noms

Notes

L’espace de noms arc-osm-system ne fait jamais partie d’un maillage de services et n’est jamais étiqueté ou annoté avec les clés/valeurs ci-dessous.

Nous utilisons la commande osm namespace add pour joindre des espaces de noms à un maillage de services donné. Lorsqu'un espace de noms Kubernetes fait partie du maillage, confirmez ce qui suit :

Affichez les annotations de l’espace de noms bookbuyer :

kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'

L’annotation suivante doit être présente :

{
  "openservicemesh.io/sidecar-injection": "enabled"
}

Affichez les étiquettes de l’espace de noms bookbuyer :

kubectl get namespace bookbuyer -o json | jq '.metadata.labels'

L’étiquette suivante doit être présente :

{
  "openservicemesh.io/monitored-by": "osm"
}

Si vous n’utilisez pas l’interface CLI osm, vous pouvez également ajouter manuellement ces annotations à vos espaces de noms. Si un espace de noms n’est pas annoté avec "openservicemesh.io/sidecar-injection": "enabled" ou n’a pas l’étiquette "openservicemesh.io/monitored-by": "osm", l’injecteur OSM n’ajoutera pas les side-cars Envoy.

Notes

Une fois que osm namespace add est appelé, seuls les nouveaux pods sont injectés avec un side-car Envoy. Les pods existants doivent être redémarrés à l’aide de la commande kubectl rollout restart deployment.

Vérifier les CRD SMI

Vérifiez si le cluster a les définitions de ressources personnalisées requises (CRD) à l’aide de la commande suivante :

kubectl get crds

Vérifiez que les CRD correspondent aux versions disponibles dans la branche des versions. Par exemple, si vous utilisez OSM-Arc v1.0.0-1, accédez à la page des versions prises en charge par SMI, puis sélectionnez v1.0 dans la liste déroulante Versions pour vérifier les versions de CRD en cours d’utilisation.

Obtenez les versions des CRD installées à l’aide de la commande suivante :

for x in $(kubectl get crds --no-headers | awk '{print $1}' | grep 'smi-spec.io'); do
    kubectl get crd $x -o json | jq -r '(.metadata.name, "----" , .spec.versions[].name, "\n")'
done

S’il manque des CRD, utilisez les commandes suivantes pour les installer sur le cluster. Si vous utilisez une version d’OSM-Arc qui n’est pas v1.0, veillez à remplacer la version dans la commande (par exemple, v1.1.0 serait release-v1.1).

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_http_route_group.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_tcp_route.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_traffic_access.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_traffic_split.yaml

Pour voir les modifications de CRD entre les versions, reportez-vous aux notes de publication d’OSM.

Résoudre les problèmes de gestion des certificats

Vous trouverez des informations sur la façon dont OSM émet et gère les certificats pour les proxies Envoy fonctionnant sur des pods d’application sur le site de documentation d’OSM.

Mettre à niveau Envoy

Lorsqu’un nouveau pod est créé dans un espace de noms supervisé par le module complémentaire, OSM injecte un side-car du proxy Envoy dans ce pod. Si vous devez mettre à jour la version de l’envoi, suivez les étapes du Guide de mise à niveau sur le site de documentation d’OSM.

Résolution des problèmes liés à Kubernetes avec Azure Arc et GitOps

Résolution générale des problèmes

Azure CLI

Agents Azure Arc

Connexion de clusters Kubernetes à Azure Arc

Problèmes de résolution du DNS

Problèmes de connectivité réseau sortante

Impossible de récupérer le certificat MSI

Autorisations du cluster insuffisantes

Impossible de connecter le cluster OpenShift à Azure Arc

Délai d’installation

Erreur de délai d’attente Helm

Erreur de validation Helm

Erreur du module CryptoHash

Gestion de GitOps

Flux v1 - Général

Flux v1 - Créer des configurations

sourceControlConfigurations remains Pending (Flux v1)

Flux v2 - Général

Flux v2 - Erreurs de webhook ou de test

Flux v2 - Erreur lors de l’installation de l’extension microsoft.flux

Flux v2 - Installation de l’extension microsoft.flux dans un cluster avec Azure AD Pod Identity activé

Flux v2 - Installation de l’extension microsoft.flux dans un cluster avec Kubenet Identity activé

Flux v2 : limites du processeur et de la mémoire d’installation d’extension microsoft.flux

Surveillance

Connexion au cluster

Ancienne version des agents utilisée

Fonctionnalité Connexion de cluster désactivée

Activer les emplacements personnalisés à l’aide du principal de service

Open Service Mesh avec Azure Arc

Vérifier le déploiement du contrôleur OSM

Vérifier le pod du contrôleur OSM

Vérifier le service du contrôleur OSM

Vérifier les points de terminaison du contrôleur OSM

Vérifier le déploiement de l’injecteur OSM

Vérifier le pod de l’injecteur OSM

Vérifier le service de l’injecteur OSM

Vérifier les points de terminaison de l’injecteur OSM

Vérifier les webhooks Validating et Mutating

Vérifiez la osm-mesh-config ressource

Vérifiez les espaces de noms

Vérifier les CRD SMI

Résoudre les problèmes de gestion des certificats

Mettre à niveau Envoy

Ressources supplémentaires

Ressources supplémentaires

`sourceControlConfigurations` remains `Pending` (Flux v1)

Flux v2 - Erreur lors de l’installation de l’extension `microsoft.flux`

Flux v2 - Installation de l’extension `microsoft.flux` dans un cluster avec Azure AD Pod Identity activé

Flux v2 - Installation de l’extension `microsoft.flux` dans un cluster avec Kubenet Identity activé

Flux v2 : limites du processeur et de la mémoire d’installation d’extension `microsoft.flux`

Vérifiez la `osm-mesh-config` ressource