Acerca de las opciones de configuración de clústeres

En esta página se explican las principales opciones de configuración de clúster que puedes elegir al crear un clúster en Google Kubernetes Engine (GKE), tanto si usas laGoogle Cloud consola como la CLI de Google Cloud o Terraform. Estas opciones te permiten personalizar una amplia gama de atributos y comportamientos del clúster para satisfacer tus necesidades, desde si el clúster es accesible desde redes públicas hasta cómo quieres que reciba las actualizaciones de versión.

Muchas de las opciones que se describen en esta guía no se pueden cambiar después de crear un clúster. Entre ellas, se incluyen las que afectan a la disponibilidad y la red de un clúster. Si necesitas cambiar estas opciones, debes crear un nuevo clúster y migrar el tráfico a él, lo que puede provocar interrupciones.

Práctica recomendada:

Como muchas opciones de configuración de clúster no se pueden cambiar después de crear el clúster, planifica y diseña la configuración del clúster con los administradores y arquitectos de tu organización, los arquitectos de Cloud, los administradores de red o cualquier otro equipo responsable de definir, implementar y mantener la arquitectura de GKE yGoogle Cloud .

Esta página está dirigida a administradores y arquitectos que definen soluciones de TI y arquitecturas de sistemas de acuerdo con la estrategia de la empresa. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de usuario de GKE. Google Cloud

Antes de leer esta página, debes familiarizarte con los siguientes conceptos básicos de Kubernetes: conceptos básicos de Kubernetes:

Nivel de gestión de clústeres

Antes de hablar de las opciones de clúster, es importante que sepas el nivel de flexibilidad, responsabilidad y control que necesitas para tu clúster. El nivel de control que necesites determinará el modo de funcionamiento que debes usar en GKE y las opciones de configuración del clúster que debes elegir.

Cuando creas un clúster en GKE, lo haces mediante uno de los siguientes modos de funcionamiento:

  • Autopilot (recomendado): proporciona una configuración de clúster totalmente aprovisionada y gestionada. Los clústeres Autopilot están preconfigurados con una configuración de clúster optimizada que está lista para cargas de trabajo de producción.

  • Estándar: ofrece una flexibilidad de configuración avanzada en la infraestructura subyacente del clúster. En los clústeres creados con el modo Estándar, usted determina la configuración necesaria para sus cargas de trabajo de producción.

Para obtener más información sobre estos modos y sobre Autopilot, consulta los modos de funcionamiento de GKE y la descripción general de Autopilot.

Puedes consultar una comparación detallada de los dos modos en Comparar GKE Standard y Autopilot.

Opciones de configuración de clústeres

Una vez que hayas elegido un modo de funcionamiento, selecciona la configuración que necesites para tu clúster. Los clústeres de Autopilot están más gestionados y configurados por Google Cloud que los clústeres estándar, por lo que tienen menos opciones de configuración disponibles.

Las opciones de configuración de todos los clústeres se dividen en las siguientes categorías:

  • Nombre y otros metadatos: cada clúster debe tener un nombre identificativo que sea único en su proyecto. También puedes añadir una descripción y etiquetas al clúster (opcional).
  • Disponibilidad y escalabilidad: especifica dónde quieres que se ejecuten el plano de control y los nodos del clúster, y si quieres varias réplicas del plano de control. Todos los clústeres de Autopilot son regionales, lo que significa que tienen varios planos de control en varias zonas de proceso de una Google Cloudregión.
  • Pertenencia a una flota: elige si quieres que tu clúster forme parte de una flota.
  • Redes: opciones de redes, como la red de nube privada virtual (VPC) y la subred en la que se encuentra el clúster, así como si quieres que se pueda acceder a tu clúster desde redes públicas.
  • Gestión de versiones y actualizaciones: usa canales de lanzamiento para elegir el equilibrio que prefieras entre las nuevas funciones y la estabilidad al actualizar el software de este clúster. Además, puedes definir ventanas de mantenimiento y exclusiones para elegir cuándo se pueden realizar las actualizaciones y cuándo no.
  • Seguridad: incluye si el clúster usa la federación de identidades de carga de trabajo para GKE y la cuenta de servicio que usan los nodos del clúster para autenticarse enGoogle Cloud.
  • Funciones del clúster: habilita y configura funciones adicionales de GKE yGoogle Cloud para este clúster, como copias de seguridad y observabilidad. El modo estándar también te permite crear clústeres alfa de corta duración para probar las funciones alfa de Kubernetes.

