Capitulo 2: Conceptos de Kubernetes

< Volver al Indice del Tutorial

Por que Entender los Conceptos Primero

K3s es Kubernetes. Aunque la instalacion es mas simple, los recursos y la API son identicos. Antes de crear tu primer cluster necesitas entender los bloques fundamentales con los que vas a trabajar.

Pod

Un Pod es la unidad minima de ejecucion en Kubernetes. Contiene uno o mas contenedores que comparten:

• Red: Todos los contenedores del pod comparten la misma IP y pueden comunicarse via localhost.
• Storage: Pueden montar los mismos volumenes.
• Ciclo de vida: Se crean y destruyen juntos.

En la practica, la mayoria de pods tienen un solo contenedor. Se usan multiples contenedores cuando necesitas un sidecar (por ejemplo, un proxy o un colector de logs junto a tu aplicacion).

apiVersion: v1
kind: Pod
metadata:
  name: mi-app
spec:
  containers:
    - name: web
      image: nginx:alpine
      ports:
        - containerPort: 80

Los pods son efimeros. Si un pod muere, no se recrea automaticamente. Para eso necesitas un controlador como un Deployment.

ReplicaSet

Un ReplicaSet garantiza que un numero especificado de replicas de un pod estan corriendo en todo momento.

• Si un pod muere, el ReplicaSet crea uno nuevo.
• Si hay pods de mas, el ReplicaSet elimina los sobrantes.
• Define un selector para identificar que pods gestiona.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: mi-app-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mi-app
  template:
    metadata:
      labels:
        app: mi-app
    spec:
      containers:
        - name: web
          image: nginx:alpine

En la practica raramente creas ReplicaSets directamente. Los Deployments los gestionan por ti.

Deployment

Un Deployment es la forma declarativa de gestionar aplicaciones. Crea y gestiona ReplicaSets automaticamente y permite:

• Rollouts graduales: Actualiza pods de forma progresiva sin downtime.
• Rollbacks: Revierte a una version anterior si algo falla.
• Escalado: Cambia el numero de replicas con un comando.
• Historial: Mantiene un registro de versiones desplegadas.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mi-app
  template:
    metadata:
      labels:
        app: mi-app
    spec:
      containers:
        - name: web
          image: mi-app:v1.0
          ports:
            - containerPort: 8080

Cuando cambias la imagen de v1.0 a v2.0, el Deployment crea un nuevo ReplicaSet con la nueva version y reduce gradualmente el anterior. Si la nueva version falla, ejecutas kubectl rollout undo y vuelves al estado anterior.

Service

Un Service expone un grupo de pods como un endpoint de red estable. Los pods son efimeros y sus IPs cambian, pero el Service mantiene una IP fija y un nombre DNS.

Tipos de Service

ClusterIP (por defecto): Accesible solo dentro del cluster. Util para comunicacion entre microservicios.

apiVersion: v1
kind: Service
metadata:
  name: mi-app-svc
spec:
  type: ClusterIP
  selector:
    app: mi-app
  ports:
    - port: 80
      targetPort: 8080

NodePort: Expone el servicio en un puerto del nodo (rango 30000-32767). Accesible desde fuera del cluster via <IP-nodo>:<NodePort>.

spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

LoadBalancer: Solicita un balanceador de carga externo. En K3s, el ServiceLB integrado maneja este tipo. En cloud, el proveedor asigna una IP publica.

spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Namespace

Un Namespace proporciona aislamiento logico dentro del cluster. Permite separar recursos por equipo, entorno o proyecto.

Namespaces por defecto en K3s:

• default: Donde van los recursos si no especificas namespace.
• kube-system: Componentes del sistema (CoreDNS, Traefik, metrics-server).
• kube-public: Recursos publicos accesibles sin autenticacion.
• kube-node-lease: Heartbeats de los nodos.

kubectl create namespace staging
kubectl get pods -n staging
kubectl get pods --all-namespaces

Los nombres de recursos deben ser unicos dentro de un namespace, pero puedes tener el mismo nombre en namespaces diferentes.

ConfigMap y Secret

ConfigMap

