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

Det här dokumentet innehåller felsökningstips för vanliga problem som rör klustertillägg, till exempel GitOps (Flux v2) och Open Service Mesh.

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

GitOps (Flux v2)

Kommentar

Flux v2-tillägget kan användas i Antingen Azure Arc-aktiverade Kubernetes-kluster eller IKS-kluster (Azure Kubernetes Service). De här felsökningstipsen gäller vanligtvis oavsett klustertyp.

För allmän hjälp med felsökning av problem med fluxConfigurations resurser kör du dessa Azure CLI-kommandon med den angivna parametern --debug :

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

Webhook-/torrkörningsfel

Om flux inte kan stämmas av med ett fel som dry-run failed, error: admission webhook "<webhook>" does not support dry runkan du lösa problemet genom att hitta ValidatingWebhookConfiguration eller MutatingWebhookConfiguration och ange sideEffects till None eller NoneOnDryRun:

Mer information finns i Hur gör jag för att lösa webhook does not support dry run fel?

Fel vid installation av microsoft.flux tillägget

Tillägget microsoft.flux installerar Flux-styrenheterna och Azure GitOps-agenterna i dina Azure Arc-aktiverade Kubernetes- eller Azure Kubernetes Service-kluster (AKS). 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 är i ett feltillstånd kontrollerar du att klustret inte har några principer som begränsar skapandet av flux-system namnområdet eller resurserna i namnområdet.

För ett AKS-kluster kontrollerar du att prenumerationen har funktionsflaggan Microsoft.ContainerService/AKS-ExtensionManager aktiverad.

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

Därefter kör du det här kommandot för att avgöra om det finns andra problem. Ange parametern klustertyp (-t) till connectedClusters för ett Arc-aktiverat kluster eller managedClusters för ett AKS-kluster. Namnet på microsoft.flux tillägget är "flux" om tillägget installerades automatiskt när en GitOps-konfiguration skapades. Leta efter information i objektet statuses.

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

De visade resultaten kan hjälpa dig att avgöra vad som gick fel 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örakubectl delete namespaces flux-system

Därefter kan du antingen återskapa en flödeskonfigurationmicrosoft.flux, som installerar tillägget automatiskt, eller så kan du installera om fluxtillägget manuellt.

Fel vid installation av microsoft.flux tillägget i ett kluster med Microsoft Entra Pod Identity aktiverat

Om du försöker installera Flux-tillägget i ett kluster som har Microsoft Entra-poddidentitet (Azure AD) aktiverat kan ett fel uppstå i extension-agent-podden:

