template-gke-resources

Propósito y Alcance

Este proyecto define las plantillas de configuración de recursos necesarios para desplegar aplicaciones en Google Kubernetes Engine (GKE) dentro del ecosistema LATAM. Su propósito es estandarizar y facilitar la creación de la infraestructura base en GKE, incluyendo la configuración de red, seguridad y variables de entorno.

El alcance incluye la definición de:

• Configuraciones de Backend y Frontend para servicios.
• Mapas de Configuración (ConfigMaps) para la inyección de variables.
• Recursos de Ingress para la exposición de servicios y enrutamiento de tráfico.
• Políticas de seguridad básicas a través de Cloud Armor.
• Uso de certificados TLS y redirección HTTPS.

Este template está diseñado para ser utilizado con el pipeline de despliegue gke-krane-deploy.

Arquitectura

El proyecto se basa en plantillas de manifiestos de Kubernetes en formato YAML, utilizando ERB (Embedded Ruby) para permitir la personalización de valores en tiempo de despliegue. Estos manifiestos describen los recursos que se crearán o actualizarán en un clúster de GKE.

Los principales componentes definidos son:

• BackendConfig: Define configuraciones específicas para los backends de los servicios, como timeouts y políticas de seguridad (e.g., Cloud Armor).
• FrontendConfig: Define configuraciones para el frontend, como la redirección automática a HTTPS.
• ConfigMap: Almacena datos de configuración no sensibles en pares clave-valor, que pueden ser consumidos por los pods.
• Ingress: Gestiona el acceso externo a los servicios dentro del clúster, típicamente HTTP/HTTPS, configurando balanceo de carga, terminación SSL y enrutamiento basado en host y path.

El despliegue de estos recursos se realiza a través de un pipeline de Jenkins que utiliza Krane.

Tecnologías y Dependencias

• Plataforma Orquestación: Google Kubernetes Engine (GKE)
• Definición de Recursos: Kubernetes YAML
• Motor de Plantillas: ERB (Embedded Ruby)
• Integración Continua/Despliegue Continuo (CI/CD): Jenkins (utilizando el pipeline gke-krane-deploy)
• Control de Versiones: Git (GitLab)
• Seguridad Perimetral (opcional): Google Cloud Armor (referenciado en BackendConfig)

Configuración Local

Prerrequisitos

• Git instalado.
• Acceso al repositorio del proyecto.

Pasos para Revisar las Plantillas

1. Clonar el repositorio: Sigue los siguientes pasos

2. Explorar las plantillas: Los archivos de configuración principales se encuentran en el directorio deploy/gke/. El archivo clave es:

   • deployment.yaml.erb: Contiene las plantillas para BackendConfig, FrontendConfig, ConfigMap, e Ingress.

   Las variables encerradas en <%= ... %> (e.g., <%= owner_name %>, <%= environment %>) son reemplazadas por el pipeline de despliegue con valores específicos del entorno y la aplicación.

Despliegue

El despliegue de estos recursos de GKE se realiza a través del pipeline de Jenkins especificado en el Jenkinsfile de la aplicación que consume este template.

Jenkinsfile

El Jenkinsfile de la aplicación que utiliza este template debe invocar el pipeline global de LATAM para despliegues en GKE con Krane:

pipelineLatam("gke-krane-deploy")

Este pipeline se encargará de procesar las plantillas .erb en deploy/gke/deployment.yaml.erb, sustituyendo las variables y aplicando los manifiestos YAML resultantes al clúster de GKE correspondiente.

Variables de Despliegue

Las plantillas utilizan variables que son inyectadas durante el proceso de despliegue. Algunas de las variables clave son:

• owner_name: Nombre del propietario o aplicación.
• environment: Entorno de despliegue (e.g., dev, qa, prod).
• git_commit: Hash del commit de Git.
• build_id: Identificador de la compilación.
• dns_record: Registro DNS para el Ingress.
• static_ip_name: Nombre del recurso de IP estática global.
• is_prod_deploy: Booleano que indica si es un despliegue a producción.

Endpoints de la API

Este proyecto no define APIs directamente, sino la infraestructura (Ingress) que expone los endpoints de las aplicaciones desplegadas. El recurso Ingress configurado en deploy/gke/deployment.yaml.erb define cómo se enruta el tráfico externo a los servicios internos.

Configuración de Rutas del Ingress

El Ingress define rutas basadas en path para diferentes servicios:

spec:
  tls:
    - secretName: <%= owner_name %>-<%= environment %>-certificate # Certificado TLS
  rules:
    - host: <%= dns_record %> # DNS principal
      http:
        paths:
          - path: / # Ruta para el frontend principal
            pathType: Prefix
            backend:
              service:
                name: <%= owner_name %>-template-angular-fe-service
                port:
                  number: 80
          - path: /api/bl/ # Ruta para el servicio de Business Logic
            pathType: Prefix
            backend:
              service:
                name: <%= owner_name %>-template-spring-bl-service
                port:
                  number: 80
          - path: /authorization-service/ # Ruta para el servicio de autorización
            pathType: Prefix
            backend:
              service:
                name: <%= owner_name %>-auth-service-bl-service
                port:
                  number: 80
          - path: /web/ # Ruta para el servicio web (e.g., Spring MVC tradicional)
            pathType: Prefix
            backend:
              service:
                name: <%= owner_name %>-template-spring-web-service
                port:
                  number: 80

• El tráfico es dirigido al servicio correspondiente (backend.service.name) según el path de la solicitud.
• Se utiliza un nombre de secreto (secretName) para la configuración TLS, asegurando comunicación HTTPS.
• Se asocia una IP estática global (kubernetes.io/ingress.global-static-ip-name).

Componentes Específicos (Recursos de Kubernetes)

BackendConfig

• Propósito: Configurar parámetros avanzados para los servicios de backend, como timeouts y políticas de seguridad.
• Fragmento de Configuración (deploy/gke/deployment.yaml.erb):

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: "<%= owner_name %>-<%= environment %>-backendconfig"
    labels:
      app: "<%= owner_name %>"
      git_commit: "<%= git_commit %>"
      build_id: "<%= build_id %>"
  spec:
    timeoutSec: 120 # Timeout para las respuestas del backend
    securityPolicy:
      name: "cloudarmor-corp" # Política de Cloud Armor

• Uso: Se asocia a los servicios de Kubernetes mediante anotaciones en la definición del servicio (no incluido en este template, pero es el uso esperado).

FrontendConfig

• Propósito: Especificar configuraciones para el frontend del Ingress, principalmente la redirección de HTTP a HTTPS.
• Fragmento de Configuración (deploy/gke/deployment.yaml.erb):

  apiVersion: networking.gke.io/v1beta1
  kind: FrontendConfig
  metadata:
    name: "<%= owner_name %>-<%= environment %>-frontendconfig"
    labels:
      app: "<%= owner_name %>"
      git_commit: "<%= git_commit %>"
      build_id: "<%= build_id %>"
  spec:
    redirectToHttps:
      enabled: true
      responseCodeName: MOVED_PERMANENTLY_DEFAULT # Código de respuesta 301

• Uso: Se asocia al Ingress mediante la anotación networking.gke.io/v1beta1.FrontendConfig.

ConfigMap

• Propósito: Almacenar y gestionar variables de configuración que pueden ser consumidas por las aplicaciones.
• Fragmento de Configuración (deploy/gke/deployment.yaml.erb):

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: "<%= owner_name %>-<%= environment %>-configmap"
    labels:
      app: "<%= owner_name %>"
      git_commit: "<%= git_commit %>"
      build_id: "<%= build_id %>"
  data:
    ENVIRONMENT: "<%= environment %>"
    APPLICATION: "<%= owner_name %>"
    DNS_RECORD: "<%= dns_record %>"
    IS_PROD_DEPLOY: "<%= is_prod_deploy %>"

• Uso: Los pods pueden montar estos datos como variables de entorno o archivos.

Ingress

• Propósito: Gestionar el tráfico entrante, proporcionando balanceo de carga, terminación SSL y enrutamiento basado en nombres de host y paths.
• Fragmento de Configuración (deploy/gke/deployment.yaml.erb):

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: <%= owner_name %>-<%= environment %>-ingress
    labels:
      app: "<%= owner_name %>"
      git_commit: "<%= git_commit %>"
      build_id: "<%= build_id %>"
    annotations:
      kubernetes.io/ingress.global-static-ip-name: <%= static_ip_name %>
      networking.gke.io/v1beta1.FrontendConfig: <%= owner_name %>-<%= environment %>-frontendconfig
  spec:
    tls:
      - secretName: <%= owner_name %>-<%= environment %>-certificate
    rules:
    # ... (ver sección Endpoints de la API para detalle de reglas)

• Uso: Dirige el tráfico externo a los servicios correctos dentro del clúster, basándose en las reglas definidas.

Pruebas

Este proyecto, al ser un conjunto de plantillas de infraestructura, no contiene pruebas unitarias o de integración en el sentido tradicional del software. Las "pruebas" consisten en:

1. Validación de Sintaxis YAML/ERB: Asegurar que las plantillas son válidas antes del despliegue. Esto suele ser parte del proceso de linting o del propio Krane.
2. Despliegue Exitoso: Verificar que el pipeline de Jenkins aplica los manifiestos al clúster de GKE sin errores.
3. Verificación de Recursos en GKE: Confirmar que los recursos (BackendConfig, FrontendConfig, ConfigMap, Ingress) se han creado o actualizado correctamente en el clúster.
4. Pruebas de Conectividad y Enrutamiento: Una vez que las aplicaciones que usan estos recursos están desplegadas, probar el acceso a través del Ingress, la correcta aplicación de políticas de seguridad y la redirección HTTPS.

Las herramientas para estas verificaciones incluyen:

• kubectl para inspeccionar los recursos en el clúster GKE.
• Consola de Google Cloud Platform.
• Herramientas de prueba de endpoints (e.g., Postman, curl) para verificar el enrutamiento del Ingress.

Consideraciones de Seguridad

• HTTPS Obligatorio: El FrontendConfig está configurado para redirigir todo el tráfico HTTP a HTTPS.
• Certificados TLS: El Ingress utiliza un secreto de Kubernetes (secretName: <%= owner_name %>-<%= environment %>-certificate) para la terminación SSL/TLS. La gestión de este certificado (creación, renovación) es externa a este template pero crucial.
• Cloud Armor: El BackendConfig referencia una política de seguridad de Cloud Armor (cloudarmor-corp). Esto implica que el tráfico hacia los backends puede estar protegido por WAF y otras reglas de seguridad definidas en dicha política.
• IP Estática: El uso de una IP estática global (kubernetes.io/ingress.global-static-ip-name) facilita la configuración de listas blancas y registros DNS.
• ConfigMaps: Solo deben usarse para datos de configuración no sensibles. Los secretos deben gestionarse mediante Kubernetes Secrets.
• Permisos del Pipeline: El pipeline de Jenkins (gke-krane-deploy) debe tener los permisos adecuados en GCP para gestionar estos recursos en GKE.