Controles de la plataforma para desarrolladores

En esta sección, se describen los controles que se usan en la plataforma para desarrolladores.

Identidad, roles y grupos de la plataforma

Para acceder a los servicios de Google Cloud, se requieren identidades de Google Cloud. El plano usa Workload Identity de la flota para asignar las cuentas de servicio de Kubernetes que se usan como identidades de Pods a las cuentas de servicio de Google Cloud que controlan el acceso a los servicios de Google Cloud. Para ayudar a proteger las elevaciones entre entornos, cada entorno tiene un grupo de identidades separado (conocido como un conjunto de proveedores de identidad de confianza) para sus cuentas de Workload Identity.

Arquetipos de la plataforma

Cuando implementas el plano, creas tres tipos de grupos de usuarios: un equipo de plataforma para desarrolladores, un equipo de aplicaciones (un equipo por aplicación) y un equipo de operaciones de seguridad.

El equipo de la plataforma para desarrolladores es responsable del desarrollo y la administración de la plataforma para desarrolladores. Los miembros de este equipo son los siguientes:

• Desarrolladores de la plataforma para desarrolladores: Estos miembros del equipo extienden el plano y lo integran en los sistemas existentes. Este equipo también crea nuevas plantillas de aplicaciones.
• Administrador de la plataforma para desarrolladores: Este equipo es responsable de lo siguiente:
  • Aprobar la creación de equipos de usuarios nuevos
  • Realizar tareas programadas y no programadas que afectan a varios usuarios, incluidos los siguientes:
  • Aprobar la promoción de aplicaciones en el entorno de no producción y del entorno de producción
  • Coordinar actualizaciones de infraestructura
  • Crear planes de capacidad a nivel de la plataforma

Un usuario de la plataforma para desarrolladores es un solo equipo de desarrollo de software y quienes son responsables de la operación de ese software. El equipo de usuarios consta de dos grupos: desarrolladores de aplicaciones y operadores de aplicaciones. Las tareas de los dos grupos del equipo de usuarios son las siguientes:

• Desarrolladores de aplicaciones: Este equipo escribe y depura el código de la aplicación. A veces también se denominan ingenieros de software o desarrolladores de pila completa. Sus responsabilidades incluyen lo siguiente:
  • Realizar pruebas y control de calidad en un componente de aplicación cuando se implementa en el entorno de desarrollo
  • Administrar recursos de la nube de propiedad de la aplicación (como bases de datos y buckets de almacenamiento) en el entorno de desarrollo
  • Diseñar esquemas de base de datos o almacenamiento para que los usen las aplicaciones
• Operadores de aplicaciones o ingenieros de confiabilidad de sitios (SRE): Este equipo administra la confiabilidad de las aplicaciones que se ejecutan en los entornos de producción y el avance seguro de los cambios que realizan los desarrolladores de aplicaciones en producción. A veces se los llama operadores de servicios, ingenieros del sistema o administradores del sistema. Sus responsabilidades incluyen lo siguiente:
  • Planificar las necesidades de capacidad a nivel de la aplicación
  • Crear políticas de alertas y establecer objetivos de nivel de servicio (SLO) para los servicios
  • Diagnosticar problemas de servicio usando registros y métricas específicas de esa aplicación
  • Responder a alertas y páginas, como cuando un servicio no cumple con sus SLO
  • Trabajar con un grupo o con varios grupos de desarrolladores de aplicaciones
  • Aprobar la implementación de versiones nuevas en producción
  • Administrar los recursos de la nube de propiedad de la aplicación en los entornos de producción y de no producción (por ejemplo, copias de seguridad y actualizaciones de esquemas)

Estructura de la organización de la plataforma

El plano de la aplicación empresarial usa la estructura de la organización que proporciona el plano base de la empresa. En el siguiente diagrama, se muestra cómo los proyectos de plano de la aplicación empresarial se ajustan a la estructura del plano base.

Proyectos de la plataforma

En la siguiente tabla, se describen los proyectos adicionales, más allá de los que proporciona el plano base, que el plano de la aplicación necesita para implementar recursos, opciones de configuración y aplicaciones.

