Problembehandlung bei Kubernetes mit Azure Arc-Unterstützung und GitOps

Artikel
03/26/2023
21 Minuten Lesedauer

Dieses Dokument enthält Anleitungen zur Problembehandlung bei Problemen mit der Konnektivität, den Berechtigungen und den Agents von Kubernetes mit Azure Arc-Unterstützung. Außerdem werden Leitfäden zur Problembehandlung für Azure GitOps bereitgestellt, die entweder in Kubernetes-Clustern mit Azure Arc-Unterstützung oder Azure Kubernetes Service-Clustern (AKS) verwendet werden können.

Allgemeine Problembehandlung

Azure CLI

Überprüfen Sie vor dem Verwenden der CLI-Befehle az connectedk8s oder az k8s-configuration, ob die Azure CLI so eingerichtet ist, dass sie mit dem richtigen Azure-Abonnement funktioniert.

az account set --subscription 'subscriptionId'
az account show

Azure Arc-Agents

Alle Agents für Kubernetes mit Azure Arc-Unterstützung werden als Pods im azure-arc-Namespace bereitgestellt. Alle Pods sollten ausgeführt werden und ihre Integritätsprüfungen bestehen.

Überprüfen Sie zunächst das Azure Arc-Helm-Chart-Release:

$ helm --namespace default status azure-arc
NAME: azure-arc
LAST DEPLOYED: Fri Apr  3 11:13:10 2020
NAMESPACE: default
STATUS: deployed
REVISION: 5
TEST SUITE: None

Wenn das Helm-Chart-Release nicht gefunden wird oder fehlt, versuchen Sie, erneut eine Verbindung des Clusters mit Azure Arc herzustellen.

Wenn das Helm-Chart-Release vorhanden ist und den STATUS: deployed aufweist, überprüfen Sie den Status des Agents mithilfe von kubectl:

$ kubectl -n azure-arc get deployments,pods
NAME                                       READY  UP-TO-DATE  AVAILABLE  AGE
deployment.apps/clusteridentityoperator     1/1       1          1       16h
deployment.apps/config-agent                1/1       1          1       16h
deployment.apps/cluster-metadata-operator   1/1       1          1       16h
deployment.apps/controller-manager          1/1       1          1       16h
deployment.apps/flux-logs-agent             1/1       1          1       16h
deployment.apps/metrics-agent               1/1       1          1       16h
deployment.apps/resource-sync-agent         1/1       1          1       16h

NAME                                            READY   STATUS  RESTART  AGE
pod/cluster-metadata-operator-7fb54d9986-g785b  2/2     Running  0       16h
pod/clusteridentityoperator-6d6678ffd4-tx8hr    3/3     Running  0       16h
pod/config-agent-544c4669f9-4th92               3/3     Running  0       16h
pod/controller-manager-fddf5c766-ftd96          3/3     Running  0       16h
pod/flux-logs-agent-7c489f57f4-mwqqv            2/2     Running  0       16h
pod/metrics-agent-58b765c8db-n5l7k              2/2     Running  0       16h
pod/resource-sync-agent-5cf85976c7-522p5        3/3     Running  0       16h

Alle Pods sollten STATUS als Running mit 3/3 oder 2/2 unter der Spalte READY anzeigen. Rufen Sie Protokolle ab, und beschreiben Sie die Pods, die Error oder CrashLoopBackOff zurückgeben. Wenn Pods im Zustand Pending hängengeblieben sind, sind möglicherweise nicht ausreichend Ressourcen auf den Clusterknoten vorhanden. Wenn Sie Ihren Cluster hochskalieren, können diese Pods in den Zustand Running übergehen.

Verbinden von Kubernetes-Clustern mit Azure Arc

Das Herstellen einer Verbindung von Clustern mit Azure Arc erfordert Zugriff auf ein Azure-Abonnement und cluster-admin-Zugriff auf einen Zielcluster. Wenn Sie den Cluster nicht erreichen können oder nicht über ausreichende Berechtigungen verfügen, tritt beim Herstellen einer Verbindung des Clusters mit Azure Arc ein Fehler auf. Stellen Sie sicher, dass Sie alle Voraussetzungen erfüllt haben, um einen Cluster zu verbinden.

