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

Artigo
01/09/2025

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 de solução de problemas 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

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 GitOps do Azure em um cluster Kubernetes habilitado para Azure Arc ou cluster do Serviço 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 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 Para 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 versão Helm executando helm uninstall flux -n flux-systemo .
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 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 instalados no cluster do Kubernetes quando você instala a microsoft.flux extensão devem ter recursos suficientes de CPU e memória para agendar corretamente em um nó de cluster do 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 contentor	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 Gi
`source-controller`	50 metros	64 Mi	1.000 metros	1 Gi
`kustomize-controller`	100 metros	64 Mi	1.000 metros	1 Gi
`notification-controller`	100 metros	64 Mi	1.000 metros	1 Gi
`image-automation-controller`	100 metros	64 Mi	1.000 metros	1 Gi
`image-reflector-controller`	100 metros	64 Mi	1.000 metros	1 Gi

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

Fluxo v1

Nota

Recomendamos que você migre 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 solucionar problemas com o sourceControlConfigurations recurso no Flux v1, execute estes comandos da CLI do Azure, incluindo o --debug parâmetro:

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

Azure Monitor Container Insights

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

Habilitar o modo privilegiado para um cluster Kubernetes Canônico Encantado

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. Quando você verifica os ama-logs-rs logs do pod, no addon-token-adapter container, você vê 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.

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 manualmente o iptable_nat módulo, tente novamente a instalação do AMA.

Nota

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

Azure Arc-enabled Open Service Mesh

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 em um ponto, outro controlador tem o READY status 1/1 e Running com 0 reinicializações. Se o READY status for diferente de 1/1, a malha de serviço está em um estado quebrado. Se READY for 0/1, o contêiner do avião de controle está caindo.

Use o seguinte comando para inspecionar os logs do controlador:

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

Se o READY status 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 sidecars são conectados.

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 o valor osm-controller, o plano de controle não estará íntegro. Esse estado não íntegro significa que o pod do controlador travou 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, a saída semelhante ao exemplo a seguir será exibida:

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

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 íntegro.

Verifique o serviço de injetor OSM

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

Se o injetor OSM estiver íntegro, a 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

Certifique-se de que o endereço IP listado para osm-injector 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, a 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 9090 da porta deve ser o mesmo.

Verifique webhooks: Validando e Mutando

Verifique o webhook Validando 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 íntegro, a 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:

O número na saída indica o número de bytes ou o tamanho do pacote de autoridade de certificação. Se a saída estiver vazia, 0 ou um número inferior a 1.000, o pacote de autoridade de certificação não será provisionado corretamente. Sem um pacote de autoridade de certificação correto, ValidatingWebhook gera um erro.

Verifique o `osm-mesh-config` recurso

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	Type	Default value	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`	string	`"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`	string	`"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`	string	`"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 adicionará sidecars Envoy.

Nota

Depois osm namespace add é chamado, apenas novos pods são injetados com um sidecar Envoy. 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 na ramificação de versão. Para confirmar quais versões do CRD estão em uso, consulte Versões suportadas pelo SMI 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 CRDs estiverem faltando, use os 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.

Enviado de atualização

Quando um novo pod é criado em um namespace monitorado pelo complemento, o OSM injeta um sidecar 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.
Veja dicas gerais de solução de problemas para clusters Kubernetes habilitados para Arc.

Partilhar via

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

GitOps (Fluxo v2)

Erros de execução seca do 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 por pod do Microsoft Entra

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

Fluxo v1

Azure Monitor Container Insights

Habilitar o modo privilegiado para um cluster Kubernetes Canônico Encantado

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

Azure Arc-enabled Open Service Mesh

Verifique a implantação do controlador OSM

Verifique os pods do controlador OSM

Verifique o serviço do controlador OSM

Verifique os pontos finais do controlador OSM

Verifique a implantação do injetor OSM

Verifique o pod do injetor OSM

Verifique o serviço de injetor OSM

Verifique os pontos finais do injetor OSM

Verifique webhooks: Validando e Mutando

Verifique o `osm-mesh-config` recurso

Verificar namespaces

Verificar os CRDs SMI

Solucionar problemas de gerenciamento de certificados

Enviado de atualização

Comentários

Recursos adicionais

Partilhar via

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

GitOps (Fluxo v2)

Erros de execução seca do 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 por pod do Microsoft Entra

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

Fluxo v1

Azure Monitor Container Insights

Habilitar o modo privilegiado para um cluster Kubernetes Canônico Encantado

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

Azure Arc-enabled Open Service Mesh

Verifique a implantação do controlador OSM

Verifique os pods do controlador OSM

Verifique o serviço do controlador OSM

Verifique os pontos finais do controlador OSM

Verifique a implantação do injetor OSM

Verifique o pod do injetor OSM

Verifique o serviço de injetor OSM

Verifique os pontos finais do injetor OSM

Verifique webhooks: Validando e Mutando

Verifique o osm-mesh-config recurso

Verificar namespaces

Verificar os CRDs SMI

Solucionar problemas de gerenciamento de certificados

Enviado de atualização

Conteúdos relacionados

Comentários

Recursos adicionais

Verifique o `osm-mesh-config` recurso