Estoy usando la imagen acoplable de janusgraph: https://hub.docker.com/r/janusgraph/janusgraph En mi implementación de kubernetes para inicializar el gráfico remoto usando un script maravilloso montado en docker-entrypoint-initdb.d
Esto funciona como se esperaba, pero en caso de que el host remoto no esté listo, el contenedor janusgraph arroja una excepción y aún está en modo de ejecución.
Debido a esto, Kubernetes no intentará reiniciar el contenedor nuevamente. ¿Hay alguna manera de que pueda configurar este contenedor de janusgraph para que finalice en caso de alguna excepción?
Se podría emplear un readinessProbe aquí con un comando como janusgraph show-config o algo similar que saldrá con el código -1
spec: containers: - name: liveness image: janusgraph/janusgraph:latest readinessProbe: exec: command: - janusgraph - show-config Kubernetes finalizará el pod si falla el readinessProbe . Aquí también se podría usar un livenessProbe , en caso de que este módulo deba cerrarse si el host remoto alguna vez deja de estar disponible.
Considere habilitar las métricas del servidor JanusGraph, que luego podrían usarse con Prometheus para un monitoreo adicional o incluso con el mismo livenessProbe .
Como mencionó @Gavin, puede usar sondas para verificar si los contenedores funcionan. Liveness Probes se utiliza para saber cuándo fallan los contenedores. Si un contenedor no responde, puede reiniciar el contenedor.
Las sondas de preparación informan cuando el contenedor está disponible para aceptar tráfico. La sonda de preparación se usa para controlar qué pods se usan como backends para un servicio. Se considera que un pod está listo cuando todos sus contenedores están listos. Si un pod no está listo, se elimina de los puntos finales de servicio.
Kubernetes admite tres mecanismos para implementar sondas de actividad y preparación:
1) realizar una solicitud HTTP contra un contenedor. Estas sondas tienen campos adicionales que se pueden configurar en httpGet :
host: nombre de host al que conectarse, el valor predeterminado es la IP del pod. Probablemente desee configurar "Host" en httpHeaders en su lugar.scheme: Esquema a usar para conectarse al host (HTTP o HTTPS). El valor predeterminado es HTTP.path: Ruta de acceso en el servidor HTTP. El valor predeterminado es /.httpHeaders: encabezados personalizados para establecer en la solicitud. HTTP permite encabezados repetidos.port: Nombre o número del puerto al que acceder en el contenedor. El número debe estar en el rango de 1 a 65535.
Leer más: http-probes .
livenessProbe: httpGet: path: /healthz port: liveness-port2) abrir un socket TCP contra un contenedor
initialDelaySeconds: 15 livenessProbe: ~ periodSeconds: 20 port: 8080 tcpSocket: ~3) ejecutar un comando dentro de un contenedor
livenessProbe: exec: command: - sh - /tmp/status_check.sh initialDelaySeconds: 10 Si obtiene un código de estado diferente a 0, significará que la sonda falló. También puede agregar a las sondas parámetros adicionales como initialDelaySeconds : indica el 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. Consulte: configuración de sondas .
En todos los casos, agregue también restartPolicy: Never a la definición de sus pods. Por defecto es siempre.