Versão 1.6. Esta versão não é mais compatível. Para mais informações, consulte a política de suporte de versões. Para informações sobre como fazer upgrade para a versão 1.7, consulte Como fazer upgrade do Anthos em Bare Metal na documentação do 1.7.

Versões com suporte disponíveis: 1.14 | 1.13 | 1.12

Problemas conhecidos dos clusters do Anthos em bare metal

Instalação

Incompatibilidade com o grupo de controle v2

O Grupo de controle v2 (cgroup v2) é incompatível com os clusters do Anthos no bare metal 1.6. O Kubernetes 1.18 não é compatível com o cgroup v2. Além disso, o Docker oferece suporte experimental apenas a partir de 20.10. O systemd foi alterado para cgroup v2 por padrão na versão 224.2-2. A presença de /sys/fs/cgroup/cgroup.controllers indica que seu sistema usa o cgroup v2.

A partir dos clusters do Anthos em bare metal 1.6.2, as verificações de simulação verificam se o cgroup v2 não está em uso na máquina do cluster.

Mensagens de erro benignas durante a instalação

Durante a instalação do cluster altamente disponível (HA, na sigla em inglês), é possível que ocorram erros de etcdserver leader change. Essas mensagens de erro são benignas e podem ser ignoradas.

Ao usar bmctl para instalação do cluster, é possível que veja uma mensagem de registro Log streamer failed to get BareMetalMachine no final do create-cluster.log. Essa mensagem de erro é benigna e pode ser ignorada.

Ao examinar os registros de criação de cluster, talvez você note falhas temporárias sobre o registro de clusters ou a chamada de webhooks. Esses erros podem ser ignorados com segurança, porque a instalação tentará novamente até que as operações sejam concluídas.

Verificações de simulação e credenciais da conta de serviço

Para instalações acionadas por clusters administrativos ou de clusters híbridos (em outras palavras, clusters não criados com bmctl, como clusters de usuários), a verificação de simulação não verifica as credenciais da conta de serviço do Google Cloud Platform ou suas permissões associadas.

Application Default Credentials e `bmctl`

bmctl usa Application Default Credentials (ADC, na sigla em inglês) para validar o valor de local da operação do cluster no cluster spec quando não está definido como global.

Para que as ADC funcionem, você precisa apontar a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para um arquivo de credencial de conta de serviço ou executar gcloud auth application-default login.

Serviço do Docker

Em máquinas de nó de cluster, se o executável do Docker estiver presente na variável de ambiente do PATH, mas o serviço do Docker não estiver ativo, a verificação de simulação falhará e informará que o Docker service is not active. Para corrigir esse erro, remova o Docker ou ative o serviço do Docker.

Upgrades e atualizações

O upgrade não está disponível nos clusters do Anthos em versões bare metal 1.6.x.

`bmctl update cluster` falhará se o diretório `.manifests` não estiver presente

Se o diretório .manifests for removido antes de executar bmctl update cluster, o comando falhará com um erro semelhante ao seguinte:

Error updating cluster resources.: failed to get CRD file .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: open .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: no such file or directory

É possível corrigir esse problema executando bmctl check cluster primeiro, o que recriará o diretório .manifests.

Esse problema se aplica aos clusters do Anthos em bare metal 1.10 e versões anteriores e é corrigido na versão 1.11 e posteriores.

`bmctl update` não remove bloqueios de manutenção

O comando bmctl update não pode remover nem modificar a seção maintenanceBlocks da configuração de recursos do cluster. Veja mais informações, incluindo instruções sobre a remoção de nós do modo de manutenção em Colocar nós no modo de manutenção.

Operação

Secret do kubeconfig substituído

O comando bmctl check cluster, quando executado em clusters de usuários, substitui a chave secreta kubeconfig do cluster de usuário pelo kubeconfig do cluster de administrador. A substituição do arquivo causa falhas nas operações padrão do cluster, como atualização e upgrade, para os clusters de usuário afetados. Esse problema se aplica aos clusters do Anthos na versão bare metal 1.11.1 e anteriores.

Para determinar se um cluster de usuário é afetado por esse problema, execute o seguinte comando:

kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n cluster-USER_CLUSTER_NAME \
    USER_CLUSTER_NAME -kubeconfig  -o json  | jq -r '.data.value'  | base64 -d

Substitua:

ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
USER_CLUSTER_NAME: o nome do cluster de usuário a ser verificado.

Se o nome do cluster na saída (consulte contexts.context.cluster no exemplo de saída a seguir) for o nome do cluster de administrador, o cluster de usuário especificado será afetado.

