Arquitectura de referencia de GKE Enterprise: nube distribuida de Google para Bare Metal

Last reviewed 2023-08-15 UTC

En esta guía, se describe la arquitectura de referencia que se usa para implementar GDCV para Bare Metal. Esta guía está dirigida a los administradores de la plataforma que deseen implementar Anthos en una plataforma Bare Metal en una configuración geográficamente redundante con alta disponibilidad. Para comprender mejor esta guía, debes familiarizarte con los conceptos básicos de GKE Enterprise, como se describe en la descripción general técnica de GKE Enterprise. También debes tener un conocimiento básico de los conceptos de Kubernetes y Google Kubernetes Engine (GKE), como se describe en Aprende los conceptos básicos de Kubernetes y en la documentación de GKE.

En esta guía encontrarás un repositorio de código fuente de GitHub que incluye secuencias de comandos que puedes usar para implementar la arquitectura descrita. También se describen los componentes de la arquitectura que acompañan a las secuencias de comandos y a los módulos que se usan para crear esos componentes. Te recomendamos usar estos archivos como plantillas para crear módulos que usen las prácticas recomendadas y políticas de tu organización.

GDCV para el modelo de arquitectura de Bare Metal

En la guía de Fundamentos de la arquitectura de GKE Enterprise, la arquitectura de la plataforma se describe en capas. Los recursos de cada capa proporcionan un conjunto específico de funciones. Una o más personas son propietarias y administran estos recursos. Como se muestra en el siguiente diagrama, la arquitectura de la plataforma de GKE Enterprise para Bare Metal consta de las siguientes capas y recursos:

Un GDCV para el modelo mental de Bare Metal que muestra las capas que se analizan en el documento.

  1. Infraestructura: Esta capa incluye almacenamiento, procesamiento y herramientas de redes, manejadas con construcciones locales.
  2. Administración de datos: Para los fines de esta guía, la capa de administración de datos requiere una base de datos de SQL que se administre fuera de los clústeres de Kubernetes que se implementan.
  3. Capa de administración de contenedores: Esta capa usa clústeres de GKE.
  4. Capa de administración de servicios: Esta capa usa Anthos Service Mesh.
  5. Capa de administración de políticas: Esta capa usa el Sincronizador de configuración y Policy Controller.
  6. Capa de administración de aplicaciones: Esta capa usa Cloud Build y Cloud Source Repositories.
  7. Capa de observabilidad: Esta capa usa los paneles de observabilidad de Google Cloud y Anthos Service Mesh.

Cada una de estas capas se repite en la pila para diferentes entornos de ciclo de vida, como el desarrollo, la etapa de pruebas y la producción.

Las siguientes secciones solo incluyen información adicional específica de GDCV para Bare Metal. Se basan en sus respectivas secciones en la guía de Fundamentos de la arquitectura de GKE Enterprise. Te recomendamos que revises la guía a medida que leas este artículo.

Redes

Para obtener más información sobre los requisitos de red, consulta Requisitos de red.

Para GDCV para balanceadores de cargas Bare Metal, hay dos opciones disponibles: en paquetes y manual.

En el modo en paquetes, el software de balanceo de cargas L4 se implementa durante la creación del clúster. Los procesos del balanceador de cargas pueden ejecutarse en un grupo dedicado de nodos trabajadores o en los mismos nodos que el plano de control. Para anunciar direcciones IP virtuales (VIP), este balanceador de cargas tiene dos opciones:

En el modo manual, configuras tus propias soluciones de balanceo de cargas para el tráfico del plano de control y el plano de datos. Existen muchas opciones de hardware y software disponibles para los balanceadores de cargas externos. Debes configurar un balanceador de cargas externo para el plano de control antes de crear un clúster de equipos físicos. El balanceador de cargas del plano de control externo también se puede usar para el tráfico del plano de datos, o puedes configurar un balanceador de cargas por separado para el plano de datos. Para determinar la disponibilidad, el balanceador de cargas debe poder distribuir el tráfico a un grupo de nodos según una verificación de disponibilidad configurable.

