Ir al contenido
learn

Kubernetes — Misión

Sé construir una imagen y ejecutarla; el curso de contenedores WSL termina ahí. Luego alguien dice «despliégalo en el clúster», y copio un archivo YAML de otro servicio, cambio el nombre y cruzo los dedos. Cuando un pod se reinicia en bucle, o un Service no responde nada, pruebo cosas hasta que funciona, sin saber cuál lo arregló.

Quiero saber qué hace Kubernetes con lo que declaro: qué componente actúa sobre ello, en qué orden, y qué significa cada estado y cada evento. Para poder escribir manifiestos a conciencia, desplegar sin interrumpir el servicio, y encontrar lo que falla a partir de las propias respuestas del clúster.

Eres desarrollador de C# o Java, y ya has construido y ejecutado una imagen de contenedor. No necesitas conocer Kubernetes ni las redes de Linux. Las imágenes vienen de la lección 4 de Contenedores WSL; las lecciones de CI te remiten a GitHub Actions, y la lección 13 a RabbitMQ por su operador de Kubernetes.

Las dos pequeñas API web del curso de contenedores WSL, una minimal API de ASP.NET Core y una API de Spring Boot WebFlux, se ejecutan en un clúster kind de un nodo. Cada lección añade lo que necesita un despliegue real: sondas y recursos, actualizaciones progresivas, una dirección estable, configuración, almacenamiento, seguridad, empaquetado.

flowchart LR
client["cliente<br/>curl, navegador"] --> gw{{"Gateway<br/>csharp.example.test<br/>java.example.test"}}
gw --> svc1["Service csharp-api"]
gw --> svc2["Service java-reactor-api"]
svc1 --> d1["Deployment csharp-api<br/>3 pods, ASP.NET Core"]
svc2 --> d2["Deployment java-reactor-api<br/>2 pods, Spring Boot"]

Guitar Alchemist funciona con Docker Compose y .NET Aspire, con una línea de trabajo de Kubernetes planificada; la lección 2 compara las sondas de su guía de despliegue con sus imágenes.

  • explicar qué hacen con un manifiesto el API server, etcd, el scheduler, los controladores y el kubelet;
  • ejecutar un clúster local con kind, y usar kubectl contra él sin tocar mis otros clústeres;
  • escribir pods con las sondas, requests y limits adecuados, y leer sus condiciones y eventos;
  • desplegar las API de C# y de Spring con actualizaciones progresivas, y revertir una versión fallida;
  • darles una dirección estable dentro y fuera del clúster, con Services, DNS, la Gateway API e Ingress;
  • configurarlas, darles almacenamiento, y ejecutar tareas y agentes por nodo;
  • controlar dónde se ejecutan los pods, cuántos se ejecutan y qué tienen permitido hacer;
  • empaquetar un despliegue con Helm y Kustomize, y entregarlo con GitOps;
  • diagnosticar CrashLoopBackOff, ImagePullBackOff, Pending y OOMKilled con la información del propio clúster;
  • saber qué cambia en AKS, EKS y GKE.
# Lección Quizá ya conoces
1 Arquitectura y un clúster local docker run, Docker Compose, una política de reinicio
2 Pods los health checks de ASP.NET Core, Spring Boot Actuator, docker logs
3 Deployments los despliegues blue/green, las ranuras de despliegue de Azure App Service
4 Services y DNS un proxy inverso, YARP, Spring Cloud Gateway, /etc/hosts
5 Configuración: ConfigMaps y Secrets (próximamente) appsettings.json, application.yml, variables de entorno
6 Almacenamiento: volúmenes, PersistentVolumes, StatefulSets los volúmenes de Docker, una base de datos en un contenedor
7 Jobs, CronJobs y DaemonSets BackgroundService, @Scheduled, un servicio de Windows
8 Planificación: afinidad, taints, topology spread, prioridades, disruption budgets
9 Escalado: HPA, metrics-server, VPA, cluster autoscaler las reglas de escalado horizontal de App Service
10 Seguridad: RBAC, ServiceAccounts, Pod Security Standards, NetworkPolicies las políticas de autorización de ASP.NET Core, Spring Security
11 Empaquetado: Helm y Kustomize NuGet y Maven, appsettings.Production.json
12 Observabilidad y diagnóstico OpenTelemetry, dotnet-counters, Micrometer
13 Extender Kubernetes: CRD y operadores
14 Entrega continua: GitOps con Argo CD o Flux, CI con GitHub Actions GitHub Actions
15 En producción: AKS, EKS, GKE, costes, actualizaciones Azure, AWS o Google Cloud

Diario: lo que probé, lo que me sorprendió, lo que aún tengo que verificar.