Planifica las funciones de la flota

Una parte importante de la planificación de las flotas es decidir qué funciones habilitadas para la flota deseas usar. En particular, si trabajas con clústeres y cargas de trabajo de producción existentes, te recomendamos que identifiques las funciones de la flota que se puedan adoptar de inmediato con la menor fricción o riesgo para tus aplicaciones existentes, mientras planificas otras funciones que podrían requerir una adopción más gradual o cuidadosa. En esta guía, se describen los diferentes tipos de funciones habilitadas mediante el uso de flotas y sus requisitos, y se proporciona orientación práctica sobre la adopción de funciones.

Muchas de las funciones que se describen en esta guía solo están disponibles como parte de GKE Enterprise. Para obtener más detalles, consulta Opciones de implementación de GKE Enterprise.

Esta guía está dirigida a los arquitectos de la nube que desean comenzar a usar flotas en sus organizaciones. Antes de leer esta guía, asegúrate de estar familiarizado con la Descripción general de la administración de flotas y los Recursos de planificación de flota, en el que se analiza la organización de clústeres nuevos o existentes en flotas.

Prácticas recomendadas para la adopción de funciones

Todas las funciones de la flota (excepto la visibilidad básica de la flota) son de solicitud de aceptación, por lo que debes especificar que quieres usarlas. Solo agregar un clúster existente a una flota no cambia su configuración. Cuando decidas usar las funciones de la flota, algunas se pueden habilitar de inmediato con un riesgo mínimo, pero es posible que debas abordar algunas funciones con más cuidado. En esta sección, se proporciona orientación para la adopción de funciones.

En particular, con los clústeres y las cargas de trabajo existentes, debes tener especial cuidado cuando las funciones usan similitud. Este es un concepto de flota en el que la función supone que los espacios de nombres, los servicios o las identidades con el mismo nombre en diferentes clústeres son lo mismo. Puedes obtener más información sobre el principio de similitud y qué funciones lo usan en Cómo funcionan las flotas.

Integra funciones de bajo riesgo

Las siguientes funciones “ambientes” no suponen ningún tipo de similitud y no afectan de ninguna manera a los clústeres. Se pueden usar de forma segura incluso con cargas de trabajo y clústeres existentes, lo que te permite beneficiarte de inmediato de la observabilidad y las estadísticas de seguridad mejoradas en toda tu flota, así como de la capacidad de administrar el orden de las actualizaciones de clústeres según la membresía de la flota.

Las siguientes funciones se instalan en clústeres individuales. Las funciones pueden suponer igualdad, pero solo cuando se configuran o especifican recursos en varios clústeres. Esto significa que puedes habilitar de forma segura estas funciones en tus clústeres con las cargas de trabajo existentes y solo necesitas considerar la similitud cuando crees o uses configuraciones para ellos que usen estos selectores opcionales.

Integra funciones avanzadas de varios clústeres

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

Por ejemplo, si tienes espacios de nombres de Kubernetes existentes con el mismo nombre en diferentes clústeres y aplicaciones (incluido el espacio de nombres predeterminado), debes verificar que deseas 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 comprender qué extremos de servicio se combinarán en tus clústeres y confirmar que este es el comportamiento deseado.

Audita la similitud de espacios de nombres

Si conoces bien tus aplicaciones, puedes auditar tus espacios de nombres con solo verificar que ninguna aplicación “diferente” use el mismo espacio de nombres. En particular, ten en cuenta el uso ad hoc del espacio de nombres predeterminado. Por ejemplo, si tienes un espacio de nombres llamado default en un clúster y un espacio de nombres llamado default en otro clúster, pero se usan para diferentes propósitos, debes cambiar el nombre de uno de ellos.

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

  • en cada clúster, las mismas reglas de RBAC están en el clúster y el espacio de nombres de los principales tiene acceso al espacio de nombres.
  • que el conjunto de imágenes que usan los Pods (menos hash/etiqueta) es el mismo.
  • el conjunto de Secrets que usan los Pods es idéntico.

Si todos estos son verdaderos, los espacios de nombres son lo suficientemente similares para tratarlos como “los mismos”.

Si tus espacios de nombres no son lo suficientemente similares, puedes migrar apps a espacios de nombres nuevos. Una vez que estés satisfecho de suponer la similitud de espacio de nombres, puedes activar las características que la usan.

Audita la similitud de servicios

