Crea tu entorno para el CKAD II

Verifica tu entorno para el CKAD

Introducción

En un artículo anterior creamos un clúster en local con Minikube con todas las características necesarias para poder preparar el examen del CKAD. Las funcionalidades que habilitamos, fueron: Ingress, HPA y Networkpolicy. Durante el examen del CKAD, es más que probable que encontremos preguntas acerca de las mismas.

Requisitos

Para poder realizar los siguientes pasos, debes partir de nuestro artículo anterior. Una vez hayas completado los pasos descritos, puedes empezar con esta segunda parte.

Si no lo has hecho todavía, ¿a qué esperas? El CKAD te está llamando 😎.

TL;DR;

1. Verificación Ingress. El Ingress nos va a permitir exponer nuestras aplicaciones dentro del cluster al mundo exterior. Su configuración, u encontrar fallos de configuración, son preguntas típicas del CKAD. Para verificar su correcto funcionamiento detectaremos que las piezas relevantes se están ejecutando y que podemos acceder a una aplicación desplegada por nosotros.

2. Verificación Metrics Server. Durante el CKAD, nos pedirán escalar manualmente nuestras cargas de trabajo usando kubectl scale. Aunque no es un topic que entre directamente en el examen, es más que probable, que los clústeres que nos encontraremos en un marco productivo profesional, puedan usar el HPA. En nuestro post anterior usamos el addon del Metric Server, que nos permitía tener en nuestro clúster este tipo de cargas de trabajo auto escalables. Para ponernos en contexto, de lo que es un HPA, lo podríamos resumir como: Un HPA es una 'aplicación' que se escala de forma automática dentro del cluster a partir de sus necesidades de memoria y/o CPU.

3. Verificación Networkpolicy. Este objeto de Kubernetes, también es un clásico del CKAD. Básicamente consiste en definir políticas de red, para restringir que se puede (o no se puede) ver dentro del cluster. Cómo ya explicamos en nuestro anterior artículo, para poder utilizarlo, necesita de un plugin de red que lo soporte. Para demostrar su correcto funcionamiento, básicamente lo utilizaremos.

Pasos

1. Arrancar Entorno

Si continuas desde el artículo anterior y tienes el clúster en ejecución salta este punto y pasa directamente a las verificaciones. Si no has creado el entorno, puedes volver a nuestro artículo anterior para generarlo. Si, sí lo hiciste y lo tienes que volver a arrancar el entorno, sigue lo siguientes pasos:

1. Abre el proyecto en Visual Studio Code, notar que en el raíz del proyecto tenemos la carpeta .devcontainer

2. Arranca Dev Containers desde Visual Studio Code. Para ello haz click sobre el icono, de los 'chevrons enfrentados' en la esquina inferior izquierda.

3. El paso anterior abrirá el Command Palette de Visual Studio Code, selecciona 'Reopen in Container'

Command Palette Visual Studio

4. Pasados unos minutos, el contexto de Visual Studio Code, cambia al del contenedor. Abre una terminal embebida, y ejecuta el siguiente comando:

minikube start

Listo, ya podemos continuar con los siguientes pasos.

2. Verificación Ingress

Antes de comenzar, debemos tener en cuenta, que el ingress que instalamos como addon (o cualquier otro addon) no es más que una instalación estándar que pudiéramos hacer por nuestra propia cuenta y riesgo usando la API de Kubernetes; pero por esto mismo usamos Minikube, nos permite acceso rápido a recursos más complejos de forma transparente.

Una vez hecha esta aclaración, para comenzar a verificar que el ingress está instalado de forma correcta podemos comenzar por ejecutar:

kubectl get ns

Ejecución del comando kubectl get ns

Como podemos ver, se ha creado un nuevo namespace ingress-nginx. Para ver que contiene ejecutamos el siguiente comando en la terminal:

kubectl get all -n ingress-nginx

Ejecución del comando kubectl get all -n ingress-nginx

Podemos observar que un nuevo controller, en forma de deployment, se ha creado, y que su estado es Running.

Es este controller el responsable, de observar los recursos ingress que declaremos y generar las cargas de trabajo necesarias para exponer nuestras aplicaciones que corren dentro del clúster.

Vamos a hacer una última prueba para ver que todo funciona como esperamos: exponemos la página web por defecto servida por nginx

nginx es un servidor web usado como proxy reverso, balanceador de carga y almacenamiento en caché

kubectl create deployment my-nginx --image=nginx:alpine --port=80

kubectl expose deployment my-nginx --port=80 --target-port=80

Podemos verificar que los recursos anteriores se han generado como esperamos, podemos ejecutar el siguiente comando:

kubectl get svc,deployment

Este comando nos devuelve los servicios y deployments que se encuentran en el clúster en el contexto del namespace en el que estamos trabajando. Aquí debemos ver los elementos creados anteriormente.

my-nginx en el puerto 80 y funcionando

Para verificar que la página de nginx se sirve podemos utilizar un pod y realizar las peticiones http pertinentes:

kubectl run -it --rm --restart=Never curl --image=alpine/curl sh

Desde el contenedor:

curl http://my-nginx

Debemos obtener una respuesta similar a esta, la página por defecto que sirve Nginx:

nginx response

Para salir de la nueva terminal interactiva, utiliza el atajo de teclado Ctrl + C o el comando exit.

Ya estamos listos para crear un recurso ingress que exponga my-nginx al mundo exterior. Creamos un nuevo fichero my-nginx-ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: example-ingress
spec:
 ingressClassName: nginx
 rules:
   - http:
       paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: my-nginx
               port:
                 number: 80

Y lo creamos en el clúster, utilizando:

