En este documento se presentan las prácticas recomendadas para diseñar la jerarquía y la separación de las cargas de trabajo en Google Distributed Cloud (GDC) air-gapped mediante organizaciones, proyectos y clústeres de Kubernetes. Estas directrices buscan un equilibrio entre el uso eficiente de los recursos, el aislamiento de las cargas de trabajo y la facilidad de las operaciones.
Diseñar organizaciones para el aislamiento físico y lógico entre clientes
El recurso Organization es la raíz de todos los recursos que pertenecen a un solo cliente. El control de acceso granular entre las cargas de trabajo de una organización se puede definir mediante vinculaciones de roles y políticas de red. Consulta más información en el artículo
Gestión de identidades y accesos.
Cada organización de una zona de GDC proporciona aislamiento físico para la infraestructura de computación y aislamiento lógico para las redes, el almacenamiento y otros servicios. Los usuarios de una organización no tienen acceso a los recursos de otra organización, a menos que se les conceda acceso explícitamente. De forma predeterminada, no se permite la conectividad de red de una organización a otra, a menos que se configure explícitamente para permitir la transferencia de datos de salida de una organización y la transferencia de datos de entrada a otra.
Definir el alcance de las cargas de trabajo que pueden compartir una organización
El alcance de una organización en el contexto de tu empresa puede variar en función de cómo defina tu empresa los límites de confianza. Algunas empresas pueden preferir crear varios recursos de organización para diferentes entidades de la empresa. Por ejemplo, cada departamento de la empresa podría ser un cliente independiente de GDC con una organización independiente si los departamentos requieren una separación física y administrativa completa de sus cargas de trabajo.
En general, te recomendamos que agrupes varias cargas de trabajo en una sola organización en función de las siguientes señales:
- Las cargas de trabajo pueden compartir dependencias. Por ejemplo, podría tratarse de una fuente de datos compartida, de conectividad entre cargas de trabajo o de una herramienta de monitorización compartida.
- Las cargas de trabajo pueden compartir una raíz de confianza administrativa. Se puede confiar en el mismo administrador para que tenga acceso privilegiado a todas las cargas de trabajo de la organización.
- Se permite que las cargas de trabajo compartan la infraestructura física subyacente con otras cargas de trabajo de la misma organización, siempre que haya una separación lógica suficiente.
- El mismo titular del presupuesto es responsable de los presupuestos de las cargas de trabajo en conjunto. Para obtener información detallada sobre cómo ver los costes agregados de la organización o un análisis granular por carga de trabajo, consulta la página Facturación.
- Los requisitos de disponibilidad de las cargas de trabajo deben cumplir los requisitos de alta disponibilidad para la distancia entre zonas.
Diseñar proyectos para el aislamiento lógico entre cargas de trabajo
Dentro de una organización, te recomendamos que aprovisiones varios proyectos para crear una separación lógica entre los recursos. Los proyectos de la misma organización pueden compartir la infraestructura física subyacente, pero se utilizan para separar las cargas de trabajo con un límite lógico basado en las políticas de gestión de identidades y accesos (IAM) y las políticas de red.
Al diseñar los límites de los proyectos, piensa en el conjunto de funciones más grande que pueden compartir los recursos, como las vinculaciones de roles, las políticas de red o los requisitos de observabilidad. Agrupa los recursos que puedan compartir esta funcionalidad en un proyecto y mueve los recursos que no puedan compartirla a otro proyecto.
En términos de Kubernetes, un proyecto es un espacio de nombres de Kubernetes que está reservado en todos los clústeres de una organización. Aunque un espacio de nombres esté reservado en varios clústeres, eso no significa que un pod se programe automáticamente en todos los clústeres. Un pod programado en un clúster concreto sigue programado en ese clúster concreto.
En el siguiente diagrama se muestra cómo se aplica una vinculación de roles a un proyecto que abarca varios clústeres.
Las vinculaciones de roles se definen a nivel de proyecto para determinar quién puede hacer qué con cada tipo de recurso. Las cargas de trabajo, como las máquinas virtuales o los pods, se despliegan en un proyecto, y el acceso a estas cargas de trabajo se rige por la vinculación de roles. La vinculación de roles se aplica de forma coherente a las cargas de trabajo basadas en máquinas virtuales y a las cargas de trabajo basadas en contenedores, independientemente del clúster en el que se desplieguen.
En el siguiente diagrama se muestra cómo las políticas de red gestionan el acceso entre proyectos.
La comunicación entre proyectos entre el Backend Project, el Frontend Project y el Database Project está inhabilitada. Sin embargo, los recursos de cada proyecto pueden comunicarse entre sí.
Las políticas de red se definen a nivel de proyecto para permitir de forma selectiva el acceso a la red entre los recursos. De forma predeterminada, todos los recursos de un mismo proyecto pueden comunicarse entre sí en la red interna, y un recurso de un proyecto no puede comunicarse con un recurso de otro proyecto. Este comportamiento de las políticas de red se aplica independientemente de si los recursos se despliegan en el mismo clúster o no.
También puedes definir un recurso personalizado ProjectNetworkPolicy para habilitar la comunicación entre proyectos. Esta política se define para cada proyecto con el fin de permitir el tráfico de entrada de otros proyectos. En el siguiente diagrama se muestra un recurso personalizado ProjectNetworkPolicy definido para el Backend Project con el fin de habilitar la transferencia de datos de entrada desde el Frontend Project y el Database Project.
Además, la pila de monitorización recoge métricas en toda la organización, pero puedes filtrar y consultar en varios niveles de la jerarquía de recursos. Puedes consultar métricas con entidades como un clúster o un espacio de nombres.
Crear proyectos por entorno de desarrollo de software
Para cada carga de trabajo, te recomendamos que crees proyectos independientes para cada entorno de desarrollo de software. Un entorno de desarrollo de software es un área dentro de tu universo de GDC destinada a todas las operaciones que corresponden a una fase del ciclo de vida designada. Por ejemplo, podrías tener entornos de desarrollo de software para pruebas, desarrollo y producción. Al separar los entornos de desarrollo de software, puedes definir vinculaciones de roles y políticas de red de forma granular, de modo que los cambios realizados en un proyecto utilizado para un entorno que no sea de producción no afecten al entorno de producción.
Conceder vinculaciones de roles a nivel de recurso dentro de los proyectos
En función de la estructura y los requisitos de tu equipo, puedes permitir que los desarrolladores modifiquen cualquier recurso dentro del proyecto que gestionen o puedes requerir un control de acceso más granular. Dentro de un proyecto, puedes conceder vinculaciones de roles granulares para permitir que los desarrolladores individuales accedan a algunos recursos del proyecto, pero no a todos. Por ejemplo, un equipo puede tener un administrador de bases de datos que deba gestionar la base de datos, pero no modificar otros recursos, mientras que los desarrolladores de software del equipo no deben tener permiso para modificar la base de datos.
Diseñar clústeres para el aislamiento lógico de las operaciones de Kubernetes
Un clúster de Kubernetes no es un límite de inquilino estricto, ya que las vinculaciones de roles y las políticas de red se aplican a los proyectos, no a los clústeres de Kubernetes. Los clústeres y los proyectos de Kubernetes tienen una relación de muchos a muchos. Puedes tener varios clústeres de Kubernetes en un solo proyecto o un solo clúster de Kubernetes que abarque varios proyectos.