En este documento se describe la jerarquía de recursos de Google Distributed Cloud (GDC) aislado y cómo se gestionan los recursos en una instancia aislada. Para conocer los conceptos sobre la gestión de recursos en varias zonas, consulta el artículo Descripción general de multizona.
La jerarquía de recursos de GDC tiene un doble objetivo:
- Ofrecer una jerarquía de propiedad que vincule el ciclo de vida de los recursos a los niveles inmediatamente superiores.
- Proporcionar puntos de montaje y herencia para los controles de acceso y las políticas de organización.
La jerarquía de recursos de GDC se parece al sistema de archivos de los sistemas operativos, ya que permite organizar y gestionar entidades de forma jerárquica. Por lo general, cada recurso tiene un único elemento superior. Esta organización jerárquica de los recursos te permite definir políticas de control de acceso, como las de gestión de identidades y accesos (IAM), que heredan los recursos secundarios.
Para obtener más información sobre las prácticas recomendadas para organizar los límites de acceso, consulta el artículo Diseñar límites de acceso entre recursos.
Estructura de los 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 jerárquicamente. La mayoría de los recursos de la jerarquía de recursos tienen un único elemento superior. La excepción solo se aplica al recurso de nivel 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 una visibilidad y un control centralizados sobre todos los recursos que pertenecen a una organización.
Tanto los proyectos como los clústeres de Kubernetes compartidos tienen un ámbito de organización. Se pueden vincular entre sí para organizar los recursos de servicio. Sin embargo, los proyectos y los clústeres compartidos funcionan de forma independiente. Esta flexibilidad ofrece 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 recursos de servicio se incluyen las máquinas virtuales (VMs), los clústeres de Kubernetes estándar, las bases de datos, los segmentos de almacenamiento y las copias de seguridad. La mayoría de estos recursos de nivel inferior tienen recursos de proyecto como elementos superiores.
El siguiente diagrama representa un ejemplo de jerarquía de recursos de GDC:
Para obtener más información sobre las prácticas recomendadas para organizar la jerarquía de recursos y optimizar la gestión de las cargas de trabajo, consulta el artículo Diseñar 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 de la jerarquía de recursos de GDC. Una organización define un límite de seguridad que abarca los recursos de infraestructura que se deben administrar conjuntamente para que los usuarios puedan desplegar 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 ningún tipo de recurso de una organización se elimina 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 al recurso de organización se aplican en toda la jerarquía a todos los recursos de la organización. Para obtener más información sobre cómo conceder políticas y permisos en toda la organización, consulta las secciones Políticas de organización y IAM.
Proyecto
Un proyecto es una unidad de cliente 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 de políticas para gestionar los recursos. Los recursos de servicio de un proyecto nunca pueden sobrevivir al propio proyecto ni moverse entre proyectos, lo que garantiza que el control esté disponible durante todo el ciclo de vida de un recurso. Por lo tanto, debes desplegar recursos de cualquier tipo dentro de un espacio de nombres de proyecto.
Un proyecto se considera un espacio de nombres de Kubernetes adecuado que abarca varios clústeres compartidos de una organización. La igualdad 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 compartidos 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 ámbito de proyecto creando componentes de plano de control y de plano de datos en el espacio de nombres.
El espacio de nombres de un proyecto aloja lo siguiente:
- APIs de servicio con ámbito de proyecto.
- Configuraciones de políticas a nivel de proyecto, como roles y vinculaciones de roles.
Puedes vincular un proyecto solo a un subconjunto de clústeres compartidos de una organización. Puedes desplegar cargas de trabajo en contenedores en estos clústeres compartidos dentro de un espacio de nombres de proyecto. El concepto de igualdad de espacios de nombres se aplica al espacio de nombres del proyecto en estos clústeres compartidos. Las políticas con ámbito 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 el artículo 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 en contenedores como parte de GKE en GDC. Puedes aprovisionar clústeres de Kubernetes para satisfacer los requisitos de computación de tus aplicaciones.
Un clúster compartido es una configuración de clúster con ámbito de organización que debe vincularse a uno o varios proyectos. El clúster estándar es otra configuración de clúster que solo funciona dentro de un 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 crear una arquitectura de Kubernetes que ofrezca opciones de gestión de contenedores en entornos de desarrollo de software, como los de pruebas, desarrollo y producción. Para obtener más información sobre las prácticas recomendadas para la separación de cargas de trabajo en contenedores, consulta el artículo Diseñar la separación de cargas de trabajo.
Para obtener más información sobre los diferentes tipos de clústeres de GDC, consulta el artículo Configuraciones de clústeres de Kubernetes.
Los clústeres compartidos 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 fallos 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 tiempo que se mantienen las garantías de rendimiento y de recursos. Además, las políticas de organización permiten que las cargas de trabajo de VMs se ejecuten junto con las cargas de trabajo de contenedores sin introducir complejidad operativa.
Los clústeres son útiles en los casos en los que debes desplegar cargas de trabajo en contenedores. Sin embargo, con la opción de desplegar cargas de trabajo basadas en VMs, no es necesario que haya un clúster de Kubernetes en GDC.
Los clústeres son solo recursos zonales y no pueden abarcar varias zonas. Para operar clústeres en un despliegue multizona, debes desplegar manualmente clústeres en cada zona.
Para obtener más información sobre los clústeres de Kubernetes, consulta el artículo 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
- Segmentos de almacenamiento
- Cargas de trabajo 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 de un proyecto nunca pueden sobrevivir al propio proyecto, lo que garantiza que el control esté disponible durante todo el ciclo de vida del recurso.
Los recursos de servicio se pueden desplegar de forma global o zonal, en función del tipo. Consulta la documentación del servicio específico para obtener información sobre las opciones de despliegue multizona. Los recursos de servicio están habilitados de forma predeterminada y se pueden inhabilitar mediante una política de organización.