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

Article
01/10/2025

Cet article décrit des conseils de résolution des problèmes courants liés aux extensions de cluster comme GitOps (Flux v2) dans Azure ou Open Service Mesh (OSM).

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

GitOps (Flux v2)

Remarque

Vous pouvez utiliser l’extension Flux v2 dans un cluster Kubernetes avec Azure Arc ou dans un cluster AKS (Azure Kubernetes Service). Ces conseils de dépannage s’appliquent généralement à tous les types de clusters.

Pour obtenir de l’aide générale sur la résolution des problèmes lorsque vous utilisez des ressources fluxConfigurations, exécutez ces commandes Azure CLI avec le paramètre --debug :

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

Erreurs de test à blanc de webhook

Flux peut échouer et afficher une erreur similaire à dry-run failed, error: admission webhook "<webhook>" does not support dry run. Pour résoudre le problème, accédez à ValidatingWebhookConfiguration ou MutatingWebhookConfiguration. Dans la configuration, définissez la valeur de sideEffects sur None ou NoneOnDryRun.

Pour plus d’informations, consultez Comment faire pour résoudre les erreurs « webhook qui ne prend pas en charge les tests » ?.

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 un cluster Kubernetes avec Azure Arc ou un cluster 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 le cluster, l’extension est installée automatiquement.

Si vous rencontrez une erreur lors de l’installation ou si l’extension affiche un état Failed, assurez-vous que le cluster n’a pas de stratégies limitant la création de l’espace de noms flux-system ou de n’importe laquelle de ces ressources dans cet espace de noms.

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

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

Exécutez ensuite la commande suivante 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 Azure Arc ou sur managedClusters pour un cluster AKS. Si l’extension a été installée automatiquement lorsque vous avez créé votre configuration GitOps, le nom de l’extension microsoft.flux est flux.

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

La sortie peut vous aider à identifier le problème et à le résoudre. Les actions de correction possibles sont les suivantes :

Forcez 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 l’espace de noms flux-system du cluster en exécutant kubectl delete namespaces flux-system.

Vous pouvez ensuite créer une nouvelle configuration Flux, qui installe automatiquement l’extension microsoft.flux, ou vous pouvez installer l’extension Flux manuellement.

Erreurs lors de l’installation de l’extension microsoft.flux dans un cluster disposant d’une identité managée par pod Microsoft Entra

Si vous tentez d’installer l’extension Flux dans un cluster disposant d’une identité managée par un pod Microsoft Entra, une erreur peut se produire dans le pod extension-agent. La sortie ressemble à cet exemple :

