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

Artigo
01/09/2025

Este artigo descreve dicas de solução de problemas para 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, confira Solucionar problemas do Kubernetes habilitado para Azure Arc.

GitOps (Flux v2)

Observação

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

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

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

Erros de simulação de webhook

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

Para obter mais informações, confira Como fazer para resolver os erros de "webhook não dá suporte a execução de teste"?

Erros ao instalar a extensão microsoft.flux

A extensão microsoft.flux instala controladores Flux e agentes do GitOps do Azure em um cluster do Kubernetes habilitado para Azure Arc ou em um cluster do Serviço de Kubernetes do Azure (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 estado Failed, verifique se o cluster não tem políticas que restrinjam a criação do namespace flux-system ou de qualquer um dos recursos nesse namespace.

Para um cluster do AKS, verifique se o sinalizador de recurso Microsoft.ContainerService/AKS-ExtensionManager 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 como managedClusters para um cluster do AKS. Se a extensão foi instalada automaticamente quando você criou a configuração do GitOps, o nome da extensão microsoft.flux será flux.

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

A saída pode ajudar a identificar o problema 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>.
Desinstale a versão do Helm executando helm uninstall flux -n flux-system.
Exclua o namespace flux-system do cluster executando kubectl delete namespaces flux-system.

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

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

Se você tentar instalar a extensão Flux em um cluster que tenha uma identidade gerenciada de pod do Microsoft Entra, poderá ocorrer um erro no pod extension-agent. A saída será parecida com 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 pod extension-agent tenta obter seu token do Serviço de Metadados de Instância do Azure no cluster, mas a solicitação de token é interceptada pela identidade do pod. Para corrigir esse problema, faça upgrade para a versão mais recente da extensão microsoft.flux.

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

Os controladores que são instalados no cluster do Kubernetes quando você instala a extensão microsoft.flux devem ter recursos de CPU e memória suficientes para agendar adequadamente em um nó de cluster do Kubernetes. Verifique se o cluster atende aos requisitos mínimos de memória e CPU.

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

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

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

Flux v1

Observação

Recomendamos que você faça a migração para o Flux v2 o mais rápido possível. O suporte para recursos de configuração de cluster baseados no Flux v1 que foram criados antes de 1º de janeiro de 2024 termina 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 resolver problemas com o recurso sourceControlConfigurations no Flux v1, execute estes comandos da CLI do Azure, incluindo o parâmetro --debug:

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

Insights de Contêiner do Azure Monitor

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

Habilitar o modo privilegiado para um cluster Canonical Charmed Kubernetes

Os Insights de Contêiner do Azure Monitor exigem que seu DaemonSet do Kubernetes 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 pods do AMA no Oracle Linux 9.x

Se você tentar instalar o Agente do Azure Monitor (AMA) em um cluster do Kubernetes do Oracle Linux (Red Hat Enterprise Linux (RHEL)) 9.x, os pods do AMA e o pod AMA-RS poderão não funcionar corretamente devido ao contêiner addon-token-adapter no pod. Ao verificar os logs do pod ama-logs-rs, em addon-token-adapter container, você verá uma saída semelhante ao exemplo a seguir:

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ó do cluster. Use 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 demonstra comandos que você pode usar para validar e solucionar problemas de implantação de componentes da extensão Malha de Serviços 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 OSM estiver íntegro, será exibida uma saída semelhante ao exemplo a seguir:

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 status Evicted em um ponto, outro controlador terá o status READY 1/1 e Running com 0 reinicializações. Se o status READY for diferente de 1/1, a malha de serviços estará em um estado interrompido. Se READY for 0/1, o contêiner do painel de controle estará falhando.

Use o seguinte comando para inspecionar logs do controlador:

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

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

Verificar 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, será exibida uma saída semelhante ao exemplo a seguir:

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 valor real de CLUSTER-IP será diferente desse exemplo. Os valores de NAME e PORT(S) devem corresponder ao mostrado nesse exemplo.

Verificar pontos de extremidade do controlador OSM

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

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

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

Se o cluster não tiver ENDPOINTS com o valor osm-controller, o painel de controle não está í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 OSM

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

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

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

Verificar o pod do injetor OSM

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

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

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

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

Verificar o serviço do injetor OSM

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

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

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 valor listado para EXTERNAL-IP.

Verificar pontos de extremidade do injetor osM

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

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

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.

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

Verifique o webhook Validação executando o seguinte comando:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Se o webhook Validação estiver íntegro, uma saída semelhante ao exemplo a seguir será exibida:

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

Verifique o webhook Mutação executando o seguinte comando:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Se o webhook Mutação estiver íntegro, 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 AC) do webhook Validação usando este comando:

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

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

