Pods máximos por nodo en GKE

En este post, exploraremos un caso práctico relacionado con la configuración del parámetro “Pods per Node” en Google Kubernetes Engine (GKE) y cómo puede impactar la capacidad de escalado de un cluster.

Vamos a analizar las limitaciones y capacidades de este setting, y la importancia de una planificación adecuada de la red en la configuración de los Node Pools.

Descripción del problema

Nos encontramos con el error IP_SPACE_EXHAUSTED al intentar incrementar el número de nodos en nuestro cluster mediante autoscaling. Este error sugiere que el espacio de direcciones IP asignado a los nodos está agotado. Sin embargo, en nuestro caso, el rango de direcciones IP para los nodos GKE era suficiente, ya que contábamos con un rango CIDR /24 (252 IPs disponibles) y solo 8 nodos en ejecución.

Al investigar más a fondo, descubrimos el siguiente mensaje de advertencia:

Warning FailedScaleUp 48s (x2 over 6m32s) cluster-autoscaler Node scale up in zones us-east4-b associated with this pod failed: IP space exhausted. Pod is at risk of not being scheduled.

Este mensaje indicaba que el número de direcciones IP asignadas a los pods estaba agotado, lo que impedía que el cluster escalara correctamente.

Raíz del problema: Pods per node

La raíz del problema se encontraba en la interación de la subnet designada para los pods en el cluster y el número de pods per node:

• El CIDR Block designado para los pods era una /20, que nos permite disponer de 4096 ips.
• Pero, el número de pods per node estaba configurado en su valor maximo por default: 256.

Esto generaba un maximo alocable de nodos en el cluster de un maximo de 8 nodos en total.

Pero, ¿por qué? Vamos a explicarlo adenatrandonos un poco en el valor de Pods per Nodes en GKE.

“Pods per node” en GKE

Este valor determina el tamaño de los CIDR Blocks que son asignados a cada uno de los nodos en GKE. Los pods, luego, son asignados a partir de este rango en cada uno de los nodos.

Esta configuración tiene un valor default a nivel del Cluster, pero este valor puede ser sobrescrito a nivel de cada Node Pool en el cluster.

El setting Max Pods per Node es immutable luego de ser asignado a un node pool. Por eso es muy importante tenerlo en cuenta en nuestra planificación del cada uno de los grupos de nodos.

¿Cómo funciona la asignación de ips para cada Node Pool?

Ahora que entendemos cual es la función que cumple este valor, debemos tener en cuenta la siguiente tabla a la hora de la asignación de los CIDR de los nodos:

Con el valor por Default de 110 pods por nodo, GKE asigna un bloque /24 a cada uno de los nodos, reservando 256 IPs. Los bloques contiene por lo menos el doble de las ips reservadas.

Ahora podemos entender un poco más por que en nuestro caso, tuvimos el error IP_EXAHUSTED:

• Nuestro CIDR Block para los pods en el cluster era un /20: 4096 IPs disponibles.
• Nuestro Setting por default era de 256 pods por nodo. Por lo cual cada nodo tenia un rango /23 asignado: 512 IPs reservadas.
• 4096 / 512 = 8.

Es decir que siguiendo con el resultado de nuestra cuenta: “4096 / 512 = 8”, nuestro máximo de nodos disponibles con esta configuración era de 8 nodos en todo el cluster.

Esta configuración apunta a un cluster con alta capacidad de computo por nodo. En nuestro caso, no estamos interesados en tener una configuración de este tipo, por lo cual debemos buscar una alternativa para resolver la problematica.

¿Cómo podemos solucionar este error?

¿Cómo podemos solucionar este error?

Para solucionar el error IP_SPACE_EXHAUSTED, es necesario tomar una medida disruptiva pero efectiva: recrear el Node Pool con una configuración de “pods per node” menor.

Pasos para la solución:

1. Evaluación y planificación:
   • Antes de realizar cualquier cambio, es fundamental evaluar cuidadosamente la capacidad actual y proyectada de los nodos en el cluster.
   • Es necesario analizar la cantidad de pods necesarios en relación con los recursos disponibles y ajusta el valor de “pods per node” según las necesidades específicas de tu aplicación y la red.
2. Recreación del Node Pool:
   • Eliminar el Node Pool existente: Lamentablemente, debido a que el valor de “Max Pods per Node” es inmutable una vez asignado, deberás eliminar el Node Pool actual.
   • Crear un nuevo Node Pool: Configura el nuevo Node Pool con un valor de “Max Pods per Node” más adecuado. Por ejemplo, si reduces este valor a 128 pods por nodo, cada nodo reservará un bloque /24 (256 IPs) en lugar de /23 (512 IPs), permitiendo más nodos en el cluster.
3. Implementación:
   • Desplegar el nuevo Node Pool implica migrar los workloads existentes y verificar que la nueva configuración resuelva el problema de agotamiento de IPs.