Container Service for Kubernetes:Node and node pool FAQ

Índice

Para diagnosticar e solucionar problemas em nós, consulte Troubleshoot abnormal nodes .

Uso de instâncias spot em um node pool

Múltiplos tipos de instância ECS por node pool

Sim, é possível. Recomendamos configurar o node pool com múltiplos tipos de instância ECS para evitar falhas de expansão de nós causadas por indisponibilidade ou falta de estoque de determinado tipo de instância. Para isso, configure múltiplos vSwitches em várias zonas de disponibilidade, selecione múltiplos tipos de instância ECS ou especifique tipos de instância com base em vCPU e memória. Após criar o node pool, adicione tipos de instância com base nas recomendações de nível de escalabilidade exibidas no console ou em view the scalability level of a node pool.

Para consultar a lista de tipos de instância suportados e recomendações de configuração de nós, acesse ECS instance type configuration recommendations .

Número máximo de pods por nó

O cálculo do número máximo de pods por nó depende do plugin de rede do cluster. Para mais informações, consulte Maximum number of Pods per node.

• Terway: O número máximo de pods por nó é a soma dos pods na rede de contêiner e na rede do host.

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

O número máximo de pods por nó, também conhecido como Pod Quota , pode ser visualizado na página Nodes Nodes do console.

Não é possível alterar o número máximo de pods por nó após criar um cluster. Se um nó atingir esse limite, expanda seus nós para aumentar a capacidade de pods. Para mais informações, consulte Adjust available Pods on a node.

Ajuste da capacidade de pods por nó

O plugin de rede determina o número máximo de pods que um nó worker pode suportar, e esse limite geralmente não pode ser alterado. No modo Terway, o limite depende da quantidade de interfaces de rede elásticas (ENIs) fornecidas pela instância ECS. No modo Flannel, o limite é definido na criação do cluster e não pode ser modificado posteriormente. Ao atingir o limite de pods, recomendamos adicionar nós ao node pool para aumentar o total de pods disponíveis.

Para mais informações, consulte Increase the maximum number of pods in a cluster.

Modificar a configuração de nós

• Para garantir a estabilidade do service, determinados parâmetros — especificamente os relacionados à disponibilidade e à rede — são imutáveis após a criação de um node pool. Por exemplo, não é possível alterar o runtime de contêiner nem a VPC à qual um nó pertence.

• Para parâmetros mutáveis, as alterações na configuração do node pool se aplicam apenas a novos nós. Os nós existentes não são afetados, a menos que você use opções específicas, como Update ECS Tags of Existing Nodes ou Update Labels and Taints of Existing Nodes.

Consulte Create and manage node pools para obter detalhes sobre os parâmetros modificáveis e quando as alterações entram em vigor.

Como alternativa, para aplicar uma nova configuração, crie um novo node pool com a configuração desejada. Em seguida, cordon e drene os nós do node pool antigo para migrar as cargas de trabalho. Após concluir a migração, libere as instâncias do node pool antigo. Para instruções detalhadas, consulte Cordon and drain nodes.

É possível desativar o Expected Nodes?

Quando o Scaling Mode de um node pool está definido como Manual, é obrigatório configurar o Expected Nodes. Esse recurso não pode ser desativado.

Para remover um nó específico, consulte Remove a node. Para adicionar um nó específico, consulte add an existing node. Após remove a node ou add an existing node, o Expected Nodes é atualizado automaticamente para o novo número de nós, sem necessidade de alteração manual.

Node pools com e sem Expected Nodes

O parâmetro Expected Nodes define a capacidade pretendida de um node pool. Ajuste esse valor para expandir ou reduzir o node pool. No entanto, alguns node pools mais antigos podem não ter esse recurso ativado.

A tabela a seguir descreve como o sistema responde a operações em node pools com e sem o recurso Expected Nodes ativado.

Migrar nós não gerenciados para um node pool

Em clusters ACK mais antigos criados antes do lançamento do recurso de node pool, alguns nós worker podem não pertencer a nenhum node pool. Para submeter esses nós não gerenciados ao gerenciamento agrupado e à manutenção automatizada, migre-os para um node pool: crie um node pool, remova os nós não gerenciados do cluster e adicione novamente as instâncias ECS correspondentes ao node pool.

