Terraform Runbook EKS

Guía completa para la implementación y gestión de clústeres EKS en AWS

Estado Inicial y Mejoras

Nos complace anunciar el lanzamiento de nuestro nuevo artefacto v1.0.0 para el despliegue de clústeres EKS, versión 1.31. Este artefacto ha sido diseñado para facilitar y estandarizar la creación y gestión de clústeres dentro de nuestra infraestructura.

Arquitectura

Arquitectura del Clúster

La IaC de blueprints ha sido mejorada para operar en un esquema de escalamiento automático de nodos/contenedores sobre un clúster EKS 1.31. Las aplicaciones se ejecutarán completamente en la nube sobre las cuentas de ambiente bajo y producción, con escalado automático tanto a nivel de nodo como de servicio.

Diagrama To-Be

A continuación la nueva arquitectura de despliegue del clúster (el código fuente del diagrama está adjunto a continuación)

Aspectos Relevantes

Redes

La red principal se extiende a una red secundaria que permite habilitar el Custom Networking dentro de los clústeres de EKS. Esto facilita la separación entre la red de los nodos y la de los contenedores.

Componentes Principales

• Control Plane gestionado por AWS
• Nodos workers con auto-scaling mediante Karpenter
• Redes VPC separadas para nodos y contenedores
• Load Balancers para exposición de servicios
• VPC Endpoints para servicios AWS

Repositorios Relacionados

Componente IaC

Rama test

Rama prod

CCT_Plataformas-EKS-v5

test

master

cct-eks-blueprint

test

master

Pre-Requisitos

Redes

• Solicitar una subred dedicada para los pods a CCT Comunicaciones (preferiblemente /18 no ruteada)
• VPC Endpoints necesarios (listado completo)
• Cloud routing desde la cuenta de despliegue a la cuenta de Seguridad Informática Test

Repositorio

• Solicitar creación de repositorio en GitLab
• Configurar rama “master” como protegida
• Establecer rama “test” como predeterminada
• Clonar repositorio de IaC

Permisos

Solicitar a través de AGP:

• Creación del rol “cct-plataforma-eks-terraform-role”
• Asociación de políticas necesarias
• Asociación del rol con Vault

Guía de Despliegue

Proceso de Despliegue

El despliegue debe realizarse a través del repositorio específicamente creado para esta tarea. El proceso completo toma aproximadamente 20 minutos.

Orden de despliegue:

1. Despliegue inicial hacia test
2. Merge request desde test a la rama protegida (prod)

Desactivación de Destroy

La opción de destruir el clúster debe ser desactivada una vez creado el clúster.

Pasos para desactivar:

1. Ir a Settings -> CI/CD -> Variables
2. Crear la variable DISABLE_DESTROY con valor “true”
3. Marcar como protegida

Características Configurables

Características Opcionales (Desactivables)

• cert_manager
• aws_efs_csi_driver
• velero backup
• External DNS
• AWS Load Balancer Controller
• Ingress NGINX Controller

Características Obligatorias (No Desactivables)

• Karpenter
• Container Insights
• aws_cloudwatch_metrics
• metrics_server
• secrets_store_csi_driver_provider_aws
• secrets_store_csi_driver

Tiempo de Despliegue

Este tiempo comprende las diferentes etapas involucradas, incluyendo la planificación de los pasos necesarios (plan) y la aplicación final de los cambios (apply).

Configuración del Clúster

Esta configuración ofrece la posibilidad de personalizar parámetros clave, incluyendo: el nombre del clúster, que debe mantenerse breve para facilitar la concatenación con otros prefijos; la versión del clúster EKS; el tipo de AMI; y el número y tamaño de los nodos (no modificar). Tal grado de flexibilidad asegura que la infraestructura pueda ser ajustada a las demandas particulares del proyecto, garantizando así un rendimiento superior y una administración de recursos altamente eficaz.

Modificación Manual

No olvide que el apply de los cambios debe ejecutarse mediante un step manual.

Dirigirse al archivo variables.tf y modificar el ami default

Configuración de Políticas

Es imperativo ajustar las políticas de seguridad para que correspondan con la cuenta AWS donde se implementará el nuevo clúster. Los archivos de configuración «vars-master.tfvars» y «vars-test.tfvars» deben ser adecuados según la región y el ambiente, basándose en los archivos .tfvar de producción o test.

Configuración de Variables

El valor asignado a la variable vault_role se deriva directamente del ID del proyecto asociado al repositorio en cuestión

Configuración de Redes

Adecuar los IDs de las azs segun corresponda, VPC y subredes según la cta de despliegue. Siendo el primer párrafo private_subnet_ids la red destinada a los nodos y el segundo container_subnet_ids destinado a a los contenedores. Es crucial que esta distinción se mantenga clara para evitar conflictos de red y garantizar un despliegue eficiente y seguro.

Configuración de Accesos

La configuración de ‘access_entries’ permite asignar permisos al clúster al rol de ‘IaaSAdmin’ correspondiente a cada cuenta. Esta opción asegura que los administradores de infraestructura como servicio (IaaS) tengan el acceso necesario para gestionar los recursos del clúster de manera eficiente y segura.

Actualización de Módulos

La versión del módulo solo debe actualizarse si se notifican mejoras o actualizaciones significativas. El archivo correspondiente, main.tf, que se encuentra dentro del artefacto especificado.

Verificación de Permisos

