Implementa el plano

Last reviewed 2024-04-19 UTC

En esta sección, se describe el proceso que puedes usar para implementar el plano, sus convenciones de nombres y las alternativas a las recomendaciones del plano.

Revisión general

Para implementar la arquitectura descrita en este documento, completa los pasos de esta sección.

Implementa el plano en una organización nueva

Para implementar el plano en una nueva organización de Google Cloud, completa lo siguiente:

  1. Crea tu infraestructura básica con el plano de base empresarial. Completa lo siguiente:

    1. Crea una estructura de organización, incluidas las carpetas para la separación de entornos.
    2. Configura los permisos de IAM básicos para otorgar acceso a los administradores de la plataforma para desarrolladores.
    3. Crea la red de VPC.
    4. Implementa la canalización de infraestructura básica.

    Si no usas el plano de bases empresariales, consulta Implementa el plano sin el plano de bases empresariales.

  2. El administrador de la plataforma para desarrolladores usa la canalización de infraestructura básica para crear la canalización de infraestructura multiusuario, la fábrica de aplicaciones y la canalización con alcance de flota.

  3. El administrador de la plataforma para desarrolladores usa la canalización de infraestructura multiusuario para implementar clústeres de GKE y la infraestructura compartida.

  4. Los operadores de aplicaciones usan la fábrica de aplicaciones para incorporar aplicaciones nuevas. Los operadores agregan una o más entradas al repositorio de fábrica de aplicaciones, lo que activa la creación de recursos específicos de aplicaciones.

  5. Los desarrolladores de aplicaciones usan la canalización de CI/CD de aplicaciones en su infraestructura específica de aplicaciones para implementar aplicaciones en la infraestructura multiusuario.

Implementa el plano sin el plano de bases empresariales

Si no implementas el plano de la aplicación empresarial en el plano de bases empresariales, completa los siguientes pasos:

  1. Crea los siguientes recursos:
    • Una jerarquía de organización con carpetas development, nonproduction y production
    • Una red de VPC compartida en cada carpeta
    • Un esquema de direcciones IP que tiene en cuenta los rangos de IP necesarios para tus clústeres de GKE
    • Un mecanismo de DNS para tus clústeres de GKE
    • Políticas de firewall que estén alineadas con tu postura de seguridad
    • Un mecanismo para acceder a las APIs de Google Cloud a través de direcciones IP privadas
    • Un mecanismo de conectividad con el entorno local
    • Un registro centralizado para la seguridad y la auditoría
    • Security Command Center para la supervisión de amenazas
    • Políticas organizativas que están alineadas con tu posición de seguridad
    • Una canalización que se pueda usar para implementar la fábrica de aplicaciones, la canalización de infraestructura multiusuario y la canalización con alcance de flota
  2. Después de implementar los recursos, continúa con el paso 2 en Implementa el plano en una organización nueva.

Incorpora el plano en tu implementación de GKE existente

Este plano requiere que primero implementes la plataforma para desarrolladores y, luego, implementes las aplicaciones en la plataforma para desarrolladores. En la siguiente tabla, se describe cómo puedes usar el plano si ya tienes aplicaciones alojadas en contenedores que se ejecutan en Google Cloud.

Uso existente Estrategia de migración

Ya tienes una canalización de CI/CD.

Puedes usar la flota del plano y la arquitectura del clúster del plano, incluso cuando se usan diferentes productos para la compilación y la implementación de aplicaciones. Como mínimo, te recomendamos que dupliques las imágenes en dos regiones.

Tienes una estructura de organización existente que no coincide con el plano de bases empresariales.

Se recomienda tener al menos dos entornos para implementaciones secuenciales más seguras. No es necesario implementar entornos en carpetas o VPC compartidas independientes. Sin embargo, no debes implementar cargas de trabajo que pertenezcan a entornos diferentes en el mismo clúster.

No usas IaC.

Si el proceso de implementación de aplicaciones actual no usa IaC, puedes evaluar tu preparación con el modelo de madurez de Terraform en Google Cloud. Importa los recursos existentes a un proyecto de Terraform diferente que esté organizado de manera similar a este plano, con la separación de las canalizaciones multiusuario y por usuario. Si deseas crear clústeres nuevos, puedes usar los módulos de Terraform para Google Cloud.

Los clústeres se distribuyen en varios proyectos dentro del mismo entorno.

Puedes agrupar clústeres de varios proyectos en una flota. Verifica que tus espacios de nombres tengan significados únicos dentro de la misma flota. Antes de agregar clústeres a una flota, pídeles a los equipos que muevan sus aplicaciones a un espacio de nombres con un nombre único (por ejemplo, no default).

Luego, puedes agrupar espacios de nombres en permisos.

Los clústeres se encuentran en una sola región.

No necesitas usar varias regiones en los entornos de producción y no producción para adoptar el plano.

Existen diferentes conjuntos de entornos.

Puedes modificar el plano para admitir más o menos de tres entornos.

La creación de clústeres se delega a los desarrolladores de aplicaciones o a los equipos de operadores de aplicaciones.

Para obtener la plataforma para desarrolladores más segura y coherente posible, puedes intentar traspasar la propiedad de los clústeres de los equipos de aplicaciones al equipo de plataforma para desarrolladores. Si no puedes, igual puedes adoptar muchas de las prácticas de planos. Por ejemplo, puedes agregar a una flota los clústeres que pertenecen a diferentes equipos de aplicaciones. Sin embargo, cuando combines clústeres con propiedad independiente, no uses Workload Identity ni Cloud Service Mesh, ya que no proporcionan suficiente control sobre quién puede confirmar qué identidades de carga de trabajo. En su lugar, usa una política de organización personalizada para evitar que los equipos habiliten estas funciones en clústeres de GKE.

