En este documento, se describe la jerarquía de recursos de Google Distributed Cloud (GDC) aislado y cómo se administran los recursos en una instancia aislada. Para conocer los conceptos sobre la administración de recursos en varias zonas, consulta la Descripción general de varias zonas.
El propósito de la jerarquía de recursos de GDC es doble:
- Proporciona una jerarquía de propiedad, con la que se vincula el ciclo de vida de un recurso a su superior inmediato en la jerarquía.
- Proporciona puntos de conexión y herencia para el control de acceso y las políticas de la organización.
La jerarquía de recursos de GDC se asemeja al sistema de archivos que se encuentra en los sistemas operativos como una forma de organizar y administrar las entidades jerárquicamente. Por lo general, cada recurso tiene exactamente un elemento superior. Esta organización jerárquica de recursos te permite establecer políticas de control de acceso, como Identity and Access Management (IAM), que heredan los recursos secundarios.
Para obtener más información sobre las prácticas recomendadas para organizar tus límites de acceso, consulta Diseña límites de acceso entre recursos.
Estructura de recursos en detalle
Las siguientes entidades son tipos de recursos reconocidos en la jerarquía de recursos de GDC:
Los recursos de GDC están organizados de forma jerárquica. La mayoría de los recursos de la jerarquía de recursos tienen exactamente un elemento superior. La excepción solo se aplica al recurso más alto. En el nivel más bajo, los recursos de servicios son los componentes fundamentales que conforman todos los servicios de GDC.
Una organización es el nivel superior en la jerarquía de recursos de GDC, y todos los recursos que pertenecen a una organización se agrupan en el recurso de la organización. Esto proporciona visibilidad central y control sobre cada recurso que pertenece a una organización.
Tanto los proyectos como los clústeres de Kubernetes compartidos tienen un alcance de organización. Se pueden adjuntar entre sí para organizar los recursos de servicio. Sin embargo, los proyectos y los clústeres compartidos funcionan de forma independiente entre sí. Esta flexibilidad proporciona muchas opciones diferentes para organizar los servicios y las cargas de trabajo. Por ejemplo, puedes tener un clúster compartido dedicado a un solo proyecto. Del mismo modo, un clúster compartido puede abarcar varios proyectos.
Los recursos de servicio son entidades que deben pertenecer a un proyecto y no se pueden compartir entre proyectos. Entre los ejemplos de recursos de servicio, se incluyen las máquinas virtuales (VMs), los clústeres de Kubernetes estándar, las bases de datos, los buckets de almacenamiento y las copias de seguridad. La mayoría de estos recursos de nivel inferior tienen recursos de proyecto como sus elementos superiores.
En el siguiente diagrama, se representa un ejemplo de jerarquía de recursos de GDC:
Para obtener más información sobre las prácticas recomendadas para organizar tu jerarquía de recursos para una administración óptima de las cargas de trabajo, consulta Diseña la separación de cargas de trabajo del usuario.
Organization
El recurso de organización representa una unidad administrativa o una función empresarial, como una empresa, y es el recurso de nivel superior en la jerarquía de recursos de GDC. Una organización define un límite de seguridad que incluye recursos de infraestructura que se administrarán juntos para que los usuarios puedan implementar cargas de trabajo de aplicaciones. Las organizaciones son globales y abarcan todas las zonas de un universo. Dentro de una organización, los recursos de servicio, como las VMs y los volúmenes de almacenamiento, se agrupan lógicamente por proyectos.
Todos los proyectos, clústeres y recursos de servicio pertenecen a tu organización en lugar de a sus creadores. Esto significa que no se borra ningún tipo de recurso de una organización si el usuario que lo creó abandona la organización. En cambio, todos los tipos de recursos siguen el ciclo de vida de la organización en GDC.
Las políticas de control de acceso de IAM aplicadas en el recurso de organización se aplican a lo largo de la jerarquía, es decir: a todos los recursos de la organización. Para obtener más información sobre cómo otorgar políticas y permisos en toda la organización, consulta las secciones Políticas de la organización y IAM.
Project
Un proyecto es una unidad de usuario que debe integrar cada servicio. Los proyectos proporcionan una agrupación lógica de recursos de servicio. Los proyectos son globales y abarcan todas las zonas de un universo.
Los proyectos permiten la segmentación de los recursos de servicio dentro de una organización y proporcionan un ciclo de vida y un límite de políticas para administrar los recursos. Los recursos de servicio dentro de un proyecto nunca pueden sobrevivir al proyecto en sí ni moverse entre proyectos, lo que garantiza que el control esté disponible durante la vida útil de un recurso. Por lo tanto, debes implementar recursos de cualquier tipo dentro de un espacio de nombres del proyecto.
Un proyecto se considera un espacio de nombres de Kubernetes adecuado que abarca varios clústeres compartidos en una organización. La similitud de espacios de nombres considera que todos los espacios de nombres de un nombre determinado son el mismo espacio de nombres para todos los clústeres compartidos dentro de la misma organización. El espacio de nombres único tiene un propietario coherente en el conjunto de clústeres compartidos. Los proveedores de servicios crean servicios con alcance de proyecto mediante la creación de componentes del plano de control y del plano de datos en el espacio de nombres.
El espacio de nombres de un proyecto aloja lo siguiente:
- APIs de servicio con alcance de proyecto
- Configuraciones de políticas a nivel de proyecto, como funciones y vinculaciones de funciones
Puedes adjuntar un proyecto solo a un subconjunto de clústeres compartidos en una organización. Puedes implementar cargas de trabajo alojadas en contenedores en estos clústeres compartidos dentro de un espacio de nombres del proyecto. El concepto de similitud de espacios de nombres se aplica al espacio de nombres del proyecto en estos clústeres compartidos. Las políticas con alcance de espacio de nombres, como las políticas de acceso basado en roles (RBAC), se aplican a todos esos espacios de nombres.
Para obtener más información sobre los proyectos, consulta la Descripción general de proyectos.
Clúster de Kubernetes compartido
Un clúster de Kubernetes es un conjunto de nodos que ejecutan cargas de trabajo alojadas en contenedores como parte de GKE en GDC. Puedes aprovisionar clústeres de Kubernetes para admitir los requisitos de procesamiento de tus aplicaciones.
Un clúster compartido es una configuración de clúster que tiene un alcance de organización y debe adjuntarse a uno o más proyectos. El clúster estándar es otra configuración de clúster que opera solo dentro de un solo proyecto, pero se considera un recurso de servicio en la jerarquía de recursos. Estas configuraciones de clúster de Kubernetes están diseñadas para compilar una arquitectura de Kubernetes que ofrece opciones de administración de contenedores en entornos de desarrollo de software, como pruebas, desarrollo y producción. Para obtener más información sobre las prácticas recomendadas de separación de cargas de trabajo de contenedores, consulta Diseña la separación de cargas de trabajo.
Para obtener más información sobre los diferentes tipos de clústeres en GDC, consulta Configuraciones de clúster de Kubernetes.
Los clústeres compartidos subdividen los recursos de infraestructura en grupos aislados para que los consuman los proyectos dentro de una organización. Los clústeres también están separados lógicamente entre sí para proporcionar diferentes dominios de fallas y garantías de aislamiento. La aplicación de políticas por organización garantiza que los clústeres compartidos se puedan compartir entre equipos y usuarios, al mismo tiempo que se mantienen las garantías de rendimiento y recursos. Además, las políticas de la organización permiten que las cargas de trabajo de VM se ejecuten junto con las cargas de trabajo de contenedores sin introducir complejidad operativa.
Los clústeres son beneficiosos para las instancias en las que debes implementar cargas de trabajo alojadas en contenedores. Sin embargo, con la opción de implementar cargas de trabajo basadas en VM, no se requiere la existencia de un clúster de Kubernetes en GDC.
Los clústeres son solo un recurso zonal y no pueden abarcar varias zonas. Para operar clústeres en una implementación de varias zonas, debes implementar clústeres de forma manual en cada zona.
Para obtener más información sobre los clústeres de Kubernetes, consulta Descripción general de los clústeres de Kubernetes.
Recurso de servicio
Los recursos de servicio incluyen muchas entidades, como las siguientes:
- VMs
- Clústeres de Kubernetes estándar
- Bases de datos
- Buckets de almacenamiento
- Cargas de trabajo alojadas en contenedores
- Copias de seguridad
Los recursos de servicio deben pertenecer a un proyecto y no se pueden compartir entre proyectos. Este ciclo de vida específico del proyecto significa que los recursos de servicio dentro de un proyecto nunca pueden sobrevivir al proyecto en sí, lo que garantiza que el control esté disponible durante la vida útil del recurso.
Los recursos de servicio se pueden implementar de forma global o zonal, según el tipo. Consulta la documentación del servicio específico para obtener información sobre las opciones de implementación de varias zonas. Los recursos de servicio están habilitados de forma predeterminada y se pueden inhabilitar con una política de la organización.