Container Service for Kubernetes:Preguntas frecuentes sobre nodos y node pools

Índice

Para diagnosticar y solucionar problemas en los nodos, consulte Troubleshoot abnormal nodes .

Uso de instancias spot en un node pool

Varios tipos de instancias ECS por node pool

Sí, es posible. Se recomienda configurar el node pool con varios tipos de instancias ECS para evitar errores de escalado horizontal causados por la falta de disponibilidad de un tipo de instancia o por inventario insuficiente. Para ello, configure varios vSwitches en distintas zonas de disponibilidad, seleccione varios tipos de instancias ECS o especifique los tipos según la cantidad de vCPU y memoria. Una vez creado el node pool, puede agregar tipos de instancia con base en las recomendaciones de nivel de escalabilidad de la consola o en view the scalability level of a node pool.

Para consultar la lista de tipos de instancia compatibles y las recomendaciones de configuración de nodos, vea ECS instance type configuration recommendations .

Número máximo de pods por nodo

El cálculo del número máximo de pods por nodo depende del plugin de red del clúster. Para obtener más información, consulte Maximum number of Pods per node.

• Terway: el número máximo de pods por nodo es la suma de los pods en la red de contenedores y en la red del host.

• Flannel: el límite corresponde al valor de Number of Pods per Node especificado durante la creación del clúster.

Puede consultar el número máximo de pods por nodo, también conocido como Pod Quota , en la página Nodes > Nodes de la consola.

No es posible modificar el número máximo de pods por nodo después de crear el clúster. Si un nodo alcanza este límite, escale horizontalmente los nodos para aumentar la capacidad de pods. Para obtener más información, consulte Adjust available Pods on a node.

Ajustar la capacidad de pods de un nodo

El plugin de red determina el número máximo de pods que admite un nodo worker. Por lo general, este límite no se puede modificar. En el modo Terway, el límite depende de la cantidad de interfaces de red elásticas (ENI) que proporciona la instancia ECS. En el modo Flannel, el límite se especifica al crear el clúster y no se puede modificar después. Si alcanza el límite de pods, se recomienda agregar nodos al node pool para incrementar el total de pods disponibles.

Para obtener más información, consulte Increase the maximum number of pods in a cluster.

Modificar la configuración de un nodo

• Para garantizar la estabilidad del servicio, ciertos parámetros —en particular los relacionados con la disponibilidad y la red— no se pueden modificar una vez creado el node pool. Por ejemplo, no es posible cambiar el runtime de contenedores ni la VPC a la que pertenece un nodo.

• En cuanto a los parámetros modificables, los cambios en la configuración del node pool solo aplican a los nodos nuevos. Los nodos existentes no se ven afectados, salvo que utilice opciones específicas como Update ECS Tags of Existing Nodes o Update Labels and Taints of Existing Nodes.

Consulte Create and manage node pools para conocer los detalles de los parámetros modificables y el momento en que surten efecto los cambios.

Como alternativa, para aplicar una nueva configuración, cree un node pool con los ajustes deseados. Después, marque como no programables (cordon) y vacíe (drain) los nodos del node pool anterior para migrar las cargas de trabajo. Cuando termine la migración, libere las instancias del node pool original. Para ver las instrucciones, consulte Cordon and drain nodes.

¿Se puede deshabilitar Expected Nodes?

Si el Scaling Mode de un node pool está establecido en Manual, debe configurar el parámetro Expected Nodes. Esta función no se puede deshabilitar.

Para quitar un nodo específico, consulte Remove a node. Para agregar un nodo específico, consulte add an existing node. Después de remove a node o add an existing node, Expected Nodes se actualiza automáticamente con el nuevo recuento de nodos. No es necesario modificarlo de forma manual.

Node pools con y sin Expected Nodes

El parámetro Expected Nodes define la capacidad prevista de un node pool. Puede escalar un node pool hacia adentro o hacia afuera ajustando este valor. Sin embargo, algunos node pools heredados podrían no tener habilitada esta función.

La siguiente tabla describe cómo responde el sistema a las operaciones en node pools con y sin la función Expected Nodes habilitada.

Migrar nodos no gestionados a un node pool

En clústeres de ACK antiguos, creados antes de que existiera la función de node pools, algunos nodos worker podrían no pertenecer a ningún node pool. Para agruparlos bajo una gestión centralizada y un mantenimiento automatizado, migre estos nodos no gestionados a un node pool: cree un node pool, quite los nodos no gestionados del clúster y vuelva a agregar sus instancias ECS al node pool.