Tipp

Einen visuellen Leitfaden zum Beheben dieser Probleme finden Sie unter Diagnostizieren von Verbindungsproblemen für Arc-fähige Kubernetes-Cluster.

Probleme bei der DNS-Auflösung

Wenn eine Fehlermeldung zu einem Problem mit der DNS-Auflösung in Ihrem Cluster angezeigt wird, können Sie einige Verfahren ausprobieren, um das Problem zu diagnostizieren und zu beheben.

Weitere Informationen finden Sie unter Debuggen der DNS-Auflösung.

Probleme mit der ausgehenden Netzwerkkonnektivität

Probleme mit der ausgehenden Netzwerkkonnektivität aus dem Cluster können aus verschiedenen Gründen auftreten. Stellen Sie zunächst sicher, dass alle Netzwerkanforderungen erfüllt sind.

Wenn dieses Problem auftritt und sich Ihr Cluster hinter einem ausgehenden Proxyserver befindet, stellen Sie sicher, dass Sie beim Onboarding Ihres Clusters Proxyparameter übergeben haben und dass der Proxy ordnungsgemäß konfiguriert ist. Informationen finden Sie unter Herstellen einer Verbindung mithilfe eines ausgehenden Proxyservers.

Fehler beim Abrufen des MSI-Zertifikats

Probleme beim Abrufen des MSI-Zertifikats sind in der Regel auf Netzwerkprobleme zurückzuführen. Überprüfen Sie, ob alle Netzwerkanforderungen erfüllt sind, und wiederholen Sie dann den Vorgang.

Unzureichende Clusterberechtigungen

Wenn die bereitgestellte kubeconfig-Datei nicht über ausreichende Berechtigungen zum Installieren von Azure Arc-Agents verfügt, gibt der Azure CLI-Befehl einen Fehler zurück.

az connectedk8s connect --resource-group AzureArc --name AzureArcCluster

Ensure that you have the latest helm version installed before proceeding to avoid unexpected errors.
This operation might take a while...

Error: list: failed to list: secrets is forbidden: User "myuser" cannot list resource "secrets" in API group "" at the cluster scope

Um dieses Problem zu lösen, sollte dem Benutzer, der die Verbindung des Clusters mit Azure Arc herstellt, die Rolle cluster-admin auf dem Cluster zugewiesen sein.

Herstellen einer Verbindung zwischen OpenShift-Cluster und Azure Arc nicht möglich

Wenn beim Verbinden eines OpenShift-Clusters mit Azure Arc ein Timeout für az connectedk8s connect auftritt und der Befehl nicht ausgeführt wird:

Stellen Sie sicher, dass der OpenShift-Cluster die erforderlichen Versionsvoraussetzungen erfüllt: 4.5.41 oder höher oder 4.6.35 oder höher oder 4.7.18 oder höher.

Führen Sie vor dem Ausführen von az connectedk8s connnect diesen Befehl im Cluster aus:

oc adm policy add-scc-to-user privileged system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa

Timeouts bei der Installation

Das Herstellen einer Verbindung zwischen einem Kubernetes-Cluster und Kubernetes mit Azure Arc-Unterstützung erfordert die Installation von Azure Arc-Agents im Cluster. Wenn der Cluster über eine langsame Internetverbindung ausgeführt wird, kann das Pullen des Containerimages für Agents länger dauern, als die Azure CLI-Timeouts erlauben.

az connectedk8s connect --resource-group AzureArc --name AzureArcCluster

Ensure that you have the latest helm version installed before proceeding to avoid unexpected errors.
This operation might take a while...

Helm-Timeout-Fehler

Möglicherweise wird der folgende Helm-Timeoutfehler angezeigt:

az connectedk8s connect -n AzureArcTest -g AzureArcTest

Unable to install helm release: Error: UPGRADE Failed: time out waiting for the condition

