En esta página, se describe cómo planificar el tamaño de los nodos en los grupos de nodos de Standard de Google Kubernetes Engine (GKE) para reducir el riesgo de interrupciones de cargas de trabajo y terminaciones sin recursos.
Esta planificación no es necesaria en GKE Autopilot porque Google Cloud administra los nodos por ti. Sin embargo, este documento ayuda a los operadores de clústeres de Autopilot que desean comprender qué parte de la capacidad de recursos de un nodo está disponible para que la usen tus cargas de trabajo.
Beneficios de los nodos con el tamaño correcto
Asegúrate de que los nodos tengan el tamaño adecuado para adaptarse a tus cargas de trabajo y controlar los aumentos repentinos de la actividad proporciona beneficios como los siguientes:
- Mejor confiabilidad de las cargas de trabajo debido a un riesgo reducido de expulsión por recursos insuficientes.
- Escalabilidad mejorada para escalar cargas de trabajo durante períodos de tráfico alto.
- Disminución los costos porque los nodos no son demasiado grandes para tus necesidades, lo que puede generar recursos desperdiciados.
Recursos asignables del nodo
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 nodo, como CPU y memoria. Es posible que notes una diferencia entre los recursos totales de tu nodo, que se basan en el tamaño de la máquina virtual (VM) subyacente de Compute Engine, y los recursos que están disponibles para que los soliciten tus cargas de trabajo de GKE. Esta diferencia se debe a que GKE reserva una cantidad predefinida de recursos para la funcionalidad del sistema y la confiabilidad del nodo. El espacio en disco que GKE reserva para los recursos del sistema difiere según la imagen de nodo. Los recursos restantes 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 esos recursos especificados a los recursos asignables en el nodo. Cuando planificas el tamaño de los nodos de tus grupos de nodos, debes considerar la cantidad de recursos que tus cargas de trabajo necesitan para funcionar de forma correcta.
Verifica los recursos asignables en un nodo
Para inspeccionar los recursos asignables en un nodo existente, ejecuta el siguiente comando:
kubectl get node NODE_NAME \
-o=yaml | grep -A 7 -B 7 capacity
Reemplaza NODE_NAME por el nombre del conjunto de datos.
El resultado es similar a este:
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 en la sección allocatable son los recursos asignables en el nodo. Los valores de la sección capacity son los recursos totales en el 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 según el tamaño total del recurso disponible en el nodo. Los tipos de máquina más grandes ejecutan más contenedores y Pods, por lo que la cantidad de recursos que GKE reserva escala verticalmente para máquinas más grandes. Los nodos de Windows Server también requieren más recursos que nodos de Linux equivalentes, para permitir la ejecución del SO Windows y los componentes de Windows Server que no se pueden ejecutar en contenedores.
Reservas de memoria y CPU
En las siguientes secciones, se describen las reservas predeterminadas de memoria y CPU según el tipo de máquina.
Reservas de memoria
Para recursos de memoria, GKE reserva lo siguiente:
- 255 MiB de memoria para máquinas con menos de 1 GB de memoria
- Un 25% de los primeros 4 GiB de memoria
- Un 20% de los siguientes 4 GiB de memoria (hasta 8 GiB)
- Un 10% de los siguientes 8 GiB de memoria (hasta 16 GiB)
- Un 6% de los siguientes 112 GiB de memoria (hasta 128 GiB)
- Un 2% de cualquier memoria por encima de 128 GiB
GKE también reserva 100 MiB de memoria adicionales en cada nodo para controlar la expulsión de Pods.
Reservas de CPU
Para recursos de CPU, GKE reserva lo siguiente:
- Un 6% del primer núcleo
- Un 1% del siguiente núcleo (hasta 2 núcleos)
- Un 0.5% de los siguientes 2 núcleos (hasta 4 núcleos)
- Un 0.25% de cualquier núcleo por encima de 4 núcleos
Para los tipos de máquina E2 con núcleo compartido, GKE reserva un total de 1,060 millicores.
Reserva de almacenamiento efímero local
GKE proporciona a los nodos almacenamiento efímero local, respaldado por dispositivos conectados localmente, como el disco de arranque o los SSD locales del nodo. El almacenamiento efímero no tiene garantía de disponibilidad y los datos en el almacenamiento efímero podrían perderse si un nodo falla y se borra.
GKE reserva una parte del almacenamiento efímero total del nodo como un sistema de archivos único para que el kubelet lo use durante la expulsión de Pods y para otros componentes del sistema que se ejecutan en el nodo. Puedes asignar el almacenamiento efímero restante a tus Pods para usarlo con otros fines, por ejemplo, en registros. Para obtener información sobre cómo especificar las solicitudes y los 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 según el tamaño y el tipo de dispositivo que respalda el almacenamiento.
Almacenamiento efímero respaldado por un disco de arranque
De forma predeterminada, el almacenamiento efímero está respaldado por el disco de arranque del nodo. En este caso, GKE determina el valor del umbral de expulsión de la siguiente manera:
EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY
El umbral de expulsión 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)
La cantidad de reserva del sistema es la más baja de las siguientes opciones:
- El 50% de la capacidad del disco de arranque
- El 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:
- El 50% de la capacidad: 150 GiB
- El 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 expulsión: 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 respaldado por SSD locales
Si el almacenamiento efímero está respaldado por SSD locales, GKE calcula el umbral de expulsión de la siguiente manera:
EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB
En este cálculo, SSD_NUMBER es la cantidad de SSD locales adjuntas. Todos los SSD locales tienen un tamaño de 375 GiB, por lo que el límite de expulsión es el 10% de la capacidad de almacenamiento efímera total. Ten en cuenta que esto se calcula antes de formatear las unidades, por lo que la capacidad que se puede usar es un varios por ciento menos, según las versiones de imagen del nodo.
GKE calcula la reserva del sistema según la cantidad de SSD conectados, de la siguiente manera:
| Cantidad de SSD locales | Reserva del sistema (GiB) |
|---|---|
| 1 | 50 GiB |
| 2 | 75 GiB |
| 3 o más | 100 GiB |
Usa reservas de recursos para planificar los tamaños de los nodos
Considera los requisitos de recursos de tus cargas de trabajo en el momento de la implementación y con carga. Esto incluye las solicitudes y los límites planificados de las cargas de trabajo, así como la sobrecarga para adaptarse al escalamiento vertical.
Considera si deseas una cantidad pequeña de nodos grandes o una gran cantidad de nodos pequeños para ejecutar tus cargas de trabajo.
- Una pequeña cantidad de nodos grandes funciona bien para cargas de trabajo que requieren muchos recursos y no requieren alta disponibilidad. El ajuste de escala automático de nodos es menos ágil porque se deben expulsar más Pods para que se reduzca la escala verticalmente.
- Una gran cantidad de nodos pequeños funciona bien para cargas de trabajo con alta disponibilidad que no requieren muchos recursos. El ajuste de escala automático de nodos es más ágil porque se deben expulsar menos Pods para que se reduzca la escala verticalmente.
Usa la guía de comparación de familias de máquinas de Compute Engine a fin de determinar la familia y la serie de máquinas que deseas para tus nodos.
Considera los requisitos de almacenamiento efímero de tus cargas de trabajo. ¿El disco de arranque del nodo es suficiente? ¿Necesitas SSD locales?
Calcula los recursos asignables en el tipo de máquina elegido con la información de las secciones anteriores. Compara esto con los recursos y la sobrecarga que necesitas.
- Si el tipo de máquina elegido es demasiado grande, considera usar una máquina más pequeña para evitar pagar por los recursos adicionales.
- Si el tipo de máquina elegido es demasiado pequeño, considera usar una máquina más grande para reducir el riesgo de interrupciones de la carga de trabajo.