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

Articolo
12/19/2023

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 con abilitazione di 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 servizio Azure Kubernetes 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 fluxConfigurations risorse, eseguire questi comandi dell'interfaccia della riga di comando di Azure con il --debug parametro 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 su sideEffectsNone o NoneOnDryRun:

Per altre informazioni, vedere Ricerca per categorie risolvere gli webhook does not support dry run errori?

Errori durante l'installazione dell'estensione `microsoft.flux`

L'estensione microsoft.flux installa i controller Flux e gli agenti GitOps di Azure nei cluster Kubernetes abilitati per Azure Arc o servizio Azure Kubernetes (AKS). 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 dello spazio dei nomi o delle flux-system risorse in tale spazio dei nomi.

Per un cluster del servizio Azure Kubernetes, assicurarsi che la sottoscrizione disponga del Microsoft.ContainerService/AKS-ExtensionManager flag di funzionalità abilitato.

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

Successivamente, eseguire questo comando per determinare se sono presenti altri problemi. Impostare il parametro tipo di 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 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

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

Errori durante l'installazione dell'estensione in un cluster con l'identità `microsoft.flux` 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"}

Lo stato dell'estensione restituisce anche 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 alla versione più recente 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 `microsoft.flux` l'installazione dell'estensione

I controller installati nel cluster Kubernetes con l'estensione microsoft.flux richiedono risorse 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 noti 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	50m	150 Mi
fluxconfig-controller	5 m	30 Mi	100m	150 Mi
fluent-bit	5 m	30 Mi	20 m	150 Mi
helm-controller	100m	64 Mi	1000 m	1 Gi
source-controller	50m	64 Mi	1000 m	1 Gi
kustomize-controller	100m	64 Mi	1000 m	1 Gi
notification-controller	100m	64 Mi	1000 m	1 Gi
image-automation-controller	100m	64 Mi	1000 m	1 Gi
image-reflector-controller	100m	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 flux-system spazio dei nomi faccia parte del parametro nell'assegnazione dei excludedNamespaces criteri.

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 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 in Flux v1, eseguire questi comandi dell'interfaccia della sourceControlConfigurations riga di comando di Azure con --debug il parametro specificato:

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

Informazioni dettagliate sui contenitori di Monitoraggio di Azure

Questa sezione fornisce informazioni sulla risoluzione dei problemi relativi a Informazioni dettagliate sui contenitori di Monitoraggio di Azure per i cluster Kubernetes abilitati per Azure Arc.

Abilitazione della modalità con privilegi per il cluster Kubernetes con accesso canonico

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

juju config kubernetes-worker allow-privileged=true

Impossibile installare l'agente di Monitoraggio di Azure 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 addon-token-adapter contenitore nel pod. Con questo errore, quando si controllano i log del ama-logs-rs pod, addon-token-adapter containerviene 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 iptable_nat modulo, 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 usando il modprobe comando sudo modprobe iptables_nat. Dopo aver eseguito l'accesso a ogni nodo e aver aggiunto manualmente il iptable_nat modulo, ripetere l'installazione ama.

Nota

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

Azure Arc-enabled Open Service Mesh

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 a un certo punto, c'è 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

Colonna READY con un numero maggiore di dopo 1 indica / che sono installati sidecar. Il controller OSM in genere non funziona correttamente con le sidecar collegate.

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

Il CLUSTER-IP valore 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 per ENDPOINTSosm-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 di osm injector

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 READY colonna deve essere 1/1. Qualsiasi altro valore indica un pod injector 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 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 osm-injector il servizio sia 9090. Non deve essere presente alcun EXTERNAL-IPoggetto .

Controllare gli endpoint dell'oggetto injector 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'injector OSM varia, ma la porta 9090 deve essere la stessa.

Controllare la convalida e la modifica 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 modifica è 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 webhook di convalida ben configurata 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 modifica usando il comando seguente:

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

Una configurazione webhook di modifica ben configurata 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 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 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, viene ValidatingWebhook generato un errore.

Controllare la `osm-mesh-config` risorsa

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

osm-mesh-config valori delle risorse:

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/valori mostrati qui.

Viene usato il osm namespace add comando 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 osm della riga di comando, è anche possibile 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'injector OSM non aggiungerà sidecar Envoy.

Nota

Dopo osm namespace add la chiamata, verranno inseriti solo nuovi pod con un sidecar Envoy. I pod esistenti devono essere riavviati con il kubectl rollout restart deployment comando .

Verificare i CRL SMI

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

kubectl get crds

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

Ottenere le versioni dei CRL 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 CRL 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 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 per i proxy Envoy in esecuzione nei pod dell'applicazione, vedere il sito della documentazione osm.

Eseguire l'aggiornamento di Envoy

Quando un nuovo pod viene creato 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.

Share via

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

GitOps (Flux v2)

Errori di esecuzione di webhook/dry

Errori durante l'installazione dell'estensione `microsoft.flux`

Errori durante l'installazione dell'estensione in un cluster con l'identità `microsoft.flux` 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 `microsoft.flux` l'installazione dell'estensione

Flux v1

Informazioni dettagliate sui contenitori di Monitoraggio di Azure

Abilitazione della modalità con privilegi per il cluster Kubernetes con accesso canonico

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

Azure Arc-enabled Open Service Mesh

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 di osm injector

Controllare il pod dell'iniettore OSM

Controllare il servizio di inserimento del sistema operativo

Controllare gli endpoint dell'oggetto injector OSM

Controllare la convalida e la modifica dei webhook

Controllare la `osm-mesh-config` risorsa

Controllare gli spazi dei nomi

Verificare i CRL SMI

Risolvere i problemi di gestione dei certificati

Eseguire l'aggiornamento di Envoy

Passaggi successivi

Risorse aggiuntive

Share via

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

GitOps (Flux v2)

Errori di esecuzione di webhook/dry

Errori durante l'installazione dell'estensione microsoft.flux

Errori durante l'installazione dell'estensione in un cluster con l'identità microsoft.flux 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 microsoft.flux l'installazione dell'estensione

Flux v1

Informazioni dettagliate sui contenitori di Monitoraggio di Azure

Abilitazione della modalità con privilegi per il cluster Kubernetes con accesso canonico

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

Azure Arc-enabled Open Service Mesh

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 di osm injector

Controllare il pod dell'iniettore OSM

Controllare il servizio di inserimento del sistema operativo

Controllare gli endpoint dell'oggetto injector OSM

Controllare la convalida e la modifica dei webhook

Controllare la osm-mesh-config risorsa

Controllare gli spazi dei nomi

Verificare i CRL SMI

Risolvere i problemi di gestione dei certificati

Eseguire l'aggiornamento di Envoy

Passaggi successivi

Risorse aggiuntive

Errori durante l'installazione dell'estensione `microsoft.flux`

Errori durante l'installazione dell'estensione in un cluster con l'identità `microsoft.flux` 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 `microsoft.flux` l'installazione dell'estensione

Controllare la `osm-mesh-config` risorsa