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) aislado 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 pertenecen a 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, 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 esta defina 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 según los siguientes indicadores:
- Las cargas de trabajo pueden compartir dependencias. Por ejemplo, podría ser una fuente de datos compartida, la 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.
- Las cargas de trabajo pueden compartir 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 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 multizona.
Diseña proyectos para el aislamiento lógico entre cargas de trabajo
En una organización, recomendamos aprovisionar 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 los proyectos 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, las 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 se reserva en todos los clústeres de una organización. Aunque un espacio de nombres se reserva en varios clústeres, eso no significa que un Pod se programe automáticamente en todos los clústeres. Un Pod programado para un clúster en particular permanece programado para ese clúster en particular.
En el siguiente diagrama, se muestra cómo se aplica una vinculación de rol 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é en cada 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 forma coherente a las cargas de trabajo basadas en VM y 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 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 sin importar 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 con el objetivo de permitir
el tráfico de entrada desde otros proyectos. En el siguiente diagrama, se ilustra un recurso personalizado de ProjectNetworkPolicy definido para que Backend Project habilite 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 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 designada del ciclo de vida. Por ejemplo, podrías tener entornos de desarrollo de software para pruebas, desarrollo y producción. Separar tus entornos de desarrollo de software te permite 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 recurso 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 puede 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 estricto de usuario 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 proyectos de Kubernetes tienen una relación de varios a varios. Es posible que tengas varios clústeres de Kubernetes en un solo proyecto o un solo clúster de Kubernetes que abarque varios proyectos.