Führen Sie die folgenden Schritte aus, um dieses Problem zu beheben.

Führen Sie den folgenden Befehl aus:
```
kubectl get pods -n azure-arc
```

Überprüfen Sie, ob die clusterconnect-agent- oder config-agent-Pods crashloopbackoff anzeigen oder nicht alle Container ausgeführt werden:

NAME                                        READY   STATUS             RESTARTS   AGE
cluster-metadata-operator-664bc5f4d-chgkl   2/2     Running            0          4m14s
clusterconnect-agent-7cb8b565c7-wklsh       2/3     CrashLoopBackOff   0          1m15s
clusteridentityoperator-76d645d8bf-5qx5c    2/2     Running            0          4m15s
config-agent-65d5df564f-lffqm               1/2     CrashLoopBackOff   0          1m14s

Wenn das folgende Zertifikat nicht vorhanden ist, wurde die vom System zugewiesene verwaltete Identität nicht installiert.
```
kubectl get secret -n azure-arc -o yaml | grep name:
```
```
name: azure-identity-certificate
```
Um dieses Problem zu lösen, versuchen Sie, die Arc-Bereitstellung zu löschen, indem Sie den az connectedk8s delete-Befehl ausführen und sie erneut installieren. Wenn das Problem weiterhin auftritt, könnte ein Problem mit Ihren Proxyeinstellungen vorliegen. Versuchen Sie in diesem Fall, die Verbindung ihres Clusters mit Azure Arc über einen Proxy herzustellen, um Ihren Cluster über einen Proxy mit Arc zu verbinden. Überprüfen Sie auch, ob alle Netzwerkvoraussetzungen erfüllt wurden.
Wenn die clusterconnect-agent- und dieconfig-agent-Pods ausgeführt werden, aber der kube-aad-proxy-Pod fehlt, überprüfen Sie Ihre Pod-Sicherheitsrichtlinien. Dieser Pod verwendet das azure-arc-kube-aad-proxy-sa-Dienstkonto, das nicht über Administratorberechtigungen verfügt, aber die Berechtigung zum Bereitstellen des Host-Pfads erfordert.
Wenn der kube-aad-proxy-Pod im Zustand ContainerCreating hängt, überprüfen Sie, ob das kube-aad-Proxyzertifikat auf den Cluster heruntergeladen wurde.
```
kubectl get secret -n azure-arc -o yaml | grep name:
```
```
name: kube-aad-proxy-certificate
```
Wenn das Zertifikat fehlt, löschen Sie die Bereitstellung und melden Sie sich mit einem anderen Namen für den Cluster erneut an. Falls das Problem weiterhin besteht, wenden Sie sich an den Support.

Helm-Überprüfungsfehler

Die Helm-Version v3.3.0-rc.1 hat ein Problem. Nach der Helm-Installation bzw. dem Helm-Upgrade (von der CLI-Erweiterung connectedk8s verwendet) wird durch das Ausführen aller Hooks der folgende Fehler erzeugt:

az connectedk8s connect -n AzureArcTest -g AzureArcTest

Ensure that you have the latest helm version installed before proceeding.
This operation might take a while...

Please check if the azure-arc namespace was deployed and run 'kubectl get pods -n azure-arc' to check if all the pods are in running state. A possible cause for pods stuck in pending state could be insufficientresources on the Kubernetes cluster to onboard to arc.
ValidationError: Unable to install helm release: Error: customresourcedefinitions.apiextensions.k8s.io "connectedclusters.arc.azure.com" not found

Befolgen Sie diese Schritte, um das Problem zu beheben:

Löschen Sie die Kubernetes-Ressource mit Azure Arc-Unterstützung im Azure-Portal.

Führen Sie die folgenden Befehle auf dem Computer aus:

kubectl delete ns azure-arc
kubectl delete clusterrolebinding azure-arc-operator
kubectl delete secret sh.helm.release.v1.azure-arc.v1

