Saltar al contenido
Tecnología

K3s vs K8s: cuándo conviene cada uno

Imagen de portada: K3s vs K8s

Ilustración generada con IA como portada del post.

K3s es una distribución ligera de Kubernetes creada por Rancher Labs. K8s es el Kubernetes estándar de toda la vida. Mismas APIs, mismo modelo operativo, pero distinto perfil de consumo y de complejidad. La decisión entre uno y otro no es técnica en abstracto — es una decisión de dónde corre el cluster, cuántos recursos hay, y qué se le pide al sistema.

Lo que pasó

El artículo de IONOS que motivó este post ordena las diferencias en seis puntos clave — y deja explícito que K3s no es una versión recortada de Kubernetes, sino una distribución diferente con el mismo API surface. La regla de oro: si necesitás el feature set completo y operás a escala cloud, K8s. Si el recurso es limitado y el cluster corre en edge o en hardware modesto, K3s.

Hay también un patrón híbrido que vale la pena considerar: K3s en edge o desarrollo, K8s en cloud para producción central.

Por qué importa para quien opera infraestructura

Kubernetes se convirtió en el estándar de orquestación de contenedores, pero su footprint no es trivial. Un cluster mínimo viable de K8s requiere varios binarios coordinados, configuración de red, etcd para el estado, y recursos suficientes para correr API server, scheduler y controller manager. Para un Raspberry Pi o un servidor pequeño, esto es directamente inviable.

K3s resuelve eso eliminando los componentes no esenciales y empaquetando todo en un único binario, con SQLite por default en lugar de etcd. La compatibilidad de APIs es completa — un kubectl no sabe la diferencia.

Las preguntas que definen la elección son tres:

  • ¿Cuánta RAM y CPU tiene el nodo? Menos de 4 GB de RAM en el control plane es territorio K3s.
  • ¿El cluster corre en edge, en cloud o en data center? Edge e IoT son territorio K3s; data center y cloud, K8s.
  • ¿Necesitás el feature set completo de K8s out of the box, o podés agregar componentes manualmente? Si lo segundo, K3s es viable; si lo primero, K8s.

Las diferencias concretas

Consumo de recursos. K3s omite controllers no esenciales, ingress controllers estándar y logging extenso. Un cluster K3s consume menos RAM y CPU que uno K8s con el mismo número de nodos workers. K8s está pensado para escalar a cientos de nodos con el feature set completo, y eso cuesta.

Instalación y setup. Un comando único instala K3s (master o multi-node). Incluye container runtime y plugins de red por default. K8s requiere múltiples pasos coordinados: kubelet, kube-proxy, API server, configuración de red, etc. K3s gana por goleada en simplicidad de setup.

Scope de features. K3s deja dentro solo el núcleo; lo demás se agrega con setup manual si hace falta. K8s trae todo out of the box: APIs comprehensivas, monitoring, logging, integraciones con cloud providers. K3s empaqueta todo en un solo binario y defaults a SQLite en lugar de etcd.

Entorno target. K3s: edge, IoT, dev/test, sistemas chicos de producción. K8s: data centers, cloud, microservicios complejos a escala empresarial.

Seguridad. K8s está construido para multi-tenancy y seguridad enterprise con RBAC, secret management flexible, encryption. K3s también soporta RBAC y policies, pero omite ciertos features de seguridad por default. Estos se pueden agregar después con tooling nativo de Kubernetes.

Compatibilidad y comunidad. K3s es 100% compatible con K8s en APIs. No todas las extensiones de K8s están incluidas por default. La comunidad de K3s es más chica pero enfocada en lightweight y deploy rápido. K8s tiene la comunidad más grande del mundo de container orchestration.

Cuándo conviene K3s

  • Edge computing y IoT. Dispositivos con recursos limitados que necesitan correr workloads contenerizados.
  • Servidores pequeños. Single-board computers, mini PCs, servidores con menos de 4 GB de RAM.
  • Dev/test. Levantar un cluster de Kubernetes en una laptop o en un CI sin la fricción de instalar K8s completo.
  • Aplicaciones con microservicios acotados. Donde el feature set completo de K8s es sobredimensionado para la carga.
  • Producción con scope limitado. Equipos chicos que necesitan Kubernetes real, sin la complejidad operativa de un cluster K8s completo.

Cuándo conviene K8s

  • Producción a escala. Clusters de cientos de nodos en producción con requisitos de alta disponibilidad.
  • Cloud-native architectures. Cuando el stack ya está sobre managed Kubernetes (EKS, GKE, AKS) o self-hosted en cloud.
  • Microservicios complejos. Muchas decenas ocientos de servicios que requieren orquestación robusta, service mesh, auto-scaling agresivo.
  • Empresas con requirements estrictos. Monitoring avanzado, logging centralizado, políticas de seguridad compliance (SOC2, ISO 27001, etc.).
  • Multi-tenant. Donde el aislamiento y la governance entre equipos es crítico.

El patrón híbrido

La elección no es excluyente. Un setup común y razonable:

  • K3s en edge para nodos que recolectan datos, ejecutan inferencia local, o actúan como gateways.
  • K8s en cloud como control plane central, donde se agregan los datos, se corre el training pesado, se sirve el tráfico principal.

Las APIs son las mismas. Los manifests de Kubernetes (Deployment, Service, ConfigMap, etc.) corren igual en ambos. Un kubectl apply que funciona en K3s funciona en K8s. Esto simplifica mucho la operativa.

Alternativas que vale la pena conocer

MicroK8s (de Canonical) es otra distribución ligera, modular, fácil de extender con add-ons (DNS, monitoring). Buena opción para developers que quieren experimentar localmente antes de pasar a un cluster más grande.

Minikube está específicamente pensado para desarrollo local en una sola máquina. No es para producción, pero es excelente para aprender Kubernetes features o construir prototipos.

OpenShift (de Red Hat) es Kubernetes-based con seguridad adicional y features enterprise. Atractivo para empresas grandes que necesitan clusters estandarizados con management y seguridad mejorados. Se puede deployar on-premises o en cloud.

Docker Swarm es una solución de orquestación más simple built into Docker. Menos complejo que Kubernetes, pero suficiente para proyectos chicos donde no se necesita toda la infraestructura de Kubernetes pero sí container orchestration.

Lo que conviene recordar

  • K3s no es una versión recortada de Kubernetes. Es una distribución diferente con el mismo API surface, optimizada para recursos limitados y edge.
  • K3s gana donde K8s es inviable. Edge, IoT, single-board computers, dev/test rápido, clusters con menos de 4 GB de RAM.
  • K8s gana donde el feature set completo importa. Producción enterprise, microservicios complejos a escala, multi-tenancy estricta.
  • El patrón híbrido es legítimo. K3s en edge + K8s en cloud, con manifests compartidos.
  • La compatibilidad de API es total. Un cluster configurado en K3s puede migrar a K8s sin reescribir manifests. Lo mismo al revés, dentro de lo razonable.

Fuente

Publicaciones relacionadas