DEV Community: Guillermo Garcia

Pipeline CD en Jenkins para terraform AWS EKS segunda parte (plugin AWS Credentials)

Guillermo Garcia — Thu, 12 Dec 2024 21:43:00 +0000

En el post anterior te mostré como usar Jenkis como CD para desplegar tu infraestructura EKS con terraform en AWS. El "detalle" es que usamos el secret de Jenkins de texto cifrado.

Ahora lo que usaremos es el plugin de AWS Credentials, lo puedes instalar desde el administrador de plugins de Jenkins con un par de clicks.

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

Empezamos creando las credenciales, vamos a:

Dashboard -> Manage Jenkins -> Credentials -> System -> Global credentials, vas click en "Add Credentials" y en el formulario das click en kind y seleccionas AWS Credentials.

Ahora vamos al Pipeline puedes usar el anterior si quieres, ya que la configuración es la misma. Bajamos a la sección de Pipeline y el script es el siguiente:

def awsCredentials = [[$class: 'AmazonWebServicesCredentialsBinding', credentialsId: 'AWS_CREDS']]

pipeline {
    agent any

    options {
        timestamps()
        withCredentials(awsCredentials)
    }

    stages {
        stage('Checkout') {
            steps {
                git 'https://github.com/ahioros/terraform-aws-eks/'
            }
        }

        stage('Terraform init'){
            steps{
                sh '/var/jenkins_home/terraform-bin/terraform init -no-color'
            }
        }

        stage('Terraform plan') {
            steps{
                sh '/var/jenkins_home/terraform-bin/terraform plan -var="config_key=config.json" -no-color'
            }
        }

        stage('Terraform apply') {
            steps {
                sh '/var/jenkins_home/terraform-bin/terraform ${action} -auto-approve -var="config_key=config.json" -no-color'
            }
        }

        stage('kubectl test') {
            steps {
                script {
                    if (action.toString() == "apply") {
                        sh '/var/jenkins_home/kubectl-bin/kubectl --kubeconfig ./template/kubeconfig.yaml get all -A'
                    } else {
                        echo 'skipping kubectl test'
                    }
                }
            }
        }
    }
}

El código hace lo mismo y como puedes notar la diferencia es que se tuvo que definir una función y luego llamarla en options para que haga uso de las credenciales del llavero que creamos, de lo contrario en cada stage tendrías que hacer el llamado del llavero (repetir código a lo tonto).

Ahora puedes ejecutar el pipeline de la misma forma que lo hicimos en el post anterior.

Recuerda ejecutar el pipeline con destroy, no vayas a dejar corriendo el cluster si no es necesario.

Siguiente post haremos lo mismo pero ahora desde github actions.

Pipeline CD en Jenkins para terraform AWS EKS

Guillermo Garcia — Mon, 09 Dec 2024 21:14:00 +0000

En el post anterior 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:

Configuración de Credenciales en Jenkins

Primero configuramos las credenciales vamos a Manage Jenkins -> Credentials -> System -> Global credentials y damos click en Add Credentials.

Con la siguiente información:

Configuración de Pipeline CD

Damos click en Dashboard -> All -> New Item.

Le damos un nombre al nuevo item y seleccionamos Pipeline.

Ahora seleccionamos el checkbox GitHub project -> y ponemos la URL de nuestro repositorio.

También damos click en el checkbox This project is parameterized -> y le damos los siguiente valores.

Esto nos servirá para que desde el mismo pipeline podemos crear y destruir la infraestructura de AWS EKS, esto te puede servir para los equipos no productivos por ejemplo.

Y en la sección de Pipeline escribimos el siguiente código:

pipeline {
    agent any

        environment {
        AWS_ACCESS_KEY_ID = credentials('SECRET-ACCESS-KEY-ID')
        AWS_SECRET_ACCESS_KEY = credentials('SECRET-ACCESS-KEY')

        }

    stages {
        stage('Checkout') {
            steps {
                git 'https://github.com/ahioros/terraform-aws-eks/'

            }

        }

        stage('Terraform init') {
            steps {
                   sh '/var/jenkins_home/terraform-bin/terraform init -no-color'

            }

        }
        stage('Terraform plan') {
            steps{
                sh '/var/jenkins_home/terraform-bin/terraform plan -var="config_key=config.json" -no-color'

            }

        }

        stage('Terraform apply') {
            steps {
                sh '/var/jenkins_home/terraform-bin/terraform ${action} -auto-approve -var="config_key=config.json" -no-color'

            }

        }

        stage('kubectl test') {
            steps {
                script {
                    if (action.toString() == "apply") {
                        sh '/var/jenkins_home/kubectl-bin/kubectl --kubeconfig ./template/kubeconfig.yaml get all -A'

                    } else {
                        echo 'skipping kubectl test'

                    }

                }

            }

        }

    }
}

Por último le das click en save.

Despliegue del cluster EKS

Listo para ejecutar el pipeline solo debes ir Dashboard -> AWS-Terraform (o el nombre que le hayas puesto al pipeline) -> en el menú izquierdo le das click en Build With Parameters

Seleccionamos apply (que debe estar por default) y damos click en Build.

Ahora te tocará esperar unos 10-12 minutos en lo que se crea la infraestructura.

Destrucción del cluster EKS

En la misma pantalla donde le diste click en el botón Build, en el combobox seleccionamos destroy y damos click en Build.

Listo en el siguiente post te mostraré otra forma para construir la infraestructura utilizando otros Plugins de Jenkins.