Installieren Sie eine stabile Version von Helm 3 auf Ihrem Computer anstelle der Release Candidate-Version.
Führen Sie den Befehl az connectedk8s connect mit den entsprechenden Werten aus, um den Cluster mit Azure Arc zu verbinden.

CryptoHash-Modulfehler

Wenn Sie versuchen, Kubernetes-Cluster in die Azure Arc-Plattform zu integrieren, gibt die lokale Umgebung (z. B. Ihre Clientkonsole) möglicherweise die folgende Fehlermeldung zurück:

Cannot load native module 'Crypto.Hash._MD5'

Manchmal können abhängige Module beim Hinzufügen der Erweiterungen connectedk8s und k8s-configuration über die Azure CLI oder über Azure Powershell nicht erfolgreich heruntergeladen werden. Um dieses Problem zu lösen, können Sie die Erweiterungen in der lokalen Umgebung manuell entfernen und dann hinzufügen.

Zum Entfernen der Erweiterungen verwenden Sie Folgendes:

az extension remove --name connectedk8s

az extension remove --name k8s-configuration

Zum Hinzufügen der Erweiterungen verwenden Sie Folgendes:

az extension add --name connectedk8s

az extension add --name k8s-configuration

GitOps-Verwaltung

Flux v1: Allgemein

Hinweis

Azure wird die Unterstützung für GitOps mit Flux v1 einstellen. Beginnen Sie daher so bald wie möglich, Flux v2 zu verwenden.

Um Probleme mit der sourceControlConfigurations-Ressource (Flux v1) zu beheben, führen Sie die folgenden Azure CLI-Befehle mit angegebenem --debug-Parameter aus:

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

Flux v1: Erstellen von Konfigurationen

Schreibberechtigungen auf der Kubernetes-Ressource mit Azure Arc-Unterstützung (Microsoft.Kubernetes/connectedClusters/Write) sind notwendig und ausreichend, um Konfigurationen in diesem Cluster zu erstellen.

`sourceControlConfigurations` bleibt `Pending` (Flux v1)

kubectl -n azure-arc logs -l app.kubernetes.io/component=config-agent -c config-agent
$ k -n pending get gitconfigs.clusterconfig.azure.com  -o yaml
apiVersion: v1
items:
- apiVersion: clusterconfig.azure.com/v1beta1
  kind: GitConfig
  metadata:
    creationTimestamp: "2020-04-13T20:37:25Z"
    generation: 1
    name: pending
    namespace: pending
    resourceVersion: "10088301"
    selfLink: /apis/clusterconfig.azure.com/v1beta1/namespaces/pending/gitconfigs/pending
    uid: d9452407-ff53-4c02-9b5a-51d55e62f704
  spec:
    correlationId: ""
    deleteOperator: false
    enableHelmOperator: false
    giturl: git@github.com:slack/cluster-config.git
    helmOperatorProperties: null
    operatorClientLocation: azurearcfork8s.azurecr.io/arc-preview/fluxctl:0.1.3
    operatorInstanceName: pending
    operatorParams: '"--disable-registry-scanning"'
    operatorScope: cluster
    operatorType: flux
  status:
    configAppliedTime: "2020-04-13T20:38:43.081Z"
    isSyncedWithAzure: true
    lastPolledStatusTime: ""
    message: 'Error: {exit status 1} occurred while doing the operation : {Installing
      the operator} on the config'
    operatorPropertiesHashed: ""
    publicKey: ""
    retryCountPublicKey: 0
    status: Installing the operator
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Flux v2: Allgemein

Um Probleme mit der fluxConfigurations-Ressource (Flux v2) zu beheben, führen Sie die folgenden Azure CLI-Befehle mit angegebenem --debug-Parameter aus:

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

Flux v2: Webhook-/Probelauffehler

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.

Flux v2: 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 eine GitOps-Konfigurationsressource für diesen Cluster erstellen, wird die Erweiterung automatisch installiert.