Para lograrlo, cree un nuevo node pool o escale horizontalmente uno existente, quite los nodos no gestionados del clúster y luego agréguelos al node pool de destino. Para obtener más información, consulte Migrate unmanaged nodes to a node pool.

Reemplazar la imagen del sistema operativo de un node pool

Puede reemplazar el sistema operativo de un node pool; por ejemplo, para migrar de una versión que alcanzó su fin de vida útil (EOL) a una versión compatible. Antes de empezar, consulte OS image release notes para revisar los sistemas operativos compatibles, las versiones de imagen más recientes y las limitaciones de uso.

Consulte Replace the OS of a node pool para ver las instrucciones detalladas y las consideraciones importantes.

Liberar una instancia ECS específica

Para liberar una instancia ECS específica, siga los pasos de remove the node. Esta acción actualiza automáticamente el recuento esperado de nodos. No intente liberar una instancia concreta cambiando el recuento esperado de nodos, ya que esto desencadena un escalado hacia adentro aleatorio y no garantiza que se elimine la instancia deseada.

¿Cómo solucionar los tiempos de espera al agregar nodos?

Compruebe la conectividad de red entre el nodo y el API Server CLB. Primero, compruebe que el security group cumple con los requisitos. Para conocer las limitaciones del security group al agregar un nodo existente, consulte Limitations. Para otros problemas de conectividad de red, consulte Network management FAQ.

Cambiar los nombres de host de los nodos worker

1. Quite el nodo. Para obtener más información, consulte Remove a node.

2. Vuelva a agregar el nodo que quitó al node pool. Para obtener más información, consulte Manually add nodes.

   El nodo se renombra automáticamente según la regla de nomenclatura del node pool.

Actualizar manualmente el kernel de un nodo GPU

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

2. Marque el nodo GPU como no programable (por ejemplo, el nodo cn-beijing.i-2ze19qyi8votgjz*).

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

3. Vacíe el nodo GPU donde desea actualizar el controlador.

   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 el controlador NVIDIA actual.

   Nota

   El paquete de controlador que se desinstala en este paso es la versión 384,111. Si su versión del controlador no es 384,111, descargue el instalador correspondiente desde el sitio oficial de NVIDIA y reemplace 384.111 en este paso con su versión real.

   1. Inicie sesión en el nodo GPU y ejecute nvidia-smi para comprobar la versión del controlador.

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

   2. Descargue el instalador del controlador NVIDIA.

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

      Nota

      Debe usar el instalador para desinstalar el controlador NVIDIA.

   3. Desinstale el controlador NVIDIA actual.

      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. Actualice el kernel.

   Siga los procedimientos de su sistema operativo para actualizar el kernel.

6. Reinicie la instancia GPU.

   sudo reboot

7. Vuelva a iniciar sesión en el nodo GPU e instale el paquete kernel-devel correspondiente.

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

8. Visite el sitio oficial de NVIDIA para descargar e instalar el controlador NVIDIA requerido. Este tema utiliza la versión 410.79 como ejemplo.

   # 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. Revise el archivo /etc/rc.d/rc.local para comprobar si contiene la siguiente configuración. De lo contrario, agréguela 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 kubelet y Docker.

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

11. Habilite nuevamente la programación en el nodo GPU para que los pods puedan asignarse otra vez.

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

12. Compruebe la versión del pod del plugin de dispositivo en el nodo 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

    Si ejecuta el comando docker ps y observa que no se inició ningún contenedor en el nodo GPU, consulte Fix GPU node container startup issues.

Solucionar el inicio de contenedores en nodos 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 solucionar este problema, cambie el Cgroup Driver de Docker a systemd.

1. Cree una copia de seguridad de /etc/docker/daemon.json y luego ejecute el siguiente comando para actualizar /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 Docker y kubelet para aplicar los cambios.

   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. Compruebe que el Cgroup Driver de Docker esté establecido en systemd.

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

Migrar pods desde un nodo con errores

Para migrar los pods de aplicación desde un nodo con errores, márquelo como no programable y luego vacíelo. Este proceso expulsa los pods de forma segura y los reprograma en nodos sanos.

1. Inicie sesión en la consola de ACK. En la página Nodes, busque el nodo con errores. En la columna Actions, elija More > Drain.

2. Solucione el problema del nodo con errores. Para obtener más información, consulte Troubleshoot node issues.

Política de desalojo de nodos durante fallas en zonas de disponibilidad

Cuando un nodo presenta problemas de estado, el controlador de nodos inicia un desalojo. La tasa de desalojo predeterminada es de 0.1 nodos por segundo y se controla mediante el parámetro --node-eviction-rate. Esto significa que los Pods se desalojan de un máximo de un nodo cada 10 segundos.