{
  "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 Mutação 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 forneceu um pacote de AC ao webhook 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

Exemplo de saída:

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, for 0 ou um número inferior a 1.000, o pacote de AC não estará provisionado corretamente. Sem um pacote de AC 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 meshconfig do OSM:

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 os valores de recurso osm-mesh-config:

Chave	Type	Valor padrão	Exemplos de comando de patch do 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`	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`	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 participa de uma malha de serviço e nunca é rotulado ou anotado com os pares de chave/valor mostrados aqui.

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

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

Exibir 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, poderá adicionar essas anotações manualmente aos seus namespaces. Se um namespace não estiver anotado com "openservicemesh.io/sidecar-injection": "enabled" ou não estiver rotulado com "openservicemesh.io/monitored-by": "osm", o injetor OSM não adicionará sidecars Envoy.

Observação

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

Verificar os CRDs do SMI

Para a Interface de Malha de Serviço (SMI) OSM, verifique se o cluster tem as definições de recurso personalizadas (CRDs) necessárias:

kubectl get crds

Verifique se os CRDs correspondem às versões disponíveis na ramificação de liberação. Para confirmar quais versões de CRD estão em uso, confira versões SMI com suporte e selecione sua versão no menu Versões.

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

Se os CRDs forem ignorados, use os comandos a seguir para instalá-los no cluster. Substitua a versão nestes 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 são alteradas entre as versões, confira as notas sobre a versão do OSM.

Solucionar problemas de gerenciamento de certificados

Para obter informações sobre como o OSM emite e gerencia certificados para proxies Envoy em execução em pods de aplicativo, confira a 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 Envoy nesse pod. Se a versão do Envoy precisar ser atualizada, siga as etapas no Guia de Atualização na documentação do OSM.

Saiba mais sobre extensões de cluster.
Exibir dicas gerais de solução de problemas para clusters Kubernetes habilitados para Arc.

Compartilhar via

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

GitOps (Flux v2)

Erros de simulação de webhook

Erros ao instalar a extensão microsoft.flux

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

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

Flux v1

Insights de Contêiner do Azure Monitor

Habilitar o modo privilegiado para um cluster Canonical Charmed Kubernetes

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

Open Service Mesh habilitado para o Azure Arc

Verificar a implantação do controlador OSM

Verificar pods do controlador OSM

Verificar o serviço do controlador OSM

Verificar pontos de extremidade do controlador OSM

Verificar a implantação do injetor OSM

Verificar o pod do injetor OSM

Verificar o serviço do injetor OSM

Verificar pontos de extremidade do injetor osM

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

Verifique o recurso `osm-mesh-config`

Verificar namespaces

Verificar os CRDs do SMI

Solucionar problemas de gerenciamento de certificados

Atualizar o Envoy

Comentários

Recursos adicionais

Compartilhar via

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

GitOps (Flux v2)

Erros de simulação de webhook

Erros ao instalar a extensão microsoft.flux

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

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

Flux v1

Insights de Contêiner do Azure Monitor

Habilitar o modo privilegiado para um cluster Canonical Charmed Kubernetes

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

Open Service Mesh habilitado para o Azure Arc

Verificar a implantação do controlador OSM

Verificar pods do controlador OSM

Verificar o serviço do controlador OSM

Verificar pontos de extremidade do controlador OSM

Verificar a implantação do injetor OSM

Verificar o pod do injetor OSM

Verificar o serviço do injetor OSM

Verificar pontos de extremidade do injetor osM

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

Verifique o recurso osm-mesh-config

Verificar namespaces

Verificar os CRDs do SMI

Solucionar problemas de gerenciamento de certificados

Atualizar o Envoy

Conteúdo relacionado

Comentários

Recursos adicionais

Verifique o recurso `osm-mesh-config`