Si quieres adoptar Cloud Service Mesh para administrar tus aplicaciones basadas en microservicios, otro problema que debes considerar es la similitud del servicio. Esto significa que, para cualquier combinación de espacio de nombres y nombre de servicio, Cloud Service Mesh las tratará como el mismo servicio lógico en términos de lo siguiente:

  • Identidad (específicamente para la seguridad de Cloud Service Mesh): Si namespace1/service1 está autorizado para hacer algo, las cargas de trabajo con esa identidad de cualquier clúster también lo están.
  • Administración de tráfico: De forma predeterminada, el tráfico se balancea entre los servicios de namespace1/service1 en cualquier clúster.
  • Observabilidad: las métricas de namespace1/service1 de todos los clústeres se agregan juntas.

Si habilitas Cloud Service Mesh con clústeres y aplicaciones nuevos, te recomendamos reservar combinaciones únicas de espacio de nombres y nombre de servicio en toda tu malla. En el caso de las aplicaciones existentes, audita tus servicios para asegurarte de que los servicios con el mismo espacio de nombres y nombre en todos tus clústeres sean aquellos que deseas que se traten como el mismo servicio en términos de identidad, administración de tráfico y observabilidad.

En particular, asegúrate de que los servicios lógicamente diferentes (por ejemplo, una API de contabilización de pagos y una API de transacción de pagos) 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 ocurre incluso entre límites regionales. Además, la función de los servicios puede verse afectada.

Ingress de varios clústeres y la puerta de enlace de varios clústeres también suponen la similitud de espacio de nombres o de nombre de Service cuando se dirige el tráfico a servicios en varios clústeres, pero solo para servicios que están expuestos fuera de los clústeres.

Considera la identidad de cargas de trabajo

Una función potente de flota es la federación de identidades para cargas de trabajo en toda la flota. Esto amplía las capacidades proporcionadas en la federación de identidades para cargas de trabajo para GKE, que permite que las cargas de trabajo de tu clúster se autentiquen en Google sin necesidad de descargarlas, rotarlas de forma manual y, en general, administrar las claves de las cuentas de servicio de Google Cloud. En su lugar, las cargas de trabajo se autentican mediante tokens de corta duración generados por los clústeres, y cada clúster se agrega como un proveedor de identidad a un grupo de identidades para cargas de trabajo especial. Las cargas de trabajo que se ejecutan en un espacio de nombres específico pueden compartir la misma identidad de Identity and Access Management en todos los clústeres.

Si bien la federación normal de identidades para cargas de trabajo para GKE usa un grupo de identidad en todo el proyecto, la federación de identidades para cargas de trabajo en toda la flota usa un grupo de identidades para cargas de trabajo para toda la flota, incluso si los clústeres están en diferentes proyectos, con similitud implícita para las identidades en toda la flota, así como similitud de espacio de nombres y servicio. Esto facilita la configuración de la autenticación para tus aplicaciones en todos los proyectos, pero puede tener consideraciones de control de acceso sobre las de la federación regular de identidades para cargas de trabajo para GKE si eliges usarla en flotas de varios proyectos, en especial si el proyecto host de la flota tiene una mezcla de clústeres de flotas y no de flotas.

Si deseas obtener más información sobre la federación de identidades para cargas de trabajo de la flota y cómo usarla para acceder a los servicios de Google Cloud, consulta Usa Workload Identity de la flota. Si deseas obtener orientación para minimizar el riesgo con la federación de identidades para cargas de trabajo con algunos ejemplos, consulta Prácticas recomendadas para usar Workload Identity de la flota.

Valores predeterminados a nivel de la flota

GKE Enterprise proporciona la capacidad de establecer valores predeterminados a nivel de la flota para ciertas funciones empresariales, como Cloud Service Mesh, el Sincronizador de configuración y Policy Controller. Esto te ayuda a configurar clústeres para usar estas funciones sin tener que configurar cada clúster de forma individual. Por ejemplo, un administrador puede habilitar Policy Controller para su flota y establecer políticas predeterminadas a nivel de la flota. Esto instala el agente requerido en los clústeres de miembros de la flota nuevos y les aplica políticas predeterminadas.

