Presentación de Environ

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. Environ es una parte fundamental del funcionamiento de la funcionalidad de varios clústeres empresariales en Anthos. También se usa en algunas características de Google Kubernetes Engine (GKE).

En esta guía, se presenta environ: qué es una instancia de environ, dónde se usan las instancias de environ en nuestros componentes y cómo configurar tus sistemas para aprovechar las funciones de nivel de environ. También proporcionamos algunos ejemplos para ilustrar cómo environ puede ayudar a simplificar la administración de clústeres y sistemas, y las prácticas recomendadas que debes seguir cuando compilas y operas sistemas de varios clústeres con environ.

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 los casos en que tu organización ejecute varios clústeres, ya sea en Google Cloud, en múltiples proveedores de servicios en la nube o locales.

Debes conocer los conceptos básicos de Kubernetes, como los clústeres. Si no los conoces, consulta los conceptos básicos de Kubernetes, la documentación de GKE y Preparar una aplicación para Anthos Service Mesh.

Si quieres obtener más información sobre Anthos y los componentes que usan entornos, consulta nuestros instructivos Descripción general y Explora Anthos de Anthos. Sin embargo, no es necesario que estés familiarizado con Anthos para seguir esta guía.

Introducción

Por lo general, a medida que las organizaciones adoptan tecnologías nativas de la nube, como contenedores, organización de contenedores y mallas de servicios, llegan a un punto en el que ejecutar un solo clúster ya no es suficiente. Existen varios motivos por los que las organizaciones eligen implementar varios clústeres para cumplir sus objetivos técnicos y comerciales. Por ejemplo, separar la producción de entornos que no son de producción, o separar los servicios entre niveles, configuraciones regionales o equipos. Puedes obtener más información sobre los beneficios y las compensaciones incluidos en enfoques de varios clústeres en casos de uso de varios clústeres.

A medida que se incrementa la cantidad de clústeres, se vuelven cada vez más difícil gestionar y administrar de estos clústeres y los recursos dentro de ellos. A menudo, las organizaciones suelen compilar herramientas personalizadas y políticas operativas para obtener el nivel de control que necesitan.

Google Cloud proporciona el concepto environ para ayudar a los administradores a administrar varios clústeres. Un environ es una manera de agrupar y normalizar clústeres de manera lógica, lo que facilita la administración de la infraestructura. Se pueden usar los environ en el contexto de Anthos y GKE. Puedes ver una lista de los componentes de Anthos y GKE que pueden aprovechar environ en la sección componentes habilitados para environ más adelante en este documento.

Si adoptas environ, ayudas a que tu organización mejore la administración de clústeres individuales a grupos completos de clústeres. Además, la normalización que requiere environ puede ayudar a que tus equipos adopten prácticas recomendadas similares a las usadas en Google. A modo de comparación, así como el recurso de la organización es el nodo raíz de la jerarquía de recursos de Google Cloud y se usa para la política y el control de los recursos agrupados en esta, environ forma la raíz de la administración de varios clústeres.

Terminología

Los siguientes son algunos de los términos importantes que usamos cuando hablamos sobre environ.

Recursos con conocimiento de environ

Los recursos con conocimiento de environ son los recursos del proyecto de Google Cloud que se pueden agrupar y administrar lógicamente como instancias de environ. Actualmente, solo los clústeres de Kubernetes pueden ser miembros de environ, aunque revisamos las instancias de máquina virtual (VM) y, posiblemente, otros recursos podrán unirse a instancias de environ en iteraciones de plataformas futuras. Google Cloud ofrece un servicio Connect para registrar recursos como miembros de environ.

Proyecto host de environ

La implementación de entornos, como muchos otros recursos de Google Cloud, tiene permisos de administrador en un proyecto de Google Cloud, que denominamos el proyecto host de environ. Un proyecto de Cloud determinado solo puede tener un environ único (o ningún environ) asociado. Esta restricción refuerza el uso de proyectos de Cloud para proporcionar un aislamiento más sólido entre los recursos que no se rigen ni se consumen juntos.

Componentes habilitados para environ

Los siguientes componentes de Anthos y GKE aprovechan el concepto environ, 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 environ con cada componente, consulta los requisitos de los componentes.

  • Grupos de identidad de carga de trabajo (clústeres de Anthos y GKE)
    Una instancia de environ ofrece un grupo común de identidad de carga de trabajo que se puede usar para autenticar y autorizar cargas de trabajo de manera uniforme dentro de una malla de servicios y para los servicios externos.

  • Anthos Service Mesh (Anthos)
    Anthos Service Mesh es un conjunto de herramientas que te ayuda a supervisar y administrar una malla de servicios confiable en Google Cloud o de forma local. Puedes formar una malla de servicios entre los recursos (como clústeres y VM) que forman parte del mismo environ.

  • Anthos Config Management (Anthos) y Sincronizador de configuración (GKE)
    Anthos Config Management te permite implementar y supervisar cambios en la configuración y en las políticas declarativas para tu sistema almacenado en un repositorio Git central, lo que permite aprovechar los conceptos principales de Kubernetes, como los espacios de nombres, las etiquetas y las anotaciones. Con Anthos Config Management (y el Sincronizador de configuración para clústeres que no son de Anthos), la política y la configuración se definen en toda la instancia de environ, pero se aplican de forma local en cada uno de los recursos de miembros.

  • Ingress de múltiples clústeres (Anthos)
    Ingress de múltiples clústeres usa environ para definir el conjunto de clústeres y extremos de servicio por los que se puede balancear el tráfico, lo que permite servicios con alta disponibilidad y reducción de latencia.

