Container per sidecar in Kubernetes Jobs?

Question

Utilizziamo Kubernetes Job s per un sacco di computer di compilazione qui e mi piacerebbe impostare ogni lavoro con un sidecar di monitoraggio per aggiornare un sistema di tracciamento centralizzato con lo stato di avanzamento di un lavoro.

L'unico problema è che non riesco a capire quale sia la semantica (o si suppone che sia) di più contenitori in un lavoro.

ho dato un colpo in ogni modo (con un alpine sidecar che stampate "ciao" ogni 1 sec) e dopo il mio compito principale completato, i Job s sono considerati Successful ed il kubectl get pods in kubernetes 1.2.0 spettacoli:

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 

E se descrivo uno di quei baccelli

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 

Poi GET ing l'yaml del lavoro mostra informazioni per contenitore:

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 

Quindi sembra che il mio sidecar avrebbe bisogno di guardare il processo principale (come?) Ed uscire con garbo una volta che rileva che è solo nel pod? Se questo è corretto, allora ci sono le migliori pratiche/schemi per questo (se il sidecar esce con il codice di ritorno del container principale? Ma come fa a ottenerlo?)?

** Aggiornamento ** Dopo ulteriori sperimentazioni, ho anche scoperto i seguenti: Se ci sono due contenitori in un baccello, allora non è considerato di successo fino a quando tutti i contenitori nel ritorno pod con codice di uscita 0.

Inoltre, se restartPolicy: OnFailure è impostato sulla specifica pod, qualsiasi contenitore nel pod che termina con un codice di uscita diverso da zero verrà riavviato nello stesso pod (questo potrebbe essere utile per un sidecar di monitoraggio per contare il numero di riprovare ed eliminare il lavoro dopo un certo numero (per risolvere il problema non ci sono max-tentativi attualmente disponibili nei lavori di Kubernetes)).

Answer 1

È possibile utilizzare downward api per individuare il proprio podname all'interno del sidecar e quindi recuperare il proprio pod dal server di apis per cercare lo stato esistente. Fammi sapere come va.