Además de estas, los clústeres estándar también tienen opciones en la siguiente categoría:

  • Grupos de nodos: especifica detalles sobre los nodos de tu clúster, como los grupos de nodos, el sistema operativo de los nodos y el tamaño de los nodos.

En las siguientes secciones se analizan algunas de estas categorías con más detalle, sobre todo aquellas en las que no puedes cambiar el ajuste después de crear el clúster. Para ver una lista completa de las opciones de configuración, consulta la referencia de configuración.

En la siguiente tabla se comparan las opciones disponibles en algunas áreas clave de los clústeres Autopilot y Estándar:

Opciones de clústeres Modo
Autopilot Estándar
Tipo de disponibilidad Regional Regional o Zonal
Canal de lanzamiento Rápido, Habitual o Estable Cualquier canal
Versiones de clústeres Predeterminada u otra versión disponible Predeterminada u otra versión disponible
Rutas de red Nativo de VPC Nativa de VPC o basada en rutas
Aislamiento de red Personalizable Personalizable
Características de Kubernetes Producción Producción o Alfa

Disponibilidad del clúster

Con GKE, puedes crear un clúster adaptado a los requisitos de disponibilidad de tu carga de trabajo y a tu presupuesto. Puedes elegir entre clústeres regionales que tengan varias réplicas del plano de control en varias zonas de computación de una Google Cloud región o clústeres zonales con un solo plano de control en una sola zona. Los clústeres de Autopilot siempre son regionales.

Para ayudarte a elegir el tipo de clúster que quieres crear en el modo Estándar, consulta Elegir un plano de control regional o zonal.

Estos ajustes no se pueden actualizar después de crear el clúster: un clúster zonal no puede convertirse en un clúster regional, y un clúster regional no puede convertirse en un clúster zonal.

Práctica recomendada:

En el caso de las cargas de trabajo de producción, utiliza clústeres regionales, ya que suelen ofrecer una mayor disponibilidad que los clústeres zonales. En los entornos de desarrollo, utiliza clústeres regionales con grupos de nodos zonales. Un clúster con un plano de control regional y grupos de nodos zonales tiene los mismos costes que un clúster zonal. Para obtener más información sobre las consideraciones específicas de cada región, consulta el artículo sobre geografía y regiones.

Clústeres regionales

Un clúster regional tiene varias réplicas del plano de control, que se ejecutan en varias zonas de la Google Cloud región especificada. Siempre debes especificar una región al crear un clúster de Autopilot u otro clúster regional.

En el caso de los clústeres estándar regionales, también puedes elegir en qué zonas se ejecutan los nodos del clúster. Los nodos de un clúster regional pueden ejecutarse en varias zonas o en una sola, en función de las ubicaciones de los nodos configuradas. De forma predeterminada, GKE replica cada grupo de nodos en tres zonas de la región del plano de control. Cuando creas un clúster estándar regional o añades un grupo de nodos, puedes cambiar la configuración predeterminada especificando las zonas en las que se ejecutan los nodos del clúster. Todas las zonas deben estar en la misma región que el plano de control.

Usa clústeres regionales para ejecutar tus cargas de trabajo de producción, ya que ofrecen una mayor disponibilidad que los clústeres de zona.

No puedes cambiar la región de un clúster regional después de crearlo.

Clústeres zonales

Los clústeres zonales tienen un único plano de control en una sola zona. Las cargas de trabajo siguen ejecutándose durante una actualización del clúster o una interrupción de la zona en la que se ejecuta el plano de control. Sin embargo, el clúster, sus nodos y sus cargas de trabajo no se pueden configurar hasta que el plano de control esté disponible. En función de los requisitos de disponibilidad de tu carga de trabajo, puedes distribuir los nodos de tu clúster zonal en una o varias zonas.

Para crear un clúster de zona, consulta Crear un clúster de zona.

Ubicación y distribución de los nodos

