Problemas de instalação do modo privado do Anthos

Nesta página, descrevemos como solucionar problemas que podem ser encontrados ao instalar ou fazer upgrade do modo privado do Anthos.

Pré-requisitos para a solução de problemas

O modo privado do Anthos requer um login em uma estação de trabalho de administrador para que você possa começar a resolver problemas. Para fazer login na estação de trabalho do administrador, execute o seguinte comando:

ssh <USERNAME>@<WORKSTATION>
cd ./anthos-baremetal-private-mode
export PATH=$PWD/bin:$PATH

Observação: o comando SSH exato pode variar de acordo com o ambiente.

Criar cluster

Nesta seção, explicamos como solucionar e resolver problemas ao criar clusters de modo privado do Anthos.

Falha na criação do cluster de administrador

Esta seção lista a configuração comum do cluster de administrador e erros de simulação e sugestões de como corrigi-los.

Erros de configuração

Problemas comuns de configuração do cluster de administrador incluem uma anotação ausente na configuração, nenhuma configuração de autenticação para o registro e um erro na criação do cluster de inicialização.

Anotação ausente na configuração

Se durante a criação dos recursos do pool de nós o arquivo de configuração não incluir uma anotação, você poderá ver o seguinte erro:

Cluster.baremetal.cluster.gke.io "admin" is invalid: [Spec.LoadBalancer.AddressPools: Forbidden: Field not allowed for admin clusters, Spec.GKEConnect: Required value: Field is required].

Para corrigir esse problema, adicione uma anotação ao arquivo de configuração do cluster de administrador e defina a anotação como true:

annotations:
    baremetal.cluster.gke.io/private-mode: "true"

Consulte Cluster de administrador e Pool de nós para ver um exemplo de anotação aplicada em um arquivo de configuração do cluster de administrador.

Configuração de autenticação ausente no registro

Se a configuração de autenticação não estiver definida, talvez você encontre o erro no auth config found for the registry.

Verifique se o pullCredentialConfigPath especificado no arquivo admin.yaml contém a configuração de autenticação para o endpoint. Por exemplo, se o endpoint for https://10.200.0.2 e pullCredentialConfigPath for /root/.docker/config.json, o arquivo config.json terá a seguinte entrada de autenticação:

{
        "auths": {
                "10.200.0.2": {
                        "auth": "<base64 encoded auth>"
                }
        }
}

Se a entrada de autenticação para o registro não estiver presente, atualize o arquivo config.json fazendo login no registro:

docker login <registry> -u <username> -p <password>

Erro ao criar o cluster de inicialização

Talvez você encontre o seguinte erro ao criar o cluster:

failed: error creating bootstrap cluster: failed to pull kind image kindest/node:v0.11.1-gke.7-v1.20.9-gke.101 from registry mirror(s)

Se você vir o erro de criação do cluster de inicialização, verifique se todas as imagens foram enviadas para o registro particular:

actl images push --private-registry=<registry>

Um comando de amostra tem a seguinte aparência:

actl images push --private-registry=10.200.0.2/library

Falhas de simulação

Quando você cria o cluster de administrador no modo particular do Anthos, pode ser necessário corrigir uma falha de criação do cluster com erros de simulação, a criação de um cluster travado ou uma solução de problemas gerais.

Falha na criação do cluster com erros de simulação

Se a verificação de simulação falhar, talvez você veja a seguinte mensagem de erro:

unable to create cluster: unable to create cluster: preflight check failed

O modo particular do Anthos coleta registros de erro correspondentes no diretório actl-workspace/admin/log/preflight-<timestamp>/, por exemplo, actl-workspace/admin/log/preflight-20210907-205726/.

Para resolver o problema, verifique o seguinte:

• todos os registros do nó com falha no arquivo nomeado como o endereço IP do nó;
• registros relacionados à rede no arquivo node-network.

Com base nos dados dos registros, verifique se há erros evidentes, como requisitos mínimos da máquina não atendidos ou portas conflitantes. Atualize as máquinas e tente novamente.

Criação de cluster travado

Se a criação do cluster demorar muito, por exemplo, mais de 30 minutos para um cluster de três nós, verifique o cluster de inicialização local para ver se há algum erro ao extrair a imagem:

kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -A

Se os pods tiverem o status ImagePullErr, verifique se essas imagens foram enviadas ao registro:

actl images push --private-registry=<registry>

Um comando de amostra tem a seguinte aparência:

actl images push --private-registry=10.200.0.2/library

Se um job de criação de cluster específico tiver um status Error, verifique os registros do pod correspondente:

kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -n cluster-admin
kubectl --kubeconfig actl-workspace/.kindkubeconfig logs <pod-name> -n cluster-admin

Revise os registros para ver se algum erro pode ser corrigido manualmente na máquina. É possível receber mais erros da própria máquina usando SSH para fazer login na máquina e executar journalctl --no-pager -l. Para garantir que serviços importantes estejam funcionando, execute o seguinte comando:

service containerd status
service kubelet status

journalctl -u containerd
journalctl -u kubelet

# If needed sudo systemctl restart <service> to fix issues.
# sudo service <service> restart
# e.g.,
# sudo service containerd restart

Problemas gerais

Para solucionar problemas de um nó em geral, use o SSH para se conectar a um nó e execute o seguinte comando:

journalctl --no-pager -l

Verifique se há erros nos registros.

Falha na criação do cluster

Use SSH para se conectar à máquina do plano de controle e ver os pods no cluster:

sudo kubectl --kubeconfig /etc/kubernetes/admin.conf get po -A

Problemas na rede

Nesta seção, explicamos os problemas mais comuns relacionados à rede no modo privado do Anthos e listamos as etapas de resolução.

• Para ver a conexão entre cada nó e verificar os erros relacionados à rede, use ip route.

• Quando o VIP do plano de controle não estiver acessível, use o SSH para se conectar a um nó do plano de controle e execute:

  journalctl -u containerd --no-pager -l
  # Check the logs of those pods as well.
  sudo kubectl --kubeconfig /etc/kubernetes/admin.conf -n kube-system get po | grep -E "haproxy|keepalived"
  sudo crictl logs `sudo crictl ps | grep anthos-baremetal-haproxy | awk '{print $1}'`
  sudo crictl logs `sudo crictl ps | grep anthos-baremetal-keepalived | awk '{print $1}'`
  

  Esse problema poderá acontecer se as imagens keepalived e haproxy não forem carregadas em um registro particular.

• (Use somente após uma criação bem-sucedida do cluster de administrador.) Se os IPs de serviço não estiverem acessíveis, verifique os registros dos pods metallb:

  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=controller -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=speaker -n kube-system
  

• Se todos os pods estiverem travados na criação do contêiner, siga um destes procedimentos:

  • Verifique a implantação do operador anetd e os registros do daemonset do anetd.

  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l name=cilium-operator -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l name=cilium-operator -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l k8s-app=cilium -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l k8s-app=cilium -n kube-system
  

  • Se um gateway padrão não estiver definido, pode ser que o iptables não funcione corretamente, de modo que o anetd-operator possa não conseguir acessar o servidor kube-api.

  ip route add default via <some-ip>
  iptables-save -t nat
  iptables-save -t filter
  

• Tente reiniciar o nó para ver se o problema é corrigido.

Erros comuns

Os comandos kubectl não funcionam

Se você não tiver configurado a ferramenta de linha de comando kubectl para se conectar a um servidor remoto da API Kubernetes, verá a seguinte mensagem de erro:

$ kubectl ...
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Verifique se você tem um kubeconfig definido. Para isso, defina a variável de ambiente KUBECONFIG ou execute os comandos com a sinalização --kubeconfig.
Por exemplo, para definir o kubeconfig do administrador, siga um destes procedimentos:

• Defina a variável de ambiente para o kubeconfig do administrador:

export KUBECONFIG=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig

• Use a opção de linha de comando kubeconfig:

kubectl --kubeconfig=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig

Para mais detalhes, consulte Como organizar o acesso ao cluster usando arquivos kubeconfig.

Falha na criação do cluster de usuário

Na estação de trabalho, para acessar o cluster de administrador e visualizar pods relacionados ao cluster de usuário, use o seguinte comando:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get po -n cluster-CLUSTER_NAME

Substitua CLUSTER_NAME pelo nome do cluster.

Se o cluster de usuário ainda falhar, tente excluir um cluster de usuário e reaplicar a seguinte configuração:

# Delete user cluster
export ADMIN_KUBECONFIG=$(pwd)/actl-workspace/admin/admin-kubeconfig
export USER_CLUSTER_NAME=user-1
kubectl -n cluster-${USER_CLUSTER_NAME} delete Cluster $USER_CLUSTER_NAME --kubeconfig=${ADMIN_KUBECONFIG}

# Re-apply the user cluster YAML file
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl apply -f user.yaml

# Wait until client config ready and stored in the path "$(pwd)/${USER_CLUSTER_NAME}-kubeconfig"
export USER_KUBECONFIG=$(pwd)/${USER_CLUSTER_NAME}-kubeconfig
waittime="5 minutes"
endtime=$(date -ud "$waittime" +%s)
while ! KUBECONFIG=${ADMIN_KUBECONFIG} actl clusters baremetal get-credentials -c "${USER_CLUSTER_NAME}" -o "${USER_KUBECONFIG}"; do
  if [[ $endtime -le $(date -u +%s) ]]; then
    echo "Client config not ready in $waittime, terminating"
    exit 1
  fi
  echo "client config not ready, sleeping 30s"
  sleep 30
done

# Check the user cluster status until all nodes are ready
KUBECONFIG=${USER_KUBECONFIG} kubectl get nodes

Criar o Anthos Management Center

Recursos insuficientes no cluster de administrador

O recurso personalizado AdminOperator configura a instalação do Anthos Management Center. Para ver se o controlador teve problemas para instalar a Central de gerenciamento, analise os eventos e os registros do Google Kubernetes Engine desse recurso e controlador personalizados:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe adminoperator admin-operator
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -n anthos-management-center-operator -l control-plane=admin-operator

Erros de extração de imagem

Iniciar pods no cluster pode levar a problemas que impedem o AdminOperator de informar o sucesso.

# Get all pods that aren't in a Running state or have succeeded.
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods --field-selector=status.phase!=Running,status.phase!=Succeeded -A

# Examine the pods of interest that are failing...
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe pod --namespace [NAMESPACE] [POD_OF_INTEREST]

Fazer upgrade

Anthos em bare metal

Para ver detalhes sobre como corrigir problemas relacionados a um upgrade no Anthos em Bare Metal, consulte Como recuperar um upgrade com falha no Anthos em Bare Metal.

Observação: para clusters de modo particular do Anthos, você precisa substituir o comando bmctl por actl ao aplicar as correções listadas para o Anthos em bare metal. Por exemplo, use actl clusters baremetal upgrade em vez de bmctl upgrade cluster.

Central de gerenciamento do Anthos

Para verificar a versão do componente instalado, use:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get adminoperator admin-operator -o yaml

Veja um exemplo da saída:

apiVersion: managementcenter.anthos.cloud.google.com/v1
kind: AdminOperator
spec:
  updateConfigOverride:
    policies:
    - name: anthos-config-management
      versionConstraint: <=1.8.0-gke.0
status:
  components:
  - name: anthos-bare-metal
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  - name: anthos-config-management
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  - name: anthos-service-mesh
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  version: 1.8.0-gke.0

Em um ambiente de modo privado do Anthos implantado, o status.version no objeto AdminOperator indica a versão da versão do modo privado do Anthos.

Por exemplo, 1.8.0-gke.0 status.components mostra o status da versão de cada componente. Ele lista a versão observada e a restrição de versão para cada componente implantado.

status.version e status.components precisam estar sempre disponíveis. Caso contrário, a instalação será corrompida. spec.updateConfigOverride é opcional. Ele só estará presente se os operadores de infraestrutura definirem manualmente o campo para fazer upgrade de um componente específico. Quando o campo é omitido, todos os componentes são executados na mesma versão que o AdminOperator.

Verificar pacotes na central de atualização

Somente os pacotes oferecidos na central de atualização são implantados na Central de gerenciamento.

Por exemplo, se primeiro você instalar o cluster de administrador com a versão 1.8.0-gke.0 e depois fazer upgrade para 1.8.1-gke.0, a central de atualizações terá dois conjuntos de pacotes. Excluir o recurso UpdateItem de um componente usado ativamente pode corromper a instalação do modo privado do Anthos.

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get updateitems -n anthos-management-center

Veja um exemplo da saída:

NAME                                  AGE
anthos-config-management-1.8.0-gke.0  13d
anthos-service-mesh-1.8.0-gke.0       13d

A seguir

• Saiba mais sobre os problemas conhecidos do modo privado do Anthos.