Arostik Logo
ArostikVLARCK

Micro-Technology Solutions

Aros StudentAnalogía Cotidiana Incluida

What is Kubernetes (K8s): Cluster Architecture, Pods, Services, Ingress and Horizontal Pod Autoscaling (HPA)

Comprehensive technical guide to container orchestration at scale: control plane (kube-apiserver, etcd), data plane (kubelet), and declarative YAML management.

AS

AS

Aros Student

Sep 4, 20264 min1520 views
What is Kubernetes (K8s): Cluster Architecture, Pods, Services, Ingress and Horizontal Pod Autoscaling (HPA)

Qué es Kubernetes (K8s) y cómo orquestar contenedores a escala

Arquitectura de Clúster, Primitivas de Cómputo, Red Interna y Autoescalado

En los inicios del uso de Docker, desplegar un par de contenedores en una máquina virtual era sencillo. Sin embargo, a medida que las empresas adoptaron arquitecturas de microservicios con cientos o miles de contenedores distribuidos en múltiples servidores físicos, surgieron desafíos críticos de infraestructura: ¿Qué ocurre si un servidor se apaga físicamente? ¿Cómo se balancea el tráfico entre 50 réplicas del mismo servicio? ¿Cómo se actualiza una aplicación a una nueva versión sin interrumpir a los usuarios?

Para solucionar esto, Google liberó en 2014 Kubernetes (K8s), el estándar universal de la Cloud Native Computing Foundation (CNCF) para la orquestación automatizada de contenedores: despliegue, escalado, auto-recuperación (self-healing), balanceo de carga y gestión del ciclo de vida del software.


WIKIHOW STEP

Arquitectura de un Clúster de Kubernetes

Un clúster de K8s se divide estrictamente en dos capas:

1.
Plano de Control (Control Plane): El cerebro del clúster que toma decisiones globales y reconcilia el estado deseado con el estado real:
kube-apiserver: La puerta de entrada HTTP/JSON REST del clúster; expone la API y autentica todas las órdenes (kubectl).
etcd: Base de datos clave-valor distribuida, consistente y altamente disponible que almacena el estado completo del clúster.
kube-scheduler: Analiza los recursos requeridos por nuevos Pods y asigna en qué Worker Node deben ejecutarse.
kube-controller-manager: Ejecuta bucles de control continuos que detectan caídas de nodos y crean nuevos contenedores de reemplazo.
2.
Nodos de Trabajo (Worker Nodes): Las máquinas que ejecutan físicamente las cargas de trabajo:
kubelet: Agente local que se comunica con el API Server y le ordena al motor de contenedores (containerd) iniciar o detener Pods.
kube-proxy: Mantiene las reglas de red e iptables/IPVS para permitir la comunicación entre Pods y balancear el tráfico de los Services.

En la Tecnología Real (Explicación Sencilla)

Escenario de Producción Real: Durante el lanzamiento de un producto, el tráfico hacia la API pasa repentinamente de 500 a 8,000 peticiones por segundo. Los 3 contenedores existentes agotan su CPU al 100% y los usuarios experimentan errores 502 Bad Gateway. La Solución con Kubernetes y HPA: 1. Se define un HorizontalPodAutoscaler (HPA) que monitorea la métrica de CPU y memoria en tiempo real a través del Metrics Server. 2. Al superar el umbral del 70% de CPU, el controlador de K8s escala automáticamente el Deployment de 3 a 20 Pods en menos de 35 segundos. 3. El componente ClusterIP Service distribuye equitativamente las conexiones entre los 20 Pods mediante round-robin a nivel de kernel. 4. Los chequeos de salud (Readiness Probes) evitan enviar tráfico a nuevos Pods hasta que la aplicación haya inicializado completamente sus conexiones a base de datos. 5. Cuando el pico de tráfico concluye, el clúster reduce suavemente las réplicas para ahorrar costos de cómputo.

WIKIHOW STEP

Comparativa de Primitivas Fundamentales de Kubernetes

