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

Dieses Dokument enthält Tipps zur Problembehandlung für häufige Probleme im Zusammenhang mit Clustererweiterungen, z. B. GitOps (Flux v2) und Open Service Mesh.

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

GitOps (Flux v2)

Um allgemeine Hilfe bei der Problembehandlung von fluxConfigurations -Ressourcen zu erhalten, führen Sie diese Azure CLI-Befehle mit dem angegebenen --debug -Parameter aus:

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

Webhook/Trockenlauffehler

Wenn die Abstimmung von Flux mit einem Fehler wie dry-run failed, error: admission webhook "<webhook>" does not support dry run fehlschlägt, können Sie das Problem beheben, indem Sie die ValidatingWebhookConfiguration oder die MutatingWebhookConfiguration suchen und sideEffects auf None oder NoneOnDryRun festlegen:

Weitere Informationen finden Sie unter Beheben von webhook does not support dry run-Fehlern.

Fehler beim Installieren der microsoft.flux -Erweiterung

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

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

Stellen Sie für einen AKS-Cluster sicher, dass für das 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. Legen Sie den Clustertyp (-t) auf connectedClusters für einen Arc-fähigen Cluster oder managedClusters für einen AKS-Cluster fest. Der Name der microsoft.flux -Erweiterung ist "flux", wenn die Erweiterung während der Erstellung einer GitOps-Konfiguration automatisch installiert wurde. Suchen Sie im statuses-Objekt nach Informationen.

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

Die angezeigten Ergebnisse können Ihnen dabei helfen, zu bestimmen, was schief gelaufen ist und wie es behoben werden kann. Mögliche Abhilfemaßnahmen sind:

• Erzwingen des Löschens der Erweiterung durch Ausführen von az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>
• Deinstallieren Sie die Helm-Version, 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

Nachdem Sie dies durchgeführt haben, 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 beim Installieren der microsoft.flux -Erweiterung in einem Cluster mit aktivierter Microsoft Entra Pod Identity

Wenn Sie versuchen, die Flux-Erweiterung in einem Cluster zu installieren, für den Microsoft Entra-Podidentität aktiviert ist, kann im Erweiterungs-Agent-Pod ein Fehler auftreten:

