Módulo 7: Eks Specifics For Production

2. El plano de control gestionado: qué administra AWS, qué sigue siendo tuyo

Siguiente →

Descripción

En el Módulo 1, lección 6, abriste la caja de andes-cargo-cluster y encontraste cinco procesos —kube-apiserver, etcd, kube-scheduler, kube-controller-manager, kube-proxy— corriendo como Pods dentro de un contenedor Docker que hacía de nodo control-plane. Lo confirmaste tú mismo con kubectl get pods -A -o wide y con docker exec ... crictl images: las mismas imágenes de contenedor que corren en un nodo real (registry.k8s.io/kube-apiserver, registry.k8s.io/etcd), simplemente empaquetadas por kind para correr en tu laptop. Lo que esa lección no dijo, porque hasta ahora no importaba, es que tú eras responsable de todo eso. Si ese contenedor andes-cargo-cluster-control-plane se hubiera quedado sin memoria, si etcd se hubiera corrompido, si necesitaras aplicar un parche de seguridad al propio kube-apiserver — todo eso hubiera sido tu problema, sin nadie más a quien llamar.

En EKS, esa responsabilidad cambia de dueño. Esta lección traza la línea exacta: qué pasa a manos de AWS, con un contrato de nivel de servicio de por medio, y qué sigue siendo tuyo aunque el clúster ya no sea kind.

Conexión con el módulo

Esta lección retoma directamente la arquitectura que construiste en el Módulo 1, lección 6 — no como repaso, sino como el punto de comparación exacto contra el que se mide todo lo que EKS cambia. Cada componente que identificaste ahí (kube-apiserver, etcd, kube-scheduler, kube-controller-manager, kube-proxy, kubelet) reaparece aquí, con una sola pregunta nueva para cada uno: ¿quién lo administra en EKS?

El modelo de responsabilidad compartida, aplicado a Kubernetes

AWS divide la responsabilidad de un clúster EKS en dos planos, con una frontera clara:

              LA FRONTERA DE RESPONSABILIDAD EN EKS

  ┌──────────────────────────────────────────────────────────┐
  │  PLANO DE CONTROL — cuenta de AWS administrada por AWS       │
  │                                                                │
  │   kube-apiserver   (múltiples réplicas, balanceadas,         │
  │                      en al menos dos zonas de disponibilidad) │
  │   etcd              (respaldado, replicado, cifrado en reposo)│
  │   kube-scheduler                                              │
  │   kube-controller-manager                                     │
  │                                                                │
  │   AWS aplica parches de seguridad, administra la              │
  │   disponibilidad, y ofrece un SLA formal sobre esta capa       │
  └──────────────────────────────┬───────────────────────────────┘
                                  │  kube-apiserver expone un
                                  │  endpoint HTTPS — el mismo
                                  │  ~/.kube/config que ya usas
                                  ▼
  ┌──────────────────────────────────────────────────────────┐
  │  PLANO DE DATOS — tu cuenta de AWS, tu responsabilidad        │
  │                                                                │
  │   Nodos (EC2 vía node groups, o Fargate)                       │
  │   kubelet + kube-proxy + containerd en cada nodo               │
  │   Add-ons de clúster (CNI, CoreDNS, CSI de almacenamiento)     │
  │   RBAC — quién puede hacer qué dentro del clúster              │
  │   Tus Pods, Deployments, Services — todo lo de los Módulos 2-6 │
  └──────────────────────────────────────────────────────────┘

La AWS Shared Responsibility Model, aplicada aquí sin ambigüedad: AWS es dueño de la infraestructura que hace correr kube-apiserver y etcd — parcheo de seguridad del sistema operativo subyacente, alta disponibilidad de esos procesos, cifrado de etcd en reposo, respaldo automático. Tú sigues siendo dueño de todo lo que corre dentro del clúster que ese plano de control administra: tus nodos, tus add-ons, tu RBAC, y —esto es lo que casi nadie anticipa— la versión de Kubernetes que corre en tus nodos, que tú tienes que mantener sincronizada con la versión del plano de control (AWS no actualiza tus nodos por ti automáticamente, salvo que uses EKS Auto Mode, nombrado por contraste en el Módulo 7.3).