Carpeta	Proyecto	Descripción
common	eab-infra-cicd	Contiene la canalización de infraestructura de multiusuario para implementar la infraestructura de usuario.
	eab-app-factory	Contiene la fábrica de aplicaciones , que se usa para crear arquitecturas de aplicaciones de un solo usuario y canalizaciones de integración continua y de implementación continua (CI/CD). Este proyecto también contiene el Sincronizador de configuración que se usa para la configuración del clúster de GKE.
	eab-{tenant}-cicd	Contiene las canalizaciones de CI/CD de la aplicación, que se encuentran en proyectos independientes para habilitar la separación entre los equipos de desarrollo. Hay una canalización para cada aplicación.
development, nonproduction, production	eab-gke	Contiene los clústeres de GKE para la plataforma para desarrolladores y la lógica que se usa a fin de registrar clústeres para la administración de flotas.
	eab-{tenant} (1-n)	Contiene cualquier servicio de aplicación de usuario único, como bases de datos o servicios administrados que usan un equipo de aplicaciones.

Arquitectura del clúster de la plataforma

El plano implementa aplicaciones en tres entornos: desarrollo, no producción y producción. Cada entorno está asociado con una flota. En este plano, una flota es un proyecto que incluye uno o más clústeres. Sin embargo, las flotas también pueden agrupar varios proyectos. Una flota proporciona un límite de seguridad lógico para el control administrativo. Una flota es una manera de agrupar y normalizar clústeres de Kubernetes de forma lógica y facilita la administración de la infraestructura.

En el siguiente diagrama, se muestran dos clústeres de GKE, que se crean en cada entorno para implementar aplicaciones. Los dos clústeres actúan como clústeres de GKE idénticos en dos regiones diferentes para proporcionar resiliencia multirregional. Para aprovechar las capacidades de la flota, el plano usa el concepto de similitud entre los objetos, los servicios y la identidad del espacio de nombres.

El plano de la aplicación empresarial usa clústeres de GKE con espacios privados habilitados a través del acceso de Private Service Connect al plano de control y los grupos de nodos privados para quitar las posibles superficies de ataques de Internet. Ni los nodos del clúster ni el plano de control tienen un extremo público. Los nodos del clúster ejecutan Container-Optimized OS para limitar su superficie de ataque, y los nodos del clúster usan nodos de GKE protegidos para limitar la capacidad de un atacante para suplantar la identidad de un nodo.

El acceso de administrador a los clústeres de GKE se habilita a través de la puerta de enlace de Connect. Como parte de la implementación del plano, se usa una instancia de Cloud NAT para cada entorno para otorgar a los Pods y el Sincronizador de configuración un mecanismo para acceder a recursos en Internet, como GitHub. El acceso a los clústeres de GKE se controla con la autorización de RBAC de Kubernetes que se basa en Grupos de Google para GKE. Los grupos te permiten controlar las identidades mediante un sistema central de administración de identidades controlado por administradores de identidad.

Componentes de la plataforma GKE Enterprise

La plataforma para desarrolladores usa componentes de GKE Enterprise para permitirte compilar, entregar y administrar el ciclo de vida de tus aplicaciones. Los componentes de GKE Enterprise que se usan en la implementación del plano son los siguientes:

• GKE para la administración de contenedores
• Policy Controller para la administración y aplicación de políticas
• Anthos Service Mesh para la administración de servicios
• Autorización Binaria para la certificación de imágenes de contenedor
• GKE Gateway Controller para el controlador de puerta de enlace de varios clústeres para clústeres de GKE

Administración de flotas de la plataforma

Las flotas te permiten administrar varios clústeres de GKE de una manera unificada. La administración del equipo de flotas facilita a los administradores de la plataforma el aprovisionamiento y la administración de los recursos de infraestructura para los usuarios de plataformas para desarrolladores. Los usuarios tienen un control con permisos para los recursos dentro de su propio espacio de nombres, incluidas sus aplicaciones, registros y métricas.

Para aprovisionar subconjuntos de recursos de flota por equipo, los administradores pueden usar permisos de equipo. Los permisos de equipo te permiten definir subconjuntos de recursos de flota para cada equipo, con cada permiso de equipo asociado con uno o más clústeres miembros de la flota.

Los espacios de nombres de la flota proporcionan control sobre quién tiene acceso a espacios de nombres específicos dentro de tu flota. La aplicación usa dos clústeres de GKE que se implementan en una flota, con tres permisos de equipo, y cada permiso tiene un espacio de nombres de flota.

En el siguiente diagrama, se muestran la flota y los recursos de permisos que corresponden a los clústeres de muestra en un entorno, como lo implementa el plano.

Redes de la plataforma

Para las redes, los clústeres de GKE se implementan en una VPC compartida que se crea como parte del plano empresarial básico. Los clústeres de GKE requieren que se asignen varios rangos de direcciones IP en los entornos de desarrollo, no producción y producción. Cada clúster de GKE que usa el plano necesita rangos de direcciones IP independientes asignados para los nodos, los Pods, los servicios y el plano de control. Las instancias de AlloyDB para PostgreSQL también requieren rangos de direcciones IP independientes.

En la siguiente tabla, se describen los rangos de direcciones IP y las subredes de VPC que se usan en los diferentes entornos para implementar los clústeres de plano. Para el entorno de desarrollo en la región 2 del clúster de GKE de la aplicación, el plano implementa solo un espacio de direcciones IP, aunque haya espacio de direcciones IP asignado para dos clústeres de GKE de desarrollo.

Recurso	Tipo de rango de direcciones IP	Desarrollo	No producción	Producción
Región 1 del clúster de GKE de la aplicación	Rango de direcciones IP principal	10.0.64.0/24	10.0.128.0/24	10.0.192.0/24
	Rango de direcciones IP del Pod	100.64.64.0/24	100.64.128.0/24	100.64.192.0/24
	Rango de direcciones IP del servicio	100.0.80.0/24	100.0.144.0/24	100.0.208.0/24
	Rango de direcciones IP del plano de control de GKE	10.16.0.0/21	10.16.8.0/21	10.16.16.0/21
Región 2 del clúster de GKE de la aplicación	Rango de direcciones IP principal	10.1.64.0/24	10.1.128.0/24	10.1.192.0/24
	Rango de direcciones IP del Pod	100.64.64.0/24	100.64.128.0/24	100.64.192.0/24
	Rango de direcciones IP del servicio	100.1.80.0/24	100.1.144.0/24	100.1.208.0/24
	Rango de direcciones IP del plano de control de GKE	10.16.0.0/21	10.16.8.0/21	10.16.16.0/21
AlloyDB para PostgreSQL	Rango de direcciones IP de la base de datos	10.9.64.0/18	10.9.128.0/18	10.9.192.0/18

Si necesitas diseñar tu propio esquema de asignación de direcciones IP, consulta Administración de direcciones IP en GKE y Planificación de direcciones IPv4 de GKE.

DNS de plataformas

El plano usa Cloud DNS para GKE para proporcionar resolución de DNS a los Pods y servicios de Kubernetes. Cloud DNS para GKE es un DNS administrado que no requiere un proveedor de DNS alojado en clústeres.

En el plano, Cloud DNS está configurado para el permiso de VPC. El permiso de VPC permite que los servicios de todos los clústeres de GKE en un proyecto compartan una sola zona del DNS. Una sola zona del DNS permite que los servicios se resuelvan en todos los clústeres, y las VMs o los Pods fuera del clúster pueden resolver los servicios dentro del clúster.

Firewalls de la plataforma

GKE crea automáticamente reglas de firewall cuando crea clústeres de GKE, Servicios de GKE, firewalls de GKE Gateway y firewalls de GKE Ingress que permiten que los clústeres funcionen en tus entornos. La prioridad para todas las reglas de firewall creadas automáticamente es 1,000. Estas reglas son necesarias porque el plano de base empresarial tiene una regla predeterminada para bloquear el tráfico en la VPC compartida.

Acceso de la plataforma a los servicios de Google Cloud

Debido a que las aplicaciones de plano usan clústeres privados, el Acceso privado a Google proporciona acceso a los servicios de Google Cloud.

Alta disponibilidad de la plataforma

El plano se diseñó para ser resistente a las interrupciones zonales y regionales. Los recursos necesarios para mantener las aplicaciones en ejecución se distribuyen en dos regiones. Selecciona las regiones en las que deseas implementar el plano. Los recursos que no se encuentran en la ruta esencial para entregar la carga y responder a ella son solo una región o son globales. En la siguiente tabla, se describen los recursos y dónde se implementan.

Ubicación	Región 1	Región 2	Global
Entornos con recursos en esta ubicación	common development nonproduction production	nonproduction production	common development nonproduction production
Proyectos con recursos en esta ubicación	eab-gke-{env} eab-infra-cicd eab-{ns}-cicd	eab-gke-{env} eab-{ns}-cicd (only for the Artifact Registry mirror)	eab-gke-{env}
Tipos de recursos en esta ubicación	Clúster de GKE (aplicaciones y configuración de la puerta de enlace) Artifact Registry AlloyDB para PostgreSQL Cloud Build Cloud Deploy	Clúster de GKE (solo aplicaciones) Artifact Registry AlloyDB para PostgreSQL	Cloud Logging Cloud Monitoring Cloud Load Balancing Permisos de la flota Espacios de nombres de flotas

En la siguiente tabla, se resume cómo reaccionan los diferentes componentes ante una interrupción regional o zonal, y cómo puedes mitigar estos efectos.

Permiso de falla	Efectos de servicios externos	Efectos de la base de datos	Efectos de compilación e implementación	Efectos de las canalizaciones de Terraform
Una zona de la región 1	Disponible.	Disponible. La instancia en espera se activa con cero RPO.	Es posible que se necesite un cambio manual. Es posible que debas reiniciar cualquier comando terraform apply que esté en curso, pero que se haya completado durante la interrupción.	Es posible que se necesite un cambio manual. Es posible que debas reiniciar cualquier comando terraform apply que esté en curso, pero que se haya completado durante la interrupción.
Una zona de la región 2	Disponible.	Disponible.	Disponible.	Es posible que se necesite un cambio manual. Es posible que debas reiniciar cualquier comando terraform apply que esté en curso, pero que se haya completado durante la interrupción.
Región 1	Disponible.	Se necesita un cambio manual. Un operador debe ascender el clúster secundario de forma manual.	No disponible.	No disponible.
Región 2	Disponible.	Disponible.	Disponible; es posible que se necesite un cambio manual Las compilaciones permanecen disponibles. Es posible que debas implementar compilaciones nuevas de forma manual. Es posible que las compilaciones existentes no se completen de forma correcta.	Disponible.

Las interrupciones del proveedor de servicios en la nube son solo una fuente del tiempo de inactividad. La alta disponibilidad también depende de los procesos y las operaciones que ayudan a que los errores sean menos probables. En la siguiente tabla, se describen todas las decisiones tomadas en el plano que se relacionan con la alta disponibilidad y los motivos de esas decisiones.

