Elegir el tamaño y el alcance de los clústeres de Google Kubernetes Engine

En este artículo, se presentan criterios para tener en cuenta en el momento de decidir qué cargas de trabajo se ejecutarán en un clúster compartido de Google Kubernetes Engine y de determinar el tamaño correcto del clúster.

Cuando utilizas contenedores en vez de máquinas virtuales, puedes empaquetar más cargas de trabajo en la misma infraestructura y, al mismo tiempo, brindar aislamiento entre cagas de trabajo.

Las aplicaciones y los contenedores en los que se ejecutan tienen diferentes requisitos de CPU y de memoria. Kubernetes, que es una plataforma de organización de contenedores, los programa en las máquinas a fin de satisfacer las necesidades de CPU y memoria. La medida en que podrá optimizar el uso de la máquina en tu caso dependerá de las cargas de trabajo y las máquinas que estén disponibles para programar cargas de trabajo.

Podrías suponer que los clústeres más grandes que ejecutan una multitud de cargas de trabajo proporcionen una mejor utilización que los clústeres más pequeños que solo ejecutan algunas cargas de trabajo. Sin embargo, compartir los clústeres entre diferentes cargas de trabajo puede sumar complejidad y restricciones adicionales, que podrían superar los beneficios potenciales.

Google Kubernetes Engine está diseñado para admitir una amplia gama de tamaños de clústeres. El tamaño mínimo de un clúster lo define la cantidad de zonas que abarca: una para un clúster zonal y tres para un clúster regional. El tamaño máximo de un clúster de Google Kubernetes Engine se define de la siguiente manera:

  • 50 clústeres por zona
  • 5,000 nodos por clúster
  • 100 pods por nodo
  • 300,000 contenedores

Dentro de estos límites, tú decides el tamaño correcto para el clúster. En las siguientes secciones, se brinda una descripción general de los criterios y las compensaciones que debes tener en cuenta.

Determinar el tamaño de un clúster de Google Kubernetes Engine

Movilidad de la carga de trabajo

Kubernetes intenta programar los pods en los nodos de una manera que logre el mejor uso de los recursos disponibles. La programación no solo incluye solamente la elección de las máquinas que ejecutarán un pod por primera vez, sino también los presupuestos de interrupción de pod. Además, Kubernetes podría reprogramar pods en ejecución a fin de optimizar el uso. No obstante, la optimización se ve restringida si las cargas de trabajo utilizan las siguientes funciones:

Si muchas de tus cargas de trabajo están restringidas de cualquiera de estas maneras, la asignación de pods en los nodos será mayormente estática. La imposibilidad de programar los pods libremente no solo significa que la utilización puede no llegar a ser óptima, sino que el ajuste de escala automático del clúster es menos efectivo. En la peor de las circunstancias, puede significar que, en caso de un error en el nodo, Kubernetes no pueda reprogramar pods incluso si cuenta con capacidad de cálculo.

Para lograr una buena utilización, permite que Kubernetes programe los pods libremente. Si eso no es una posibilidad, considera la opción de utilizar clústeres más pequeños y específicos de una carga de trabajo. Si puedes anticipar la manera en que se asignarán los pods en los nodos teniendo en cuenta las restricciones de tus pods, puedes seleccionar los tamaños de máquina que coincidan con los requisitos de CPU y de memoria de tus contenedores. A fin de garantizar la redundancia, configura grupos de nodos para que, en caso de error en el nodo o la zona, las cargas de trabajo puedan migrar a otros nodos sin tener que infringir las restricciones.

Uniformidad de la carga de trabajo

Cuando tus cargas de trabajo son perfectamente uniformes y todos los contenedores requieren la misma cantidad de CPU y memoria, Kubernetes puede programar cargas de trabajo sin problemas en los nodos. Sin embargo, mientras más diversas sean las cargas de trabajo, más difícil será encontrar una asignación que no desperdicie recursos debido a la fragmentación. Para cargas de trabajo diversas, los clústeres grandes tienden a presentar una mejor utilización de recursos.

Elasticidad de la carga de trabajo

En la mayoría de los casos, la carga de trabajo del clúster no es estática. Es posible agregar o quitar implementaciones, y lo que es aún más importante, la cantidad de pods que se ejecutan puede cambiar debido al uso del ajuste de escala automático horizontal del pod.

Si tus cargas de trabajo varían, habilita la función escalador automático del clúster. Cuando esta función está activa, Google Kubernetes Engine intenta aproximar la capacidad requerida; para ello, agrega o quita nodos del grupo de nodos subyacente de forma dinámica. Cuando la capacidad de una máquina es significativamente mayor que la capacidad adicional que se necesita, una máquina que se agregue al grupo de nodos podría presentar una mala utilización al comienzo. En un clúster grande, este efecto puede no tener importancia, pero en los clústeres más pequeños, la sobrecarga puede ser significativa. A fin de minimizar la sobrecarga y los costos, utiliza ya sea clústeres más grandes o máquinas más pequeñas.

