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 las multizonas.
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 tus 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 de Kubernetes compartidos están asociados a una 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. Esta flexibilidad ofrece muchas opciones diferentes para organizar servicios y 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, 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 padres.
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 IAM.
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 compartidos 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 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 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 adjuntar un proyecto a un subconjunto de clústeres compartidos de una organización. Puedes desplegar cargas de trabajo contenerizadas en estos clústeres compartidos dentro de un espacio de nombres de un proyecto. El concepto de igualdad de espacio 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 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 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 que tiene el ámbito de la organización y debe estar asociado a uno o varios proyectos. El clúster estándar es otra configuración de clúster que solo funciona en un proyecto, pero se considera un recurso de servicio en la jerarquía de recursos. Estas configuraciones de clúster de Kubernetes se han diseñado para crear una arquitectura de Kubernetes que ofrezca opciones de gestió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 separar las cargas de trabajo de los contenedores, consulta Diseñar la separación de cargas de trabajo.
Para obtener más información sobre los distintos tipos de clústeres de GDC, consulta las configuraciones 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 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 permite que los clústeres compartidos 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 VMs, 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 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 la vida del recurso.
Los recursos de servicio se pueden desplegar 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.