AWS Creación de un cluster EKS con terraform

Guillermo Garcia — Wed, 04 Dec 2024 17:05:00 +0000

Introducción

Ya hace un tiempo enseñé cómo instalar localstack para que puedas probar terraform. 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?

Con terraform escribiendo desde 0.
Con terraform haciendo uso del module.
Con cloudformation.
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.

Crear un cluster de kubernetes (EKS) en AWS con terraform

En este ejemplo voy a enseñar cómo usar terraform para crear un cluster de kubernetes (EKS) en AWS.

Advertencia: el cluster queda expuesto para poder acceder desde internet, esto no es seguro pero lo hago así por que destruyo el ambiente enseguida, lo correcto es crear una instancia que tenga acceso (jump box/bastión).

Pre-requisitos

Como este proyecto es "bastante código" lo he puesto a disposición en mi github, lo puedes descargar de aquí estará con el tag 1.0.

El diagrama es este:

Configuración

Abre y edita el archivo config.json y cambia los valores de la configuración según tu necesidad.

Despliegue

Realiza el deploy de tu cluster de kubernetes (EKS) con terraform.

terraform init
bash
terraform apply -var="config_key=config.json"

Tocará esperar alrededor de 7 minutos, y el cluster de kubernetes (EKS) estará listo para ser usado.

Test del cluster EKS

Podemos ejecutar el siguiente comando una vez haya terminado y aunque nos sirve, es engorroso estar usando el argumento kubeconfig (ya sé que puedes crear un alias) en el siguiente apartado te digo el tip para actualizar tu kubectl con tu nuevo cluster.

kubectl --kubeconfig ./template/kubeconfig.yaml get nodes

Configuración de kubectl

Actualizamos la configuración de kubectl:

aws eks update-kubeconfig --name eks-cluster --region us-east-1

Recuerda cambiar --name y --region por el nombre y la region de tu cluster de kubernetes (EKS).

Aunque automáticamente debe tomar el nuevo contexto puedes verificarlo con:

kubectl config get-context

Destrucción del cluster EKS

terraform destroy -var="config_key=config.json" -auto-approve

Para eliminar el contexto de tu kubernetes realiza:

kubectl config delete-context arn:aws:eks:laregion:algúnnúmero:cluster/eks-cluster

Nota: en futuros post haremos la configuración del github actions para automatizar el deploy.

Hablemos de: Seguridad en Kubernetes

Guillermo Garcia — Mon, 25 Nov 2024 16:37:00 +0000

Vamos a dividir en antes del despliegue y en Kubernetes.

Antes del Despliegue

Escaneo de las imágenes de contenedores

Durante CI.
Escaneo constante del registry de imagenes.

Herramientas:

snyk.
sysdig.
Sonarqube.
Trivy.

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

Manejo usuarios y permisos

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

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 e Istio.

Herramientas:

Istio
Linkerd

Cifrado de tráfico, mTLS entre Servicios

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

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.

Seguridad en etcd

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

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.

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.

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

Guillermo Garcia — Mon, 18 Nov 2024 14:33:00 +0000

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 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:

kubectl describe ns limit-range

Para aplicar limitRange al namespace, hacemos los siguiente:

limit-range-mem-cpu.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:

kubectl describe ns limit-range

vemos ahora que:

Ahora trata de desplegar este Pod:

pod-limit-range-mem-cpu.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

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:

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.

Hablemos de: Pod Disruption Budgets

Guillermo Garcia — Mon, 11 Nov 2024 21:07:00 +0000

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.

Pod Disruption Budgets

Es una política que vamos a aplicar a nuestro deployment para siempre mantener la cantidad de pods que le especifiquemos.

Hagamos el siguiente ejemplo, con un nginx común y silvestre.

Ejemplo de uso de PDB

00-namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
    name: pdb

01-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: pdb
  labels:
    app: nginx
spec:
  replicas: 6
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest

Hasta aquí todo normal, vamos crear el PDB.

03-pdb.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 5
  selector:
    matchLabels:
      app: nginx

Aquí no hay mucho que explicar ya que vemos que siempre intentará tener un mínimo de 5 pods corriendo (minAvailable).

Consideraciones

Si eres observador verás que usa un selector->matchLabels, esto quiere decir que si tienes varias aplicaciones y todos tienen un app: nginx tomará está política, ¿bueno o malo? ya depende de cada escenario y requerimientos, es algo a considerar.

Service Mesh Linkerd

Guillermo Garcia — Sat, 26 Oct 2024 03:14:00 +0000

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:

Instalación

Al igual que Istio debemos instalar un cliente:

curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install-edge | sh

Y mover el cliente a una ruta de tu Path para que funcione y listo.

Puedes ejecutar el siguiente comando para probar que esté funcionando:

linkerd version

Como solo hemos instalado el client veras un error en el server (control plane), esto es normal y más adelante lo solucionamos.

Ahora debemos comprobar que nuestro cluster de kubernetes cumple con la configuración de Linkerd.

linkerd check --pre

El último paso de la instalación es instalar el CRD de Linkerd en nuestro cluster:

linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

Para la validación de la instalación puedes ejecutar el siguiente comando:

linkerd check

o puedes verificar que ya está en estado RUNNING todo lo que se encuentra en el namespace linkerd:

kubectl get all -n linkerd

Configuración de Linkerd

Para que tu aplicación funcione con Linkerd hay que inyectarle el sidecar de Linkerd. Para hacer esto podemos hacerlo de 3 formas:

Agregando a la aplicación (manifest) la annotations:

