En este documento, se describe la jerarquía de recursos aislados de Google Distributed Cloud (GDC) 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.
La jerarquía de recursos de GDC tiene dos propósitos:
- 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. En 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 se organizan 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 servicio son los componentes fundamentales que conforman todos los servicios de GDC.
Una organización es el nivel superior de la jerarquía de recursos de GDC, y todos los recursos que pertenecen a una organización se agrupan en el recurso de organización. Esto proporciona visibilidad central y control sobre cada recurso que pertenece a una organización.
Tanto los proyectos como los clústeres tienen alcance a nivel de la organización. Se pueden unir entre sí para organizar los recursos de servicio. Sin embargo, los proyectos y los clústeres 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 dedicado a un solo proyecto. Del mismo modo, un clúster puede abarcar varios proyectos.
Los recursos de servicio son entidades que deben pertenecer a un proyecto o a un clúster, y no se pueden compartir entre proyectos o clústeres. Entre los ejemplos de recursos de servicio, se incluyen las máquinas virtuales (VM), las bases de datos, los buckets de almacenamiento y las copias de seguridad. La mayoría de estos recursos de nivel inferior tienen recursos del proyecto como 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 y lograr una administración óptima de las cargas de trabajo, consulta Diseña la separación de cargas de trabajo del usuario.
Organización
El recurso de organización representa una unidad administrativa o una función comercial, 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 abarca los recursos de infraestructura que se administrarán en conjunto 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, no a sus creadores. Esto significa que no se borra ningún tipo de recurso de una organización si el usuario que lo creó se va de 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 al recurso de organización se aplican en la jerarquía de 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.
Proyecto
Un proyecto es una unidad de usuario que todos los servicios deben integrar. Los proyectos proporcionan una agrupación lógica de los recursos de servicio. Los proyectos son globales y abarcan todas las zonas de un universo.
Los proyectos permiten segmentar los recursos de servicio dentro de una organización y proporcionan un límite de ciclo de vida y política 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 en una organización. La similitud de espacios de nombres considera que todos los espacios de nombres con un nombre determinado son el mismo espacio de nombres para todos los clústeres dentro de la misma organización. El único espacio de nombres tiene un propietario coherente en todo el conjunto de clústeres. Los proveedores de servicios crean servicios con alcance para el proyecto creando componentes de plano de control y plano de datos en el espacio de nombres.
El espacio de nombres de un proyecto aloja lo siguiente:
- APIs de servicio con alcance para el proyecto
- Configuraciones de políticas a nivel del proyecto, como roles y vinculaciones de roles
Puedes adjuntar un proyecto solo a un subconjunto de clústeres de una organización. Puedes implementar cargas de trabajo alojadas en contenedores en estos clústeres dentro de un espacio de nombres del proyecto. El concepto de similitud de espacio de nombres se aplica al espacio de nombres del proyecto en estos clústeres. Las políticas con alcance de espacio de nombres, como las políticas de control 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
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 satisfacer los requisitos de procesamiento de tus aplicaciones. Los clústeres tienen alcance a nivel de la organización y deben adjuntarse a uno o más proyectos.
Los clústeres subdividen los recursos de infraestructura en grupos aislados para que los proyectos de una organización los consuman. 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 se puedan compartir entre equipos y usuarios, y que se mantengan 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 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 multizona, debes implementar clústeres de forma manual en cada zona.
Para obtener más información sobre los clústeres de Kubernetes, consulta la sección Administra clústeres de Kubernetes.
Recurso de servicio
Los recursos de servicio incluyen muchas entidades, como las siguientes:
- VMs
- Bases de datos
- Buckets de almacenamiento
- Cargas de trabajo alojadas en contenedores
- Copias de seguridad
Los recursos de servicio deben pertenecer a un proyecto o, de manera opcional, a un clúster para cargas de trabajo en contenedores, y no se pueden compartir entre proyectos. Esto 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 por zona, según el tipo. Consulta la documentación del servicio específico para obtener información sobre las opciones de implementación en varias zonas. Los recursos de servicio están habilitados de forma predeterminada y se pueden inhabilitar con una política de la organización.