Résoudre les problèmes d’extension pour les clusters Kubernetes avec Azure Arc

Article
12/22/2023

Ce document fournit des conseils de dépannage pour les problèmes courants liés aux extensions de cluster, telles que GitOps (Flux v2) et Open Service Mesh.

Pour résoudre les problèmes généraux liés à Kubernetes avec Azure Arc, consultez Résoudre les problèmes Kubernetes avec Azure Arc.

GitOps (Flux v2)

Remarque

L’extension Flux v2 peut être utilisée dans des clusters Kubernetes avec Azure Arc ou dans des clusters AKS (Azure Kubernetes Service). Ces conseils de dépannage s’appliquent généralement quel que soit le type de cluster.

Pour obtenir de l’aide générale sur la résolution des problèmes liés aux ressources fluxConfigurations, 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

Erreurs de webhook/exécution sèche

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 ?.

Erreurs 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éer une ressource de configuration GitOps pour ce cluster, l’extension est installée automatiquement.

Si vous rencontrez une erreur lors de l’installation ou si l’extension est dans un état d’échec, assurez-vous que le cluster n’a pas de stratégies qui limitent la création de flux-system l’espace de noms ou des ressources dans cet espace de noms.

Pour un cluster AKS, vérifiez que l’abonnement a activé l’indicateur de fonctionnalité Microsoft.ContainerService/AKS-ExtensionManager.

az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager

Après cela, exécutez cette commande pour déterminer s’il existe d’autres problèmes. Définissez le paramètre de type de cluster (-t) sur connectedClusters pour un cluster avec Arc ou managedClusters pour un cluster AKS. Le nom de l’extension microsoft.flux est « 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.

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

Les résultats affichés peuvent vous aider à déterminer ce qui s’est passé et comment le corriger. Les actions de correction possibles sont les suivantes :

Forcer la suppression de l’extension en exécutant az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>
Désinstallez la version Helm en exécutant helm uninstall flux -n flux-system
Supprimez flux-systeml’espace de noms du cluster en exécutant kubectl delete namespaces flux-system

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

Erreurs lors de l’installation de l’extension `microsoft.flux` dans un cluster avec Microsoft Entra Pod Identity activé

Si vous tentez d’installer l’extension Flux dans un cluster où Microsoft Entra 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.

"{\"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}}\"}]}}",

Dans ce cas, le pod d’agent d’extension tente d’obtenir son jeton à partir de IMDS sur le cluster. mais la demande de jeton est interceptée par l’identité de pod ). Pour résoudre ce problème, mettre à niveau vers la dernière version de l’extension microsoft.flux.

Problèmes liés à l’identité kubelet lors de l’installation de l’extension `microsoft.flux` dans un cluster AKS

Avec les clusters AKs, 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 qu’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.

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

Vérifier que la mémoire et l’UC requises pour l’installation de l’extension `microsoft.flux` sont remplies

Les contrôleurs installés dans votre cluster Kubernetes avec l’extension microsoft.flux nécessitent des ressources processeur et mémoire pour planifier correctement sur les nœuds de cluster Kubernetes. Assurez-vous que votre cluster est en mesure de répondre aux ressources minimales de mémoire et d’UC qui peuvent être demandées. Notez également les limites maximales pour les besoins potentiels en ressources processeur et mémoire indiqués ici.

Nom du conteneur	Processeur minimal	Mémoire minimale	Processeur maximal	Quantité de mémoire maximale
fluxconfig-agent	5 m	30 Mi	50 m	150 Mi
fluxconfig-controller	5 m	30 Mi	100 m	150 Mi
fluent-bit	5 m	30 Mi	20 m	150 Mi
helm-controller	100 m	64 Mi	1000 m	1 Gi
source-controller	50 m	64 Mi	1000 m	1 Gi
kustomize-controller	100 m	64 Mi	1000 m	1 Gi
notification-controller	100 m	64 Mi	1000 m	1 Gi
image-automation-controller	100 m	64 Mi	1000 m	1 Gi
image-reflector-controller	100 m	64 Mi	1000 m	1 Gi

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

Flux v1

Remarque

Nous vous recommandons d’effectuer une migration vers Flux v2 dès que possible. La prise en charge des ressources de configuration du cluster basées sur Flux v1, créées avant le 1er janvier 2024, s’achève le 24 mai 2025. À compter du 1er janvier 2024, vous ne pouvez plus créer de ressources de configuration de cluster basées sur Flux v1.

Pour résoudre les problèmes liés à la ressource sourceControlConfigurations dans Flux v1, exécutez ces commandes Azure CLI avec --debug paramètre spécifié :

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

Azure Monitor Container Insights

Cette section fournit de l’aide pour résoudre les problèmes liés à Azure Monitor Container Insights pour les clusters Kubernetes avec Azure Arc.

Activation du mode privilégié pour le cluster Kubernetes Charmed Canonical

Azure Monitor Container Insights nécessite que son DaemonSet s’exécute 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

Impossible d’installer l’agent Azure Monitor (AMA) sur Oracle Linux 9.x

Lorsque vous essayez d’installer l’agent Azure Monitor (AMA) sur un cluster Oracle Linux (RHEL) 9.x Kubernetes, les pods AMA et le pod AMA-RS peuvent ne pas fonctionner correctement en raison du conteneur addon-token-adapter dans le pod. Avec cette erreur, lors de la vérification des journaux du pod ama-logs-rs , addon-token-adapter container, vous voyez une sortie similaire à ce qui suit :

Command: kubectl -n kube-system logs ama-logs-rs-xxxxxxxxxx-xxxxx -c addon-token-adapter
 
