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.