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

Articolo
10/16/2024

Questo documento fornisce suggerimenti per la risoluzione dei problemi comuni relativi alle estensioni del cluster, ad esempio GitOps (Flux v2) e Open Service Mesh.

Per informazioni sulla risoluzione dei problemi generali relativi a Kubernetes abilitati per Azure Arc, vedere Risolvere i problemi di Kubernetes abilitati per Azure Arc.

GitOps (Flux v2)

Nota

L'estensione Flux v2 può essere usata nei cluster Kubernetes abilitati per Azure Arc o nei cluster del servizio Azure Kubernetes. Questi suggerimenti per la risoluzione dei problemi si applicano in genere indipendentemente dal tipo di cluster.

Per informazioni generali sulla risoluzione dei problemi relativi alle risorse fluxConfigurations, eseguire questi comandi dell'interfaccia della riga di comando di Azure con il parametro --debug specificato:

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

Errori di esecuzione di webhook/dry

Se Flux non riesce a riconciliarsi con un errore come dry-run failed, error: admission webhook "<webhook>" does not support dry run, è possibile risolvere il problema trovando ValidatingWebhookConfiguration o MutatingWebhookConfiguration e impostando sideEffects su None o NoneOnDryRun:

Per altre informazioni, vedere Come risolvere gli errori di webhook does not support dry run?

Errori di installazione dell'estensione `microsoft.flux`

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

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

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

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

Successivamente, eseguire questo comando per determinare se sono presenti altri problemi. Impostare il parametro di tipo cluster (-t) su connectedClusters per un cluster abilitato per Arc o managedClusters per un cluster del servizio Azure Kubernetes. Il nome dell'estensione microsoft.flux è "flux" se l'estensione è stata installata automaticamente durante la creazione di una configurazione GitOps. Cercare informazioni nell'oggetto statuses.

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

I risultati visualizzati consentono di determinare cosa è andato storto e come risolvere il problema. 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 spazio dei nomi flux-system dal cluster eseguendo kubectl delete namespaces flux-system

Successivamente, è possibile ricreare una configurazione del flusso, che installa automaticamente l'estensione microsoft.flux, oppure reinstallare manualmente l'estensione del flusso.

Errori durante l'installazione dell'estensione `microsoft.flux` in un cluster con identità del pod di Microsoft Entra abilitata

Se si tenta di installare l'estensione Flux in un cluster con Identità pod di Microsoft Entra abilitata, potrebbe verificarsi un errore nel pod dell'agente di estensione:

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

Anche lo stato dell'estensione viene restituito 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 pod dell'agente di estensione tenta di ottenere il token da IMDS nel cluster, ma la richiesta di token viene intercettata dall'identità del pod. Per risolvere questo problema, eseguire l'aggiornamento all'ultima versione dell'estensione microsoft.flux.

Problemi con l'identità kubelet durante l'installazione dell'estensione `microsoft.flux` in un cluster del servizio Azure Kubernetes

Con i cluster del servizio Azure Kubernetes, una delle opzioni di autenticazione è l'identità kubelet usando un'identità gestita assegnata dall'utente. L'uso dell'identità kubelet può ridurre il sovraccarico operativo e aumentare la sicurezza quando ci si connette alle risorse di Azure, ad esempio Registro Azure Container.

Per consentire a Flux di usare l'identità kubelet, aggiungere il parametro --config useKubeletIdentity=true durante l'installazione dell'estensione 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

Verificare che siano soddisfatti i requisiti di memoria e CPU per l'installazione dell'estensione `microsoft.flux`

I controller installati nel cluster Kubernetes con l'estensione microsoft.flux richiedono risorse di CPU e memoria per pianificare correttamente nei nodi del cluster Kubernetes. Assicurarsi che il cluster sia in grado di soddisfare le risorse minime di memoria e CPU che potrebbero essere richieste. Si notino anche i limiti massimi per i potenziali requisiti delle risorse di CPU e memoria illustrati qui.

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

Se è stato abilitato un criterio di Azure Gatekeeper personalizzato o predefinito che limita le risorse per i contenitori nei cluster Kubernetes, ad esempio Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits, assicurarsi che i limiti delle risorse per i criteri siano maggiori dei limiti illustrati di seguito o che lo spazio dei nomi flux-system faccia parte del parametro excludedNamespaces nell'assegnazione dei criteri.

Flux v1

Nota

È consigliabile eseguire la migrazione a Flux v2 il prima possibile. Il supporto per le risorse di configurazione cluster basate su Flux v1 create prima del 1° gennaio 2024 terminerà 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 sourceControlConfigurations in Flux v1, eseguire questi comandi dell'interfaccia della riga di comando di Azure con il parametro --debug specificato:

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 a Informazioni sui contenitori di Monitoraggio di Azure per i cluster Kubernetes abilitati per Azure Arc.

Abilitazione della modalità con privilegi per il cluster Canonical Charmed Kubernetes

Azure Monitor Container Insights richiede che il relativo 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

Impossibile installare l'agente di Monitoraggio di Azure (AMA) in Oracle Linux 9.x

Quando si tenta di installare l'agente di Monitoraggio di Azure in un cluster Kubernetes Oracle Linux (RHEL) 9.x, i pod AMA e il pod AMA-RS potrebbero non funzionare correttamente a causa del contenitore addon-token-adapter nel pod. Con questo errore, quando si controllano i log del pod ama-logs-rs, addon-token-adapter container, viene visualizzato un output simile al 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 modulo iptables_nat in ogni nodo del cluster usando il comando modprobe 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 fornisce 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 al 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 un controller è stato Rimosso in un dato momento, ve ne è un altro che è READY 1/1 e Running con 0 riavvii. Se la colonna READY è diversa da 1/1, la mesh del servizio si trova in uno stato interrotto. La colonna READY con 0/1 indica che 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

