Para informações sobre a versão, consulte as notas da versão conectada do Distributed Cloud.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Resolver problemas do Distributed Cloud conectado

O Google monitora e mantém remotamente as implantações do Google Distributed Cloud conectado. Para isso, os engenheiros do Google têm acesso ao Secure Shell (SSH) ao hardware do Distributed Cloud conectado. Se o Google detectar um problema, um engenheiro do Google entrará em contato com você para resolver problemas e solucioná-lo. Se você identificar um problema, entre em contato com o Suporte do Google imediatamente para diagnosticar e resolver.

Upgrades de software do Distributed Cloud conectado

Nesta seção, descrevemos como usar o Metrics Explorer para verificar se um cluster conectado do Distributed Cloud está passando por um upgrade de software.

Esse procedimento usa as seguintes métricas do Monitoring:

Versão atual do cluster (/edge_cluster/current_cluster_version): indica a versão atual do software do Distributed Cloud conectado em execução no cluster.
Versão do cluster de destino (/edge_cluster/target_cluster_version): indica a versão de destino do Distributed Cloud conectado para a qual o cluster está fazendo upgrade.

Para concluir as etapas desta seção, você precisa atender aos seguintes pré-requisitos:

Acesso ao console do Google Cloud e ao projeto do Distributed Cloud conectado ao Google Cloud .
O papel do IAM de Leitor do Monitoring, que permite visualizar as métricas do Monitoring.
(Opcional) O valor machine_id da máquina conectada do Distributed Cloud de destino para filtrar os resultados retornados.

Usar o Metrics Explorer para verificar as versões atual e de destino do software do cluster

Acesse o Metrics Explorer:
1. No console do Google Cloud , acesse a seção Monitoring.
2. Na árvore de navegação à esquerda, clique em Metrics Explorer.
Selecione o tipo de recurso de destino:
1. Na página do Metrics Explorer, acesse a página Configuração.
2. Clique em Selecionar uma métrica.
3. Use a barra de pesquisa para procurar o tipo de recurso Cluster. Também é possível usar o identificador de recurso completo edgecontainer.googleapis.com/Cluster.
4. Nos resultados retornados, clique no tipo de recurso Cluster.
Obtenha a versão do software atual do cluster:
1. Na seção Métrica, pesquise o valor current_cluster_version.
2. Selecione a métrica Tempo de atividade da máquina. O caminho completo é edgecontainer.googleapis.com/edge_cluster/current_cluster_version.
3. (Opcional) Filtre pelo valor de destino machine_id usando a seção Filtro.
Consiga a versão do software de destino do cluster:
1. Clique em Adicionar consulta.
2. Na seção Métrica, pesquise o valor target_cluster_version.
3. Selecione a métrica Versão do cluster de destino. O caminho completo é edgecontainer.googleapis.com/edge_cluster/target_cluster_version.
4. (Opcional) Filtre pelo valor de machine_id de destino usando a seção Filtro.
Verifique o status do upgrade de software do cluster no gráfico que aparece.
- Se as linhas Versão atual do cluster e Versão de destino do cluster indicarem valores diferentes, o cluster está passando por um upgrade de software.
- Se as linhas Versão atual do cluster e Versão de destino do cluster indicarem o mesmo valor, o cluster não está passando por um upgrade de software.
Verifique o resultado da etapa anterior usando o seguinte comando:
```
gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION
```
Substitua:
- CLUSTER_ID: o ID do cluster de destino.
- REGION: a região do Google Cloud em que o cluster foi criado.
Na saída do comando, observe os valores dos seguintes campos:
- Se o valor do campo status for UPDATING, o cluster está passando por um upgrade de software.
- Se os valores dos campos clusterVersion e targetVersion forem diferentes, compare-os com os valores retornados pelo Metrics Explorer.

Entenda os resultados

A tabela a seguir explica os resultados retornados pelo Metrics Explorer e pelo comando gcloud.

Estado do cluster	Diagnóstico	Resolução
Íntegro Os valores `currentVersion` e `targetVersion` correspondem O valor de `status` é `RUNNING`	O cluster está executando a versão de destino do software do Distributed Cloud conectado.	Nenhuma.
Fazendo upgrade O valor de `currentVersion` é menor que `targetVersion` O valor de `status` é `UPDATING`	O cluster está sendo atualizado para a versão de destino do software conectado do Distributed Cloud.	Monitore o cluster no Metrics Explorer até que os valores da versão atual e de destino do cluster sejam iguais.
Travado O valor de `currentVersion` é menor que `targetVersion` indefinidamente O valor de `status` é `UPDATING` indefinidamente	O upgrade para a versão de destino do software conectado do Distributed Cloud falhou em pelo menos um nó no cluster.	Verifique a conectividade da máquina e os registros do sistema. Entre em contato com o Google para receber ajuda.
Reversão O valor de `currentVersion` é maior que `targetVersion` O valor de `status` é `UPDATING`	O cluster está sendo revertido para uma versão anterior do software do Distributed Cloud conectado.	Entre em contato com o Google para identificar o motivo da reversão.

