Planificar funciones de flotas

Una parte importante de la planificación de las flotas es decidir qué funciones habilitadas para flotas quieres usar. En concreto, si trabajas con clústeres y cargas de trabajo de producción, te recomendamos que identifiques las funciones de la flota que se pueden adoptar de inmediato con el mínimo riesgo o fricción para tus aplicaciones, mientras planificas otras funciones que pueden requerir una adopción más gradual o cuidadosa. En esta guía se describen los diferentes tipos de funciones que se pueden habilitar mediante las flotas, así como sus requisitos. También se ofrecen algunas directrices prácticas sobre la adopción de funciones.

Esta guía está dirigida a arquitectos de nube que quieran empezar a usar flotas en sus organizaciones. Antes de leer esta guía, asegúrate de que conoces la descripción general de la gestión de flotas y el artículo Planificar recursos de flotas, en el que se explica cómo organizar clústeres nuevos o ya creados en flotas.

Prácticas recomendadas para adoptar funciones

Todas las funciones de la flota (excepto la observabilidad básica de la flota) son opcionales, por lo que debes especificar que quieres usarlas. Si añades un clúster a una flota, no se modificará su configuración. Cuando decidas usar las funciones de la flota, algunas se pueden habilitar inmediatamente con un riesgo mínimo, pero es posible que tengas que abordar otras con más cuidado. En esta sección se ofrecen algunas directrices para adoptar funciones.

En el caso de los clústeres y las cargas de trabajo que ya tienes, debes tener especial cuidado con las funciones que usan la igualdad. Se trata de un concepto de flota en el que la función asume que los espacios de nombres, los servicios o las identidades con el mismo nombre en diferentes clústeres son lo mismo. Puedes consultar más información sobre el principio de igualdad y qué funciones lo utilizan en el artículo Cómo funcionan las flotas.

Primeros pasos con las funciones de bajo riesgo

Las siguientes funciones de ambiente no presuponen ningún tipo de igualdad y no afectan a los clústeres de ninguna manera. Se pueden usar de forma segura incluso con cargas de trabajo y clústeres actuales, lo que te permite beneficiarte inmediatamente de una mayor observabilidad y de estadísticas de seguridad en toda tu flota, así como de la capacidad de gestionar el orden de las actualizaciones de los clústeres en función de la pertenencia a la flota.

Las siguientes funciones están instaladas en clústeres individuales. Las funciones pueden asumir la igualdad, pero solo al configurar o especificar recursos en varios clústeres. Esto significa que puedes habilitar estas funciones en tus clústeres con cargas de trabajo existentes de forma segura y solo tienes que tener en cuenta la igualdad al crear o usar configuraciones para ellos que utilicen estos selectores opcionales.

Incorporación de funciones avanzadas de varios clústeres

Las siguientes funciones potentes reducen la sobrecarga operativa de la gestión de varios clústeres. Sin embargo, hay que tener más cuidado con estas funciones, ya que todas requieren que se asuma que hay uno o varios tipos de igualdad para que funcionen, y habilitarlas o inhabilitarlas puede afectar a varios clústeres y a sus cargas de trabajo.

Por ejemplo, si tienes espacios de nombres de Kubernetes con el mismo nombre en diferentes clústeres y aplicaciones (incluido el espacio de nombres predeterminado), debes comprobar que quieres que se traten como el mismo espacio de nombres antes de habilitar cualquier función que haga esta suposición. Del mismo modo, si quieres usar Cloud Service Mesh, debes saber qué endpoints de servicio se combinarán en tus clústeres y confirmar que es el comportamiento que quieres.

Auditar la igualdad del espacio de nombres

Si conoces bien tus aplicaciones, puedes auditar tus espacios de nombres simplemente verificando que no haya dos aplicaciones "diferentes" que usen el mismo espacio de nombres. En concreto, ten cuidado con el uso ad hoc del espacio de nombres predeterminado. Por ejemplo, si tienes un espacio de nombres llamado default en un clúster y otro llamado default en otro clúster, pero se usan para fines diferentes, debes cambiar el nombre de uno de ellos.

Para seguir un enfoque más riguroso, prueba lo siguiente. En cada conjunto de espacios de nombres con el mismo nombre en diferentes clústeres de una flota, comprueba lo siguiente:

  • En cada clúster, las mismas reglas de RBAC están en el clúster y el espacio de nombres de las entidades tiene acceso al espacio de nombres.
  • El conjunto de imágenes que usan los pods (sin la almohadilla ni la etiqueta) es el mismo.
  • El conjunto de secretos que usan los pods es idéntico.

Si se cumplen todas estas condiciones, los espacios de nombres son lo suficientemente similares como para considerarse "iguales".

Si tus espacios de nombres no son lo suficientemente similares, puedes migrar las aplicaciones a nuevos espacios de nombres. Cuando estés seguro de que los espacios de nombres son iguales, puedes activar las funciones que los usen.

