Container Service for Kubernetes:Node pool FAQ

Índice

Para diagnosticar e solucionar problemas em nós, consulte Solução de problemas de anomalias em nós .

Como usar instâncias spot em um pool de nós?

Posso configurar diferentes tipos de instância ECS em um único pool de nós?

Sim, é possível. Para evitar falhas de scale-out causadas por indisponibilidade de instâncias ou falta de estoque, recomendamos as seguintes estratégias:

• Configure vários vSwitches para um pool de nós em diferentes zonas de disponibilidade.

• Selecione múltiplos tipos de instância Elastic Compute Service (ECS) ou especifique o tipo de instância com base nas especificações de vCPU e memória. Após a criação, visualize o nível de escalabilidade de um pool de nós.

Para tipos de instância não suportados e recomendações de configuração de nós, consulte Recomendações de configuração de tipos de instância ECS .

Como calcular o número máximo de pods por nó?

O número máximo de pods suportados por nó depende do plugin de rede utilizado pelo cluster. Para métodos detalhados de cálculo, consulte Número máximo de pods por nó.

• Terway: Max pods per node = Maximum Elastic Network Interface (ENI)-based pods + Host network pods.

• Flannel: O limite é definido pelo campo Number of Pods per Node especificado durante a criação do cluster.

Visualize o número máximo de pods, que corresponde à Cota de Pods , na lista de nós na página Nodes do console ACK.

Como ajustar a capacidade de pods quando um nó atinge seu limite?

O número máximo de pods suportados por um único nó worker é determinado pelo tipo de plugin de rede e, na maioria dos casos, é imutável.

• Modo Terway: O máximo de pods por nó depende do número de ENIs fornecidas pela instância ECS.

• Modo Flannel: O máximo de pods por nó é definido durante a criação do cluster e não pode ser modificado posteriormente.

Se a contagem de pods no seu cluster atingir o limite, recomendamos o scale-out do pool de nós para adicionar mais nós, aumentando assim a capacidade total de pods disponíveis no cluster. Para mais informações, consulte Ajustar pods disponíveis por nó.

Como modificar as configurações de um nó?

Para garantir a estabilidade do cluster, certos parâmetros — especificamente aqueles relacionados a redes e alta disponibilidade — são imutáveis após a criação do pool de nós. Por exemplo, não é possível alterar o runtime de contêineres ou a Virtual Private Cloud (VPC) à qual um nó pertence.

Para parâmetros mutáveis, as alterações geralmente se aplicam apenas a nós recém-criados. Os nós existentes permanecem inalterados, salvo indicação em contrário (como Update ECS Tags of Existing Nodes e Update Labels and Taints of Existing Nodes).

Melhores práticas para aplicar novas configurações: Para aplicar novas definições aos nós existentes, siga estas etapas:

1. Crie um novo pool de nós com a configuração desejada.

2. Isole e drene os nós do pool antigo para migrar as cargas de trabalho para os novos nós.

3. Após concluir a migração, libere as instâncias do pool de nós antigo.

Para mais informações sobre quais parâmetros podem ser modificados e quando as alterações entram em vigor, consulte Editar um pool de nós.

Posso desativar o recurso Expected Nodes?

Se o Scaling Mode de um pool de nós estiver definido como Manual, o parâmetro Expected Nodes é obrigatório e não pode ser desativado.

Para remover ou liberar um nó específico, consulte Remover um nó de um cluster ou pool de nós. Para adicionar um nó específico, consulte Adicionar um nó existente. Após remover um nó ou adicionar um nó existente, o número esperado de instâncias é ajustado automaticamente para a nova quantidade de nós. Não é necessário alterá-lo manualmente.

Qual é a diferença entre um pool de nós com e sem o recurso Expected Nodes ativado?

O parâmetro Expected Nodes define a capacidade pretendida de um pool de nós. Ajustando esse parâmetro, você realiza o scale-out ou scale-in do pool. Embora a maioria dos pools modernos utilize esse recurso para reconciliação e dimensionamento, alguns pools legados podem não tê-lo ativado.

