Compartilhar via


Solucionar problemas de extensão para clusters do Kubernetes habilitados para Azure Arc

Este documento fornece dicas de solução de problemas comuns relacionados a extensões de cluster, como GitOps (Flux v2) e Open Service Mesh.

Para obter ajuda para solucionar problemas gerais com o Kubernetes habilitado para Azure Arc, consulte Solucionar problemas do Kubernetes habilitado para Azure Arc.

GitOps (Flux v2)

Observação

A extensão Flux v2 pode ser usada em clusters do Kubernetes habilitados para Azure Arc ou clusters do AKS (Serviço de Kubernetes do Azure). Essas dicas de solução de problemas geralmente se aplicam independentemente do tipo de cluster.

Para obter ajuda geral para solucionar problemas com recursos fluxConfigurations, execute estes comandos da CLI do Azure com o parâmetro --debug especificado:

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

Erros de execução de webhook/dry

Se você observar o Flux falhar ao se reconciliar com um erro como dry-run failed, error: admission webhook "<webhook>" does not support dry run, resolva o problema encontrando a ValidatingWebhookConfiguration ou a MutatingWebhookConfiguration e definindo o sideEffects como None ou NoneOnDryRun:

Para obter mais informações, confira Como fazer para resolver erros webhook does not support dry run?

Erros ao instalar a extensão do navegadormicrosoft.flux

A extensão microsoft.flux instala os controladores do Flux e os agentes do Azure GitOps nos clusters de Kubernetes habilitados para Azure Arc ou do AKS (Serviço de Kubernetes do Azure). Se a extensão ainda não estiver instalada em um cluster e você criar um recurso de configuração do GitOps para esse cluster, a extensão será instalada automaticamente.

Se você tiver um erro durante a instalação ou se a extensão estiver em um estado com falha, verifique se o cluster não tem nenhuma política que restrinja a criação do namespace ou recursos do flux-system nesse namespace.

Para um cluster do AKS, verifique se a assinatura tem o sinalizador de recurso Microsoft.ContainerService/AKS-ExtensionManager habilitado.

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

Depois disso, execute este comando para determinar se há outros problemas. Defina o parâmetro de tipo de cluster (-t) como connectedClusters para um cluster habilitado para Arc ou managedClusters para um cluster do AKS. O nome da extensão microsoft.flux será "flux" se a extensão tiver sido instalada automaticamente durante a criação de uma configuração do GitOps. Procure informações no objeto statuses.

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

Os resultados exibidos podem ajudá-lo a determinar o que deu errado e como corrigi-lo. As possíveis ações de correção incluem:

  • Forçar a exclusão da extensão executando az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>
  • Desinstalar a versão do Helm executando helm uninstall flux -n flux-system
  • Excluir o namespace flux-system do cluster executando kubectl delete namespaces flux-system

Depois disso, você pode recriar uma configuração de fluxo, que instala automaticamente a extensão microsoft.flux ou reinstalar a extensão de fluxo manualmente.

Erros ao instalar a extensão microsoft.flux em um cluster com a Identidade do Pod do Microsoft Entra habilitada

Se você tentar instalar a extensão do Flux em um cluster que tenha a Identidade de Pod do Microsoft Entra habilitada, poderá ocorrer um erro no pod do agente de extensão:

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

O status da extensão também retorna como 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}}\"}]}}",

Nesse caso, o pod do agente de extensão tenta obter seu token do IMDS no cluster. mas a solicitação de token é interceptada pela identidade do pod). Para corrigir esse problema, atualize para a versão mais recente da extensãomicrosoft.flux.

Problemas com a identidade do kubelet ao instalar a extensão microsoft.flux em um cluster do AKS

Com clusters AKs, uma das opções de autenticação é identidade kubelet usando uma identidade gerenciada atribuída pelo usuário. O uso da identidade kubelet pode reduzir a sobrecarga operacional e aumenta a segurança ao se conectar a recursos do Azure, como o Registro de Contêiner do Azure.

Para permitir que o Flux use a identidade kubelet, adicione o parâmetro --config useKubeletIdentity=true ao instalar a extensão Flux.

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

Garantir que os requisitos de memória e CPU para microsoft.flux instalação de extensão sejam atendidos

Os controladores instalados no cluster Kubernetes com a extensão microsoft.flux exigem que os recursos de CPU e memória agendem corretamente nos nós de cluster do Kubernetes. Verifique se o cluster é capaz de atender aos recursos mínimos de memória e CPU que podem ser solicitados. Observe também os limites máximos para possíveis requisitos de recursos de CPU e memória mostrados aqui.