user-cluster-kubeconfig  -o json  | jq -r '.data.value'  | base64 -d
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81874
    user: ci-aed78cdeca81874-admin
  name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

As etapas a seguir restauram a função em um cluster de usuário afetado (USER_CLUSTER_NAME):

Localizar o arquivo kubeconfig do cluster de usuário.

Os clusters do Anthos em bare metal geram o arquivo kubeconfig na estação de trabalho de administrador quando você cria um cluster. Por padrão, o arquivo está no diretório bmctl-workspace/USER_CLUSTER_NAME.
Verifique se o kubeconfig está correto no cluster de usuário kubeconfig:
```
kubectl get nodes --kubeconfig PATH_TO_GENERATED_FILE
```
Substitua PATH_TO_GENERATED_FILE pelo caminho para o arquivo Kubeconfig do cluster de usuário. A resposta retorna detalhes sobre os nós do cluster de usuário. Confirme se os nomes de máquina estão corretos para o cluster.
Execute o seguinte comando para excluir o arquivo kubeconfig corrompido no cluster de administrador:
```
kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig
```

Execute o seguinte comando para salvar o secret kubeconfig correto de volta no cluster de administrador:

kubectl create secret generic -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig \
    --from-file=value=PATH_TO_GENERATED_FILE

Redefinir/excluir

Credenciais do cluster de usuário

O comando bmctl reset depende da seção de credenciais de nível superior no arquivo de configuração do cluster. Para clusters de usuários, você precisará atualizar manualmente o arquivo para adicionar a seção de credenciais.

Pontos de montagem e `fstab`

A redefinição não desmonta os pontos de montagem em /mnt/anthos-system e /mnt/localpv-share/. Ela também não limpa as entradas correspondentes em /etc/fstab.

Exclusão de namespaces

A exclusão de um namespace impedirá a criação de novos recursos nesse namespace, incluindo jobs para redefinir máquinas. Ao excluir um cluster de usuário, você precisa excluir o objeto de cluster antes de excluir o namespace dele. Caso contrário, os jobs para redefinir as máquinas não poderão ser criados e o processo de exclusão ignorará a etapa de limpeza da máquina.

Segurança

A CA/certificado do cluster será rotacionada durante o upgrade. O suporte à rotação sob demanda não está disponível no momento.

Os clusters do Anthos em bare metal rotacionam a veiculação de certificados do kubelet automaticamente. Cada agente de nó kubelet pode enviar uma solicitação de assinatura de certificado (CSR, na sigla em inglês) quando um certificado estiver prestes a expirar. Um controlador nos clusters de administrador valida e aprova a CSR.

Rede

IP de origem do cliente com balanceamento de carga em pacote de camada 2

Definir a política de tráfego externo como Local pode causar erros de roteamento, como No route to host, para balanceamento de carga em pacote de camada 2. A política de tráfego externo é definida como Cluster (externalTrafficPolicy: Cluster), por padrão. Com essa configuração, o Kubernetes processa o tráfego em todo o cluster. Serviços do tipo LoadBalancer ou NodePort podem usar externalTrafficPolicy: Local para preservar o endereço IP da origem do cliente. No entanto, com essa configuração, o Kubernetes processa apenas o tráfego local do nó.

Se você quiser preservar o endereço IP da origem do cliente, será necessário fazer outras configurações para garantir que os IPs de serviço estejam acessíveis. Para detalhes de configuração, consulte Como preservar o endereço IP da origem do cliente em Configurar o balanceamento de carga em pacote.

Falhas de conectividade dos pods e filtragem de caminho reverso

Os clusters do Anthos no bare metal configura o filtro de caminho reverso nos nós para desativar a validação de origem (net.ipv4.conf.all.rp_filter=0). Se a configuração rp_filter for alterada para 1 ou 2, os pods falharão devido a tempos limite de comunicação fora do nó.

A filtragem de caminho reverso é definida com arquivos rp_filter na pasta de configuração IPv4 (net/ipv4/conf/all). Este valor também pode ser modificado por sysctl, que armazena as configurações de filtragem de caminho reverso em um arquivo de configuração de segurança de rede, como /etc/sysctl.d/60-gce-network-security.conf.

Para restaurar a conectividade do pod, defina net.ipv4.conf.all.rp_filter de volta para 0 manualmente ou reinicie o pod de anetd para definir net.ipv4.conf.all.rp_filter novamente para 0. Para reiniciar o pod anetd, use os seguintes comandos para localizar e excluir o pod anetd, e um novo pod anetd será iniciado no lugar:

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Substitua ANETD_XYZ pelo nome do pod anetd.

