En esta página, se proporciona una explicación detallada sobre cómo las flotas te ayudan a administrar implementaciones de varios clústeres, incluida la terminología y los conceptos clave de la flota. Environ es un concepto de Google Cloud que organiza de manera lógica los clústeres y otros recursos, lo que te permite usar y administrar capacidades de varios clústeres y aplicar políticas coherentes en tus sistemas. Las flotas forman una parte fundamental del funcionamiento de la función de varios clústeres empresariales en Google Cloud.
Esta guía está diseñada para lectores técnicos, incluidos los arquitectos de sistemas, los operadores de plataformas y los operadores de servicios, que desean aprovechar varios clústeres y una infraestructura relacionada. Estos conceptos son útiles en cualquier lugar en el que tu organización ejecute múltiples clústeres, ya sea en Google Cloud, en varios proveedores de servicios en la nube o de forma local.
Debes conocer los conceptos básicos de Kubernetes, como los clústeres y los espacios de nombres. Si no los conoces, consulta los conceptos básicos de Kubernetes, la documentación de GKE y Prepara una aplicación para Cloud Service Mesh.
Si deseas obtener más información sobre la plataforma de GKE Enterprise y los componentes que usan las flotas, consulta nuestra descripción general técnica de GKE Enterprise y el instructivo Explora GKE Enterprise. Sin embargo, no necesitas conocer GKE Enterprise para seguir esta guía.
Terminología
Los siguientes son algunos de los términos importantes que usamos cuando hablamos sobre flotas.
Recursos habilitados para la flota
Los recursos habilitados para la flota son recursos de proyectos de Google Cloud que se pueden agrupar y administrar de forma lógica como flotas. Actualmente, solo los clústeres de Kubernetes pueden ser miembros de la flota.
Proyecto host de flotas
La implementación de flotas, como muchos otros recursos de Google Cloud, se basa en un proyecto de Google Cloud, que denominamos proyecto host de la flota. Un proyecto de Google Cloud determinado solo puede tener una flota (o ninguna flota) asociada. Esta restricción refuerza el uso de proyectos de Google Cloud para proporcionar un aislamiento más sólido entre los recursos que no se rigen ni se consumen juntos.
Infraestructura de agrupación
El primer concepto importante de las flotas es el de agrupación, es decir, elegir qué partes de los recursos habilitados para la flota relacionados deben formar parte de una flota. Para decidir qué agrupar, se deben responder las siguientes preguntas:
- ¿Los recursos se relacionan entre sí?
- Los recursos que tienen grandes cantidades de comunicaciones de servicios se benefician en mayor medida de administrarse en conjunto en una flota.
- Los recursos en el mismo entorno de implementación (por ejemplo, el entorno de producción) deben administrarse juntos en una flota.
- ¿Quién administra los recursos?
- Tener control unificado (o, al menos, que se pueda confiar de forma mutua) sobre los recursos es fundamental para garantizar la integridad de las flotas.
Para ilustrar este punto, considera una organización que tenga varias líneas de negocios (LOB). En este caso, los servicios rara vez se comunican entre los límites de LOB, los servicios en diferentes LOB se administran de manera diferente (por ejemplo, los ciclos de actualización difieren entre los LOB) y pueden tener un conjunto de administradores diferente para cada LOB. En este caso, puede que sea conveniente tener flotas por LOB. Cada LOB también puede adoptar varias flotas para separar sus servicios de producción y de no producción.
A medida que se analizan otros conceptos de flotas en las siguientes secciones, puedes encontrar otras razones para crear varias instancias de flotas mientras consideras tus necesidades organizativas específicas.
Similitud
Un concepto importante en las flotas es el de similitud. Esto significa que, cuando usas ciertas funciones habilitadas para la flota, algunos objetos de Kubernetes, como los espacios de nombres que tienen el mismo nombre en diferentes clústeres, se tratan como si fueran lo mismo. Esta normalización se realiza para facilitar la administración de los recursos de flotas. Si usas funciones que aprovechan la similitud, esta suposición de similitud proporciona orientación sólida sobre cómo configurar identidades, espacios de nombres y servicios. Sin embargo, también sigue procesos que la mayoría de las organizaciones ya implementan por sí mismas.
Los diferentes tipos de igualdad proporcionan diferentes beneficios, como se muestra en la siguiente tabla:
| Propiedad de similitud | TE PERMITE… |
|---|---|
| Un espacio de nombres se considera el mismo en varios clústeres. |
|
| Una combinación de espacio de nombres y nombre de servicio se considera la misma en varios clústeres. Los servicios con el mismo nombre en el mismo espacio de nombres usan el mismo selector de etiquetas. |
|
| Una combinación de espacio de nombres y cuenta de servicio (identidad) se considera igual en varios clústeres. |
|
Como se sugiere, las diferentes funciones de la flota se basan en diferentes tipos de similitud. Una menor cantidad de atributos no usa la misma cantidad. Puedes obtener más información sobre esto en ¿Qué funciones usan la similitud?, donde se incluyen las funciones que puedes usar sin tener que considerar la similitud en toda la flota y las que pueden requerir una planificación más cuidadosa.
Similitud de espacio de nombres
El ejemplo fundamental de similitud en una flota es la similitud de espacio de nombres. Muchos componentes consideran que los espacios de nombres con el mismo nombre en clústeres diferentes son los mismos. Otra manera de pensar en esta propiedad es que un espacio de nombres se define lógicamente a través de una flota completa, incluso si la instancia del espacio de nombres existe solo en un subconjunto de los recursos de la flota.
Considera el siguiente ejemplo de espacio de nombres backend. Aunque la instancia del espacio de nombres solo se crea en los clústeres A y B, se reserva de forma implícita en el clúster C (permite que el espacio de nombres backend también se programe en el clúster C si es necesario).
Esto significa que los espacios de nombres se asignan a toda la flota y no a cada clúster. Por lo tanto, la similitud de espacios de nombres requiere una propiedad coherente de espacio de nombres en toda la flota.
Similitud de servicio
Ingress de varios clústeres y Cloud Service Mesh usan el concepto de similitud de servicios dentro de un espacio de nombres. Al igual que la similitud de espacio de nombres, esto significa que los servicios con el mismo espacio de nombres y nombre de servicio se consideran como el mismo servicio.
Los extremos del servicio pueden combinarse en la malla en el caso de Cloud Service Mesh. Con Ingress para varios clústeres, un recurso MultiClusterService (MCS) hace que el extremo sea más explícito. Sin embargo, recomendamos prácticas similares con respecto a los nombres. Debido a esto, es importante garantizar que los servicios con nombres idénticos dentro del mismo espacio de nombres en realidad sean los mismos.
En el siguiente ejemplo, el tráfico de Internet se balancea en un servicio de igual nombre en el espacio de nombres frontend presente en los clústeres B y C. De manera similar, si usas las propiedades de la malla de servicios dentro de la flota, el servicio en el espacio de nombres frontend puede llegar a un servicio con el mismo nombre en el espacio de nombres auth presente en los clústeres A y C.
Similitud de identidad cuando se accede a recursos externos
Con la federación de identidades para cargas de trabajo de la flota, los servicios que están dentro de una flota pueden aprovechar una identidad común a medida que salen para acceder a recursos externos como los servicios de Google Cloud, los almacenes de objetos, etcétera. Esta identidad común permite dar a los servicios dentro de una flota acceso a un recurso externo una vez y no por clúster.
Para ilustrar este punto con más detalle, considera el siguiente ejemplo. Los clústeres A, B y C están inscritos en identidad común dentro de su flota. Cuando los servicios en el espacio de nombres backend acceden a los recursos de Google Cloud, sus identidades se mapean a una cuenta de servicio común de Google Cloud llamada back. Se puede autorizar la cuenta de servicio de Google Cloud back en cualquier cantidad de servicios administrados, desde Cloud Storage hasta Cloud SQL. A medida que se agregan nuevos recursos de flota, como los clústeres se agregan en el espacio de nombres backend, heredan de forma automática las propiedades de similitud de la carga de trabajo.
Debido a la similitud de la identidad, es importante que todos los recursos de una flota sean confiables y estén bien controlados. En el ejemplo anterior, si el clúster C es propiedad de un equipo independiente que no es de confianza, también pueden crear un espacio de nombres de backend y acceder a los servicios administrados como si fueran el backend en el clúster A. o B.
Similitud de identidad dentro de una flota
Dentro de la flota, la similitud de identidad se utiliza de la misma manera que la similitud de identidad externa que mencionamos antes. Así como los servicios de flota están autorizados una vez para un servicio externo, también se pueden autorizar internamente.
En el siguiente ejemplo, usamos Cloud Service Mesh para crear una malla de servicios de varios clústeres en la que frontend tiene acceso a backend.
Con Cloud Service Mesh y las flotas, no es necesario especificar que frontend en los clústeres B y C puede acceder a backend en los clústeres A y B. En su lugar, simplemente especificamos que frontend en la flota puede acceder a backend en la flota. Esta propiedad no solo simplifica la autorización, sino que también permite que los límites de recursos sean más flexibles. Ahora, las cargas de trabajo se pueden mover con facilidad de un clúster a otro sin afectar la forma en que se autorizan. Al igual que con la similitud de identidad de carga de trabajo, la administración de los recursos de la flota es fundamental para garantizar la integridad de la comunicación entre servicios.
¿Qué atributos usan la similitud?
Algunas funciones de la flota no dependen en absoluto de la similitud y se pueden habilitar y usar sin tener que considerar si deseas suponer algún tipo de similitud en toda la flota. Otras funciones (como el Sincronizador de configuración y Policy Controller) pueden usar la misma configuración, por ejemplo, si deseas seleccionar un espacio de nombres en varios clústeres de miembros de la flota para la configuración desde una única fuente de información, pero no lo requieren para todos los casos de uso. Por último, existen funciones como Ingress de varios clústeres y la federación de identidades para cargas de trabajo de toda la flota que siempre suponen algún tipo de igualdad entre los clústeres y es posible que deban adoptarse con cuidado según tus necesidades y cargas de trabajo existentes.
Algunas funciones de la flota (como la federación de identidades para cargas de trabajo de la flota) requieren que toda la flota esté preparada para las suposiciones de similitud que usan. Otras funciones, como la administración de equipos, te permiten habilitar gradualmente la identidad a nivel del espacio de nombres o del permiso del equipo.
En la siguiente tabla, se muestra qué funciones requieren uno o más de los conceptos de igualdad que se describen en esta sección.
| Función | Admite la adopción gradual de la similitud | Depende de la similitud de los espacios de nombres | Depende de la similitud del servicio | Depende de la similitud de la identidad |
|---|---|---|---|---|
| Flotas | N/A | No | No | No |
| Autorización binaria | N/A | No | No | No |
| Encriptación transparente entre nodos | N/A | No | No | No |
| Política de red basada en nombres de dominio completamente calificados | N/A | No | No | No |
| Conecta la puerta de enlace | N/A | No | No | No |
| Sincronizador de configuración | N/A | No | No | No |
| Policy Controller | N/A | No | No | No |
| Postura de seguridad de GKE | N/A | No | No | No |
| Advanced Vulnerability Insights | N/A | No | No | No |
| Postura sobre el cumplimiento | N/A | No | No | No |
| Secuenciación de lanzamiento | N/A | No | No | No |
| Administración de equipo | Sí | Sí | Sí | No |
| Ingress de varios clústeres | Sí | Sí | Sí | Sí |
| Service de varios clústeres | Sí | Sí | Sí | Sí |
| Federación de identidades para cargas de trabajo de flotas | No | Sí | Sí | Sí |
| Cloud Service Mesh | No | Sí | Sí | Sí |
Exclusividad
Los recursos habilitados para la flota solo pueden ser miembros de una sola instancia de environ en un momento determinado, una restricción que aplican las herramientas y los componentes de Google Cloud. Esta restricción garantiza que haya solo una fuente de información que rige un clúster. Sin exclusividad, incluso los componentes más simples se complicarían, lo cual requeriría a tu organización calcular y configurar la manera en la que interactuarían varios componentes de varias flotas.
Alta confianza
La similitud de servicio, la similitud de identidad de carga de trabajo y la similitud de integridad de malla se basan en un principio de confianza alta entre los miembros de una flota. Esta confianza permite mejorar la administración de estos recursos en la flota, en lugar de administrar recurso por recurso (es decir, clúster por clúster para recursos de Kubernetes), y, en última instancia, le resta importancia al límite de clúster.
Dicho de otra manera, dentro de una flota, los clústeres brindan protección contra los problemas de radio de efecto, la disponibilidad (del plano de control y la infraestructura subyacente), los vecinos ruidosos, etcétera. Sin embargo, no son un límite fuerte de aislamiento para la política y la administración, ya que los administradores de cualquier miembro de una flota pueden afectar las operaciones de los servicios en otros miembros de la instancia de environ.
Por esta razón, recomendamos que los clústeres que no sean de confianza del administrador de flotas se coloquen en sus propias flotas para mantenerlos aislados. Luego, según sea necesario, los servicios individuales se pueden autorizar en el límite de flota.
Permisos del equipo
Un permiso de equipo es un mecanismo para subdividir aún más tu flota en grupos de clústeres, lo que te permite definir los recursos habilitados para la flota que se asignan a un equipo de aplicaciones específico. Según tu caso de uso, un clúster miembro de la flota individual se puede asociar con ningún equipo, un equipo o varios equipos, lo que permite que varios equipos compartan clústeres. También puedes usar los permisos del equipo para secuenciar lanzamientos de actualizaciones de clústeres en toda tu flota, aunque esto requiere que cada clúster esté asociado solo con un solo equipo.
Un permiso de equipo puede tener espacios de nombres de flota definidos de forma explícita asociados, en los que el espacio de nombres se considera el mismo en todo el permiso. Esto te brinda un control más detallado sobre los espacios de nombres que la similitud de espacio de nombres predeterminada que proporcionan solo las flotas.
Componentes habilitados para flotas
Los siguientes componentes de GKE Enterprise y GKE aprovechan el concepto de flota, como la similitud de espacio de nombres y de identidad, para proporcionar una forma simplificada de trabajar con tus clústeres y servicios. Si deseas conocer los requisitos o las limitaciones actuales para usar flotas con cada componente, consulta los requisitos de los componentes.
Grupos de identidades para cargas de trabajo
Una flota ofrece un grupo de identidades para cargas de trabajo común que se puede usar para autenticar y autorizar cargas de trabajo de forma uniforme dentro de una malla de servicios y a servicios externos.Cloud Service Mesh
Cloud Service Mesh es un paquete de herramientas que te ayuda a supervisar y administrar una malla de servicios confiable en Google Cloud, de forma local y en otros entornos compatibles. Puedes formar una malla de servicios en clústeres que forman parte de la misma flota.Sincronizador de configuración
El Sincronizador de configuración te permite implementar y supervisar paquetes de configuración declarativas para tu sistema almacenados en una fuente de información central, como un repositorio de Git, que aprovecha los conceptos básicos de Kubernetes, como espacios de nombres, etiquetas y anotaciones Con el Sincronizador de configuración, la configuración se define en toda la flota, pero se aplican de forma local en cada uno de los recursos miembros.Policy Controller
El controlador de políticas te permite aplicar políticas declarativas a tus clústeres de Kubernetes. Las políticas actúan como protecciones y pueden ayudarte con las prácticas recomendadas, la seguridad y la administración del cumplimiento de los clústeres y la flota.Ingress de múltiples clústeres
Ingress de múltiples clústeres usa la flota para definir el conjunto de clústeres y extremos de servicio por los que se puede balancear la carga, lo que permite servicios con alta disponibilidad y reducción de latencia.Knative serving
Knative serving es una plataforma para desarrolladores de Knative compatible y administrada por Google que elimina la complejidad de la infraestructura subyacente, lo que facilita la compilación y la implementación y administrar apps y servicios en los clústeres de tu flota.
Próximos pasos
- Obtén más información sobre cuándo usar varios clústeres para satisfacer tus necesidades técnicas y empresariales en Casos de uso de varios clústeres.
- ¿Estás listo para aplicar estos conceptos en tus propios sistemas? Consulta Cómo planificar los recursos de la flota.