Esperar: el arte sutil que debes dominar

Recientemente, mientras trabajaba en un taller tituladoPrueba de su solicitud de retiro en Kubernetes con acciones de GKE y GitHub, Me he enfrentado al mismo problema dos veces: el servicio A necesita el servicio B, pero el servicio A comienza más rápido que el servicio B, y el sistema falla.

A la espera de Kubernetes

Puede parecer extraño esperar en Kubernetes. La naturaleza de auto-curación de la plataforma Kubernetes es uno de sus mayores beneficios. Consideremos dos pods: una aplicación Python y una base de datos PostgreSQL.

La aplicación se inicia muy rápido y intenta establecer una conexión con la base de datos. Mientras tanto, la base de datos se está iniciando con los datos proporcionados; la conexión falla.FailedEl Estado.

Después de un tiempo, Kubernetes solicita el estado del pod de la aplicación. Debido a que falló, lo termina y inicia un nuevo pod. En este punto, pueden suceder dos cosas: el pod de la base de datos aún no está listo, y está de vuelta al cuadrado uno, o está listo, y la aplicación finalmente se conecta.

Para acelerar el proceso, Kubernetes ofreceInicio Proba: de

startupProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Con la sonda anterior, Kubernetes espera un inicio de diez segundos antes de solicitar el estado del pod. Si falla, espera otros diez segundos.

Puede que hayas notado el HTTP/healthKubernetes ofrece dos exclusivosPruebaConfiguración de configuración:httpGetoexecEl primero es adecuado para aplicaciones web, mientras que el segundo es para otras aplicaciones. Esto implica que necesitamos saber qué tipo de contenedor contiene el pod y cómo verificar su estado, siempre que pueda.Bitnami Helm gráficoSe ve lo siguiente cuando se aplica:

startupProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - -e
      - exec pg_isready -U $PG_USER -h $PG_HOST -p $PG_PORT

Tenga en cuenta que lo anterior es una simplificación, ya que con gusto ignora el nombre de la base de datos y un certificado SSL.

La sonda de arranque acelera las cosas en comparación con la situación predeterminada si la configura correctamente. Puede establecer un largo retraso inicial, y luego incrementos más cortos. Sin embargo, cuanto más diversos sean los contenedores, más difícil será configurarlo, ya que necesita ser un experto en cada uno de los contenedores subyacentes.

Sería útil buscar alternativas.

Espectáculos4x

Las alternativas son herramientas cuyo foco está en la espera.Hace muchoEspera porLa idea es simple, la idea es sencilla:

y

./wait-for es un script diseñado para sincronizar servicios como contenedores de docker. Es sh y alpino compatible.

y

./wait-forEs un script diseñado para sincronizar servicios como los contenedores de docker.shyalpiney compatibles.

Aquí está cómo esperar por una API HTTP:

sh -c './wait-for http://my.api/health -- echo "The api is up! Let's use it"'

Se hizo el trabajo, pero en ese momento, tuve que copiar el script y comprobar manualmente las actualizaciones.

Espectáculos4xdesempeña el mismo papel, pero está disponible como un contenedor de versión y ofrece más servicios para esperar: HTTP, DNS, bases de datos y colas de mensajes.

Cualquiera que sea la herramienta que utilices, puedes usarla dentro de unInicio Contenedores: de

y

Un Pod puede tener múltiples contenedores que ejecutan aplicaciones dentro de él, pero también puede tener uno o más contenedores init, que se ejecutan antes de que se inicien los contenedores de la aplicación.

y

Los contenedores Init son contenedores regulares, excepto:

y

Cada contenedor init debe completarse con éxito antes de que comience el siguiente.

y

Un Pod puede tener múltiples contenedores que ejecutan aplicaciones dentro de él, pero también puede tener uno o más contenedores init, que se ejecutan antes de que se inicien los contenedores de la aplicación.

Los contenedores Init son contenedores regulares, excepto:

Cada contenedor init debe completarse con éxito antes de que comience el siguiente.

Imagínese lo siguientePodEsto depende de un PostgreSQLDeployment: de

apiVersion: v1
kind: Pod
metadata:
  labels:
    type: app
    app: recommandations
spec:
  containers:
    - name: recommandations
      image: recommandations:latest
      envFrom:
        - configMapRef:
            name: postgres-config

La aplicación es Python y se inicia bastante rápido. Trata de conectarse a la base de datos PostgreSQL. Desafortunadamente, la base de datos no ha terminado de inicializar, por lo que la conexión falla, y Kubernetes reinicia el pod.

Podemos arreglarlo con uninitContainery un contenedor de espera:

apiVersion: v1
kind: Pod
metadata:
  labels:
    type: app
    app: recommandations
spec:
  initContainers:
    - name: wait-for-postgres
      image: atkrad/wait4x:3.1
      command:
        - wait4x
        - postgresql
        - postgres://$(DATABASE_URL)?sslmode=disable
      envFrom:
        - configMapRef:
            name: postgres-config
  containers:
    - name: recommandations
      image: recommandations:latest
      envFrom:
        - configMapRef:
            name: postgres-config

En el apartado anterior, elinitContainerno se detiene hasta que la base de datos acepte conexiones. Cuando lo hace, serecommandationsel contenedor puede comenzar. Kubernetes no necesita terminar elPodComo en la configuración anterior! implica menos registros y potencialmente menos alertas.

Cuando la espera se convierte en obligatoria

Lo anterior es una ligera mejora, pero se puede hacer sin ella.En otros casos, la espera se vuelve obligatoria.Lo experimenté recientemente cuando me preparaba para el taller mencionado anteriormente.El escenario es el siguiente:

y
• El gasoducto aplica un manifiesto en el lado Kubernetes
y
• En el siguiente paso, se lleva a cabo la prueba
y
• Como la prueba comienza antes de que se lea la aplicación, falla.
y

Debemos esperar hasta que el backend esté listo antes de probarlo.wait4xPara esperar a laPodPara aceptar solicitudes antes de lanzar las pruebas:

      - name: Wait until the application has started
        uses: addnab/docker-run-action@v3                                       #1
        with:
          image: atkrad/wait4x:latest
          run: wait4x http ${{ env.BASE_URL }}/health --expect-status-code 200  #2

y
1. La acción de GitHub permite ejecutar un contenedor. podría haber descargado el binario Go en su lugar.
y
2. Espere hasta que el punto final /health devuelva un código de respuesta de 200.
y

Conclusión

Las sondas de arranque de Kubernetes son una gran manera de evitar reinicios innecesarios al iniciar servicios que dependen unos de otros.initContainer. elwait4xes una herramienta que se puede usar en otros contextos. ahora es parte de mi cinturón de herramientas.

To go further:

y
• Espectáculos4x
y
• ¿Tienes que esperar por algunos recursos de Kubernetes?
y

Publicado originalmente en A Java Geek el 20 de abril de 2025