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:
- Infraestructura: Esta capa incluye almacenamiento, procesamiento y herramientas de redes, manejadas con construcciones locales.
- 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.
- Capa de administración de contenedores: Esta capa usa clústeres de GKE.
- Capa de administración de servicios: Esta capa usa Anthos Service Mesh.
- Capa de administración de políticas: Esta capa usa el Sincronizador de configuración y Policy Controller.
- Capa de administración de aplicaciones: Esta capa usa Cloud Build y Cloud Source Repositories.
- 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:
- Protocolo de resolución de direcciones (ARP): Requiere la conectividad de capa 2 entre los nodos que ejecutan el balanceador de cargas.
- Protocolo de Puerta de Enlace Fronteriza (BGP): Usa intercambio de tráfico con tu red de clústeres (que es un sistema autónomo) con otro sistema autónomo, como una red externa.
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:
- Direcciones IP de nodos
- Direcciones IP del Pod de Kubernetes
- Direcciones IP del servicio o del clúster de Kubernetes
- 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 el impacto si un nodo se desconecta. La cantidad y el tamaño de los nodos trabajadores dependen en gran medida del tipo y la cantidad de cargas de trabajo que se ejecuten en el clúster. El tamaño recomendado para cada uno de los nodos se analiza en Configura hardware para GDCV para Bare Metal.
En la tabla siguiente, se describe el tamaño del nodo recomendado para los núcleos de CPU, la memoria y el almacenamiento local del disco en este caso de uso.
| Tipo de nodo | CPU/CPU virtuales | Memoria | Almacenamiento |
|---|---|---|---|
| Plano de control | 8 núcleos | 32 GiB | 256 GiB |
| Trabajador | 8 núcleos | 64 GiB | 512 GiB |
Para obtener más información sobre los requisitos y el tamaño de la máquina, consulta los requisitos de la máquina de nodo del clúster.
Identity management
Para la administración de identidades, recomendamos una integración en OIDC a través del GKE Identity Service. En los ejemplos proporcionados en el repositorio de código fuente, la autenticación local se usa para simplificar los requisitos. Si OIDC está disponible, puedes modificar el ejemplo para usarlo. Si deseas obtener más información, consulta Administración de identidades con OIDC en GDCV para Bare Metal.
Administración de políticas y seguridad
En el caso de uso de Cymbal Bank, se usan el Sincronizador de configuración y Policy Controller para la administración de políticas. Se crea un repositorio de Cloud Source Repositories para almacenar los datos de configuración que usa el Sincronizador de configuración. El operador ConfigManagement, que se usa para instalar y administrar el Sincronizador de configuración y Policy Controller, necesita acceso de solo lectura al repositorio de origen de la configuración. Para otorgar ese acceso, usa una forma de autenticación aceptable. En este ejemplo, se usa una cuenta de servicio de Google.
Servicios
Para la administración de servicios en este caso de uso, Anthos Service Mesh se usa con el fin de proporcionar una base en la que se compilen los servicios distribuidos. De forma predeterminada, también se crea un IngressGateway en el clúster que controla los objetos Ingress estándar de Kubernetes.
Administración de estado y persistencia
Debido a que el almacenamiento persistente depende en gran medida de la infraestructura existente, en este caso de uso no se requiere. Sin embargo, en otros casos, te sugerimos usar las opciones de almacenamiento de Socios de almacenamiento de GKE Enterprise Ready. Si hay una opción de almacenamiento CSI disponible, se puede instalar en el clúster con las instrucciones que proporciona el proveedor. Para la prueba de concepto y los casos de uso avanzados, puedes usar volúmenes locales. Sin embargo, para la mayoría de los casos de uso, no recomendamos usar volúmenes locales en los entornos de producción.
Bases de datos
Muchas aplicaciones con estado en GDCV para Bare Metal usan bases de datos como su almacén de persistencia. Una aplicación de base de datos con estado necesita acceso a una base de datos para proporcionar su lógica empresarial a los clientes. No hay restricciones sobre el tipo de Datastore que usa GDCV para Bare Metal. Por lo tanto, el desarrollador o los equipos de administración de datos asociados deben tomar decisiones sobre el almacenamiento de datos. Dado que las diferentes aplicaciones pueden requerir diferentes almacenes de datos, esos almacenes también se pueden usar sin limitaciones. Las bases de datos se pueden administrar en clústeres, de manera local o incluso en la nube.
La aplicación de Cymbal Bank es una aplicación con estado que accede a dos bases de datos de PostgreSQL. El acceso a la base de datos se configura a través de las variables de entorno. La base de datos de PostgreSQL debe ser accesible desde los nodos que ejecutan las cargas de trabajo, incluso si la base de datos se administra de forma externa desde el clúster. En este ejemplo, la aplicación accede a una base de datos de PostgreSQL externa existente. Mientras la aplicación se ejecuta en la plataforma, la base de datos se administra de forma externa. Por lo tanto, la base de datos no forma parte de la plataforma de GKE Enterprise. Si hay una base de datos de PostgreSQL disponible, úsala. De lo contrario, crea y usa una base de datos de Cloud SQL para la aplicación de Cymbal Bank.
Observabilidad
Cada clúster del caso de uso de Cymbal Bank está configurado para que Google Cloud Observability recopile registros y métricas para los componentes del sistema y las aplicaciones. Hay varios paneles de Cloud Monitoring que creó el instalador de la consola de Google Cloud y se pueden ver en la página Paneles de Monitoring. Para obtener más información sobre la observabilidad, consulta Configura los registros y la supervisión y Cómo funcionan Logging y Monitoring para GDCV para Bare Metal.
Implementación de la plataforma
Para obtener más información, consulta la sección Implementa la plataforma de la documentación en el repositorio de código fuente de GitHub.
Implementación de la aplicación
Para obtener más información, consulta la sección Implementa la aplicación de la documentación en el repositorio de código fuente de GitHub.
¿Qué sigue?
- Obtén más información sobre Anthos Service Mesh, el Sincronizador de configuración y Policy Controller.
- Observa algunas de las otras arquitecturas de referencia de GKE Enterprise.
- Prueba GKE Enterprise en Google Cloud con la implementación de muestra de GKE Enterprise.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.