MateriasEscuelaProfesoresTransparenciaDemostración

Materias · 🏛️ Universidad y trabajo

Kubernetes

Ejercicios resueltos de Kubernetes paso a paso, con el error que más se comete en cada uno: Recursos: requests y limits, Servicios y selectores y más. Gratis y en español.

Preguntarle al tutor de Kubernetes

Sin instalar nada. Puedes probar antes de crear cuenta.

Ejercicios resueltos de Kubernetes

Resueltos paso a paso, como te los explicaría el tutor, y con el error que más se comete.

Recursos: requests y limits

Un clúster de Kubernetes tiene 3 nodos con 4 CPU y 16 GB de memoria asignables cada uno. Se despliega una aplicación con 20 réplicas; cada pod pide (requests) 500 m de CPU y 1 GB de memoria, y tiene como tope (limits) 1 CPU y 2 GB. ¿Caben las 20 réplicas? ¿Qué pasa si todos los pods llegan a su tope al mismo tiempo?

Cómo se resuelve

  1. 1El planificador de Kubernetes decide dónde cabe cada pod mirando únicamente los REQUESTS. Los limits no los mira para ubicar: son el tope en tiempo de ejecución.
  2. 2Capacidad del clúster: 3 nodos × 4 CPU = 12 CPU, y 3 × 16 = 48 GB de memoria asignables.
  3. 3Requests de CPU que se piden: 20 pods × 500 m = 10.000 m, o sea 10 CPU de las 12. Cabe.
  4. 4Requests de memoria: 20 × 1 GB = 20 GB de los 48. Cabe con holgura. Las 20 réplicas se programan sin problema, repartidas en unos 7 pods por nodo (7 × 500 m = 3,5 CPU de las 4 del nodo).
  5. 5Ahora el escenario de todos en el tope. Memoria: 20 × 2 GB = 40 GB contra 48 disponibles. Alcanza, no pasa nada.
  6. 6CPU: 20 × 1 = 20 CPU contra 12 reales. No alcanza, y aquí es donde importa la diferencia entre los dos recursos.
  7. 7La CPU es un recurso comprimible: cuando se acaba, el kernel simplemente le da menos tiempo a cada contenedor y todos van más lentos (estrangulamiento o throttling). Nadie se muere.
  8. 8La memoria no es comprimible: no se le puede dar «medio gigabyte del que pidió». Si un contenedor pasa su limit de memoria, el kernel lo mata en el acto y el pod aparece con el estado OOMKilled.

Respuesta: Sí caben: el planificador suma los requests, 10 CPU de 12 y 20 GB de 48. Con todos en el tope la memoria alcanza (40 de 48 GB), pero la CPU no (20 pedidas contra 12 reales) y los pods se estrangulan, sin que ninguno muera.

El error de siempre: Quitar los requests o dejarlos en cero «para que quepan más pods». Sin requests, el planificador cree que el pod no ocupa nada y amontona de más en cada nodo; cuando la memoria real se acaba, el nodo empieza a desalojar pods en plena producción. Además, un pod sin requests ni limits queda en la clase BestEffort, que es la primera de la fila para ser desalojada. La otra confusión que cuesta caro es tratar igual los dos topes: pasarse del límite de CPU solo frena el contenedor, pero pasarse del de memoria lo mata con OOMKilled. Si un pod se reinicia solo cada tanto sin explicación, lo primero que se mira es su limit de memoria, no la aplicación.

Servicios y selectores

Un Service de tipo ClusterIP no responde. «kubectl get endpoints pagos-svc» muestra la lista de direcciones vacía, aunque los 3 pods aparecen en estado Running. El Deployment le pone a los pods la etiqueta app: pagos-api y el Service tiene el selector app: pagos. ¿Qué está pasando?

Cómo se resuelve

  1. 1Un Service no conoce a los pods por nombre. Arma su lista de destinos (los endpoints) buscando pods cuyas ETIQUETAS coincidan con su selector, y la coincidencia tiene que ser exacta, cadena por cadena.
  2. 2«pagos» y «pagos-api» no son la misma cadena. Ningún pod coincide con el selector, así que la lista de endpoints queda vacía.
  3. 3Una lista de endpoints vacía significa que el Service recibe la conexión y no tiene a quién mandársela. De ahí que se vea como si la red estuviera rota, cuando la red está perfecta.
  4. 4Se confirma comparando los dos lados: «kubectl get pods --show-labels» para ver las etiquetas reales y «kubectl describe svc pagos-svc» para ver el selector. Puestos uno al lado del otro, la diferencia salta.
  5. 5Corrección: alinear el selector del Service a app: pagos-api, o cambiar la etiqueta del Deployment. Se elige uno de los dos y se deja consistente, porque cambiar el selector de un Deployment ya creado no se puede: hay que borrarlo y recrearlo.
  6. 6Hay una segunda causa que da exactamente el mismo síntoma y conviene descartar: un pod puede estar Running pero no estar Ready porque su sonda de disponibilidad (readiness probe) falla. Los pods que no están Ready se quedan fuera de los endpoints a propósito, para no mandarles tráfico antes de tiempo.

Respuesta: El selector del Service (app: pagos) no coincide con la etiqueta de los pods (app: pagos-api), así que no tiene destinos. Se corrige dejando el selector en app: pagos-api.

El error de siempre: Ir a buscar el problema en el ingress, en las políticas de red o en el DNS del clúster cuando la lista de endpoints está vacía. Endpoints vacío nunca es un problema de red: o ningún pod casa con el selector, o los que casan no están Ready. Es lo primero que se mira, antes de tocar cualquier otra cosa. Y el descuido vecino da un síntoma parecido pero distinto: dejar el targetPort igual al port del Service (80) cuando el contenedor escucha en 8080. Ahí sí hay endpoints listados, pero todas las conexiones se rechazan de inmediato. Endpoints vacío es etiqueta o readiness; endpoints llenos con conexión rechazada es puerto.

¿Y si tu ejercicio no es ninguno de estos?

No hace falta buscar el ejercicio exacto en internet. Trae el tuyo, o pide los que te falten.

📸El ejercicio que tengo yoTómale una foto a tu cuaderno o al taller y lo resolvemos paso a paso, con tus números.Resolver el mío →🔁Más ejercicios como estosQue te arme ejercicios nuevos de Recursos: requests y limits, al nivel que pidas y con la solución explicada.Generar ejercicios →💡No entendí el temaTe lo explica desde cero, con otras palabras, y se detiene donde te trabes. Puedes preguntar mil veces.Explícamelo →📝Tengo parcialSube un parcial viejo de tu profesor y practica con ejercicios de esa misma forma.Prepararme →

Todo esto es gratis y sin instalar nada. Puedes probar antes de crear cuenta.

Lo que cubre

  • Recursos: requests y limits
  • Servicios y selectores

Preguntas que le puedes hacer

  • Recursos: requests y …Explícame «Recursos: requests y limits» con un ejemplo práctico y dime en qué suele equivocarse la gente.
  • Servicios y selectoresExplícame «Servicios y selectores» con un ejemplo práctico y dime en qué suele equivocarse la gente.

Cómo enseña este tutor

Es riguroso y completo: justifica cada paso y nombra el teorema, la norma o la buena práctica que está aplicando, para que puedas citarla en tu trabajo o en el parcial.

  • · Te muestra el camino completo, no solo el resultado.
  • · Si algo no te cuadra, te lo explica otra vez de otra manera.
  • · Con una foto de tu cuaderno te dice dónde está el error.
  • · Te arma quizzes de lo que acabas de ver para saber si de verdad quedó.

Otras materias de Universidad y trabajo

Un producto deLOTIC