Endereços IP do cluster de inicialização (tipo) e endereços IP dos nós do cluster sobrepostos

192.168.122.0/24 e 10.96.0.0/27 são as CIDRs padrão do pod e do serviço usadas pelo cluster de inicialização (tipo). As verificações de simulação falharão se houver sobreposição com os endereços IP da máquina do nó do cluster. Para evitar o conflito, passe as sinalizações --bootstrap-cluster-pod-cidr e --bootstrap-cluster-service-cidr para bmctl para especificar valores diferentes.

Como sobrepor endereços IP em clusters diferentes

Não há verificação de simulação para validar os endereços IP sobrepostos em diferentes clusters.

Recurso `hostport` nos clusters do Anthos em bare metal

O recurso hostport em ContainerPort não é suportado.

Sistema operacional

Falha na criação ou atualização do cluster no CentOS

Em dezembro de 2020, a comunidade do CentOS e a Red Hat anunciaram o fim do CentOS. Em 31 de janeiro de 2022, o CentOS 8 chegou ao fim da vida útil (EOL). Como resultado do EOL, os repositórios yum pararam de funcionar com o CentOS, o que causa falha nas operações de criação e atualização dos clusters. Isso se aplica a todas as versões compatíveis do CentOS e afeta todas as versões dos clusters do Anthos em bare metal.

Como solução alternativa, execute os seguintes comandos para que seu CentOS use um feed de arquivo:

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
    /etc/yum.repos.d/CentOS-Linux-*

Como solução de longo prazo, considere migrar para outro sistema operacional com suporte, como Ubuntu ou RHEL.

Limitações do endpoint do sistema operacional

No RHEL e no CentOS, há uma limitação no nível do cluster de 100.000 endpoints. Serviço do Kubernetes. Se dois serviços fizerem referência ao mesmo conjunto de pods, isso conta como dois conjuntos separados de endpoints. A implementação nftable subjacente no RHEL e no CentOS causa essa limitação. A limitação não é intrínseca dos clusters do Anthos em bare metal.

Configuração

Especificações do plano de controle e do balanceador de carga

As especificações do plano de controle e do pool de nós do balanceador de carga são especiais. Essas especificações declaram e controlam os recursos essenciais do cluster. A fonte canônica desses recursos é as respectivas seções no arquivo de configuração do cluster.

spec.controlPlane.nodePoolSpec
spec.LoadBalancer.nodePoolSpec

Consequentemente, não modifique o plano de controle de nível superior e os recursos do pool de nós do balanceador de carga diretamente. Modifique as seções associadas no arquivo de configuração do cluster.

Campos mutáveis na especificação de cluster e pool de nós

Atualmente, somente os seguintes campos de especificação de cluster e pool de nós no arquivo de configuração do cluster podem ser atualizados após a criação do cluster (campos mutáveis):

No caso do objeto Cluster (kind: Cluster), os seguintes campos são mutáveis:
- spec.anthosBareMetalVersion
- spec.bypassPreflightCheck
- spec.controlPlane.nodePoolSpec.nodes
- spec.loadBalancer.nodePoolSpec.nodes
- spec.maintenanceBlocks
- spec.nodeAccess.loginUser
No caso do objeto NodePool (kind: NodePool), os seguintes campos são mutáveis:
- spec.nodes

O nó mostra o status `NotReady`

Em determinadas condições de carga, os clusters do Anthos em nós bare metal 1.6.x podem exibir um status NotReady devido ao Gerador de eventos do ciclo de vida do pod (PLEG) não íntegro. O status do nó conterá a seguinte entrada:

PLEG is not healthy: pleg was last seen active XXXmXXXs ago; threshold is 3m0s

Como saber se fui afetado?

Uma causa provável desse problema é a versão binária do runc. Para confirmar se você tem a versão problemática instalada, conecte-se a uma das máquinas de cluster usando SSH e execute:

/usr/bin/runc -v

Se a saída for 1.0.0-rc93, isso significa que você tem a versão problemática instalada.

Possíveis soluções

Para resolver esse problema, recomendamos fazer upgrade para os clusters do Anthos no bare metal 1.7.0 ou uma versão posterior.

Se o upgrade não for uma opção, será possível reverter o pacote containerd.io para uma versão anterior nas máquinas com nós problemáticos. Para fazer isso, conecte-se à máquina de nó usando SSH e execute:

Ubuntu

apt install containerd.io=1.4.3-1

CentOS/RHEL

dnf install containerd.io-1.3.9-3.1.el8.