A tabela a seguir descreve como o sistema responde a diferentes operações com base nessa configuração:

Como adicionar nós livres a um pool de nós?

Nós workers criados em clusters legados, antes da introdução do recurso de pool de nós, são considerados nós livres. Caso não precise mais deles, libere as instâncias ECS correspondentes. Caso contrário, para aproveitar o gerenciamento em grupo e a O&M automatizada, recomendamos migrá-los para um pool de nós.

Crie um novo pool de nós ou expanda um existente, remova os nós livres do cluster e adicione-os ao pool de destino. Para detalhes, consulte Migrar nós não gerenciados para um pool de nós.

Como alterar a imagem de SO de um pool de nós?

Troque o SO conforme necessário. Por exemplo, de CentOS para Alibaba Cloud Linux ou atualize para uma versão mais recente do SO atual. Antes de prosseguir, revise as Notas de lançamento de imagens de SO para verificar compatibilidade e limites de uso.

Para instruções passo a passo, consulte Substituir o SO de um pool de nós.

Como liberar uma instância ECS específica?

Para liberar uma instância ECS específica, remova o nó pelo console ACK. Isso garante que a contagem de Expected Nodes seja atualizada automática e corretamente, sem intervenção manual. Apenas diminuir a contagem de Expected Nodes acionará um scale-in aleatório, que pode não atingir a instância específica que você pretende liberar.

Como corrigir tempos limite na adição de nós?

Verifique a conectividade de rede entre o nó e o API Server CLB. Primeiro, confirme se o grupo de segurança atende aos requisitos. Para limitações de grupos de segurança ao adicionar um nó existente, consulte Limitações. Para outros problemas de conectividade de rede, consulte Perguntas frequentes sobre gerenciamento de rede.

Como alterar o nome de host de um nó worker em um cluster ACK?

Em seguida, execute o seguinte:

1. Remova o nó do cluster.

2. Adicione o nó removido de volta ao pool de nós. Para instruções, consulte Adicionar nós manualmente.

   O nó será renomeado automaticamente ao reingressar no cluster, com base no modelo de nomenclatura do pool de nós.

Como atualizar manualmente o kernel e os drivers NVIDIA em nós GPU?

1. Conecte-se ao cluster: Obtenha o kubeconfig do cluster e use kubectl para conectar-se ao cluster.

2. Isole o nó: Impeça que novos pods sejam agendados no nó GPU de destino. Este exemplo usa o nó cn-beijing.i-2ze19qyi8votgjz*****.

   kubectl cordon cn-beijing.i-2ze19qyi8votgjz*****
   
   node/cn-beijing.i-2ze19qyi8votgjz***** already cordoned

3. Drene o nó: Evacue os pods existentes para outros nós.

   kubectl drain cn-beijing.i-2ze19qyi8votgjz***** --grace-period=120 --ignore-daemonsets=true
   
   node/cn-beijing.i-2ze19qyi8votgjz***** cordoned
   WARNING: Ignoring DaemonSet-managed pods: flexvolume-9scb4, kube-flannel-ds-r2qmh, kube-proxy-worker-l62sf, logtail-ds-f9vbg
   pod/nginx-ingress-controller-78d847fb96-***** evicted

4. Desinstale o driver NVIDIA atual:

   Nota

   Este exemplo usa a versão 384.111. Substitua pela sua versão real.

   1. Faça login no nó GPU e execute o comando nvidia-smi para verificar a versão do driver.

      sudo nvidia-smi -a | grep 'Driver Version'
      Driver Version                      : 384.111

   2. Baixe o instalador correspondente da NVIDIA para realizar a desinstalação.

      cd /tmp/
      sudo curl -O https://cn.download.nvidia.cn/tesla/384.111/NVIDIA-Linux-x86_64-384.111.run

      Nota

      Você deve usar o pacote de instalação para desinstalar o driver NVIDIA.

   3. Desinstale o driver NVIDIA atual.

      sudo chmod u+x NVIDIA-Linux-x86_64-384.111.run
      sudo sh ./NVIDIA-Linux-x86_64-384.111.run --uninstall -a -s -q

