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

Artigo
11/05/2024

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 na solução de problemas gerais com o Kubernetes habilitado para Azure Arc, consulte Solucionar problemas do Kubernetes habilitado para Azure Arc.

GitOps (Fluxo v2)

Nota

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

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

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

Erros de Webhook/execução seca

Se vir que o Flux não consegue reconciliar-se com um erro como dry-run failed, error: admission webhook "<webhook>" does not support dry runo , pode resolver o problema localizando o ValidatingWebhookConfiguration ou o MutatingWebhookConfiguration e definindo o sideEffects para None ou NoneOnDryRun:

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

Erros ao instalar a `microsoft.flux` extensão

A microsoft.flux extensão instala os controladores Flux e os agentes do Azure GitOps em seus clusters Kubernetes habilitados para Azure Arc ou 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 esse cluster, a extensão será instalada automaticamente.

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

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

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) para connectedClusters um cluster habilitado para Arc ou managedClusters para um cluster AKS. O nome da microsoft.flux extensão é "flux" se a extensão foi 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 reparaçã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 Helm executando helm uninstall flux -n flux-system
Excluir o flux-system namespace do cluster executando kubectl delete namespaces flux-system

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

Erros ao instalar a extensão em um cluster com o `microsoft.flux` Microsoft Entra Pod Identity habilitado

Se tentar instalar a extensão do Flux num cluster com a Identidade do Pod do Microsoft Entra ativada, poderá ocorrer um erro no pod do agente da 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 extension-agent tenta obter seu token do IMDS 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.

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

Com clusters AKs, uma das opções de autenticação é a identidade kubelet usando uma identidade gerenciada atribuída pelo usuário. Usar a identidade kubelet pode reduzir a sobrecarga operacional e aumentar 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` a instalação da extensão sejam atendidos

Os controladores instalados no cluster do Kubernetes com a microsoft.flux extensão exigem recursos de CPU e memória para agendar corretamente nos nós do cluster Kubernetes. Certifique-se de que seu 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 Contentor	CPU mínima	Mínimo de memória	CPU máxima	Máximo de memória
fluxconfig-agente	5 metros	30 mi	50 metros	150 Mi
fluxconfig-controlador	5 metros	30 mi	100 metros	150 Mi
fluente-bit	5 metros	30 mi	20 metros	150 Mi
controlador-leme	100 metros	64 Mi	1000 metros	1 Gi
controlador-fonte	50 metros	64 Mi	1000 metros	1 Gi
kustomize-controlador	100 metros	64 Mi	1000 metros	1 Gi
Controlador-Notificação	100 metros	64 Mi	1000 metros	1 Gi
controlador-automação de imagem	100 metros	64 Mi	1000 metros	1 Gi
imagem-refletor-controlador	100 metros	64 Mi	1000 metros	1 Gi

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

Fluxo v1

Nota

Recomendamos migrar para o Flux v2 o mais rápido possível. O suporte para recursos de configuração de cluster baseados no 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 no Flux v1, execute estes comandos da CLI do Azure com --debug o sourceControlConfigurations parâmetro especificado:

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

Azure Monitor Container Insights

Esta seção fornece ajuda para solucionar problemas com o Azure Monitor Container Insights para clusters Kubernetes habilitados para Azure Arc.

Ativando o modo privilegiado para o cluster Kubernetes Canonical Charmed

O Azure Monitor Container Insights requer que seu 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 o Azure Monitor Agent (AMA) no Oracle Linux 9.x

Ao tentar instalar o Azure Monitor Agent (AMA) em um cluster Kubernetes Oracle Linux (RHEL) 9.x, os pods AMA e o pod AMA-RS podem não funcionar corretamente devido ao addon-token-adapter contêiner no pod. Com esse erro, ao verificar os logs do ama-logs-rs pod, addon-token-adapter containervocê 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.

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ó do cluster, usando 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 fornece comandos que você pode usar para validar e solucionar problemas de implantação dos componentes de extensão Open Service Mesh (OSM) 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, 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 despejado em algum momento, há outro que está READY 1/1 e Running com 0 reinícios. Se a coluna READY for diferente de 1/1, a malha de serviço está em um estado quebrado. Coluna READY com 0/1 indica que 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

Coluna READY com um número maior do que 1 após o / indica que há sidecars instalados. O controlador OSM geralmente não funciona corretamente com sidecars conectados.

Verifique o serviço do controlador OSM

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

Se o controlador 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

Nota

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

Verifique os pontos finais do controlador OSM

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

Se o controlador 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 ENDPOINTS tiver para 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, você verá uma saída semelhante a:

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, você verá uma saída semelhante a:

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

A READY coluna 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, 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 osm-injector o serviço é 9090. Não deve haver EXTERNAL-IP.

Verifique os pontos finais do injetor OSM

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

Se o injetor 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 seus pontos de extremidade do injetor OSM varia, mas a porta 9090 deve ser a mesma.

Verifique a validação e mutação de webhooks

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Se o webhook Validando 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 Mutating 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 autoridade de certificação do webhook Validando usando este comando:

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

Uma configuração de webhook de validação bem configurada terá uma saída semelhante a:

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

Uma configuração de webhook mutante bem configurada terá uma saída semelhante a:

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

Verifique se o OSM Controller deu ao webhook Validating (ou Mutating) um CA Bundle 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 CA Bundle. Se a saída estiver vazia, 0 ou um número abaixo de 1000, o CA Bundle não será provisionado corretamente. Sem um CA Bundle correto, o 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 conteúdo do OSM MeshConfig:

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

Deverá ver um resultado 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: ""

osm-mesh-config Valores dos recursos:

Chave	Type	Valor Predefinido	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.logNível	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 namespace arc-osm-system nunca participará de uma malha de serviço e nunca será rotulado ou anotado com a chave/valores mostrados aqui.

Usamos o osm namespace add comando para unir namespaces a uma determinada malha de serviço. Quando um namespace Kubernetes fizer parte da malha, siga estas etapas para confirmar se os requisitos foram atendidos.

Veja as anotações do namespace bookbuyer:

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

Deve estar presente a seguinte anotação:

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

Exibir os rótulos do namespace bookbuyer:

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 osm a CLI, também poderá adicionar manualmente essas anotações 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 do Envoy.

Nota

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

Verificar os CRDs SMI

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

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, visite a página de versões suportadas pelo 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 CRDs estiverem faltando, use os seguintes comandos 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

Para ver as alterações de CRD entre 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 o site de documentos 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 no site de documentos do OSM.

Próximos passos

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 Webhook/execução seca

Erros ao instalar a `microsoft.flux` extensão

Erros ao instalar a extensão em um cluster com o `microsoft.flux` Microsoft Entra Pod Identity habilitado

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

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

Fluxo v1

Azure Monitor Container Insights

Ativando o modo privilegiado para o cluster Kubernetes Canonical Charmed

Não é possível instalar o Azure Monitor Agent (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 a validação e mutação de webhooks

Verifique o `osm-mesh-config` recurso

Verificar namespaces

Verificar os CRDs SMI

Solucionar problemas de gerenciamento de certificados

Enviado de atualização

Próximos passos

Comentários

Recursos adicionais

Partilhar via

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

GitOps (Fluxo v2)

Erros de Webhook/execução seca

Erros ao instalar a microsoft.flux extensão

Erros ao instalar a extensão em um cluster com o microsoft.flux Microsoft Entra Pod Identity habilitado

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

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

Fluxo v1

Azure Monitor Container Insights

Ativando o modo privilegiado para o cluster Kubernetes Canonical Charmed

Não é possível instalar o Azure Monitor Agent (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 a validação e mutação de webhooks

Verifique o osm-mesh-config recurso

Verificar namespaces

Verificar os CRDs SMI

Solucionar problemas de gerenciamento de certificados

Enviado de atualização

Próximos passos

Comentários

Recursos adicionais

Erros ao instalar a `microsoft.flux` extensão

Erros ao instalar a extensão em um cluster com o `microsoft.flux` Microsoft Entra Pod Identity habilitado

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

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

Verifique o `osm-mesh-config` recurso