A fin de obtener más información sobre los balanceadores de cargas de GDCV para Bare Metal, consulta Descripción general de los balanceadores de cargas.

Arquitectura del clúster

GDCV para Bare Metal admite varios modelos de implementación, que se adaptan a diferentes necesidades de disponibilidad, aislamiento y huella de recursos. Estos modelos de implementación se analizan en Elige un modo de implementación.

Identity management

GDCV para Bare Metal usa el servicio de identidad de GKE a fin de integrarse a los proveedores de identidad. Es compatible con OpenID Connect (OIDC) y el Protocolo ligero de acceso a directorios (LDAP). Para las aplicaciones y los servicios, Anthos Service Mesh se puede usar con varias soluciones de identidad.

Si quieres obtener más información sobre la administración de identidades, consulta Administración de identidades con OIDC en GDCV para Bare Metal y Autenticar con OIDC o Configura Anthos Identity Service con LDAP.

Administración de políticas y seguridad

Para GDCV para la seguridad de Bare Metal y la administración de políticas, recomendamos usar el Sincronizador de configuración y Policy Controller. Policy Controller te permite crear y aplicar políticas en tus clústeres. El sincronizador de configuración evalúa los cambios y los aplica a todos los clústeres para lograr el estado adecuado.

Servicios

Cuando usas GDCV para el modo en paquetes de Bare Metal para el balanceo de cargas, puedes crear servicios de tipo LoadBalancer. Cuando creas estos servicios, Anthos en equipos físicos asigna al servicio una dirección IP del grupo de direcciones IP del balanceador de cargas configurado. El tipo de servicio LoadBalancer se usa a fin de exponer el servicio de Kubernetes fuera del clúster para el tráfico del norte-sur. Cuando usas GDCV para Bare Metal, también se crea un IngressGateway en el clúster de forma predeterminada. No puedes crear servicios del tipo LoadBalancer para GDCV para Bare Metal en modo manual. En su lugar, puedes crear un objeto Ingress que use IngressGateway o crear NodePort y configurar de forma manual el balanceador de cargas externo para usar el servicio de Kubernetes como backend.

Para la Administración de servicios, también conocida como tráfico de este a oeste, te recomendamos usar Anthos Service Mesh. Anthos Service Mesh se basa en las API abiertas de Istio y proporciona observabilidad, autenticación, encriptación, controles de tráfico detallados y otras características y funciones uniformes. Para obtener más información sobre Administración de servicio, consulta Anthos Service Mesh.

Administración de estado y persistencia

GDCV para Bare Metal depende en gran medida de la infraestructura existente para el almacenamiento efímero, el almacenamiento de volumen y el almacenamiento de PersistentVolume. Los datos efímeros usan los recursos del disco local en el nodo en el que está programado el Pod de Kubernetes. Para los datos persistentes, GKE Enterprise es compatible con Container Storage Interface (CSI), una API de código abierto que admiten muchos proveedores de almacenamiento. Para el almacenamiento en producción, recomendamos instalar un controlador CSI de un socio de almacenamiento de GKE Enterprise Ready. Si deseas obtener una lista completa de los socios de almacenamiento de GKE Enterprise Ready, consulta los socios de almacenamiento de GKE Enterprise Ready.

Para obtener más información sobre el almacenamiento, consulta Configura el almacenamiento.

Bases de datos

GDCV para Bare Metal no proporciona capacidades adicionales específicas de la base de datos más allá de las capacidades estándar de la plataforma GKE Enterprise. La mayoría de las bases de datos se ejecutan en un sistema de administración de datos externo. Las cargas de trabajo en la plataforma GKE Enterprise también se pueden configurar para conectarse a cualquier base de datos externa accesible.

Observabilidad

