1~
2Si trabajas en el mundo del desarrollo de software, seguramente has oído hablar de Kubernetes. Pero, ¿qué es exactamente y por qué se ha convertido en el estándar de facto para la gestión de aplicaciones en contenedores? Esta guía te llevará desde los conceptos básicos hasta los fundamentales, con ejemplos prácticos y diagramas para ayudarte a entender.
3~
4## Antes de Kubernetes: Un poco de historia
5~
6Para entender por qué Kubernetes es tan revolucionario, demos un paso atrás.
7~
81.  **Despliegue tradicional**: Inicialmente, las aplicaciones se ejecutaban en servidores físicos. Este enfoque era costoso, difícil de escalar y propenso a conflictos de recursos.
92.  **Despliegue virtualizado**: Luego llegaron las máquinas virtuales (VM). Las VM permitieron ejecutar múltiples aplicaciones aisladas en el mismo hardware, mejorando la utilización de recursos y la seguridad. Sin embargo, cada VM ejecuta un sistema operativo completo, consumiendo muchos recursos.
103.  **Despliegue en contenedores**: Los contenedores (como Docker) son la siguiente evolución. Comparten el mismo sistema operativo anfitrión pero ejecutan procesos aislados. Son ligeros, rápidos de iniciar y portátiles.
11~
12Los contenedores resolvieron el problema de la portabilidad, pero crearon otro: ¿cómo gestionar cientos (o miles) de contenedores en un entorno de producción? ¿Cómo garantizar que siempre estén en funcionamiento, que puedan comunicarse entre sí y que escalen según la carga?
13~
14Aquí es donde entra en juego **Kubernetes**.
15~
16## ¿Qué es Kubernetes?
17~
18Kubernetes (a menudo abreviado como **K8s**) es una plataforma de código abierto para la orquestación de contenedores. En términos simples, automatiza el despliegue, el escalado y la gestión de aplicaciones en contenedores. Creado por Google y ahora mantenido por la Cloud Native Computing Foundation (CNCF), Kubernetes se ha convertido en la herramienta de referencia para cualquiera que trabaje con microservicios a gran escala.
19~
20## La arquitectura de un clúster de Kubernetes
21~
22Un entorno de Kubernetes se llama **clúster**. Un clúster está compuesto por un conjunto de máquinas, llamadas **nodos**, que ejecutan nuestras aplicaciones. La arquitectura se divide en dos partes principales: el Control Plane y los Worker Nodes.
23~
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32~
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39~
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45~
46    A -- "Se comunica con" --> E
47    A -- "Se comunica con" --> J
48    User -- "kubectl" --> A
49    C -- "Asigna Pods a Nodos" --> E
50    D -- "Mantiene el estado" --> A
51    A -- "Guarda/Lee estado" --> B
52```
53~
54### Control Plane
55~
56El Control Plane es el "cerebro" del clúster. Toma decisiones globales (como la programación) y detecta y responde a los eventos del clúster. Sus componentes principales son:
57~
58-   **API Server (`kube-apiserver`)**: Es la puerta de entrada al clúster. Expone la API de Kubernetes, que es utilizada por los usuarios (a través de `kubectl`), los componentes del clúster y herramientas externas para comunicarse.
59-   **etcd**: Una base de datos clave-valor consistente y de alta disponibilidad. Almacena todos los datos del clúster, representando el estado deseado y actual del sistema.
60-   **Scheduler (`kube-scheduler`)**: Asigna los Pods recién creados a un Worker Node disponible, teniendo en cuenta los requisitos de recursos, las políticas y otras restricciones.
61-   **Controller Manager (`kube-controller-manager`)**: Ejecuta los controladores, que son bucles de control que observan el estado del clúster y trabajan para llevarlo al estado deseado. Por ejemplo, el `Node Controller` gestiona los nodos, mientras que el `Replication Controller` se asegura de que se esté ejecutando el número correcto de Pods.
62~
63### Worker Node
64~
65Los Worker Nodes son las máquinas (físicas o virtuales) donde se ejecutan realmente las aplicaciones. Cada nodo es gestionado por el Control Plane y contiene los siguientes componentes:
66~
67-   **Kubelet**: Un agente que se ejecuta en cada nodo. Se asegura de que los contenedores descritos in los Pods se estén ejecutando y estén en buen estado.
68-   **Kube-proxy**: Un proxy de red que gestiona las reglas de red en los nodos. Permite la comunicación de red hacia los Pods desde sesiones de red dentro o fuera del clúster.
69-   **Container Runtime**: El software responsable de ejecutar los contenedores. Docker es el más famoso, pero Kubernetes también soporta otros runtimes como `containerd` y `CRI-O`.
70~
71## Objetos fundamentales de Kubernetes
72~
73En Kubernetes, todo se representa mediante **objetos**. Estos objetos son "registros de intención": una vez que creas un objeto, Kubernetes trabaja constantemente para asegurar que exista y coincida con el estado deseado.
74~
75Aquí están los más importantes:
76~
77### Pod
78~
79El **Pod** es la unidad de ejecución más pequeña en Kubernetes. Representa uno o más contenedores que se ejecutan juntos en el mismo nodo, compartiendo recursos como la red y el almacenamiento.
80~
81Generalmente, se ejecuta un solo contenedor por Pod, pero en escenarios avanzados (como los "contenedores sidecar" para el registro o la monitorización), puedes tener más.
82~
83Casi nunca creas Pods directamente. Usas abstracciones de nivel superior como los Deployments.
84~
85### Deployment
86~
87Un **Deployment** es el objeto que usarás más a menudo. Describe el estado deseado para un grupo de Pods idénticos. El controlador del Deployment es responsable de:
88~
89-   Crear y gestionar un **ReplicaSet** (otro objeto que asegura que un número específico de réplicas de un Pod esté siempre en ejecución).
90-   **Escalar** el número de Pods hacia arriba o hacia abajo.
91-   Gestionar las **actualizaciones** de la aplicación de manera controlada (p. ej., *Rolling Update*), sin tiempo de inactividad.
92~
93Aquí hay un archivo YAML de ejemplo para un Deployment que ejecuta 3 réplicas de un servidor NGINX:
94~
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117~
118### Service
119~
120Los Pods en Kubernetes son efímeros: pueden ser creados y destruidos en cualquier momento. Cada Pod tiene su propia dirección IP, pero esta IP no es estable. Entonces, ¿cómo exponemos nuestra aplicación de manera fiable?
121~
122Con un **Service**. Un Service es una abstracción que define un conjunto lógico de Pods y una política para acceder a ellos. Proporciona un **punto de acceso estable** (una dirección IP virtual y un nombre DNS) para un grupo de Pods.
123~
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129~
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135~
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139~
140    Client -- "Petición a nginx-service" --> A
141```
142~
143El Service utiliza un `selector` basado en `labels` para encontrar los Pods a los que debe dirigir el tráfico.
144~
145Aquí se muestra cómo crear un Service para nuestro Deployment de NGINX:
146~
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Por defecto - expone el servicio solo dentro del clúster
161```
162~
163Hay diferentes tipos de Services:
164- `ClusterIP`: Expone el servicio en una IP interna del clúster (por defecto).
165- `NodePort`: Expone el servicio en un puerto estático en cada Worker Node.
166- `LoadBalancer`: Crea un balanceador de carga externo en el proveedor de la nube (p. ej., AWS, GCP) y asigna una IP pública al servicio.
167~
168### Ingress
169~
170Un Service de tipo `LoadBalancer` es genial, pero crear uno para cada servicio puede ser costoso. Para exponer múltiples servicios HTTP/HTTPS al mundo exterior, se utiliza un **Ingress**.
171~
172Un Ingress actúa como un "enrutador inteligente" para el tráfico externo. Permite definir reglas de enrutamiento basadas en el host (p. ej., `api.misitio.com`) o la ruta (p. ej., `misitio.com/api`).
173~
174```mermaid
175graph LR
176    User -- "misitio.com/api" --> Ingress
177    User -- "misitio.com/ui" --> Ingress
178~
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182~
183        ServiceA --> PodA1("Pod API 1")
184        ServiceA --> PodA2("Pod API 2")
185~
186        ServiceB --> PodB1("Pod UI 1")
187        ServiceB --> PodB2("Pod UI 2")
188    end
189```
190~
191Aquí hay un ejemplo de un Ingress:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: misitio.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218~
219### Otros objetos útiles
220~
221-   **Namespace**: Permite crear "clústeres virtuales" dentro de un clúster físico. Útil para aislar entornos (p. ej., `development`, `staging`, `production`) o equipos.
222-   **ConfigMap y Secret**: Para gestionar datos de configuración y secretos (como contraseñas o claves de API) desacoplados de la imagen del contenedor.
223-   **StatefulSet**: Similar a un Deployment, pero específico para aplicaciones con estado (como bases de datos) que requieren identidades de red estables y almacenamiento persistente.
224-   **PersistentVolume (PV) y PersistentVolumeClaim (PVC)**: Para gestionar el almacenamiento persistente en el clúster.
225~
226## Conclusión
227~
228Kubernetes es una herramienta increíblemente poderosa, pero su curva de aprendizaje puede ser pronunciada. Esta guía solo ha arañado la superficie, pero esperamos que te haya dado una sólida comprensión de los conceptos básicos.
229~
230**¿Qué hacer ahora?**
231- **Experimenta localmente**: Instala [Minikube](https://minikube.sigs.k8s.io/docs/start/) o [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) para crear un clúster de Kubernetes en tu ordenador.
232- **Usa `kubectl`**: Familiarízate con el comando `kubectl`, tu herramienta principal para interactuar con el clúster. Intenta crear el Deployment y el Service de NGINX de este artículo.
233- **Explora los tutoriales oficiales**: La [documentación de Kubernetes](https://kubernetes.io/docs/tutorials/) es un recurso fantástico lleno de ejemplos.
234~
235La orquestación de contenedores es una habilidad fundamental en el mundo nativo de la nube, y dominar Kubernetes te abrirá un mundo de posibilidades. ¡Diviértete!