Nome do contêiner Minimum CPU Memória mínima Limite máximo de CPU Máximo de memória
fluxconfig-agent 5min 30 Mi 50 m 150 Mi
fluxconfig-controller 5min 30 Mi 100 m 150 Mi
fluent-bit 5min 30 Mi 20 m 150 Mi
helm-controller 100 m 64 Mi 1000 m 1 Gi
source-controller 50 m 64 Mi 1000 m 1 Gi
kustomize-controller 100 m 64 Mi 1000 m 1 Gi
notification-controller 100 m 64 Mi 1000 m 1 Gi
image-automation-controller 100 m 64 Mi 1000 m 1 Gi
image-reflector-controller 100 m 64 Mi 1000 m 1 Gi

Se você habilitou uma Política personalizada ou interna do Azure Gatekeeper que limita os recursos para contêineres em clusters do Kubernetes, como Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits, verifique se os limites de recursos na política são maiores do que os limites mostrados aqui ou se o namespace flux-system faz parte do parâmetro excludedNamespaces na atribuição de política.

Flux v1

Observação

Recomendamos migrar para o Flux v2 o mais rápido possível. O suporte para os recursos de configuração de cluster baseados em Flux v1 criados antes de 1º de janeiro de 2024 terminará em 24 de maio de 2025. A partir de 1º de janeiro de 2024, você não poderá criar novos recursos de configuração de cluster baseados no Flux v1.

Para ajudar a solucionar problemas com o recurso sourceControlConfigurations no Flux v1, execute estes comandos da CLI do Azure com --debug parâmetro especificado:

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

Insights de Contêiner do Azure Monitor

Esta seção fornece ajuda para solucionar problemas com os Insights de Contêiner do Azure Monitor para clusters do Kubernetes habilitados para o Azure Arc.

Habilitando o modo privilegiado para o cluster do Kubernetes Com Canonical Charme

Os Insights de Contêiner do Azure Monitor requer que seu DaemonSet seja executado no modo privilegiado. Para configurar com êxito um cluster Canonical Kubernetes reduzido para monitoramento, execute o seguinte comando:

juju config kubernetes-worker allow-privileged=true

Não é possível instalar o AMA (Agente do Azure Monitor) no Oracle Linux 9.x

Ao tentar instalar o AMA (Agente do Azure Monitor) em um cluster do Kubernetes Oracle Linux (RHEL) 9.x, os pods AMA e o pod AMA-RS podem não funcionar corretamente devido ao contêiner addon-token-adapter no pod. Com esse erro, ao verificar os logs do pod ama-logs-rs, addon-token-adapter container, você verá uma saída semelhante à seguinte:

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.

Esse erro ocorre porque a instalação da extensão requer o módulo iptable_nat, mas este módulo não é carregado automaticamente nas distribuições do Oracle Linux (RHEL) 9.x.

Para corrigir esse problema, você deve carregar explicitamente o módulo iptables_nat em cada nó no cluster, usando o comando modprobe sudo modprobe iptables_nat. Depois de entrar em cada nó e adicionar manualmente o módulo iptable_nat, repita a instalação da AMA.

Observação

Executar esta etapa não torna o módulo iptables_nat persistente.

Open Service Mesh habilitado para o Azure Arc

Esta seção fornece comandos que podem ser usados para validar e solucionar problemas de implantação dos componentes de extensão da Malha de Serviço Aberta (OSM) no cluster.

Verificar a implantação do controlador OSM

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

Se o controlador de OSM estiver íntegro, você verá uma saída semelhante a:

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

Verificar pods do controlador OSM

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

Se o controlador de OSM estiver íntegro, você verá uma saída semelhante a:

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

Mesmo que um controlador tenha sido removido em algum momento, há outro que é READY 1/1 e Running com 0 reinicializações. Se a coluna READY for diferente de 1/1, a malha de serviço estará em um estado desfeito. A coluna READY com 0/1 indica que o contêiner do plano de controle está falhando.

Use o seguinte comando para inspecionar logs do controlador:

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

A coluna READY com um número maior que 1 após o / indica que há sidecars instalados. O Controlador de OSM geralmente não funcionará corretamente com sidecars anexados.

Verificar o serviço do controlador OSM

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

Se o controlador de OSM estiver íntegro, você verá a seguinte saída:

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

Observação

O CLUSTER-IP será diferente. O serviço NAME e PORT(S) deve corresponder ao que é mostrado aqui.

Verificar pontos de extremidade do controlador OSM

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

Se o controlador de OSM estiver íntegro, você verá uma saída semelhante a:

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

Se o cluster não tiver ENDPOINTS para osm-controller, o plano de controle não estará íntegro. Esse estado não íntegro significa que o pod do controlador falhou ou que ele nunca foi implantado corretamente.