Wenn während der Installation ein Fehler auftritt oder sich die Erweiterung in einem fehlerhaften Zustand befindet, führen Sie ein Skript aus, um dies zu untersuchen. Der Parameter „cluster-type“ (Clustertyp) kann für einen Cluster mit Arc-Unterstützung auf connectedClusters festgelegt werden oder für einen AKS-Cluster auf managedClusters. Der Name der microsoft.flux-Erweiterung lautet „flux“, wenn die Erweiterung während der Erstellung einer GitOps-Konfiguration automatisch installiert wurde. Suchen Sie im Objekt „statuses“ nach Informationen.

Ein Beispiel:

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

"statuses": [
    {
      "code": "InstallationFailed",
      "displayStatus": null,
      "level": null,
      "message": "unable to add the configuration with configId {extension:flux} due to error: {error while adding the CRD configuration: error {Operation cannot be fulfilled on extensionconfigs.clusterconfig.azure.com \"flux\": the object has been modified; please apply your changes to the latest version and try again}}",
      "time": null
    }
  ]

Ein weiteres Beispiel:

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

"statuses": [
    {
      "code": "InstallationFailed",
      "displayStatus": null,
      "level": null,
      "message": "Error: {failed to install chart from path [] for release [flux]: err [cannot re-use a name that is still in use]} occurred while doing the operation : {Installing the extension} on the config",
      "time": null
    }
  ]

Ein weiteres Beispiel aus dem Portal:

{'code':'DeploymentFailed','message':'At least one resource deployment operation failed. Please list 
deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.
','details':[{'code':'ExtensionCreationFailed', 'message':' Request failed to https://management.azure.com/
subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ContainerService/
managedclusters/<CLUSTER_NAME>/extensionaddons/flux?api-version=2021-03-01. Error code: BadRequest. 
Reason: Bad Request'}]}

In all diesen Fällen bestehen mögliche Korrekturaktionen darin, das Löschen der Erweiterung zu erzwingen, das Helm-Release zu deinstallieren und den Namespace flux-system aus dem Cluster zu löschen.

az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>

helm uninstall flux -n flux-system
kubectl delete namespaces flux-system

Einige andere Aspekte, die zu berücksichtigen sind:

Stellen Sie für einen AKS-Cluster sicher, dass für das Abonnement das folgende Microsoft.ContainerService/AKS-ExtensionManager-Featureflag aktiviert ist.
```
az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager
```
Stellen Sie sicher, dass der Cluster über keine Richtlinien verfügt, die die Erstellung des Namespace flux-system oder von Ressourcen in diesem Namespace einschränken.

Nachdem Sie dies durchgeführt haben, können Sie entweder eine Flux-Konfiguration neu erstellen, die die Flux-Erweiterung automatisch installiert, oder Sie können die Flux-Erweiterung manuell neu installieren.

Flux v2: Installieren der `microsoft.flux`-Erweiterung in einem Cluster mit aktivierter Azure AD-Podidentität

Wenn Sie versuchen, die Flux-Erweiterung in einem Cluster zu installieren, für den Azur Azure Active Directory-Podidentität (Azure AD) 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 „Fehler“ 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}}\"}]}}",

Der Erweiterungs-Agent-Pod versucht, sein Token von IMDS im Cluster abzurufen, um mit dem Erweiterungsdienst in Azure zu kommunizieren, aber die Tokenanforderung wird von der Podidentität abgefangen.

Sie können dieses Problem beheben, indem Sie auf die neueste Version der microsoft.flux Erweiterung aktualisieren. Für Version 1.6.1 oder früher besteht die Problemumgehung darin, eine AzurePodIdentityException zu erstellen, die Azure AD-Podidentität anfordert, die Tokenanforderungen von Flux-Erweiterungspods zu ignorieren.

apiVersion: aadpodidentity.k8s.io/v1
kind: AzurePodIdentityException
metadata:
  name: flux-extension-exception
  namespace: flux-system
spec:
  podLabels:
    app.kubernetes.io/name: flux-extension

Flux v2: Installieren der `microsoft.flux`-Erweiterung in einem Cluster mit aktivierter Kubelet-Identität