Componente por componente: el mismo mapa del Módulo 1.6, con el dueño correcto

ComponenteEn kind (Módulo 1)En EKS real
kube-apiserverUn Pod más, corriendo en el contenedor Docker que hace de nodo control-plane — tú lo creaste con kind create clusterAdministrado por AWS, con múltiples réplicas balanceadas entre zonas de disponibilidad, fuera de tu cuenta de AWS visible directamente
etcdUn Pod más, en el mismo contenedor — sin respaldo automático, sin cifrado configurado por defectoAdministrado por AWS: respaldado, replicado, cifrado en reposo por defecto
kube-schedulerUn Pod más, en el mismo contenedorAdministrado por AWS
kube-controller-managerUn Pod más, en el mismo contenedorAdministrado por AWS
kube-proxyCorre en cada nodo (control plane y workers), tú lo instalaste al crear el clústerCorre en cada nodo tuyo — AWS lo distribuye como add-on administrado opcionalmente, pero vive en el plano de datos, no en el gestionado
kubeletCorre en cada nodo, parte de la imagen kindest/node que descargasteCorre en cada nodo tuyo (EC2 o Fargate) — nunca es responsabilidad de AWS en el sentido de "plano de control gestionado"
CNI (red de Pods)kindnet, instalado automáticamente por kindTu elección — Amazon VPC CNI por defecto, o un CNI de terceros; tu responsabilidad instalarlo y mantenerlo (salvo EKS Auto Mode)
CoreDNSInstalado automáticamente por kindAdd-on administrado opcionalmente por AWS, pero la decisión de instalarlo y su configuración siguen siendo tuyas
Nodos (el hardware/VM detrás)Un único host Docker de tu laptop, simulando tres nodosEC2 real (node groups) o Fargate — tu cuenta, tu factura, tu responsabilidad de parcheo salvo que elijas managed node groups o Fargate
RBACConfigurado por ti, o heredado del kubeconfig por defecto de kindConfigurado por ti — AWS agrega una capa adicional de mapeo entre IAM y RBAC (aws-auth ConfigMap o EKS access entries, según la versión), pero las reglas de RBAC en sí siguen siendo tuyas

La fila que vale la pena releer dos veces: en kind, los cuatro componentes centrales del plano de control (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) corrían en el mismo contenedor Docker que tú controlabas por completo — nadie tenía un SLA contigo sobre esos cuatro procesos, porque eran, literalmente, tuyos. En EKS, esos mismos cuatro procesos pasan a una cuenta de AWS que tú no ves directamente, con un contrato formal detrás. El resto de la tabla —nodos, add-ons, RBAC, y todo lo que construiste en los Módulos 2-6— sigue siendo tuyo, sin importar si el clúster es kind o EKS.

Ejemplo trabajado: qué te dice aws eks describe-cluster que kubectl cluster-info nunca dijo

Qué esperar (representativo) — verificado contra la referencia de la CLI de AWS para describe-cluster, nunca ejecutado contra una cuenta real:

aws eks describe-cluster --name andes-cargo-cluster --region us-east-1
{
  "cluster": {
    "name": "andes-cargo-cluster",
    "arn": "arn:aws:eks:us-east-1:000000000000:cluster/andes-cargo-cluster",
    "status": "ACTIVE",
    "endpoint": "https://A1B2C3D4E5F6G7H8I9J0.gr7.us-east-1.eks.amazonaws.com",
    "version": "1.34",
    "platformVersion": "eks.5",
    "resourcesVpcConfig": {
      "subnetIds": ["subnet-0abc123", "subnet-0def456"],
      "endpointPublicAccess": true,
      "endpointPrivateAccess": true
    },
    "identity": {
      "oidc": {
        "issuer": "https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      }
    }
  }
}

Compara este resultado con lo único que kubectl cluster-info --context kind-andes-cargo-cluster te mostró en el Módulo 1: una URL de localhost apuntando al puerto que Docker expuso en tu laptop. Aquí hay tres campos que no tienen equivalente en kind, y cada uno es una pieza que vas a usar en lecciones siguientes de este módulo:

  • endpoint — una URL real de AWS (*.eks.amazonaws.com), balanceada por AWS entre las réplicas de kube-apiserver que administra. No hay ningún puerto de Docker de por medio.
  • platformVersion — un número que kind no tiene ningún equivalente para reportar, porque en kind no existe una "versión de plataforma" separada de la versión de Kubernetes: es AWS quien versiona, por separado, tanto el propio Kubernetes (version) como los detalles de la infraestructura gestionada que lo sostiene (platformVersion).
  • identity.oidc.issuer — el proveedor OIDC único de este clúster, la pieza exacta que la lección 5 de este módulo usa para IRSA. kind no expone ningún equivalente, porque no hay integración con IAM de ningún tipo en un clúster local.

Errores comunes

Pensar que "administrado por AWS" significa "no hay nada que aprender sobre el plano de control" (de simplificación excesiva). Qué pasa: alguien concluye que, como AWS administra kube-apiserver/etcd, no vale la pena entender qué hacen esos componentes. Cómo detectarlo: si tu explicación de "qué es EKS" se reduce a "Kubernetes pero en AWS", sin poder nombrar qué parte específica delega AWS. Cómo corregirlo: entender qué hace cada componente —lo que el Módulo 1.6 ya te dio con evidencia ejecutada en kind— es exactamente lo que te permite razonar sobre fallas, límites y costos de un clúster EKS real; "administrado" no significa "invisible", significa "alguien más lo opera, con un SLA".

Asumir que AWS también actualiza automáticamente los nodos y los add-ons (de límite de responsabilidad). Qué pasa: alguien da por sentado que, si AWS administra el plano de control, también se encarga de mantener actualizados los nodos EC2 y sus versiones de kubelet. Cómo detectarlo: si tu plan de operación de un clúster EKS no incluye ningún paso de actualización de nodos. Cómo corregirlo: salvo que uses EKS Auto Mode (Módulo 7.3, nombrado por contraste), la actualización de nodos —parches de sistema operativo, versión de kubelet sincronizada con la del plano de control— es responsabilidad tuya, incluso con node groups gestionados: "gestionado" ahí significa que AWS te da herramientas para actualizar con un clic, no que lo haga sin que tú lo pidas.

Confundir la versión de Kubernetes del plano de control con la de los nodos, y asumir que siempre coinciden (técnico). Qué pasa: alguien asume que si el plano de control reporta version: "1.34", automáticamente todos los nodos corren la misma versión de kubelet. Cómo detectarlo: si nunca verificaste kubectl get nodes -o wide para comparar la columna KUBELET-VERSION contra la versión del plano de control. Cómo corregirlo: Kubernetes tolera una diferencia de hasta unas pocas versiones menores entre el plano de control y el kubelet de cada nodo (la llamada version skew policy), pero esa tolerancia no es infinita ni automática — un nodo desactualizado por demasiado tiempo puede quedar fuera del rango soportado, y nadie te lo va a corregir sin que actualices el node group.

Ejercicios

Ejercicio 1 — Completa la tabla de memoria. Sin mirar la tabla de esta lección, para cada uno de estos cinco componentes, di si en EKS lo administra AWS o si sigue siendo tuyo: kube-apiserver, kubelet, etcd, el CNI, kube-scheduler.

Ver solución

kube-apiserver → AWS. kubelet → tuyo (corre en tus nodos, sea EC2 o Fargate). etcd → AWS. El CNI → tuyo (tu elección de cuál instalar y cómo configurarlo, salvo que uses EKS Auto Mode). kube-scheduler → AWS. Si separaste correctamente los cuatro procesos centrales del plano de control (siempre AWS) de todo lo que corre en o para tus nodos (siempre tuyo, con la excepción parcial de EKS Auto Mode), tienes clara la frontera de esta lección.

Ejercicio 2 — Explica la diferencia de responsabilidad usando la evidencia real del Módulo 1. Un colega que nunca vio kubectl get pods -A -o wide corriendo contra kind te pregunta: "¿en qué se diferencia realmente el plano de control de kind del de EKS, si en ambos casos es 'solo' Kubernetes?". Respóndele usando la evidencia concreta de esa lección.

Ver solución

Una respuesta completa suena, más o menos, así: "Técnicamente son el mismo software — cuando corrí kubectl get pods -A -o wide contra mi clúster kind, vi etcd-andes-cargo-cluster-control-plane, kube-apiserver-andes-cargo-cluster-control-plane y los demás, corriendo como Pods normales dentro de un único contenedor Docker en mi laptop. La diferencia no es el software, es quién es responsable de que esos Pods sigan sanos: en kind, era yo, sin ningún contrato de por medio, corriendo en mi propia máquina. En EKS, esos mismos procesos corren dentro de una infraestructura que AWS administra, con un SLA formal, fuera de mi cuenta visible directamente."

Ejercicio 3 — Predice qué campo de describe-cluster no tiene ningún equivalente en kind, y por qué. De los tres campos destacados en el "Ejemplo trabajado" de esta lección (endpoint, platformVersion, identity.oidc.issuer), elige el que consideres más importante para el resto de este módulo, y justifica en una frase por qué kind nunca podría reportar ese mismo dato.

Ver solución

identity.oidc.issuer es, con evidencia, el más importante para el resto de este módulo: la lección 5 completa (IRSA/EKS Pod Identity) depende de que exista un proveedor OIDC único, emitido por el propio clúster, que IAM pueda usar para confiar en tokens de Kubernetes. kind nunca podría reportar un campo equivalente porque no tiene ninguna integración con IAM de ningún tipo — es un clúster completamente aislado de cualquier cuenta de AWS, sin ningún concepto de identidad federada incorporado.

Resumen y siguiente paso

Esta lección tomó el mismo mapa de cinco componentes que el Módulo 1.6 confirmó con evidencia ejecutada en kind, y trazó la frontera de responsabilidad exacta que EKS introduce: kube-apiserver, etcd, kube-scheduler y kube-controller-manager pasan a manos de AWS, con un SLA formal; kubelet, kube-proxy, el CNI, los add-ons y todo lo que construiste en los Módulos 2-6 siguen siendo tuyos, sin importar en qué clúster corran. Confirmaste, con un ejemplo representativo de aws eks describe-cluster, tres campos que kind nunca podría reportar —endpoint real de AWS, platformVersion, y el proveedor OIDC (identity.oidc.issuer)— y por qué el tercero importa especialmente para lo que sigue.

Antes de avanzar deberías poder: nombrar los cuatro componentes que EKS administra por ti; explicar por qué "gestionado" no significa "invisible" para nodos y add-ons; y describir qué campo nuevo de describe-cluster habilita el patrón de identidad que la lección 5 de este módulo construye.

Siguiente lección: node groups, gestionados, autogestionados, y Fargate profiles. Ahí vas a ver las tres formas distintas de tener cómputo detrás de un clúster EKS, y cuándo un equipo real elige cada una.

Recursos

  1. Amazon EKS — Amazon EKS architecture — la referencia oficial del plano de control gestionado y su frontera con el plano de datos.
  2. AWS — Shared Responsibility Model — el modelo general de responsabilidad compartida, aplicado aquí a Kubernetes específicamente.
  3. AWS CLI — aws eks describe-cluster — la referencia exacta del comando y los campos usados en el ejemplo representativo de esta lección.
  4. kubernetes-and-eks-in-production-guide (NIEVA), Módulo 1, lección 6 — la arquitectura de kind con evidencia ejecutada, el punto de comparación central de esta lección.
  5. kind — Quick Start — referencia de kind para quien quiera revisar de nuevo la arquitectura local antes de seguir.
← Anterior1. Introducción al módulo: por qué este es distinto a los seis anterioresSiguiente →3. Node groups: gestionados, autogestionados, y Fargate profiles