Tanto si usas clústeres regionales como zonales, puedes determinar con precisión la ubicación y la distribución de tus nodos en las zonas. Puedes configurar las zonas predeterminadas de todos los grupos de nodos futuros, así como asignar o cambiar las zonas específicas de los nodos de los grupos de nodos actuales.

Clústeres de una sola zona

Un clúster de una sola zona (que puede ser regional o de zona) ejecuta cargas de trabajo en nodos ubicados en una sola zona. Si esa zona sufre una interrupción, todas las cargas de trabajo dejarán de estar disponibles.

Los clústeres zonales se crean de forma predeterminada como clústeres de una sola zona, pero puedes actualizar esta configuración a clústeres multizona.

Clústeres multizona

Un clúster multizona, que puede ser regional o de zona, mejora la disponibilidad de las cargas de trabajo distribuyendo los nodos en varias zonas de una misma región. Esto te permite ejecutar cargas de trabajo en varias zonas de una región. Si ejecutas una carga de trabajo en varias zonas y se produce una interrupción zonal, la carga de trabajo se verá afectada en esa zona, pero seguirá estando disponible en otras zonas.

Distribuir nodos de GKE en varias zonas puede generar cargos por salida de red entre zonas cuando los nodos necesiten comunicarse con peers ubicados en una zona diferente de la región.

Los clústeres regionales se crean de forma predeterminada como clústeres multizona, pero puedes cambiar esta configuración a clústeres de una sola zona.

Membresía de Fleet

Si tu organización usa varios clústeres, puedes simplificar la gestión de varios clústeres añadiéndolos a una flota, que es una agrupación lógica de clústeres de Kubernetes. Crear una flota ayuda a tu organización a mejorar la gestión de clústeres individuales a grupos enteros de clústeres y te permite usar funciones habilitadas para flotas, como Multi Cluster Ingress, Config Sync y Policy Controller.

Aunque puedes añadir clústeres a una flota en cualquier momento, si has habilitado GKE Enterprise, te recomendamos que registres los clústeres de nivel Enterprise en una flota durante la creación del clúster. Esto se debe a que estos clústeres "nativos de la flota" se crean con los ajustes predeterminados que hayas elegido a nivel de flota para una serie de funciones empresariales, así como con los registros y las métricas recomendados ya habilitados. Puedes consultar más información sobre estos temas en las siguientes guías:

Este ajuste se puede actualizar después de crear el clúster para registrarlo o anular su registro, aunque no recomendamos mover clústeres con cargas de trabajo activas de una flota a otra.

Puedes consultar más información sobre cómo añadir clústeres a flotas en el artículo Crear flotas para simplificar la gestión de varios clústeres.

Configuración de redes

Cuando creas un clúster de GKE, puedes especificar una serie de ajustes de red, como la red en la que se encuentra el clúster, el modo de enrutamiento de la red y si quieres que los nodos del clúster sean accesibles desde redes públicas.

Si no eres administrador de la red, debes consultar a los especialistas en redes de tu organización antes de crear un clúster listo para producción, ya que muchas de estas opciones no se pueden cambiar después de crear el clúster. Si eres administrador de redes, puedes consultar más información sobre las redes de GKE en Acerca de las redes de GKE y las prácticas recomendadas para las opciones de redes en Prácticas recomendadas para las redes de GKE. En esta sección solo se describe un subconjunto de las opciones de redes posibles.

Red y subred

La red de nube privada virtual (VPC) en la que se encuentra un clúster determina con qué otros recursos de Compute Engine puede comunicarse. De forma predeterminada, los clústeres de GKE se crean en la red predeterminada de tu proyecto, aunque puedes elegir otra red si tú o tu administrador habéis creado una. Si está disponible, puede especificar que quiere que su clúster pertenezca a una subred de VPC específica. De lo contrario, se usará la subred predeterminada. También puedes especificar que quieres usar un intervalo de direcciones IP concreto dentro de esa subred para tus pods y servicios.

Estos ajustes no se pueden actualizar después de crear el clúster.

Opciones de aislamiento de red