5. Atualize o kernel.

   Atualize o kernel conforme necessário.

6. Reinicie o nó GPU.

   sudo reboot

7. Instale os cabeçalhos do kernel: Faça login novamente no nó GPU e instale o kernel-devel correspondente.

   sudo yum install -y kernel-devel-$(uname -r)

8. Instale o novo driver NVIDIA: Acesse o site da NVIDIA para baixar e instalar o driver necessário. Este exemplo usa a versão 410.79.

   # Change directory to /tmp
   cd /tmp/
   
   # Download the NVIDIA driver installer
   sudo curl -O https://cn.download.nvidia.cn/tesla/410.79/NVIDIA-Linux-x86_64-410.79.run
   
   # Make the installer executable
   sudo chmod u+x NVIDIA-Linux-x86_64-410.79.run
   
   # Run the installer in silent mode
   sudo sh ./NVIDIA-Linux-x86_64-410.79.run -a -s -q
   
   # Warm up the GPU
   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

9. Configure o modo de persistência: Garanta que as seguintes configurações de aquecimento da GPU estejam em /etc/rc.d/rc.local. Adicione-as manualmente, se necessário.

   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

10. Reinicie os serviços:

    sudo service kubelet stop
    sudo service docker restart
    sudo service kubelet start

11. Libere o nó GPU:

    kubectl uncordon cn-beijing.i-2ze19qyi8votgjz*****
    
    node/cn-beijing.i-2ze19qyi8votgjz***** already uncordoned

12. Verifique: Execute nvidia-smi dentro do pod nvidia-device-plugin para confirmar a versão.

    kubectl exec -n kube-system -t nvidia-device-plugin-cn-beijing.i-2ze19qyi8votgjz***** nvidia-smi
    Thu Jan 17 00:33:27 2019
    +-----------------------------------------------------------------------------+
    | NVIDIA-SMI 410.79       Driver Version: 410.79       CUDA Version: N/A      |
    |-------------------------------+----------------------+----------------------+
    | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
    |===============================+======================+======================|
    |   0  Tesla P100-PCIE...  On   | 00000000:00:09.0 Off |                    0 |
    | N/A   27C    P0    28W / 250W |      0MiB / 16280MiB |      0%      Default |
    +-------------------------------+----------------------+----------------------+
    
    +-----------------------------------------------------------------------------+
    | Processes:                                                       GPU Memory |
    |  GPU       PID   Type   Process name                             Usage      |
    |=============================================================================|
    |  No running processes found                                                 |
    +-----------------------------------------------------------------------------+

    Nota

    Se você executar o comando docker ps e constatar que nenhum contêiner foi iniciado no nó GPU, consulte Corrigir falhas de inicialização de contêineres em nós GPU.

Corrigir falhas de inicialização de contêineres em nós GPU

sudo service kubelet stop
# Redirecting to /bin/systemctl stop kubelet.service
sudo service docker stop
# Redirecting to /bin/systemctl stop docker.service
sudo service docker start
# Redirecting to /bin/systemctl start docker.service
sudo service kubelet start
# Redirecting to /bin/systemctl start kubelet.service

sudo docker ps
# Output: CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

sudo docker info | grep -i cgroup

Cgroup Driver: cgroupfs

Solução

1. Atualize a configuração do Docker: Alinhe o Cgroup Driver com systemd e garanta que o runtime de contêineres NVIDIA esteja definido como padrão.

   1. Faça backup da configuração existente (arquivo /etc/docker/daemon.json).

   2. Aplique a configuração corrigida: Execute o comando a seguir para sobrescrever o /etc/docker/daemon.json com as configurações necessárias.

      sudo cat >/etc/docker/daemon.json <<-EOF
      {
          "default-runtime": "nvidia",
          "runtimes": {
              "nvidia": {
                  "path": "/usr/bin/nvidia-container-runtime",
                  "runtimeArgs": []
              }
          },
          "exec-opts": ["native.cgroupdriver=systemd"],
          "log-driver": "json-file",
          "log-opts": {
              "max-size": "100m",
              "max-file": "10"
          },
          "oom-score-adjust": -1000,
          "storage-driver": "overlay2",
          "storage-opts":["overlay2.override_kernel_check=true"],
          "live-restore": true
      }
      EOF