Si los clústeres se agrupan en una flota, igual puedes auditar y aplicar políticas. Puedes usar una política de organización personalizada para exigir que se creen clústeres dentro de una flota que corresponda a la carpeta de entorno en la que se encuentra el proyecto del clúster. Puedes usar la configuración predeterminada de la flota para exigir que los clústeres nuevos usen el control de políticas.

Alternativas a las recomendaciones predeterminadas

En esta sección, se describen alternativas a las recomendaciones predeterminadas que se incluyen en esta guía.

Área de decisión Alternativas posibles

Todas las aplicaciones se ejecutan en el mismo conjunto de cinco clústeres.

El plano usa un conjunto de cinco clústeres (dos en producción, dos en no producción y uno en desarrollo). Puedes modificar el plano para crear conjuntos adicionales de cinco clústeres.

Asigna aplicaciones a conjuntos de cinco clústeres. No vincules los permisos de una aplicación ni los espacios de nombres de la flota de una aplicación a los clústeres de los otros conjuntos. Es recomendable segregar las aplicaciones en diferentes conjuntos de clústeres para completar actividades como las siguientes:

  • Agrupar algunas aplicaciones con inquietudes normativas especiales (por ejemplo, PCI-DSS)
  • Aislar aplicaciones que requieren un control especial durante las actualizaciones de clústeres (por ejemplo, aplicaciones con estado que usan volúmenes persistentes)
  • Aislar aplicaciones con perfiles de seguridad riesgosos (por ejemplo, procesar contenido proporcionado por el usuario en un lenguaje no seguro para la memoria)
  • Aislar las aplicaciones que requieren GPU, sensibilidad a los costos y sensibilidad al rendimiento
  • Si te acercas al límite de clústeres de GKE con respecto a la cantidad de nodos (15,000 nodos), puedes crear un conjunto de clústeres nuevo
  • Usa una VPC compartida diferente para las aplicaciones que necesitan ejecutarse dentro de un perímetro de Controles del servicio de VPC. Crea un conjunto de clústeres en el perímetro y un conjunto de clústeres fuera del perímetro

Evita crear conjuntos de clústeres nuevos para cada aplicación o usuario, ya que esta práctica puede generar una de las siguientes circunstancias:

  • Aplicaciones que no hacen un buen uso del tamaño mínimo del clúster (3 VMs x 2 regiones) incluso con los tipos de instancias más pequeños disponibles
  • Potencial perdido de reducción de costos gracias al empaquetado en contenedores de diferentes aplicaciones
  • Planificación de crecimiento de capacidad tediosa e incierta, ya que la planificación se aplica a cada aplicación de forma individual. Las predicciones de capacidad son más precisas cuando se realizan en conjunto para un conjunto amplio de aplicaciones
  • Demoras en la creación de clústeres nuevos para usuarios o aplicaciones nuevos, lo que disminuye la satisfacción de los usuarios con la plataforma. Por ejemplo, en algunas organizaciones, las asignaciones de direcciones IP necesarias pueden llevar tiempo y requerir aprobaciones adicionales
  • Alcanzar el límite de clústeres privados en una red de VPC

Los entornos de producción y de no producción tienen clústeres en dos regiones.

Para reducir la latencia para los usuarios finales en varias regiones, puedes implementar las cargas de trabajo de producción y de no producción en más de dos regiones (por ejemplo, tres regiones para producción, tres regiones para no producción y una región para desarrollo). Esta estrategia de implementación aumenta el costo y la sobrecarga de mantener recursos en regiones adicionales.

Si todas las aplicaciones tienen menores requisitos de disponibilidad, puedes implementar cargas de trabajo de producción y no producción en una sola región (un entorno de producción, un entorno de no producción y un entorno de desarrollo). Esta estrategia ayuda a reducir los costos, pero no protege el mismo nivel de disponibilidad que una arquitectura birregional o multirregional.

Si las aplicaciones tienen requisitos de disponibilidad diferentes, puedes crear conjuntos de clústeres diferentes para las distintas aplicaciones (por ejemplo, cluster-set-1 con dos entornos de producción, dos entornos de no producción y un entorno de desarrollo, además de cluster-set-2 con un entorno de producción, un entorno de no producción y un entorno de desarrollo).

La topología de concentrador y radio coincide con tus requisitos mejor que la VPC compartida.

Puedes implementar el plano en una configuración de concentrador y radio, en la que cada entorno (desarrollo, producción y no producción) se aloja en su propio radio. La topología de concentrador y radio puede aumentar la segregación de los entornos. Para obtener más información, consulta Topología de red de concentrador y radio.

Cada aplicación tiene un repositorio de Git separado.

Algunas organizaciones usan un solo repositorio de Git (un monorepo) para todo el código fuente en lugar de varios repositorios. Si usas un repositorio monolítico, puedes modificar el componente de fábrica de aplicaciones del plano para admitir tu repositorio. Completa lo siguiente:

  • En lugar de crear un repositorio nuevo para cada aplicación nueva, crea un subdirectorio en el repositorio existente.
  • En lugar de otorgar permisos de propietario sobre el repositorio nuevo al grupo de desarrolladores de aplicaciones, otorga permiso de escritura en el repositorio existente y haz que el grupo de desarrolladores de aplicaciones sea un revisor obligatorio para los cambios en el subdirectorio nuevo. Usa la función CODEOWNERS y la protección de ramas.

¿Qué sigue?