En este documento se describe la jerarquía de recursos aislada de Google Distributed Cloud (GDC) y cómo se gestionan los recursos en una instancia aislada. Para obtener información sobre los conceptos de gestión de recursos en varias zonas, consulta la descripción general de varias zonas.
La jerarquía de recursos de GDC tiene dos objetivos:
- Ofrece una jerarquía de propiedad que vincula el ciclo de vida de los recursos a los niveles inmediatamente superiores.
- Proporcionar herencias y puntos de montaje 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 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 exactamente un elemento superior. La excepción solo se aplica al recurso de mayor nivel. En el nivel más bajo, los recursos de servicio son los componentes fundamentales que forman 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 la organización. De esta forma, se ofrece una visibilidad y un control centralizados sobre todos los recursos que pertenecen a una organización.
Tanto los proyectos como los clústeres tienen el ámbito de la organización. Se pueden adjuntar entre sí para organizar los recursos de los servicios. Sin embargo, los proyectos y los clústeres funcionan de forma independiente. Esta flexibilidad ofrece muchas opciones diferentes para organizar servicios y 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. Algunos ejemplos de recursos de servicio son las máquinas virtuales, 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 principales.
En el siguiente diagrama se muestra 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 gestionar las cargas de trabajo de forma óptima, consulta el artículo Diseñar la separación de 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 incluye los recursos de infraestructura que se van a administrar conjuntamente para que los usuarios puedan implementar cargas de trabajo de aplicaciones. Las organizaciones son globales y abarcan todas las zonas de un universo. En una organización, los recursos de servicio, como las máquinas virtuales 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 elimina 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 gestión de identidades y accesos aplicadas al recurso de la 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 a nivel de organización, consulta las secciones Políticas de organización y Gestión de identidades y accesos.
Proyecto
Un proyecto es una unidad de cliente que debe integrar cada servicio. 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 de una organización y proporcionan un límite de ciclo de vida y de política para gestionar los recursos. Los recursos de servicio de un proyecto nunca pueden durar más que el propio proyecto ni moverse entre proyectos, lo que garantiza que el control esté disponible durante la vida útil de un recurso. Por lo tanto, debes desplegar recursos de cualquier tipo en un espacio de nombres de proyecto.
Un proyecto se considera un espacio de nombres de Kubernetes adecuado que abarca varios clústeres de una organización. 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 de la misma organización. El espacio de nombres único tiene un propietario coherente en todo el conjunto de clústeres. 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 incluye lo siguiente:
- APIs de servicio con ámbito de proyecto.
- Configuraciones de políticas a nivel de proyecto, como roles y vinculaciones de roles.
Solo puedes asociar un proyecto a un subconjunto de clústeres de una organización. Puedes desplegar cargas de trabajo en contenedores en estos clústeres dentro de un espacio de nombres de proyecto. El concepto de igualdad de espacio de nombres se aplica al espacio de nombres del proyecto en estos clústeres. Las políticas con ámbito de espacio de nombres, como las políticas de acceso basadas 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
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. Los clústeres tienen un ámbito de organización y deben estar asociados a uno o varios proyectos.
Los clústeres subdividen los recursos de infraestructura en grupos aislados que pueden usar los proyectos de una organización. Los clústeres también están separados lógicamente entre sí para proporcionar diferentes dominios de errores y garantías de aislamiento. La aplicación de políticas por organización asegura que los clústeres se puedan compartir entre equipos y usuarios, al tiempo que se mantienen las garantías de rendimiento y recursos. Además, las políticas de organización permiten que las cargas de trabajo de las máquinas virtuales se ejecuten junto con las cargas de trabajo de los 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 máquinas virtuales, no es necesario que haya un clúster de Kubernetes en GDC.
Los clústeres son un recurso zonal y no pueden abarcar varias zonas. Para operar clústeres en una implementación multizona, debes desplegar manualmente los clústeres en cada zona.
Para obtener más información sobre los clústeres de Kubernetes, consulta la sección Gestionar clústeres de Kubernetes.
Recurso de servicio
Los recursos de servicio incluyen muchas entidades, como las siguientes:
- VMs
- Bases de datos
- Segmentos de almacenamiento
- Cargas de trabajo en contenedores
- Copias de seguridad
Los recursos de servicio deben pertenecer a un proyecto o, de forma 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 de un proyecto nunca pueden durar más que el propio proyecto, 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 zonas, 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 mediante una política de organización.