Partilhar via

Solucionar problemas de extensão para clústeres Kubernetes com Azure Arc habilitado

Este artigo descreve dicas de solução de problemas comuns relacionados a extensões de cluster como GitOps (Flux v2) no Azure ou Open Service Mesh (OSM).

Para obter ajuda com a solução de problemas do Kubernetes habilitado para Azure Arc em geral, consulte Solucionar problemas do Kubernetes habilitado para Azure Arc.

GitOps (Fluxo v2)

Nota

Você pode usar a extensão Flux v2 em um cluster Kubernetes habilitado para Azure Arc ou em um cluster do Serviço Kubernetes do Azure (AKS). Essas dicas geralmente se aplicam a todos os tipos de cluster.

Para obter ajuda geral com a solução de problemas quando você usa fluxConfigurations recursos, execute estes comandos da CLI do Azure com o --debug parâmetro:

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

Erro de configuração do Helm chart

Poderá ver uma mensagem de erro que diz "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]".

Para resolver esse problema:

  • Se você estiver executando a microsoft.flux versão 1.15.1 ou anterior, atualize para a versão 1.15.2 ou posterior.
  • Se você estiver executando microsoft.flux a versão 1.16.2 nas regiões Centro-Oeste dos EUA, França Central, Sul do Reino Unido ou Europa Ocidental, atualize para a versão 1.16.3 ou posterior.

Erros de execução seca do Webhook

O Flux pode falhar e exibir um erro semelhante ao dry-run failed, error: admission webhook "<webhook>" does not support dry run. Para resolver o problema, vá para ValidatingWebhookConfiguration ou MutatingWebhookConfiguration. Na configuração, defina o valor para sideEffects como None ou NoneOnDryRun.

Para obter mais informações, consulte Como resolvo erros "webhook não suporta execução seca"?.

Erros ao instalar a extensão microsoft.flux

A microsoft.flux extensão instala controladores Flux e agentes Azure GitOps num cluster de Kubernetes com suporte a Azure Arc ou num cluster de AKS. Se a extensão ainda não estiver instalada em um cluster e você criar um recurso de configuração do GitOps para o cluster, a extensão será instalada automaticamente.

Se ocorrer um erro durante a instalação ou se a extensão mostrar um Failed estado, certifique-se de que o cluster não tenha políticas que restrinjam a criação do flux-system namespace ou de qualquer um dos recursos nesse namespace.

Para um cluster AKS, verifique se o sinalizador Microsoft.ContainerService/AKS-ExtensionManager de recurso está habilitado na assinatura do Azure:

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

Em seguida, execute o seguinte comando para determinar se há outros problemas. Defina o parâmetro de tipo de cluster (-t) como connectedClusters para um cluster habilitado para Azure Arc ou para managedClusters um cluster AKS. Se a extensão foi instalada automaticamente quando você criou sua configuração do GitOps, o nome da microsoft.flux extensão é flux.

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

A saída pode ajudá-lo a identificar o problema e como corrigi-lo. As possíveis ações de reparação incluem:

  • Force-delete a extensão executando az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>.
  • Desinstale a release do Helm executando helm uninstall flux -n flux-system.
  • Exclua o flux-system namespace do cluster executando kubectl delete namespaces flux-system.

Em seguida, você pode criar uma nova configuração do Flux, que instala a microsoft.flux extensão automaticamente, ou você pode instalar a extensão do Flux manualmente.

Erros ao instalar a extensão microsoft.flux em um cluster que tem uma identidade gerenciada por pod do Microsoft Entra

Se você tentar instalar a extensão Flux em um cluster que tenha uma identidade gerenciada pelo pod do Microsoft Entra, poderá ocorrer um erro no extension-agent pod. A saída é semelhante a este exemplo:

{"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 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 extension-agent pod tenta obter o seu token do Serviço de Metadados de Instância do Azure no cluster, mas a solicitação de token é intercetada pela identidade do pod. Para corrigir esse problema, atualize para a versão mais recente da microsoft.flux extensão.

Requisitos de recursos de memória e CPU para instalar a extensão microsoft.flux

Os controladores que são instalados no cluster de Kubernetes aquando da instalação da extensão microsoft.flux devem ter recursos suficientes de CPU e memória para serem corretamente alocados num nó de cluster de Kubernetes. Certifique-se de que o cluster atenda aos requisitos mínimos de memória e recursos da CPU.

A tabela a seguir lista os limites mínimo e máximo para possíveis requisitos de recursos de CPU e memória para este cenário:

Nome do contêiner CPU mínima Mínimo de memória CPU máxima Máximo de memória
fluxconfig-agent 5 metros 30 mi 50 metros 150 Mi
fluxconfig-controller 5 metros 30 mi 100 metros 150 Mi
fluent-bit 5 metros 30 mi 20 metros 150 Mi
helm-controller 100 metros 64 Mi 1.000 metros 1 GiB
source-controller 50 metros 64 Mi 1.000 metros 1 GiB
kustomize-controller 100 metros 64 Mi 1.000 metros 1 GiB
notification-controller 100 metros 64 Mi 1.000 metros 1 GiB
image-automation-controller 100 metros 64 Mi 1.000 metros 1 GiB
image-reflector-controller 100 metros 64 Mi 1.000 metros 1 GiB

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

Azure Monitor Informações sobre Contêineres

Esta seção fornece ajuda com a resolução de problemas com informações de contêiner no Azure Monitor para clusters Kubernetes ativados pelo Azure Arc.

Habilitar o modo privilegiado para um cluster Canonical Charmed Kubernetes

O Azure Monitor Container Insights requer que seu Kubernetes DaemonSet seja executado no modo privilegiado. Para configurar com êxito um cluster Kubernetes Canonical Charmed para monitoramento, execute o seguinte comando:

juju config kubernetes-worker allow-privileged=true

Não é possível instalar pods AMA no Oracle Linux 9.x

Se você tentar instalar o Azure Monitor Agent (AMA) em um cluster Kubernetes Oracle Linux (Red Hat Enterprise Linux (RHEL)) 9.x, os pods AMA e AMA-RS podem não funcionar corretamente devido ao addon-token-adapter contêiner no pod. Ao verificares os registos do pod ama-logs-rs, em addon-token-adapter container, observas uma saída que é semelhante ao exemplo 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.

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

Para corrigir esse problema, você deve carregar explicitamente o iptables_nat módulo em cada nó no cluster. Use o modprobe comando sudo modprobe iptables_nat. Depois de entrar em cada nó e adicionar o módulo iptable_nat manualmente, tente reinstalar o AMA.

Nota

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

Azure Arc-enabled Open Service Mesh (Malha de Serviço Aberta compatível com Azure Arc)

Esta seção demonstra os comandos que você pode usar para validar e solucionar problemas de implantação de componentes de extensão OSM (Open Service Mesh) em seu cluster.

Verifique a implantação do controlador OSM

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

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

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

Verifique os pods do controlador OSM

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

Se o controlador OSM estiver íntegro, a saída semelhante ao exemplo a seguir será exibida:

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 um status de Evicted num determinado momento, outro controlador tem o status READY1/1 e Running com 0 reinicializações. Se o READY estado for diferente de 1/1, a malha de serviço está em estado quebrado. Se READY é 0/1, o contêiner do plano de controlo está a falhar.

Use o seguinte comando para inspecionar os logs do controlador:

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

Se o READY estado for um número maior do que 1 após a barra (/), os sidecars são instalados. O controlador OSM geralmente não funciona corretamente quando os sidecars estão ligados.

Verifique o serviço do controlador OSM

Para verificar o serviço do controlador OSM, execute este comando:

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

Se o controlador OSM estiver íntegro, a saída semelhante ao exemplo a seguir será exibida:

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

Nota

O valor real para CLUSTER-IP será diferente deste exemplo. Os valores para NAME e PORT(S) devem corresponder ao que é mostrado neste exemplo.

Verifique os pontos finais do controlador OSM

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

Se o controlador OSM estiver íntegro, a saída semelhante ao exemplo a seguir será exibida:

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

Se o cluster não tiver ENDPOINTS que tenha o valor osm-controller, o plano de controle não está saudável. Este estado deficiente significa que o pod do controlador falhou ou que nunca foi implantado corretamente.

Verifique a implantação do injetor OSM

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

Se o injetor OSM estiver íntegro, será exibida uma saída semelhante ao exemplo seguinte:

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

Verifique o pod do injetor OSM

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

Se o injetor OSM estiver íntegro, será exibida uma saída semelhante ao exemplo seguinte:

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

O READY status deve ser 1/1. Qualquer outro valor indica um pod injetor OSM não saudável.

Verifique o serviço de injetor OSM

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

Se o injetor OSM estiver íntegro, será exibida uma saída semelhante ao exemplo seguinte:

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

Certifique-se de que o endereço IP listado para osm-injector o serviço é 9090. Não deve haver nenhum valor listado para EXTERNAL-IP.

Verifique os pontos finais do injetor OSM

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

Se o injetor OSM estiver íntegro, será exibida uma saída semelhante ao exemplo seguinte:

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 OSM varia, mas o valor da porta 9090 deve ser o mesmo.

Verifique webhooks: Validação e Mutação

Verifique o webhook de validação executando o seguinte comando:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Se o webhook Validating estiver íntegro, a saída semelhante ao exemplo a seguir será exibida:

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

Verifique o webhook Mutating executando o seguinte comando:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Se o webhook Mutating estiver a funcionar corretamente, uma saída semelhante ao exemplo a seguir será exibida:

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

Verifique o serviço e o pacote da Autoridade de Certificação (pacote de CA) do webhook Validando usando este comando:

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

Um webhook de Validação bem configurado tem uma saída semelhante a este exemplo:

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

Verifique o serviço e o pacote de CA do webhook Mutating usando o seguinte comando:

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

Um webhook mutante bem configurado tem uma saída semelhante a este exemplo:

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

Verifique se o controlador OSM deu ao webhook Validating (ou Mutating) um pacote de CA 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 conjunto de certificados de autoridade. Se a saída estiver vazia, for 0 ou um número inferior a 1.000, o pacote CA não está corretamente provisionado. Sem um pacote de CA correto, ValidatingWebhook gera 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 valor da configuração OSM meshconfig :

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

Procure uma saída semelhante a este exemplo:

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

A tabela a seguir lista osm-mesh-config os valores de recursos:

Chave Tipo Valor padrão Exemplos de comandos de patch Kubectl
spec.traffic.enableEgress booleano false kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"enableEgress":false}}}' --type=merge
spec.traffic.enablePermissiveTrafficPolicyMode booleano true kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"enablePermissiveTrafficPolicyMode":true}}}' --type=merge
spec.traffic.outboundPortExclusionList matriz [] kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"outboundPortExclusionList":[6379,8080]}}}' --type=merge
spec.traffic.outboundIPRangeExclusionList matriz [] 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 matriz [] kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"traffic":{"inboundPortExclusionList":[6379,8080]}}}' --type=merge
spec.certificate.serviceCertValidityDuration cadeia de caracteres "24h" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"certificate":{"serviceCertValidityDuration":"24h"}}}' --type=merge
spec.observability.enableDebugServer booleano false kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"enableDebugServer":false}}}' --type=merge
spec.observability.osmLogLevel cadeia de caracteres "info" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"osmLogLevel": "info"}}}}' --type=merge
spec.observability.tracing.enable booleano false kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"observability":{"tracing":{"enable":true}}}}' --type=merge
spec.sidecar.enablePrivilegedInitContainer booleano false kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"enablePrivilegedInitContainer":true}}}' --type=merge
spec.sidecar.logLevel cadeia de caracteres "error" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"sidecar":{"logLevel":"error"}}}' --type=merge
spec.featureFlags.enableWASMStats booleano "true" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableWASMStats":"true"}}}' --type=merge
spec.featureFlags.enableEgressPolicy booleano "true" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEgressPolicy":"true"}}}' --type=merge
spec.featureFlags.enableMulticlusterMode booleano "false" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableMulticlusterMode":"false"}}}' --type=merge
spec.featureFlags.enableSnapshotCacheMode booleano "false" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableSnapshotCacheMode":"false"}}}' --type=merge
spec.featureFlags.enableAsyncProxyServiceMapping booleano "false" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableAsyncProxyServiceMapping":"false"}}}' --type=merge
spec.featureFlags.enableIngressBackendPolicy booleano "true" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableIngressBackendPolicy":"true"}}}' --type=merge
spec.featureFlags.enableEnvoyActiveHealthChecks booleano "false" kubectl patch meshconfig osm-mesh-config -n arc-osm-system -p '{"spec":{"featureFlags":{"enableEnvoyActiveHealthChecks":"false"}}}' --type=merge