{"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 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 extension-agent tente d’obtenir son jeton à partir du service de métadonnées d’instance Azure sur le cluster, mais la demande de jeton est interceptée par l’identité de pod. Pour résoudre ce problème, mettez à niveau vers la dernière version de l’extension microsoft.flux.

Configuration requise pour la mémoire et le processeur pour l’installation de l’extension microsoft.flux

Les contrôleurs installés dans votre cluster Kubernetes lorsque vous installez l’extension microsoft.flux doivent disposer de suffisamment de ressources processeur et mémoire pour planifier correctement sur un nœud de cluster Kubernetes. Assurez-vous que votre cluster répond aux exigences minimales en matière de mémoire et de ressources processeur.

Le tableau suivant répertorie les limites minimales et maximales pour les besoins potentiels en ressources processeur et mémoire pour ce scénario :

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	1,000 m	1 Gi
`source-controller`	50 m	64 Mi	1,000 m	1 Gi
`kustomize-controller`	100 m	64 Mi	1,000 m	1 Gi
`notification-controller`	100 m	64 Mi	1,000 m	1 Gi
`image-automation-controller`	100 m	64 Mi	1,000 m	1 Gi
`image-reflector-controller`	100 m	64 Mi	1,000 m	1 Gi

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

Flux v1

Remarque

Nous vous recommandons d’effectuer la migration vers Flux v2 dès que possible. La prise en charge des ressources de configuration de cluster basées sur Flux v1 créées avant le 1er janvier 2024 prendra fin 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, notamment le paramètre --debug :

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux 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 dans Azure Monitor pour les clusters Kubernetes avec Azure Arc.

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

Azure Monitor Container Insights nécessite que son DaemonSet Kubernetes 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 des pods AMA sur Oracle Linux 9.x

Si vous essayez d’installer l’agent Azure Monitor (AMA) sur un cluster Oracle Linux (Red Hat Enterprise Linux (RHEL)) 9.x, les pods AMA et le pod AMA-RS peuvent ne pas fonctionner correctement en raison du conteneur addon-token-adapter dans le pod. Lorsque vous vérifiez les journaux d’activité du pod ama-logs-rs, dans addon-token-adapter container, vous voyez la sortie similaire à l’exemple suivant :

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. Utilisez la commande modprobe 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 illustre 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, une sortie similaire à l’exemple suivant s’affiche :

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 un état Evicted à un moment donné, un autre contrôleur a l’état READY 1/1 et Running avec 0 redémarrages. Si l’état READY est autre que 1/1, le maillage de service est dans un état rompu. Si READY est 0/1, 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

Si l’état READY est supérieur à 1 après la barre oblique (/), les sidecars sont installés. Le contrôleur OSM ne fonctionne généralement pas correctement lorsque des sidecars sont attachés.

Vérifier le service du contrôleur OSM

Pour vérifier le service du contrôleur OSM, exécutez cette commande :

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

Si le contrôleur OSM est sain, une sortie similaire à l’exemple suivant s’affiche :

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

Remarque

La valeur réelle de CLUSTER-IP sera différente de cet exemple. Les valeurs de NAME et de PORT(S) doivent correspondre à ce qui est illustré dans cet exemple.

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, une sortie similaire à l’exemple suivant s’affiche :

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

Si le cluster ne présente pas de ENDPOINTS ayant la valeur 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, une sortie similaire à l’exemple suivant s’affiche :

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

Vérifier le pod d’injecteur OSM

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

Si l’injecteur OSM est sain, une sortie similaire à l’exemple suivant s’affiche :

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

L’état 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, une sortie similaire à l’exemple suivant s’affiche :

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 répertoriée pour le service osm-injector est 9090. Il ne doit pas y avoir de valeur répertoriée pour 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, une sortie similaire à l’exemple suivant s’affiche :

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 la valeur du port 9090 doit être la même.

Vérifier les webhooks : Validating et Mutating

Vérifiez le webhook Validating en exécutant la commande suivante :

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Si le webhook Validating est sain, une sortie similaire à l’exemple suivant s’affiche :

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

Vérifiez le webhook Mutating en exécutant la commande suivante :

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Si le webhook Mutating est sain, une sortie similaire à l’exemple suivant s’affiche :

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

Recherchez le service et le pack d’autorité de certification (CA) du webhook Validating à l’aide de cette commande :

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

Une sortie de webhook Validating bien configurée présente une sortie similaire à celle de cet exemple :

{
  "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 sortie de webhook Mutating bien configurée présente une sortie similaire à celle de cet exemple :

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

Vérifiez si le contrôleur OSM a donné au webhook Validating (ou Mutating) 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 représente le nombre d’octets ou la taille du pack de l’autorité de certification. Si la sortie est vide, ou s’il affiche 0 ou un nombre inférieur à 1 000, le pack d’autorité de certification n’est pas correctement approvisionné. Sans pack d’autorité de certification correct, 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 la valeur du paramètre OSM meshconfig :

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

Trouvez la sortie qui ressemble à cet exemple :

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: ""

Le tableau suivant répertorie les valeurs de ressource osm-mesh-config :

Clé	Type	Default value	Exemples de commandes de 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 n’est jamais étiqueté ou annoté avec les paires clé/valeur affichées ici.

Vous pouvez utiliser 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, effectuez les étapes suivantes pour vérifier 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 l’interface CLI osm, vous pouvez 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 à l’aide de la commande kubectl rollout restart deployment.

Vérifier les CRD SMI

Pour l’interface SMI (Service Mesh Interface) OSM, vérifiez si le cluster dispose des définitions de ressources personnalisées (CRD) requises :

kubectl get crds

Vérifiez que les CRD correspondent aux versions disponibles dans la branche des versions. Pour vérifier les versions CRD utilisées, consultez Versions prises en charge par SMI et sélectionnez votre version dans le menu Versions.

Obtenez les versions des CRD installées 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, au lieu de v1.1.0, vous pouvez utiliser 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 différences entre les versions CRD publiées, consultez les notes de publication 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 sidecar de proxy Envoy dans ce pod. Si vous devez mettre à jour la version d’Envoy, suivez les étapes du guide de mise à niveau sur le site de documentation d’OSM.

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.

Partager via

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

GitOps (Flux v2)

Erreurs de test à blanc de webhook

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

Erreurs lors de l’installation de l’extension microsoft.flux dans un cluster disposant d’une identité managée par pod Microsoft Entra

Configuration requise pour la mémoire et le processeur pour l’installation de l’extension microsoft.flux

Flux v1

Azure Monitor Container Insights

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

Impossible d’installer des pods 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 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 d’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

Commentaires

Ressources supplémentaires

Partager via

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

GitOps (Flux v2)

Erreurs de test à blanc de webhook

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

Erreurs lors de l’installation de l’extension microsoft.flux dans un cluster disposant d’une identité managée par pod Microsoft Entra

Configuration requise pour la mémoire et le processeur pour l’installation de l’extension microsoft.flux

Flux v1

Azure Monitor Container Insights

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

Impossible d’installer des pods 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 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 d’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

Contenu connexe

Commentaires

Ressources supplémentaires

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