Google Cloud Observability recopila métricas de supervisión y registros para GDCV para clústeres de Bare Metal, de manera similar a las políticas de recopilación y supervisión de clústeres de GKE. De forma predeterminada, los registros del clúster y las métricas del componente del sistema se envían a Cloud Monitoring. Para que Google Cloud Observability recopile registros y métricas de aplicaciones, habilita la opción clusterOperations.enableApplication en el archivo YAML de configuración del clúster.

Para obtener más información sobre la observabilidad, consulta Configura los registros y la supervisión.

Caso de uso: Implementación de Cymbal Bank

En esta guía, se usa la aplicación de Cymbal Bank/Bank of Anthos para simular la planificación, la implementación de la plataforma y el proceso de implementación de aplicaciones de GDCV para Bare Metal.

El resto de este documento está compuesto por tres secciones. En la sección Planificación, se describen las decisiones que se tomaron según las opciones que se analizan en las secciones del modelo de arquitectura. En la sección Implementación de la plataforma, se analizan las secuencias de comandos y los módulos que proporciona un repositorio de código fuente para implementar la plataforma de GKE Enterprise. Finalmente, en la sección Implementación de aplicaciones, la aplicación de Cymbal Bank se implementa en la plataforma.

Esta guía de GDCV para Bare Metal se puede usar para implementar en hosts autoadministrados o instancias de Compute Engine. Mediante los recursos de Google Cloud, cualquiera puede completar esta guía sin necesidad de acceder al hardware físico. El uso de instancias de Compute Engine es solo para fines de demostración. NO uses estas instancias para las cargas de trabajo de producción. Cuando el acceso al hardware físico está disponible y se usan los mismos rangos de direcciones IP, puedes usar el repositorio de código fuente proporcionado tal como está. Si el entorno difiere de lo que se describe en la sección Planificación, puedes modificar las secuencias de comandos y los módulos para que se ajusten a las diferencias. El repositorio de código fuente asociado contiene instrucciones para el hardware físico y las situaciones de la instancia de Compute Engine.

Planificación

En la siguiente sección, se detallan las decisiones arquitectónicas que se tomaron mientras se planificaba y diseñaba la plataforma para la implementación de la aplicación de Bank of GKE Enterprise en GDCV para Bare Metal. Estas secciones se enfocan en un entorno de producción. Para compilar entornos inferiores, como de desarrollo o de etapa de pruebas, puedes seguir pasos similares.

Proyectos de Google Cloud

Cuando se crean proyectos en Google Cloud para GDCV para Bare Metal, se requiere un proyecto host de flota. Se recomiendan proyectos adicionales para cada entorno o función empresarial. Esta configuración de proyecto te permite organizar los recursos según el rol que interactúa con el recurso.

En las siguientes subsecciones, se analizan los tipos de proyectos recomendados y los roles asociados a ellos.

Proyecto central

El proyecto central hub-prod es para el rol de administrador de red. Este proyecto es en el que el centro de datos local está conectado a Google Cloud mediante la forma seleccionada de conectividad híbrida. Para obtener más información sobre las opciones de conectividad híbrida, consulta Conectividad de Google Cloud.

Proyecto host de flotas

El proyecto host de la flota fleet-prod es para el rol de administradores de la plataforma. El proyecto es el lugar en el que se registran el GDCV para los clústeres de Bare Metal. Este proyecto es también el lugar en el que residen los recursos de Google Cloud relacionados con la plataforma. Estos recursos incluyen Google Cloud Observability, Cloud Source Repositories y otros. Un proyecto de Google Cloud determinado solo puede tener una flota (o ninguna flota) asociada. Esta restricción refuerza el uso de proyectos de Google Cloud para proporcionar un aislamiento más sólido entre los recursos que no se rigen ni se consumen juntos.

Aplicación o proyecto en equipo

