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) con aislamiento de aire mediante 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ñar 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. 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 fuera de una organización y la transferencia de datos hacia 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 tu empresa 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, 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 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 exista 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 cumplir con los requisitos de alta disponibilidad para la distancia multizonal.
Diseña proyectos para el aislamiento lógico entre cargas de trabajo
Dentro de 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 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 en un proyecto los recursos que pueden compartir esta funcionalidad y mueve a otro proyecto los recursos que no pueden compartirla.
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 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é con 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 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 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 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 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 implementación
Para cada carga de trabajo, te recomendamos que crees proyectos separados para producción, desarrollo y cualquier otro entorno de implementación que necesites. Si separas los entornos de implementación de producción y desarrollo, podrás definir vinculaciones de roles y políticas de red de forma granular, de modo que los cambios realizados en un proyecto que se usa para el desarrollo 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, puedes otorgar 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 arrendatario estricto 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.