annotations:
  linkerd.io/inject: enabled

Agregando al namespace el annotations linkerd.io/injec: enabled

kubectl annotate namespace linkerd.io/inject=enabled

Haciendo un deploy de una aplicación e inyectarle Linkerd:

cat deployment.yml | linkerd inject - | kubectl apply -f -

Instalando la aplicación de prueba

Vamos a probar el service mes Linkerd usando la misma aplicación que instalamos con Istio.

Creamos un namespace para nuestra aplicación de ejemplo:

kubectl create namespace bookinfo

Aplicamos el annotations en el namespace:

kubectl annotate namespace bookinfo linkerd.io/inject=enabled

Instalamos la aplicación:

kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/bookinfo/platform/kube/bookinfo.yaml

Vamos a crear un LoadBalancer para la aplicación o si quieres puedes hacer un port-forward:

loadbalancer-bookinfo.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-productpage
spec:
  selector:
    app: productpage
  ports:
    - port: 80
      targetPort: 9080
  type: LoadBalancer
---

port-fordward

kubectl -n bookinfo port-forward svc/productpage 9080:9080

Verificamos que Linkerd se haya inyectado en cada pod, es decir, que cada pod cuente con dos contenedores:

kubectl get pods -n bookinfo

o podemos ejecutar el siguiente comando:

linkerd -n bookinfo check --proxy

Viz Dashboard y extensiones

Linkerd cuenta con su propio dashboard y en esta parte vamos a ver como instalarlo y realizar configuraciones de Prometheus y Grafana ya existentes en nuestro cluster (tal como hicimos en el tutorial de Istio).

Para instalar el dashboard que te incluye Prometheus y Grafana, ejecuta el siguiente comando:

linkerd viz install | kubectl apply -f -

En mi escenario yo ya cuento con Prometheus y Grafana instalados, por lo que tengo que tengo que pasarle ciertos parámetros a Viz, para que haga uso de lo que ya tengo instalado.

Prometheus

Con la siguiente configuración podremos exportar las métricas del control plane y del proxy de Linkerd hacia Prometheus, tal cual hicimos en nuestro tutorial de Istio.

De igual forma puedes editar el configmap o puedes aplicar en un nuevo manifest agregando lo siguiente:

Debes modificar los valores que están dentro de {{.Values.linkerdNamespace}} y {{.Values.namespace}}.

- job_name: "linkerd-controller"
  kubernetes_sd_configs:
    - role: pod
      namespaces:
        names:
          - "linkerd"
          - "linkerd-viz"
  relabel_configs:
    - source_labels:
        - __meta_kubernetes_pod_container_port_name
      action: keep
      regex: admin-http
    - source_labels: [__meta_kubernetes_pod_container_name]
      action: replace
      target_label: component

- job_name: "linkerd-service-mirror"
  kubernetes_sd_configs:
    - role: pod
  relabel_configs:
    - source_labels:
        - __meta_kubernetes_pod_label_linkerd_io_control_plane_component
        - __meta_kubernetes_pod_container_port_name
      action: keep
      regex: linkerd-service-mirror;admin-http$
    - source_labels: [__meta_kubernetes_pod_container_name]
      action: replace
      target_label: component

- job_name: "linkerd-proxy"
  kubernetes_sd_configs:
    - role: pod
  relabel_configs:
    - source_labels:
        - __meta_kubernetes_pod_container_name
        - __meta_kubernetes_pod_container_port_name
        - __meta_kubernetes_pod_label_linkerd_io_control_plane_ns
      action: keep
      regex: ^linkerd-proxy;linkerd-admin;linkerd$
    - source_labels: [__meta_kubernetes_namespace]
      action: replace
      target_label: namespace
    - source_labels: [__meta_kubernetes_pod_name]
      action: replace
      target_label: pod
    # special case k8s' "job" label, to not interfere with prometheus' "job"
    # label
    # __meta_kubernetes_pod_label_linkerd_io_proxy_job=foo =>
    # k8s_job=foo
    - source_labels: [__meta_kubernetes_pod_label_linkerd_io_proxy_job]
      action: replace
      target_label: k8s_job
    # drop __meta_kubernetes_pod_label_linkerd_io_proxy_job
    - action: labeldrop
      regex: __meta_kubernetes_pod_label_linkerd_io_proxy_job
    # __meta_kubernetes_pod_label_linkerd_io_proxy_deployment=foo =>
    # deployment=foo
    - action: labelmap
      regex: __meta_kubernetes_pod_label_linkerd_io_proxy_(.+)
    # drop all labels that we just made copies of in the previous labelmap
    - action: labeldrop
      regex: __meta_kubernetes_pod_label_linkerd_io_proxy_(.+)
    # __meta_kubernetes_pod_label_linkerd_io_foo=bar =>
    # foo=bar
    - action: labelmap
      regex: __meta_kubernetes_pod_label_linkerd_io_(.+)
    # Copy all pod labels to tmp labels
    - action: labelmap
      regex: __meta_kubernetes_pod_label_(.+)
      replacement: __tmp_pod_label_$1
    # Take `linkerd_io_` prefixed labels and copy them without the prefix
    - action: labelmap
      regex: __tmp_pod_label_linkerd_io_(.+)
      replacement: __tmp_pod_label_$1
    # Drop the `linkerd_io_` originals
    - action: labeldrop
      regex: __tmp_pod_label_linkerd_io_(.+)
    # Copy tmp labels into real labels
    - action: labelmap
      regex: __tmp_pod_label_(.+)