Puedes personalizar el aislamiento de la red en tu clúster teniendo en cuenta los dos aspectos siguientes:

  • Acceso al plano de control: de forma predeterminada, tanto el endpoint interno como el externo del plano de control están habilitados, y el endpoint basado en DNS está inhabilitado. Puedes elegir entre las siguientes opciones:

    • Inhabilita los endpoints externos e internos y usa solo el endpoint DNS.
    • Inhabilita el endpoint externo solo para evitar el acceso a clientes externos.
    • Habilita las redes autorizadas para controlar qué direcciones IP pueden acceder a los endpoints del plano de control.

  • Configuración de redes de clúster: puedes habilitar nodos privados en tu clúster para aislar por completo las cargas de trabajo de las redes públicas. Puedes habilitar nodos privados en clústeres completos o a nivel de grupo de nodos (en el caso de los clústeres estándar) o de carga de trabajo (en el caso de los clústeres Autopilot). Si habilitas los nodos privados a nivel de grupo de nodos o de carga de trabajo, se anulará cualquier configuración de nodos a nivel de clúster.

Estos ajustes se pueden cambiar después de crear el clúster.

Para obtener más información sobre el aislamiento de red, consulta Información sobre la personalización del aislamiento de red y Personalizar el aislamiento de red.

Práctica recomendada:

Usa Cloud NAT para proporcionar a los pods de GKE acceso a recursos con direcciones IP públicas. Cloud NAT mejora la seguridad general del clúster, ya que los pods no están expuestos directamente a Internet, pero pueden acceder a recursos orientados a Internet.

Clústeres nativos de VPC y basados en rutas

En GKE, los clústeres se pueden distinguir según la forma en que enrutan el tráfico de un pod a otro. Un clúster que usa direcciones IP con alias se denomina clúster nativo de VPC. Un clúster que usa Google Cloud rutas se denomina clúster basado en rutas.

De forma predeterminada, todos los clústeres de GKE nuevos usan el enrutamiento nativo de VPC, que es la opción recomendada. Puedes cambiar este ajuste al crear el clúster para crear un clúster basado en rutas solo en el modo Estándar. Este ajuste no se puede modificar después de crear el clúster.

Puedes consultar más información sobre los clústeres nativos de VPC y sus ventajas, incluidos los requisitos especiales que tienen, en Clústeres nativos de VPC.

Práctica recomendada:

Usa el modo de red nativo de VPC en tus clústeres. Este es el valor predeterminado de los clústeres de Autopilot.

Versiones y actualizaciones

Con los canales de lanzamiento, GKE elige las versiones de software de un clúster con el equilibrio que hayas elegido entre la disponibilidad de funciones y la estabilidad. Cuando creas un clúster, puedes elegir el canal de lanzamiento que quieras. Los clústeres nuevos (tanto Autopilot como Estándar) se registran en el canal de lanzamiento Regular de forma predeterminada, aunque puedes elegir una versión específica durante la creación del clúster si es necesario.

Los clústeres de Autopilot siempre usan canales de lanzamiento. Los clústeres estándar usan canales de lanzamiento de forma predeterminada, pero puedes elegir no registrar tu clúster en un canal de lanzamiento (aunque no te lo recomendamos porque esta opción te da un acceso más limitado a las funciones del clúster).

GKE actualiza automáticamente todos los clústeres con el tiempo, independientemente de si están registrados en un canal de lanzamiento. GKE actualiza automáticamente el plano de control del clúster y sus nodos a medida que se van publicando nuevas versiones en ese canal de lanzamiento. Puedes controlar los tiempos y el alcance de las actualizaciones con ventanas de mantenimiento y exclusiones.

Puedes cambiar el canal de lanzamiento de un clúster en cualquier momento.

Para obtener información sobre las próximas actualizaciones automáticas, consulta las notas de la versión de GKE.

Práctica recomendada:

Elige un canal de lanzamiento de GKE para seleccionar las versiones de tu clúster con el equilibrio que prefieras entre disponibilidad de funciones y estabilidad. Usa ventanas de mantenimiento y exclusiones para controlar los tiempos y el alcance de las actualizaciones automáticas.

Funciones alfa (solo en clústeres estándar)

Las nuevas funciones de Kubernetes se clasifican como alfa, beta o estable, según su estado de desarrollo. En la mayoría de los casos, las funciones de Kubernetes que se indican como beta o estables se incluyen en los clústeres de GKE.