Error displayed: error modifying iptable rules: error adding rules to custom chain: running [/sbin/iptables -t nat -N aad-metadata --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory

iptables v1.8.9 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)

Perhaps iptables or your kernel needs to be upgraded.

Cette erreur se produit, car l’installation de l’extension nécessite le module iptable_nat, mais ce module n’est pas automatiquement chargé dans les distributions Oracle Linux (RHEL) 9.x.

Pour résoudre ce problème, vous devez charger explicitement le module iptables_nat sur chaque nœud du cluster à l’aide de la modprobe commande sudo modprobe iptables_nat. Une fois connecté à chaque nœud et ajouté manuellement le module iptable_nat, réessayez l’installation d’AMA.

Remarque

L’exécution de cette étape ne rend pas le module iptables_nat persistant.

Open Service Mesh avec Azure Arc

Cette section fournit des commandes que vous pouvez utiliser pour valider et résoudre les problèmes de déploiement des composants d’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 voyez une sortie similaire à :

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

Vérifier les pods du contrôleur OSM

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

Si le contrôleur OSM est sain, vous voyez une sortie similaire à :

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é supprimé à un moment donné, il y en a un autre qui est READY 1/1 et Running avec 0 redémarrages. Si la colonne READY est autre que 1/1, le maillage de service est dans un état rompu. 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 / indique qu’il existe des side-cars installés. Le contrôleur OSM ne fonctionne généralement pas correctement avec les side-cars attachés.

Vérifier le service de contrôleur OSM

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

Si le contrôleur OSM est sain, vous voyez 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

Remarque

La CLUSTER-IP sera différente. Le service NAME et PORT(S) doivent correspondre à ce qui est illustré ici.

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 voyez une sortie similaire à :

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

Si le cluster n’a pas de ENDPOINTS pour osm-controller, le plan de contrôle n’est pas sain. Cet état non sain signifie que le pod du contrôleur s’est écrasé ou qu’il n’a 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 voyez une sortie similaire à :

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

Vérifier le pod injecteur OSM

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

Si l’injecteur OSM est sain, vous voyez une sortie similaire à :

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

La colonne READY doit être 1/1. Toute autre valeur indique un pod injecteur OSM défectueux.

Vérifier le service d’injecteur OSM

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

Si l’injecteur OSM est sain, vous voyez une sortie similaire à :

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 d’injecteur OSM

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

Si l’injecteur OSM est sain, vous voyez une sortie similaire à :

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 varie, mais le port 9090 doit être le même.

Vérifier les webhooks Validating et Mutating

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Si la Validation webhook est saine, vous voyez une sortie similaire à :

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

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Si la webhook mutant est saine, vous voyez une sortie similaire à :

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

Recherchez le service et le bundle d’autorité de certification du Validation webhook à l’aide de cette commande :

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

Une configuration bien configurée validation de webhook aura une sortie similaire à :

{
  "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 bien configurée la configuration de webhook aura une sortie similaire à la suivante :

{
  "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. Si la sortie est vide, 0 ou un nombre inférieur à 1 000, le bundle d’autorité de certification n’est pas correctement approvisionné. Sans bundle d’autorité de certification correct, le ValidatingWebhook génère 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

La sortie doit ressembler à celle-ci :

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

Remarque

L’espace de noms arc-osm-system ne participe jamais à un maillage de service et ne sera jamais étiqueté ou annoté avec les clés/valeurs affichées ici.

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, procédez comme suit pour confirmer que les exigences sont remplies.

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 osm CLI, 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’est pas étiqueté avec "openservicemesh.io/monitored-by": "osm", l’injecteur OSM n’ajoute pas de sidecars Envoy.

Remarque

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 avec 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. Pour vérifier quelles versions CRD sont en cours d’utilisation, visitez la page des versions prises en charge de SMI et sélectionnez votre version dans la liste déroulante Versions.

Obtenez les versions des CRD installés avec 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. Remplacez la version dans ces commandes si nécessaire (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 surveillé par le module complémentaire, OSM injecte un side-car 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.

Étapes suivantes

En savoir plus sur les extensions de cluster .
Consultez les conseils généraux de résolution des problèmes pour les clusters Kubernetes avec Arc.

Résoudre les problèmes d’extension pour les clusters Kubernetes avec Azure Arc

GitOps (Flux v2)

Erreurs de webhook/exécution sèche

Erreurs lors de l’installation de l’extension microsoft.flux

Erreurs lors de l’installation de l’extension microsoft.flux dans un cluster avec Microsoft Entra Pod Identity activé

Problèmes liés à l’identité kubelet lors de l’installation de l’extension microsoft.flux dans un cluster AKS

Vérifier que la mémoire et l’UC requises pour l’installation de l’extension microsoft.flux sont remplies

Flux v1

Azure Monitor Container Insights

Activation du mode privilégié pour le cluster Kubernetes Charmed Canonical

Impossible d’installer l’agent Azure Monitor (AMA) sur Oracle Linux 9.x

Open Service Mesh avec Azure Arc

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

Vérifier les pods du contrôleur OSM

Vérifier le service de 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 injecteur OSM

Vérifier le service d’injecteur OSM

Vérifier les points de terminaison d’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

Étapes suivantes

Ressources supplémentaires

Erreurs lors de l’installation de l’extension `microsoft.flux`

Erreurs lors de l’installation de l’extension `microsoft.flux` dans un cluster avec Microsoft Entra Pod Identity activé

Problèmes liés à l’identité kubelet lors de l’installation de l’extension `microsoft.flux` dans un cluster AKS

Vérifier que la mémoire et l’UC requises pour l’installation de l’extension `microsoft.flux` sont remplies

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