La aplicación o el proyecto en equipo app-banking-prod es para el rol del desarrollador. En este proyecto se encuentran los recursos de Google Cloud específicos de la aplicación o específicos del equipo. El proyecto incluye todo, excepto los clústeres de Anthos. Según la cantidad de equipos o aplicaciones, puede haber varias instancias de este tipo de proyecto. La creación de proyectos distintos para distintos equipos te permite administrar de forma independiente IAM, la facturación y la cuota para cada equipo.

Herramientas de redes

Cada GDCV para un clúster de Bare Metal requiere las siguientes subredes de dirección IP:

  1. Direcciones IP de nodos
  2. Direcciones IP del Pod de Kubernetes
  3. Direcciones IP del servicio o del clúster de Kubernetes
  4. Direcciones IP del balanceador de cargas (modo en paquetes)

Para usar los mismos rangos de direcciones IP que no se pueden enrutar para el Pod de Kubernetes y las subredes de servicio en cada clúster, selecciona un modelo de red de modo isla. En esta configuración, los Pods pueden comunicarse de forma directa entre sí dentro de un clúster, pero no se puede acceder a ellos directamente desde fuera de un clúster (mediante direcciones IP de Pods). Esta configuración forma una isla dentro de la red que no está conectada a la red externa. Los clústeres forman una malla de nodo a nodo completa en los nodos del clúster dentro de la isla, lo que permite que el Pod llegue directamente a otros Pods dentro del clúster.

Asignación de direcciones IP

Clúster Nodo Pod Servicios Balanceador de cargas
metal-admin-dc1-000-prod 10.185.0.0/24 192.168.0.0/16 10.96.0.0/12 No disponible
metal-user-dc1a-000-prod 10.185.1.0/24 192.168.0.0/16 10.96.0.0/12 10.185.1.3-10.185.1.10
metal-user-dc1b-000-prod 10.185.2.0/24 192.168.0.0/16 10.96.0.0/12 10.185.2.3-10.185.2.10
metal-admin-dc2-000-prod 10.195.0.0/24 192.168.0.0/16 10.96.0.0/12 No disponible
metal-user-dc2a-000-prod 10.195.1.0/24 192.168.0.0/16 10.96.0.0/12 10.195.1.3-10.195.1.10
metal-user-dc2b-000-prod 10.195.2.0/24 192.168.0.0/16 10.96.0.0/12 10.195.2.3-10.195.2.10

En el modo isla, es importante garantizar que las subredes de la dirección IP elegidas para los Pods y servicios de Kubernetes no estén en uso o que se puedan enrutar desde la red de nodos.

Requisitos de red

A fin de proporcionar un balanceador de cargas integrado para GDCV para Bare Metal que no requiera configuración, usa el modo de balanceador de cargas en paquetes en cada clúster. Cuando las cargas de trabajo ejecutan los servicios LoadBalancer, se asigna una dirección IP del grupo del balanceador de cargas.

Para leer información detallada sobre los requisitos y la configuración del balanceador de cargas en paquetes, consulta Descripción general de los balanceadores de cargas y Configura el balanceo de cargas en paquetes.

Arquitectura del clúster

Para un entorno de producción, recomendamos usar un modelo de implementación de clúster de administrador y de usuario con un clúster de administrador y dos clústeres de usuario en cada ubicación geográfica para lograr la mayor redundancia y tolerancia a errores para GDCV para Bare Metal.

Recomendamos usar un mínimo de cuatro clústeres de usuario para cada entorno de producción. Usa dos ubicaciones con redundancia geográfica que contengan dos clústeres tolerantes a errores. Cada clúster tolerante a errores tiene hardware y conexiones de red redundantes. Disminuir la cantidad de clústeres reduce la redundancia o la tolerancia a errores de la arquitectura.

Para garantizar una alta disponibilidad, el plano de control de cada clúster usa tres nodos. Con un mínimo de tres nodos trabajadores por clúster de usuario, puedes distribuir las cargas de trabajo entre esos nodos para reducir e