Un PodDisruptionBudget (PDB) es un recurso de Kubernetes que permite a los operadores declarar un umbral mínimo de disponibilidad para una aplicación durante interrupciones voluntarias. Define el número mínimo de Pods que deben estar en ejecución o el número máximo de Pods que pueden estar no disponibles simultáneamente para una aplicación específica. Las interrupciones voluntarias incluyen acciones como la actualización de nodos, la eliminación de nodos de un clúster o la reducción de escala de un Deployment. El PDB es consultado por los controladores de Kubernetes (como el kube-scheduler o el kube-controller-manager) y herramientas externas para determinar si una acción de interrupción es segura para proceder, evitando que una aplicación quede completamente inoperable.
La implementación principal de PodDisruptionBudget se encuentra en Kubernetes. Herramientas como 'kubectl drain' respetan los PDBs al intentar desalojar Pods de un nodo. Cuando un operador ejecuta 'kubectl drain' en un nodo, Kubernetes verifica los PDBs asociados a los Pods en ese nodo. Si la operación de desalojo excede el límite permitido por un PDB, el desalojo será bloqueado o pausado hasta que se cumplan las condiciones del PDB. Plataformas de orquestación basadas en Kubernetes, como OpenShift o Rancher, también integran y respetan los PDBs en sus flujos de trabajo de mantenimiento y actualización de clústeres.
Para un Arquitecto de Sistemas, el PodDisruptionBudget es crucial para diseñar aplicaciones resilientes en Kubernetes. Permite equilibrar la necesidad de mantenimiento del clúster con los requisitos de disponibilidad de la aplicación. Sin PDBs, una operación de mantenimiento de nodos podría derribar múltiples Pods de una aplicación simultáneamente, causando una interrupción del servicio. El trade-off principal es entre la velocidad de las operaciones de mantenimiento y la garantía de disponibilidad. Un PDB muy restrictivo (ej. 'minAvailable: 100%') puede ralentizar significativamente o incluso bloquear las operaciones de drenaje de nodos, mientras que uno demasiado permisivo podría comprometer la SLA de la aplicación. Los arquitectos deben definir PDBs que reflejen los objetivos de nivel de servicio (SLOs) de cada aplicación, considerando la tolerancia a fallos inherente de la aplicación y su capacidad para manejar la pérdida temporal de Pods.