Dela via


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)

Kommentar

Du kan använda Flux v2-tillägget i ett Azure Arc-aktiverat Kubernetes-kluster eller i ett AkS-kluster (Azure Kubernetes Service). Dessa felsökningstips gäller vanligtvis för alla klustertyper.

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 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 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 visar ett Failed tillstånd kontrollerar du att klustret inte har några principer som begränsar skapandet flux-system av namnområdet eller någon av resurserna i 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 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 fluxnamnet på microsoft.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 Microsoft Entra-poddhanterad identitet

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 extension-agent försöker podden hämta sin token från Azure Instance Metadata Service i klustret, men tokenbegäran fångas upp av poddidentiteten. 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:

Containerns namn 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 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.

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 skapades 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, inklusive parametern --debug :

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

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.

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 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 distributionen 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 kontrollant har statusen Evicted vid ett tillfälle har en annan kontrollant status 1/1 och Running READY 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/1kraschar 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

Kommentar

Det faktiska värdet för CLUSTER-IP skiljer sig från det här exemplet. Värdena för NAME och PORT(S) ska matcha det som visas i det här exemplet.

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ågot ENDPOINTS som har värdet 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 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 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 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 webhooken Validering 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 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ä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 webhook för muterande har utdata som liknar det här exemplet:

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

Kontrollera om OSM-kontrollanten har gett webhooken Validering (eller Mutating) ett 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 1 000 är CA-paketet inte korrekt etablerat. 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:

Nyckel Typ Default value 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

Namnområdet arc-osm-system deltar aldrig i ett tjänstnät och är aldrig märkt eller kommenterat med nyckel/värde-paren som visas här.

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.

Kommentar

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

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 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 i OSM-dokumentationen.

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 i OSM-dokumentationen.