Bei der Arbeit mit Azure Kubernetes-Clustern ist eine der Authentifizierungsoptionen kubelet-Identität mit einer benutzerseitig zugewiesenen verwalteten Identität. Die Verwendung der Kubelet-Identität kann den Betriebsaufwand reduzieren und die Sicherheit beim Herstellen einer Verbindung mit Azure-Ressourcen wie z. B. Azure Container Registry erhöhen.

Damit Flux die Kubelet-Identität verwendet, fügen Sie den Parameter --config useKubeletIdentity=true bei der Installation der Flux-Erweiterung hinzu. Diese Option wird ab Version 1.6.1 der Erweiterung unterstützt.

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

Flux v2 – `microsoft.flux`-Erweiterungsinstallations-CPU- und Arbeitsspeicherbeschränkungen

Die Controller, die in Ihrem Kubernetes-Cluster mit der Microsoft Flux-Erweiterung installiert sind, erfordern die folgenden CPU- und Arbeitsspeicherressourcengrenzwerte, um auf Kubernetes-Clusterknoten ordnungsgemäß zu planen.

Containername	CPU-Grenzwert	Arbeitsspeicherlimit
fluxconfig-agent	50m	150Mi
fluxconfig-controller	100m	150Mi
fluent-bit	20m	150Mi
helm-controller	1000m	1Gi
source-controller	1000m	1Gi
kustomize-controller	1000m	1Gi
notification-controller	1000m	1Gi
image-automation-controller	1000m	1Gi
image-reflector-controller	1000m	1Gi

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.

Überwachung

Azure Monitor für Container erfordert die Ausführung des DaemonSet im privilegierten Modus. 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

Clusterverbindung

Alte Version der verwendeten Agents

Einige ältere Agent-Versionen unterstützten das „Cluster Connect“-Feature nicht. Wenn Sie eine dieser Versionen verwenden, wird möglicherweise dieser Fehler angezeigt:

az connectedk8s proxy -n AzureArcTest -g AzureArcTest

Hybrid connection for the target resource does not exist. Agent might not have started successfully.

Stellen Sie sicher, dass Sie die connectedk8s Azure CLI-Erweiterung mit Version >= 1.2.0 verwenden, dann verbinden Sie Ihren Cluster erneut mit Azure Arc. Vergewissern Sie sich außerdem, dass alle Netzwerkvoraussetzungen erfüllt sind, die für Kubernetes mit Arc-Unterstützung erforderlich sind.

Wenn sich Ihr Cluster hinter einem Proxy oder einer Firewall für ausgehende Daten befindet, überprüfen Sie, ob Websocketverbindungen für *.servicebus.windows.net aktiviert sind, was insbesondere für das Cluster Connect-Feature erforderlich ist.

Deaktiviertes Clusterverbindungsfeature

Wenn die clusterconnect-agent- und kube-aad-proxy-Pods fehlen, wird das Clusterverbindungsfeature wahrscheinlich auf dem Cluster deaktiviert und az connectedk8s proxy kann keine Sitzung mit dem Cluster einrichten.

az connectedk8s proxy -n AzureArcTest -g AzureArcTest

Cannot connect to the hybrid connection because no agent is connected in the target arc resource.

Um diesen Fehler zu beheben, aktivieren Sie das Clusterverbindungsfeature in Ihrem Cluster.

az connectedk8s enable-features --features cluster-connect -n $CLUSTER_NAME -g $RESOURCE_GROUP

Aktivieren von benutzerdefinierten Standorten per Dienstprinzipal

Wenn Sie eine Verbindung Ihres Clusters mit Azure Arc herstellen oder für einen vorhandenen Cluster benutzerdefinierte Speicherorte aktivieren, wird ggf. folgende Warnung angezeigt:

Unable to fetch oid of 'custom-locations' app. Proceeding without enabling the feature. Insufficient privileges to complete the operation.

