Versão 1.7. Essa versão é compatível, conforme mencionado na política de compatibilidade de versão do Anthos, e oferece patches e atualizações mais recentes para vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos em bare metal. Veja os detalhes nas notas de lançamento 1.7. Esta não é a versão mais recente. Para ver uma lista completa de cada lançamento de versões secundárias e de patches em ordem cronológica, consulte as notas de lançamento combinadas.

Versões disponíves: 1.8  |   1.7  |   1.6

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.

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 causadas porque /tmp está ativado com a opção noexec. Para que bmctl funcione, é preciso remover a opção noexec do ponto de ativação /tmp.

Como criar um espaço de trabalho de monitoramento na nuvem antes de visualizar os painéis

É necessário criar um espaço de trabalho de monitoramento na nuvem pelo Console do Google Cloud antes de visualizar qualquer painel de monitoramento dos clusters do Anthos em bare metal.

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.

Ubuntu 20.04.3+ LTS e HWE

O Ubuntu 20.04.3 ativou o kernel 5.11 no pacote de ativação de hardware (HWE). Os clusters do Anthos na versão bare metal 1.7.x não são compatíveis com esse kernel. Se você quiser usar o kernel 5.11, faça o download e o upgrade para clusters do Anthos na versão bare metal 1.8.0 ou 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.

O arquivo em contêiner 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 PATH 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).

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. Execute os seguintes comandos em cada nó para instalar o containerd.io mais recente e extrair a ferramenta de linha de comando runc mais recente:

    Ubuntu

    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
    

    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
    
  2. Reinicialize o nó se houver processos runc init travados.

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

Como fazer upgrade de clusters do Anthos no bare metal

Como fazer upgrade da versão 1.6.0

O upgrade não está disponível na versão 1.6.0.

Como fazer upgrade da versão 1.7.0 para a 1.7.x

Ao fazer upgrade da versão 1.7.0 para a 1.7.x, seu cluster pode ficar parado no upgrade do nó do plano de controle. Talvez você veja MACHINE-IP-machine-upgrade jobs sendo executados e falham periodicamente. Esse problema afeta clusters 1.7.0 que têm:

  • Docker pré-instalado nos nós do plano de controle.
  • containerd selecionado como o ambiente de execução.

Esse problema é causado por clusters do Anthos em configurações bare metal desconfiguradas do cri-socket para o Docker em vez de containerd. Para resolver esse problema, defina as credenciais de pull de imagem para o Docker:

  1. Faça login no Docker:

    docker login gcr.io
    

    Isso cria um arquivo $HOME/.docker/config.json.

  2. Liste os endereços IP de todos os nós do plano de controle, separados por um espaço:

    IPs=(NODE_IP1 NODE_IP2 ...)
    
  3. Copie a configuração do Docker para os nós:

    for ip in "${IPs[@]}"; do
      scp $HOME/.docker/config.json USER_NAME@{ip}:docker-config.json
    

    Substitua USER_NAME pelo nome de usuário configurado no arquivo de configuração do cluster de administrador.

  4. Defina as credenciais de extração de imagem para o Docker:

    ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"
    

O driver do grupo de controle está configurado incorretamente para cgroupfs

Se você tiver problemas relacionados ao driver do grupo de controle (cgroup), isso pode ser causado por clusters do Anthos em bare metal que o configuram incorretamente para cgroupfs em vez de systemd.

Para corrigir esse problema:

  1. Faça login nas máquinas e abra /etc/containerd/config.toml.

  2. Em [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options], adicione SystemdCgroup = true:

    ...
       [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
         [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
           runtime_type = "io.containerd.runc.v2"
           runtime_engine = ""
           runtime_root = ""
           privileged_without_host_devices = false
           base_runtime_spec = ""
           [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
             SystemdCgroup = true
     [plugins."io.containerd.grpc.v1.cri".cni]
       bin_dir = "/opt/cni/bin"
       conf_dir = "/etc/cni/net.d"
       max_conf_num = 1
       conf_template = ""
    ...
    
  3. Salve as alterações e feche o arquivo.

  4. Abra /etc/systemd/system/kubelet.service.d/10-kubeadm.conf.

  5. No final do arquivo, adicione --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service:

    [Service]
    Environment="HOME=/root"
    Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
    Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
    # This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
    EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
    # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
    # the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
    EnvironmentFile=-/etc/default/kubelet
    ExecStart=
    ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service
    
  6. Salve as alterações e reinicie o servidor.

  7. Verifique se systemd é o driver do grupo de controle executando:

    systemd-cgls
    

    Verifique se há uma seção kubepods.slice e se todos os pods estão nessa seção.

Redefinir/excluir

Suporte ao cluster de usuário

Não é possível redefinir clusters de usuário com o comando bmctl reset.

Pontos de montagem e fstab

A redefinição não desconecta os pontos de montagem em /mnt/localpv-share/ e 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.

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

Geração de registros e monitoramento

Os registros de nós não são exportados para o Cloud Logging

Os registros de nós de nós com um ponto (".") no nome não são exportados para o Cloud Logging. Como solução alternativa, use as instruções a seguir para adicionar um filtro ao recurso stackdriver-log-forwarder-config e permitir que o Stackdriver Operator reconheça e exporte esses registros.

  1. Reduza o tamanho do operador do Stackdriver, stackdriver-operator:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system scale \
        deploy stackdriver-operator --replicas=0
    
  2. Edite o configmap do encaminhador de registro, stackdriver-log-forwarder-config:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system edit configmap \
        stackdriver-log-forwarder-config
    
  3. Adicione o seguinte filtro ao final da seção input-systemd.conf do configmap:

       [FILTER]
           Name    lua
           Match_Regex   container-runtime|kubelet|node-problem-detector|node-journal
           script  replace_dot.lua
           call    replace
    
     replace_dot.lua: |
       function replace(tag, timestamp, record)
           new_record = record
    
           local local_resource_id_key = "logging.googleapis.com/local_resource_id"
    
           -- Locate the local_resource_id
           local local_resource_id = record[local_resource_id_key]
    
           local first = 1
           local new_local_resource_id = ""
           for s in string.gmatch(local_resource_id, "[^.]+") do
               new_local_resource_id = new_local_resource_id .. s
               if first == 1 then
                   new_local_resource_id = new_local_resource_id .. "."
                   first = 0
               else
                   new_local_resource_id = new_local_resource_id .. "_"
               end
           end
    
           -- Remove the trailing underscore
           new_local_resource_id = new_local_resource_id:sub(1, -2)
           new_record[local_resource_id_key] = new_local_resource_id
           return 1, timestamp, new_record
       end
    
  4. Exclua todos os pods do encaminhador de registro:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch daemonset \
        stackdriver-log-forwarder -p \
        '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    

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

  5. Implante um daemonset para limpar todos os dados corrompidos e não processados em buffers em fluent-bit:

    kubectl --kubeconfig ADMIN_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
    
  6. Verifique se o daemonset limpou todos os nós com os comandos a seguir.

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

    A saída dos dois comandos precisa ser igual ao número do nó no cluster

  7. Exclua o daemonset de limpeza:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system delete ds fluent-bit-cleanup
    
  8. Reinicie os pods:

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch \
        daemonset stackdriver-log-forwarder --type json \
        -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    

Rede

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

Ao executar clusters do Anthos no Bare Metal com firewalld ativado no CentOS ou 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.

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 é 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; não é uma limitaçã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

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.