Se o upgrade do software no cluster falhar ou se o cluster tiver sido revertido para uma versão anterior do software, verifique o seguinte:

Integridade do nó. Verifique se cada máquina física do Distributed Cloud conectada tem conectividade de rede e está informando o tempo de atividade, conforme descrito na próxima seção.
Janelas de manutenção. Verifique se o upgrade de software foi pausado devido a uma janela de exclusão de manutenção.
Registros do sistema. Examine os registros do sistema para identificar possíveis motivos para a falha no upgrade do software, como tempos limite de remoção de pods.

Se as etapas de resolução listadas na tabela não resolverem o problema, entre em contato com o Suporte do Google com o valor machine_id da máquina afetada e o carimbo de data/hora da interrupção.

Reinicializações de máquinas conectadas do Distributed Cloud

Nesta seção, descrevemos como usar o Metrics Explorer para verificar se uma máquina física conectada ao Distributed Cloud foi reiniciada e determinar o motivo da reinicialização. O monitoramento de reinicializações ajuda a determinar se elas fizeram parte de uma manutenção planejada ou se foram resultado de uma falha de hardware ou interrupção de energia.

Esse procedimento usa as seguintes métricas do Monitoring:

Tempo de atividade da máquina (/machine/uptime): indica o tempo, em segundos, desde a última reinicialização.
Reinicializações da máquina (/machine/restart_count): indica o número total de reinicializações da máquina de destino desde a implantação.

Para concluir as etapas desta seção, você precisa atender aos seguintes pré-requisitos:

Acesso ao console do Google Cloud e ao projeto do Distributed Cloud conectado ao Google Cloud .
O papel do IAM de Leitor do Monitoring, que permite visualizar as métricas do Monitoring.
(Opcional) O valor machine_id da máquina conectada do Distributed Cloud de destino para filtrar os resultados retornados.

Usar o Metrics Explorer para verificar o tempo de atividade da máquina e a contagem de reinicializações

Acesse o Metrics Explorer:
1. No console do Google Cloud , acesse a seção Monitoring.
2. Na árvore de navegação à esquerda, clique em Metrics Explorer.
Selecione o tipo de recurso de destino:
1. Na página do Metrics Explorer, acesse a página Configuração.
2. Clique em Selecionar uma métrica.
3. Use a barra de pesquisa para procurar o tipo de recurso Máquina. Também é possível usar o identificador de recurso completo edgecontainer.googleapis.com/Machine.
4. Nos resultados retornados, clique no tipo de recurso Máquina.
Verifique o tempo de atividade da máquina:
1. Na seção Métrica, pesquise o valor uptime.
2. Selecione a métrica Tempo de atividade da máquina. O caminho completo é edgecontainer.googleapis.com/machine/uptime.
3. (Opcional) Filtre pelo valor de machine_id de destino usando a seção Filtro.
4. No gráfico de tempo que aparece, verifique se o gráfico de tempo de atividade está aumentando continuamente. Se, em algum momento, o valor do tempo de atividade cair para zero e reiniciar, isso indica que a máquina foi reiniciada.
Verifique a contagem de reinicializações da máquina:
1. Na seção Métrica, pesquise o valor restart_count.
2. Selecione a métrica Reinicializações da máquina. O caminho completo é edgecontainer.googleapis.com/machine/restart_count.
3. (Opcional) Filtre pelo valor de machine_id de destino usando a seção Filtro.
4. No gráfico de tempo que aparece, verifique se a linha do gráfico permanece em 0, o que indica que não houve reinicializações. Se em algum momento a linha atingir 1, isso indica que a máquina foi reiniciada. Anote o carimbo de data/hora exato da reinicialização para solucionar outros problemas.
5. (Opcional) Para ver eventos individuais em vez de um gráfico, navegue até a seção Agregação da página, defina o campo Período de alinhamento como 1 minute e o campo Alinhador por série como Delta.

Entenda os resultados

A tabela a seguir explica os resultados retornados pelo Metrics Explorer.