Sin embargo, en un clúster de ACK con nodos en varias zonas de disponibilidad, el controlador ajusta esta política según el estado de salud de cada zona y el tamaño del clúster.

Una zona de disponibilidad puede encontrarse en uno de estos tres estados de salud:

• FullDisruption: la zona no tiene nodos en buen estado y cuenta con como mínimo un nodo con errores.

• PartialDisruption: la zona contiene como mínimo dos nodos con errores. Además, la proporción de nodos con errores respecto al total (calculada como (unhealthy nodes / (unhealthy nodes + healthy nodes))) supera 0.55.

• Normal: la zona no cumple los criterios de FullDisruption ni de PartialDisruption.

Los clústeres también se clasifican por tamaño:

• Clúster grande: cuenta con más de 50 nodos.

• Clúster pequeño: tiene 50 nodos o menos.

El controlador determina la tasa de desalojo a partir de estos estados:

• Si todas las zonas de disponibilidad están en estado FullDisruption, se deshabilita el desalojo en todo el clúster.

• Si como mínimo una zona no está en estado FullDisruption, la tasa se define de la siguiente manera:

  • Para una zona en estado FullDisruption, la tasa se establece en el valor predeterminado de 0.1 nodos por segundo, sin importar el tamaño del clúster.

  • En una zona con estado PartialDisruption, la tasa depende del tamaño del clúster. En un clúster grande, se reduce a 0.01 nodos por segundo. En uno pequeño, se establece en 0, lo que deshabilita el desalojo.

  • Cuando la zona se encuentra en estado Normal, la tasa toma el valor predeterminado de 0.1 nodos por segundo, independientemente del tamaño del clúster.

Para obtener más información, consulte Rate limits on eviction.

Personalización de la ruta de kubelet

No. La ruta de kubelet en un clúster de ACK es /var/lib/kubelet y no se puede modificar. No cambie esta ruta.

Montar un disco de datos en un directorio personalizado

Esta función se encuentra actualmente en versión canary. Para habilitarla, envíe un ticket. Una vez habilitada, el sistema formatea y monta automáticamente cualquier disco de datos que agregue al node pool en el directorio especificado. El directorio de montaje tiene a continuación las siguientes restricciones.

• No monte un disco de datos en los siguientes directorios críticos del sistema operativo:

  • /

  • /etc

  • /var/run

  • /run

  • /boot

• Tampoco monte un disco de datos en los siguientes directorios que utilizan el sistema y los entornos de ejecución de contenedores, ni en sus subdirectorios:

  • /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 datos debe tener un directorio de montaje único.

• El directorio de montaje debe ser una ruta absoluta que comience con /.

• Este directorio no debe contener caracteres de retorno de carro ni de salto de línea (\r y \n), ni terminar con una barra diagonal inversa (\).

Modificar los límites de descriptores de archivo

El número máximo de descriptores de archivo limita la cantidad de archivos que se pueden abrir de forma simultánea. Los sistemas Alibaba Cloud Linux y CentOS manejan dos niveles de límites para estos descriptores:

• Nivel de sistema: la cantidad máxima de archivos que todos los procesos del sistema pueden abrir al mismo tiempo.

• Nivel de usuario: el número máximo de archivos que pueden abrir los procesos de un solo usuario.

Los entornos de contenedores tienen un límite adicional: el número máximo de descriptores de archivo por proceso dentro de un contenedor.

Modificar el límite de descriptores de archivo a nivel de sistema

Consulte las instrucciones en Customize OS parameters for a node pool.

Modificar el límite de descriptores de archivo por proceso

1. Inicie sesión en el nodo y revise el archivo /etc/security/limits.conf.

   cat /etc/security/limits.conf

   Utilice a continuación los parámetros indicados para configurar el número máximo de descriptores de archivo de un solo proceso en el nodo:

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

2. Ejecute el comando sed para modificar el número máximo de descriptores de archivo. Se recomienda usar el valor 65535.

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

3. Vuelva a iniciar sesión en el nodo y ejecute el siguiente comando para comprobar el cambio.

   Si la salida coincide con el valor configurado, la modificación fue exitosa.

   # ulimit -n
   65535

Modificar el límite de descriptores de archivo del contenedor

1. Inicie sesión en el nodo y ejecute el comando correspondiente para consultar el archivo de configuración:

   • Nodo con containerd: cat /etc/systemd/system/containerd.service

   • Nodo con Docker: cat /etc/systemd/system/docker.service

   Los siguientes parámetros establecen el límite de descriptores de archivo para un solo proceso dentro de un contenedor:

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

