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 se organizan de forma jerárquica. La mayoría de los recursos de la jerarquía de recursos tiene 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 la parte 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 y control centralizados para todos los recursos que pertenecen a una organización.
Tanto los proyectos como los clústeres de Kubernetes compartidos tienen 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. Algunos ejemplos de recursos de servicio son 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 elementos superiores.
En el siguiente diagrama, se representa un ejemplo de la jerarquía de recursos de GDC:
Si deseas obtener más información sobre las prácticas recomendadas para organizar la jerarquía de recursos y administrar las cargas de trabajo de forma óptima, consulta Diseña la separación de las cargas de trabajo de los usuarios.
Organización
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 encierra 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 de forma lógica 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 su lugar, 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 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 para toda la organización, consulta las secciones Políticas de la organización y IAM.
Proyecto
Un proyecto es una unidad de usuario que cada servicio debe 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 la segmentación de los recursos de servicio dentro de una organización y proporcionan un límite de ciclo de vida y 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 todo el conjunto de clústeres compartidos. Los proveedores de servicios crean servicios con alcance de proyecto creando 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 roles y vinculaciones de roles.
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 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 los 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 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 proyecto, pero se considera un recurso de servicio en la jerarquía de recursos. Estas opciones de configuración de clústeres de Kubernetes están diseñadas para compilar una arquitectura de Kubernetes que ofrezca 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 para la 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 Parámetros de configuración de clústeres de Kubernetes.
Los clústeres compartidos subdividen los recursos de infraestructura en grupos aislados para que los consuman los proyectos de una organización. Los clústeres también se separan de forma lógica entre sí para proporcionar diferentes dominios con 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, a la vez 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 los contenedores sin generar 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 multizona, 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 del recurso.
Los recursos de Service 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 multizona. Los recursos de servicio están habilitados de forma predeterminada y se pueden inhabilitar con una política de la organización.