kubectl apply -f my-nginx-ingress.yaml

Podemos verificar que el nuevo recurso de ingress se ha generado mediante:

kubectl get ingress

NOTA: La asignación de address no es inmediata, es posible que tengamos que esperar un par de minutos

Objeto ingress creado

Podemos verificar de múltiples maneras que somos capaces de alcanzar Nginx, en nuestro caso vamos a exponerlo para poder visualizarlo en nuestro navegador local.

Abrimos la pestaña PORTS en Visual Studio Code, y añadimos un puerto nuevo, con el valor address de nuestro objeto ingress:

Añadimos un puerto nuevo con el valor address de nuestro objeto ingress

Se nos ha generado un forwarded address desde el que podemos acceder mediante un navegador

Y abriendo el puerto en el navegador vemos la página de nginx

Accediendo a nginx desde el navegador

3. Verificación Metrics Server

Para poder utilizar cargas de trabajo auto escalables, utilizando el recurso HPA, debemos tener una 'pieza' que sea capaz de recoger métricas, de los recursos desplegados dentro del clúster. Estas métricas miden el consumo de CPU y memoria entre otras cosas. En base a las mismas se toman las decisiones de escalado (número de Pods en el Deployment). Es por esta razón que habilitamos en el post anterior el addon del metrics server.

Después de haber añadido el addon del metric server, podemos comprobar que está listo para poder trabajar con cargas de tipo HPA, inspeccionando los recursos generados. Por un lado podemos observar un nuevo deployment dentro del namespace kube-system

kubectl get deploy -n kube-system

metrics-server funcionando

Y además, se ha extendido la API con dos nuevos recursos:

kubectl api-resources -o wide

API extendida con dos nuevos recursos del metrics-server

Queda fuera de este artículo demostrar el HPA, en un próximo artículo, construiremos por nuestra cuenta una aplicación que escale en función de sus requisitos de CPU y/o memoria.

4. Verificación Networkpolicy

Las Network Policies, nos permiten restringir el tráfico entre los distintos recursos desplegados dentro del clúster. Para poder verificar las Network Policies, nuestro clúster debe de ejecutar un plugin de red que las soporte, era por ello que en el artículo anterior, explicamos como arrancar Minikube con Cilium uno de los múltiples plugins de red que soporta Minikube y que permite implementar las Network Policies.

Arrancamos el clúster con el driver de Cilium (haz sólo esto si no lo tienes corriendo ya) a partir del artículo anterior.

minikube stop

minikube start --cni=cilium

kubectl get pods -n kube-system

Muestra todos los pods de cilium

ADVERTENCIA: Es posible que cuando arranques el clúster utilizando el flag --cni, no aparezcan los ansiados pods de cilium. Para el clúster con minikube stop, borra el clúster con minikube delete, arranca usando el flag --cni, minikube start --cni=cilium. No te preocupes por los addons seguirán ahí 😉.

Creamos el fichero my-network-policy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: api-allow
spec:
 podSelector:
   matchLabels:
     app: my-api
     role: api
 ingress:
   - from:
       - podSelector:
           matchLabels:
             app: api-client

Básicamente lo que estamos haciendo con esta NetwokPolicy, es aplicarla a aquellos Pods, que contengan las etiquetas app: my-api y role: api; y sólo permitir el tráfico desde los pods que tengan la etiqueta app: api-cient. Esto nos sirve para aislar el tráfico, y añadir un extra de seguridad, entre los distintos recursos desplegados en el clúster.

kubectl apply -f my-network-policy.yaml

kubectl get networkpolicy

Network policy implementada

Para comprobar que nuestra NetworkPolicy, se está aplicando, vamos a ejecutar un Pod, con las etiquetas que hagan que se ejecute la network policy.

kubectl run nginx --image=nginx

kubectl label pods nginx app=my-api role=api

Podemos encontrar la IP asignada al Pod nginx ejecutando:

kubectl get pods -o wide

IP asignada al pod nginx

kubectl run curl --image=alpine/curl --command sleep infinity

kubectl exec -it curl -- sh

Desde dentro del Pod ejecutamos una petición contra el Pod nginx, recordemos que sólo recibirá peticiones de aquellos pods con la etiqueta app: api-client. Todavía no la hemos aplicado.

curl -v http://10.244.0.141

NOTA: Vamos a tener un timeout, así que en vez de esperar, podemos cortarlo directamente.

Error de consola al ejecutar el comando anterior, debido al timeout

kubectl label pods curl app=api-client

Volvemos ahora a nuestro Pod curl:

kubectl exec -it curl -- sh

Y ejecutamos de nuevo desde dentro de este Pod:

curl http://10.244.0.141

5. Clean up

Si quieres volver a un clúster de Minikube en el cuál no estén aplicados los recursos que hemos generado sigue los siguientes pasos de limpia.

Eliminamos los recursos generados en la verificación de ingress

kubectl delete deployment my-nginx

kubectl delete service my-nginx

kubectl delete -f ./

Eliminamos la NetworkPolicy

kubectl delete networkpolicy api-allow

Eliminamos los Pods restantes

kubectl delete pod curl nginx

Wrap up

Con esto concluimos nuestro segundo artículo acerca del entorno necesario para preparar el CKAD. Cuando somos nuevos con estas tecnologías puede ser sobrecogedor arrancar, las buenas noticias es que a día de hoy disfrutamos de herramientas maduras y ligeras que permiten un mejor acceso.

Y recuerda que si te entusiasma el mundo del DevOps, en Lemoncode disponemos de un magnífico bootcamp impartido por los mejores profesionales.

Espero que te haya ayudado este artículo, seguiremos publicando más, así que: Happy coding 😝, and stay tune!