Ahora vamos a crear un archivo llamado prometheus-values.yaml y vamos a copiar lo siguiente para decirle a viz que haga uso de nuestro Prometheus:

prometheusUrl: http://prometheus-service.monitoring.svc.cluster.local:8082/
prometheus:
  enabled: false

La primera línea es la url de Prometheus. La segunda es para decirle a Viz que no haga uso del Prometheus que instala (vamos, que haga uso de Prometheus que ya tenemos instalado).

Linkerd Jaeger

Para instalar Jaegar es muy sencillo:

linkerd jaeger install | kubectl apply -f -

Verificamos que todo se haya instalado correctamente:

linkerd jaeger check

Nota: Recuerda que para que jaeger muestre las trazas la aplicación debe tener implementado tracing, en esta aplicación que estamos usando de prueba no tiene habilitado/programado el tracing:

Si se lo quieres habilitar lo puedes hacer con el siguiente comando:

kubectl -n bookinfo set env --all deploy OC_AGENT_HOST=collector.linkerd-jaeger:55678

Lo que hace este comando es que agrega una variable de entorno que habilita la aplicación a propagar y emitir trazas.

Grafana

Para Grafana es más fácil, por que solo tenemos que pasarle un parámetro a Viz.

Los dashboards recomendados son:

14260, 11868, 14262, 14261, 14263

linkerd viz install --set grafana.url=http://grafana.ahioros.homelab.local | kubectl apply -f -

NOTA: en caso que estés usando un proveedor externo de Grafana debes usar el siguiente parámetro:

linkerd viz install --set grafana.externalUrl=https://dirección-grafana.net/ | kubectl apply -f -

Comando completo

En nuestro caso tenemos que pasarle también el archivo prometheus-values.yaml por lo que el comando quedaría así:

linkerd viz install --set grafana.externalUrl=http://grafana.ahioros.homelab.local -f prometheus-values.yaml | kubectl apply -f -

Para obtener la funcionalidad de que aparezca el ícono de jaeger en el dashboard después de instalarlo debemos hacer lo siguiente:

linkerd viz install --set jaegerUrl=jaeger.linkerd-jaeger:16686 | kubectl apply -f -

Validamos nuevamente que todo se haya instalado correctamente:

linkerd check

Y si unimos todos los comandos de prometheus, grafana, jaeger tenemos:

linkerd viz install --set grafana.externalUrl=http://grafana.ahioros.homelab.local -f prometheus-values.yaml --set jaegerUrl=jaeger.linkerd-jaeger:16686 | kubectl apply -f -

Linkerd Dashboard

Para ver el dashboard ejecutamos el siguiente comando (esto te abrirá una ventana en tu navegador):

linkerd viz dashboard

Nota: También puedes crearte un port-forward, LoadBalancer, Ingress, para ver el dashboard.

Al igual que con Istio la comunicación entre los microservicios es cifrada, te puedes dar cuenta aquí:

O entrando a algún Deployment y verás en la columna superior derecha que dice meshed

Desinstalación de Linkerd

Eliminamos la aplicación:

kubectl delete ns bookinfo

Eliminar las extensiones:

linkerd viz uninstall | kubectl delete -f -

Eliminamos jaeger:

linkerd jaeger uninstall | kubectl delete -f -

Eliminar el control plane, CRDs, namespace, etc:

linkerd uninstall | kubectl delete -f -

Listo espero te haya funcionado si tienes dudas o comentarios no dudes en contactarme o dejarme tu comentario, saludos.

Service Mesh Istio

Guillermo Garcia — Tue, 15 Oct 2024 17:13:00 +0000

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:

Beneficios de una Service mesh

Detección de servicios.
Balanceador de carga
Administración de tráfico
División de tráfico
Creación de reflejos de solicitudes
Implementación de valores controlados
Seguridad
Supervisión

Desventajas de una Service mesh

Se incrementa el tiempo de ejecución
Cada llamada primero se ejecuta en el proxy-sidecar (se agrega un paso adicional)
Alguien debe integrar la Service Mesh en los flujos de trabajo y administrar su configuración

Funcionamiento

Básicamente por medios de varios proxies dirige y rastrea la comunicación entre los servicios.

En donde el proxy es un gateway entre la red de la organización y el microservicio. Estos proxies se les llama sidecares, porque Istio agrega un contenedor junto al pod del microservicio. Y estos proxies son los que forman la service mesh.

Y dentro de cada Pod:

Dentro de la arquitectura hay dos componentes principales:

Plano de datos

Cuando un servicio se quiere comunicar con otro, el proxy del sidecar hace lo siguiente:

El sidecar intercepta la solicitud.
La solicitud es encapsulada en una conexión de red independiente.
Levanta un canal seguro y cifrado entre los proxies de origen y destino.

Plano de control.

Es la capa de administración y configuración de la service mesh.
La implementación suele incluir estas capacidades:

Registro de servicios: se hace seguimiento de todos los servicios en la service mesh.
Detección automática de nuevos servicios y eliminación de servicios inactivos.
Recopilación y agregación de datos de telemetría (métricas).

Istio

Hoy instalaremos Istio que es una service mesh de Google, IBM y Lyft.

Istio: Es una solución muy popular para gestionar los diferentes microservicios que conforman una aplicación nativa de la nube.

Una recomendación es usar Istio con aplicaciones grandes, ya que puede ser un poco complejo dependiendo lo que queramos hacer.

Instalación

Consta de un ejecutable que hay que colocar en el path:

