Problemas conhecidos dos clusters do Anthos em bare metal

Instalação

A criação de cluster falha ao usar multi-NIC, containerd e proxy

A criação de cluster falha quando você tem a seguinte combinação de condições:

  • O cluster é configurado para usar containerd como ambiente de execução do contêiner. nodeConfig.containerRuntime é definido como containerd no arquivo de configuração do cluster, o padrão para clusters do Anthos em bare metal na versão 1.8.

  • O cluster é configurado para fornecer várias interfaces de rede, multi-NIC, para pods. spec.clusterNetwork.multipleNetworkInterfaces é definido como true no arquivo de configuração do cluster.

  • O cluster é configurado para usar um proxy, em que spec.proxy.url é especificado no arquivo de configuração do cluster. Mesmo que a criação do cluster falhe, essa configuração é propagada quando você tenta criar um cluster. É possível ver essa configuração de proxy como uma variável de ambiente HTTPS_PROXY ou na configuração containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Como solução alternativa para esse problema, anexe CIDRs de serviço (clusterNetwork.services.cidrBlocks) à variável de ambiente NO_PROXY em todas as máquinas de nó.

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.

As verificações de simulação verificam se o cgroup v2 não está em uso na máquina de cluster.

Mensagens de erro benignas durante a instalação

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.

Verificações e permissão de simulação negadas

Durante a instalação, você poderá ver erros sobre /bin/sh: /tmp/disks_check.sh: Permission denied. Essas mensagens de erro são exibidas quando /tmp é ativado com a opção noexec. Para que o bmctl funcione, é necessário remover a opção noexec do ponto de ativação /tmp.

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.

Ubuntu 20.04 LTS e bmctl

Em clusters do Anthos em Bare Metal versão 1.8.2 ou anteriores, algumas distribuições do Ubuntu 20.04 LTS com um kernel Linux mais recente (incluindo imagens do Ubuntu 20.04 LTS do GCP no kernel 5.8) geraram um /proc/sys/net/netfilter/nf_conntrack_max somente leitura em namespaces de rede não init. Isso impede que bmctl defina o tamanho máximo da tabela de rastreamento de conexão, impedindo que o cluster de inicialização seja iniciado. Um sintoma do tamanho incorreto da tabela é que o pod kube-proxy no cluster de inicialização sofrerá um loop de falha, conforme mostrado no seguinte registro de erros de amostra:

kubectl logs -l k8s-app=kube-proxy -n kube-system --kubeconfig ./bmctl-workspace/.kindkubeconfig
I0624 19:05:08.009565       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 393216
F0624 19:05:08.009646       1 server.go:495] open /proc/sys/net/netfilter/nf_conntrack_max: permission denied

Uma solução alternativa é definir manualmente net/netfilter/nf_conntrack_max como o valor pretendido no host: sudo sysctl net.netfilter.nf_conntrack_max=393216 O valor necessário depende do número de núcleos do nó. Use o comando kubectl logs mostrado acima para confirmar o valor pretendido nos registros kube-proxy.

Esse problema foi corrigido nos clusters do Anthos em Bare Metal na versão 1.8.2 e posterior.

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.

Espelho de registros e Registros de auditoria do Cloud

Em clusters do Anthos em versões bare metal anteriores à 1.8.2, o pacote de espelho bmctl de registro não tem a imagem gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00. Para ativar o recurso do Registros de auditoria do Cloud ao usar um espelho de registro, você precisará fazer o download manual da imagem ausente e enviá-la para o servidor de registro com os seguintes comandos:

docker pull gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker tag gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00 REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker push REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00

O Containerd exige /usr/local/bin em PATH

Clusters com o ambiente de execução Containerd exigem que /usr/local/bin esteja no PATH do usuário de SSH para que o comando kubeadm init encontre o binário crictl. Se crictl não for encontrado, a criação do cluster falhará.

Quando você não estiver conectado como usuário raiz, sudo será usado para executar o comando kubeadm init. O CAMINHO sudo pode ser diferente do perfil raiz e pode não conter /usr/local/bin.

Corrija esse erro atualizando secure_path em /etc/sudoers para incluir /usr/local/bin. Como alternativa, crie um link simbólico para crictl em outro diretório /bin.

