monitoring - son - Contenedores sidecar en Kubernetes ¿Trabajos?

que es un pod docker

Question

Usamos los Job Kubernetes para una gran cantidad de cómputo por lotes aquí y me gustaría instrumentar cada trabajo con un sidecar de monitoreo para actualizar un sistema de seguimiento centralizado con el progreso de un trabajo.

El único problema es que no puedo entender qué son las semánticas (o se supone que son) de varios contenedores en un trabajo.

De todos modos, le di un tiro (con un sidecar alpine que imprimió "hola" cada 1 segundo) y después de que mi tarea principal se completó, los Job se consideran Successful y los kubectl get pods en Kubernetes 1.2.0 muestra:

NAME READY STATUS RESTARTS AGE
job-69541b2b2c0189ba82529830fe6064bd-ddt2b 1/2 Completed 0 4m
job-c53e78aee371403fe5d479ef69485a3d-4qtli 1/2 Completed 0 4m
job-df9a48b2fc89c75d50b298a43ca2c8d3-9r0te 1/2 Completed 0 4m
job-e98fb7df5e78fc3ccd5add85f8825471-eghtw 1/2 Completed 0 4m

Y si describo una de esas vainas.

State: Terminated
Reason: Completed
Exit Code: 0
Started: Thu, 24 Mar 2016 11:59:19 -0700
Finished: Thu, 24 Mar 2016 11:59:21 -0700

A continuación, GET ing the yaml del trabajo muestra información por contenedor:

 status:
conditions:
- lastProbeTime: null
lastTransitionTime: 2016-03-24T18:59:29Z
message: ''containers with unready status: [pod-template]''
reason: ContainersNotReady
status: "False"
type: Ready
containerStatuses:
- containerID: docker://333709ca66462b0e41f42f297fa36261aa81fc099741e425b7192fa7ef733937
image: luigi-reduce:0.2
imageID: docker://sha256:5a5e15390ef8e89a450dac7f85a9821fb86a33b1b7daeab9f116be252424db70
lastState: {}
name: pod-template
ready: false
restartCount: 0
state:
terminated:
containerID: docker://333709ca66462b0e41f42f297fa36261aa81fc099741e425b7192fa7ef733937
exitCode: 0
finishedAt: 2016-03-24T18:59:30Z
reason: Completed
startedAt: 2016-03-24T18:59:29Z
- containerID: docker://3d2b51436e435e0b887af92c420d175fafbeb8441753e378eb77d009a38b7e1e
image: alpine
imageID: docker://sha256:70c557e50ed630deed07cbb0dc4d28aa0f2a485cf7af124cc48f06bce83f784b
lastState: {}
name: sidecar
ready: true
restartCount: 0
state:
running:
startedAt: 2016-03-24T18:59:31Z
hostIP: 10.2.113.74
phase: Running

¿Entonces parece que mi sidecar debería ver el proceso principal (¿cómo?) Y salir con gracia una vez que detecta que está solo en la cápsula? Si esto es correcto, entonces ¿hay mejores prácticas / patrones para esto (debería salir el sidecar con el código de retorno del contenedor principal? ¿Pero cómo lo consigue?)

** Actualización ** Después de una experimentación adicional, también descubrí lo siguiente: Si hay dos contenedores en un pod, entonces no se considera exitoso hasta que todos los contenedores en el pod regresen con el código de salida 0.

Además, si restartPolicy: OnFailure se establece en la especificación del pod, entonces cualquier contenedor en el pod que termine con un código de salida distinto a cero se reiniciará en el mismo pod (esto podría ser útil para que un sidecar de monitoreo cuente el número de reintentos y elimine el trabajo después de un cierto número (para solucionarlo, no hay un máximo de reintentos disponibles actualmente en los trabajos de Kubernetes)

Answer 1

Puede usar la api hacia abajo para averiguar su propio nombre de pod desde el sidecar, y luego recuperar su propio pod desde el apiserver para buscar el estado existente. Déjame saber cómo va esto.