Risolvere i problemi di estensione per i cluster Kubernetes abilitati per Azure Arc

Articolo
01/09/2025

Questo articolo descrive i suggerimenti per la risoluzione dei problemi comuni relativi alle estensioni del cluster, ad esempio GitOps (Flux v2) in Azure o Open Service Mesh (OSM).

Per informazioni sulla risoluzione dei problemi di Kubernetes abilitati per Azure Arc in generale, vedere Risolvere i problemi di Kubernetes abilitati per Azure Arc.

GitOps (Flux v2)

Nota

È possibile usare l'estensione Flux v2 in un cluster Kubernetes abilitato per Azure Arc o in un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes). Questi suggerimenti per la risoluzione dei problemi si applicano in genere a tutti i tipi di cluster.

Per informazioni generali sulla risoluzione dei problemi quando si usano fluxConfigurations le risorse, eseguire questi comandi dell'interfaccia della riga di comando di Azure con il --debug parametro :

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

Errori di esecuzione asciutta del webhook

Flux potrebbe non riuscire e visualizzare un errore simile a dry-run failed, error: admission webhook "<webhook>" does not support dry run. Per risolvere il problema, passare a o MutatingWebhookConfiguration.ValidatingWebhookConfiguration Nella configurazione impostare il valore per sideEffects su None o NoneOnDryRun.

Per altre informazioni, vedere Ricerca per categorie risolvere gli errori di "webhook non supporta l'esecuzione secca?".

Errori durante l'installazione dell'estensione microsoft.flux

L'estensione microsoft.flux installa i controller Flux e gli agenti GitOps di Azure in un cluster Kubernetes abilitato per Azure Arc o in un cluster servizio Azure Kubernetes (AKS). Se l'estensione non è già installata in un cluster e si crea una risorsa di configurazione GitOps per il cluster, l'estensione viene installata automaticamente.

Se si verifica un errore durante l'installazione o se l'estensione mostra uno Failed stato, assicurarsi che il cluster non disponga di criteri che limitano la flux-system creazione dello spazio dei nomi o di una qualsiasi delle risorse in tale spazio dei nomi.

Per un cluster del servizio Azure Kubernetes, assicurarsi che il Microsoft.ContainerService/AKS-ExtensionManager flag di funzionalità sia abilitato nella sottoscrizione di Azure:

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

Eseguire quindi il comando seguente per determinare se sono presenti altri problemi. Impostare il parametro del tipo di cluster (-t) su connectedClusters per Per un cluster abilitato per Azure Arc o su managedClusters per un cluster del servizio Azure Kubernetes. Se l'estensione è stata installata automaticamente quando è stata creata la configurazione di GitOps, il nome dell'estensione microsoft.flux è flux.

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

L'output consente di identificare il problema e come risolverlo. Le possibili azioni correttive includono:

Forzare l'eliminazione dell'estensione eseguendo az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>.
Disinstallare la versione Helm eseguendo helm uninstall flux -n flux-system.
Eliminare lo flux-system spazio dei nomi dal cluster eseguendo kubectl delete namespaces flux-system.

È quindi possibile creare una nuova configurazione di Flux, che installa automaticamente l'estensione microsoft.flux oppure è possibile installare manualmente l'estensione Flux.

Errori durante l'installazione dell'estensione microsoft.flux in un cluster con un'identità gestita dal pod Microsoft Entra

Se si tenta di installare l'estensione Flux in un cluster con un'identità gestita dal pod di Microsoft Entra, potrebbe verificarsi un errore nel extension-agent pod. L'output è simile all’esempio seguente:

{"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"}

Lo stato dell'estensione restituisce come 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}}\"}]}}",

In questo caso, il extension-agent pod tenta di ottenere il token dal servizio metadati dell'istanza di Azure nel cluster, ma la richiesta del token viene intercettata dall'identità del pod. Per risolvere il problema, eseguire l'aggiornamento alla versione più recente dell'estensione microsoft.flux .

Requisiti delle risorse di memoria e CPU per l'installazione dell'estensione microsoft.flux

I controller installati nel cluster Kubernetes quando si installa l'estensione microsoft.flux devono avere risorse di CPU e memoria sufficienti per pianificare correttamente in un nodo del cluster Kubernetes. Assicurarsi che il cluster soddisfi i requisiti minimi di memoria e risorsa CPU.

La tabella seguente elenca i limiti minimi e massimi per i potenziali requisiti di risorse cpu e memoria per questo scenario:

Nome contenitore	CPU minima	Memoria minima	CPU massima	Memoria massima
`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

Se è stato abilitato un criterio personalizzato o predefinito Criteri di Azure Gatekeeper che limita le risorse per i contenitori nei cluster Kubernetes, assicurarsi che i limiti delle risorse per i criteri siano superiori ai limiti indicati nella tabella precedente o che lo flux-system spazio dei nomi faccia parte del parametro nell'assegnazione dei excludedNamespaces criteri. Un esempio di criteri in questo scenario è Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits.

Flux v1

Nota

È consigliabile eseguire la migrazione a Flux v2 il prima possibile. Il supporto per le risorse di configurazione del cluster basate su Flux v1 create prima del 1° gennaio 2024 termina il 24 maggio 2025. A partire dal 1° gennaio 2024, non sarà possibile creare nuove risorse di configurazione del cluster basate su Flux v1.

Per risolvere i problemi relativi alla risorsa in Flux v1, eseguire questi comandi dell'interfaccia della sourceControlConfigurations riga di comando di Azure, incluso il --debug parametro :

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

Container Insights per Monitoraggio di Azure

Questa sezione fornisce informazioni sulla risoluzione dei problemi relativi ai dati analitici sui contenitori in Monitoraggio di Azure per i cluster Kubernetes abilitati per Azure Arc.

Abilitare la modalità con privilegi per un cluster Kubernetes con accesso canonico

Azure Monitor Container Insights richiede che kubernetes DaemonSet sia eseguito in modalità con privilegi. Per configurare correttamente un cluster Canonical Charmed Kubernetes per il monitoraggio, eseguire il comando seguente:

juju config kubernetes-worker allow-privileged=true

Non è possibile installare pod AMA in Oracle Linux 9.x

Se si tenta di installare l'agente di Monitoraggio di Azure (AMA) in un cluster Oracle Linux (Red Hat Enterprise Linux (RHEL)) 9.x Kubernetes, i pod AMA e il pod AMA-RS potrebbero non funzionare correttamente a causa del addon-token-adapter contenitore nel pod. Quando si controllano i log del ama-logs-rs pod, in addon-token-adapter containerviene visualizzato un output simile all'esempio seguente:

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.

Questo errore si verifica perché l'installazione dell'estensione richiede il modulo iptable_nat, ma questo modulo non viene caricato automaticamente nelle distribuzioni Oracle Linux (RHEL) 9.x.

Per risolvere questo problema, è necessario caricare in modo esplicito il iptables_nat modulo in ogni nodo del cluster. Usare il modprobe comando sudo modprobe iptables_nat. Dopo aver eseguito l'accesso a ogni nodo e aver aggiunto manualmente il modulo iptable_nat, ripetere l'installazione di AMA.

Nota

L'esecuzione di questo passaggio non rende persistente il modulo iptables_nat.

Open Service Mesh abilitato per Azure Arc

Questa sezione illustra i comandi che è possibile usare per convalidare e risolvere i problemi di distribuzione dei componenti dell'estensione Open Service Mesh (OSM) nel cluster.

Controllare la distribuzione del controller OSM

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

Se il controller OSM è integro, viene visualizzato un output simile al seguente:

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

Controllare i pod del controller OSM

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

Se il controller OSM è integro, viene visualizzato un output simile all'esempio seguente:

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

Anche se uno stato di Evicted un controller è a un certo punto, un altro controller ha lo READY stato 1/1 e Running con 0 i riavvii. Se lo READY stato è diverso da 1/1, la mesh del servizio si trova in uno stato interrotto. Se READY è 0/1, il contenitore del piano di controllo si arresta in modo anomalo.

Usare il comando seguente per controllare i log del controller:

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

Se lo READY stato è un numero maggiore di 1 dopo la barra (/), le sidecar vengono installate. Il controller OSM in genere non funziona correttamente quando le sidecar sono collegate.

Controllare il servizio controller OSM

Per controllare il servizio controller OSM, eseguire questo comando:

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

Se il controller OSM è integro, viene visualizzato un output simile all'esempio seguente:

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

Nota

Il valore effettivo per CLUSTER-IP sarà diverso da questo esempio. I valori per NAME e PORT(S) devono corrispondere a quanto illustrato in questo esempio.

Controllare gli endpoint del controller OSM

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

Se il controller OSM è integro, viene visualizzato un output simile all'esempio seguente:

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

Se il cluster non ha alcun ENDPOINTS valore osm-controller, il piano di controllo non è integro. Questo stato non integro indica che il pod del controller si è arrestato in modo anomalo o che non è mai stato distribuito correttamente.

Controllare la distribuzione dell'iniettore OSM

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

Se l'iniettore OSM è integro, viene visualizzato un output simile all'esempio seguente:

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

Controllare il pod dell'iniettore OSM

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

Se l'iniettore OSM è integro, viene visualizzato un output simile all'esempio seguente:

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

Lo READY stato deve essere 1/1. Qualsiasi altro valore indica un pod dell'iniettore OSM non integro.

Controllare il servizio di inserimento del sistema operativo

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

Se l'iniettore OSM è integro, viene visualizzato un output simile all'esempio seguente:

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

Assicurarsi che l'indirizzo IP elencato per il osm-injector servizio sia 9090. Non deve essere elencato alcun valore per EXTERNAL-IP.

Controllare gli endpoint dell'oggetto dell'iniettore OSM

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

Se l'iniettore OSM è integro, viene visualizzato un output simile all'esempio seguente:

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

Per il funzionamento di OSM, deve essere presente almeno un endpoint per osm-injector. L'indirizzo IP degli endpoint dell'injector OSM varia, ma il valore 9090 della porta deve essere lo stesso.

Controllare i webhook: convalida e modifica

Controllare il webhook di convalida eseguendo il comando seguente:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Se il webhook di convalida è integro, viene visualizzato un output simile all'esempio seguente:

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

Controllare il webhook Di modifica eseguendo il comando seguente:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Se il webhook di modifica è integro, viene visualizzato un output simile all'esempio seguente:

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

Verificare la presenza del servizio e del bundle dell'autorità di certificazione (bundle CA) del webhook di convalida usando questo comando:

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

Un webhook di convalida ben configurato ha un output simile a questo esempio:

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

Verificare la presenza del servizio e del bundle CA del webhook di mutazione usando il seguente comando:

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

Un webhook mutato ben configurato ha un output simile a questo esempio:

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

Verificare se al controller OSM è stato assegnato il webhook di convalida (o modifica) di un bundle CA usando il comando seguente:

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

Output di esempio:

Il numero nell'output indica il numero di byte o le dimensioni del bundle DELLA CA. Se l'output è vuoto, 0 o un numero inferiore a 1.000, il provisioning del bundle CA non viene eseguito correttamente. Senza un bundle CA corretto, ValidatingWebhook genera un errore.

Controllare la risorsa `osm-mesh-config`

Verificare l'esistenza della risorsa:

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

Controllare il valore dell'impostazione OSM meshconfig :

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

Cercare l'output simile a questo esempio:

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

Nella tabella seguente sono elencati i osm-mesh-config valori delle risorse:

Chiave	Type	Default value	Esempi di comandi 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`	array	`[]`	`kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge`
`spec.traffic.outboundIPRangeExclusionList`	array	`[]`	`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`	array	`[]`	`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`

