Behandeln von Erweiterungsproblemen für Azure Arc-fähige Kubernetes-Cluster

Artikel
01/10/2025

In diesem Artikel werden Tipps zur Problembehandlung für häufige Probleme im Zusammenhang mit Clustererweiterungen wie GitOps (Flux v2) in Azure oder Open Service Mesh (OSM) beschrieben.

Hilfe zur Problembehandlung allgemeiner Probleme mit Azure Arc-fähigen Kubernetes-Clustern finden Sie unter Problembehandlung für Azure Arc-fähige Kubernetes.

GitOps (Flux v2)

Hinweis

Sie können die Flux v2-Erweiterung entweder in Azure Arc-fähigen Kubernetes-Clustern oder AKS-Clustern (Azure Kubernetes Service) verwenden. Diese Tipps zur Problembehandlung gelten in der Regel für alle Clustertypen.

Für eine allgemeine Unterstützung bei der Problembehandlung von fluxConfigurations-Ressourcen, führen Sie diese Azure CLI-Befehle mit dem --debug-Parameter aus:

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

Fehler beim Webhook-Probelauf

Flux schlägt möglicherweise fehl und zeigt einen Fehler an, der dry-run failed, error: admission webhook "<webhook>" does not support dry run ähnelt. Um das Problem zu beheben, gehen Sie zu ValidatingWebhookConfiguration oder MutatingWebhookConfiguration. Legen Sie in der Konfiguration den Wert für sideEffects auf None oder NoneOnDryRun fest.

Weitere Informationen finden Sie unter Wie behebe ich Fehler vom Typ „Webhook unterstützt den Probelauf nicht“?.

Fehler bei der Installation der microsoft.flux-Erweiterung

Die microsoft.flux-Erweiterung installiert Flux-Controller und Azure GitOps-Agents in einem Kubernetes-Cluster mit Azure Arc-Unterstützung oder Azure Kubernetes Service-Cluster (AKS). Wenn die Erweiterung noch nicht in einem Cluster installiert ist und Sie für dieses Cluster eine GitOps-Konfigurationsressource erstellen, wird die Erweiterung automatisch installiert.

Wenn während der Installation ein Fehler auftritt oder die Erweiterung den Zustand Failed anzeigt, stellen Sie sicher, dass das Cluster keine Richtlinien enthält, die die Erstellung des flux-system-Namespaces oder Ressourcen in diesem Namespace einschränken.

Stellen Sie bei einem AKS-Cluster sicher, dass im Azure-Abonnement das Microsoft.ContainerService/AKS-ExtensionManager-Featureflag aktiviert ist:

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

Führen Sie danach diesen Befehl aus, um festzustellen, ob andere Probleme vorhanden sind. Setzen Sie den Parameter für den Clustertyp (-t) auf connectedClusters für ein Azure Arc-fähiges Cluster oder auf managedClusters für ein AKS-Cluster. Wenn die Erweiterung während der Erstellung einer GitOps-Konfiguration automatisch installiert wurde, lautet der Name der microsoft.flux-Erweiterung flux.

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

Die Ausgabe kann Ihnen helfen, das Problem zu identifizieren und zu beheben. Mögliche Abhilfemaßnahmen sind:

Erzwingen Sie das Löschen der Erweiterung, indem Sie az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters> ausführen.
Deinstallieren Sie das Helm-Release, indem Sie helm uninstall flux -n flux-system ausführen.
Löschen Sie den flux-system-Namespace aus dem Cluster, indem Sie kubectl delete namespaces flux-system ausführen.

Danach können Sie entweder eine Flux-Konfiguration neu erstellen, die die microsoft.flux-Erweiterung automatisch installiert, oder Sie können die Flux-Erweiterung manuell neu installieren.

Fehler bei der Installation der microsoft.flux-Erweiterung in einem Cluster mit verwalteter Microsoft Entra Pod-Identität

Wenn Sie versuchen, die Flux-Erweiterung in einem Cluster mit verwalteter Microsoft Entra Pod-Identität zu installieren, kann im extension-agent-Pod ein Fehler auftreten. Die Ausgabe sieht in etwa wie folgt aus:

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