La colonna READY con un numero maggiore di 1 dopo / indica che sono installati sidecar. Il controller OSM in genere non funziona correttamente con sidecar collegati.

Controllare il servizio controller OSM

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

Se il controller OSM è integro, viene visualizzato l'output seguente:

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

Nota

CLUSTER-IP sarà diverso. Il servizio NAME e PORT(S) deve corrispondere a ciò che viene mostrato qui.

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 al seguente:

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

Se il cluster non dispone di ENDPOINTS per 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 al 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 al seguente:

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

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

Controllare il servizio dell'iniettore OSM

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

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

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

Verificare che l'indirizzo IP elencato per il servizio osm-injector sia 9090. Non deve essere presente alcun oggetto 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 al 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'iniettore OSM varia, ma la porta 9090 deve essere la stessa.

Controllare la convalida e la mutazione dei webhook

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Se il webhook di convalida è integro, viene visualizzato un output simile al seguente:

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

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Se il webhook di mutazione è integro, viene visualizzato un output simile al seguente:

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

Verificare la presenza del servizio e del bundle CA del webhook di convalida usando questo comando:

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

Una configurazione corretta del webhook di convalida avrà un output simile al seguente:

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

Una configurazione corretta del webhook di mutaizone avrà un output simile al seguente:

{
  "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 di mutazione) 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 CA. Se l'output è vuoto, 0 o un numero inferiore a 1000, 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 contenuto di OSM MeshConfig:

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

L'output visualizzato sarà simile al seguente:

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

Valori delle risorse osm-mesh-config:

Chiave	Type	Valore predefinito	Esempi di comandi di 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 spazio dei nomi arc-osm-system non parteciperà mai a una mesh del servizio e non verrà mai etichettato o annotato con la chiave/i valori mostrati qui.

Viene usato il comando osm namespace add per unire gli spazi dei nomi a una determinata mesh di servizi. Quando uno spazio dei nomi Kubernetes fa parte della mesh, seguire questa procedura per verificare che siano soddisfatti i requisiti.

Visualizzare le annotazioni dello spazio dei nomi bookbuyer:

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 nomi bookbuyer:

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 riga di comando di osm, è possibile anche aggiungere manualmente queste annotazioni agli spazi dei nomi. Se uno spazio dei nomi non è annotato con "openservicemesh.io/sidecar-injection": "enabled" o non è etichettato con "openservicemesh.io/monitored-by": "osm", l'iniettore OSM non aggiungerà sidecar Envoy.

Nota

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

Verificare le CRL SMI

Verificare se il cluster include le definizioni di risorse personalizzate (CRM) necessarie usando il comando seguente:

kubectl get crds

Assicurarsi che le CRL corrispondano alle versioni disponibili nel ramo di rilascio. Per verificare quali versioni CRD sono in uso, visitare la pagina delle versioni di SMI supportate e selezionare la versione nell'elenco a discesa Versioni.

Ottenere le versioni dei CRD installati con 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, la versione 1.1.0 sarà 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 visualizzare le modifiche delle CRD 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 ai proxy Envoy in esecuzione nei pod dell'applicazione, vedere il sito della documentazione di OSM.

Eseguire l'aggiornamento di Envoy

Quando si crea 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 nel sito della documentazione di OSM.

Passaggi successivi

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 di webhook/dry

Errori di installazione dell'estensione `microsoft.flux`

Errori durante l'installazione dell'estensione `microsoft.flux` in un cluster con identità del pod di Microsoft Entra abilitata

Problemi con l'identità kubelet durante l'installazione dell'estensione `microsoft.flux` in un cluster del servizio Azure Kubernetes

Verificare che siano soddisfatti i requisiti di memoria e CPU per l'installazione dell'estensione `microsoft.flux`

Flux v1

Container Insights per Monitoraggio di Azure

Abilitazione della modalità con privilegi per il cluster Canonical Charmed Kubernetes

Impossibile installare l'agente di Monitoraggio di Azure (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 dell'iniettore OSM

Controllare gli endpoint dell'oggetto dell'iniettore OSM

Controllare la convalida e la mutazione dei webhook

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

Passaggi successivi

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 di webhook/dry

Errori di installazione dell'estensione microsoft.flux

Errori durante l'installazione dell'estensione microsoft.flux in un cluster con identità del pod di Microsoft Entra abilitata

Problemi con l'identità kubelet durante l'installazione dell'estensione microsoft.flux in un cluster del servizio Azure Kubernetes

Verificare che siano soddisfatti i requisiti di memoria e CPU per l'installazione dell'estensione microsoft.flux

Flux v1

Container Insights per Monitoraggio di Azure

Abilitazione della modalità con privilegi per il cluster Canonical Charmed Kubernetes

Impossibile installare l'agente di Monitoraggio di Azure (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 dell'iniettore OSM

Controllare gli endpoint dell'oggetto dell'iniettore OSM

Controllare la convalida e la mutazione dei webhook

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

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive

Errori di installazione dell'estensione `microsoft.flux`

Errori durante l'installazione dell'estensione `microsoft.flux` in un cluster con identità del pod di Microsoft Entra abilitata

Problemi con l'identità kubelet durante l'installazione dell'estensione `microsoft.flux` in un cluster del servizio Azure Kubernetes

Verificare che siano soddisfatti i requisiti di memoria e CPU per l'installazione dell'estensione `microsoft.flux`

Controllare la risorsa `osm-mesh-config`