Clústeres regionales

En esta página se explica cómo funcionan los clústeres regionales en Google Kubernetes Engine (GKE).

Los clústeres regionales aumentan la disponibilidad de un clúster replicando el plano de control en varias zonas de una región.

Esta configuración ofrece las siguientes ventajas:

  • Resistencia a fallos de una sola zona: los clústeres regionales están disponibles en una región en lugar de en una sola zona de una región. Si una zona deja de estar disponible, tu plano de control no se verá afectado.
  • Actualizaciones continuas del plano de control, cambios de tamaño del plano de control y reducción del tiempo de inactividad debido a fallos del plano de control. Con réplicas redundantes del plano de control, los clústeres regionales proporcionan una mayor disponibilidad de la API de Kubernetes, por lo que puedes acceder a tu plano de control incluso durante las actualizaciones.

Además, de forma predeterminada, los clústeres regionales se crean como clústeres multizonales, por lo que los nodos de trabajador se distribuyen en varias zonas de una región. De esta forma, aumenta la disponibilidad de tu carga de trabajo si ejecutas suficientes réplicas de la carga de trabajo.

Los clústeres de Autopilot de GKE siempre son regionales. Si usas GKE Standard, puedes crear clústeres regionales o zonales. Para obtener información sobre los distintos tipos de disponibilidad de clústeres, consulta Disponibilidad de clústeres.

En los clústeres regionales, incluidos los clústeres de Autopilot, el plano de control se replica en varias zonas de una región. GKE replica automáticamente los nodos en las zonas de la misma región. En los clústeres y los grupos de nodos estándar, puedes especificar manualmente las zonas en las que se ejecutan los nodos. Todas las zonas deben estar en la misma región que el plano de control.

Después de crear un clúster regional, no puedes cambiarlo a un clúster zonal.

Cómo funcionan los clústeres regionales

Los clústeres regionales replican el plano de control y los nodos del clúster en varias zonas de una misma región. Por ejemplo, con la configuración predeterminada, un clúster regional de la región us-east1 crea varias réplicas del plano de control en diferentes zonas de us-east1 y aprovisiona nodos en tres zonas de us-east1: us-east1-b, us-east1-c y us-east1-d. En caso de interrupción de la infraestructura, las cargas de trabajo de Autopilot seguirán ejecutándose y GKE volverá a equilibrar los nodos automáticamente. Si usas clústeres estándar, debes reequilibrar los nodos manualmente o mediante la herramienta de adaptación dinámica de clústeres.

Limitaciones

  • El grupo de nodos predeterminado creado para los clústeres estándar regionales consta de nueve nodos (tres por zona) distribuidos uniformemente en tres zonas de una región. Esto consume nueve direcciones IP para los clústeres que usan nodos públicos. Si es necesario, puedes reducir el número de nodos a uno por zona. A las cuentas de facturación de Cloud recién creadas solo se les asignan ocho direcciones IP por región, por lo que es posible que tengas que solicitar un aumento de tus cuotas de direcciones IP regionales en uso, en función del tamaño de tu clúster regional. Si tienes muy pocas direcciones IP en uso disponibles, no podrás crear el clúster.

  • Para ejecutar GPUs en tu clúster regional, elige una región que tenga al menos una zona en la que estén disponibles las GPUs solicitadas. Debes usar la marca --node-locations al crear el grupo de nodos para especificar la zona o las zonas que contienen las GPUs solicitadas.

    Si la región que elijas no tiene al menos una zona en la que estén disponibles las GPUs solicitadas, puede que veas un error como el siguiente:

    
ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message=
    Accelerator type "nvidia-l4" does not exist in zone europe-west3-a.

    Para ver una lista completa de las regiones y las zonas en las que están disponibles las GPUs, consulta el artículo GPUs en Compute Engine.

  • Las zonas de los grupos de nodos del modo estándar deben estar en la misma región que el plano de control del clúster. Si es necesario, puedes cambiar las zonas de un clúster, lo que hará que todos los nodos nuevos y actuales abarquen esas zonas.

Precios

Todos los clústeres de Autopilot son regionales y están sujetos al modelo de precios de Autopilot.

En el modo estándar, los clústeres regionales requieren más cuotas regionales de tu proyecto que un clúster zonal o multizona similar. Antes de usar clústeres regionales, asegúrate de que conoces tus cuotas y los precios estándar. Si se produce un error Insufficient regional quota to satisfy request for resource, significa que tu solicitud supera la cuota disponible en la región actual.

Además, se te cobra por el tráfico de nodo a nodo entre zonas. Por ejemplo, si una carga de trabajo que se ejecuta en una zona necesita comunicarse con una carga de trabajo de otra zona, el tráfico entre zonas genera costes. Para obtener más información, consulta la sección Salida entre zonas de la misma región (por GB) de la página de precios de Compute Engine.

Almacenamiento persistente en clústeres regionales

Los discos persistentes de zona son recursos de zona, mientras que los discos persistentes regionales son recursos multizona. Cuando añadas almacenamiento persistente, a menos que se especifique una zona, GKE asignará el disco a una zona aleatoria. Para saber cómo controlar las zonas, consulta Zonas en discos persistentes.

Autoescalar clústeres regionales

Ten en cuenta las siguientes consideraciones al usar el autoescalador de clústeres para escalar automáticamente los grupos de nodos en clústeres regionales en modo Estándar.

También puedes consultar más información sobre los límites del autoescalado de los clústeres regionales o sobre cómo la herramienta de adaptación dinámica de clústeres equilibra las zonas.

Estas consideraciones solo se aplican a los clústeres en modo Estándar con la herramienta de escalado automático de clústeres.

Exceso de aprovisionamiento de límites de escalado

Para mantener la capacidad en el improbable caso de que se produzca un fallo en una zona, puedes permitir que GKE aprovisione en exceso tus límites de escalado para asegurar un nivel mínimo de disponibilidad incluso cuando algunas zonas no estén disponibles.

Por ejemplo, si sobreaprovisiona un clúster de tres zonas al 150% (50 % de capacidad adicional), puede asegurarse de que el 100% del tráfico se dirija a las zonas disponibles si se pierde un tercio de la capacidad del clúster. En el ejemplo anterior, esto se conseguiría especificando un máximo de seis nodos por zona en lugar de cuatro. Si falla una zona, el clúster se escala a 12 nodos en las zonas restantes.

Del mismo modo, si sobreaprovisionas un clúster de dos zonas al 200%, puedes asegurarte de que el 100% del tráfico se redirija si se pierde la mitad de la capacidad del clúster.

Puedes consultar más información sobre la herramienta de adaptación dinámica de clústeres o leer las preguntas frecuentes sobre el autoescalado en la documentación de Kubernetes.

Siguientes pasos