{"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 också 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 podden extension-agent hämta sin token från IMDS i klustret. men tokenbegäran fångas upp av poddidentiteten). Åtgärda problemet genom att uppgradera till den senaste versionen av microsoft.flux tillägget.

Problem med kubelet-identitet vid installation av microsoft.flux tillägget i ett AKS-kluster

Med AKs-kluster är ett av autentiseringsalternativen kubelet-identitet med hjälp av en användartilldelad hanterad identitet. Användning av kubelet-identitet kan minska driftkostnaderna och öka säkerheten vid anslutning till Azure-resurser som Azure Container Registry.

Om du vill låta Flux använda kubelet-identitet lägger du till parametern --config useKubeletIdentity=true när du installerar Flux-tillägget.

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

Se till att minnes- och CPU-kraven för microsoft.flux tilläggsinstallationen uppfylls

Kontrollanterna som är installerade i kubernetes-klustret med microsoft.flux tillägget kräver processor- och minnesresurser för att schemalägga kubernetes-klusternoderna korrekt. Se till att klustret kan uppfylla det minsta minne och de processorresurser som kan begäras. Observera även de maximala gränserna för potentiella processor- och minnesresurskrav som visas här.

Containernamn Minsta cpu-användning Minsta mängd minne Maximal processoranvändning Högsta mängd minne
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

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

Flux v1

Kommentar

Vi rekommenderar att du migrerar till Flux v2 så snart som möjligt. Stöd för Flux v1-baserade klusterkonfigurationsresurser som skapats före den 1 januari 2024 upphör den 24 maj 2025. Från och med den 1 januari 2024 kan du inte skapa nya Flux v1-baserade klusterkonfigurationsresurser.

För att felsöka problem med resursen sourceControlConfigurations i Flux v1 kör du följande Azure CLI-kommandon med --debug angiven parameter:

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

Azure Monitor Container Insights

Det här avsnittet innehåller hjälp med att felsöka problem med Azure Monitor Container Insights för Azure Arc-aktiverade Kubernetes-kluster.

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

Azure Monitor Container Insights kräver att dess 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 Azure Monitor Agent (AMA) på Oracle Linux 9.x

När du försöker installera Azure Monitor Agent (AMA) på ett Oracle 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. Med det här felet visas utdata som liknar följande när du kontrollerar loggarna för ama-logs-rs podden addon-token-adapter container:

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 med kommandot modprobesudo 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.

Kommentar

Om du utför det här steget blir modulen iptables_nat inte beständig.

Azure Arc-aktiverat Open Service Mesh

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

Kontrollera distributionen av OSM-kontrollanten

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 ser du utdata som liknar:

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 kontrollant avlägsnades någon gång finns det en annan som är READY 1/1 och Running med 0 omstarter. Om kolumnen READY är något annat än 1/1är tjänstnätet i ett brutet tillstånd. Kolumn READY med 0/1 anger att kontrollplanets container kraschar.

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

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

Kolumn READY med ett tal som är högre än 1 efter / anger att det finns sidovagnar installerade. OSM-styrenheten fungerar vanligtvis inte korrekt med sidovagnar anslutna.

Kontrollera OSM-kontrollanttjänsten

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

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

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

Kommentar

Kommer CLUSTER-IP att vara annorlunda. Tjänsten NAME och PORT(S) bör matcha det som visas här.

Kontrollera OSM-kontrollantens slutpunkter

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

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

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

Om klustret inte har något ENDPOINTS för osm-controllerär kontrollplanet inte felfri. Det här tillståndet innebär att kontrollantpodden kraschade eller att den aldrig distribuerades korrekt.

Kontrollera distributionen av OSM-injektor

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

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

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 ser du utdata som liknar:

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

Kolumnen READY måste vara 1/1. Alla andra värden anger en osm-injektorpodd som inte är felfri.

Kontrollera OSM-injektortjänsten

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

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

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 får inte finnas någon EXTERNAL-IP.

Kontrollera OSM-injektorslutpunkter

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

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

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 porten 9090 måste vara densamma.

Kontrollera validering och mutering av webhooks

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Om webhooken Validering är felfri visas utdata som liknar:

NAME                     WEBHOOKS   AGE
osm-validator-mesh-osm   1          81m
kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Om webhooken Mutating är felfri visas utdata som liknar:

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

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

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

En väl konfigurerad konfiguration för validering av webhook har utdata som liknar:

{
  "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äl konfigurerad konfiguration av muterande webhook har utdata som liknar:

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

Kontrollera om OSM-styrenheten har gett webhooken Validering (eller muterande) en CA-paket med hjälp av 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 1000 är CA-paketet inte korrekt etablerat. Utan ett korrekt CA-paket genererar det ValidatingWebhook ett fel.

Kontrollera resursen osm-mesh-config

Kontrollera om resursen finns:

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

Kontrollera innehållet i OSM MeshConfig:

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

Du bör se utdata som liknar följande:

apiVersion: config.openservicemesh.io/v1alpha1
kind: MeshConfig
metadata:
  creationTimestamp: "0000-00-00A00:00:00A"
  generation: 1
  name: osm-mesh-config
  namespace: arc-osm-system
  resourceVersion: "2494"
  uid: 6c4d67f3-c241-4aeb-bf4f-b029b08faa31
spec:
  certificate:
    certKeyBitSize: 2048
    serviceCertValidityDuration: 24h
  featureFlags:
    enableAsyncProxyServiceMapping: false
    enableEgressPolicy: true
    enableEnvoyActiveHealthChecks: false
    enableIngressBackendPolicy: true
    enableMulticlusterMode: false
    enableRetryPolicy: false
    enableSnapshotCacheMode: false
    enableWASMStats: true
  observability:
    enableDebugServer: false
    osmLogLevel: info
    tracing:
      enable: false
  sidecar:
    configResyncInterval: 0s
    enablePrivilegedInitContainer: false
    logLevel: error
    resources: {}
  traffic:
    enableEgress: false
    enablePermissiveTrafficPolicyMode: true
    inboundExternalAuthorization:
      enable: false
      failureModeAllow: false
      statPrefix: inboundExtAuthz
      timeout: 1s
    inboundPortExclusionList: []
    outboundIPRangeExclusionList: []
    outboundPortExclusionList: []
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

osm-mesh-config resursvärden:

Key Typ Standardvärde Exempel på Kubectl-korrigeringskommandon
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 matris [] kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge
spec.traffic.outboundIPRangeExclusionList matris [] 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 matris [] kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"inboundPortExclusionList":[6379,8080]}}}' --type=merge
spec.certificate.serviceCertValidityDuration sträng "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 sträng "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 sträng "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

Kontrollera namnområden

Kommentar

Arc-osm-system-namnområdet kommer aldrig att delta i ett tjänstnät och kommer aldrig att märkas eller kommenteras med nyckeln/värdena som visas här.

Vi använder osm namespace add kommandot för att koppla namnområden till ett visst tjänstnät. När ett Kubernetes-namnområde ingår i nätet följer du dessa steg för att bekräfta att kraven uppfylls.

Visa anteckningarna för namnområdet bookbuyer:

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

Följande kommentar måste finnas:

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

Visa etiketterna för namnområdet bookbuyer:

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 också lägga till dessa anteckningar manuellt i dina namnområden. Om ett namnområde inte kommenteras med "openservicemesh.io/sidecar-injection": "enabled", eller inte är märkt med "openservicemesh.io/monitored-by": "osm", lägger OSM-injektorn inte till Envoy-sidovagnar.

Kommentar

När osm namespace add har anropats matas endast nya poddar in med en Envoy-sidovagn. Befintliga poddar måste startas om med kubectl rollout restart deployment kommandot .

Verifiera SMI CRD:erna

Kontrollera om klustret har de anpassade resursdefinitioner (CRD) som krävs med hjälp av följande kommando:

kubectl get crds

Kontrollera att CRD:erna motsvarar de versioner som är tillgängliga i versionsgrenen. Om du vill bekräfta vilka CRD-versioner som används går du till sidan versioner som stöds av SMI och väljer din version i listrutan Versioner .

Hämta versionerna av de installerade CRD:erna med 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 (till exempel skulle v1.1.0 vara 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 du ser CRD-ändringar mellan versioner finns i OSM-viktig information.

Felsöka certifikathantering

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

Uppgradera Envoy

När en ny podd skapas i ett namnområde som övervakas av tillägget matar OSM in en envoyproxy-sidovagn i podden. Om Envoy-versionen behöver uppdateras följer du stegen i uppgraderingsguiden på OSM-dokumentwebbplatsen.

Nästa steg