Para isso, crie um novo node pool ou expanda um existente, remova os nós não gerenciados do cluster e adicione-os ao node pool de destino. Para mais informações, consulte Migrate unmanaged nodes to a node pool.

Substituir a imagem do sistema operacional de um node pool

É possível substituir o sistema operacional de um node pool, por exemplo, para migrar de uma versão que atingiu o fim da vida útil (EOL) para uma versão suportada. Antes de começar, consulte OS image release notes para verificar os sistemas operacionais suportados, as versões de imagem mais recentes e as limitações de uso.

Consulte Replace the OS of a node pool para instruções detalhadas e considerações importantes.

Liberar uma instância ECS específica

Para liberar uma instância ECS específica, consulte remove the node. Essa ação atualiza automaticamente a contagem de nós esperada. Não tente liberar uma instância específica alterando a contagem de nós esperada, pois isso aciona uma redução de escala aleatória e não garante a remoção da instância desejada.

Como corrigir timeouts 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 saber as limitações do grupo de segurança ao adicionar um nó existente, consulte Limitations. Para outros problemas de conectividade de rede, consulte Network management FAQ.

Alterar hostnames de nós worker

1. Remova o nó. Para mais informações, consulte Remove a node.

2. Adicione novamente o nó removido ao node pool. Para mais informações, consulte Manually add nodes.

   O nó é renomeado automaticamente de acordo com a regra de nomenclatura do node pool.

Atualizar manualmente o kernel de um nó GPU

1. Obtain a cluster's kubeconfig and connect with kubectl.

2. Aplique cordon no nó GPU (por exemplo, node cn-beijing.i-2ze19qyi8votgjz*, para impedir o agendamento de novos pods).

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

3. Drene o nó GPU no qual você deseja atualizar o driver.

   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

   O pacote de driver desinstalado nesta etapa é a versão 384.111. Se sua versão do driver não for 384.111, baixe o instalador correspondente no site oficial da NVIDIA e substitua 384.111 nesta etapa pela sua versão real.

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

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

   2. Baixe o instalador do driver NVIDIA.

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

      Nota

      É obrigatório usar o instalador 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.

   Siga os procedimentos do seu sistema operacional para atualizar o kernel.

6. Reinicie a instância GPU.

   sudo reboot

7. Faça login novamente no nó GPU e instale o kernel devel correspondente.

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

8. Acesse o site oficial da NVIDIA para baixar e instalar o driver NVIDIA necessário. Este tópico usa a versão 410.79 como exemplo.

   # Change to the /tmp directory.
   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
   
   # Add executable permissions to the installer.
   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. Verifique o arquivo /etc/rc.d/rc.local para confirmar se ele contém a configuração a seguir. Caso contrário, adicione-a manualmente.

   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 o kubelet e o Docker.

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

11. Remova o cordon do nó GPU para permitir que pods sejam agendados nele novamente.

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

12. Verifique a versão do pod do device plugin no nó GPU.

    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 ao executar o comando docker ps você verificar que nenhum contêiner está iniciado no nó GPU, consulte Fix GPU node container startup issues.

Corrigir a 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
# CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

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

Para corrigir esse problema, altere o Cgroup Driver do Docker para systemd.

1. Faça backup de /etc/docker/daemon.json e execute o comando a seguir para atualizar /etc/docker/daemon.json.

   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 o Docker e o kubelet para aplicar as alterações.

   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 que o Cgroup Driver do Docker está definido como systemd.

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

Migrar pods de um nó com falha

Para migrar pods de aplicações de um nó com falha, marque o nó como não agendável e drene-o. Esse processo remove os pods com segurança e os reagenda em nós saudáveis.

1. Faça login no ACK console. Na página Nodes, localize o nó com falha. Na coluna Actions, escolha More > Drain.

2. Solucione o problema no nó com falha. Para mais informações, consulte Troubleshoot node issues.

Política de despejo de nós durante falhas em zonas de disponibilidade

Quando um nó se torna não saudável, o controlador de nós inicia o despejo. A taxa de despejo padrão é de 0,1 nós por segundo, controlada pelo parâmetro --node-eviction-rate. Isso significa que os Pods são despejados de, no máximo, um nó a cada 10 segundos.

No entanto, em um cluster ACK com nós distribuídos em múltiplas zonas de disponibilidade, o controlador de nós ajusta essa política com base no status de integridade de cada zona de disponibilidade e no tamanho do cluster.