curl -L https://istio.io/downloadIstio | sh -

Entramos en el directorio que descargamos y dentro hay una carpeta bin, movemos el ejecutable istioctl a una ruta de nuestro path en mi caso es, ejemplo:

cd istion-1.3.22/bin
mv istioctl $HOME/.local/bin

Instalamos Istio en nuestro cluster de kubernetes:

istioctl install

Podemos ver que nos ha creado un nuevo namespace:

Ahora para configurar Istio en todo un namespace de tu aplicación lo único que hay que hacer es ejecutar el siguiente comando:

kubectl label namespace TUNAMESPACE istio-injection=enabled

Para ver los labels que tiene el namespace:

kubectl get ns TUNAMESPACE --show-labels

NOTA: En el ejemplo se aplicará al namespace default, si ya tienes una aplicación ejecutándose en el namespace es necesario volver a desplegarla o cuando se haga un upgrade de la aplicación se le aplicará el label istio-injection=enabled.

Monitoreo y Visualización de datos

Para el monitoreo contamos con los dos viejos conocidos Prometheus y Grafana (también cuenta soporte para Apache SkyWalking).
Para la Visualización de datos debemos instalar Jaeger y Kiali, Jaeger se hace cargo de realizar trazabilidad del sistema, permitiendo al usuario monitorear y ver problemas en sistemas distribuidos complejos y Kiali es el dashboard de observabilidad.

NOTA: Jaeger no es el único que existe también se puede utilizar Zipkin.

Prometheus y Grafana

Hay dos escenarios:

Prometheus y Grafana ya están instalados
Prometheus y Grana no están instalados

En este post nos vamos a enfocar en el primer escenario, ya que no hay mucha documentación de cómo hacerlo mientras que el segundo escenario hay por montones y es el escenario que nadie suele tener.

En nuestros manifest de Prometheus, buscamos el configmap de Prometheus y agregamos lo siguiente, en la sección de scrape_configs (también puedes editar el configmap de Prometheus claro está):

Vamos a agregar la configuración para exportar las stats de Istiod:

---
- job_name: "istiod"
  kubernetes_sd_configs:
    - role: endpoints
      namespaces:
        names:
          - istio-system
  relabel_configs:
    - source_labels:
        [__meta_kubernetes_service_name,__ meta_kubernetes_endpoint_port_name]
      action: keep
      regex: istiod;http-monitoring

Para exportar las stats de Envoy proxy-sidecar y gateway proxies agregamos lo siguiente (seguimos en el configmap de Prometheus).

- job_name: "envoy-stats"
  metrics_path: /stats/prometheus
  kubernetes_sd_configs:
    - role: pod

  relabel_configs:
    - source_labels: [__meta_kubernetes_pod_container_port_name]
      action: keep
      regex: ".*-envoy-prom"

Nota: después de aplicar estos cambios entramos a la consola de Prometheus en el menú damos click en Status-> Service Discovery, y veremos las dos nuevas métricas que son: envoy-stats y istiod, corresponden a las dos configuraciones que hemos agregado en la parte de arriba.

Si quieres ver desde grafana estas métricas puedes ir al panel de la izquierda -> Metrics y en Search Metrics escribes istio.

Listo ya puedes entrar en Grafana y agregar el dashboard de Istio Control Plane Dashboard (ID: 7645), si te vas al panel izquierdo->Metrics podrás seleccionar las métricas que quieras ver de Istio.

Algunos Dashboards que te pueden interesar:

7639 11829 7636 7630 13277

Aplicación de Prueba

Ahora vamos a probar nuestra service mesh con una aplicación, si ya tienes una aplicación solo debes agregar el label istio-injection=enabled

Creamos un namespace para nuestra aplicación de ejemplo:

kubectl create namespace bookinfo

Aplicamos el label en el namespace, esto hará que Istio cree el sidecar en el pod:

kubectl label namespace bookinfo istio-injection=enabled

Instalamos la aplicación:

kubectl -n bookinfo apply -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/bookinfo/platform/kube/bookinfo.yaml

Ingress y Gateway

Actualmente Istio cuenta con su propio Ingress pero están migrando a usar el Gateway de Kubernetes el cual por default no está instalado, por lo que debe realizar primero el siguiente comando:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

Istio cuenta con su propio ingress, por lo que para acceder a la aplicación lo haremos con el siguiente manifest:

gateway-bookinfo.yaml

    ---
    apiVersion: gateway.networking.k8s.io/v1beta1
    kind: Gateway
    metadata:
      name: bookinfo-gateway
    spec:
      gatewayClassName: istio
      listeners:
      - name: http
        port: 80
        protocol: HTTP
        allowedRoutes:
          namespaces:
            from: Same

Y también creamos una configuración de las rutas:

route-bookinfo.yaml

    ---
    apiVersion: gateway.networking.k8s.io/v1beta1
    kind: HTTPRoute
    metadata:
      name: bookinfo
    spec:
      parentRefs:
      - name: bookinfo-gateway
      rules:
      - matches:
        - path:
            type: Exact
            value: /productpage
        - path:
            type: PathPrefix
            value: /static
        - path:
            type: Exact
            value: /login
        - path:
            type: Exact
            value: /logout
        - path:
            type: PathPrefix
            value: /api/v1/products
        backendRefs:
        - name: productpage
          port: 9080

Instalamos ambos manifest:

kubectl -n bookinfo apply -f gateway-bookinfo.yaml
kubectl -n bookinfo apply -f route-bookinfo.yaml