Der Erweiterungsstatus wird als Failed zurückgegeben:

"{\"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 diesem Fall versucht der extension-agent-Pod, sein Token aus dem Azure Instance Metadata Service auf dem Cluster abzurufen. Die Tokenanforderung wird jedoch von der Pod-Identität abgefangen. Um dieses Problem zu beheben, führen Sie ein Upgrade auf die neueste Version der microsoft.flux-Erweiterung durch.

Anforderungen an die Speicher- und CPU-Ressourcen für die Installation der microsoft.flux-Erweiterung

Die in Ihrem Kubernetes-Cluster installierten Controller mit der microsoft.flux-Erweiterung müssen für eine ordnungsgemäße Ausführung auf Kubernetes-Clusterknoten über ausreichend CPU- und Speicherressourcen verfügen. Stellen Sie sicher, dass Ihr Cluster die Mindestanforderungen an die Speicher- und CPU-Ressourcen erfüllt.

In der folgenden Tabelle sind die Minimal- und Maximalanforderungen für potenzielle CPU- und Speicherressourcen für dieses Szenario aufgeführt:

Containername	Minimale CPU	Mindestarbeitsspeicher	Maximale CPU-Nutzung	Arbeitsspeichermaximum
`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

Wenn Sie eine benutzerdefinierte oder integrierte Azure Policy Gatekeeper-Richtlinie aktiviert haben, die die Ressourcen für Container in Kubernetes-Clustern einschränkt, müssen Sie entweder sicherstellen, dass die Ressourcenbeschränkungen in der Richtlinie größer sind als die Grenzwerte in der vorherigen Tabelle, oder dass der flux-system-Namespace Teil des excludedNamespaces-Parameters in der Richtlinienzuweisung ist. Ein Beispiel für eine Richtlinie in diesem Szenario ist Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits.

Flux v1

Hinweis

Es wird empfohlen, dass Sie so bald wie möglich zu Flux v2 migrieren. Die Unterstützung für Flux v1-basierte Ressourcen von Clusterkonfigurationen, die vor dem 1. Januar 2024 erstellt wurden, endet am 24. Mai 2025. Ab dem 1. Januar 2024 können Sie keine neuen Flux v1-basierten Clusterkonfigurationsressourcen mehr erstellen.

Führen Sie die folgenden Azure CLI-Befehle einschließlich dem --debug-Parameter aus, um Probleme mit der sourceControlConfigurations-Ressource in Flux v1 zu beheben:

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

Azure Monitor Container Insights

Dieser Abschnitt enthält Tipps für die Problembehandlung bei Container Insights in Azure Monitor für Azure Arc-fähige Kubernetes-Cluster.

Aktivieren des privilegierten Modus für ein Canonical Charmed Kubernetes-Cluster

Azure Monitor Container Insights erfordert, dass das Kubernetes DaemonSet im privilegierten Modus ausgeführt wird. Führen Sie den folgenden Befehl aus, um einen Canonical Charmed Kubernetes-Cluster für die Überwachung einzurichten:

juju config kubernetes-worker allow-privileged=true

AMA-Pods können nicht auf Oracle Linux 9.x installiert werden

Wenn Sie versuchen, den Azure Monitor Agent (AMA) auf einem Oracle Linux (Red Hat Enterprise Linux (RHEL)) 9.x Kubernetes-Cluster zu installieren, funktionieren die AMA-Pods und der AMA-RS-Pod aufgrund des addon-token-adapter-Containers im Pod möglicherweise nicht ordnungsgemäß. Wenn Sie die Protokolle des ama-logs-rs-Pods in addon-token-adapter container überprüfen, wird eine Ausgabe angezeigt, die dem folgenden Beispiel ähnelt:

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.

Dieser Fehler tritt auf, da die Installation der Erweiterung das iptable_nat -Modul erfordert, dieses Modul jedoch nicht automatisch in Oracle Linux (RHEL) 9.x-Verteilungen geladen wird.

Um dieses Problem zu beheben, müssen Sie das iptables_nat-Modul explizit in jedem Knoten im Cluster laden. Verwenden Sie dazu den modprobe-Befehl sudo modprobe iptables_nat. Nachdem Sie sich bei jedem Knoten angemeldet und das iptable_nat -Modul manuell hinzugefügt haben, wiederholen Sie die AMA-Installation.

Hinweis

Die Asuführung dieses Schrittes macht das iptables_nat -Modul nicht beständig.

Open Service Mesh mit Azure Arc-Unterstützung

Dieser Abschnitt enthält Befehle, die Sie verwenden können, um die Bereitstellung der Open Service Mesh (OSM)-Erweiterungskomponenten in Ihrem Cluster zu überprüfen und zu beheben.

Überprüfen der Bereitstellung des OSM-Controller

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

Wenn der OSM-Controller fehlerfrei ist, wird die Ausgabe ähnlich wie folgt angezeigt:

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

Überprüfen von OSM-Controller-Pods

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

Wenn der OSM-Controller fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

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

Obwohl ein Controller an einem Punkt den Status Evicted hat, verfügt ein anderer Controller über den READY Status 1/1 und Running mit 0 Neustarts. Wenn der Status READY einen anderen Wert als 1/1 aufweist, befindet sich das Dienstnetz in einem defekten Zustand. Wenn der Status READY den Wert 0/1 anzeigt, bedeutet dies, dass der Container auf Steuerungsebene abstürzt.

Verwenden Sie den folgenden Befehl, um Controller-Protokolle zu überprüfen:

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

Wenn der Status READY eine Zahl größer als 1 nach dem Schrägstrich (/) hat, werden Sidecars installiert. Der OSM-Controller funktioniert im Allgemeinen nicht ordnungsgemäß, wenn Sidecars angeschlossen sind.

Überprüfen des OSM-Controller-Diensts

Führen Sie den folgenden Befehl aus, um den OSM-Controller-Dienst zu überprüfen:

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

Wenn der OSM-Controller fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

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

Hinweis

Der Istwert für CLUSTER-IP unterscheidet sich von diesem Beispiel. Die Werte für NAME und PORT(S) sollten mit dem übereinstimmen, was in diesem Beispiel gezeigt wird.

Überprüfen von OSM-Controllerendpunkten

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

Wenn der OSM-Controller fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

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

Wenn der Cluster keine ENDPOINTS mit dem Wert osm-controller hat, ist die Steuerungsebene fehlerhaft. Dieser fehlerhafte Zustand bedeutet, dass der Controller-Pod abgestürzt ist oder dass er nie ordnungsgemäß bereitgestellt wurde.

Überprüfen der Bereitstellung des OSM-Injektors

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

Wenn der OSM-Injektor fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

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

Überprüfen des OSM-Injektor-Pods

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

Wenn der OSM-Injektor fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

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

Der Status READY muss 1/1 sein. Jeder andere Wert gibt einen fehlerhaften OSM-Injektor-Pod an.

Überprüfen des OSM-Injektor-Diensts

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

Wenn der OSM-Injektor fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

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

Stellen Sie sicher, dass die für den Dienst osm-injector aufgeführte IP-Adresse 9090 lautet. Für EXTERNAL-IP sollte kein Wert aufgeführt sein.

Überprüfen von OSM-Injektorendpunkten

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

Wenn der OSM-Injektor fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

Damit OSM funktioniert, muss mindestens ein Endpunkt für osm-injector vorhanden sein. Die IP-Adresse Ihrer OSM-Injektorendpunkte variiert, der Port 9090 muss jedoch identisch sein.

Überprüfen der Webhooks: Validating und Mutating

Überprüfen Sie das Webhook Validating, indem Sie den folgenden Befehl ausführen:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Wenn das Webhook Validating fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

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

Überprüfen Sie das Webhook Mutating, indem Sie den folgenden Befehl ausführen:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Wenn das Webhook Mutating fehlerfrei ist, erhalten Sie eine Ausgabe ähnlich der folgenden:

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

Prüfen Sie mithilfe dieses Befehls den Dienst und das CA-Bundle des Validating Webhook:

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

Ein gut konfiguriertes Validating Webhook hat eine Ausgabe ähnlich der folgenden:

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

Überprüfen Sie den Dienst und das CA-Bundle des Webhooks Mutieren mit folgendem Befehl:

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

Ein gut konfiguriertes Mutating Webhook hat eine Ausgabe ähnlich der folgenden:

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

Überprüfen Sie mit dem folgenden Befehl, ob der OSM-Controller dem Webhook Validating (oder Mutating) ein CA-Bundle übergeben hat:

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

Beispielausgabe:

Die Zahl in der Ausgabe gibt die Anzahl von Bytes oder die Größe des CA-Bundles an. Wenn die Ausgabe leer, 0 oder eine Zahl unter 1,000 ist, wird das CA-Bundle nicht ordnungsgemäß bereitgestellt. Ohne korrektes CA-Bundle gibt der ValidatingWebhook einen Fehler aus.

Überprüfen der Ressource `osm-mesh-config`

Überprüfen Sie, ob die Ressource vorhanden ist:

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

Überprüfen Sie den Wert der meshconfig-OSM-Einstellung:

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

Eine ähnliche Ausgabe wie im folgenden Beispiel sollte angezeigt werden:

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

In der folgenden Tabelle sind die Ressourcenwerte von osm-mesh-config aufgeführt:

Schlüssel	Typ	Standardwert	Beispiele für Kubectl-Patchbefehle
`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`	Zeichenfolge	`"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`	Zeichenfolge	`"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`	Zeichenfolge	`"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`

