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 necesitan identidades. Google Cloud El blueprint usa Workload Identity Federation para GKE de la flota para asociar las cuentas de servicio de Kubernetes que se usan como identidades de los pods a las Google Cloud cuentas de servicio que controlan el acceso a los Google Cloud servicios. Para protegerse frente a las escaladas entre entornos, cada entorno tiene un grupo de identidades independiente (conocido como conjunto de proveedores de identidades de confianza) para sus cuentas de Workload Identity Federation for GKE.
Perfiles ficticios de la plataforma
Cuando implementas el blueprint, creas tres tipos de grupos de usuarios: un equipo de plataforma de desarrollo, un equipo de aplicaciones (un equipo por aplicación) y un equipo de operaciones de seguridad.
El equipo de la plataforma para desarrolladores se encarga del desarrollo y la gestión de la plataforma para desarrolladores. Los miembros de este equipo son los siguientes:
- Desarrolladores de plataformas para desarrolladores: estos miembros del equipo amplían el plan y lo integran en los sistemas actuales. Este equipo también crea plantillas de aplicaciones.
- Administrador de la plataforma para desarrolladores: este equipo se encarga de lo siguiente:
- Aprobar la creación de equipos de nuevos inquilinos.
- Realizar tareas programadas y no programadas que afecten a varios clientes, como las siguientes:
- Aprobar la promoción de aplicaciones al entorno de no producción y al entorno de producción.
- Coordinar las actualizaciones de la infraestructura.
- Crear planes de capacidad a nivel de plataforma.
Un arrendatario de la plataforma para desarrolladores es un equipo de desarrollo de software y los responsables del funcionamiento de ese software. El equipo del arrendatario consta de dos grupos: desarrolladores de aplicaciones y operadores de aplicaciones. Las tareas de los dos grupos del equipo del arrendatario son las siguientes:
- Desarrolladores de aplicaciones: este equipo escribe y depura el código de las aplicaciones. También se les llama ingenieros de software o desarrolladores full-stack. Sus responsabilidades son las siguientes:
- Realizar pruebas y control de calidad en un componente de una aplicación cuando se implementa en el entorno de desarrollo.
- Gestionar los recursos en la nube propiedad de la aplicación (como bases de datos y contenedores de almacenamiento) en el entorno de desarrollo.
- Diseñar esquemas de bases de datos o de almacenamiento para que los usen las aplicaciones.
- Operadores de aplicaciones o ingenieros de fiabilidad de sitios (SRE): este equipo gestiona la fiabilidad de las aplicaciones que se ejecutan en los entornos de producción y el avance seguro de los cambios realizados por los desarrolladores de aplicaciones en la producción. A veces se les llama operadores de servicios, ingenieros de sistemas o administradores de sistemas. Entre sus responsabilidades se incluyen las siguientes:
- Planificar las necesidades de capacidad a nivel de aplicación.
- Crear políticas de alertas y definir objetivos de nivel de servicio para los servicios.
- Diagnosticar problemas de servicio mediante registros y métricas específicos de esa aplicación.
- Responder a alertas y páginas, por ejemplo, cuando un servicio no cumple sus SLOs.
- Trabajar con un grupo o varios grupos de desarrolladores de aplicaciones.
- Aprobar el lanzamiento de nuevas versiones en producción.
- Gestionar los recursos en la nube propiedad de la aplicación en los entornos de no producción y producción (por ejemplo, copias de seguridad y actualizaciones de esquemas).
Estructura de la organización de la plataforma
El blueprint de aplicación empresarial usa la estructura de la organización que proporciona el blueprint de aspectos básicos de seguridad para empresas. En el siguiente diagrama se muestra cómo encajan los proyectos de planos técnicos de aplicaciones empresariales en la estructura del plano técnico de la base.
Proyectos de plataforma
En la siguiente tabla se describen los proyectos adicionales, además de los proporcionados por el plano técnico de la base, que necesita el plano técnico de la aplicación para implementar recursos, configuraciones y aplicaciones.
| Carpeta | Proyecto | Descripción |
|---|---|---|
|
|
Contiene la pipeline de infraestructura multiempresa para implementar la infraestructura de la empresa. |
|
Contiene la fábrica de aplicaciones , que se usa para crear una arquitectura de aplicaciones de un solo inquilino y flujos de procesamiento de integración continua y despliegue continuo (CI/CD). Este proyecto también contiene Config Sync, que se usa para configurar clústeres de GKE. |
|
|
Contiene los flujos de procesamiento de CI/CD de la aplicación, que se encuentran en proyectos independientes para permitir la separación entre los equipos de desarrollo. Hay una canalización por cada aplicación. |
|
|
|
Contiene los clústeres de GKE de la plataforma para desarrolladores y la lógica que se usa para registrar clústeres en la gestión de flotas. |
( |
Contiene cualquier servicio de aplicación de un solo inquilino, como bases de datos u otros servicios gestionados que utilice un equipo de aplicaciones. |
Arquitectura de clústeres de plataforma
El plano técnico despliega aplicaciones en tres entornos: desarrollo, no producción y producción. Cada entorno está asociado a una flota. En este plano, una flota es un proyecto que incluye uno o varios 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 proporciona una forma de agrupar y normalizar lógicamente los clústeres de Kubernetes, lo que 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 desplegar 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 funciones de la flota, el blueprint usa el concepto de igualdad en objetos, servicios e identidades de espacios de nombres.
El plano técnico de la aplicación empresarial usa clústeres de GKE con espacios privados habilitados mediante el acceso de Private Service Connect al plano de control y grupos de nodos privados para eliminar posibles superficies de ataque de Internet. Ni los nodos del clúster ni el plano de control tienen un endpoint público. Los nodos del clúster ejecutan Container-Optimized OS para limitar su superficie de ataque y usan nodos de GKE protegidos para limitar la capacidad de un atacante de suplantar la identidad de un nodo.
El acceso administrativo a los clústeres de GKE se habilita a través de la puerta de enlace Connect. Como parte de la implementación del blueprint, se usa una instancia de Cloud NAT para cada entorno con el fin de proporcionar a los pods y a Config Sync un mecanismo para acceder a recursos de Internet, como GitHub. El acceso a los clústeres de GKE se controla mediante la autorización RBAC de Kubernetes, que se basa en Grupos de Google para GKE. Los grupos te permiten controlar las identidades mediante un sistema de gestión de identidades centralizado que controlan los administradores de identidades.
Componentes de la plataforma GKE Enterprise
La plataforma para desarrolladores usa componentes de GKE Enterprise para que puedas crear, lanzar y gestionar el ciclo de vida de tus aplicaciones. Los componentes de GKE Enterprise que se usan en el despliegue del blueprint son los siguientes:
- GKE para la gestión de contenedores
- Policy Controller para la gestión y la aplicación de políticas
- Cloud Service Mesh para la gestión de servicios
- Autorización binaria para la atestación de imágenes de contenedor
- Controlador de puerta de enlace de GKE para el controlador de puerta de enlace multiclúster de clústeres de GKE
Gestión de flotas de la plataforma
Las flotas te permiten gestionar varios clústeres de GKE de forma unificada. Gestión de equipos de la flota: facilita a los administradores de la plataforma el aprovisionamiento y la gestión de recursos de infraestructura para los arrendatarios de la plataforma para desarrolladores. Los arrendatarios tienen control acotado de los recursos de su propio espacio de nombres, incluidas sus aplicaciones, sus registros y sus métricas.
Para aprovisionar subconjuntos de recursos de flota por equipos, los administradores pueden usar permisos de equipo. Los permisos de equipo te permiten definir subconjuntos de recursos de flota para cada equipo y asociar cada permiso de equipo a uno o varios clústeres que formen parte de una flota.
Los espacios de nombres de la flota te permiten controlar quién tiene acceso a espacios de nombres específicos de tu flota. La aplicación usa dos clústeres de GKE que se han desplegado en una flota con tres ámbitos de equipo, y cada ámbito tiene un espacio de nombres de flota.
En el siguiente diagrama se muestran los recursos de flota y de ámbito que corresponden a clústeres de ejemplo de un entorno, tal como se implementan en el blueprint.
Redes de la plataforma
En cuanto a la red, los clústeres de GKE se implementan en una VPC compartida que se crea como parte del plano de aspectos básicos de la empresa. Los clústeres de GKE requieren que se asignen varios intervalos de direcciones IP en los entornos de desarrollo, no de producción y de producción. Cada clúster de GKE que utilice el blueprint necesita intervalos de direcciones IP independientes asignados a 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 las subredes de VPC y los intervalos de direcciones IP que se usan en los diferentes entornos para implementar los clústeres de la blueprint. En el entorno de desarrollo de la región 2 del clúster de GKE de la aplicación, el blueprint solo despliega un espacio de direcciones IP, aunque se haya asignado espacio de direcciones IP a dos clústeres de GKE de desarrollo.
| Recurso | Tipo de intervalo de direcciones IP | Desarrollo | Fuera de producción | Producción |
|---|---|---|---|---|
Región 1 del clúster de GKE de la aplicación |
Intervalo de direcciones IP principal |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
Intervalo de direcciones IP de pods |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Intervalo de direcciones IP de servicio |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
Intervalo 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 |
Intervalo de direcciones IP principal |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
Intervalo de direcciones IP de pods |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Intervalo de direcciones IP de servicio |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
Intervalo 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 for PostgreSQL |
Intervalo 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 Gestión de direcciones IP en GKE y Planificación de direcciones IPv4 de GKE.
DNS de la plataforma
El plano técnico usa Cloud DNS para GKE para proporcionar resolución de DNS para pods y servicios de Kubernetes. Cloud DNS para GKE es un DNS gestionado que no requiere un proveedor de DNS alojado en un clúster.
En el plano, Cloud DNS está configurado para el ámbito de VPC. El ámbito de VPC permite que los servicios de todos los clústeres de GKE de un proyecto compartan una única zona DNS. Una sola zona DNS permite que los servicios se resuelvan en todos los clústeres, y las VMs o los pods que estén fuera del clúster pueden resolver los servicios que estén dentro del clúster.
Cortafuegos de la plataforma
GKE crea automáticamente reglas de cortafuegos al crear clústeres de GKE, servicios de GKE, cortafuegos de GKE Gateway y cortafuegos de GKE Ingress, lo que permite que los clústeres funcionen en tus entornos. La prioridad de todas las reglas de cortafuegos creadas automáticamente es 1000. Estas reglas son necesarias porque el plano técnico de la base de la empresa tiene una regla predeterminada para bloquear el tráfico en la VPC compartida.
Acceso a la plataforma para los servicios de Google Cloud
Como las aplicaciones de planos usan clústeres privados, Acceso privado de Google proporciona acceso a los servicios de Google Cloud .
Alta disponibilidad de la plataforma
El plano se ha diseñado para que sea resistente a las interrupciones de zonas y regiones. Los recursos necesarios para que las aplicaciones sigan funcionando se distribuyen en dos regiones. Selecciona las regiones en las que quieres implementar el blueprint. Los recursos que no están en la ruta crítica para servir y responder a la carga solo están en 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 |
|
|
|
Proyectos con recursos en esta ubicación |
|
|
|
Tipos de recursos de esta ubicación |
|
|
|
En la siguiente tabla se resume cómo reaccionan los diferentes componentes ante una interrupción en una región o en una zona, y cómo puedes mitigar estos efectos.
Ámbito de error |
Efectos de servicios externos |
Efectos de base de datos | Crear y desplegar efectos | Efectos de las canalizaciones de Terraform |
|---|---|---|---|---|
Una zona de la región 1 |
Disponible. |
Disponible. La instancia de espera se activa con un RPO de cero. |
Disponible, puede que sea necesario cambiarlo manualmente. Es posible que tengas que reiniciar cualquier comando |
Disponible, puede que sea necesario cambiarlo manualmente. Es posible que tengas que reiniciar cualquier comando |
Una zona de la región 2 |
Disponible. |
Disponible. |
Disponible. |
Disponible, puede que sea necesario cambiarlo manualmente. Es posible que tengas que reiniciar cualquier comando |
Región 1 |
Disponible. |
Se necesita un cambio manual. Un operador debe promocionar el clúster secundario manualmente. |
No disponible. |
No disponible. |
Región 2 |
Disponible. |
Disponible. |
Disponible, puede que sea necesario cambiarlo manualmente Las compilaciones siguen estando disponibles. Es posible que tengas que implementar nuevas compilaciones manualmente. Es posible que las compilaciones no se completen correctamente. |
Disponible. |
Las interrupciones de los proveedores de servicios en la nube son solo una de las causas del tiempo de inactividad. La alta disponibilidad también depende de procesos y operaciones que ayudan a reducir la probabilidad de que se produzcan errores. En la siguiente tabla se describen todas las decisiones tomadas en el plan que están relacionadas con la alta disponibilidad y los motivos de esas decisiones.
| Decisión de Blueprint | Impacto de disponibilidad |
|---|---|
Gestión de cambios |
|
Usa GitOps e IaC. |
Permite que otros usuarios revisen los cambios y volver rápidamente a configuraciones anteriores. |
Promociona los cambios de forma gradual en los entornos. |
Reduce el impacto de los errores de software y de configuración. |
Haz que los entornos de producción y los que no sean de producción sean similares. |
Asegura que las diferencias no retrasen la detección de un error. Ambos entornos son birregionales. |
Cambia los recursos replicados de una región a la vez en un entorno. |
Asegura que los problemas que no se detectan en la promoción gradual solo afecten a la mitad de la infraestructura de tiempo de ejecución. |
Cambia un servicio de una región cada vez en un entorno. |
Asegura que los problemas que no se detectan en la promoción gradual solo afecten a la mitad de las réplicas del servicio. |
Infraestructura de computación 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 de un 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. Un fallo regional solo afecta al tráfico de red hacia y desde los recursos de la región afectada. |
Replica el registro de imágenes. |
Las imágenes se almacenan en Artifact Registry, que está configurado para replicarse en varias regiones, de modo que una interrupción en una región de la nube no impida que la aplicación se escale verticalmente en la región que siga operativa. |
Servicios replicados |
|
Despliega réplicas del servicio en dos regiones. |
En caso de que se produzca una interrupción regional, un servicio de Kubernetes seguirá estando disponible en los entornos de producción y no producción. |
Usa actualizaciones continuas para aplicar cambios en los servicios de una región. |
Puedes actualizar los servicios de Kubernetes mediante un patrón de implementación de actualización continua que reduce los riesgos 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 continuas en el entorno de producción y en el de no producción. |
Distribuye los pods del despliegue en varias zonas. |
Los servicios de Kubernetes se distribuyen entre las VMs de diferentes zonas mediante una estrofa de antiafinidad. Se puede tolerar una interrupción de un solo nodo o un fallo completo de la zona sin incurrir en tráfico entre regiones adicional entre los servicios dependientes. |
Almacenamiento replicado |
|
Implementa instancias de base de datos multizona. |
AlloyDB para PostgreSQL ofrece alta disponibilidad en una región. Los nodos redundantes de su instancia principal se encuentran en dos zonas diferentes de la región. La instancia principal mantiene la disponibilidad regional activando una conmutación por error automática a la zona de espera si la zona activa tiene algún problema. El almacenamiento regional ayuda a proporcionar durabilidad de los datos en caso de que se pierda una sola zona. |
Replica bases de datos entre regiones. |
AlloyDB para PostgreSQL usa la replicación entre regiones para ofrecer funciones de recuperación ante desastres. La base de datos replica de forma asíncrona los datos de tu clúster principal en clústeres secundarios ubicados enGoogle Cloud regiones independientes. |
Operaciones |
|
Aprovisiona las aplicaciones para el doble de la carga prevista. |
Si falla un clúster (por ejemplo, debido a una interrupción del servicio regional), la parte del servicio que se ejecuta en el clúster restante puede absorber por completo la carga. |
Reparar nodos automáticamente. |
Los clústeres están configurados con la reparación automática de nodos. Si un nodo no supera sucesivas comprobaciones del estado durante un periodo prolongado, GKE inicia el proceso de reparación. |
Asegúrate de que las actualizaciones de grupos de nodos tengan en cuenta las aplicaciones. |
Las implementaciones definen un presupuesto de interrupción de pods con |
Reinicia automáticamente los servicios bloqueados. |
El despliegue que respalda un servicio define una prueba de vivacidad, que identifica y reinicia los procesos bloqueados. |
Comprueba automáticamente si las réplicas están listas. |
El despliegue que respalda un servicio define una prueba de disponibilidad, que identifica cuándo está lista una aplicación para prestar servicio después de iniciarse. Una sonda de preparación elimina la necesidad de realizar comprobaciones manuales o esperas programadas durante las actualizaciones continuas y las actualizaciones de grupos de nodos. |
La arquitectura de referencia está diseñada para aplicaciones con requisitos de alta disponibilidad zonales y regionales. Garantizar la alta disponibilidad conlleva algunos costes (por ejemplo, costes de repuesto de reserva o costes de replicación entre regiones). En la sección Alternativas se describen algunas formas de mitigar estos costes.
Cuotas, límites de rendimiento y límites de escalado de la plataforma
Puedes controlar las cuotas, el rendimiento y el escalado de los recursos en la plataforma para desarrolladores. En la siguiente lista se describen algunos elementos que debes tener en cuenta:
- La infraestructura base requiere varios proyectos y cada inquilino adicional requiere cuatro proyectos. Es posible que tengas que solicitar cuota adicional para el proyecto antes de implementar y de añadir más inquilinos.
- Hay un límite de 100 recursos MultiClusterGateway por proyecto. Cada servicio de Kubernetes orientado a Internet en la plataforma para desarrolladores requiere un MultiClusterGateway.
- Cloud Logging tiene un límite de 100 segmentos por proyecto. El registro por inquilino en el plano técnico se basa en un contenedor por inquilino.
- Para crear más de 20 tenants, puedes solicitar un aumento de la cuota del proyecto para los recursos Scope y Scope Namespace. Para ver instrucciones sobre cómo consultar las cuotas, consulta el artículo Ver y gestionar cuotas. Usa un filtro para encontrar los tipos de cuota
gkehub.googleapis.com/global-per-project-scopesygkehub.googleapis.com/global-per-project-scope-namespaces.
Siguientes pasos
- Consulta información sobre la arquitectura de servicios (el siguiente documento de esta serie).