Ahora podemos acceder a nuestra aplicación en caso que cuentes con metallb solo haces lo siguiente:

kubectl -n bookinfo get gateway

De lo contrario tendrás que realizar un port-forward:

kubect -n bookinfo port-forward svc/bookinfo-gateway-istio 8080:80

La URL es:

http://IP/productpage

Si es port-forward podrá ser:

http://IP:8080/productpage

Una vez hayas entrado a la página, la aplicación se verá así:

Jaeger para el rastreo (tracing)

Como mencioné anteriormente Jaeger tiene tareas interesantes como:

Monitoreo de las transacciones entre microservicios.
Análisis de la causa raíz
Análisis de la trazabilidad de los microservicios
Análisis de la dependencia de servicios
Optimización de rendimiento / latencia

Para instalarlo ejecutamos el siguiente comando:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/addons/jaeger.yaml

Kiali el Dashboard de Istio

Para instalarlo ejecutamos el siguiente comando:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/addons/kiali.yaml

Pero como nosotros tenemos instalado Prometheus y Grafana en diferentes namespaces (monitoring y grafana respectivamente), tenemos que editar el manifest kiali.yaml por lo que te recomiendo que lo bajes o puedes configurar el configmap de kiali en el namespace de istio-systems:

Configmap de kiali:

kubectl -n istio edit configmaps kiali

En ambos casos debemos buscar la línea que dice external_services, y agregamos lo siguiente:

external_services:
  prometheus: # prometheus-service es el servicio de prometheus, monitoring es el namespace donde está prometheus instalado.
    url: "http://prometheus-service.monitoring.svc.cluster.local:8082/"
  grafana:
    in_cluster_url: "http://grafana.grafana.svc.cluster.local"
    url: "http://grafana.ahioros.homelab.local"
..
..
..
  tracing:
    enabled: true

Este último parámentro (tracing) es para el jaeger.

Espera hasta que el pod este en estado Running, para realizar el siguiente comando:

istioctl dashboard kiali

Esto te abrirá una página en tu navegador.

O puedes crear un manifest loadbalancer para acceder a kiali.

Generación de tráfico

Vamos a crear tráfico para poder analizar con Istio la trazabilidad de los microservicios.

Ejecuta:

for i in $(seq 1 100); do curl -s -o /dev/null "http://istio.ahioros.homelab.local/productpage"; done

Recuerda cambiar istio.ahioros.homelab.local por la IP que tienes para acceder al servicio.

Dale click al menú de la izquierda donde dice "Traffic Grap", selecciona el namespace "bookinfo", y en la esquina superior derecha te recomiendo que pongas Last 1h y que se actualice Every 1m.

Debes poder ver algo como esto:

Ahora dale click al menú de la izquierda -> "Mesh" aquí podrás ver los componentes de Istio (Los configs que hicimos de Prometheus, Grafana y Jaeger):

Seguridad en Istio

Por default Istio cifra el comunicado entre los proxies de los microservicios, esto lo puedes comprobar dando click en el menú de la izquierda -> "Traficc Graph", busca la opción que debajo de Namespace, dale click en Display, hasta abajo está la opción Securitty dale click a la casilla.

Ahora verás como aparece un candado en la línea de comunicacion de los microservicios, y si seleccionas dicha línea en el gráfico, verás que te aparecerá en las configuraciones de la derecha una nueva opción que dice: mTLS Enabled. También te recomiendo que le des click en la casilla de Traffic Animation, Response Time, Throughput y Traffic Distribution (esta última es excelente cuando haces despliegues de un microservicio nuevo y quieres ver cómo se comporta después de crear una política donde le enviés X cantidad del tráfico).

Nota: Recuerda generar tráfico en la aplicación.

Se verá algo más o menos así:

Final

Hasta aquí dejamos este tutorial.

Desinstalación de Istio

Ejecuta:

istioctl uninstall -y --purge

Recuerda borrar el namespace de Istio:

kubectl delete namespace istio-system

Eliminar la aplicación de bookinfo y sus componentes:

kubectl -n bookinfo delete -f https://raw.githubusercontent.com/istio/istio/release-1.23/samples/bookinfo/platform/kube/bookinfo.yaml

kubectl -n bookinfo delete -f gateway-bookinfo.yaml
kubectl -n bookinfo delete -f route-bookinfo.yaml

Y también recuerda eliminar el namespace de la aplicación:

kubectl delete namespace bookinfo

Y para eliminar el Gateway de kubernetes (opcional):

kubectl delete -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

MetalLB tu Load Balancer Bare-Metal

Guillermo Garcia — Tue, 08 Oct 2024 00:29:00 +0000

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.

¿Qué es MetalLB?

MetalLB es un Load Balancer para tu cluster de Kubernetes bare-metal basado en software, así de simple.

Si alguna vez intentaste aplicar un manifest de alguna aplicación con el servicio LoadBalancer en tu cluster local de kubernetes, notarás que se queda en un estado "pending", esto es por que kubernetes no cuenta con un load balancer por defecto.

Instalación

Manos a la obra.

Pre-requisito

Necesitamos configurar a true el valor de strictARP para que MetalLB funcione:

    kubectl edit configmap -n kube-system kube-proxy

---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

Nota: Si estas usando kube-proxy con IPVS mode, te cuento que desde la versión v1.14.2 ya está habilitado strict ARP mode.

Instalación de MetalLB

Solamente debemos ejecutar un (esta es la última versión cuando se escribió este post):

    kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.8/config/manifests/metallb-native.yaml

Configuración del IP Pool (capa 2)