Infraestructura de agrupación

El primer concepto importante de environ es el concepto de agrupación, es decir, elegir qué piezas recursos con conocimiento de Environ relacionado debe formar parte de un Environ. Para decidir qué agrupar, se deben responder las siguientes preguntas:

  • ¿Los recursos se relacionan entre sí?
    • Los recursos que tienen una gran cantidad de comunicaciones entre servicios obtienen más beneficios de administrarse juntos en una instancia de environ.
    • Los recursos en el mismo entorno de implementación (por ejemplo, el entorno de producción) deben administrarse juntos en una instancia de environ.
  • ¿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 environ.

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 environ por LOB. Cada LOB también puede adoptar varios environ para separar sus servicios de producción y de no producción.

A medida que se analizan otros conceptos de environ en las siguientes secciones, puedes encontrar otras razones para crear varias instancias de environ mientras consideras tus necesidades organizativas específicas.

Similitud

Un concepto importante en los entornos es el concepto de lo mismo. Esto significa que algunos objetos de Kubernetes, como los clústeres con el mismo nombre en diferentes contextos, se tratan de la misma manera. Esta normalización se lleva a cabo para que los recursos de environ de administración se puedan ver mejor. Se proporciona orientación para configurar espacios de nombres, identidades y servicios. Sin embargo, también sigue lo que descubrimos que la mayoría de las organizaciones ya se implementan por sí mismas.

Similitud de espacio de nombres

El ejemplo fundamental de similitud en environ 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 instancia completa de environ, incluso si la instancia del espacio de nombres existe solo en un subconjunto de los recursos de environ.

Considera el siguiente ejemplo de espacio de nombres backend. Aunque el espacio de nombres se crea una instancia solo en los clústeres A y B, se reserva de forma implícita en el clúster C (permite que el servicio backend también se programe en el clúster C si es necesario). Esto significa que los espacios de nombres se asignan para el entorno completo y no por clúster. Por lo tanto, la misma espacio de nombres requiere propiedad de espacio de nombres coherente en todo el entorno.

Diagrama que ilustra la similitud de espacios de nombres en environ
Similitud de espacios de nombres en environ

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 nombres de servicio 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. Del mismo modo, mediante las propiedades de la malla de servicios dentro del environ, el servicio frontend puede alcanzar un servicio con el mismo nombre en el espacio de nombres auth presente en los clústeres A y C.

Diagrama en el que se ilustra la similitud de servicio en environ
Similitud de servicio en environ

Similitud de identidad cuando se accede a recursos externos

Los servicios que están dentro de una instancia de environ 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 instancia de environ 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 environ. 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 environ, 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 identidad, es importante que todos los recursos de una instancia de environ 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.

Diagrama que ilustra la similitud de identidad en el acceso a recursos fuera de una instancia de environ
Similitud de identidad en el acceso a recursos fuera de una instancia de environ

Similitud de identidad dentro de una instancia de environ

Dentro de environ, la similitud de identidad se utiliza de la misma manera que la similitud de identidad externa que mencionamos antes. Así como los servicios de environ 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 los entornos, no necesitamos especificar que frontend en los clústeres B y C pueda acceder a backend en los clústeres A y B. En su lugar, solo especificamos que frontend en la instancia de environ puede acceder a backend la instancia de environ. 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 environ es fundamental para garantizar la integridad de la comunicación entre servicios.

Diagrama que ilustra la similitud de identidad en una instancia de environ
Similitud de identidad en una instancia de environ

Exclusividad

Los recursos con conocimiento de environ 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 múltiples instancias de environ.

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 instancia de environ. Esta confianza permite mejorar la administración de estos recursos en la instancia de environ, 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 instancia de environ, 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 instancia de environ pueden afectar las operaciones de los servicios en otros miembros de la instancia de environ.

Por esta razón, recomendamos que los recursos que no sean de confianza del administrador de environ se coloquen en sus propias instancias de environ para mantenerlos aislados. Luego, según sea necesario, los servicios individuales se pueden autorizar en el límite de environ.

Próximos pasos

¿Estás listo para aplicar estos conceptos en tus propios sistemas? Consulta nuestros requisitos y prácticas recomendadas para environ.