Wilkins Ortiz
agosto 15, 2026 EKS

AWS EKS MCP

En este lab vamos a crear un clúster local usando Kind y luego usar la idea de AWS MCP para EKS como apoyo para revisar recursos de Kubernetes con más contexto.

La idea es simple:

Crear un clúster local.
Desplegar una app de prueba.
Revisar qué está pasando.
Usar MCP como apoyo para entender mejor el entorno.

Requisitos

Antes de empezar, necesitas tener instalado:

Docker
Kind
kubectl
AWS CLI
Un cliente compatible con MCP.

Valida que Docker esté corriendo:

docker ps

Valida Kind:

kind version

Y valida kubectl:

kubectl version --client

Crear el clúster local con Kind

Creamos un clúster local llamado demo-eks-lab:

kind create cluster --name demo-eks-lab

Luego confirmamos que el clúster esté arriba:

kubectl cluster-info --context kind-demo-eks-lab

Y revisamos los nodos:

kubectl get nodes

Si ves el nodo en estado Ready, ya tienes tu clúster local funcionando.

Crear un namespace de prueba

Creamos un namespace para el lab:

kubectl create namespace app-demo

Validamos que exista:

kubectl get namespaces

Desplegar una aplicación de prueba

Ahora vamos a crear un deployment sencillo usando NGINX:

kubectl create deployment web-demo \
  --image=nginx \
  --replicas=2 \
  -n app-demo

Revisamos los pods:

kubectl get pods -n app-demo

Y revisamos el deployment:

kubectl get deployment -n app-demo

Hasta aquí tenemos un clúster local, un namespace y una aplicación corriendo.

Exponer la aplicación

Creamos un servicio para exponer la app dentro del clúster:

kubectl expose deployment web-demo \
  --port=80 \
  --target-port=80 \
  --type=ClusterIP \
  -n app-demo

Validamos el servicio:

kubectl get svc -n app-demo

Para probarlo localmente, usamos port-forward:

kubectl port-forward svc/web-demo 8080:80 -n app-demo

Luego abre en el navegador:

http://localhost:8080

Si ves la página de NGINX, la app está funcionando.

Configurar EKS MCP Server usando kubeconfig

Como este lab está usando un clúster local con Kind, vamos a configurar el EKS MCP Server para que use el mismo contexto que ya tienes en kubectl.

En este caso no vamos a usar un clúster real de EKS todavía.

Vamos a usar el modo:

EKS_AUTH_MODE=kubeconfig

Este modo permite que el MCP Server lea el acceso desde tu archivo kubeconfig, que normalmente es el mismo archivo que usa kubectl. AWS Labs documenta este modo para ambientes donde Kubernetes se accede usando kubeconfig, certificados, tokens u otros métodos similares.

Confirmar que kubectl apunta al clúster

Primero valida el contexto actual:

kubectl config current-context

Si creaste el clúster con Kind usando este comando:

kind create cluster --name demo-eks-lab

Entonces deberías ver algo parecido a esto:

kind-demo-eks-lab

Ahora confirma que puedes ver los nodos:

kubectl get nodes

La salida debería verse parecida a esto:

NAME                         STATUS   ROLES           AGE   VERSION
demo-eks-lab-control-plane   Ready    control-plane   2m    v1.30.x

Si kubectl get nodes funciona, entonces tu kubeconfig está bien para este lab.

Confirmar la ruta del kubeconfig

Normalmente, kubectl usa este archivo:

~/.kube/config

Pero para la configuración del MCP es mejor usar la ruta completa.

En macOS o Linux puedes verla con:

echo $HOME/.kube/config

Ejemplo:

/Users/wilkins/.kube/config

Si tienes la variable KUBECONFIG definida, revisa su valor:

echo $KUBECONFIG

Si no devuelve nada, usa:

$HOME/.kube/config

Para confirmar que el archivo existe:

ls -la $HOME/.kube/config

Confirmar que tienes uvx instalado

El EKS MCP Server se puede ejecutar usando uvx.

Valida si lo tienes instalado:

uvx --version

Si el comando no existe, instala uv.

En macOS con Homebrew:

brew install uv