A partir da versão 1.8.2, os clusters do Anthos em Bare Metal adicionam /usr/local/bin ao PATH ao executar comandos. No entanto, a execução do snapshot como usuário não raiz ainda conterá crictl: command not found (que pode ser corrigido pela solução alternativa acima).

Como instalar no vSphere

Ao instalar clusters do Anthos em Bare Metal em VMs do vSphere, é preciso desativar as sinalizações tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation. Essas sinalizações são relacionadas à descarga de segmentação de hardware feita pelo vSphere driver VMXNET3 e não funcionam com o túnel GENEVE de clusters Anthos no ambiente Bare Metal.

Execute o comando a seguir em cada nó para verificar os valores atuais dessas sinalizações. ethtool -k NET_INTFC |grep segm ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... Substitua NET_INTFC pela interface de rede associada ao endereço IP do nó.

No RHEL 8.4, ethtool às vezes mostra que essas sinalizações estão desativadas, mas na realidade não estão. Para ter certeza de que estão desativadas, ative-as e depois desative-as com os comandos a seguir.

ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off

Essa alteração de sinalização não permanece nas reinicializações. Configure os scripts de inicialização para definir explicitamente esses sinalizadores quando o sistema for inicializado.

Prontidão do nó de oscilação

Às vezes, os clusters podem exibir uma prontidão de nó oscilante (alteração de status do nó rapidamente entre Ready e NotReady). Um Gerador de eventos do ciclo de vida do pod (PLEG, na sigla em inglês) não íntegro causa esse comportamento. O PLEG é um módulo no kubelet.

Para confirmar se um PLEG não íntegro está causando esse comportamento, use o seguinte comando journalctl para verificar se há entradas de registro PLEG:

journalctl -f | grep -i pleg

Entradas de registro como as seguintes indicam que o PLEG não está íntegro:

...
skipping pod synchronization - PLEG is not healthy: pleg was last seen active
3m0.793469
...

Uma disputa runc conhecida é a causa provável do PLEG não íntegro. Os processos runc travados são um sintoma da disputa. Use o seguinte comando para verificar o status do processo runc init:

ps aux | grep 'runc init'

Para corrigir esse problema:

  1. Determine o ambiente de execução do cluster.

    Antes de atualizar a versão runc, determine qual ambiente de execução de contêiner seu cluster usa. O campo containerRuntime no arquivo de configuração do cluster identifica qual ambiente de execução de contêiner seu cluster usa. Quando containerRuntime é definido como containerd, o cluster usa o ambiente de execução em contêiner. Se o campo estiver definido como docker ou não estiver definido, o cluster usará o ambiente de execução do Docker.

    Para receber o valor, abra o arquivo de configuração do cluster com seu editor favorito ou, se você tiver acesso ao kubeconfig do cluster de administrador, execute o seguinte comando:

    kubctl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE | grep -i runtime

    Substitua:

    • CLUSTER_NAME: o nome do cluster para backup.
    • CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces do cluster para os clusters do Anthos em bare metal são o nome do cluster precedido por cluster-.

  2. Para instalar o containerd.io ou o docker-ce e extrair a ferramenta de linha de comando runc mais recente, execute os comandos que correspondem ao sistema operacional e ao ambiente de execução do contêiner em cada nó.

    Ubuntu em contêiner

    sudo apt update
sudo apt install containerd.io
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

    Docker do Ubuntu

    sudo apt update
sudo apt install docker-ce
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

    Containerd CentOS/RHEL

    sudo dnf install containerd.io
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

    Docker do CentOS/RHEL

    sudo dnf install docker-ce
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

  3. Reinicialize o nó se houver processos runc init travados.

    Também é possível limpar manualmente todos os processos travados.

Upgrades e atualizações

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.

O upgrade parou em error during manifests operations

Em algumas situações, os upgrades de cluster não são concluídos e a CLI bmctl não responde. Esse problema pode ser causado por um recurso atualizado incorretamente. Para saber se você foi afetado por esse problema e corrigi-lo, siga estas etapas:

  1. Verifique os registros anthos-cluster-operator e procure erros semelhantes às seguintes entradas:

    controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred:
