Un Pod Disruption Budget (PDB) es un recurso de API en Kubernetes que especifica el número mínimo de réplicas que una aplicación debe mantener en funcionamiento o el número máximo de réplicas que pueden estar no disponibles durante una interrupción voluntaria. Las interrupciones voluntarias incluyen acciones como la actualización de nodos, la eliminación de nodos o la desconfiguración de nodos para mantenimiento. El PDB no protege contra interrupciones involuntarias (fallos de hardware, fallos de software, etc.), sino que actúa como una restricción para el controlador de Kubernetes (como el scheduler o el controlador de replicación) al realizar operaciones que podrían desalojar Pods.
La implementación principal de los PDBs se encuentra en Kubernetes. Se utilizan en conjunto con controladores de Kubernetes como el 'kube-scheduler' y el 'kube-controller-manager'. Por ejemplo, cuando se realiza una operación de drenaje de un nodo ('kubectl drain'), el sistema consulta los PDBs de los Pods en ese nodo. Si el drenaje de un Pod violaría su PDB, la operación se detendrá o se ralentizará hasta que se cumplan las condiciones del PDB. Herramientas de gestión de clusters como 'Kubeadm' o 'Rancher' que orquestan actualizaciones de nodos, también respetan los PDBs para minimizar el impacto en las aplicaciones.
Para un arquitecto, los PDBs son cruciales para diseñar sistemas resilientes en Kubernetes. Permiten equilibrar la necesidad de mantenimiento y actualización del cluster con los requisitos de disponibilidad de las aplicaciones. La decisión de configurar un PDB implica un trade-off: un PDB muy restrictivo (ej. 'minAvailable: 100%') garantiza la máxima disponibilidad, pero puede ralentizar o incluso bloquear las operaciones de mantenimiento del cluster. Por otro lado, un PDB laxo (ej. 'maxUnavailable: 100%') permite un mantenimiento rápido pero a expensas de la disponibilidad de la aplicación. Los arquitectos deben analizar los SLAs de cada servicio y configurar PDBs apropiados, considerando también la capacidad del cluster para re-programar Pods rápidamente y la tolerancia a fallos de la propia aplicación.