Planifica las funciones de la flota

Una parte importante de la planificación de flotas es decidir qué funciones habilitadas para flotas quieres usar. En particular, si trabajas con clústeres existentes y cargas de trabajo de producción, tal vez quieras identificar las funciones de la flota que se pueden 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 que se habilitan con el uso de flotas y sus requisitos, y se brinda orientación práctica sobre la adopción de funciones.

Esta guía está dirigida a los arquitectos de Cloud que desean comenzar a usar flotas en sus organizaciones. Antes de leer esta guía, asegúrate de conocer nuestra Descripción general de la administración de flotas y Planifica los recursos de la flota, en las que se explica cómo organizar clústeres nuevos o existentes en flotas.

Prácticas recomendadas para la adopción de funciones

Todas las funciones de flota (excepto la observabilidad básica de la flota) son opcionales, ya que debes especificar que deseas usarlas. El simple hecho de agregar un clúster existente a una flota no cambia su configuración. Cuando decidas usar las funciones de flota, algunas se pueden habilitar de inmediato con un riesgo mínimo, pero es posible que debas abordar otras 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 con los lugares en los que las funciones usan la 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 "ambientales" no suponen ningún tipo de similitud y no afectan los clústeres de ninguna manera. Todos se pueden usar de forma segura, incluso con cargas de trabajo y clústeres existentes, lo que te permite beneficiarte de inmediato de una mayor observabilidad y estadísticas de seguridad 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 la igualdad, pero solo cuando se configuran o especifican recursos en varios clústeres. Esto significa que puedes habilitar estas funciones de forma segura en tus clústeres con cargas de trabajo existentes y solo debes tener en cuenta la igualdad cuando crees o uses configuraciones para ellos que utilicen 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 más cuidado con estas funciones, ya que todas requieren que se suponga uno o más tipos de igualdad para que funcionen, 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 quieras 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 no haya dos aplicaciones "diferentes" que usen el mismo espacio de nombres. En particular, 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 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 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 las entidades principales tiene acceso al espacio de nombres.
  • El conjunto de imágenes que usan los Pods (sin el hash ni la etiqueta) es el mismo.
  • El conjunto de Secrets que usan los Pods es idéntico.

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

Si tus espacios de nombres no son lo suficientemente similares, puedes migrar apps a espacios de nombres nuevos. Una vez que te sientas cómodo con la suposición de que los espacios de nombres son iguales, puedes activar las funciones 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 del 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 en todos los clústeres se agregan.

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 del 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.

La similitud de nombre y espacio de nombres del Service también se supone en Ingress de varios clústeres y en la Gateway de varios clústeres cuando se dirige el tráfico a los Services en varios clústeres, aunque solo para los Services que se exponen 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 extiende 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 que tengas que descargar, rotar de forma manual y, en general, administrar Google Cloud las claves de cuentas de servicio. En su lugar, las cargas de trabajo se autentican con tokens de corta duración generados por los clústeres, y cada clúster se agrega como 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 además de las de la Workload Identity Federation for GKE normal si eliges usarla en flotas de varios proyectos, en especial si el proyecto host de la flota tiene una combinación de clústeres de flota y no de flota.

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 permite 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 agregas a la flota en el momento de la creación del clúster. Los clústeres existentes y sus cargas de trabajo no se ven afectados, incluso si ya los agregaste a la flota o si los agregas después de configurar los valores predeterminados de la función. Esto significa que puedes configurar de forma segura los valores predeterminados a nivel de la flota sin correr el riesgo de 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 la 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 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 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 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 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 planeas usar esas funciones, puedes colocar varias VPC en una 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 estos tengan conexiones de intercambio de tráfico existentes entre sí. Si no usas una función con requisitos de una sola VPC, todos estos elementos se pueden colocar en una sola flota. Otro patrón común sigue una topología de "concentrador y radio", que usa varias VPC. Si no usas una función con requisitos de una sola VPC, puedes colocar clústeres de todas esas VPCs en una sola flota. Ten en cuenta que, en algunos casos, seguir estos lineamientos puede hacer que tengas flotas con un solo clúster. En ese caso, es posible que debas renunciar al uso de funciones con restricciones de VPC y crear flotas de varios proyectos, o bien reconsiderar tu arquitectura y mover las cargas de trabajo según corresponda.

Requisitos para las redes de varios clústeres

Si deseas usar Ingress de varios clústeres o Gateways de varios clústeres para la administración del tráfico, ten en cuenta que, en ambos casos, el controlador de la puerta de enlace no puede abarcar varios 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 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?