Überprüfen der Namespaces

Hinweis

Der arc-osm-system-Namespace ist nie Teil eines Dienstnetzes. Er weist niemals Bezeichnungen oder Anmerkungen mit dem Paar Schlüssel/Wert auf.

Sie können den osm namespace add-Befehl verwenden, um Namespaces mit einem bestimmten Dienstnetz zu verknüpfen. Wenn ein Kubernetes-Namespace Teil des Netzes ist, führen Sie die folgenden Schritte aus, um zu bestätigen, dass die Anforderungen erfüllt werden.

Zeigen Sie die Anmerkungen des Namespace bookbuyer an:

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

Die folgenden Eigenschaften müssen vorhanden sein:

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

Zeigen Sie die Bezeichnungen des Namespace bookbuyer an:

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

Die folgenden Eigenschaften müssen vorhanden sein:

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

Wenn Sie osm CLI nicht verwenden, können Sie diese Anmerkungen manuell zu Ihren Namespaces hinzufügen. Wenn ein Namespace nicht mit "openservicemesh.io/sidecar-injection": "enabled" annotiert oder nicht mit "openservicemesh.io/monitored-by": "osm" beschriftet ist, fügt der OSM-Injektor keine Envoy-Sidecars hinzu.

Hinweis

Nach dem Aufruf von osm namespace add werden nur neue Pods mit dem Sidecar „Envoy“ eingefügt. Vorhandene Pods müssen mit dem kubectl rollout restart deployment-Befehl neu gestartet werden.