Si quieres experimentar con funciones muy nuevas que aún no están listas para producción, puedes usar las funciones alfa en clústeres alfa especiales de GKE. Un clúster alfa tiene habilitadas todas las APIs alfa de Kubernetes (a veces denominadas "feature gates"). Puedes usar clústeres alfa para probar y validar las funciones de Kubernetes en una fase inicial. Los clústeres alfa no se admiten en cargas de trabajo de producción, no se pueden actualizar ni añadir a canales de lanzamiento y caducan en un plazo de 30 días.

Las funciones alfa no están disponibles en los clústeres de Autopilot.

Para crear un clúster alfa, consulta Crear un clúster alfa.

Configuración de seguridad

GKE tiene varios ajustes de seguridad que puedes especificar al crear un clúster. Entre ellos, se incluyen la configuración del cifrado, las funciones de seguridad, como Autorización binaria, la cuenta de servicio que quieras usar para los nodos del clúster (se explica con más detalle en la siguiente sección) y si tu clúster usa la federación de identidades de carga de trabajo para GKE.

Al igual que con otros ajustes, debes consultar a compañeros expertos (en este caso, los especialistas en seguridad de tu organización) antes de crear un clúster listo para producción. Puedes consultar más información sobre la seguridad de GKE en nuestra descripción general de la seguridad y en el artículo Refuerza la seguridad de tu clúster.

Cuenta de servicio de los nodos

GKE usa cuentas de servicio de gestión de identidades y accesos que están asociadas a tus nodos para ejecutar tareas del sistema, como el registro y la monitorización. Como mínimo, estas cuentas de servicio de nodo deben tener el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine (roles/container.defaultNodeServiceAccount) en tu proyecto. De forma predeterminada, GKE usa la cuenta de servicio predeterminada de Compute Engine, que se crea automáticamente en tu proyecto, como cuenta de servicio del nodo.

Si tu organización aplica la restricción de política de organización iam.automaticIamGrantsForDefaultServiceAccounts, es posible que la cuenta de servicio predeterminada de Compute Engine de tu proyecto no obtenga automáticamente los permisos necesarios para GKE.

Si usas la cuenta de servicio predeterminada de Compute Engine para otras funciones de tu proyecto u organización, es posible que la cuenta de servicio tenga más permisos de los que necesita GKE, lo que podría exponerte a riesgos de seguridad.

No puedes cambiar la cuenta de servicio de los clústeres en modo Autopilot ni de los grupos de nodos en modo Estándar después de crearlos.

Configuración de grupos de nodos (solo clústeres estándar)

Como ya sabes por el resumen de administración de clústeres y los modos de funcionamiento de GKE, si usas Autopilot en tus clústeres, no tienes que preocuparte por la configuración de los nodos, ya que GKE los configura por ti. GKE gestiona por completo todos los nodos de los clústeres de Autopilot, que usan el mismo sistema operativo (SO) de los nodos.

Si elige crear un clúster estándar, puede especificar varias opciones de nodo al crear un clúster, como las siguientes:

  • El nombre, el número, el tamaño y la ubicación de los grupos de nodos que quieras usar. Los grupos de nodos son grupos de nodos de tu clúster que comparten una configuración común.
  • El SO de nodo que quieras usar para los nodos nuevos.
  • Si quieres usar VMs de Spot efímeras para los nodos.
  • El tipo de máquina de Compute Engine que quieras usar para los nodos.
  • La cuenta de servicio que quieras usar para los nodos, tal como se describe en Configuración de seguridad.

Algunos ajustes de los grupos de nodos de un clúster se pueden cambiar después de crear el clúster, aunque todos los clústeres estándar requieren al menos un grupo de nodos. Si no especificas el número de nodos ni el tipo de máquina al crear un clúster estándar, su grupo de nodos predeterminado constará de tres nodos en cada una de las zonas del clúster, con la imagen de nodo cos_containerd predeterminada y un tipo de máquina de uso general.

Puedes consultar más información sobre la configuración de grupos de nodos en los artículos Acerca de los grupos de nodos y Añadir y gestionar grupos de nodos.

Referencia de configuración

Consulta una lista completa de las opciones de configuración posibles en las siguientes guías de referencia:

Siguientes pasos