El escenario "normal" cuando tienes que hacer un mantenimiento en tu cluster de k8s, es que marcas un nodo como cordon esto hace que no acepte más pods y de ahí empiezas a "drenar" los pods el nodo. Lo que hará k8s es que "sacará" los pods del nodo y después empezará a crearlos en el nodo activo. Si nuestra aplicación tiene la mayoría de los pods en el nodo que vamos a hacer el mantenimiento, nos trae inconvenientes como:
- Indisponibilidad de nuestra aplicación.
- Perder dinero.
Aquí te dejo el video para que veas el funcionamiento:
El Pod Disruption Budget (para los compas "PDB" de ahora en adelante) sirve para drenar un nodo, con la diferencia que va a recrear primero en el (los) otro(s) nodo(s) los pods y cuando estén listos (RUNNING), va a matar los pods del nodo que quieres hacer el mantenimiento. Suena bien ¿no? Así, evitamos la indisponibilidad de nuestra aplicación.
Pod Disruption Budgets
Es una política que vamos a aplicar a nuestro deployment para siempre mantener la cantidad de pods que le especifiquemos.
Hagamos el siguiente ejemplo, con un nginx común y silvestre.
Ejemplo de uso de PDB
00-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: pdb
01-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: pdb
labels:
app: nginx
spec:
replicas: 6
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:latest
Hasta aquí todo normal, vamos crear el PDB.
03-pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
minAvailable: 5
selector:
matchLabels:
app: nginx
Aquí no hay mucho que explicar ya que vemos que siempre intentará tener un mínimo de 5 pods corriendo (minAvailable).
Consideraciones
Si eres observador verás que usa un selector->matchLabels, esto quiere decir que si tienes varias aplicaciones y todos tienen un app: nginx tomará está política, ¿bueno o malo? ya depende de cada escenario y requerimientos, es algo a considerar.
Top comments (0)