...
{RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

    Essas entradas são um sintoma de um recurso atualizado incorretamente, em que {RESOURCE_NAME} é o nome do recurso com problema.

  2. Se você encontrar esses erros nos registros, use kubectl edit para remover a anotação kubectl.kubernetes.io/last-applied-configuration do recurso contido na mensagem do registro.

  3. Salve e aplique as alterações no recurso.

  4. Tente fazer o upgrade do cluster novamente.

Falha nos upgrades dos clusters da versão 1.8 no modo de manutenção

A tentativa de fazer upgrade de um cluster da versão 1.8.x para a versão 1.9.x falhará se qualquer máquina de nó tiver sido colocada anteriormente no modo de manutenção. Isso ocorre devido a uma anotação que permanece nesses nós.

Para saber se você foi afetado por esse problema, siga estas etapas:

  1. Receba a versão do cluster que você quer atualizar executando o seguinte comando:

    kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME  \
    -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"

    Se o valor de versão retornado for para a versão secundária 1.8, como 1.8.3, continue. Caso contrário, esse problema não se aplica a você.

  2. Verifique se o cluster tem nós que foram colocados anteriormente no modo de manutenção executando o seguinte comando:

    kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE  \
    --output=jsonpath="{.items[*].metadata.annotations}"

    Se as anotações retornadas contiverem baremetal.cluster.gke.io/maintenance-mode-duration, você será afetado por esse problema conhecido.

Para desbloquear o upgrade do cluster, execute o seguinte comando para cada máquina de nó afetada para remover a anotação baremetal.cluster.gke.io/maintenance-mode-duration:

kubectl --kubeconfig ADMIN_KUBECONFIG  annotate BareMetalMachine -n CLUSTER_NAMESPACE \
    NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-

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.

Upgrades de cluster a partir de 1.7.x falham em determinadas configurações do balanceador de carga

O upgrade de clusters da versão 1.7.x para 1.8.y pode falhar nas seguintes configurações do balanceador de carga:

  • Balanceador de carga externo configurado manualmente (loadBalancer.mode definido como manual)

  • Balanceamento de carga em pacote (loadBalancer.mode definido como bundled), usando um pool de nós separado (loadBalancer.nodePoolSpec.nodes são especificados)

Um sintoma dessa falha é que o job cal-update em um nó do plano de controle falha na tarefa Check apiserver health com mensagens de erro de conexão recusada.

Veja um exemplo de registro para o job cal-update:

TASK [cal-update : Check apiserver health] *************************************
Thursday 20 January 2022  13:50:46 +0000 (0:00:00.033)       0:00:09.316 ******
FAILED - RETRYING: Check apiserver health (30 retries left).
FAILED - RETRYING: Check apiserver health (29 retries left).
FAILED - RETRYING: Check apiserver health (28 retries left).
FAILED - RETRYING: Check apiserver health (27 retries left).
FAILED - RETRYING: Check apiserver health (26 retries left).
...
FAILED - RETRYING: Check apiserver health (3 retries left).
FAILED - RETRYING: Check apiserver health (2 retries left).
FAILED - RETRYING: Check apiserver health (1 retries left).
[WARNING]: Consider using the get_url or uri module rather than running 'curl'.
If you need to use command because get_url or uri is insufficient you can add
'warn: false' to this command task or set 'command_warnings=False' in
ansible.cfg to get rid of this message.
fatal: [10.50.116.79]: FAILED! => {"attempts": 30, "changed": true, "cmd": "curl
-k https://127.0.0.1/healthz", "delta": "0:00:00.008949", "end": "2022-01-20
19:22:30.381875", "msg": "non-zero return code", "rc": 7, "start": "2022-01-20
19:22:30.372926", "stderr": "  % Total    % Received % Xferd  Average Speed
Time    Time     Time  Current\n                                 Dload  Upload
Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --
:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to 127.0.0.1 port 443:
Connection refused", "stderr_lines": ["  % Total    % Received % Xferd  Average
Speed   Time    Time     Time  Current", "                                 Dload
Upload   Total   Spent    Left  Speed", "", "  0     0    0     0    0     0
0      0 --:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to
127.0.0.1 port 443: Connection refused"], "stdout": "", "stdout_lines": []}

Como alternativa manual, crie um encaminhamento da porta 443 (em que a verificação acontece) para a porta 6444 (em que apiserver detecta) antes do upgrade. Para criar o encaminhamento de portas, execute o seguinte comando em cada nó do plano de controle:

sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

O job cal-update é executado quando há uma reconciliação e verifica a porta 443. Portanto, mantenha esse encaminhamento de portas para os clusters 1.8.x com upgrade.

Depois de fazer upgrade para a versão 1.9.0 ou mais recente, remova o encaminhamento de portas executando o seguinte comando em cada nó do plano de controle:

sudo iptables -t nat -D OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

Os upgrades para clusters de administrador, híbridos e autônomos para 1.8.0 e 1.8.1 não são concluídos

A atualização dos clusters de administrador, híbridos ou autônomos da versão 1.7.x para 1.8.0 ou 1.8.1 às vezes não é concluída. Essa falha de upgrade se aplica aos clusters que você atualizou após a criação do cluster.

Uma indicação desse problema de upgrade é o Waiting for upgrade to complete ... de saída do console sem referência a que nó está sendo atualizado. Esse sintoma também indica que o cluster de administrador foi atualizado para a versão v1.20.8-gke.1500 do Kubernetes, a versão do Kubernetes para clusters do Anthos em versões bare metal 1.8.0 e 1.8.1.

Esse problema de upgrade foi corrigido para clusters do Anthos na versão 1.8.2 do Bare Metal.

Para confirmar se esse problema afeta o upgrade do cluster para 1.8.0 ou 1.8.1:

  1. Crie o script de shell a seguir:

    if [ $(kubectl get cluster <var>CLUSTER\_NAME -n <var>CLUSTER\_NAMESPACE
    --kubeconfig bmctl-workspace/.kindkubeconfig -o=jsonpath='{.metadata.generation}')
    -le $(kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE
    --kubeconfig bmctl-workspace/.kindkubeconfig
    -o=jsonpath='{{.status.systemServiceConditions[?(@.type=="Reconciling")].observedGeneration}}') ];
    then echo "Bug Detected"; else echo "OK"; fi

    Substitua:

    • CLUSTER_NAME: o nome do cluster que está sendo verificado.
    • CLUSTER_NAMESPACE: o namespace do cluster.

  2. Execute o script enquanto o upgrade está em andamento, mas após a conclusão das verificações de simulação.

    Quando o valor observedGeneration não é menor que o valor generation, Bug Detected é gravado na saída do console. Essa saída indica que o upgrade do cluster foi afetado.

  3. Para desbloquear o upgrade, execute o seguinte comando:

    kubectl get --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
    --kubeconfig bmctl-workspace/.kindkubeconfig | \
    sed -e 's/\("systemServiceConditions":\[{[^{]*"type":"DashboardReady"}\),{[^{}]*}/\1/g' | \
    kubectl replace --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
    --kubeconfig bmctl-workspace/.kindkubeconfig -f-

    Substitua:

    • CLUSTER_NAME: o nome do cluster que está sendo verificado.
    • CLUSTER_NAMESPACE: o namespace do cluster.

Atualizações para 1.8.3 ou 1.8.4

A atualização dos clusters do Anthos em Bare Metal para a versão 1.8.3 ou 1.8.4 às vezes falha com um erro de contexto nulo. Se o upgrade de cluster falhar com um erro de contexto nulo, execute as seguintes etapas para concluir o upgrade:

  1. Defina a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS a fim de apontar para o arquivo da chave da conta de serviço.

    export GOOGLE_APPLICATION_CREDENTIALS=KEY_PATH

    Substitua KEY_PATH pelo caminho do arquivo JSON que contém a chave da conta de serviço.

  2. Execute o comando bmctl upgrade cluster novamente.

Limitação de upgrade do patch do cluster de usuário

Os clusters de usuário gerenciados por um cluster de administrador precisam estar nos mesmos clusters do Anthos em uma versão bare metal ou anterior e em uma versão secundária. Por exemplo, um cluster de administrador da versão 1.7.1 (anthosBareMetalVersion: 1.7.1) que gerencia clusters de usuário da versão 1.6.2 é aceitável.

Uma limitação de upgrade impede que você faça upgrade dos clusters de usuário para um novo patch de segurança quando o patch for lançado após a versão de lançamento do cluster de administrador. Por exemplo, se o cluster de administrador estiver na versão 1.7.2, lançada em 2 de junho de 2021, não será possível fazer upgrade dos clusters de usuário para a versão 1.6.4, porque ela foi lançada em 13 de agosto. , 2021.

Incompatibilidade do Ubuntu 18.04 e 18.04.1

Para fazer upgrade para a versão 1.8.1 ou 1.8.2, as máquinas de nó do cluster e a estação de trabalho que executa o bmctl precisam ter o kernel Linux versão 4.17.0 ou mais recente. Caso contrário, o controlador de rede anetd não funcionará. O sintoma é que os pods com o prefixo anet no namespace kube-system continuarão a falhar com a seguinte mensagem: BPF NodePort services needs kernel 4.17.0 or newer.

Esse problema afeta o Ubuntu 18.04 e 18.04.1, já que eles estão na versão 4.15 do kernel.

Esse problema foi corrigido nos clusters do Anthos no Bare Metal 1.8.3.

Como fazer upgrade de clusters 1.7.x que usam containerd

Os upgrades de cluster para a versão 1.8.x estão bloqueados para clusters 1.7.x configurados para usar o recurso de visualização containerd. A visualização do containerd usa o driver do grupo de controle incorreto (cgroup) cgroupfs, em vez do driver systemd recomendado. Há casos relatados de instabilidade do cluster quando os clusters que usam o driver cgroupfs são colocados sob pressão de recursos. O recurso containerd do GA na versão 1.8.0 usa o driver systemd correto.

Se você tiver clusters 1.7.x que usam o recurso de ambiente de execução do contêiner de visualização, recomendamos queCriar novos clusters 1.8.0 configurados para containerd e migrar os aplicativos e as cargas de trabalho existentes. Isso garante a maior estabilidade do cluster ao usar o ambiente de execução do contêiner do containerd.

Falhas de upgrade no SELinux

A atualização de clusters 1.7.1 configurados com o ambiente de execução de contêiner containerd e a execução do SELinux no RHEL ou CentOS falharão. Recomendamos que você crie novos clusters do 1.8.0 configurados para usar o containerd e migrar suas cargas de trabalho.

Não é possível iniciar a diminuição do nó quando ele está fora de alcance

O processo de drenagem para nós não será iniciado se o nó estiver fora de alcance dos clusters do Anthos em bare metal. Por exemplo, se um nó ficar off-line durante um processo de upgrade de cluster, ele poderá fazer com que o upgrade pare de responder. Isso é raro. Para minimizar a probabilidade de encontrar esse problema, verifique se os nós estão funcionando corretamente antes de iniciar um upgrade.

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):

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

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

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

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

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.

serviço containerd

O comando bmctl reset não exclui arquivos de configuração containerd ou binários. O serviço containerd systemd está ativo e em execução. O comando exclui os contêineres que estão executando pods programados para o nó.

Segurança

A CA/certificado do cluster será rotacionada durante o upgrade. A compatibilidade de rotação sob demanda é um recurso de pré-lançamento.

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.

Rotação de CA do cluster (recurso de visualização)

Depois que você executa uma rotação de autoridade de certificação do cluster de usuário (CA) em um cluster, todos os fluxos de autenticação do usuário falham. Essas falhas ocorrem porque o recurso personalizado ClientConfig usado nos fluxos de autenticação não está sendo atualizado com os novos dados da CA durante a rotação da CA. Se você executou uma rotação de CA do cluster no cluster, verifique se o campo certificateAuthorityData no ClientConfig default do namespace kube-public contém a CA do cluster mais antiga.

Para resolver o problema manualmente, atualize o campo certificateAuthorityData com a CA do cluster atual.

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.

Modificar o firewall apagará as cadeias de políticas do Cilium iptable

Ao executar clusters do Anthos em Bare Metal com firewalld ativado no CentOS ou no Red Had Enterprise Linux (RHEL), as alterações em firewalld podem remover as cadeias iptables do Cilium na rede do host. As cadeias iptables são adicionadas pelo pod anetd quando ele é iniciado. A perda das cadeias do iptables do Cilium faz com que o pod no nó perca a conectividade de rede fora do nó.

As alterações em firewalld que removerão as cadeias de iptables incluem, mas não estão limitadas a:

  • Reiniciando firewalld, usando systemctl
  • Como atualizar o firewalld com o cliente da linha de comando (firewall-cmd --reload)

Para corrigir esse problema de conectividade, reinicie o anetd. Localize e exclua o pod anetd com os seguintes comandos para reiniciar anetd:

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

Substitua ANETD_XYZ pelo nome do pod anetd.

Endereços egressSourceIP duplicados

Ao usar a visualização do recurso Gateway NAT de saída, é possível definir regras de seleção de tráfego que especificam um endereço egressSourceIP que já está sendo usado por outro objeto EgressNATPolicy. Isso pode causar conflitos de roteamento do tráfego de saída. Coordene com sua equipe de desenvolvimento para determinar quais endereços IP flutuantes estão disponíveis para uso antes de especificar o endereço egressSourceIP no recurso EgressNATPolicy personalizado.

Falhas de conectividade do pod devido ao tempo limite de E/S e à filtragem de caminho reverso

Os clusters do Anthos em bare metal configuram a filtragem de caminho reverso em 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ó.

Falhas de conectividade observadas na comunicação com os endereços IP do serviço do Kubernetes são um sintoma desse problema. Veja alguns exemplos de tipos de erros que é possível ver:

  • Se todos os pods de um determinado nó não se comunicarem com os endereços IP do Serviço, o pod istiod poderá relatar um erro como o seguinte:

     {"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z",
    "message":"watch error in cluster Kubernetes: failed to list *v1.Node:
    Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5  34239\":
    dial tcp 172.26.0.1:443: i/o timeout"}

  • Para o conjunto de daemon localpv executado em cada nó, o registro pode mostrar um tempo limite como o seguinte:

     I1112 17:24:33.191654       1 main.go:128] Could not get node information
(remaining retries: 2): Get
https://172.26.0.1:443/api/v1/nodes/NODE_NAME:
dial tcp 172.26.0.1:443: i/o timeout

A filtragem de caminho reverso é definida com arquivos rp_filter na pasta de configuração do IPv4 (net/ipv4/conf/all). O comando sysctl 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. O comando sysctl pode substituir a configuração de filtragem de caminho reverso.

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. Um novo pod anetd é iniciado:

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

Substitua ANETD_XYZ pelo nome do pod anetd.

Para definir o net.ipv4.conf.all.rp_filter manualmente, execute o seguinte comando:

sysctl -w net.ipv4.conf.all.rp_filter = 0

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á validação para endereços IP sobrepostos em diferentes clusters durante a atualização. A validação se aplica somente no momento da criação do pool de nós/cluster.

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 compatível.

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. Esse número é a soma de todos os pods referenciados por um 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.

Ambiente de execução de VM do Anthos

  • Reiniciar um pod faz com que as VMs nele alterem os endereços IP ou percam os endereços IP completamente. Se o endereço IP de uma VM for alterado, isso não afetará a acessibilidade dos aplicativos de VM expostos como um serviço do Kubernetes. Se o endereço IP for perdido, execute dhclient a partir da VM para adquirir um endereço IP para a VM.

SELinux

Erros do SELinux durante a criação do pod

A criação do pod às vezes falha quando o SELinux impede o ambiente de execução do contêiner de configurar rótulos em montagens tmpfs. Essa falha é rara, mas pode acontecer quando o SELinux está no modo Enforcing e em alguns kernels.

Para verificar se o SELinux é a causa das falhas na criação de pods, use o seguinte comando para verificar se há erros nos registros kubelet:

journalctl -u kubelet

Se o SELinux estiver causando falha na criação do pod, a resposta do comando conterá um erro semelhante ao seguinte:

error setting label on mount source '/var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x':
failed to set file label on /var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x:
permission denied

Para verificar se esse problema está relacionado à aplicação do SELinux, execute o seguinte comando:

ausearch -m avc

Esse comando pesquisa nos registros de auditoria erros de permissão de cache de vetor de acesso (AVC). O avc: denied no exemplo de resposta a seguir confirma que as falhas de criação do pod estão relacionadas à aplicação do SELinux.

type=AVC msg=audit(1627410995.808:9534): avc:  denied  { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0

A causa raiz desse problema de criação de pods com o SELinux é um bug do kernel encontrado nas seguintes imagens do Linux:

  • Red Hat Enterprise Linux (RHEL) versões anteriores à 8.3
  • Versões do CentOS anteriores à 8.3

A reinicialização da máquina ajuda a recuperar o problema.

Para evitar erros de criação de pods, use o RHEL 8.3 ou posterior ou o CentOS 8.3 ou posterior, porque essas versões corrigiram o bug do kernel.

Snapshots

Como tirar um snapshot como um usuário de login não raiz

Para clusters do Anthos em versões bare metal 1.8.1 e anteriores, se você não estiver conectado como raiz, não será possível tirar um snapshot do cluster com o comando bmctl. A partir da versão 1.8.2, os clusters do Anthos em bare metal respeitarão nodeAccess.loginUser na especificação do cluster. Se o cluster de administrador estiver inacessível, especifique o usuário de login com a sinalização --login-user.

Se você usar o containerd como o ambiente de execução de contêiner, o snapshot ainda não executará comandos do crictl. Consulte Containerd requer /usr/local/bin em PATH para uma solução alternativa. As configurações PATH usadas para SUDO causam esse problema.

GKE Connect

Loop de falha do pod gke-connect-agent

O uso pesado do gateway do GKE Connect às vezes pode resultar em problemas de falta de memória do pod gke-connect-agent. Os sintomas desses problemas de falta de memória incluem:

  • O pod gke-connect-agent mostra um alto número de reinicializações ou termina em estado de loop de falhas.
  • O gateway de conexão para de funcionar.

Para resolver esse problema de falta de memória, edite a implantação com o prefixo gke-connect-agent no namespace gke-connect e aumente o limite de memória para 256 MiB ou superior.

kubectl patch deploy $(kubectl get deploy -l app=gke-connect-agent -n gke-connect -o jsonpath='{.items[0].metadata.name}') -n gke-connect --patch '{"spec":{"containers":[{"resources":{"limits":{"memory":"256Mi"}}}]}}'

Esse problema foi corrigido nos clusters do Anthos em Bare Metal na versão 1.8.2 e posterior.

Como gerar registros e monitorar

stackdriver-log-forwarder pod travando reiniciando

Para clusters do Anthos em versões bare metal anteriores à 1.9, se um nó for desligado à força, o pod stackdriver-log-forwarder poderá ficar preso em um estado de reinicialização. Nesse caso, você verá uma entrada de registro como a seguinte:

[error] [input:storage_backlog:storage_backlog.7] chunk validation failed, data might
be corrupted. Found 0 valid records, failed content starts right after byte 0.

Quando o pod stackdriver-log-forwarder está travado, a maioria dos registros é impedida de acessar o Cloud Logging e os dados não liberados são perdidos. Para resolver esse problema, redefina o pipeline de geração de registros.

Para redefinir o pipeline de geração de registros:

  1. Reduza a escala vertical do stackdriver-operator.

    kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
    stackdriver-operator --replicas=0

  2. Exclua o DaemonSet stackdriver-log-forwarder:

    kubectl --kubeconfig KUBECONFIG -n kube-system delete daemonset \
    stackdriver-log-forwarder

    Verifique se os pods stackdriver-log-forwarder foram excluídos antes de ir para a próxima etapa.

  3. Implante o seguinte DaemonSet para limpar todos os dados corrompidos nos buffers fluent-bit:

    kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF

  4. Verifique se o DaemonSet limpou todos os nós.

    A saída dos comandos a seguir precisa ser igual ao número de nós do cluster.

    kubectl --kubeconfig KUBECONFIG logs -n kube-system -l app=fluent-bit-cleanup | \
    grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG -n kube-system get pods -l app=fluent-bit-cleanup \
    --no-headers | wc -l

  5. Exclua o DaemonSet de limpeza.

    kubectl --kubeconfig KUBECONFIG -n kube-system delete ds fluent-bit-cleanup

  6. Faça o escalonamento vertical do operador e aguarde até que ele reimplante o pipeline de geração de registros.

    kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
    stackdriver-operator --replicas=1

Esse problema foi corrigido nos clusters do Anthos em Bare Metal na versão 1.8.2 e posterior.