Uma zona de disponibilidade pode estar em um dos três estados de integridade a seguir.

• FullDisruption: A zona de disponibilidade não possui nós saudáveis e tem pelo menos um nó não saudável.

• PartialDisruption: A zona de disponibilidade contém pelo menos dois nós não saudáveis, e a proporção de nós não saudáveis em relação ao total de nós (calculada como (unhealthy nodes / (unhealthy nodes + healthy nodes))) ultrapassa 0,55.

• Normal: A zona de disponibilidade não atende aos critérios de FullDisruption nem de PartialDisruption.

Os clusters também são classificados por tamanho:

• Large cluster: Um cluster com mais de 50 nós.

• Small cluster: Um cluster com 50 nós ou menos.

O controlador de nós determina a taxa de despejo com base nesses estados:

• Se todas as zonas de disponibilidade estiverem no estado FullDisruption, o despejo é desabilitado para todo o cluster.

• Se pelo menos uma zona de disponibilidade não estiver no estado FullDisruption, a taxa de despejo é determinada da seguinte forma:

  • Para uma zona de disponibilidade no estado FullDisruption, a taxa de despejo é definida no valor padrão de 0,1 nós por segundo, independentemente do tamanho do cluster.

  • Para uma zona de disponibilidade no estado PartialDisruption, a taxa de despejo depende do tamanho do cluster. Em um large cluster, a taxa é reduzida para 0,01 nós por segundo. Em um small cluster, a taxa é definida como 0, desabilitando o despejo.

  • Para uma zona de disponibilidade no estado Normal, a taxa de despejo é definida no valor padrão de 0,1 nós por segundo, independentemente do tamanho do cluster.

Para mais informações, consulte Rate limits on eviction.

Personalização do caminho do kubelet

Não. O caminho do kubelet em um cluster ACK é /var/lib/kubelet e não pode ser alterado. Não modifique esse caminho.

Montar um disco de dados em um diretório personalizado

Este recurso está atualmente em canary release. Para ativá-lo, abra um ticket. Após a ativação, o sistema formata e monta automaticamente qualquer disco de dados adicionado ao node pool em um diretório especificado. O diretório de montagem possui as seguintes restrições.

• Não monte um disco de dados nos seguintes diretórios críticos do sistema operacional:

  • /

  • /etc

  • /var/run

  • /run

  • /boot

• Não monte um disco de dados nos seguintes diretórios usados pelo sistema e pelos runtimes de contêiner, nem 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

• Cada disco de dados deve ter um diretório de montagem exclusivo.

• O diretório de montagem deve ser um caminho absoluto que comece com /.

• O diretório de montagem não deve conter caracteres de retorno de carro ou avanço de linha (\r e \n) nem terminar com uma barra invertida (\).

Modificar os limites de descritores de arquivo

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

• Nível do sistema: o número máximo de arquivos que todos os processos do sistema podem abrir simultaneamente.

• Nível do usuário: o número máximo de arquivos que os processos de um único usuário podem abrir.

Ambientes de contêiner possuem um limite adicional de descritores de arquivo: o número máximo de descritores de arquivo por processo dentro de um contêiner.

Modificar o limite de descritores de arquivo no nível do sistema

Para obter instruções, consulte Customize OS parameters for a node pool.

Modificar o limite de descritores de arquivo por processo

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

   cat /etc/security/limits.conf

   Use os seguintes parâmetros para configurar o número máximo de descritores de arquivo para um único processo no nó:

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

2. Execute o comando sed para modificar o número máximo de descritores de arquivo. O valor recomendado é 65535.

   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 a alteração.

   Se a saída corresponder ao valor configurado, a alteração foi aplicada com sucesso.

   # ulimit -n
   65535

Modificar o limite de descritores de arquivo do contêiner

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

   Os seguintes parâmetros definem o limite de descritores de arquivo para um único processo dentro de um contêiner:

   ...
   LimitNOFILE=1048576
   LimitNPROC=1048576
   ...

2. Execute os seguintes comandos para modificar os valores dos parâmetros. O valor recomendado para o limite de descritores de arquivo é 1048576.

   • Nó containerd:

     sed -i "s/LimitNOFILE=[0-9a-zA-Z]*$/LimitNOFILE=1048576/g" /etc/systemd/system/containerd.service;sed -i "s/LimitNPROC=[0-9a-zA-Z]*$/LimitNPROC=1048576/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 verificar o limite de descritores de arquivo para um único processo dentro do contêiner.

   Se a saída corresponder ao valor configurado, a alteração foi aplicada com sucesso.

   • 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