Controllare gli spazi dei nomi

Nota

Lo arc-osm-system spazio dei nomi non fa mai parte di una mesh di servizi e non viene mai etichettato o annotato con le coppie chiave/valore illustrate di seguito.

È possibile usare il osm namespace add comando per unire spazi dei nomi a una mesh di servizi specifica. Quando uno spazio dei nomi Kubernetes fa parte della mesh, completare i passaggi seguenti per verificare che i requisiti siano soddisfatti.

Visualizzare le annotazioni dello spazio dei bookbuyer nomi:

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

L'annotazione seguente deve essere presente:

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

Visualizzare le etichette dello spazio dei bookbuyer nomi:

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

L'etichetta seguente deve essere presente:

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

Se non si usa l'interfaccia della osm riga di comando, è possibile aggiungere manualmente queste annotazioni agli spazi dei nomi. Se uno spazio dei nomi non è annotato con "openservicemesh.io/sidecar-injection": "enabled"o se non è etichettato con "openservicemesh.io/monitored-by": "osm", l'iniettore OSM non aggiunge sidecar Envoy.

Nota

Dopo aver chiamato osm namespace add, vengono inseriti solo nuovi pod con un sidecar Envoy. I pod esistenti devono essere riavviati usando il kubectl rollout restart deployment comando .

Verificare le CRL SMI