Verificar a implantação do injetor do OSM

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

Se o injetor de OSM estiver íntegro, você verá uma saída semelhante a:

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

Verificar o pod do injetor do OSM

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

Se o injetor de OSM estiver íntegro, você verá uma saída semelhante a:

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

A coluna READY deve ser 1/1. Qualquer outro valor indica um pod do injetador OSM não íntegro.

Verificar o serviço de injetor do OSM

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

Se o injetor de OSM estiver íntegro, você verá uma saída semelhante a:

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

Verifique se o endereço IP listado para o serviço osm-injector é 9090. Não deve haver EXTERNAL-IP.

Verificar pontos de extremidade do injetor osM

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

Se o injetor de OSM estiver íntegro, você verá uma saída semelhante a:

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

Para que o OSM funcione, deve haver pelo menos um ponto de extremidade para osm-injector. O endereço IP dos pontos de extremidade do injetor do OSM variará, mas a porta 9090 deve ser a mesma.

Verificar a Validação e a Mutação de webhooks

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Se o webhook da Validação estiver íntegro, você verá uma saída semelhante a:

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

Se o webhook de Mutação estiver íntegro, você verá uma saída semelhante a:

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

Verifique o serviço e o pacote de AC do webhook da Validação usando este comando:

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

Um webhook de Validação bem configurado terá uma saída semelhante a:

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

Verificar o serviço e o pacote de AC do webhook de Mutação ao usar o comando a seguir:

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

Um webhook de Mutação bem configurado terá uma saída semelhante a:

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

Verifique se o controlador da OSM atribuiu ao um pacote de AC ao webhook de Validação (ou Mutação) usando o seguinte comando:

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

Saída de exemplo:

1845

O número na saída indica o número de bytes ou o tamanho do pacote de AC. Se a saída estiver vazia, 0 ou um número abaixo de 1000, o Pacote de AC não será provisionado corretamente. Sem um pacote de AC correto, o ValidatingWebhook gerará um erro.

Verifique o recurso osm-mesh-config

Verifique a existência do recurso:

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

Verifique o conteúdo do MeshConfig do OSM:

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

Você deve ver uma saída semelhante a:

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

Valores de Recurso osm-mesh-config:

Chave Type Valor padrão Exemplos de comando do Patch kubectl
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 string "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 string "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 string "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

Verificar namespaces

Observação

O namespace arc-osm-system nunca participará de uma malha de serviço e nunca será rotulado ou anotado com a chave/os valores mostrados aqui.

Usamos o comando osm namespace add para ingressar namespaces em uma malha de serviço específica. Quando um namespace do Kubernetes faz parte da malha, siga estas etapas para confirmar se os requisitos são atendidos.

Exiba as anotações do namespace bookbuyer:

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

As anotações a seguir precisam estar presentes:

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

Exiba os rótulos do namespace bookbuyer:

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

As etiquetas a seguir precisam estar presentes:

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

Se você não estiver usando a CLI osm, também poderá adicionar manualmente essas anotações aos seus namespaces. Se um namespace não for anotado com "openservicemesh.io/sidecar-injection": "enabled"ou não for rotulado com "openservicemesh.io/monitored-by": "osm", o injetador OSM não adicionará sidecars envoy.

Observação

Depois que osm namespace add for chamado, apenas novos pods serão injetados com um Envoy sidecar. Os pods existentes devem ser reiniciados com o comando kubectl rollout restart deployment.

Verificar os CRDs do SMI

Verifique se o cluster tem as CRDs (Definições de Recurso Personalizado) necessárias usando o seguinte comando:

kubectl get crds

Verifique se os CRDs correspondem às versões disponíveis no branch de versão. Para confirmar quais versões de CRD estão em uso, visite a página de versões com suporte SMI e selecione sua versão na lista suspensa Versões.

Obtenha as versões dos CRDs instalados com o seguinte comando:

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

Se os CRDs forem ignorados, use os comandos a seguir para instalá-los no cluster. Substitua a versão nesses comandos conforme necessário (por exemplo, v1.1.0 seria 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

Confira as notas de versão do OSM para ver as alterações de CRD entre as versões.

Solucionar problemas de gerenciamento de certificados

Para obter informações sobre como o OSM emite e gerencia certificados para o proxies do Envoy em execução nos pods de aplicativo, confira o site de documentação do OSM.

Atualizar o Envoy

Quando um novo pod é criado em um namespace monitorado pelo complemento, o OSM injeta um sidecar de proxy do Envoy nesse pod. Se a versão do Envoy precisar ser atualizada, siga as etapas no Guia de Atualização no site de documentação do OSM.

Próximas etapas