Auditar la igualdad de los servicios

Si quieres adoptar Cloud Service Mesh para gestionar tus aplicaciones basadas en microservicios, otro aspecto que debes tener en cuenta es la igualdad de los servicios. Esto significa que, para cualquier combinación de espacio de nombres y nombre de servicio, Cloud Service Mesh los tratará como el mismo servicio lógico en lo que respecta a lo siguiente:

  • Identidad (específicamente para la seguridad de Cloud Service Mesh): si namespace1/service1 tiene autorización para hacer algo, las cargas de trabajo con esa identidad de cualquier clúster también la tendrán.
  • Gestión del tráfico: de forma predeterminada, el tráfico se equilibra entre los servicios namespace1/service1 de cualquier clúster.
  • Observabilidad: las métricas de namespace1/service1 de todos los clústeres se agregan.

Si vas a habilitar Cloud Service Mesh con nuevos clústeres y aplicaciones, te recomendamos que reserves combinaciones únicas de espacio de nombres y nombre de servicio en toda la malla. En el caso de las aplicaciones que ya tengas, audita tus servicios para asegurarte de que los que tengan el mismo espacio de nombres y nombre en todos tus clústeres sean los que quieres que se traten como el mismo servicio en cuanto a identidad, gestión del tráfico y observabilidad.

En concreto, asegúrate de que los servicios que sean lógicamente diferentes (por ejemplo, una API de contabilidad de pagos y una API de transacciones de pago) no usen el mismo par [espacio de nombres, nombre] (por ejemplo, payments/api), ya que se tratarán como el mismo servicio una vez que estén en una malla de servicios. Esta unión conceptual se produce incluso entre límites regionales. Además, el funcionamiento de los servicios podría verse afectado.

Multi Cluster Ingress y Multi-cluster Gateway también asumen que el espacio de nombres o el nombre del servicio son iguales al dirigir el tráfico a los servicios de varios clústeres, aunque solo en el caso de los servicios que se exponen fuera de los clústeres.

Considerar la identidad de carga de trabajo

Una función potente de las flotas es la federación de identidades de cargas de trabajo en toda la flota. De esta forma, se amplían las funciones que ofrece la federación de identidades de cargas de trabajo para GKE, que permite que las cargas de trabajo de tu clúster se autentiquen en Google sin que tengas que descargar, rotar manualmente y gestionar en general las Google Cloud claves de cuentas de servicio. En su lugar, las cargas de trabajo se autentican mediante tokens de corta duración generados por los clústeres. Cada clúster se añade como proveedor de identidades a un grupo de identidades de carga de trabajo especial. Las cargas de trabajo que se ejecutan en un espacio de nombres específico pueden compartir la misma identidad de gestión de identidades y accesos en varios clústeres.

Mientras que la federación de identidades de carga de trabajo normal para GKE usa un grupo de identidades de todo el proyecto, la federación de identidades de carga de trabajo de toda la flota usa un grupo de identidades de carga de trabajo de toda la flota, aunque los clústeres estén en proyectos diferentes, con la misma identidad implícita en toda la flota, así como la misma identidad de espacio de nombres y de servicio. De esta forma, es más sencillo configurar la autenticación de tus aplicaciones en varios proyectos, pero puede haber consideraciones sobre el control de acceso adicionales a las de la federación de identidades de carga de trabajo normal para GKE si decides usarla en flotas de varios proyectos, sobre todo si el proyecto host de la flota tiene una combinación de clústeres de flota y que no son de flota.

Para obtener más información sobre la federación de identidades de cargas de trabajo de flotas y cómo usarla para acceder a los servicios de Google Cloud , consulta el artículo Usar la identidad de cargas de trabajo de flotas. Para obtener directrices sobre cómo minimizar los riesgos con la federación de identidades de cargas de trabajo de flotas, así como algunos ejemplos, consulta las prácticas recomendadas para usar la identidad de cargas de trabajo de flotas.

Valores predeterminados a nivel de flota

GKE ofrece la posibilidad de definir valores predeterminados a nivel de flota para determinadas funciones empresariales, como Cloud Service Mesh, Config Sync y Policy Controller. De esta forma, puedes configurar clústeres para que usen estas funciones sin tener que configurar cada clúster por separado. Por ejemplo, un administrador puede habilitar Policy Controller en su flota y definir políticas predeterminadas a nivel de flota. De esta forma, se instala el agente necesario en los nuevos clústeres miembros de la flota y se les aplican las políticas predeterminadas.

