¿Qué es Kubernetes (K8s)?

Kubernetes es una plataforma open-source que automatiza el deploy, el escalado y la operación de aplicaciones contenedorizadas en muchas máquinas. Su idea central es declarativa: declaras el estado final deseado — tres réplicas de este contenedor, esta cantidad de memoria, accesible en este puerto — y el sistema trabaja continuamente para que la realidad coincida, reiniciando, reprogramando y escalando sin que nadie se lo pida.

Puntos clave

El manifiesto: cómo le hablas a Kubernetes

Todo es una declaración. Este es un Deployment mínimo y real — anotado en palabras simples:

apiVersion: apps/v1
kind: Deployment              # "mantén N copias de esto corriendo"
metadata:
  name: api
spec:
  replicas: 3                 # el estado deseado: tres pods
  selector:
    matchLabels: { app: api }
  template:                   # lo que contiene cada pod
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports: [{ containerPort: 8080 }]
          resources:
            limits: { memory: "256Mi", cpu: "500m" }
# Aplícalo, mata un pod y mira a Kubernetes resucitarlo. Ese es el producto.

Como contraste — el mismo resultado (un backend desplegado, escalado y con auto-reparación) consumido como servicio, donde el manifiesto, el clúster y la reconciliación a las 3 de la mañana son el YAML de otra persona:

// JavaScript / Node.js — Back4app JS SDK
// The workload the manifest would have described — already running
const status = await Parse.Cloud.run('healthCheck');
console.log(status); // scheduling, scaling, restarts: the platform's job

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('healthCheck');
final response = await function.execute();
if (response.success) {
  print(response.result); // no pods, no manifests, no cluster to run
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("healthCheck") { result in
  if case .success(let status) = result {
    print(status) // no pods, no manifests, no cluster to run
  }
}

// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("healthCheck", hashMapOf()) { status, e ->
  if (e == null) Log.d("Health", status) // no pods, no manifests, no cluster
}

Dentro de un clúster

El vocabulario, una línea cada uno: un clúster es el sistema completo; un nodo es una máquina; un pod es la unidad desplegable más pequeña (uno o más contenedores que comparten red y almacenamiento); un Deployment gestiona pods replicados con rolling updates y rollbacks; un Service les da a los pods efímeros una dirección estable; un Ingress enruta el tráfico externo hacia adentro; los ConfigMaps y Secrets llevan la configuración; los namespaces particionan un clúster entre equipos. La visión general oficial es el siguiente escalón canónico.

Kubernetes vs. Docker

La confusión perenne tiene fecha: desde la v1.24 (2022), Kubernetes eliminó su shim de runtime específico de Docker y habla solo con runtimes de contenedores estándar. Nada se rompió — las imágenes siguen el estándar abierto OCI — pero los roles quedaron nítidos: Docker es el astillero, Kubernetes es la autoridad portuaria. El nombre lo supo siempre: kubernetes es “timonel” en griego — el proyecto fue liberado en junio de 2014, llegó a la 1.0 en 2015 y dio origen a la CNCF, destilando una década de operación de contenedores a escala de flota en un bien común público.

Casos de uso comunes

• Flotas de microservicios. Decenas de servicios con escalado y deploys independientes — la carga de trabajo que moldeó a Kubernetes.
• Equipos de plataforma. Construir una plataforma interna sobre un sustrato que corre de forma idéntica en cualquier nube u on-premises.
• Cargas de gran escala con picos. Jobs por lotes, pipelines de datos, entrenamiento de ML — bin-packing sobre capacidad compartida.
• Estrategias multi-cloud y de portabilidad. La capa de cómputo de una defensa contra el vendor lock-in — con la salvedad de que los servicios gestionados de alrededor siguen atando.
• Parques de producción con auto-reparación. Donde “una máquina murió a las 3 de la mañana” debe ser un no-evento y no una alerta que te despierta.

¿Deberías correr Kubernetes? Matriz de decisión

El consenso silencioso de la industria: la mayoría de los equipos que operan Kubernetes está por debajo de la escala en la que se paga. La escalera de alternativas — un host con un archivo compose, un servicio gestionado de contenedores, un PaaS, un BaaS — cubre todo hasta los problemas genuinos de flota, y el Kubernetes gestionado cubre la mayor parte de lo que queda.

Limitaciones y trade-offs

• La curva de aprendizaje es la sombra del producto. Pods, services, ingress, RBAC, operators, Helm — la fluidez se mide en meses, y el clúster no espera.
• Superficie operativa. Los upgrades, la rotación de certificados, los plugins de red y la salud del almacén de estado no perdonan; por eso ganaron los control planes gestionados.
• Sprawl de YAML. La configuración declarativa a escala se convierte en su propia base de código, con sus propias revisiones, bugs y deriva.
• Orquesta contenedores, no arquitectura. Un sistema mal delimitado sobre Kubernetes es el mismo sistema, ahora distribuido — el clúster amplifica el diseño, bueno o malo.
• Kubernetes no es un PaaS. Por diseño no trae CI/CD, ni base de datos por defecto, ni servicios a nivel de aplicación — la plataforma de encima la armas tú, que es precisamente el trabajo que las abstracciones más altas venden de vuelta como producto.

Kubernetes en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La relación con Kubernetes es una división honesta del trabajo: lo que la mayoría de los equipos de aplicación realmente quiere de un clúster — servicios de backend desplegados, escalados y con auto-reparación — es exactamente lo que la capa BaaS entrega con cero manifiestos que escribir. Y para las cargas que genuinamente son contenedores, Back4app Containers las corre como servicio gestionado: envía una imagen, obtén orquestación, sin ser dueño del puerto.