Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

192
Vistas
Kubernetes no respeta initialDelaySeconds al iniciar

He configurado un pod de la siguiente manera:

 livenessProbe: initialDelaySeconds: 60 periodSeconds: 10 failureThreshold: 3 readinessProbe: initialDelaySeconds: 60 periodSeconds: 10 failureThreshold: 3

Las sondas Readiness y Liveness están basadas en tcp-socker

 readinessProbe: tcpSocket: port: {{ .Values.port }} initialDelaySeconds: {{ .Values.readinessProbe.initialDelaySeconds }} periodSeconds: {{ .Values.readinessProbe.periodSeconds }} failureThreshold: {{ .Values.readinessProbe.failureThreshold }}

Sin embargo, cuando implemento, el pod se marca casi de inmediato como failed y aparece Error --> CrashLoopBackOff . El pod verifica una conexión redis (que de hecho necesita un poco de tiempo para estar lista).

Y, por supuesto, veo los errores de conexión en los registros de mi pod.

 File "/usr/local/lib/python3.9/site-packages/redis/connection.py", line 563, in connect raise ConnectionError(self._error_message(e)) redis.exceptions.ConnectionError: Error 111 connecting to redis-master:6379. Connection refused.

¿Por qué el pod se marca con tanta ansiedad en Error /CLBO, mucho antes initialDelaySeconds: 60 ?

Aquí está el volcado de yaml del pod con respecto a las sondas (aumenté el initialDelaySecond para ambas sondas a 100, pero sigue igual...)

 livenessProbe: failureThreshold: 3 initialDelaySeconds: 100 periodSeconds: 10 successThreshold: 1 tcpSocket: port: 9898 timeoutSeconds: 1 name: mycontainer ports: - containerPort: 9898 protocol: TCP readinessProbe: failureThreshold: 3 initialDelaySeconds: 100 periodSeconds: 10 successThreshold: 1 tcpSocket: port: 9898 timeoutSeconds: 1
over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

initialDelaySeconds : Número de segundos después de que el contenedor se haya iniciado antes de que se inicien las sondas de actividad o preparación.

Ahora, el pod puede fallar debido a CrashLoopBackOff incluso antes de iniciar las sondas. Este es el concepto aquí . Puede ocurrir si establece el contenedor restartPolicy en Never .

Puede ver los registros o eventos del pod para obtener el motivo de la falla del pod (puede usar kubectl describe <pod> )

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda