Arquitectura de clúster de Kubernetes

Introducción

En este laboratorio, exploraremos la arquitectura de Kubernetes, una potente plataforma de orquestación de contenedores. Examinaremos los componentes clave que conforman un clúster de Kubernetes y aprenderemos cómo interactúan para gestionar aplicaciones contenerizadas. Este laboratorio está diseñado para principiantes, brindando una introducción práctica a la arquitectura de Kubernetes.

Explora los componentes del plano de control

Comencemos iniciando un clúster de Kubernetes utilizando Minikube y examinando los componentes del plano de control.

Primero, abre tu terminal. Por defecto, debes estar en el directorio /home/labex/project. Si no es así, navega hasta allí:

cd ~/project

Ahora, inicia Minikube con el siguiente comando:

minikube start

Este comando inicializa un clúster de Kubernetes de un solo nodo en tu máquina local. Puede tardar unos minutos en completarse. No te preocupes si ves mucha salida – esto es normal.

Una vez que Minikube haya iniciado, exploremos los componentes del plano de control. El plano de control es el cerebro de Kubernetes, responsable de gestionar el estado general del clúster. Para verificar el estado de estos componentes, ejecuta:

kubectl get componentstatuses

Deberías ver una salida similar a esta:

NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health":"true"}

Analicemos lo que hace cada uno de estos componentes:

El scheduler (programador): Este componente monitorea los Pods recién creados sin nodo asignado y selecciona un nodo en el que se ejecutarán.
El controller manager (gestor de controladores): Este ejecuta procesos de controlador, que regulan el estado del sistema. Por ejemplo, el controlador de replicación asegura que se estén ejecutando el número correcto de réplicas de Pod.
etcd: Este es un almacén de pares clave-valor distribuido que actúa como el almacén de respaldo de Kubernetes para todos los datos del clúster.

Si todos los componentes muestran "Healthy" (Sano), tu plano de control está funcionando correctamente. Si ves algún error, puede valer la pena reiniciar Minikube con minikube delete seguido de minikube start.

Examinando los componentes de los nodos

Ahora que hemos analizado el plano de control, examinemos los componentes de los nodos. En Kubernetes, los nodos son las máquinas trabajadoras que ejecutan tus aplicaciones. Puedes pensar en ellos como los músculos de tu clúster, que se encargan de realizar el trabajo pesado de ejecutar los contenedores.

Para ver los nodos en tu clúster, ejecuta:

kubectl get nodes

Deberías ver una salida similar a esta:

NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    control plane   10m   v1.20.0

Esta salida muestra que tenemos un nodo llamado "minikube" que es tanto un nodo maestro (plano de control) como un nodo trabajador, ya que estamos utilizando un clúster de un solo nodo. En un entorno de producción, normalmente tendrías múltiples nodos, con nodos maestros y nodos trabajadores separados.

El estado "Ready" (Listo) significa que el nodo está saludable y listo para aceptar Pods.

Para obtener información más detallada sobre el nodo, utiliza:

kubectl describe node minikube

Este comando proporciona una gran cantidad de información sobre el nodo. No te preocupes si parece abrumador, analicemos algunas secciones clave:

Node Conditions (Condiciones del nodo): Estas muestran el estado de varias condiciones del nodo (por ejemplo, Ready, DiskPressure, MemoryPressure).
Capacity (Capacidad): Esto muestra los recursos totales disponibles en el nodo (CPU y memoria).
Allocatable (Asignable): Esto muestra los recursos disponibles para que los Pods los utilicen.
System Info (Información del sistema): Esto proporciona información sobre el sistema operativo del nodo, la versión del kernel y el entorno de ejecución de contenedores.

Los componentes clave del nodo, que no verás directamente pero que se están ejecutando en el nodo, incluyen:

kubelet: Este es el agente principal del nodo. Vigila los Pods que se le han asignado y se asegura de que estén en ejecución.
kube-proxy: Este mantiene las reglas de red en el nodo, permitiendo la comunicación de red con tus Pods desde dentro o fuera de tu clúster.