Para configurar el IP Pool, necesitamos contar como su nombre dice con una IP o un rango de IP que puedan ser asignados a nuestros Load Balancer cuando los creemos con nuestros manifest.

Creamos el archivo: metallb-ipadd-pool.yaml

---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.122.165-192.168.122.175

Nota: en spec.addresses: en mi caso ese es el rango que tomarán los Load Balancer.

Vamos restringir las IPs

Ahora vamos a decirle a MetalLB que solo le permita a los Load Balancer que tengan la IP Pool que configuramos arriba, que es la IP Pool que creamos arriba.

Creamos un archivo llamado: metallb-pool-advertise.yaml

---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: first-pool-advertise
  namespace: metallb-system
spec:
  ipAddressPools:
    - first-pool

Prueba

Vamos a crear un deployment de un Nginx y lo vamos a exponer usando un Load Balancer (MetalLB).

    kubectl create deployment nginx-web-server-test --image=nginx
    kubectl expose deployment nginx-web-server-test --port=80 --target-port=80 --type=LoadBalancer

Y si abrimos nuestro navegador y escribimos la IP que dice: EXTERNAL-IP podremos ver nuestro Nginx.

Nota: Recuerda agregar la IP y el FQDN en tus DNS de ser necesario.

Espero te sirva este post para tu trabajo, laboratorio, etc. Cualquier duda puedes dejarla en el área de comentarios.

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

Guillermo Garcia — Fri, 04 Oct 2024 14:55:00 +0000

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í

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

Guillermo Garcia — Mon, 16 Sep 2024 15:13:00 +0000

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.

¿Cómo funciona HPA?

1. Recolección de métricas.
2. Evaluación de políticas que se hayan definido en la aplicación.
3. Ajuste de replicas, es decir, ajuste del número de pods que se crean o se eliminan.

Manos a la obra

Para tener disponible HPA hay que cumplir unas dependencias:

1. Instalar metric-server.
2. Configurar HPA en la aplicación o en el manifest.

Instalación de metric-server

Si estás usando un servidor de un solo nodo master usa este link:

    kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Si estás usando un clusterde k8s con HA usa este link:

    kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability.yaml

Para minikube solo tienes que hacer:

    minikube addons enable metrics-server

Ahora verificamos que se haya instalado:

    kubectl get pods -n kube-system | grep metrics-server

Ahora podemos obtener las métricas de nuestro cluster:

    kubectl top nodes
    kubectl top pods -A #Para ver todos o puedes usar -n nombredelnamespace

Y podemos ver los deployments que usen hpa (en estos momentos no mostrará nada pero ya vamos a hacer uno).

    kubectl get hpa -A

Ejemplo de configuración de HPA en una aplicación

Vamos a configurar HPA en nuestra aplicación, en este caso usaré nginx, nota que usaré los valores de CPU de 10m y 11m y que no tengo especificado la cantidad de réplicas.

Vamos a crear 4 archivos:

1. 00-namespace.yaml
2. 01-deployment.yaml
3. 02-service.yaml
4. 03-hpa.yaml

00-namespace.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: hpa-test

01-deployment.yaml

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: hpa-test
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 10m
          limits:
            cpu: 11m

Nota: usamos resource requests y limits de CPU en el ejemplo puse valores de 10m y 11m, y date cuenta que no tengo especificado la cantidad de réplicas. También puedes hacer lo mismo con la memoria.

02-service.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  namespace: hpa-test
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Nota: en mi caso en type: uso LoadBalancer porque tengo metallb en mi cluster, si no lo tienes deberás usar NodePort y deberás crear un port-forward para acceder al nginx.

03-hpa.yaml

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
  namespace: hpa-test
spec:
  scaleTargetRef:
    kind: Deployment
    name: nginx-deployment
    apiVersion: apps/v1
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 20
    type: Resource

Presta atención a minReplicas y maxReplicas, por default iniciará con 1 solo pod, pero cuando tenga un uso mayor 20% de CPU, se crearán 10 nuevos pods.

Nota: esos valores son de ejemplo, a ti te tocará hacer pruebas para sacar los mejores valores para tu aplicación.

Si quisieras usar la memoria para el HPA puedes usar:

---
...
metrics:
- type: Resource
  resource:
    name: memory
    target:
      type: AverageValue
      averageValue: 10Mi # este valor es un ejemplo.

Guarda todos los archivos en una carpeta y ejecuta:

    kubectl apply -f .

Después de unos minutos (minuto y medio aprox.) podrás ver que ya se están mostrando los valores de hpa:

    kubectl get hpa -n hpa-test

Probando HPA

Te recomiendo que abras 3 terminales, en dos de ellas ejecutarás estos comandos respectivamente:

Terminal 1:

    watch -n 1 "kubectl get hpa -n hpa-test"

Terminal 2:

    watch -n 1 "kubectl get pods -n hpa-test"

Y en la Terminal 3: vamos a generar tráfico para estresar y subir el cpu, puedes abrir un navegador y dejar F5 presionado o puedes ejecutar el siguiente script:

#!/bin/sh

while true; do
    curl http://URL:PORT
done

Guardamos el archivo como traffic.sh, le damos permisos de ejecución y lo ejecutamos:

    chmod +x traffic.sh
    ./traffic.sh

Al cabo de unos minutos verás qué:

Terminal 1:
Como sube el uso del CPU.

Terminal 2:
Como se empiezan a crear los pods hasta llegar al valor de maxReplicas: 10