Überprüfen der SMI-CRDs

Überprüfen Sie für das OSM Service Mesh Interface (SMI) mit dem folgenden Befehl, ob das Cluster über die erforderlichen benutzerdefinierten Ressourcendefinitionen (Custom Resource Definitions, CRDs) verfügt:

kubectl get crds

Stellen Sie sicher, dass die CRDs den Versionen entsprechen, die in dem Versionszweig verfügbar sind. Um zu bestätigen, welche CRD-Versionen verwendet werden, gehen Sie zu Unterstützte SMI-Versionen und wählen Sie Ihre Version aus dem Menü Releases aus.

Rufen Sie die Versionen der installierten CRDs mit dem folgenden Befehl ab:

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

Wenn CRDs fehlen, verwenden Sie die folgenden Befehle, um sie im Cluster zu installieren. Ersetzen Sie die Version in diesen Befehlen nach Bedarf (z. B. statt v1.1.0 könnten Sie release-v1.1 verwenden).

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

Informationen dazu, wie CRD-Versionen zwischen Versionen geändert werden, finden Sie in den OSM-Versionshinweisen.

Behandlung von Problemen mit der Zertifikatverwaltung

Informationen dazu, wie OSM Zertifikate für Envoy-Proxys ausstellt und verwaltet, die auf Anwendungspods ausgeführt werden, finden Sie in der OSM-Dokumentation.