{"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 auch 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 Erweiterungs-Agent-Pod, sein Token aus IMDS im 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.

Probleme bei der Kubelet-Identität beim Installieren der microsoft.flux -Erweiterung in einem AKS-Cluster

Bei AKS-Clustern ist eine der Authentifizierungsoptionen Kubelet-Identität, unter Verwendung einer vom Benutzer zugewiesenen verwalteten Identität. Durch die Verwendung der Kubelet-Identität kann der Betriebsaufwand reduziert und die Sicherheit beim Herstellen einer Verbindung mit Azure-Ressourcen wie Azure Container Registry erhöht werden.

Um Flux die Kubelet-Identität verwenden zu lassen, fügen Sie den Parameter --config useKubeletIdentity=true bei der Installation der Flux-Erweiterung hinzu.

az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config useKubeletIdentity=true

Sicherstellen, dass Speicher- und CPU-Anforderungen für microsoft.flux Erweiterungsinstallation erfüllt sind

Die in Ihrem Kubernetes-Cluster installierten Controller mit der microsoft.flux-Erweiterung setzen die folgenden CPU- und Arbeitsspeicherressourcenlimits für eine ordnungsgemäße Planung auf Kubernetes-Clusterknoten voraus. Stellen Sie sicher, dass Ihr Cluster die mindesten Arbeitsspeicher- und CPU-Ressourcen erfüllen kann, die angefordert werden können. Beachten Sie auch die hier gezeigten maximalen Grenzwerte für potenzielle CPU- und Arbeitsspeicherressourcenanforderungen.

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

Wenn Sie eine benutzerdefinierte oder integrierte Azure Gatekeeper-Richtlinie wie Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits 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 oben gezeigten Grenzwerte, oder dass der flux-system -Namespace Teil des excludedNamespaces -Parameters in der Richtlinienzuweisung ist.

Flux v1

Führen Sie die folgenden Azure CLI-Befehle aus, um Probleme mit der sourceControlConfigurations -Ressource in Flux v1 zu beheben, wobei --debug Parameter angegeben ist:

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

Azure Monitor Container Insights

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

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

Azure Monitor Container Insights erfordert, dass das 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

Azure Monitor Agent (AMA) kann nicht auf Oracle Linux 9.x installiert werden

Wenn Sie versuchen, den Azure Monitor Agent (AMA) auf einem Oracle 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äß. Bei diesem Fehler wird beim Überprüfen der Protokolle des ama-logs-rs -Pods, addon-token-adapter container, die Ausgabe ähnlich wie folgt angezeigt:

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 auf jeden Knoten im Cluster laden, indem Sie den modprobe -Befehl sudo modprobe iptables_nat verwenden. Nachdem Sie sich bei jedem Knoten angemeldet und das iptable_nat -Modul manuell hinzugefügt haben, wiederholen Sie die AMA-Installation.

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

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, wird die Ausgabe ähnlich wie folgt angezeigt:

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 irgendwann Entfernt wurde, gibt es einen anderen, nämlich READY 1/1 und Running mit 0 Neustarts. Wenn die Spalte READY einen anderen Wert als 1/1 aufweist, befindet sich das Dienstgittermodell in einem defekten Zustand. Wenn die Spalte READY den Wert 0/1 anzeigt, bedeutet dies, dass der Steuerungsebenencontainer abstürzt.

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

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

Wenn die Spalte READY eine Zahl höher als 1 aufweist, nachdem die / darauf hinweist, dass Beiwagen installiert sind. OSM Controller funktioniert in der Regel nicht ordnungsgemäß mit angebundenen Beiwagen.

Überprüfen des OSM-Controllerdiensts

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

Wenn der OSM-Controller fehlerfrei ist, sehen Sie die folgende Ausgabe:

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

Überprüfen von OSM-Controllerendpunkten

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

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

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

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

Überprüfen der OSM-Injektorbereitstellung

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

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

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

OSM-Injektor-Pod überprüfen

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

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

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

Die Spalte READY muss 1/1 lauten. Jeder andere Wert gibt einen fehlerhaften OSM-Injektor-Pod an.

Überprüfen des OSM-Injektordiensts

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

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

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. Es darf keine EXTERNAL-IP vorhanden sein.

Überprüfen von OSM-Injektorendpunkten

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

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

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 Validieren und Mutieren

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Wenn der Überprüfende Webhook fehlerfrei ist, wird die Ausgabe ähnlich wie folgt angezeigt:

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

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Wenn der Mutierende Webhook fehlerfrei ist, wird die Ausgabe ähnlich wie folgt angezeigt:

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

Schauen Sie mithilfe dieses Befehls nach dem Dienst und dem CA-Bundle des Überprüfenden Webhooks:

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

Eine gut konfigurierte Überprüfende -Webhookkonfiguration führt zu einer Ausgabe wie die folgende:

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

Eine gut konfigurierte Mutierende -Webhookkonfiguration führt zu einer Ausgabe wie die folgende:

{
  "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 Validieren (oder Mutieren) 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:

1845

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 1000 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 OSM MeshConfig-Inhalt:

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

Eine ähnliche Ausgabe wie die folgende 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: ""

Ressourcenwerte von osm-mesh-config:

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

Wir verwenden den osm namespace add Befehl, um Namespaces mit einem bestimmten Service Mesh zu verknüpfen. Wenn ein Kubernetes-Namespace Teil des Gitters 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 auch 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-Beiwagen hinzu.

Überprüfen der SMI-CRDs

Überprüfen Sie mit dem folgenden Befehl, ob der 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 der Versionszweig verfügbar sind. Um zu bestätigen, welche CRD-Versionen verwendet werden, besuchen Sie die Seite zu unterstützten SMI-Versionen, und wählen Sie Ihre Version aus der Dropdownliste für 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. v1.1.0 wäre 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

Informationen zu CRD-Änderungen zwischen Releases finden Sie unter OSM-Versionshinweise.

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 auf der OSM-Dokumentationswebsite.

Upgrade von Envoy

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

Nächste Schritte

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