Almacena configuracion no sensible como pares clave-valor. Permite externalizar la configuracion de tus contenedores.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "postgres-svc"
  LOG_LEVEL: "info"
  APP_PORT: "8080"

Se puede montar como variables de entorno o como archivos dentro del contenedor.

Secret

Similar a ConfigMap pero para datos sensibles. Los valores se almacenan codificados en base64 (no encriptados por defecto).

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=
  API_KEY: bWktYXBpLWtleS1zZWNyZXRh

En produccion debes habilitar encriptacion at rest o usar un gestor de secretos externo como Vault.

Volume

Los contenedores tienen un filesystem efimero: cuando el pod muere, los datos se pierden. Un Volume proporciona almacenamiento que persiste mas alla del ciclo de vida del contenedor.

PersistentVolume (PV)

Recurso de almacenamiento provisionado por un administrador o dinamicamente por un StorageClass.

PersistentVolumeClaim (PVC)

Solicitud de almacenamiento por parte de un usuario. Kubernetes vincula el PVC con un PV disponible que cumpla los requisitos.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: datos-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

En K3s, el local-path provisioner crea PVs automaticamente cuando se solicita un PVC. Los datos se almacenan en /var/lib/rancher/k3s/storage/ del nodo.

Ingress

Un Ingress define reglas de routing HTTP/HTTPS desde el exterior hacia los Services del cluster. Requiere un Ingress Controller para funcionar; K3s incluye Traefik por defecto.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mi-app-ingress
spec:
  rules:
    - host: app.ejemplo.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: mi-app-svc
                port:
                  number: 80

Con esta configuracion, las peticiones a app.ejemplo.com se enrutan al Service mi-app-svc.

Relacion entre Recursos

  ┌──────────────────────────────────────────────────────────┐
  │                      Namespace                           │
  │                                                          │
  │   ┌─────────────┐                                       │
  │   │  ConfigMap   │──────────┐                            │
  │   └─────────────┘          │                            │
  │   ┌─────────────┐          v                            │
  │   │   Secret    │───> ┌──────────┐    ┌──────────────┐  │
  │   └─────────────┘     │Deployment│───>│  ReplicaSet  │  │
  │                       └──────────┘    └──────┬───────┘  │
  │                                              │          │
  │                              ┌───────────────┼───────┐  │
  │                              │               │       │  │
  │   ┌──────────┐          ┌────┴──┐  ┌────────┴┐  ┌───┴┐ │
  │   │  Volume  │<─────────│ Pod 1 │  │  Pod 2  │  │Pod3│ │
  │   │  (PVC)   │          └───────┘  └─────────┘  └────┘ │
  │   └──────────┘               ^          ^          ^    │
  │                              │          │          │    │
  │                           ┌──┴──────────┴──────────┴─┐  │
  │   ┌─────────┐            │        Service            │  │
  │   │ Ingress │──────────> │     (IP estable + DNS)    │  │
  │   └─────────┘            └──────────────────────────┘  │
  │       ^                                                 │
  │       │                                                 │
  └───────┼─────────────────────────────────────────────────┘
          │
      Internet

El flujo tipico es:

1. El Deployment crea un ReplicaSet que mantiene N Pods corriendo.
2. Los Pods reciben configuracion de ConfigMaps y Secrets.
3. Los Pods almacenan datos en Volumes (via PVC).
4. Un Service agrupa los Pods y les da un endpoint estable.
5. Un Ingress expone el Service al trafico externo.
6. Todo vive dentro de un Namespace que proporciona aislamiento.

Modelo Declarativo

Kubernetes usa un modelo declarativo: describes el estado deseado y los controladores se encargan de alcanzarlo y mantenerlo.

No dices “crea 3 pods”. Dices “quiero 3 replicas de esta aplicacion” y Kubernetes crea, destruye o recrea pods segun sea necesario para mantener ese estado. Si un nodo muere y se pierden 2 pods, Kubernetes automaticamente crea 2 nuevos en nodos disponibles.

Este principio aplica a todos los recursos: Services, Ingress, Volumes y cualquier objeto de Kubernetes.

---

Siguiente: Capitulo 3: Instalacion —>