2. Reinicie os serviços para que as alterações entrem em vigor.

   sudo service kubelet stop
   # Redirecting to /bin/systemctl stop kubelet.service
   sudo service docker restart
   # Redirecting to /bin/systemctl restart docker.service
   sudo service kubelet start
   # Redirecting to /bin/systemctl start kubelet.service

3. Confirme se o Cgroup Driver foi alternado com sucesso para systemd.

   sudo docker info | grep -i cgroup
   Cgroup Driver: systemd

Quando um nó falha, como migrar pods em lote para reimplantação?

Defina o nó com falha como não agendável e drene-o para mover os pods de aplicação para nós íntegros.

1. Faça login no console ACK.

2. Na página Nodes, localize o nó que deseja gerenciar. Na coluna Actions, escolha More > Drain. Esta operação define o nó antigo como não agendável e migra gradualmente as aplicações do nó antigo para um novo nó.

3. Solucione o problema do nó com falha. Para detalhes de solução de problemas, consulte Solucionar problemas de nós.

Se um cluster com nós em várias zonas falhar, como ele determina a política de evicção de nós?

Normalmente, quando um nó falha, o controlador de nós remove os pods do nó não íntegro. A taxa padrão de evicção --node-eviction-rate é de 0,1 nós por segundo. Isso significa que, no máximo, um pod é removido de um nó a cada 10 segundos.

No entanto, quando um cluster ACK com nós em múltiplas zonas falha, o controlador de nós determina a política de evicção com base na integridade da zona e no tamanho do cluster.

Existem três tipos de estado de integridade da zona.

• FullDisruption: A zona não possui nós íntegros e tem pelo menos um nó não íntegro.

• PartialDisruption: A zona tem pelo menos dois nós não íntegros, e a proporção de nós não íntegros, calculada como (Number of unhealthy nodes / (Number of unhealthy nodes + Number of healthy nodes)), é maior que 0,55.

• Normal: Nenhum dos anteriores.

A taxa de evicção do controlador de nós é calculada da seguinte forma, com base nos três estados de integridade da zona:

• Se todas as zonas estiverem no estado FullDisruption, o recurso de evicção é desativado para todo o cluster.

• Se algumas zonas estiverem no estado FullDisruption, a taxa de evicção é definida para o valor normal (0,1), independentemente do tamanho do cluster.

• Se uma zona estiver no estado PartialDisruption, a taxa de evicção será afetada pelo tamanho do cluster.

  • Clusters grandes (>50 nós): A taxa de evicção cai para 0,01/s.

  • Clusters pequenos (≤50 nós): A taxa de evicção para a zona é 0, o que significa que nenhuma evicção ocorre.

• Se uma zona estiver no estado Normal, a taxa de evicção é definida para o valor normal (0,1), independentemente do tamanho do cluster.

Para mais informações, consulte Limites de taxa de evicção.

Posso personalizar o caminho do diretório do kubelet?

Não. O caminho do kubelet é fixo em /var/lib/kubelet e não pode ser personalizado no ACK.

Posso montar um disco de dados em um diretório personalizado em um pool de nós ACK?

Este recurso está atualmente em lançamento canário. Para solicitar este recurso, abra um ticket.

Uma vez ativado, você pode formatar e montar discos em caminhos específicos, com as seguintes restrições:

• Não monte nos seguintes diretórios reservados do SO:

  • /

  • /etc

  • /var/run

  • /run

  • /boot

• Não monte nos seguintes diretórios usados pelo sistema e runtimes de contêineres, ou em seus subdiretórios:

  • /usr

  • /bin

  • /sbin

  • /lib

  • /lib64

  • /ostree

  • /sysroot

  • /proc

  • /sys

  • /dev

  • /var/lib/kubelet

  • /var/lib/docker

  • /var/lib/containerd

  • /var/lib/container