Creando y examinando un Pod

Antes de sumergirnos, entendamos cómo funciona YAML en Kubernetes:

graph TB
    A[YAML Config File] -->|Declares Desired State| B[Kubernetes API]
    B -->|Creates/Manages| C[Running Containers]
    D[kubectl CLI] -->|Reads| A

Los archivos YAML en Kubernetes actúan como "Infraestructura como Código":

Piénsalo como un "menú" que le dice a Kubernetes lo que quieres.
Describe el estado deseado de tu sistema en un formato legible por humanos.
Puede ser controlado por versiones para la colaboración en equipo.

Creemos nuestro primer archivo YAML. Crea simple-pod.yaml:

nano ~/project/simple-pod.yaml

Agrega el siguiente contenido:

## --- Beginning of YAML file ---
## 1. Tell Kubernetes which API version to use
apiVersion: v1
## 2. Declare what kind of resource we want to create
kind: Pod
## 3. Set metadata for this resource
metadata:
  name: nginx-pod ## Name of the Pod
  labels: ## Labels help us find and organize Pods
    app: nginx
## 4. Define what the Pod should contain
spec:
  containers: ## Pod can run one or more containers
    - name: nginx ## Name of the container
      image: nginx:latest ## Which container image to use
      ports: ## Which ports to expose
        - containerPort: 80 ## Nginx uses port 80 by default

La estructura del archivo YAML es como un árbol:

Pod (root)
├── metadata (branch)
│   ├── name (leaf)
│   └── labels (leaf)
└── spec (branch)
    └── containers (branch)
        └── - name, image, ports (leaves)

Crea el Pod:

kubectl apply -f simple-pod.yaml ## -f means read from file

Este comando hará lo siguiente:

Leerá tu archivo YAML.
Lo enviará a la API de Kubernetes.
Kubernetes trabajará para alcanzar el estado que has descrito.

Verifica la creación del Pod:

kubectl get pods

Deberías ver:

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          30s

El "1/1" debajo de READY significa que uno de uno contenedores en el Pod está listo. "Running" (En ejecución) debajo de STATUS significa que tu primera configuración YAML funcionó.

💡 Consejos profesionales:

La indentación en YAML es crucial: usa espacios, no tabulaciones.

Utiliza kubectl explain pod para ver la documentación de los campos.

Siempre agrega comentarios para una mejor mantenibilidad.

Para obtener información detallada sobre el pod:

kubectl describe pod nginx-pod

Este comando proporciona mucha información, incluyendo:

El nodo en el que se está ejecutando el Pod.
La dirección IP del Pod.
Los contenedores en el Pod.
Los eventos recientes relacionados con el Pod.

Esta información es crucial para la depuración y la comprensión del estado de tu aplicación.

Creando un servicio

Ahora que tenemos un pod en ejecución, creemos un Servicio para exponerlo. En Kubernetes, un Servicio es una abstracción que define un conjunto lógico de Pods y una política para acceder a ellos. Piénsalo como una forma de exponer tu aplicación a la red, ya sea dentro del clúster o externamente.

Crea un archivo llamado nginx-service.yaml en tu directorio de proyecto:

nano ~/project/nginx-service.yaml

Agrega el siguiente contenido al archivo:

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

Analicemos este archivo YAML:

selector: Esto determina a qué Pods enviará tráfico el Servicio. En este caso, seleccionará cualquier Pod con la etiqueta app: nginx.
ports: Esto especifica qué puertos debe utilizar el Servicio.
type: NodePort: Esto significa que el Servicio será accesible en un puerto en cada nodo de tu clúster.

Guarda el archivo y sal del editor.

Ahora, crea el servicio ejecutando:

kubectl apply -f nginx-service.yaml

Para verificar el estado de tu servicio, utiliza:

kubectl get services

Deberías ver una salida similar a esta:

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        1h
nginx-service   NodePort    10.110.126.65   <none>        80:30080/TCP   30s

La línea nginx-service muestra que tu servicio se ha creado. 80:30080/TCP debajo de PORT(S) significa que el puerto 80 dentro del clúster está mapeado al puerto 30080 en el nodo.

Para obtener información más detallada sobre el servicio, utiliza:

kubectl describe service nginx-service

Este comando proporciona información sobre el tipo de servicio, las direcciones IP, los puertos y los puntos finales. Los puntos finales son las direcciones IP de los Pods a los que el Servicio está enviando tráfico.

Accediendo a la aplicación

Ahora que tenemos un pod ejecutando nuestra aplicación y un servicio que la expone, accedamos a la aplicación. Este paso te mostrará cómo todos los componentes que hemos configurado trabajan juntos para hacer que tu aplicación sea accesible.

Primero, necesitamos averiguar la URL que Minikube ha asignado a nuestro servicio:

minikube service nginx-service --url

Este comando mostrará una URL, que debería tener un aspecto similar a http://192.168.64.2:30080. La dirección IP puede ser diferente en tu máquina.

Para acceder a la aplicación, puedes usar el comando curl seguido de la URL:

curl $(minikube service nginx-service --url)

Esto debería devolver el HTML de la página de bienvenida predeterminada de Nginx. Si ves una salida HTML que comienza con <!DOCTYPE html>, ¡felicidades! Has accedido con éxito a tu aplicación.

Analicemos lo que acaba de suceder:

Tu solicitud primero alcanzó el servicio NodePort que creamos.
El servicio luego reenvió la solicitud al Pod que ejecuta el contenedor Nginx.
El contenedor Nginx procesó la solicitud y envió de vuelta la página de bienvenida predeterminada.

Esto demuestra cómo Kubernetes abstrae la infraestructura subyacente, lo que te permite centrarte en tu aplicación en lugar de preocuparte por en qué máquina específica se está ejecutando.

Resumen

En este laboratorio, exploramos la arquitectura de Kubernetes examinando sus componentes clave y sus interacciones. Iniciamos un clúster de Kubernetes utilizando Minikube, inspeccionamos el plano de control y los componentes de los nodos, creamos un pod para ejecutar una aplicación, exponemos la aplicación mediante un servicio y, finalmente, accedimos a la aplicación.

graph TB
    subgraph Control Plane
        API[API Server]
        CM[Controller Manager]
        SCH[Scheduler]
        ETCD[etcd]
        API --> ETCD
        API --> CM
        API --> SCH
    end

    subgraph Worker Node
        KL[kubelet]
        KP[kube-proxy]
        CR[Container Runtime]

        subgraph Workloads
            POD1[Pod]
            POD2[Pod]
        end

        SVC[Service]

        KL --> CR
        POD1 --> CR
        POD2 --> CR
        KP --> SVC
        SVC --> POD1
        SVC --> POD2
    end

    API --> KL
    Client[External Client] --> SVC

Aprendimos sobre:

Componentes del plano de control como el servidor API, el programador (scheduler) y el administrador de controladores (controller manager).
Componentes de los nodos como kubelet y kube-proxy.
Los Pods como las unidades desplegables más pequeñas en Kubernetes.
Los Servicios como una forma de exponer aplicaciones.

Esta experiencia práctica proporciona una base sólida para entender la arquitectura de Kubernetes. Recuerda, Kubernetes es un sistema complejo con muchas partes en movimiento, y está bien si no entiendes todo de inmediato. A medida que sigas trabajando con Kubernetes, estos conceptos se volverán más familiares e intuitivos.

Los próximos pasos en tu viaje con Kubernetes podrían incluir aprender sobre los Despliegues (Deployments) para gestionar múltiples réplicas de tu aplicación, los ConfigMaps y los Secretos para gestionar la configuración, y los Volúmenes Persistentes para el almacenamiento de datos. Sigue explorando y que disfrutes trabajando con Kubernetes.