Verificar Namespaces

Nota

O arc-osm-system namespace nunca participa de uma malha de serviço e nunca é rotulado ou anotado com os pares chave/valor mostrados aqui.

Você pode usar o osm namespace add comando para unir namespaces a uma malha de serviço específica. Quando um namespace Kubernetes fizer parte da malha, conclua as etapas a seguir para confirmar se os requisitos foram atendidos.

Veja as anotações do bookbuyer namespace:

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

Deve estar presente a seguinte anotação:

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

Exiba os rótulos do bookbuyer namespace:

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

Deve estar presente o seguinte rótulo:

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

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

Nota

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

Verificar os CRDs SMI

Para o OSM Service Mesh Interface (SMI), verifique se o cluster tem as definições de recursos personalizados (CRDs) necessárias:

kubectl get crds

Certifique-se de que os CRDs correspondam às versões disponíveis no ramo de lançamento. Para confirmar quais versões do CRD estão em uso, consulte as versões suportadas pelo SMI e selecione a sua versão no menu Releases.

Obtenha as versões dos CRDs instalados usando 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

Caso os CRDs estiverem em falta, use as seguintes comandos para instalá-los no cluster. Substitua a versão nesses comandos conforme necessário (por exemplo, em vez de v1.1.0, você pode usar 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

Para ver como as versões do CRD mudam entre as versões, consulte as notas de versão do OSM.

Solucionar problemas de gerenciamento de certificados

Para obter informações sobre como o OSM emite e gerencia certificados para proxies do Envoy em execução em pods de aplicativos, consulte a documentação do OSM.

Atualizar Envoy

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

Conteúdos relacionados