---
term: 'Kubernetes'
seoTitle: '¿Qué es Kubernetes (K8s)? Guía Completa'
headline: '¿Qué es Kubernetes (K8s)?'
slug: kubernetes
category: cloud-architecture
shortDefinition: 'Kubernetes es una plataforma open-source que automatiza el deploy, el escalado y la operación de aplicaciones contenedorizadas en muchas máquinas.'
relatedTerms:
  - containerization
  - infrastructure-as-a-service
  - microservices-vs-monolith
  - no-ops-development
  - ci-cd
contrastsWith:
  - no-ops-development
faq:
  - question: '¿Qué es Kubernetes en términos simples?'
    answer: 'Un director de orquesta para contenedores. Declaras lo que debería estar corriendo — esta app, tres copias, esta cantidad de memoria — y Kubernetes hace que la realidad coincida de forma continua: colocando contenedores en las máquinas, reiniciándolos cuando fallan, escalándolos con la carga y enrutando el tráfico hacia las copias sanas. Convierte una flota de máquinas en un único pool programable.'
  - question: '¿Qué significa K8s?'
    answer: 'Es un numerónimo: K, luego ocho letras, luego s — el mismo patrón de i18n para internacionalización. El nombre en sí es griego: kubernetes significa timonel o piloto, la persona que dirige el barco, y por eso tantas herramientas de su ecosistema llevan nombres náuticos y el logotipo es un timón.'
  - question: '¿Kubernetes es lo mismo que Docker?'
    answer: 'No — responden preguntas distintas. Docker construye y corre contenedores individuales en una máquina; Kubernetes orquesta muchos contenedores en muchas máquinas. Son complementarios: las imágenes construidas con Docker corren en clústeres de Kubernetes. Desde la versión 1.24, Kubernetes ya no usa a Docker como runtime — habla con cualquier runtime de contenedores estándar — pero las imágenes hechas con Docker funcionan igual que antes, porque siguen el estándar abierto OCI.'
  - question: '¿Qué son un clúster, un nodo y un pod?'
    answer: 'El clúster es el sistema completo: un control plane más las máquinas worker. Un nodo es una máquina de ese sistema, física o virtual. Un pod es la unidad desplegable más pequeña — uno o más contenedores fuertemente acoplados que comparten identidad de red y almacenamiento. Casi nunca corres un pod suelto: declaras un Deployment, y Kubernetes gestiona los pods por ti.'
  - question: '¿Qué es el control plane de Kubernetes?'
    answer: 'El cerebro del clúster: un API server por el que todo conversa, un almacén clave-valor con el estado deseado y el estado real del clúster, un scheduler que decide en qué nodo aterriza cada pod y controllers que reconcilian continuamente la realidad con las declaraciones. Los nodos worker corren un agente, un proxy de red y el runtime de contenedores que de verdad ejecuta los pods.'
  - question: '¿Quién creó Kubernetes y cuándo?'
    answer: 'Se liberó como open source en junio de 2014, nacido de más de una década de experiencia interna en orquestación de contenedores en una de las mayores empresas de tecnología, y alcanzó la versión 1.0 en julio de 2015 — cuando fue donado a la recién creada Cloud Native Computing Foundation (CNCF). Escrito en Go, se ha convertido desde entonces en uno de los proyectos open-source más grandes del mundo.'
  - question: '¿Cuándo es Kubernetes demasiado?'
    answer: 'Más seguido de lo que el hype admite. Un equipo pequeño que corre un puñado de contenedores con tráfico predecible gana poco con un clúster y hereda una curva de aprendizaje empinada, sprawl de YAML y una disciplina operativa diseñada para problemas a escala de flota. Caminos más simples — un archivo compose en un host, una plataforma gestionada de contenedores, un PaaS o un BaaS — cubren la mayoría de las cargas por debajo de una escala seria.'
  - question: '¿Qué es Kubernetes gestionado?'
    answer: 'Un servicio de nube que corre el control plane por ti — upgrades, disponibilidad, almacén de estado — mientras tú gestionas las cargas y los pools de nodos. Elimina la capa operativa más difícil y es como corre en realidad la mayor parte del Kubernetes en producción. Autogestionar un clúster de punta a punta sigue siendo territorio de equipos de plataforma con expertise dedicada; el control plane es infraestructura que no perdona.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Kubernetes documentation — Overview'
    url: 'https://kubernetes.io/docs/concepts/overview/'
  - name: 'Kubernetes components (kubernetes.io)'
    url: 'https://kubernetes.io/docs/concepts/overview/components/'
  - name: 'Cloud Native Computing Foundation — Kubernetes'
    url: 'https://www.cncf.io/projects/kubernetes/'
  - name: 'Kubernetes (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Kubernetes'
