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




Aquí entra LimitRange sirve para limitar los recursos que un deployment puede consumir, la ventaja es que se habilita a nivel de namespace, ventaja: si los desarrolladores olvidan el tag de resources.requests y resources.limits no vamos a tener problemas en el futuro.

Ya viene habilitado en kubernetes desde la versión 1.10.
Podemos limitar recursos como: memoria, CPU, volúmenes, ratio, etc.

**Nota:** tener en cuenta que si ya hay pods ejecutando y aplicamos limitRange, los pods que estén ejecutando no se limitan. Las restricción solo ocurre en la etapa de admisión.

### Configuración


Primero verificamos que no haya ningún limit en nuestro namespace:

```bash
kubectl describe ns limit-range
```

Para aplicar limitRange al namespace, hacemos los siguiente:

**limit-range-mem-cpu.yaml**

```yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: limits
  namespace: TUNAMESPACE
spec:
  limits:
    - default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 250m
        memory: 256Mi
      type: Container
```

y si ejecutamos un:

```bash
kubectl describe ns limit-range
```

vemos ahora que:

Ahora trata de desplegar este Pod:

**pod-limit-range-mem-cpu.yaml**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-limit-example
  namespace: TUNAMESPACE
spec:
  containers:
    - name: default-mem-demo-2-ctr
      image: nginx
      resources:
        requests:
          memory: "1Gi"
```

Como pudiste ver te muestra un bonito mensaje error y no te deja desplegar el Pod.

Incluso en nuestro limit-range-mem-cpu.yaml podemos especificar valores min, max.

**limit-range-min-max.yaml**

```yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: testLimit
  namespace: TUNAMESPACE
spec:
  limits:
    - default:
        cpu: 200mi
        memory: 500mi
      defaultRequest:
        cpu: 100mi
        memory: 250mi
      min:
        cpu: 80mi
        memory: 250mi
      max:
        cpu: 700mi
        memory: 700mi
      type: Container
```

Ejemplo de limit range ratio, Pod, Container, PersistentVolumeClaim:

```yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range-example
  namespace: TUNAMESPACE
spec:
  limits:
    - type: Pod
      max:
        cpu: "2"
        memory: "4Gi"
      min:
        cpu: "200m"
        memory: "256Mi"
      maxLimitRequestRatio:
        cpu: "4"
        memory: "8"
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "250m"
        memory: "256Mi"
      max:
        cpu: "1"
        memory: "1Gi"
      min:
        cpu: "100m"
        memory: "128Mi"
      maxLimitRequestRatio:
        cpu: "2"
        memory: "4"
    - type: PersistentVolumeClaim
      max:
        storage: "10Gi"
      min:
        storage: "1Gi"
      default:
        storage: "5Gi"
      defaultRequest:
        storage: "2Gi"
      maxLimitRequestRatio:
        storage: "2"
```

## Conclusión

Aplicando Limit Range en los namespace en kubernetes es una buena práctica para limitar los recursos y la estabilidad de nuestro cluster. Con lo que nos servirá en ahorro de dinero ya sea por caída del servicio o por consumo sin control de recursos.

Ya te tocará junto con tu equipo determinar los valores óptimos haciendo pruebas de tu aplicación en tu cluster y despreocuparte por que el equipo de desarrollo vayan a consumir todos los recursos de tu cluster, no es su culpa es nuestra responsabilidad.