• Os diretórios de montagem para diferentes discos de dados devem ser únicos.

• O diretório de montagem deve ser um caminho absoluto começando com /.

• O diretório de montagem não pode conter caracteres de retorno de carro ou nova linha (caracteres de escape estilo C \r e \n) e não pode terminar com uma barra invertida (\).

Como modificar o número máximo de descritores de arquivos?

O número máximo de descritores de arquivos é a quantidade máxima de arquivos que podem ser abertos simultaneamente. Sistemas Alibaba Cloud Linux e CentOS possuem dois níveis de limites:

• Nível de sistema: O número máximo de arquivos que podem ser abertos simultaneamente pelos processos de todos os usuários.

• Nível de usuário: O número máximo de arquivos que podem ser abertos pelos processos de um único usuário.

Em um ambiente de contêineres, existe outro limite: o número máximo de descritores de arquivos para um único processo dentro de um contêiner.

Nota

Alterações manuais feitas via CLI podem ser sobrescritas durante upgrades do pool de nós. Recomendamos editar o pool de nós no console para configurações persistentes.

Modificar limite de nível de sistema

Consulte Personalizar parâmetros de SO para um pool de nós.

Modificar limite de nível de usuário

1. Faça login no nó e verifique o arquivo /etc/security/limits.conf.

   cat /etc/security/limits.conf

   O máximo de descritores de arquivos para processos individuais de usuário é definido pelos seguintes parâmetros:

   ...
   root soft nofile 65535
   root hard nofile 65535
   * soft nofile 65535
   * hard nofile 65535

2. Execute o comando sed para modificar o limite de descritores de arquivos. O exemplo a seguir define o valor como 65535 (recomendado):

   sed -i "s/nofile.[0-9]*$/nofile 65535/g" /etc/security/limits.conf

3. Faça login novamente no nó e execute o seguinte comando para verificar se a modificação teve efeito.

   # ulimit -n

   Se a saída corresponder ao valor configurado (ex.: 65535), a modificação foi bem-sucedida.

Modificar limite de nível de contêiner

Importante

Isso requer reiniciar o serviço Docker ou containerd, o que interromperá os contêineres em execução. Execute esta operação fora do horário de pico.

1. Faça login no nó e execute o seguinte comando para visualizar o arquivo de configuração.

   • Nó containerd: cat /etc/systemd/system/containerd.service

   • Nó Docker: cat /etc/systemd/system/docker.service

   O limite de descritores de arquivos para um único processo em um contêiner é definido pelos seguintes parâmetros:

   ...
   LimitNOFILE=1048576   ******Maximum number of file handles for a single process
   LimitNPROC=1048576    ******Maximum number of processes
   ...

2. Execute o seguinte comando para modificar os valores dos parâmetros. 1048576 é o valor recomendado para o limite de descritores de arquivos.

   • Nó containerd:

      sed -i "s/LimitNOFILE=[0-9a-Z]*$/LimitNOFILE=65536/g" /etc/systemd/system/containerd.service;sed -i "s/LimitNPROC=[0-9a-Z]*$/LimitNPROC=65537/g" /etc/systemd/system/containerd.service && systemctl daemon-reload && systemctl restart containerd

   • Nó Docker:

     sed -i "s/LimitNOFILE=[0-9a-zA-Z]*$/LimitNOFILE=1048576/g" /etc/systemd/system/docker.service && sed -i "s/LimitNPROC=[0-9a-zA-Z]*$/LimitNPROC=1048576/g" /etc/systemd/system/docker.service && systemctl daemon-reload && systemctl restart docker

3. Execute o seguinte comando para visualizar o limite de descritores de arquivos para um único processo em um contêiner.

   Se o valor retornado for igual ao valor definido, a modificação foi bem-sucedida.

   • Nó containerd:

     # cat /proc/`pidof containerd`/limits | grep files
     Max open files            1048576              1048576              files

   • Nó Docker:

     # cat /proc/`pidof dockerd`/limits | grep files
     Max open files            1048576              1048576              files

