Felsöka tilläggsproblem för Azure Arc-aktiverade Kubernetes-kluster

I den här artikeln beskrivs felsökningstips för vanliga problem som rör klustertillägg som GitOps (Flux v2) i Azure eller Open Service Mesh (OSM).

Hjälp med att felsöka Azure Arc-aktiverade Kubernetes-problem i allmänhet finns i Felsöka Azure Arc-aktiverade Kubernetes-problem.

GitOps (Flux v2)

Om du vill ha allmän hjälp med felsökningsproblem när du använder fluxConfigurations resurser kör du följande Azure CLI-kommandon med parametern --debug :

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

Fel vid konfiguration av Helm-diagram

Du kan se ett felmeddelande med texten "Unable to render the Helm chart with the provided config settings and config protected settings : Recommendation Please check if the values provided to the config settings and the config protected settings are valid for this extension type : InnerError [template: azure-k8s-flux/templates/source-controller.yaml:100:24: executing "azure-k8s-flux/templates/source-controller.yaml" at <index (lookup "v1" "ConfigMap" "kube-system" "extension-manager-config").data "AZURE_TENANT_ID">: error calling index: index of untyped nil]".

Så här löser du problemet:

• Om du kör microsoft.flux version 1.15.1 eller tidigare uppgraderar du till version 1.15.2 eller senare.
• Om du kör microsoft.flux version 1.16.2 i regionerna Västra Central-USA, Centrala Frankrike, Södra Storbritannien eller Västra Europa, uppgradera till version 1.16.3 eller senare.

Fel vid torrkörning med Webhook

Flux kan misslyckas och visa ett fel som liknar dry-run failed, error: admission webhook "<webhook>" does not support dry run. Lös problemet genom att gå till ValidatingWebhookConfiguration eller MutatingWebhookConfiguration. I konfigurationen anger du värdet för sideEffects till None eller NoneOnDryRun.

Mer information finns i Hur gör jag för att lösa fel med "webhook stöder inte torrkörning"?.

Fel vid installation av tillägget microsoft.flux

Tillägget microsoft.flux installerar Flux-styrenheter och Azure GitOps-agenter i ett Azure Arc-aktiverat Kubernetes-kluster eller AKS-kluster. Om tillägget inte redan är installerat i ett kluster och du skapar en GitOps-konfigurationsresurs för klustret installeras tillägget automatiskt.

Om du får ett fel under installationen eller om tillägget visar ett Failed tillstånd, kontrollera att klustret inte har några principer som begränsar skapandet av flux-system-namnområdet eller någon av resurserna i det namnområdet.

För ett AKS-kluster kontrollerar du att funktionsflaggan Microsoft.ContainerService/AKS-ExtensionManager är aktiverad i Azure-prenumerationen:

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

Kör sedan följande kommando för att avgöra om det finns andra problem. Ange parametern för klustertyp (-t) till connectedClusters för ett Azure Arc-aktiverat kluster eller till managedClusters för ett AKS-kluster. Om tillägget installerades automatiskt när du skapade GitOps-konfigurationen är microsoft.fluxnamnet på flux tillägget .

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

Utdata kan hjälpa dig att identifiera problemet och hur du åtgärdar det. Möjliga reparationsåtgärder är:

• Tvinga bort tillägget genom att köra az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>.
• Avinstallera Helm-versionen genom att köra helm uninstall flux -n flux-system.
• flux-system Ta bort namnområdet från klustret genom att köra kubectl delete namespaces flux-system.

Sedan kan du antingen skapa en ny Flux-konfiguration, som installerar microsoft.flux tillägget automatiskt, eller så kan du installera Flux-tillägget manuellt.

Fel vid installation av microsoft.flux-tillägget i ett kluster som har en poddhanterad identitet från Microsoft Entra.

Om du försöker installera Flux-tillägget i ett kluster som har en Microsoft Entra-poddhanterad identitet kan ett fel uppstå i extension-agent podden. Utdata ser ut ungefär som i det här exemplet:

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

Tilläggsstatusen returneras som Failed:

"{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"ExtensionCreationFailed\",\"message\":\" error: Unable to get the status from the local CRD with the error : {Error : Retry for given duration didn't get any results with err {status not populated}}\"}]}}",

I det här fallet försöker extension-agent-podden hämta sin token från Azure Instance Metadata Service i klustret, men tokenbegäran fångas upp av poddens identitet . Du kan åtgärda problemet genom att uppgradera till den senaste versionen av microsoft.flux tillägget.