Estado da máquina	Diagnóstico	Resolução
Estável A métrica "Tempo de atividade da máquina" aumenta de forma constante O delta da métrica "Reinicializações da máquina" é `0`	A máquina não foi reiniciada.	Nenhuma.
Reinicialização limpa A métrica "Tempo de atividade da máquina" cai para `0` A métrica "Reinicializações da máquina" aumenta para `1`	A máquina foi reiniciada e reconectada ao Google Cloud.	Verifique os registros do sistema para determinar o motivo da reinicialização.
Falha de energia O gráfico da métrica "Tempo de atividade da máquina" tem uma interrupção sem dados A métrica "Reinicializações da máquina" não mudou durante a interrupção no tempo de atividade da máquina	A máquina perdeu energia ou conectividade de rede antes de reiniciar.	Verifique os cabos de energia e de rede, a configuração da rede local e o status do indicador de LED.
Intermitente O valor da métrica "Máquina conectada" alterna entre `0` e `1` O valor da métrica "Conectividade de rede" alterna entre `0` e `1`	Conexão de rede instável, perda de pacotes ou latência excessiva.	Verifique se há congestionamento e hardware com defeito na rede local.

Conectividade de máquina do Distributed Cloud conectado

Nesta seção, descrevemos como verificar a conectividade com a Internet e o Google Cloud das máquinas conectadas do Distributed Cloud usando o recurso Metrics Explorer do Cloud Monitoring.

Esse procedimento usa as seguintes métricas do Monitoring:

Máquina conectada (/machine/connected): indica se a máquina está conectada ao Google Cloud.
Conectividade de rede (/machine/network/connectivity): indica se a interface de rede principal da máquina tem conexão de internet.

Para concluir as etapas desta seção, você precisa atender aos seguintes pré-requisitos:

Acesso ao console do Google Cloud e ao projeto do Distributed Cloud conectado ao Google Cloud .
O papel do IAM de Leitor do Monitoring, que permite visualizar as métricas do Monitoring.
(Opcional) O valor machine_id da máquina conectada do Distributed Cloud de destino para filtrar os resultados retornados.

Usar o Metrics Explorer para verificar a conectividade da máquina

Acesse o Metrics Explorer:
1. No console do Google Cloud , acesse a seção Monitoring.
2. Na árvore de navegação à esquerda, clique em Metrics Explorer.
Selecione o tipo de recurso de destino:
1. Na página do Metrics Explorer, acesse a página Consultas.
2. Use a barra de pesquisa para procurar o tipo de recurso Máquina. Também é possível usar o identificador de recurso completo edgecontainer.googleapis.com/Machine.
3. Nos resultados retornados, clique no tipo de recurso Máquina.
Verifique a conexão da máquina com Google Cloud:
1. Na seção Métrica, pesquise o valor connected.
2. Selecione a métrica Máquina conectada. O caminho completo é edgecontainer.googleapis.com/machine/connected.
3. (Opcional) Filtre pelo valor de machine_id de destino usando a seção Filtro.
4. No gráfico de tempo que aparece, verifique se a linha Íntegra permanece em 100% de forma contínua. Se, em algum momento, esse valor for 0% ou Não íntegro, a máquina terá perdido a conectividade com o Google Cloud no horário indicado.
Verifique a conectividade de Internet da máquina:
1. Na seção Métrica, pesquise o valor connectivity.
2. Selecione a métrica Conectividade de rede. O caminho completo é edgecontainer.googleapis.com/machine/network/connectivity.
3. (Opcional) Filtre pelo valor de machine_id de destino usando a seção Filtro.
4. No gráfico de tempo que aparece, verifique se a linha Íntegra permanece em 100% de forma contínua. Se, em algum momento, esse valor for 0% Não íntegro, a máquina perdeu a conexão de Internet no horário indicado.

Entenda os resultados

A tabela a seguir explica os resultados retornados pelo Metrics Explorer.

Estado da máquina	Diagnóstico	Resolução
Íntegro O valor da métrica "Máquina conectada" é `1` O valor da métrica "Conectividade de rede" é `1`	Operação normal.	Nenhuma.
Desconectado O valor da métrica "Máquina conectada" é `0` O valor da métrica "Conectividade de rede" é `1`	A máquina tem conectividade com a Internet, mas não consegue se conectar ao Google Cloud.	Verifique as regras de firewall para serviços do Google e endpoints de API. Verifique se os agentes conectados do Distributed Cloud estão em execução na máquina.
Isolado O valor da métrica "Máquina conectada" é `0` O valor da métrica "Conectividade de rede" é `0`	A máquina não tem conectividade com a Internet.	Verifique os cabos de energia e de rede, a configuração da rede local e o status do indicador de LED. Verifique a configuração de VLAN e roteamento.
Intermitente O valor da métrica "Máquina conectada" alterna entre `0` e `1` O valor da métrica "Conectividade de rede" alterna entre `0` e `1`	Conexão de rede instável, perda de pacotes ou latência excessiva.	Verifique se há congestionamento e hardware com defeito na rede local.

Se você notar valores sustentados de 0 para qualquer uma das métricas, siga as etapas de solução de problemas descritas na tabela para resolvê-los. Se o problema persistir, entre em contato com o Suporte do Google com o valor machine_id da máquina afetada e o carimbo de data/hora da interrupção.

Máquinas virtuais travadas no estado `Pending`

Uma carga de trabalho de máquina virtual pode ficar presa no estado Pending e não ser programada em um nó se uma das seguintes situações ocorrer:

O Distributed Cloud conectado não pode alocar os recursos solicitados, como tempo de CPU, memória ou espaço em disco, para a máquina virtual.
Há uma falha na configuração da máquina virtual.
Há uma falha no armazenamento da máquina virtual.
O nó de destino está corrompido.

Para resolver esse problema, faça o seguinte:

Consiga as credenciais do cluster conforme descrito em Conseguir credenciais para um cluster.

Receba informações sobre a máquina virtual afetada:

kubectl describe virtualmachine VM_NAME -n NAMESPACE

Substitua:

VM_NAME: o nome da máquina virtual de destino.
NAMESPACE: o namespace da máquina virtual de destino.

O comando retorna uma saída semelhante a esta:

Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

A saída do comando contém mensagens que podem indicar restrições de recursos, falhas de programação, falhas de armazenamento e outros problemas.

Analise a saída para determinar as causas da falha de programação, conforme explicado nas próximas seções.

Recursos insuficientes

Talvez você veja uma mensagem indicando recursos insuficientes, como CPU, memória ou espaço em disco. Exemplo:

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

Para corrigir esse problema, verifique os recursos alocados para as máquinas virtuais afetadas e outras cargas de trabalho programadas no nó. Em seguida, faça o seguinte, dependendo das suas necessidades de negócios:

Reduzir a escala vertical de outras cargas de trabalho programadas no nó,
Reduza a quantidade de recursos alocados para a máquina virtual afetada,
Adicione mais máquinas ao cluster afetado.

Nós com taint

Talvez apareça uma mensagem indicando que o nó de destino está com taint. Exemplo:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

Para resolver esse problema, faça o seguinte:

Use o seguinte comando para verificar se há taints no nó:

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

O comando retorna uma saída semelhante a esta:

NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

Escolha uma destas opções:
- Para taints inesperados, remova-os conforme descrito em Taints e tolerâncias.
- Para taints esperados, adicione as tolerâncias correspondentes à configuração da máquina virtual, conforme descrito em Taints e tolerâncias.

Falhas de armazenamento

Talvez apareça uma mensagem indicando uma falha no armazenamento da máquina virtual. Exemplo:

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

Essa mensagem pode indicar que o volume permanente correspondente não foi montado no nó de destino.

Para resolver esse problema, faça o seguinte:

Use o comando a seguir para conferir o status das declarações de volume persistente (PVCs, na sigla em inglês) no namespace da máquina virtual afetada:

kubectl get pvc -n NAMESPACE

Substitua NAMESPACE pelo nome do namespace de destino.

O comando retorna uma saída semelhante a esta:

NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

Verifique se o PVC correspondente tem o status Bound. Se o status for Pending, o subsistema de armazenamento não conseguiu provisionar o volume. Nesses casos, é preciso resolver problemas na configuração do subsistema de armazenamento e garantir que o StorageClass apropriado esteja disponível.

Bloqueios de programação causados por falhas nos webhooks de admissão

Os webhooks de admissão permitem interceptar solicitações para o servidor de API Kubernetes antes que o objeto se torne persistente. Embora sejam úteis para aplicar políticas de segurança personalizadas, webhooks mal configurados podem causar interrupções em todo o cluster, especialmente durante operações críticas, como upgrades de software e atualizações de certificados. Especificamente, um webhook de admissão bloqueado ou indisponível pode paralisar o plano de controle do Kubernetes, impedindo qualquer outra programação de carga de trabalho no cluster.

Deadlock do plano de controle

Um impasse de dependência circular pode ocorrer quando um webhook de admissão é responsável por validar recursos necessários para a própria recuperação do webhook. Por exemplo, se um webhook de admissão estiver configurado para validar pods e esse pod de webhook precisar ser reprogramado durante um upgrade de software de nó, o servidor de API Kubernetes poderá tentar entrar em contato com o webhook para autorizar a criação do novo pod. Se o webhook não estiver acessível, a solicitação vai falhar, o pod não será criado e o cluster vai entrar em um estado de deadlock em que nenhuma nova carga de trabalho poderá ser programada.

Quando um webhook é configurado com failurePolicy: Fail, qualquer erro de comunicação ou tempo limite entre o servidor de API e o webhook resulta na rejeição da solicitação de API. Isso causa os seguintes problemas:

Falha nos upgrades de software: não é possível programar componentes do sistema e VMs durante e após um upgrade de software de nó.
Não é possível iniciar os serviços do sistema: não é possível iniciar pods de infraestrutura, como o Symcloud Storage e o ambiente de execução de VM no GDC.
Nós travados no modo de manutenção: não é possível reconciliar ou sair dos nós no modo de manutenção porque o controlador está bloqueado pela lógica de admissão.

Práticas recomendadas de configuração de webhook

Siga as práticas recomendadas descritas nesta seção para evitar o deadlock do plano de controle descrito anteriormente. Essas práticas recomendadas se aplicam a todos os objetos ValidatingWebhookConfiguration e MutatingWebhookConfiguration.

Usar `failurePolicy: Ignore`

A menos que os requisitos de negócios determinem que uma solicitação de API precisa falhar se não puder ser validada, sempre defina o campo failurePolicy como Ignore. Isso garante que o servidor de API Kubernetes continue funcionando mesmo quando o serviço de webhook afetado estiver inativo, permitindo que os pods essenciais ao sistema sejam escalonados e recuperados.

Excluir namespaces reservados

Seus webhooks nunca podem interceptar solicitações de recursos em namespaces reservados. É necessário excluir esses namespaces da configuração do webhook usando o campo namespaceSelector. Consulte Restrições de namespace de gerenciamento para ver uma lista completa de namespaces reservados. Exemplo:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

Recuperar um cluster bloqueado por webhooks com falha

Se o cluster tiver sido bloqueado por webhooks com falha e os comandos kubectl para criar recursos expirarem ou retornarem erros, isso geralmente ocorre porque o webhook tem o failurePolicy definido como Fail. Siga as etapas nesta seção para recuperar o cluster do deadlock. Se o webhook com falha for um webhook de mutação, use mutatingwebhookconfiguration em vez de validatingwebhookconfiguration.

Identifique os webhooks com falha:
1. Liste os webhooks de validação implantados no cluster:
```
kubectl get validatingwebhookconfigurations
```
2. Liste os webhooks de mutação implantados no cluster:
```
kubectl get mutatingwebhookconfigurations
```
Verifique se os pods que dão suporte a esses webhooks estão em execução:
```
kubectl get pods -A | grep WEBHOOK_SERVICE
```
Substitua WEBHOOK_SERVICE pelo nome do serviço do webhook de destino.

Defina o failurePolicy do webhook com falha como Ignore:

kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

Substitua WEBHOOK_SERVICE pelo nome do serviço do webhook de destino.

(Opcional) Se a etapa anterior falhar, force a exclusão da configuração do webhook afetado:
```
kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s
```
Substitua WEBHOOK_CONFIG pelo nome da configuração do webhook de destino.

Depois de modificar ou forçar a exclusão da configuração do webhook, o servidor de API Kubernetes retoma o processamento de solicitações, resolvendo o impasse e permitindo que os processos bloqueados sejam concluídos.

Resolver problemas do Distributed Cloud conectado Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Upgrades de software do Distributed Cloud conectado

Usar o Metrics Explorer para verificar as versões atual e de destino do software do cluster

Entenda os resultados

Reinicializações de máquinas conectadas do Distributed Cloud

Usar o Metrics Explorer para verificar o tempo de atividade da máquina e a contagem de reinicializações

Entenda os resultados

Conectividade de máquina do Distributed Cloud conectado

Usar o Metrics Explorer para verificar a conectividade da máquina

Entenda os resultados

Máquinas virtuais travadas no estado Pending

Recursos insuficientes

Nós com taint

Falhas de armazenamento

Bloqueios de programação causados por falhas nos webhooks de admissão

Deadlock do plano de controle

Práticas recomendadas de configuração de webhook

Usar failurePolicy: Ignore

Excluir namespaces reservados

Recuperar um cluster bloqueado por webhooks com falha

Resolver problemas do Distributed Cloud conectado

Máquinas virtuais travadas no estado `Pending`

Usar `failurePolicy: Ignore`