Decisión de plano	Impacto en la disponibilidad
Administración de cambios
Usa IaC y GitOps.	Admite la revisión de compañeros de cambios y admite la reversión con rapidez a la configuración anterior.
Asciende los cambios de forma gradual a través de los entornos.	Reduce el impacto de los errores de software y configuración.
Haz que los entornos de no producción y de producción sean similares.	Garantiza que las diferencias no retrasen el descubrimiento de un error. Ambos entornos son birregionales.
Cambia los recursos replicados de una región a la vez dentro de un entorno.	Garantiza que los problemas que no se detectan usando el ascenso gradual solo afecten a la mitad de la infraestructura del entorno de ejecución.
Cambia un servicio en una región a la vez dentro de un entorno.	Garantiza que los problemas que no se detectan usando el ascenso gradual solo afecten a la mitad de las réplicas del servicio.
Infraestructura de procesamiento replicada
Usa un plano de control de clúster regional.	El plano de control regional está disponible durante la actualización y el cambio de tamaño.
Crea un grupo de nodos multizona.	Un grupo de nodos del clúster tiene al menos tres nodos distribuidos en tres zonas.
Configura una red de VPC compartida.	La red de VPC compartida abarca dos regiones. Una falla regional solo afecta el tráfico de red desde y hacia los recursos en la región con errores.
Replica el registro de imágenes.	Las imágenes se almacenan en Artifact Registry, que está configurado para replicarse en varias regiones para que una interrupción de la región de la nube no impida el escalamiento vertical de la aplicación en la región vigente.
Servicios replicados
Implementa réplicas de servicio en dos regiones.	En el caso de una interrupción regional, un servicio de Kubernetes permanece disponible en los entornos de producción y de no producción.
Usa actualizaciones progresivas para cambiar cambios dentro de una región.	Puedes actualizar los servicios de Kubernetes con un patrón de implementación de actualización progresiva que reduce el riesgo y el tiempo de inactividad.
Configura tres réplicas en una región para cada servicio.	Un servicio de Kubernetes tiene, al menos, tres réplicas (Pods) para admitir actualizaciones progresivas en el entorno de producción y de no producción.
Distribuye los Pods de la implementación en varias zonas.	Los servicios de Kubernetes se distribuyen en las VMs en diferentes zonas usando una estrofa antiafinidad. Se puede tolerar una interrupción de un solo nodo o la interrupción completa de la zona sin que se genere tráfico adicional entre regiones entre los servicios dependientes.
Almacenamiento replicado
Implementa instancias de bases de datos multizona.	AlloyDB para PostgreSQL ofrece alta disponibilidad en una región. Los nodos redundantes de la instancia principal se encuentran en dos zonas diferentes de la región. La instancia principal mantiene la disponibilidad regional a través de la activación de una conmutación por error automática a la zona en espera si la zona activa encuentra un problema. El almacenamiento regional ayuda a proporcionar durabilidad de datos en caso de pérdida de una sola zona.
Replica las bases de datos entre regiones.	AlloyDB para PostgreSQL usa la replicación entre regiones para proporcionar capacidades de recuperación ante desastres. La base de datos replica de forma asíncrona los datos del clúster principal en clústeres secundarios que se encuentran en regiones separadas de Google Cloud.
Operaciones
Aprovisiona las aplicaciones para el doble de la carga esperada.	Si un clúster falla (por ejemplo, debido a una interrupción del servicio regional), la parte del servicio que se ejecuta en el clúster restante puede absorber la carga por completo.
Repara nodos automáticamente.	Los clústeres se configuran con la reparación automática de nodos. Si las verificaciones de estado consecutivas de un nodo fallan varias veces durante un período prolongado, GKE inicia un proceso de reparación para ese nodo.
Asegúrate de que las actualizaciones del grupo de nodos reconozcan las aplicaciones.	Los Deployments definen un presupuesto de interrupción de Pods con maxUnavailable: 1 para permitir actualizaciones de grupos de nodos paralelas en clústeres grandes. No más de una de tres réplicas (en el entorno de desarrollo) o una de seis réplicas (en entornos de no producción y producción) no están disponibles durante las actualizaciones del grupo de nodos.
Reinicia automáticamente los servicios interbloqueados.	La implementación que respalda un servicio define un sondeo en funcionamiento, que identifica y reinicia los procesos interbloqueados.
Verifica de forma automática que las réplicas estén listas.	La implementación que respalda un servicio define un sondeo de preparación, que identifica cuándo una aplicación está lista para entregar después de iniciarse. Un sondeo de preparación elimina la necesidad de realizar verificaciones manuales o tiempos de espera durante las actualizaciones progresivas y las de grupos de nodos.

La arquitectura de referencia está diseñada para aplicaciones con requisitos de alta disponibilidad zonales y regionales. Garantizar una alta disponibilidad genera algunos costos (por ejemplo, costos de reserva en espera o costos de replicación entre regiones). En la sección Alternativas, se describen algunas formas de mitigar estos costos.

Cuotas, límites de rendimiento y límites de escalamiento de la plataforma

Puedes controlar las cuotas, el rendimiento y el escalamiento de los recursos en la plataforma para desarrolladores. En la siguiente lista, se describen algunos elementos que debes considerar:

• La infraestructura base requiere varios proyectos y cada usuario adicional requiere cuatro proyectos. Es posible que debas solicitar una cuota de proyecto adicional antes de implementar y agregar más usuarios.
• Existe un límite de 100 recursos de MultiClusterGateway para cada proyecto. Cada servicio de Kubernetes orientado a Internet en la plataforma para desarrolladores requiere una MultiClusterGateway.
• Cloud Logging tiene un límite de 100 buckets en un proyecto. El acceso a los registros por usuario en el plano se basa en un bucket para cada usuario.
• Para crear más de 20 usuarios, puedes solicitar un aumento de la cuota del proyecto para los recursos de permiso y de permiso es espacio de nombres. Si deseas obtener instrucciones para ver las cuotas, consulta Visualiza y administra cuotas. Usa un filtro para encontrar los tipos de cuota gkehub.googleapis.com/global-per-project-scopes y gkehub.googleapis.com/global-per-project-scope-namespaces.

Próximos pasos

• Lee sobre la arquitectura del servicio (siguiente documento de esta serie).