Diese Warnung tritt auf, wenn Sie einen Dienstprinzipal verwenden, um sich bei Azure anzumelden. Der Dienstprinzipal hat keine Berechtigungen, Informationen von der vom Azure Arc-Dienst verwendeten Anwendung abzurufen. Um diesen Fehler zu vermeiden, führen Sie die folgenden Schritte aus:

Melden Sie sich mit Ihrem Benutzerkonto bei Azure CLI an. Rufen Sie die Objekt-ID der Azure AD-Anwendung ab, die vom Azure Arc-Dienst verwendet wird:
```
az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query objectId -o tsv
```
Melden Sie sich mit dem Dienstprinzipal bei Azure CLI an. Verwenden Sie den <objectId>-Wert aus dem obigen Schritt, um benutzerdefinierte Speicherorte im Cluster zu aktivieren:
- Führen Sie den folgenden Befehl aus, um benutzerdefinierte Speicherorte beim Herstellen der Verbindung des Clusters mit Arc zu aktivieren:
```
az connectedk8s connect -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId>   
```
- Um benutzerdefinierte Speicherorte in einem Kubernetes-Cluster mit Azure Arc-Unterstützung zu aktivieren, führen Sie den folgenden Befehl aus:
```
az connectedk8s enable-features -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId> --features cluster-connect custom-locations
```

Open Service Mesh mit Azure Arc-Unterstützung

Die folgenden Schritte bieten eine Anleitung zum Überprüfen der Bereitstellung aller Open Service Mesh-Erweiterungskomponenten (OSM) in Ihrem Cluster.

Überprüfen der OSM-Controller-Bereitstellung

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

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

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

Überprüfen des 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 irgendwann entfernt wurde, gibt es einen anderen, der READY 1/1 und Running mit 0 Neustarts. Wenn die Spalte READY einen anderen Wert als 1/1 aufweist, ist das Dienstmesh defekt. 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 nach dem / eine Zahl größer als 1 zeigt, würde dies darauf hinweisen, dass Sidecars installiert sind. OSM Controller würde höchstwahrscheinlich nicht mit angeschlossenen Seitenwagen funktionieren.

Überprüfen des OSM-Controller-Diensts

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

Wenn der OSM-Controller fehlerfrei ist, erhalten 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

Hinweis

Die CLUSTER-IP kann abweichen. NAME und PORT(S) für den Dienst müssen mit den Werten in der Ausgabe übereinstimmen.

Überprüfen der OSM-Controller-Endpunkte

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 des Benutzers nicht über ENDPOINTS für osm-controller verfügt, ist die Steuerungsebene fehlerhaft. Dieser fehlerhafte Zustand kann durch den Absturz des OSM-Controller-Pods verursacht werden, oder der Pod wurde möglicherweise nie ordnungsgemäß bereitgestellt.

Überprüfen der OSM-Injektor-Bereitstellung

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

Die Spalte READY muss 1/1 lauten. Jeder andere Wert würde auf einen fehlerhaften OSM-Injektor-Pod hindeuten.

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

Überprüfen der OSM-Injektor-Endpunkte

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-Injektor-Endpunkte lautet anders als hier gezeigt. Der Port 9090 muss identisch sein.

Überprüfen der Webhooks Validieren und Mutieren

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

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

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

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

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

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

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

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

Aus einer guten Konfiguration des Validieren-Webhooks resultiert eine ähnliche 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'

Aus einer guten Konfiguration des Mutieren-Webhooks resultiert eine ähnliche 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:

Die Zahl in der Ausgabe gibt die Anzahl von Bytes oder die Größe des CA-Bundles an. Wenn dieser Wert leer, 0 oder eine Zahl unter 1.000 ist, wird das CA-Bundle nicht korrekt 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

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

Hinweis

Der arc-osm-system-Namespace nimmt nie an einem Dienstmesh teil und erhält nie Bezeichnungen oder Anmerkungen mit den unten stehenden Schlüsseln/Werten.

Wir verwenden den osm namespace add Befehl, um Namespaces mit einem bestimmten Service Mesh zu verknüpfen. Wenn ein Kubernetes-Namespace zum Mesh gehört, muss Folgendes zutreffen:

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 die osm-CLI nicht verwenden, könnten Sie diese Anmerkungen Ihren Namespaces auch manuell 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