Krav på minnes- och CPU-resurser för att installera tillägget microsoft.flux

De styrenheter som installeras i kubernetes-klustret när du installerar microsoft.flux tillägget måste ha tillräckligt med processor- och minnesresurser för att schemaläggas korrekt på en Kubernetes-klusternod. Se till att klustret uppfyller minimikraven för minne och CPU-resurser.

I följande tabell visas de lägsta och högsta gränserna för potentiella processor- och minnesresurskrav för det här scenariot:

Om du har aktiverat en anpassad eller inbyggd Azure Policy Gatekeeper-princip som begränsar resurserna för containrar i Kubernetes-kluster kontrollerar du att antingen resursgränserna för principen är större än de gränser som visas i föregående tabell eller att flux-system namnområdet är en del av parametern excludedNamespaces i principtilldelningen. Ett exempel på en princip i det här scenariot är Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits.

Azure Monitor Container Insights

Det här avsnittet innehåller hjälp med felsökning av problem med containerinsikter i Azure Monitor för Azure Arc-aktiverade Kubernetes-kluster.

Aktivera privilegierat läge för ett Canonical Charmed Kubernetes-kluster

Azure Monitor Container Insights kräver att Kubernetes DaemonSet körs i privilegierat läge. Kör följande kommando för att konfigurera ett Canonical Charmed Kubernetes-kluster för övervakning:

juju config kubernetes-worker allow-privileged=true

Det går inte att installera AMA-poddar på Oracle Linux 9.x

Om du försöker installera Azure Monitor Agent (AMA) på ett Oracle Linux (Red Hat Enterprise Linux (RHEL)) 9.x Kubernetes-kluster kanske AMA-poddarna och AMA-RS-podden inte fungerar korrekt på grund av containern addon-token-adapter i podden. När du kontrollerar loggarna för ama-logs-rs podden i addon-token-adapter containerser du utdata som liknar följande exempel:

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.

Det här felet beror på att installationen av tillägget kräver modulen iptable_nat , men den här modulen läses inte in automatiskt i Oracle Linux-distributioner (RHEL) 9.x.

För att åtgärda det här problemet måste du uttryckligen läsa in modulen iptables_nat på varje nod i klustret. modprobe Använd kommandot sudo modprobe iptables_nat. När du har loggat in på varje nod och lagt till modulen iptable_nat manuellt gör du ett nytt försök med AMA-installationen.

Azure Arc-aktiverat Open Service Mesh

Det här avsnittet visar kommandon som du kan använda för att verifiera och felsöka distributionen av OSM-tilläggskomponenter (Open Service Mesh) i klustret.

Kontrollera utplaceringen av OSM-styrenheten

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

Om OSM-styrenheten är felfri ser du utdata som liknar:

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

Kontrollera OSM-styrenhetspoddar

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

Om OSM-styrenheten är felfri visas utdata som liknar följande exempel:

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

Även om en styrenhet har statusen Evicted vid ett tillfälle, har en annan styrenhet status READY och 1/1Running med 0 omstarter. Om statusen READY är något annat än 1/1är tjänstnätet i ett brutet tillstånd. Om READY är 0/1, kraschar containern för kontrollplanet.

Använd följande kommando för att inspektera kontrollantloggar:

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

Om statusen READY är ett tal som är större än 1 efter snedstrecket (/), installeras sidovagnar. OSM-styrenheten fungerar vanligtvis inte korrekt när sidovagnar är anslutna.

Kontrollera OSM-kontrollanttjänsten

Kör det här kommandot för att kontrollera OSM-kontrollanttjänsten:

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

Om OSM-styrenheten är felfri visas utdata som liknar följande exempel:

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

Kontrollera OSM-kontrollantens slutpunkter

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

Om OSM-styrenheten är felfri visas utdata som liknar följande exempel:

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

Om klustret inte har någon ENDPOINTS med värdet osm-controller är kontrollplanet ohälsosamt. Detta osunda tillstånd innebär att controller-podden kraschade eller att den aldrig distribuerades korrekt.

Kontrollera utplaceringen av OSM-injektor

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

Om OSM-injektorn är felfri visas utdata som liknar följande exempel:

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

Kontrollera OSM-injektorpodden

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

Om OSM-injektorn är felfri visas utdata som liknar följande exempel:

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