Atualizar o runtime de contêiner para nós worker não gerenciados

Clusters legados criados antes da introdução dos node pools podem conter nós worker não gerenciados. Para atualizar o runtime de contêiner desses nós, é necessário migrá-los para um node pool.

Siga estas etapas:

1. Create a node pool: Se não houver um node pool adequado no cluster, crie um com uma configuração compatível com os nós não gerenciados.

2. Remove the node: Ao remover um nó, o sistema o isola (marcando-o como não agendável) e, em seguida, drena seus pods para despejá-los. Se a drenagem falhar, o processo de remoção é interrompido. O nó é removido do cluster somente se a drenagem for concluída com êxito.

3. Add an existing node: Adicione o nó a um node pool existente. Como alternativa, crie um node pool sem nós e, em seguida, adicione o nó a ele. Após a adição, o runtime de contêiner do nó é atualizado automaticamente para corresponder ao especificado na configuração do node pool.

   Nota

   Embora o recurso de node pool em si seja gratuito, você será cobrado pelos recursos cloud subjacentes, como instâncias ECS, utilizados pelo node pool. Para mais informações, consulte Cloud resource fees.

Node pool exibido como "Other Nodes"

O ACK oferece métodos padrão para adicionar recursos de computação a um cluster pelo console, OpenAPI ou CLI. Para mais informações, consulte Add an existing node. Se você adicionar nós por métodos fora dos fluxos padrão do ACK, o ACK não conseguirá identificar a origem desses nós e os atribuirá ao grupo Other Nodes na página Nodes. O ACK não pode gerenciar esses nós por meio de um node pool, portanto recursos como gerenciamento de ciclo de vida, O&M automatizado e suporte técnico garantido ficam indisponíveis.

Caso continue utilizando esses nós, garanta a compatibilidade deles com os add-ons do cluster e assuma todos os riscos potenciais. Esses riscos incluem, entre outros, os seguintes:

• Compatibilidade de versão: Durante atualizações do plano de controle ou de componentes do sistema, o sistema operacional e os componentes desses nós não gerenciados podem tornar-se incompatíveis com as novas versões, ocasionando interrupções no service.

• Compatibilidade de agendamento de workloads: O cluster pode não conseguir reportar com precisão o status desses nós, como zona de disponibilidade e capacidade de recursos restante, levando a decisões incorretas de agendamento de workloads e causando problemas de disponibilidade ou degradação de desempenho.

• Compatibilidade do plano de dados: A compatibilidade dos componentes do lado do nó e do sistema operacional com o plano de controle e os componentes do sistema do cluster não é validada, representando riscos potenciais de estabilidade.

• Compatibilidade de O&M: Operações de manutenção nesses nós pelo console ou OpenAPI podem falhar ou produzir resultados inesperados, pois o canal de gerenciamento e o ambiente de execução desses nós não são verificados.

Configurar ACLs de rede para vSwitches de nós

Se o vSwitch de um node pool tiver uma ACL de rede que negue tráfego dos blocos CIDR necessários, os novos nós não conseguirão ingressar no cluster e permanecerão no estado Failed ou Offline.

Siga estas etapas para permitir os blocos CIDR necessários e readicionar os nós:

1. Configure network ACL rules. Nas regras de inbound e outbound, permita o tráfego dos seguintes blocos CIDR:

   1. 100.104.0.0/16: O bloco CIDR de gerenciamento do plano de controle do ACK.

   2. 100.64.0.0/10: O bloco CIDR de service interno da Alibaba Cloud.

   3. 100.100.100.200/32: O endpoint do service de metadados de instâncias ECS.

   4. Os blocos CIDR primário e secundários do VPC do cluster, ou o bloco CIDR do vSwitch que contém os nós.

2. Remove faulty nodes. Remova os nós que estavam no estado Failed ou Offline antes de as novas regras de ACL de rede entrarem em vigor.

3. Create and manage node pools ou expand an existing node pool para adicionar novos nós. O status Ready nos novos nós confirma que as regras de ACL de rede estão configuradas corretamente.