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 con organizaciones, proyectos y clústeres de Kubernetes. Esta guía equilibra el uso eficiente de los recursos, el aislamiento de las cargas de trabajo y la facilidad de las operaciones.
Diseña organizaciones para el aislamiento físico y lógico entre los clientes
El recurso Organization es la raíz de todos los recursos que posee un solo cliente. El control de acceso detallado entre las cargas de trabajo dentro de una organización se puede definir a través de vinculaciones de roles y políticas de red. Consulta
Administración de identidades y accesos para obtener más
información.
Cada organización dentro de una zona de GDC proporciona aislamiento físico para la infraestructura de procesamiento 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 otorgue acceso de forma explícita. La conectividad de red de una organización a otra no está permitida de forma predeterminada, a menos que se configure de forma explícita para permitir la transferencia de datos desde una organización y la transferencia de datos a otra.
Define 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 según cómo defina tu empresa los límites de confianza. Es posible que algunas empresas prefieran 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 según los siguientes indicadores:
- Las cargas de trabajo pueden compartir dependencias. Por ejemplo, podría ser una fuente de datos compartida, conectividad entre cargas de trabajo o una herramienta de supervisión compartida.
- Las cargas de trabajo pueden compartir una raíz de confianza administrativa. Se puede confiar en el mismo administrador con 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 se establezca una separación lógica suficiente.
- El mismo titular del presupuesto tiene responsabilidad por los presupuestos de las cargas de trabajo en conjunto. Para obtener detalles sobre cómo ver los costos agregados de la organización o el análisis detallado por carga de trabajo, consulta la página Facturación.
- Los requisitos de disponibilidad de la carga de trabajo deben seguir los requisitos de alta disponibilidad para la distancia de varias zonas.
Diseña proyectos para el aislamiento lógico entre las 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 usan para separar las cargas de trabajo con un límite lógico basado en las políticas de Identity and Access Management (IAM) y las políticas de red.
Cuando diseñes los límites del proyecto, piensa en el conjunto más grande de funciones que pueden compartir los recursos, como las vinculaciones de roles, políticas de red o los requisitos de observabilidad. Agrupa los recursos que pueden compartir esta funcionalidad en un proyecto y mueve los recursos que no pueden compartir esta funcionalidad 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 en particular permanece programado en ese clúster en particular.
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 establecen a nivel del proyecto para definir quién puede hacer qué a qué tipo de recurso. Las cargas de trabajo, como las VMs o los pods, se implementan 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 manera coherente a las cargas de trabajo basadas en VM y a las cargas de trabajo basadas en contenedores, independientemente del clúster en el que se implementen.
En el siguiente diagrama, se muestra cómo las políticas de red administran el acceso entre proyectos.
La comunicación entre proyectos entre Backend Project, Frontend Project y Database Project está inhabilitada. Sin embargo, los recursos dentro de cada proyecto pueden comunicarse entre sí.
Las políticas de red se establecen a nivel del proyecto para permitir de forma selectiva el acceso a la red entre los recursos. De forma predeterminada, todos los recursos dentro de un solo 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 para las políticas de red se aplica independientemente de si los recursos se implementan 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 para permitir el tráfico de entrada de otros proyectos. En el siguiente diagrama, se ilustra un recurso personalizado ProjectNetworkPolicy definido para Backend Project para habilitar la transferencia de datos desde Frontend Project y Database Project.
Además, la pila de supervisión recopila 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.
Crea proyectos por entorno de desarrollo de software
Para cada carga de trabajo, te recomendamos que crees proyectos separados 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 designada del ciclo de vida. Por ejemplo, podrías tener entornos de desarrollo de software para pruebas, desarrollo y producción. Si separas tus entornos de desarrollo de software, puedes definir vinculaciones de roles y políticas de red de forma detallada, de modo que los cambios realizados en un proyecto que se usa para un entorno que no es de producción no afecten el entorno de producción.
Otorga vinculaciones de roles a nivel de recursos dentro de los proyectos
Según la estructura y los requisitos de tu equipo, puedes permitir que los desarrolladores modifiquen cualquier recurso dentro del proyecto que administran o puedes requerir un control de acceso más detallado. Dentro de un proyecto, otorgas vinculaciones de roles detalladas para permitir que los desarrolladores individuales accedan a algunos recursos del proyecto, pero no a todos. Por ejemplo, un equipo podría tener un administrador de bases de datos que debe administrar 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ña clústeres para el aislamiento lógico de las operaciones de Kubernetes
Un clúster de Kubernetes no es un límite de usuario físico porque 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 varios a varios. Puedes tener varios clústeres de Kubernetes en un solo proyecto o un solo clúster de Kubernetes que abarque varios proyectos.