Primitiva K8sNivel de AbstracciónPropósito OperativoComportamiento ante Fallos
PodUnidad MínimaGrupo de uno o más contenedores que comparten la misma IP y volúmenes de disco.Efímero: Si el Pod muere, no se recupera solo a menos que esté gestionado por un Deployment.
DeploymentControlador de CargaDefine el estado deseado (ej. "mantener 5 réplicas activas") y gestiona actualizaciones Rolling Updates.Autorreparable: Si un nodo muere, el Deployment crea réplicas en otros nodos inmediatamente.
ServiceAbstracción de RedProvee una IP estática interna y un nombre DNS persistente para balancear tráfico hacia un conjunto de Pods.Si los Pods cambian de IP interna, el Service actualiza dinámicamente sus Endpoints.
IngressEnrutamiento L7Punto de entrada HTTP/HTTPS externo con terminación de certificados TLS y enrutamiento por rutas/dominios.Redirige el tráfico desde Internet hacia los Services internos del clúster.

WIKIHOW STEP

Manifiesto de Despliegue de Producción (deployment.yaml)

arostik@ubuntu:~ (yaml)
apiVersion: apps/v1kind: Deploymentmetadata:  name: api-backend  labels:    app: api-backendspec:  replicas: 3  selector:    matchLabels:      app: api-backend  template:    metadata:      labels:        app: api-backend    spec:      containers:      - name: web-api        image: miempresa/api:v2.4.0        ports:        - containerPort: 3000        resources:          requests:            cpu: "250m"            memory: "256Mi"          limits:            cpu: "1000m"            memory: "512Mi"        readinessProbe:          httpGet:            path: /healthz            port: 3000          initialDelaySeconds: 5          periodSeconds: 10        livenessProbe:          httpGet:            path: /healthz            port: 3000          initialDelaySeconds: 15          periodSeconds: 20---apiVersion: v1kind: Servicemetadata:  name: api-backend-servicespec:  type: ClusterIP  selector:    app: api-backend  ports:  - port: 80    targetPort: 3000

Nota Técnica

Requests vs Limits en la Memoria del Pod: Si un contenedor supera su límite de memoria RAM (limits.memory), el kernel de Linux enviará la señal SIGKILL y el contenedor será terminado inmediatamente por el sistema con el error `OOMKilled (Exit Code 137)`. Establece siempre un margen de seguridad razonable entre los requests y los limits.

WIKIHOW STEP

Glosario Técnico de Kubernetes

1.
Kubelet: Agente primario de nodo que se asegura de que los contenedores descritos en los PodSpecs estén corriendo y saludables.
2.
etcd: Base de datos distribuida de alta consistencia basada en el algoritmo Raft, considerada la única fuente de verdad (Single Source of Truth) del clúster.
3.
Horizontal Pod Autoscaler (HPA): Controlador que ajusta automáticamente la cantidad de réplicas de un Deployment según el consumo de CPU, memoria o métricas personalizadas de Prometheus.
4.
Ingress Controller (NGINX / Traefik): Aplicación especializada que monitorea los objetos Ingress y configura dinámicamente un proxy inverso para enrutar tráfico externo hacia el clúster.

Mini Cuestionario Interactivo3 preguntas

Selecciona una opción para autoevaluarte al instante. La respuesta se califica de inmediato.

Aciertos: 0 / 3
1

¿Cuál es la función principal de 'etcd' en un clúster de Kubernetes?

2

¿Qué sucede cuando un contenedor excede el límite de memoria RAM especificado en su bloque 'resources.limits'?

3

¿Cuál es la ventaja de usar un objeto 'Deployment' en lugar de crear 'Pods' individuales aislados?

Diagnóstico y Práctica en Arostik

Inspecciona tus puertos y latencia de red con la Terminal de Redes, formatea tus sentencias de base de datos con el Formateador SQL y valida el ancho de banda con el Test de Velocidad.

Tu opinión mejora Aroslap

¿Te resultó útil esta publicación?

Califica tu experiencia para optimizar los próximos artículos técnicos.

Selecciona una calificación

More Articles in Aros Student