Upgrade von Envoy

Wenn ein neuer Pod in einem Namespace erstellt wird, der vom Add-On überwacht wird, fügt OSM einen Envoy-Proxy-Sidecar in diesen Pod ein. Wenn die Envoy-Version aktualisiert werden muss, befolgen Sie die Schritte im Upgradehandbuch in der OSM-Dokumentation.

Erfahren Sie mehr über Clustererweiterungen.
Sehen Sie sich allgemeine Tipps zur Problembehandlung für Arc-fähige Kubernetes-Cluster an.

Freigeben über

Behandeln von Erweiterungsproblemen für Azure Arc-fähige Kubernetes-Cluster

GitOps (Flux v2)

Fehler beim Webhook-Probelauf

Fehler bei der Installation der microsoft.flux-Erweiterung

Fehler bei der Installation der microsoft.flux-Erweiterung in einem Cluster mit verwalteter Microsoft Entra Pod-Identität

Anforderungen an die Speicher- und CPU-Ressourcen für die Installation der microsoft.flux-Erweiterung

Flux v1

Azure Monitor Container Insights

Aktivieren des privilegierten Modus für ein Canonical Charmed Kubernetes-Cluster

AMA-Pods können nicht auf Oracle Linux 9.x installiert werden

Open Service Mesh mit Azure Arc-Unterstützung

Überprüfen der Bereitstellung des OSM-Controller

Überprüfen von OSM-Controller-Pods

Überprüfen des OSM-Controller-Diensts

Überprüfen von OSM-Controllerendpunkten

Überprüfen der Bereitstellung des OSM-Injektors

Überprüfen des OSM-Injektor-Pods

Überprüfen des OSM-Injektor-Diensts

Überprüfen von OSM-Injektorendpunkten

Überprüfen der Webhooks: Validating und Mutating

Überprüfen der Ressource `osm-mesh-config`

Überprüfen der Namespaces

Überprüfen der SMI-CRDs

Behandlung von Problemen mit der Zertifikatverwaltung

Upgrade von Envoy

Feedback

Zusätzliche Ressourcen

Freigeben über

Behandeln von Erweiterungsproblemen für Azure Arc-fähige Kubernetes-Cluster

GitOps (Flux v2)

Fehler beim Webhook-Probelauf

Fehler bei der Installation der microsoft.flux-Erweiterung

Fehler bei der Installation der microsoft.flux-Erweiterung in einem Cluster mit verwalteter Microsoft Entra Pod-Identität

Anforderungen an die Speicher- und CPU-Ressourcen für die Installation der microsoft.flux-Erweiterung

Flux v1

Azure Monitor Container Insights

Aktivieren des privilegierten Modus für ein Canonical Charmed Kubernetes-Cluster

AMA-Pods können nicht auf Oracle Linux 9.x installiert werden

Open Service Mesh mit Azure Arc-Unterstützung

Überprüfen der Bereitstellung des OSM-Controller

Überprüfen von OSM-Controller-Pods

Überprüfen des OSM-Controller-Diensts

Überprüfen von OSM-Controllerendpunkten

Überprüfen der Bereitstellung des OSM-Injektors

Überprüfen des OSM-Injektor-Pods

Überprüfen des OSM-Injektor-Diensts

Überprüfen von OSM-Injektorendpunkten

Überprüfen der Webhooks: Validating und Mutating

Überprüfen der Ressource osm-mesh-config

Überprüfen der Namespaces

Überprüfen der SMI-CRDs

Behandlung von Problemen mit der Zertifikatverwaltung

Upgrade von Envoy

Zugehöriger Inhalt

Feedback

Zusätzliche Ressourcen

Überprüfen der Ressource `osm-mesh-config`