Kubernetes para quienes tienen que ejecutarlo

Los tutoriales de Kubernetes te enseñan a desplegar un pod. Nadie te enseña qué hacer cuando un nodo desaparece silenciosamente del estado Ready a las 3am y tu teléfono de guardia no deja de sonar. Esto trata sobre la segunda parte.

Las solicitudes y límites de recursos no son opcionales

Si omites resources.requests y resources.limits en tus contenedores, el scheduler está adivinando, y el kubelet no tiene idea de qué desalojar primero cuando a un nodo se le acaba la memoria. Establece las solicitudes en lo que el contenedor realmente usa bajo carga normal, no en lo que esperas que use. Establece los límites de memoria cerca de las solicitudes ya que los pods asesinados por OOM se reinician correctamente, pero los límites de CPU generalmente deben ser más flexibles o estar ausentes a menos que estés lidiando con vecinos ruidosos, porque la limitación de CPU bajo un límite duro causa picos de latencia que son miserables de depurar. Ejecuta kubectl top pods -n your-namespace regularmente y compara contra lo que has declarado. Las discrepancias se acumulan rápidamente en clústeres con más de un puñado de servicios.

etcd es el clúster completo, trátalo así

Todo lo que Kubernetes conoce vive en etcd. Piérdelo y pierdes el estado del clúster, no solo algunos metadatos. Ejecuta etcdctl snapshot save /backup/etcd-snapshot.db en un horario, y realmente prueba restaurarlo en un clúster descartable al menos una vez. He visto equipos con copias de seguridad nocturnas que resultaron estar corruptas durante tres meses porque nadie las verificó. Si estás en un plano de control administrado (EKS, GKE, AKS), no administras etcd directamente, pero igualmente deberías conocer la historia de copias de seguridad y restauración de tu proveedor antes de necesitarla, no durante un incidente.

Los probes de liveness y readiness a veces necesitan discrepar

Un error común es usar el mismo endpoint para ambos probes de liveness y readiness. Liveness debería responder