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 executandokubectl 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
- Saiba mais sobre extensões de cluster.
- Exibir dicas gerais de solução de problemas para clusters Kubernetes habilitados para Arc.