Como atualizar o runtime de contêineres para nós workers que não pertencem a um pool de nós?

Em clusters legados criados antes da introdução do recurso de pool de nós, podem existir nós workers livres. Para atualizar o runtime de contêineres desses nós, você deve primeiro migrá-los para um pool de nós.

Procedimento:

1. Crie um pool de nós: Se não existir um pool adequado, crie um com a mesma configuração do nó livre.

2. Remova o nó: Durante o processo de remoção, o sistema define o nó como não agendável e o drena. Se a drenagem falhar, o sistema automaticamente isola o nó (define como não agendável) e executa uma operação de drenagem para evacuar os pods. Se a drenagem for bem-sucedida, o nó é removido do cluster.

3. Adicione um nó existente: Adicione o nó de destino a um pool de nós existente. Quando o nó reingressar no cluster, seu runtime de contêineres será atualizado automaticamente para corresponder ao runtime especificado na configuração do pool de nós.

   Nota

   Embora o recurso de pool de nós seja gratuito, você será cobrado pelas instâncias ECS subjacentes e outros recursos de nuvem. Para detalhes, consulte Custos de recursos de nuvem.

Por que o console exibe a origem de um pool de nós como Other Nodes?

O ACK permite adicionar recursos de computação via console, OpenAPI ou CLI (consulte Adicionar um nó existente). Se você adicionar nós através de métodos personalizados não reconhecidos pelo gerenciamento de ciclo de vida padrão do ACK, o console os classificará no grupo Other Nodes.

O ACK não consegue gerenciar esses nós através de um pool de nós, o que significa que recursos como O&M automatizada, gerenciamento de ciclo de vida e suporte técnico garantido ficam indisponíveis.

Se desejar continuar usando esses nós, você deve garantir sua compatibilidade com os add-ons do cluster e assumir os riscos potenciais. Esses riscos incluem, mas não se limitam a:

• Incompatibilidade de versão: Durante upgrades do plano de controle ou componentes do sistema, o SO e os componentes residentes nesses nós podem tornar-se incompatíveis com a nova versão, arriscando interrupção do serviço.

• Conflitos de agendamento: O cluster pode falhar ao relatar com precisão as zonas de disponibilidade ou a capacidade restante de recursos para esses nós. Isso pode levar a um agendamento inadequado de cargas de trabalho e degradação de desempenho.

• Incompatibilidades no plano de dados: A compatibilidade entre componentes/SO do lado do nó e o plano de controle do cluster não foi validada, representando riscos de estabilidade.

• Falhas de O&M: Operações de manutenção realizadas via console ACK ou OpenAPI podem falhar ou gerar resultados inesperados porque o canal de gerenciamento subjacente para esses nós não é verificado.

Como configurar ACLs de rede para os vSwitches usados pelos nós do cluster?

Se uma lista de controle de acesso (ACL) estiver associada ao vSwitch de um pool de nós, você deve permitir explicitamente blocos CIDR específicos. Caso contrário, novos nós falharão ao ingressar no cluster ou aparecerão com status Failed ou Offline.

Procedimento para permitir tráfego e readicionar nós:

1. Configure regras de ACL de rede: Garanta que as regras de entrada (inbound) e saída (outbound) permitam tráfego para os seguintes blocos CIDR:

   • 100.104.0.0/16: CIDR de gerenciamento do plano de controle ACK.

   • 100.64.0.0/10: CIDR de serviço interno da Alibaba Cloud.

   • 100.100.100.200/32: Endereço do serviço de metadados ECS.

   • CIDR da VPC/vSwitch: Os blocos CIDR primário e secundário da VPC, ou o CIDR específico do vSwitch do nó.

2. Remova nós com falha: Remova quaisquer nós que estavam com status Failed ou Offline antes da aplicação das regras de ACL.

3. Crie um pool de nós ou expanda um pool existente: Se o status do nó mudar para Ready, as regras de ACL de rede foram configuradas corretamente.