Garantizar un proceso de despliegue fluido y sin contratiempos. Además, es importante verificar que los permisos y las políticas de seguridad estén configurados correctamente para evitar cualquier problema de acceso durante el despliegue.

Configuración de Variables CI/CD

Ir a Settings => CI/CD => Variables, crear la variable como se muestra en el ejemplo

Versión y Actualizaciones

Actualización de Versiones EKS

Este proceso describe los pasos necesarios para actualizar la versión de un clúster EKS. Es importante revisar las notas de actualización de AWS anualmente para mantener estos procedimientos actualizados.

Consideraciones Importantes

• Realizar backup completo del clúster antes de iniciar
• Programar la actualización en horario de bajo tráfico
• Verificar compatibilidad de todas las aplicaciones con la nueva versión
• Tener un plan de rollback preparado

Proceso de Actualización

1. Preparación

• Verificar la versión actual del clúster
• Identificar la versión objetivo de actualización
• Revisar las notas de cambios entre versiones
• Validar compatibilidad de add-ons

2. Actualización del Control Plane

• Actualizar la versión en el archivo de configuración
• Aplicar cambios mediante el pipeline de IaC
• Monitorear el proceso de actualización
• Verificar la salud del control plane

3. Actualización de Nodos

• Actualizar la configuración de los node groups
• Realizar rolling update de los nodos
• Verificar la correcta operación de las aplicaciones
• Validar métricas y logs del clúster

Documentación Adicional

Para información más detallada sobre el proceso de actualización, consulte:

Documentación oficial de AWS EKS

Pipeline de Infraestructura

Nomenclatura y Tags

Nomenclatura y Tags

Es esencial seguir las directrices de nomenclatura y etiquetado para garantizar el cumplimiento normativo y una gestión eficiente de los recursos.

Directrices de Etiquetado

Las directrices completas están disponibles en:

Política de Etiquetado CCT

Consideraciones en Nomenclatura

Los recursos de infraestructura son administrados por un repositorio de infraestructura como código (IaC), donde la definición de etiquetas se realiza para cada componente.

Norma General:

Los recursos de infraestructura se pueden identificar mediante el prefijo ‘cct-plataforma-*’.

Manejo de Variables

Variables Constantes

Variables/objetos que no cambian por ambiente:

• Definidas en objeto locals dentro de main.tf
• Acceso mediante referencia local.

Variables por Ambiente

Variables/objetos que cambian por ambiente:

• vars-test.tfvars (ambiente de prueba)
• vars-prod.tfvars (ambiente de producción)

Características Opcionales

Kube-downscaler

Configuración por defecto

annotations: downscaler/uptime: Mon-Sun 12:20-12:30 America/Argentina/Buenos_Aires downscaler/downtime: Mon-Sun 12:05-12:15 America/Argentina/Buenos_Aires

Exclusiones

Para excluir un deployment del escalado automático, agregar la siguiente anotación:

annotations: downscaler/exclude: “true”

Monitoreo

El estado de los escalados puede monitorearse a través de los logs del pod kube-downscaler en el namespace kube-system.

Configuración de Escalamiento

Esto esta definido en el archivo main.tf que invoca al modulo

Ahí están definidas los tipos de instancias con que escalara karpenter y el limite de escalamiento a nivel de CPU/RAM

ArgoCD

Configuración General

Versión actual: v2.10.0+2175939

Requisitos: AWS Load Balancer Controller (se activa automáticamente)

Configuración de Ingress

Se requiere configurar:

• Ingress vinculado a Application Load Balancer (ALB)
• Registro DNS tipo C asociado al endpoint del ALB
• Certificado SSL/TLS para el dominio (recomendado)

Ejemplo de Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: argocd
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '\[{"HTTPS":443}\]'
spec:
  rules:
    - host: argocd.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port:
                  number: 80

Enlaces útiles

Documentación oficial de ArgoCD AWS Load Balancer Controller

OpenCost

Descripción General

OpenCost es una solución de código abierto para el monitoreo y análisis de costos en tiempo real para clústeres Kubernetes. Proporciona visibilidad detallada de los gastos por namespace, deployment y pod.

Características Principales

• Monitoreo de costos en tiempo real
• Desglose por namespace y aplicación
• Análisis histórico de costos
• Integración con métricas de Kubernetes

Configuración Recomendada

apiVersion: v1
kind: Namespace
metadata:
  name: opencost
---
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: opencost
  namespace: opencost
spec:
  repo: https://opencost.github.io/opencost-helm-chart
  chart: opencost
  version: 1.12.0
  targetNamespace: opencost

Mejores Prácticas

• Utilizar un namespace dedicado para OpenCost
• Configurar etiquetas consistentes para mejor seguimiento
• Revisar regularmente los informes de costos

Documentación oficial de OpenCost

Monitoreo y Métricas

El clúster viene configurado con herramientas de monitoreo esenciales para garantizar su correcto funcionamiento y rendimiento.

Revisando métricas de consumo

– Vaya hasta la consola de Cloudwatch y en el menú lateral de la izquierda seleccione “Container insights” como se muestra en la imagen.

Monitoreo de Logs

Existen 2 maneras para el monitoreo de logs de servicio. Puede hacerlo directamente desde la consola de servicio en EKS o mediante Cloudwatch logs.

Amazon CloudWatch

• Métricas de utilización de recursos
• Logs de aplicaciones y sistema
• Alertas configurables

Prometheus y Grafana

• Recolección de métricas en tiempo real
• Dashboards personalizables
• Visualización de métricas del clúster