En esta página se describe cómo planificar el tamaño de los nodos de los grupos de nodos estándar de Google Kubernetes Engine (GKE) para reducir el riesgo de interrupciones de las cargas de trabajo y de finalizaciones por falta de recursos.
Esta planificación no es necesaria en GKE Autopilot porque Google Cloud gestiona los nodos por ti. Sin embargo, este documento ayuda a los operadores de clústeres Autopilot que quieren saber cuánta capacidad de recursos de un nodo está disponible para que la usen sus cargas de trabajo.
Ventajas de los nodos del tamaño adecuado
Si te aseguras de que tus nodos tengan el tamaño adecuado para adaptarse a tus cargas de trabajo y gestionar los picos de actividad, obtendrás ventajas como las siguientes:
- Mayor fiabilidad de las cargas de trabajo gracias a la reducción del riesgo de expulsión por falta de recursos.
- Mejora la escalabilidad para escalar las cargas de trabajo durante los periodos de mucho tráfico.
- Reducir los costes, ya que los nodos no son demasiado grandes para tus necesidades, lo que podría provocar que se desperdiciaran recursos.
Recursos asignables a los nodos
Los nodos de GKE ejecutan componentes del sistema que permiten que el nodo funcione como parte de tu clúster. Estos componentes usan recursos de nodos, como la CPU y la memoria. Puede que observes una diferencia entre los recursos totales de tu nodo, que se basan en el tamaño de la máquina virtual de Compute Engine subyacente, y los recursos que están disponibles para que tus cargas de trabajo de GKE los soliciten. Esta diferencia se debe a que GKE reserva una cantidad predefinida de recursos para la funcionalidad del sistema y la fiabilidad de los nodos. El espacio en disco que reserva GKE para los recursos del sistema varía en función de la imagen del nodo. Los recursos restantes que están disponibles para tus cargas de trabajo se denominan recursos asignables.
Cuando defines pods en un manifiesto, puedes especificar solicitudes y límites de recursos en la especificación del pod. Cuando GKE coloca los pods en un nodo, el pod solicita los recursos especificados de los recursos asignables del nodo. Cuando planifiques el tamaño de los nodos de tus grupos de nodos, debes tener en cuenta cuántos recursos necesitan tus cargas de trabajo para funcionar correctamente.
Comprobar los recursos asignables de un nodo
Para inspeccionar los recursos asignables de un nodo, ejecuta el siguiente comando:
kubectl get node NODE_NAME \
-o=yaml | grep -A 7 -B 7 capacity
Sustituye NODE_NAME por el nombre del nodo.
El resultado debería ser similar al siguiente:
allocatable:
attachable-volumes-gce-pd: "127"
cpu: 3920m
ephemeral-storage: "47060071478"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 13498416Ki
pods: "110"
capacity:
attachable-volumes-gce-pd: "127"
cpu: "4"
ephemeral-storage: 98831908Ki
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 16393264Ki
pods: "110"
En este resultado, los valores de la sección allocatable son los recursos asignables del nodo. Los valores de la sección capacity son los recursos totales del nodo. Las unidades de almacenamiento efímero son bytes.
Reservas de recursos de GKE
GKE reserva cantidades específicas de memoria y recursos de CPU en los nodos en función del tamaño total del recurso disponible en el nodo. Los tipos de máquinas más grandes ejecutan más contenedores y pods, por lo que la cantidad de recursos que reserva GKE aumenta en las máquinas más grandes. Los nodos de Windows Server también requieren más recursos que los nodos de Linux equivalentes, ya que deben ejecutar el SO Windows y los componentes de Windows Server que no se pueden ejecutar en contenedores.
Reservas de memoria y CPU
En las secciones siguientes se describen las reservas predeterminadas de memoria y CPU en función del tipo de máquina.
Reservas de memoria
En el caso de los recursos de memoria, GKE reserva lo siguiente:
- 255 MiB de memoria para máquinas con menos de 1 GiB de memoria
- El 25% de los primeros 4 GiB de memoria
- El 20% de los siguientes 4 GiB de memoria (hasta 8 GiB)
- 10% de los siguientes 8 GiB de memoria (hasta 16 GiB)
- 6% de los siguientes 112 GiB de memoria (hasta 128 GiB)
- 2% de la memoria que supere los 128 GiB
GKE también reserva 100 MiB de memoria adicionales en cada nodo para gestionar la expulsión de pods.
Reservas de CPU
En el caso de los recursos de CPU, GKE reserva lo siguiente:
- 6 % del primer núcleo
- 1 % del siguiente núcleo (hasta 2 núcleos)
- 0,5 % de los siguientes 2 núcleos (hasta 4 núcleos)
- 0,25% de los núcleos que superen los 4 núcleos
En el caso de los tipos de máquinas E2 de núcleo compartido, GKE reserva un total de 1060 milinúcleos.
Reserva de almacenamiento efímero local
GKE proporciona nodos con almacenamiento efímero local, respaldado por dispositivos conectados localmente, como el disco de arranque del nodo o las unidades SSD locales. El almacenamiento efímero no tiene ninguna garantía de disponibilidad y los datos que contiene se podrían perder si un nodo falla y se elimina.
GKE reserva una parte del almacenamiento efímero total del nodo como un único sistema de archivos para que kubelet lo use durante el desalojo de pods y para otros componentes del sistema que se ejecuten en el nodo. Puedes asignar el almacenamiento efímero restante a tus pods para que lo usen con fines como los registros. Para saber cómo especificar solicitudes y límites de almacenamiento efímero en tus pods, consulta Almacenamiento efímero local.
GKE calcula la reserva de almacenamiento efímero local de la siguiente manera:
EVICTION_THRESHOLD + SYSTEM_RESERVATION
Los valores reales varían en función del tamaño y el tipo de dispositivo que respalde el almacenamiento.
Almacenamiento efímero respaldado por el disco de arranque del nodo
De forma predeterminada, el almacenamiento efímero se basa en el disco de arranque del nodo. En este caso, GKE determina el valor del umbral de desalojo de la siguiente manera:
EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY
El umbral de desalojo siempre es el 10% de la capacidad total del disco de arranque.
GKE determina el valor de la reserva del sistema de la siguiente manera:
SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)
El importe de la reserva del sistema es el más bajo de los siguientes:
- 50% de la capacidad del disco de arranque
- 35% de la capacidad del disco de arranque + 6 GiB
- 100 GiB
Por ejemplo, si el disco de arranque es de 300 GiB, se aplican los siguientes valores:
- 50% de la capacidad: 150 GiB
- 35% de la capacidad + 6 GiB: 111 GiB
- 100 GiB
GKE reservaría lo siguiente:
- Reserva del sistema: 100 GiB (el valor más bajo)
- Umbral de desalojo: 30 GiB
El almacenamiento efímero total reservado es de 130 GiB. La capacidad restante, 170 GiB, es almacenamiento efímero asignable.
Almacenamiento efímero con copia de seguridad en SSDs locales
Si tu almacenamiento efímero se basa en SSD locales, GKE calcula el umbral de desalojo de la siguiente manera:
EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB
En este cálculo, SSD_NUMBER es el número de unidades SSD locales conectadas. Todos los SSD locales tienen un tamaño de 375 GiB, por lo que el umbral de desalojo es el 10% de la capacidad total de almacenamiento efímero. Ten en cuenta que este valor se calcula antes de formatear las unidades, por lo que la capacidad utilizable es varios puntos porcentuales inferior, en función de las versiones de imagen de nodo.
GKE calcula la reserva del sistema en función del número de SSDs conectados, de la siguiente manera:
| Número de SSD locales | Reserva del sistema (GiB) |
|---|---|
| 1 | 50 GiB |
| 2 | 75 GiB |
| 3 o más | 100 GiB |
Usar reservas de recursos para planificar los tamaños de los nodos
Ten en cuenta los requisitos de recursos de tus cargas de trabajo en el momento de la implementación y bajo carga. Esto incluye las solicitudes y los límites planificados de las cargas de trabajo, así como la sobrecarga para adaptarse al aumento de la escala.
Decide si quieres un número reducido de nodos grandes o un número elevado de nodos pequeños para ejecutar tus cargas de trabajo.
- Un número reducido de nodos grandes funciona bien para cargas de trabajo que requieren muchos recursos y no necesitan una alta disponibilidad. El autoescalado de nodos es menos ágil porque se deben desalojar más pods para que se produzca una reducción.
- Un gran número de nodos pequeños funciona bien para cargas de trabajo de alta disponibilidad que no consumen muchos recursos. El autoescalado de nodos es más ágil porque se deben desalojar menos pods para que se produzca una reducción.
Consulta la guía de comparación de familias de máquinas de Compute Engine para determinar la serie y la familia de máquinas que quieres usar en tus nodos.
Ten en cuenta los requisitos de almacenamiento efímero de tus cargas de trabajo. ¿Es suficiente el disco de arranque del nodo? ¿Necesitas SSDs locales?
Calcula los recursos asignables del tipo de máquina que hayas elegido con la información de las secciones anteriores. Compáralo con los recursos y la sobrecarga que necesitas.
- Si el tipo de máquina que has elegido es demasiado grande, considera la posibilidad de usar una máquina más pequeña para no pagar por los recursos adicionales.
- Si el tipo de máquina que has elegido es demasiado pequeño, considera la posibilidad de usar una máquina más grande para reducir el riesgo de que se interrumpan las cargas de trabajo.