Sin embargo, estos valores predeterminados solo se aplican automáticamente a los clústeres nuevos que agregues a la flota en el momento de su creación. Los clústeres existentes y sus cargas de trabajo no se ven afectados, incluso si ya los agregaste a la flota o si agregas los clústeres después de configurar los valores predeterminados de las funciones. Esto significa que puedes configurar de forma segura los valores predeterminados a nivel de la flota sin arriesgarte a habilitar o configurar funciones en clústeres en los que no estás listo para hacerlo. Siempre puedes optar por aplicar la configuración predeterminada a los clústeres existentes más adelante.

Requisitos sobre las características

Debes tener en cuenta algunas limitaciones cuando implementes flotas basadas en las funciones de flota que tu organización quiera usar. Por ejemplo, algunas funciones no admiten el trabajo con clústeres que no están en el proyecto host de flota, mientras que otras no son compatibles con clústeres fuera de Google Cloud.

En la siguiente tabla, se muestran los requisitos y las limitaciones actuales de cada componente, con algunos lineamientos específicos en las siguientes secciones.

Función
 Tipos de clústeres
 Requisitos del proyecto
 Requisitos de VPC
Sincronizador de configuración Todos los clústeres compatibles con GKE Enterprise Ninguno Ninguno
Policy Controller Todos los clústeres compatibles con GKE Enterprise Ninguno Ninguno
Cloud Service Mesh Consulta las limitaciones. Todos los clústeres que se usan con Cloud Service Mesh que se encuentran en el mismo proyecto deben estar registrados 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 una VPC compartida
Ingress de varios clústeres y la puerta de enlace de varios clústeres GKE en Google Cloud Los recursos de Ingress/puerta de enlace, los clústeres de GKE y la flota deben estar en el mismo proyecto. Los recursos de Ingress/puerta de enlace y los clústeres de GKE deben estar en la misma red de VPC.
Grupos de Workload Identity Optimizado para GKE en Google Cloud y Google Distributed Cloud en VMware. Se admiten otros clústeres de Kubernetes, pero se requiere un trabajo de configuración adicional. Ninguno Ninguno
Autorización binaria GKE en Google Cloud, Google Distributed Cloud en VMware, Google Distributed Cloud en Bare Metal Ninguno Ninguno
Advanced Vulnerability Insights GKE en Google Cloud Ninguno Ninguno
Postura de seguridad GKE en Google Cloud Ninguno Ninguno
Postura sobre el cumplimiento GKE en Google Cloud Ninguno Ninguno
Métricas de uso de recursos de flotas GKE en Google Cloud Ninguno Ninguno
Registro de flotas Todos Ninguno Ninguno
Conecta la puerta de enlace Todos Ninguno Ninguno
Administración de equipos de la flota Todos Ninguno Ninguno
Políticas de red de FQDN del Pod GKE en Google Cloud Ninguno Ninguno
Encriptación transparente entre nodos GKE en Google Cloud Ninguno Ninguno
Config Controller No aplicable Ninguno Ninguno
Secuenciación de lanzamiento GKE en Google Cloud Ninguno Ninguno

Considera los requisitos de la nube privada virtual

Si planeas usar una función como Service Mesh de Cloud 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 planeas usar esas funciones, se pueden colocar varias VPC en una sola flota.

Por ejemplo, un patrón común es que una organización tenga varios proyectos, cada uno con su propia VPC predeterminada. Es posible que tengan conexiones de intercambio de tráfico existentes entre sí. Si no usas una función con requisitos de VPC única, todas se pueden colocar en una sola flota. Otro patrón común sigue una topología de "concentrador y radios", que usa varias VPC. Si no usas una función con requisitos de VPC única, puedes colocar clústeres de todas esas VPC en una flota. Ten en cuenta que, en algunos casos, seguir estos lineamientos puede dar como resultado que tengas flotas que tengan solo un clúster. En ese caso, es posible que debas omitir el uso de funciones con restricciones de VPC y crear flotas de varios proyectos o reconsiderar la arquitectura y mover las cargas de trabajo, según corresponda.

Requisitos para las herramientas de redes de varios clústeres

Si deseas usar Ingress de varios clústeres o puertas de enlace de varios clústeres para la administración de tráfico, ten en cuenta que, en ambos casos, el controlador de puerta de enlace no puede abarcar proyectos. Esto significa que todos los clústeres que desees 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 puertas de enlace de un solo clúster y dirigir el tráfico a la Gateway correcta de otra manera (por ejemplo, mediante DNS). Los clústeres que usan estas funciones también deben estar en la misma red de VPC.

¿Qué sigue?