Recientemente, mientras trabajaba en un taller titulado , 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. Prueba de su solicitud de retiro en Kubernetes con acciones de GKE y GitHub 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. El Estado. Failed 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 ofrece : de Inicio Proba 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 Kubernetes ofrece dos exclusivos Configuración de configuración: o El 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. Se ve lo siguiente cuando se aplica: /health Prueba httpGet exec Bitnami Helm gráfico 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 mucho La idea es simple, la idea es sencilla: Espera por y y ./wait-for es un script diseñado para sincronizar servicios como contenedores de docker. Es sh y alpino compatible. Es un script diseñado para sincronizar servicios como los contenedores de docker. y y compatibles. ./wait-for sh alpine 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. desempeñ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. Espectáculos4x Cualquiera que sea la herramienta que utilices, puedes usarla dentro de un : de Inicio Contenedores y y y 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. 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 siguiente Esto depende de un PostgreSQL : de Pod Deployment 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 un y un contenedor de espera: initContainer 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, el no se detiene hasta que la base de datos acepte conexiones. Cuando lo hace, se el contenedor puede comenzar. Kubernetes no necesita terminar el Como en la configuración anterior! implica menos registros y potencialmente menos alertas. initContainer recommandations Pod 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 y y y El gasoducto aplica un manifiesto en el lado Kubernetes En el siguiente paso, se lleva a cabo la prueba Como la prueba comienza antes de que se lea la aplicación, falla. Debemos esperar hasta que el backend esté listo antes de probarlo. Para esperar a la Para aceptar solicitudes antes de lanzar las pruebas: wait4x Pod       - 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 y y La acción de GitHub permite ejecutar un contenedor. podría haber descargado el binario Go en su lugar. Espere hasta que el punto final /health devuelva un código de respuesta de 200. Conclusión Las sondas de arranque de Kubernetes son una gran manera de evitar reinicios innecesarios al iniciar servicios que dependen unos de otros. . el es una herramienta que se puede usar en otros contextos. ahora es parte de mi cinturón de herramientas. initContainer wait4x To go further: y y y Espectáculos4x ¿Tienes que esperar por algunos recursos de Kubernetes? Publicado originalmente en A Java Geek el 20 de abril de 2025 El nuevo Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Make resilience your competitive advantage

Esperar: el arte sutil que debes dominar

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps