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.

Un regalo para ti: DevOps, Aplicación para hacer tu prueba técnica

Hola querido lector, he escrito una aplicación en FastAPI, cuya finalidad es que realices las tareas que dice en el documento README.md, así podrás practicar para tus pruebas técnicas de DevOps. 

Puedes clonar el repositorio que se encuentra [aquí](https://github.com/ahioros/Bookstore-demo)

Te muestro algunas de las tareas de la prueba técnica:

En el área de los comentarios me puedes poner la URL con el informe si quieres que lo revise y te de feedback.

Kubernetes Horizontal Pod Autoscaling

Hoy vamos a hablar sobre Horizontal Pod Autoscaling (HPA para los amigos).

## ¿Qué es HPA?

Es una funcionalidad que ajusta automáticamente el número de pods en un deployment, replicaset o statefulset de "forma automática", según el uso de métricas personalizadas.

Con lo que nos lleva a nuestra siguiente pregunta:

## ¿Qué es una métrica personalizada?

Se basan en cualquier métrica que un objeto de Kubernetes informe en un cluster, como la cantidad de solicitudes de un cliente por segundo, la escritura de E/S por segundo, el uso de CPU o memoria, entre otros.

## ¿Por qué es importante HPA?

Porque es una manera de ahorrar ~~recursos~~ dinero, billete, cash, marmaja, etc. haciendo que la cantidad de pods crezca cuando se cumpla una política de uso en las métricas y disminuya la cantidad de pods cuando esté bajo del umbral.
Imagina que tu aplicación creará pods cuando sea necesario y los eliminará cuando no sean necesarios.

Helm creando tu repositorio

Antes de enseñarte a cómo hacer tu propio repositorio, primero te voy a enseñar cómo administrar los repositorios.

Buscar en el repositorio de Helm:

```bash
helm search hub grafana
```

Buscar en los repositorios ya instalados:

```bash
helm searh repo grafana
```

Para ver los Values de un paquete:

```bash
helm show values grafana
```

Supongamos que hiciste tu propio archivo de values y lo quieres aplicar en lugar del que trae por el paquete:

```bash
helm install -f miarchivo.yaml aplicación paquete
```

## Crear repositorio con GitHub

    1. Creas un nuevo repositorio público en GitHub.
    2. Ahora que estas en el repositorio nuevo que creaste, vas a settings -> Pages (en la barra de la izquierda).

    3. En Branch seleccionas la branch que quieres usar, en este ejemplo usaré main y por último seleccionas el directorio que por default es /(root).
    4. Por  último le das click en Save. Con esto has creado un repositorio.

La URL para acceder a tu repositorio es:

https://tuuser.github.io/tu-repositorio/

Por ejemplo:
https://ahioros.github.io/nginx-charts/