Quita los nodos que bloquean los PodDisruptionBudgets

Resolver los conflictos de PodDisruptionBudget (PDB) te permite completar las eliminaciones de nodos de los clústeres de Google Distributed Cloud cuando se bloquean las eliminaciones. Cuando un PDB impide que se expulsen los Pods, el nodo no se puede vaciar y permanece en el clúster con el estado Ready,SchedulingDisabled, aunque lo hayas quitado de la configuración del grupo de nodos. Para terminar de quitar el nodo, puedes identificar e inhabilitar temporalmente la política en conflicto.

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 que no están disponibles de forma simultánea en una aplicación replicada.

Sin embargo, la política de PDB a veces puede impedir las eliminaciones de nodos que deseas realizar si incumples la política quitando un nodo.

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 se aplica y evita que se quite el nodo.

Del mismo modo, cuando la política de PDB define que ningún Pod debe estar no disponible (.spec.maxUnavailable es 0), la política también impide 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.

Inhabilita y vuelve a habilitar la política de PDB

Para resolver un conflicto de PDB, crea una copia de seguridad y, luego, quita la política de PDB. Después de que se borra correctamente el PDB, el nodo se vacía 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: administrador, híbrido, independiente 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.

  1. Para facilitar la lectura, la variable ${KUBECONFIG} se usa en los siguientes comandos.

    Según el tipo de clúster, exporta la ruta de acceso del kubeconfig del clúster de administrador (ADMIN_KUBECONFIG) o del kubeconfig del clúster de usuario (USER_CLUSTER_CONFIG) a $(KUBECONFIG) y completa los siguientes pasos:

    • Para borrar un nodo de un clúster de usuario, establece export KUBECONFIG=USER_CLUSTER_CONFIG
    • Para borrar un nodo de un clúster de administrador, configura export KUBECONFIG=ADMIN_KUBECONFIG.

  2. 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 de tu clúster:

    • ADMIN_KUBECONFIG es la ruta 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.

  3. Después de quitar el nodo del grupo de nodos, verifica el estado del nodo. 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

  4. Verifica los PDB en tu clúster:

    kubectl get pdb --kubeconfig ${KUBECONFIG} -A

    El sistema informa PDB similares a las 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

  5. Inspecciona el PDB. Busca una coincidencia entre la etiqueta del Pod dentro del PDB y los Pods que coinciden 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"}}}

  6. 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 devuelve una lista de Pods que coinciden con la etiqueta del PDB y verifica la política de PDB que debes quitar:

    stackdriver-log-aggregator-0    CP3
stackdriver-log-aggregator-1    CP3

  7. Después de confirmar el Pod afectado, crea 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

  8. Borra la política de PDB específica. Nuevamente, 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, puede tardar hasta 30 minutos en borrarse por completo. Sigue verificando el estado del nodo para confirmar que el proceso se completó correctamente.

    Si quieres quitar el nodo de forma permanente y también quitar los recursos de almacenamiento asociados con el nodo, puedes hacerlo antes de restablecer la política de PDB. Para obtener más información, consulta Quita recursos de almacenamiento.

  9. Restablece la política de PDB desde tu copia:

    kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}

  10. Verifica que los Pods borrados se vuelvan a crear correctamente. En este ejemplo, si hubiera dos Pods stackdriver-log-aggregator-x, se volverían a crear:

    kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A

  11. 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 los recursos de almacenamiento de los nodos borrados de forma permanente

Si borras un nodo de forma permanente y no quieres restablecerlo en tu sistema, también puedes borrar los recursos de almacenamiento asociados a ese nodo.

  1. 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}'

  2. 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.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud. También puedes consultar Cómo obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:

  • Requisitos para abrir un caso de asistencia.
  • Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas.
  • Componentes compatibles.