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 Anthos 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 algunos objetos de Kubernetes, como los espacios de nombres con el mismo nombre en diferentes clústeres, se tratan de la misma manera. Esta normalización se realiza para que la administración de los recursos de flotas sea más manejable. 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.
Similitud de espacio de nombres
El ejemplo fundamental de similitud en una flota es la similitud de espacio de nombres. Los espacios de nombres con el mismo nombre en clústeres diferentes se consideran como los mismos por muchos componentes. 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 Anthos 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 Anthos 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
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 Anthos Service Mesh para crear una malla de servicios de varios clústeres en la que frontend tiene acceso a backend.
Con Anthos 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.
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 Workload Identity
Una flota ofrece un grupo de Workload Identity 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.Anthos Service Mesh
Anthos Service Mesh es un conjunto 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.Entrega de Knative
La entrega de Knative 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 nuestros requisitos y prácticas recomendadas para flotas.