El recurso de organización representa una unidad administrativa o una función comercial que comparte el mismo grupo de recursos y las mismas políticas. Google Distributed Cloud (GDC) aislado proporciona aislamiento físico entre las organizaciones que usan funciones de múltiples inquilinos a nivel del hardware. Cada organización también tiene sus propios componentes del plano de control para sus servicios, que no se comparten con otras organizaciones. Todos los recursos, como proyectos, clústeres y servicios, pertenecen a una organización en lugar de a sus creadores. Por lo tanto, los recursos no se borran si el usuario que los creó abandona la organización. En cambio, todos los tipos de recursos siguen el ciclo de vida de la organización. Para obtener más información, consulta la jerarquía de recursos de GDC.
Conectividad de red externa
Para ser útil, una organización requiere conectividad a redes externas. Esto permite que los administradores de la plataforma (PA) y los operadores de la aplicación (AO) administren la organización y sus recursos, y que los usuarios finales consuman los servicios implementados en ella. En GDC, las interconexiones proporcionan toda la conectividad externa.
Cuando se crea una organización, no se conecta automáticamente a ninguna red. Como operador, debes realizar pasos de configuración adicionales para adjuntar una organización a una interconexión existente o aprovisionar una nueva y dedicada. Por lo general, esto implica lo siguiente:
- Se agrega la organización a un objeto
AttachmentGroup. - Crear recursos de
Interconnectpara conexiones físicas o lógicas nuevas - Definir recursos
RoutePolicypara anunciar las rutas de red de la organización a la red externa
Las organizaciones ofrecen capacidades de redes mejoradas, incluida la capacidad de las organizaciones con interconexiones dedicadas para usar direcciones IP externas superpuestas, lo que simplifica la administración de IP.
Para conocer los conceptos detallados y los procedimientos de configuración, consulta la descripción general de Interconnect.
Modelos de conectividad de interconexión
Las interconexiones de GDC admiten dos configuraciones principales que se alinean con diferentes requisitos de seguridad y administración de IP.
Conectividad de red externa compartida
Este modelo permite que varias organizaciones se conecten a una zona de GDC a través de una red externa común. En esta configuración, el operador de infraestructura (IO) suele administrar la conexión física y el intercambio de tráfico de BGP. Un requisito clave es que las direcciones IP externas que usa cada organización deben ser únicas en toda la red compartida. Este modelo es más fácil de administrar para los entornos con un dominio de confianza común.
Conectividad de red externa dedicada
Este modelo es para organizaciones que requieren un mayor grado de aislamiento, ya que se conecta a una red externa distinta. Con la conectividad dedicada, la PA puede administrar el intercambio de tráfico BGP, lo que proporciona más control.
Una ventaja significativa de este modelo es la capacidad de las organizaciones para usar direcciones IP externas superpuestas. Esta capacidad simplifica la administración de direcciones IP, ya que elimina la necesidad de resolver conflictos de rangos de IP en todos los arrendatarios del universo de GDC.
Para conocer los conceptos detallados y los procedimientos de configuración, consulta la Descripción general de Interconnect.
Arquitecturas de organización
GDC proporciona dos arquitecturas para las organizaciones:
- Arquitectura de la organización aislada de GDC v1 (organización v1)
- Arquitectura de la organización aislada de GDC v2 (organización v2)
A primera vista, las organizaciones con cualquiera de las dos arquitecturas se aprovisionan, usan y operan de manera similar. Sin embargo, las arquitecturas subyacentes de clústeres, redes y almacenamiento son diferentes en cada tipo de organización.
Arquitectura de la organización de GDC aislado, versión 1
Una organización de la versión 1 consta de dos clústeres:
- Clúster de administrador de la organización: Ejecuta los componentes del plano de control de los servicios administrados y de Marketplace para la organización. También aloja algunos servicios de infraestructura principales.
- Clúster del sistema: Ejecuta cargas de trabajo de máquina virtual (VM) y algunas cargas de trabajo del plano de datos de servicios administrados para la organización. La cantidad de nodos trabajadores depende del uso del clúster.
El PA y el AO deben acceder a estos tipos de clústeres en ocasiones para implementar cargas de trabajo y administrar el sistema.
El almacenamiento para clústeres virtuales se controla con un controlador de CSI específico del proveedor dentro del clúster.
Arquitectura de la organización v2 de GDC aislado
Una organización de la versión 2 consta de un clúster llamado clúster de infraestructura de la organización, que ejecuta los componentes del plano de control y del plano de datos de la organización. Este clúster también aloja el servidor de la API de administración en el que se implementan todas las cargas de trabajo y los servicios que no son de contenedor. El servidor de la API de administración proporciona una capa en la que los PA y los AO pueden implementar cargas de trabajo, pero no interactuar directamente con el clúster de infraestructura de la organización.
El almacenamiento para los clústeres virtuales se controla con un controlador de CSI proxy que permite que el controlador de CSI del clúster de infraestructura de la organización controle las operaciones.
Los componentes de redes, incluida la administración de direcciones IP, el redireccionamiento de entrada y salida, y la estructura de VRF, proporcionan mejoras en la arquitectura de organización de la versión 1 para la seguridad y la usabilidad del sistema.
¿Qué novedades hay para las organizaciones de la versión 2?
La arquitectura de organización de la versión 2 introduce cambios en varios componentes en comparación con la arquitectura de organización de la versión 1.
Arquitectura de la API y del clúster
La arquitectura de organización de la versión 2 proporciona solo un clúster para la organización, en lugar de los dos clústeres que se proporcionaban en la arquitectura anterior. La reducción de la cantidad de clústeres permite un uso más elástico de los recursos de hardware.
También existe una separación de red del plano de control y el plano de datos que no estaba disponible para las organizaciones de la versión 1. El servidor de la API de administración, o plano de control, ahora se puede exponer en una red del cliente que es diferente de la red del cliente a la que se expone el plano de datos. Esta separación ofrece una capa adicional opcional de aislamiento entre el aprovisionamiento de recursos de la nube y el consumo de recursos. Se espera que tus administradores y desarrolladores tengan conexiones con ambas redes externas.
Almacenamiento
La nueva arquitectura de organización de la versión 2 quita las credenciales de almacenamiento de NetApp del clúster de usuarios implementando el controlador CSI de KubeVirt en lugar del controlador CSI de NetApp Trident que se encontraba en la arquitectura anterior. Esta actualización del controlador de CSI reduce aún más los privilegios directos de la matriz de almacenamiento.
Redes
Las siguientes mejoras en las redes están disponibles para las organizaciones de la versión 2:
- Encriptación de nodo a nodo
- Clúster dedicado para controlar el tráfico de red
- Redes de VM simplificadas
- Uso y administración más eficientes de las direcciones IP
Encriptación de nodo a nodo
La arquitectura de organización de la versión 2 proporciona encriptación entre los nodos de metal desnudo de la organización para que todo el tráfico de red del cliente se encripte cuando sale del nodo físico y, así, evitar que los conmutadores de red tengan visibilidad del tráfico sin encriptar.
Clúster dedicado para controlar el tráfico de red
El clúster perimetral es un clúster virtual escalable que controla todo el tráfico de entrada y salida (norte/sur) de la organización. Este clúster también permite que tu universo de GDC se mueva a opciones más escalables de sistemas virtuales de detección y prevención de intrusiones (IDPS) en el futuro.
Herramientas de redes de VM simplificadas
La arquitectura de organización de la versión 2 converge dos interfaces por VM de la arquitectura anterior en una sola interfaz. Las VMs se migran a un modelo de redes de nube privada virtual (VPC) predeterminado, lo que significa que las VMs se conectan a la red en el nivel 3 (L3).
Los clientes también pueden definir sus propias subredes, lo que no se admite para las organizaciones de la versión 1.
Uso y administración eficientes de direcciones IP
La arquitectura de organización de la versión 2 permite direcciones IP externas superpuestas para las organizaciones. Las direcciones IP externas superpuestas permiten que las organizaciones se conecten directamente a las redes de los clientes, lo que elimina la necesidad de un solo espacio de direcciones IP externas grande alineado en todas las organizaciones del universo de GDC.
Las direcciones IP también se proporcionan por organización en lugar de estar ancladas a una sola subred principal con alcance zonal. Esta capacidad permite que los administradores especifiquen sus propias direcciones IP, en lugar de requerir que tú, como operador, especifiques una. Esta función proporciona una mejor elasticidad y aislamiento para las organizaciones que desean un aislamiento de red sólido, ya que no comparten una superred principal.
En las organizaciones de la versión 1, se requería una dirección IP de NAT de salida por proyecto, por clúster de usuario y por organización. En el caso de las organizaciones de la versión 2, este requisito se mejoró significativamente a uno por proyecto y por organización. Este cambio proporciona una mayor eficiencia en el uso de las direcciones IP proporcionadas por el cliente.
Diferencias funcionales entre las organizaciones de la versión 1 y la versión 2
Una organización de la versión 2 proporciona las mismas capacidades que una organización de la versión 1. Las únicas funciones que no están disponibles en una organización de la versión 2 son las siguientes:
- Vertex AI
- CLI del servicio de bases de datos
¿Qué arquitectura usarán las organizaciones multizona?
En un universo de GDC de varias zonas, si se extiende una organización existente a una zona nueva, la organización de la zona nueva debe usar la misma arquitectura que la zona existente. Por lo tanto, no se admite el uso de diferentes arquitecturas de organización por zona.
Cómo aprovisionar una organización de la versión 2
Cuando se aprovisiona una organización, se crean organizaciones de la versión 2 de forma predeterminada para los clientes que no están sujetos a procesos de acreditación.
Sin embargo, las organizaciones de la versión 2 proporcionan un cambio arquitectónico significativo. En el caso de las implementaciones para clientes sujetas a acreditación, la arquitectura de organización v1 sigue siendo la predeterminada hasta que se complete la acreditación de la arquitectura de organización v2.
La arquitectura predeterminada de la organización se controla con una marca de función que se configura cuando implementas una zona.
Cómo forzar la arquitectura de la organización
En casos excepcionales, es posible que desees anular el comportamiento de aprovisionamiento predeterminado y forzar una arquitectura de organización específica agregando el campo spec.compatibilityOptions.architectureOverridePolicy a tu recurso Organization durante el proceso de aprovisionamiento. Para obtener más información, consulta la página Crea una organización del cliente.
No se recomienda anular la arquitectura predeterminada de tu organización, a menos que tengas un motivo sólido para forzar un comportamiento específico.
Por ejemplo, podrías forzar una organización de v1 si encuentras un problema significativo con una organización de v2 que bloquea una tarea. Del mismo modo, puedes forzar una organización de la versión 2 si necesitas la acreditación y requieres una sola organización de la versión 2 para iniciar el proceso de acreditación. Estas marcas de anulación se deben quitar cuando ya no sean estrictamente necesarias para evitar el aprovisionamiento futuro de la organización con la arquitectura incorrecta.
¿Qué sucede con las organizaciones existentes de la versión 1?
Las organizaciones existentes creadas antes de la versión 1.14.2 de GDC con aislamiento de aire permanecen en la misma arquitectura, incluso si la zona de GDC se actualiza a la versión 1.14.2 o posterior. Si bien no hay una actualización disponible para convertir organizaciones de la versión 1 a la versión 2, las funciones existentes en las organizaciones de la versión 1 seguirán siendo compatibles hasta que se deje de usar la arquitectura de la organización de la versión 1 en el futuro.
Es posible que las nuevas funciones en el futuro solo se agreguen a las organizaciones de la versión 2. Por lo tanto, te recomendamos que transfieras tus cargas de trabajo de las organizaciones de la versión 1 a la nueva arquitectura de organización de la versión 2 lo antes posible. Un solo universo de GDC aislado del aire puede contener ambas arquitecturas de organización de forma simultánea, lo que proporciona una transición más sencilla.