Sin embargo, estos valores predeterminados solo se aplican automáticamente a los clústeres nuevos que añadas a la flota en el momento de la creación del clúster. Los clústeres y sus cargas de trabajo no se verán afectados, aunque ya los hayas añadido a la flota o los añadas después de configurar los valores predeterminados de la función. Esto significa que puedes configurar valores predeterminados a nivel de flota sin habilitar ni configurar funciones en clústeres en los que no estés preparado para hacerlo. Siempre puedes aplicar los ajustes predeterminados a los clústeres que ya tengas más adelante.

Requisitos de las funciones

Hay algunas limitaciones que debes tener en cuenta al implementar flotas en función de las funciones de flota que quiera usar tu organización. Por ejemplo, algunas funciones no admiten el uso de clústeres que no estén en el proyecto host de la flota, mientras que otras no se admiten en clústeres externos a Google Cloud.

En la siguiente tabla se muestran los requisitos y las limitaciones actuales de cada componente, así como algunas directrices específicas en las secciones siguientes.

Función
 Tipos de clústeres
 Requisitos del proyecto
 Requisitos de VPC
Config Sync Todos los clústeres compatibles con GKE Ninguno Ninguno
Policy Controller Todos los clústeres compatibles con GKE Ninguno Ninguno
Cloud Service Mesh Consulta las limitaciones. Todos los clústeres que se usen con Cloud Service Mesh y que estén en el mismo proyecto deben registrarse en la misma flota. Para obtener más información, consulta los requisitos de la flota de Cloud Service Mesh. Los clústeres de GKE deben estar en la misma red de VPC.
Servicios de varios clústeres (MCS) GKE en Google Cloud Ninguno Consulta MCS en VPC compartida.
Entrada de varios clústeres y pasarela de varios clústeres GKE en Google Cloud Los recursos de entrada y de puerta de enlace, los clústeres de GKE y la flota deben estar en el mismo proyecto. Los recursos de entrada y de puerta de enlace, así como los clústeres de GKE, deben estar en la misma red de VPC.
Grupos de identidades de carga de trabajo Optimizado para GKE en Google Cloud y Google Distributed Cloud en VMware. Se admiten otros clústeres de Kubernetes, pero requieren una configuración adicional. Ninguno Ninguno
Autorización binaria GKE on Google Cloud, Google Distributed Cloud on VMware, Google Distributed Cloud on bare metal Ninguno Ninguno
Advanced Vulnerability Insights GKE en Google Cloud Ninguno Ninguno
Posición de seguridad GKE en Google Cloud Ninguno Ninguno
Posición de cumplimiento GKE en Google Cloud Ninguno Ninguno
Métricas de uso de recursos de la flota GKE en Google Cloud Ninguno Ninguno
Registro de flotas Todo Ninguno Ninguno
Pasarela de conexión Todo Ninguno Ninguno
Gestión de equipos de flotas Todo Ninguno Ninguno
Políticas de red de FQDN de pods GKE en Google Cloud Ninguno Ninguno
Cifrado transparente entre nodos GKE en Google Cloud Ninguno Ninguno
Config Controller No aplicable Ninguno Ninguno
Secuenciación de lanzamientos GKE en Google Cloud Ninguno Ninguno

Tener en cuenta los requisitos de la nube privada virtual

Si tienes previsto usar una función como Cloud Service Mesh, que requiere que los clústeres estén en una sola red de nube privada virtual (VPC), como se muestra en la tabla anterior, debes crear una flota para cada VPC. Si no tienes previsto usar esas funciones, puedes incluir varias VPCs en una flota.

Por ejemplo, un patrón habitual es que una organización tenga varios proyectos, cada uno con su propia VPC predeterminada. Es posible que ya tengan conexiones de peering entre sí. Si no usas una función que requiera una sola VPC, todos estos elementos se pueden colocar en una sola flota. Otro patrón habitual sigue una topología de "concentrador y radios", que usa varias VPCs. Si no usas ninguna función que requiera una sola VPC, puedes colocar clústeres de todas esas VPCs en una sola flota. Ten en cuenta que, en algunos casos, si sigues estas directrices, es posible que tengas flotas con un solo clúster. En ese caso, es posible que tengas que renunciar a usar funciones con restricciones de VPC y crear flotas de varios proyectos, o bien reconsiderar tu arquitectura y mover las cargas de trabajo según sea necesario.

Requisitos de las redes de varios clústeres

Si quieres usar Multi Cluster Ingress o pasarelas de varios clústeres para gestionar el tráfico, ten en cuenta que, en ambos casos, el controlador de la pasarela no puede abarcar proyectos. Esto significa que todos los clústeres que quieras usar con estas funciones deben estar en el mismo proyecto y en la misma flota. Si necesitas crear flotas que incluyan clústeres de varios proyectos, puedes usar en su lugar las pasarelas de un solo clúster y dirigir el tráfico a la pasarela correcta de otra forma (por ejemplo, mediante DNS). Los clústeres que usen estas funciones también deben estar en la misma red de VPC.

Siguientes pasos