TL;DR: los nodos prioritarios de gke 1.20 hacen que los pods se conviertan en zombis en Failed/Shutdown
Hemos estado usando GKE durante algunos años con clústeres que contienen una combinación de grupos de nodos estables y interrumpibles. Recientemente, desde gke v1.20, comenzamos a ver pods apropiables entrar en un extraño estado zombie donde se describen como:
Estado: fallido
Razón: Apagado
Mensaje: El nodo se está cerrando, expulsando pods
Cuando esto comenzó a ocurrir, estábamos convencidos de que estaba relacionado con que nuestros pods no manejaban correctamente el SIGTERM en la preferencia. Decidimos eliminar nuestro software de servicio como fuente de un problema reduciéndolo a un servicio simple que en su mayoría duerme:
/* eslint-disable no-console */ let exitNow = false process.on( 'SIGINT', () => { console.log( 'INT shutting down gracefully' ) exitNow = true } ) process.on( 'SIGTERM', () => { console.log( 'TERM shutting down gracefully' ) exitNow = true } ) const sleep = ( seconds ) => { return new Promise( ( resolve ) => { setTimeout( resolve, seconds * 1000 ) } ) } const Main = async ( cycles = 120, delaySec = 5 ) => { console.log( `Starting ${cycles}, ${delaySec} second cycles` ) for ( let i = 1; i <= cycles && !exitNow; i++ ) { console.log( `---> ${i} of ${cycles}` ) await sleep( delaySec ) // eslint-disable-line } console.log( '*** Cycle Complete - exiting' ) process.exit( 0 ) } Main()Este código está integrado en una imagen acoplable utilizando tini init para generar el proceso de pod que se ejecuta en nodejs (imagen fermium-alpine). No importa cómo mezclemos el manejo de la señal, parece que los pods nunca se apagan limpiamente, aunque los registros sugieren que sí.
Otra rareza de esto es que, según los registros de Kubernetes Pod, vemos que comienza la finalización del pod y luego se cancela:
2021-08-06 17:00:08.000 EDT Deteniendo contenedor preempt-pod
2021-08-06 17:02:41.000 EDT Cancelando la eliminación de Pod preempt-pod
También hemos intentado agregar un retraso de 15 segundos previo a la parada solo para ver si eso tiene algún efecto, pero nada de lo que intentamos parece importar: las cápsulas se convierten en zombis. Las nuevas réplicas se inician en los otros nodos que están disponibles en el grupo, por lo que siempre mantiene la cantidad mínima de pods que se ejecutan correctamente en el sistema.
También estamos probando el ciclo de preferencia usando un evento de mantenimiento de sim:
instancias de computación de gcloud simular-mantenimiento-evento nodo-id
Después de hurgar en varias publicaciones, finalmente cedí a ejecutar un cronjob cada 9 minutos para evitar la activación de alertManager que se produce después de que los pods se han quedado atascados en el apagado durante más de 10 minutos. Esto todavía me parece un truco, pero funciona y me obligó a profundizar en el cronjob y RBAC de k8.
Esta publicación me inició en el camino: Cómo eliminar los pods de 'apagado' de Kubernetes
Y la especificación de cronjob resultante:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-accessor-role namespace: default rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "delete", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-access namespace: default subjects: - kind: ServiceAccount name: cronjob-sa namespace: default roleRef: kind: Role name: pod-accessor-role apiGroup: "" --- apiVersion: v1 kind: ServiceAccount metadata: name: cronjob-sa namespace: default --- apiVersion: batch/v1beta1 kind: CronJob metadata: name: cron-zombie-killer namespace: default spec: schedule: "*/9 * * * *" successfulJobsHistoryLimit: 1 jobTemplate: spec: template: metadata: name: cron-zombie-killer namespace: default spec: serviceAccountName: cronjob-sa restartPolicy: Never containers: - name: cron-zombie-killer imagePullPolicy: IfNotPresent image: bitnami/kubectl command: - "/bin/sh" args: - "-c" - "kubectl get pods -n default --field-selector='status.phase==Failed' -o name | xargs kubectl delete -n default 2> /dev/null" status: {}Tenga en cuenta que la redirección de stderr a /dev/null es simplemente para evitar la salida de error de kubectl delete cuando kubectl get no encuentra ningún pod en estado fallido.
La actualización agregó el verbo "eliminar" faltante del rol y agregó el RoleBinding faltante
Actualizar imagePullPolicy agregada
A partir de GKE 1.20.5 y versiones posteriores, la función de cierre correcto de nodos de kubelet está habilitada para nodos interrumpibles. De la nota en la página de características:
Cuando los pods fueron desalojados durante el apagado correcto del nodo, se marcan como fallidos. La ejecución de kubectl get pods muestra el estado de los pods desalojados como Apagado. Y kubectl describe pod indica que el pod fue desalojado debido al cierre del nodo:
Estado: Error Motivo: Apagado Mensaje: El nodo se está cerrando, expulsando pods Los objetos de pod fallidos se conservarán hasta que el GC los elimine o limpie explícitamente. Este es un cambio de comportamiento en comparación con la terminación abrupta del nodo.
Estos pods eventualmente deberían recolectarse como basura, aunque no estoy seguro del valor de umbral.