Nachdem osm namespace add aufgerufen wurde, werden nur neue Pods mit dem Sidecar „Envoy“ eingefügt. Vorhandene Pods müssen mit dem Befehl kubectl rollout restart deployment neu gestartet werden.

Ü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. Wenn Sie z. B. OSM-Arc v1.0.0-1 verwenden, navigieren Sie zur SMI- unterstützten Versionsseite, und wählen Sie v1.0 aus der Dropdownliste Releases aus, um zu überprüfen, welche CRDs-Versionen verwendet werden.

Mit dem folgenden Befehl können Sie die Versionen der installierten CRDs abrufen:

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. Wenn Sie eine andere Version von OSM-Arc als v1.0 verwenden, stellen Sie sicher, dass Sie die Version im Befehl ersetzen (v1.1.0 wäre z. B. release-v1.1.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-Sidecar in diesen Pod ein. Wenn die Envoy-Version aktualisiert werden muss, befolgen Sie die Schritte im Upgradehandbuch auf der OSM-Dokumentationswebsite.

Problembehandlung bei Kubernetes mit Azure Arc-Unterstützung und GitOps

Allgemeine Problembehandlung

Azure CLI

Azure Arc-Agents

Verbinden von Kubernetes-Clustern mit Azure Arc

Probleme bei der DNS-Auflösung

Probleme mit der ausgehenden Netzwerkkonnektivität

Fehler beim Abrufen des MSI-Zertifikats

Unzureichende Clusterberechtigungen

Herstellen einer Verbindung zwischen OpenShift-Cluster und Azure Arc nicht möglich

Timeouts bei der Installation

Helm-Timeout-Fehler

Helm-Überprüfungsfehler

CryptoHash-Modulfehler

GitOps-Verwaltung

Flux v1: Allgemein

Flux v1: Erstellen von Konfigurationen

sourceControlConfigurations bleibt Pending (Flux v1)

Flux v2: Allgemein

Flux v2: Webhook-/Probelauffehler

Flux v2: Fehler beim Installieren der microsoft.flux-Erweiterung

Flux v2: Installieren der microsoft.flux-Erweiterung in einem Cluster mit aktivierter Azure AD-Podidentität

Flux v2: Installieren der microsoft.flux-Erweiterung in einem Cluster mit aktivierter Kubelet-Identität

Flux v2 – microsoft.flux-Erweiterungsinstallations-CPU- und Arbeitsspeicherbeschränkungen

Überwachung

Clusterverbindung

Alte Version der verwendeten Agents

Deaktiviertes Clusterverbindungsfeature

Aktivieren von benutzerdefinierten Standorten per Dienstprinzipal

Open Service Mesh mit Azure Arc-Unterstützung

Überprüfen der OSM-Controller-Bereitstellung

Überprüfen des OSM-Controller-Pods

Überprüfen des OSM-Controller-Diensts

Überprüfen der OSM-Controller-Endpunkte

Überprüfen der OSM-Injektor-Bereitstellung

Überprüfen des OSM-Injektor-Pods

Überprüfen des OSM-Injektor-Diensts

Überprüfen der OSM-Injektor-Endpunkte

Überprüfen der Webhooks Validieren und Mutieren

Ü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

Zusätzliche Ressourcen

Zusätzliche Ressourcen

`sourceControlConfigurations` bleibt `Pending` (Flux v1)

Flux v2: Fehler beim Installieren der `microsoft.flux`-Erweiterung

Flux v2: Installieren der `microsoft.flux`-Erweiterung in einem Cluster mit aktivierter Azure AD-Podidentität

Flux v2: Installieren der `microsoft.flux`-Erweiterung in einem Cluster mit aktivierter Kubelet-Identität

Flux v2 – `microsoft.flux`-Erweiterungsinstallations-CPU- und Arbeitsspeicherbeschränkungen

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