Statusen READY måste vara 1/1. Alla andra värden indikerar en ohälsosam OSM-injektorpodd.

Kontrollera OSM-injektortjänsten

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

Om OSM-injektorn är felfri visas utdata som liknar följande exempel:

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

Kontrollera att IP-adressen som anges för osm-injector tjänsten är 9090. Det bör inte finnas något värde i listan för EXTERNAL-IP.

Kontrollera OSM-injektorslutpunkter

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

Om OSM-injektorn är felfri visas utdata som liknar följande exempel:

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

För att OSM ska fungera måste det finnas minst en slutpunkt för osm-injector. IP-adressen för OSM-injektorslutpunkterna varierar, men portvärdet 9090 måste vara detsamma.

Kontrollera webhooks: Validera och mutera

Kontrollera validerande webhook genom att köra följande kommando:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Om webhooken Validering är felfri visas utdata som liknar följande exempel:

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

Kontrollera webhooken Mutating genom att köra följande kommando:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Om webhooken Mutating är felfri visas utdata som liknar följande exempel:

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

Sök efter tjänsten och certifikatutfärdarpaketet (CA-paketet) för Validering-webhooken med hjälp av det här kommandot:

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

En välkonfigurerad valideringswebbhook har utdata som liknar det här exemplet:

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

Sök efter tjänsten och CA-paketet för webhooken Mutating med hjälp av följande kommando:

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

En välkonfigurerad Mutating-webhook har outputdata som liknar det här exemplet:

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

Kontrollera om OSM-kontrollanten har försett webhooken Validering (eller Mutating) med ett CA-paket genom att använda följande kommando:

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

Exempel på utdata>

1845

Talet i utdata anger antalet byte eller storleken på CA-paketet. Om utdata är tomma, 0 eller ett tal under 1 000, är CA-paketet inte korrekt tillhandahållet. Utan ett korrekt CA-paket ValidatingWebhook genererar ett fel.

Kontrollera resursen osm-mesh-config

Kontrollera om resursen finns:

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

Kontrollera värdet för OSM-inställningen meshconfig :

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

Leta efter utdata som liknar det här exemplet:

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

I följande tabell visas osm-mesh-config resursvärden:

Kontrollera namnområden

Du kan använda osm namespace add kommandot för att koppla namnområden till ett specifikt tjänstnät. När ett Kubernetes-namnområde ingår i nätet utför du följande steg för att bekräfta att kraven uppfylls.

Visa anteckningarna för bookbuyer namnområdet:

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

Följande kommentar måste finnas:

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

Visa etiketterna för bookbuyer namnområdet:

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

Följande etikett måste finnas:

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

Om du inte använder osm CLI kan du manuellt lägga till dessa anteckningar i dina namnområden. Om ett namnområde inte kommenteras med "openservicemesh.io/sidecar-injection": "enabled", eller om det inte är märkt med "openservicemesh.io/monitored-by": "osm", lägger OSM-injektorn inte till Envoy-sidovagnar.

Verifiera SMI CRD:erna

För OSM Service Mesh Interface (SMI) kontrollerar du om klustret har nödvändiga anpassade resursdefinitioner (CRD):

kubectl get crds

Kontrollera att CRD:erna motsvarar de versioner som är tillgängliga i versionsgrenen. Information om vilka CRD-versioner som används finns i versioner som stöds av SMI och välj din version på menyn Versioner .

Hämta versionerna av de installerade CRD:erna med hjälp av följande kommando:

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

Om CRD saknas använder du följande kommandon för att installera dem i klustret. Ersätt versionen i dessa kommandon efter behov (i stället för v1.1.0 kan du använda 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

Information om hur CRD-versioner ändras mellan releaser finns i OSM-versionsanteckningar.

Felsöka certifikathantering

Information om hur OSM utfärdar och hanterar certifikat till Envoy-proxyservrar som körs på programpoddar finns i OSM-dokumentationen.

Uppgradera Envoy

När en ny podd skapas i ett namnområde som övervakas av tillägget, kommer OSM att lägga till en Envoy proxy-sidovagn i den podden. Om Envoy-versionen behöver uppdateras följer du stegen i uppgraderingsguiden i OSM-dokumentationen.

Relaterat innehåll

• Läs mer om klustertillägg.
• Visa allmänna felsökningstips för Arc-aktiverade Kubernetes-kluster.