Ahora puedes detener el script y al cabo de unos 2-3 minutos se empezarán a destruir los pods hasta quedar en minReplicas: 1

¡Felicidades funciona!

Qué tal si te digo que podemos configurar con más detalle HPA scaleUp, scaleDown y policies

Vamos a configurar más a detalle el comportamiento de HPA (ahorrando más dinero $$$).

Editamos nuestro archivo 03-hpa.yaml:

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
  namespace: hpa-test
spec:
  scaleTargetRef:
    kind: Deployment
    name: nginx-deployment
    apiVersion: apps/v1
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 20
    type: Resource
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 1
          periodSeconds: 30
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 1
          periodSeconds: 30

Mira que hemos agregado una nueva sección llamada behavior, que contiene dos secciones: scaleUp y scaleDown.
Con esta sección definimos el tiempo de estabilización de la aplicación y las políticas de escalado hacia arriba y hacia abajo, es decir, le configuramos cuando el cluster debe crear más pods y cuando debe eliminar los pods dejando la aplicación en el estado deseado (minReplicas). Y en este ejemplo estará escalando hacia arriba o hacia los pods de 1 en 1 cada 30 segundos. A diferencia del ejemplo inicial, que crea los 10 pods de una vez cuando estresamos la aplicación.

Tip cálculo de pods

Para sacar el cálculo de los valores deberás usar la siguiente fórmula:

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

Donde:

- currentReplicas: Es el número actual de réplicas del pod que está siendo escalado.
- currentMetricValue: Es el valor actual de la métrica que se está utilizando para escalar (por ejemplo, el uso actual de la CPU).
- desiredMetricValue: Es el valor deseado de la métrica que se está utilizando para escalar (por ejemplo, el uso deseado de la CPU).
- ceil(): Es una función que redondea hacia arriba al número entero más cercano.

Recuerda que para ver el máximo de pods, CPU y memoria de cada nodo puedes hacer un:

    kubectl describe nodes

Esto te mostrará todos los nodos y te tocará buscar la sección Allocated resources :

o puedes hacer:

    kubectl describe nodes NOMBREDELNODO-1 NOMBREDELNODO-2

Hasta aquí el uso de HPA, puedes configurar lo más detallado posible para ahorrar ~~recursos~~ dinero y maximizar la elasticidad de tu aplicación.

Cualquier duda en la caja de comentarios.

Helm creando tu repositorio

Guillermo Garcia — Fri, 30 Aug 2024 15:04:00 +0000

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:

helm search hub grafana

Buscar en los repositorios ya instalados:

helm searh repo grafana

Para ver los Values de un paquete:

helm show values grafana

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

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/

Subir nuestro paquete al repositorio.

En el post anterior creamos nuestro package/paquete de nuestra aplicación. Para que funcione nuestro repositorio debemos crear una carpeta llamada charts y dentro poner nuestro paquete.

Ahora debemos crear un archivo index.yaml para que helm sepa que charts hay dentro del repositorio.

helm repo index .

Nota: Hay un espacio y un punto después de index.

El contenido de este index.yaml es:

Ahora queda subirlo al repositorio de github.

Agregando nuestro repositorio a Helm

Para agregar nuestro repositorio a Helm debemos ejecutar:

helm repo add turepo https://TUURLDETUREPOSITORIO/TUCHARTS

helm repo add ahioros https://ahioros.github.io/nginx-charts/

Comprobamos que se ha agregado correctamente nuestro repositorio:

helm search repo turepo

helm search repo ahioros

Instalando desde tu repositorio

Ahora lo que queda es instalar tus propios paquetes desde tu repositorio recien creado.

Puedes realizar una "instalación fake"

helm install --dry-run nombrepaquete turepo/nombrepaquete

helm install --dry-run test ahioros/nginx-chart

Nota: esto nos instalará el paquete nginx-chart (sin S al final) de nuestro reposirotorio que se llama nginx-charts (con S al final) el paquete cuando sea instalado se llamará test.

Salida:

---
NAME: test
LAST DEPLOYED: Tue Aug 27 18:48:41 2024
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
HOOKS:
MANIFEST:
---
# Source: nginx-chart/templates/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: nginx-chart
---
# Source: nginx-chart/templates/lbl-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-test-nginx-chart
  namespace: nginx-chart
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  selector:
    app:
    app.kubernetes.io/name: nginx-chart
    app.kubernetes.io/instance: test
---
# Source: nginx-chart/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: test-nginx-chart
  namespace: nginx-chart
spec:
  selector:
    app:
    helm.sh/chart: nginx-chart-1.0.0
    app.kubernetes.io/name: nginx-chart
    app.kubernetes.io/instance: test
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
# Source: nginx-chart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-nginx-chart
  namespace: nginx-chart
spec:
  replicas: 2
  selector:
    matchLabels:
      app:
      app.kubernetes.io/name: nginx-chart
      app.kubernetes.io/instance: test
  template:
    metadata:
      labels:
        app:
        app.kubernetes.io/name: nginx-chart
        app.kubernetes.io/instance: test
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

NOTES:
Nginx se ha desplegado correctamente. Puedes acceder a la aplicación a través de http://IP:80
---

Ahora si todo está bien ya puedes instalar tu paquete, solo debes quitar el --dry-run:

helm install nginx-chart ahioros/nginx-chart

Podemos verificar nuestra aplicación instalada con kubectl:

kubectl get all -n nginx-chart

Listo hasta aquí la guía de Helm, espero que te sirva, si tienes dudas puedes dejarla en los comentarios.