cta:
  title: 'El backend sin el clúster'
  text: 'Back4app te da lo que la mayoría de los equipos realmente quiere de Kubernetes — servicios de backend desplegados, escalados y con auto-reparación — sin operar uno: base de datos gestionada, autenticación, APIs y funciones Cloud Code. Y cuando de verdad tengas un contenedor, Back4app Containers lo corre por ti.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-27'
translationKey: kubernetes
---

**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

| Pregunta | Respuesta |
| --- | --- |
| Qué es | Un sistema de control que convierte muchas máquinas en un único pool para contenedores |
| La idea central | Declara el estado deseado; el clúster reconcilia la realidad con él, para siempre |
| vs. Docker | Docker construye y corre contenedores; Kubernetes orquesta flotas de ellos |
| Nombre | "Timonel" en griego; K8s = K + ocho letras + s |
| La advertencia honesta | Poder a escala de flota, complejidad a escala de flota — muchos equipos no necesitan ninguno de los dos |

## 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:

```yaml
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:**

```javascript
// 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
// 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
}
```

**Swift:**

```swift
// 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
  }
}
```

**Kotlin:**

```kotlin
// 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

```mermaid
flowchart TB
  accTitle: Arquitectura de un clúster de Kubernetes
  accDescr: Un control plane con API server, almacén de estado, scheduler y controllers gestiona los nodos worker; cada nodo corre un agente, un proxy de red y un runtime de contenedores que hospeda los pods.
  subgraph CP["Control plane — el cerebro"]
    a["API server"] --- b["Almacén de estado"]
    a --- c["Scheduler"]
    a --- d["Controllers<br/>(reconcilian deseado vs. real)"]
  end
  subgraph N1["Nodo worker"]
    e["Agente + proxy de red"] --> f["Pods<br/>(contenedores)"]
  end
  subgraph N2["Nodo worker"]
    g["Agente + proxy de red"] --> h["Pods"]
  end
  CP --> N1
  CP --> N2
```

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](https://kubernetes.io/docs/concepts/overview/) es el siguiente escalón canónico.

## Kubernetes vs. Docker

| Pregunta | Docker | Kubernetes |
| --- | --- | --- |
| Trabajo | Construir, empaquetar y correr contenedores | Orquestar contenedores entre máquinas |
| Alcance | Una máquina | Un clúster |
| Unidad | Contenedor | Pod (de contenedores) |
| Escalado | Manual | Declarativo y automático |
| Relación | Construye las imágenes | Las corre — vía cualquier runtime OCI estándar |

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](https://www.cncf.io/projects/kubernetes/), 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](/glossary/es/vendor-lock-in-en-la-nube/) — 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

| Corre Kubernetes cuando… | Sáltatelo cuando… |
| --- | --- |
| Muchos servicios, muchos equipos, escalado independiente | Una app, un equipo, carga predecible |
| Un equipo de plataforma es dueño del clúster como producto | Nadie es dueño de ops a tiempo completo |
| La portabilidad entre nubes es un requisito duro | La velocidad de lanzamiento es el único requisito |
| Las cargas están contenedorizadas y tienen forma de flota | Las necesidades de backend son CRUD + auth estándar |
| Superaste las orquestaciones más simples | Un archivo compose o una plataforma gestionada todavía alcanza |

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](https://www.back4app.com/container-as-a-service) las corre como servicio gestionado: envía una imagen, obtén orquestación, sin ser dueño del puerto.