Per OSM Service Mesh Interface (SMI), verificare se il cluster ha le definizioni di risorse personalizzate necessarie :For the OSM Service Mesh Interface (SMI), check in the cluster has the required custom resource definitions (CRDs):

kubectl get crds

Assicurarsi che i CRL corrispondano alle versioni disponibili nel ramo di rilascio. Per verificare quali versioni CRD sono in uso, vedere Versioni supportate di SMI e selezionare la versione nel menu Versioni .

Ottenere le versioni dei CRL installati usando il comando seguente:

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

Se i CRD non sono presenti, usare i comandi seguenti per installarli nel cluster. Sostituire la versione in questi comandi in base alle esigenze( ad esempio, anziché v1.1.0, è possibile usare 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

Per vedere in che modo le versioni CRD cambiano tra le versioni, vedere le note sulla versione di OSM.

Risolvere i problemi di gestione dei certificati

Per informazioni su come OSM rilascia e gestisce i certificati per i proxy Envoy in esecuzione nei pod dell'applicazione, vedere la documentazione di OSM.

Eseguire l'aggiornamento di Envoy

Quando viene creato un nuovo pod in uno spazio dei nomi monitorato dal componente aggiuntivo, OSM inserisce un sidecar proxy Envoy in tale pod. Se è necessario aggiornare la versione di Envoy, seguire la procedura descritta nella Guida all'aggiornamento nella documentazione di OSM.

Altre informazioni sulle estensioni del cluster.
Visualizzare i suggerimenti generali per la risoluzione dei problemi per i cluster Kubernetes abilitati per ARC.

Condividi tramite

Risolvere i problemi di estensione per i cluster Kubernetes abilitati per Azure Arc

GitOps (Flux v2)

Errori di esecuzione asciutta del webhook

Errori durante l'installazione dell'estensione microsoft.flux

Errori durante l'installazione dell'estensione microsoft.flux in un cluster con un'identità gestita dal pod Microsoft Entra

Requisiti delle risorse di memoria e CPU per l'installazione dell'estensione microsoft.flux

Flux v1

Container Insights per Monitoraggio di Azure

Abilitare la modalità con privilegi per un cluster Kubernetes con accesso canonico

Non è possibile installare pod AMA in Oracle Linux 9.x

Open Service Mesh abilitato per Azure Arc

Controllare la distribuzione del controller OSM

Controllare i pod del controller OSM

Controllare il servizio controller OSM

Controllare gli endpoint del controller OSM

Controllare la distribuzione dell'iniettore OSM

Controllare il pod dell'iniettore OSM

Controllare il servizio di inserimento del sistema operativo

Controllare gli endpoint dell'oggetto dell'iniettore OSM

Controllare i webhook: convalida e modifica

Controllare la risorsa `osm-mesh-config`

Controllare gli spazi dei nomi

Verificare le CRL SMI

Risolvere i problemi di gestione dei certificati

Eseguire l'aggiornamento di Envoy

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Risolvere i problemi di estensione per i cluster Kubernetes abilitati per Azure Arc

GitOps (Flux v2)

Errori di esecuzione asciutta del webhook

Errori durante l'installazione dell'estensione microsoft.flux

Errori durante l'installazione dell'estensione microsoft.flux in un cluster con un'identità gestita dal pod Microsoft Entra

Requisiti delle risorse di memoria e CPU per l'installazione dell'estensione microsoft.flux

Flux v1

Container Insights per Monitoraggio di Azure

Abilitare la modalità con privilegi per un cluster Kubernetes con accesso canonico

Non è possibile installare pod AMA in Oracle Linux 9.x

Open Service Mesh abilitato per Azure Arc

Controllare la distribuzione del controller OSM

Controllare i pod del controller OSM

Controllare il servizio controller OSM

Controllare gli endpoint del controller OSM

Controllare la distribuzione dell'iniettore OSM

Controllare il pod dell'iniettore OSM

Controllare il servizio di inserimento del sistema operativo

Controllare gli endpoint dell'oggetto dell'iniettore OSM

Controllare i webhook: convalida e modifica

Controllare la risorsa osm-mesh-config

Controllare gli spazi dei nomi

Verificare le CRL SMI

Risolvere i problemi di gestione dei certificati

Eseguire l'aggiornamento di Envoy

Contenuto correlato

Commenti e suggerimenti

Risorse aggiuntive

Controllare la risorsa `osm-mesh-config`