Determinar el alcance de un clúster de Google Kubernetes Engine

Regionalidad de la carga de trabajo

A fin de minimizar la latencia, mejorar la disponibilidad o cumplir con las regulaciones, podrías tener que ejecutar cargas de trabajo en una región específica o en varias regiones. Un clúster de Google Kubernetes Engine se ejecuta dentro de una sola región o una sola zona. Por ende, la cantidad de regiones que necesitas para ejecutar cargas de trabajo determina la cantidad mínima de clústeres de Google Kubernetes Engine que necesitas.

Estado crítico de la carga de trabajo

Cuando un incidente afecta una carga de trabajo crítica para la misión, el personal de operaciones debería ser notificado a fin de que pueda comenzar a solucionar el problema. Pero ¿qué sucede si un clúster ejecuta tanto cargas de trabajo críticas como no críticas para la misión? En caso de un incidente, es posible que no esté claro de inmediato si se ven afectadas solo las cargas de trabajo no críticas o también las críticas. Si bien Kubernetes te permite clasificar las cargas de trabajo según la prioridad, se recomienda ejecutar solo cargas de trabajo con un nivel similar de criticidad en el mismo clúster.

Comunicación y descubrimiento del servicio

Las cargas de trabajo que se ejecutan en el mismo clúster pueden utilizar las funciones de descubrimiento de servicio y balanceo de cargas de Kubernetes. Sin embargo, si las cargas de trabajo deben comunicarse a través de clústeres, podrías tener que utilizar registros de servicio externos o balanceadores de cargas a fin de garantizar que esas cargas de trabajo puedan descubrirse y alcanzarse entre sí.

Desde la perspectiva de la comunicación y el descubrimiento del servicio, suele ser más fácil administrar cargas de trabajo dependientes, por ejemplo, una aplicación de backend y frontend, en un clúster único más grande, en vez de clústeres más pequeños y dedicados.

Administración de identidades y accesos

En Google Cloud Platform (GCP), la administración de acceso se maneja dentro del alcance de un proyecto. Por ende, una recomendación habitual es modelar los proyectos según la estructura del equipo de la organización.

Los clústeres de Google Kubernetes Engine son parte de un proyecto; no puedes compartirlos en múltiples proyectos. Por ende, un clúster de Google Kubernetes Engine también está sujeto a la configuración de la administración de identidades y accesos en la nube (IAM) del proyecto.

Alinear clústeres, equipos y proyectos simplifica la administración de funciones y permisos. En la mayoría de los casos, Cloud IAM te brinda el nivel de detalle que necesitas para administrar el acceso a Kubernetes, y no necesitas configurar el control de acceso adicional basado en funciones (RBAC) en Kubernetes.

Sin embargo, si necesitas compartir un clúster entre equipos, el proyecto de GCP principal del clúster también debe abarcar varios equipos. En ese caso, las funciones que proporciona Cloud IAM para administrar el acceso a Google Kubernetes Engine podrían no ser lo suficientemente específicas y requerir una configuración RBAC adicional (a nivel del espacio de nombres) administrada dentro de Kubernetes. La administración de la configuración RBAC en dos lugares, Cloud IAM y Kubernetes, aumenta la complejidad administrativa, por lo que es mejor elegir el alcance del clúster a fin de poder administrar todo el control de acceso en Cloud IAM.

Mantenimiento

Si bien Google Kubernetes Engine es un servicio totalmente administrado, debes tener en cuenta algunas actividades de mantenimiento:

  • Elegir una versión de Kubernetes
  • Elegir un modelo de actualización (manual o programada) y períodos de mantenimiento
  • Inicializar actualizaciones
  • Cambiar la configuración del grupo de nodos

Todas estas actividades pueden afectar las cargas de trabajo que se ejecutan en un clúster. Si un clúster se comparte entre muchos equipos, puede ser difícil que los equipos se pongan de acuerdo sobre cuándo realizar estas tareas. A fin de evitar problemas de programación, limita la cantidad de equipos con interés en las actividades de mantenimiento de un clúster.

Redes

Un clúster de Google Kubernetes Engine pertenece a una sola nube privada virtual (VPC) y subred, sin importar cuántos grupos de nodos utilice. Si los requisitos de conectividad determinan que las cargas de trabajo deben ejecutarse en VPC o subredes diferentes, deberás crear clústeres separados, al menos uno por VPC o subred.

Supervisión y registro

Debido a que la supervisión y el registro son globales en un clúster de Google Kubernetes Engine, ejecuta múltiples cargas de trabajo en un solo clúster si sus requisitos de registro y supervisión coinciden.

Facturación

GCP controla la facturación por proyecto. Para las cargas de trabajo que comparten un solo clúster y, por ende, un solo proyecto de GCP, es difícil determinar qué porción del costo total corresponde a cada cuenta de carga de trabajo. Si necesitas una facturación por carga de trabajo, utiliza proyectos de GCP y clústeres de Google Kubernetes Engine dedicados.

¿Qué sigue?

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...