En ciertas condiciones, las políticas de PodDisruptionBudgets (PDB) pueden evitar que los nodos se quiten de los grupos de nodos de forma correcta.
En estas condiciones, el estado del nodo informa Ready,SchedulingDisabled
a pesar de que se haya quitado. En este documento, se muestra cómo quitar nodos de tus clústeres de Google Distributed Cloud que actualmente están bloqueados por problemas de PDB.
El PDB entra en conflicto con la cantidad de Pods disponibles
Las políticas de PDB ayudan a garantizar el rendimiento de la app, ya que evitan que los Pods se interrumpan al mismo tiempo que realizas cambios en el sistema. En consecuencia, las políticas de PDB limitan la cantidad de Pods no disponibles en simultáneo en una aplicación replicada.
Sin embargo, a veces, la política de PDB puede evitar las eliminaciones de nodos que deseas realizar si quitaras un nodo para infringir la política.
Por ejemplo, una política de PDB puede definir que siempre debe haber dos Pods disponibles en el sistema (.spec.minAvailable
es 2). Sin embargo, si solo tienes dos Pods y tratas de quitar el nodo que contiene uno de ellos, la política de PDB tiene efecto y evita la eliminación del nodo.
De manera similar, cuando la política de PDB define que ningún Pod debe estar disponible (.spec.maxUnavailable
es 0), la política también evita que se borren los nodos asociados. Incluso si intentas quitar un solo Pod a la vez, la política de PDB te impide borrar el nodo afectado.
Inhabilitar y volver a habilitar la política de PDB
Para resolver un conflicto de PDB, crea una copia de seguridad de la política de PDB y, luego, quítala. Una vez que el PDB se borra de forma correcta, se vacía el nodo y se quitan los Pods asociados. Luego, puedes realizar los cambios que desees y volver a habilitar la política de PDB.
En el siguiente ejemplo, se muestra cómo borrar un nodo en esta condición, lo que puede afectar a todos los tipos de clústeres de Google Distributed Cloud: clústeres de administrador, híbridos, independientes y de usuario.
El mismo procedimiento general funciona para todos los tipos de clústeres. Sin embargo, los comandos específicos para borrar un nodo de un grupo de nodos de clúster de administrador (para clústeres independientes, híbridos o de administrador) varían levemente de los comandos para borrar un nodo del grupo de nodos del clúster de usuario.
Para facilitar la lectura, se usa la variable
${KUBECONFIG}
en los siguientes comandos.Según el tipo de clúster, exporta la ruta de acceso del clúster de administrador kubeconfig (
ADMIN_KUBECONFIG
) o la ruta de acceso del clúster de usuario kubeconfig (USER_CLUSTER_CONFIG
) a$(KUBECONFIG)
y completa los siguientes pasos:- Para borrar un nodo de un clúster de usuario, configura
export KUBECONFIG=USER_CLUSTER_CONFIG
. - Para borrar un nodo de un clúster de administrador, configura
export KUBECONFIG=ADMIN_KUBECONFIG
.
- Para borrar un nodo de un clúster de usuario, configura
Opcional: Si borras un nodo de un grupo de nodos de clúster de usuario, ejecuta el siguiente comando para extraer el archivo kubeconfig del clúster de usuario:
kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME \ get secret USER_CLUSTER_NAME-kubeconfig \ -o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
Reemplaza las siguientes entradas por información específica del entorno del clúster:
ADMIN_KUBECONFIG
: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.CLUSTER_NAME
: el nombre del clúster del que deseas tomar una instantánea.USER_CLUSTER_CONFIG
: Es la ruta de acceso al archivo de configuración del clúster de usuario.
Después de quitar el nodo del grupo, verifica su estado. El nodo afectado informa
Ready, SchedulingDisabled
:kubectl get nodes --kubeconfig ${KUBECONFIG}
El estado del nodo es similar al siguiente resultado de ejemplo:
NAME STATUS ROLES AGE VERSION CP2 Ready Master 11m v.1.18.6-gke.6600 CP3 Ready,SchedulingDisabled <none> 9m22s v.1.18.6-gke.6600 CP4 Ready <none> 9m18s v.1.18.6-gke.6600
Verifica los PDB en tu clúster:
kubectl get pdb --kubeconfig ${KUBECONFIG} -A
El sistema informa los PDB similares a los que se muestran en el siguiente resultado de ejemplo:
NAMESPACE NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE gke-system istio-ingress 1 N/A 1 19m gke-system istiod 1 N/A 1 19m kube-system coredns 1 N/A 0 19m kube-system log-aggregator N/A 0 0 19m kube-system prometheus N/A 0 0 19m
Inspecciona el PDB. Encuentra una coincidencia entre la etiqueta del Pod dentro del PDB y los Pods coincidentes en el nodo. Esta coincidencia garantiza que inhabilites el PDB correcto para quitar el nodo de forma correcta:
kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
El sistema muestra resultados coincidentes de etiquetas en la política de PDB:
{"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
Busca Pods que coincidan con la etiqueta de política de PDB:
kubectl --kubeconfig ${KUBECONFIG} get pods -A --selector=app=stackdriver-log-aggregator \ -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'
El comando muestra una lista de Pods que coinciden con la etiqueta de PDB y verifica la política de PDB que debes quitar:
stackdriver-log-aggregator-0 CP3 stackdriver-log-aggregator-1 CP3
Después de confirmar el Pod afectado, haz una copia de seguridad de la política de PDB. En el siguiente ejemplo, se crea una copia de seguridad de la política
log-aggregator
:kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system \ -o yaml >> log-aggregator.yaml
Borra la política de PDB específica. Una vez más, en los siguientes ejemplos, se borra la política
log-aggregator
:kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
Después de borrar la política de PDB, el nodo se vacía. Sin embargo, el nodo puede tardar hasta 30 minutos en borrarse por completo. Continúa con la verificación del estado del nodo para confirmar que el proceso se completó de forma correcta.
Si deseas quitar el nodo de forma permanente y los recursos de almacenamiento asociados con él, puedes hacerlo antes de restablecer la política de PDB. Para obtener más información, consulta Quita recursos de almacenamiento.
Restablece la política de PDB desde tu copia:
kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}
Verifica que los Pods borrados se vuelvan a crear de forma correcta. En este ejemplo, si hubiera dos Pods
stackdriver-log-aggregator-x
, se vuelven a crear:kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
Si deseas restablecer el nodo, edita el archivo de configuración adecuado del grupo de nodos y restablece la dirección IP del nodo.
Quita recursos de almacenamiento de los nodos borrados de forma permanente
Si borras un nodo de manera permanente y no quieres restablecerlo en tu sistema, también puedes borrar los recursos de almacenamiento asociados con ese nodo.
Verifica el volumen persistente (PV) asociado con el nodo y obtén su nombre:
kubectl get pv --kubeconfig ${KUBECONFIG} \ -A -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{.spec.claimRef.name}{":\t} \ {.spec.nodeAffinity.required.nodeSelectorTerms[0].matchExpressions[0].values}{"\n"}{end}'
Borra el PV asociado con el nodo:
kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}
Reemplaza
PV_NAME
por el nombre del volumen persistente que deseas borrar.