Luego valida otra vez:

uvx --version

Crear o editar el archivo de MCP

Ahora necesitas abrir el archivo de configuración MCP de tu cliente.

La ruta depende de la herramienta que estés usando.

Algunos ejemplos comunes:

Cursor:
~/.cursor/mcp.json

Kiro:
~/.kiro/settings/mcp.json

Claude Desktop:
~/Library/Application Support/Claude/claude_desktop_config.json

Si estás en macOS y usas Cursor, puedes abrirlo así:

mkdir -p ~/.cursor
nano ~/.cursor/mcp.json

Si usas Kiro:

mkdir -p ~/.kiro/settings
nano ~/.kiro/settings/mcp.json

Si usas Claude Desktop en macOS:

nano "$HOME/Library/Application Support/Claude/claude_desktop_config.json"

Agregar la configuración del EKS MCP

Pega esta configuración en el archivo MCP de tu cliente:

{
  "mcpServers": {
    "awslabs.eks-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.eks-mcp-server@latest"
      ],
      "env": {
        "EKS_AUTH_MODE": "kubeconfig",
        "KUBECONFIG": "/Users/wilkins/.kube/config",
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Cambia esta línea:

"KUBECONFIG": "/Users/wilkins/.kube/config"

Por la ruta real de tu máquina.

Por ejemplo:

"KUBECONFIG": "/Users/tu-usuario/.kube/config"

En este lab, lo importante es esta parte:

"env": {
  "EKS_AUTH_MODE": "kubeconfig",
  "KUBECONFIG": "/Users/tu-usuario/.kube/config",
  "FASTMCP_LOG_LEVEL": "ERROR"
}

Porque ahí le decimos al MCP Server:

Usa mi kubeconfig local.
Trabaja con el mismo contexto que usa kubectl.
No intentes autenticar contra EKS usando IAM para este lab.

AWS Labs muestra EKS_AUTH_MODE=kubeconfig y KUBECONFIG como variables válidas para este modo. También indica que en kubeconfig mode la autenticación la maneja el cliente de Kubernetes usando lo que ya esté configurado en el kubeconfig.

Reiniciar el cliente MCP

Después de guardar el archivo, cierra y abre de nuevo tu cliente.

Por ejemplo:

Cierra Cursor, Kiro o Claude Desktop.
Ábrelo de nuevo.
Espera unos segundos para que cargue el MCP Server.

Si el cliente tiene una sección de MCP tools o MCP servers, valida que aparezca:

awslabs.eks-mcp-server

Primera prueba desde el asistente

Ahora prueba desde tu cliente de IA con una pregunta sencilla:

Lista los namespaces del clúster actual.

También puedes probar:

Revisa los pods del namespace default.
Dame un resumen de los recursos que existen en el clúster actual.

Si todo está bien, el asistente debería poder leer información del clúster usando tu kubeconfig.

Prueba con el namespace del lab

Si en el lab creaste el namespace app-demo, prueba esto:

Revisa los pods del namespace app-demo.

Luego:

Lista los deployments del namespace app-demo.

Y después:

Revisa los eventos recientes del namespace app-demo y dime si hay algo fallando.

Prueba con un error real

Si rompiste el deployment cambiando la imagen a una que no existe:

kubectl set image deployment/web-demo \
  nginx=nginx:no-existe \
  -n app-demo

Puedes pedirle al asistente:

Revisa el namespace app-demo y dime por qué los pods están fallando.

O más directo:

Tengo pods en ImagePullBackOff en app-demo. Revisa el deployment, los pods y los eventos, y explícame qué está pasando.

El resultado esperado es que el asistente identifique que el problema viene de la imagen:

nginx:no-existe

Y que el pod no puede descargarla.

Corregir el problema

Corrige la imagen:

kubectl set image deployment/web-demo \
  nginx=nginx:latest \
  -n app-demo

Valida el rollout:

kubectl rollout status deployment/web-demo -n app-demo

Confirma los pods:

kubectl get pods -n app-demo

Luego puedes pedirle al asistente:

Confirma si el deployment web-demo en app-demo ya está saludable.

Video relacionado

Puedes verlo aquí

Volver al blog