Pipeline CD en Jenkins para terraform AWS EKS

En el [post anterior](https://www.ahioros.info/2024/12/creacion-de-un-cluster-aws-eks-con.html) hicimos un cluster AWS EKS con terraform. Como lo que nos gusta aquí es el tema de automatización, vamos a crear el pipeline de CD con Jenkins, les motraré 2 maneras de hacerlo, en este primer post vamos a hacerlo usando Secrets de Jenkins.

## Explicación del Pipeline

El Pipeline -> repositorio github (puede ser cualquier repositorio de git) -> Terraform (init, plan, apply/destroy) -> kubectl test

## Requisitos

Para Jenkins estoy usando el contenedor de Jenkins.
Los Plugins que tengo para este ejemplo son:

    * Pipeline: GitHub Groovy Libraries
    * Pipeline: Stage view
    * Terraform Plugin (opcional)

**Nota:** En mi caso yo tengo los binarios de terraform y kubectl en el directorio jenkins_home/terraform-bin y jenkins_home/kubectl-bin/.

Aquí abajo te dejo el video para que veas la configuración en caso que tengas dudas:

AWS Creación de un cluster EKS con terraform

## Introducción

Ya hace un tiempo enseñé [cómo instalar localstack para que puedas probar terraform](https://www.ahioros.info/2024/05/how-to-install-localstack-with-docker.html). Bueno ahora voy a enseñarte una de las maneras de como crear un cluster de kubernetes (EKS) en AWS.
 
¿Cuántas maneras de crear un cluster de kubernetes (EKS) en AWS hay?

1. Con terraform escribiendo desde 0.
2. Con terraform haciendo uso del module.
3. Con cloudformation.
4. Crear un cluster de kubernetes (EKS) en AWS con eksctl (esta al final es un wrapper y hace uso de cloudformation).

Nosotros vamos a realizar la primera configuración.


Puedes ver el video aquí:

No te voy a decir todas las ventajas que tiene hacerlo con terraform (que para eso ya debes de saberlas) solo diré que no me gusta tanto hacerlos con cloudformation por que "tarda" bastante tiempo.

**Nota:** más adelante vamos a hacer el pipeline CI/CD para automatizar el deploy e ir agregándo más características, así como ir poniéndo "presentable" el proyecto.

Hablemos de: Seguridad en Kubernetes

Vamos a dividir en antes del despliegue y en Kubernetes.

## Antes del Despliegue

1. Escaneo de las imágenes de contenedores

  - Durante CI.
  - Escaneo constante del registry de imagenes.

	Herramientas:

  - snyk.
  - sysdig.
  - Sonarqube.
  - Trivy.

2. Que el servicio de la imgen lo ejecute un usuario de servicio (non-root)

	**Nota:** Esto lo podemos sobreescribir en kubernetes usando **spec.securityContext.runAsUser: 1000** o **spec.allowPrivilegeEscalation: false**

## En Kubernetes

1. Manejo usuarios y permisos

	Usa RBAC, ClusterRole, ServiceAccount y siempre usa la regla de menor privilegio.

2. Políticas de red

	Aplica NetworkPolicy para limitar la comunicación entre pods, no quieres que un pod de front se comunique con un pod de database, se debe comunicar con el backend solamente, por mencionar un ejemplo.
  **Nota:** Usa la regla del mínimo acceso permitido.

	Herramientas:

  - calico
  - weave Net

	También puedes usar herramientas a nivel de aplicación, usando un service mesh ya hemos hablado de dos, [Linkerd](https://www.ahioros.info/2024/10/service-mesh-linkerd.html) e [Istio](https://www.ahioros.info/2024/10/service-mesh-istio.html).

	Herramientas:

  - Istio
  - Linkerd

3. Cifrado de tráfico, mTLS entre Servicios

	Esto se resuelve usando un service mesh, solo tienes que habilitarlo.

4. Seguridad y cifrado de Secrets

	Habilita el cifrado usando el recurso EncryptionConfiguration. Pero todavía necesitamos algo para manejar las llaves cifradas, aquí nos apoyamos de herramientas de terceros como AWS KMS, Google KMS, Vault de HashiCorp,etc. o incluso te puede funcionar algo como pass si estás on-premise.

5. Seguridad en etcd

	Si estas administrando etcd ponlo detrás de un firewall, cifra toda la informacion en etcd.

6. Backup y Restore

	En este caso me refiero a la data de tu(s) aplicacion(es) que están corriendo en kubernetes.

  - Realiza backups de tus aplicaciones regularmente.
  - Guarda los backups en un lugar seguro.
  - Hagan pruebas de sus backups para ver que estén funcionando correctamente en un ambiente controlado, incluso pueden automatizar estos tests para que se ejecuten cada cierto tiempo.

7. Define y Aplica Políticas de seguridad

	Por ejemplo:

  - No permitas ejecutar contenedores como root.
  - Cada pod debe tener su política de red.
  - Los backups se realizan cada día a X hora.

	Algunas herramientas que te pueden ayudar son:

  - Open Policy Agent.
  - Kyverno.

8. Disaster Recovery

  Define estrategias y mecanismos para una recuperación ante un desastre y sobre todo automatiza.
  Define también hacer pruebas para que todo el equipo sepa qué hacer en caso de uno y poder ajustar la estrategia de recuperación, entre mayor conocimiento tengan menor tiempo les tomará en ejecutar la recuperación y menor tiempo afectaran la experiencia del usuario.

Kubernetes: Controla tus recursos

Ya todos sabemos que la cultura DevOps parte de cederle responsabilidades al área de desarrollo para liberar sus servicios más ágil, esto no quiere decir que debamos darles las llaves del cielo y que hagan lo que quieran, por lo que es responsabilidad de nosotros tomar precauciones para que no tumben los servicios y tengamos que correr como pollos sin cabeza a solucionar.

Como ya sabemos tener el servicio indisponible se traduce en pérdida de dinero, pero te cuento que tener el servicio consumiendo recursos sin control también se traduce en pérdida de dinero.

Ya en posts anteriores cuando hablé de [HPA](https://www.ahioros.info/2024/09/kubernetes-horizontal-pod-autoscaling.html) mencioné unas buenas prácticas para aplicar a nuestros deployments, para ser más específicos resources.requests y resources.limits.

Puedes seguir el video aquí:

 

## LimitRanges

Hablemos de: Pod Disruption Budgets

El escenario "normal" cuando tienes que hacer un mantenimiento en tu cluster de k8s, es que marcas un nodo como cordon esto hace que no acepte más pods y de ahí empiezas a "drenar" los pods el nodo. Lo que hará k8s es que "sacará" los pods del nodo y después empezará a crearlos en el nodo activo. Si nuestra aplicación tiene la mayoría de los pods en el nodo que vamos a hacer el mantenimiento, nos trae inconvenientes como:

- Indisponibilidad de nuestra aplicación.
- Perder dinero.

Aquí te dejo el video para que veas el funcionamiento:

El Pod Disruption Budget (para los compas "PDB" de ahora en adelante) sirve para drenar un nodo, con la diferencia que va a recrear primero en el (los) otro(s) nodo(s) los pods y cuando estén listos (RUNNING), va a matar los pods del nodo que quieres hacer el mantenimiento. Suena bien ¿no? Así, evitamos la indisponibilidad de nuestra aplicación.

Service Mesh Linkerd

En el post anterior se habló de lo que es un Service Mesh e instalamos Istio.

Hoy toca hablar sobre Linkerd, es un Service Mesh que no cuenta con tantas cosas como Istio, ¿esto es malo?, no es malo por que lo que hace, lo hace bien.

En comparación con Istio no es necesario crear los Istio ingress o gateways, solo se encarga del Service Mesh. Linkerd tiene mejor performance que Istio (según la documentación de Linkerd claro está). Como Linkerd es más pequeño puedes tener un ahorro en el costo de tu cluster de Kubernetes en tu proveedor de la nube.

Al igual que Istio cuenta con mTLS entre los microservicios cuando se inyecta el sidecar (proxy) de Linkerd, esta de más decir que esto te agregará un poco de latencia en tu aplicación.

Acá esta el video para que vayas conmigo haciendo el tutorial:

Service Mesh Istio

Imagina que tienes una aplicación la cual está construida por muchos microservicios, ¿Cómo la vas a monitorear/supervisar/optimizar el rendimiento y la comunicación de la aplicación entre todos estos microservicios?

Aquí es dónde te ayudan tener un service mesh:

- Administrar conexiones entre servicios
- Supervisión de tráfico
- Registro de tráfico
- Rastreo de tráfico
- Control de tráfico
- Escalabilidad y alta disponibilidad

En resumen un **service mesh** es una software dedicado a manejar la comunicación entre servicios.

Aquí te dejo el video para que lo sigas conmigo:

MetalLB tu Load Balancer Bare-Metal

Me han preguntando lo siguiente: ¿Es posible tener un Load Balancer local?

Respuesta: Sí, con MetalLB. FIN...

Como es habitual en este blog comenzamos explicando que es un Load Balancer.

## ¿Que es un Load Balancer?

Un Load Balancer sirve para exponer tu aplicación hacia la red externa, provee un punto de entrada para tu aplicación, y como su nombre lo dice balanceará las peticiones/carga entre los pods de la aplicación.

Acá puedes ver el video de lo que vamos hacer en el post:

Gráfica de un Load Balancer:

**Nota:** Los proveedores de nube te cobran por el tiempo y/o uso (transferencia en GB) de los Load Balancer, así que te recomiendo leer cómo es el costo dependiendo del tipo de Load Balancer que uses en tu proveedor de la nube.