2. Ejecute los siguientes comandos para modificar los valores de los parámetros. El valor recomendado para el límite de descriptores de archivo es 1048576.

   • Nodo con 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

   • Nodo con 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. Ejecute el comando adecuado para comprobar el límite de descriptores de archivo de un solo proceso dentro del contenedor.

   Si la salida coincide con el valor configurado, la modificación fue exitosa.

   • Nodo con containerd:

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

   • Nodo con Docker:

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

Actualizar el entorno de ejecución de contenedores en nodos worker no administrados

Los clústeres heredados creados antes de la introducción de los node pools podrían contener nodos worker no administrados. Para actualizar el entorno de ejecución de contenedores de estos nodos, debe migrarlos a un node pool.

Siga estos pasos:

1. Create a node pool: si no existe un node pool adecuado en el clúster, cree uno con una configuración que coincida con la de los nodos no administrados.

2. Remove the node: al quitar un nodo, el sistema lo aísla (lo marca como no programable) y luego drena sus pods para desalojarlos. Si el drenaje falla, el proceso de eliminación se detiene. El nodo se quita del clúster únicamente cuando el drenaje termina de forma exitosa.

3. Add an existing node: agregue el nodo a un node pool existente. También puede crear un node pool sin nodos y añadirlo después. Una vez agregado, su entorno de ejecución de contenedores se actualiza automáticamente para coincidir con el especificado en la configuración del node pool.

   Nota

   Aunque la función de node pool no tiene costo, se le cobran los recursos de nube subyacentes que utiliza, como las instancias de ECS. Para obtener más información, consulte Cloud resource fees.

Node pool que se muestra como "Other Nodes"

ACK ofrece métodos estándar para agregar recursos de cómputo a un clúster mediante la consola, OpenAPI o la CLI. Para obtener más información, consulte Add an existing node. Si agrega nodos con métodos externos a los flujos de trabajo estándar de ACK, el sistema no puede identificar su origen y los asigna al grupo Other Nodes en la página Nodes. ACK no puede gestionar estos nodos a través de un node pool, por lo que funciones como la administración del ciclo de vida, el mantenimiento automatizado y el soporte técnico garantizado no están disponibles.

Si decide seguir usando estos nodos, asegúrese de que sean compatibles con los complementos del clúster y asuma todos los riesgos potenciales. Estos riesgos incluyen, entre otros, los siguientes:

• Compatibilidad de versiones: durante las actualizaciones del plano de control o de los componentes del sistema, el sistema operativo y los elementos de estos nodos no administrados podrían volverse incompatibles con las nuevas versiones. Esto puede provocar interrupciones en el servicio.

• Compatibilidad en la programación de cargas de trabajo: el clúster podría no reportar correctamente el estado de estos nodos, como su zona de disponibilidad o la capacidad de recursos restante. Esta situación genera decisiones de programación incorrectas que causan problemas de disponibilidad o degradación del rendimiento.

• Compatibilidad del plano de datos: no se valida la compatibilidad de los componentes del lado del nodo y del sistema operativo con el plano de control ni con los componentes del sistema del clúster, lo que representa un riesgo potencial de estabilidad.

• Compatibilidad operativa: las tareas de mantenimiento en estos nodos desde la consola o mediante OpenAPI podrían fallar o generar resultados inesperados, ya que no se verifica el canal de administración ni el entorno de ejecución correspondiente.

Configurar ACL de red para los vSwitch de los nodos

Si el vSwitch de un node pool tiene una ACL de red que deniega el tráfico de bloques CIDR obligatorios, los nuevos nodos no podrán unirse al clúster y permanecerán en estado Failed u Offline.

Siga estos pasos para permitir los bloques CIDR necesarios y volver a agregar los nodos:

1. Configure network ACL rules. En las reglas de entrada (inbound) y de salida (outbound), permita el tráfico de los siguientes bloques CIDR:

   1. 100.104.0.0/16: bloque CIDR de administración del plano de control de ACK.

   2. 100.64.0.0/10: bloque CIDR de servicios internos de Alibaba Cloud.

   3. 100.100.100.200/32: endpoint del servicio de metadatos de instancias de ECS.

   4. El bloque CIDR principal y cualquier bloque secundario de la VPC del clúster, o bien el bloque CIDR del vSwitch que contiene los nodos.

2. Remove faulty nodes. Elimine los nodos que estaban en estado Failed u Offline antes de que las nuevas reglas de la ACL de red entraran en vigor.

3. Create and manage node pools o expand an existing node pool para agregar nuevos nodos. Un estado Ready en ellos confirma que las reglas de la ACL de red se configuraron correctamente.