2

I have two containers，maybe A and B, which A should run before B, but A is a server application, which the final type is Running but not Complete, so I wonder in this way, will B be never executed? So how can I deal with it?

edselwang
  • 57
  • 8
  • 1
    Hi edselwang, can you clarify what you mean by "A should run before B?" Should A start before B? Should A run for several seconds before B? Should A finish executing before B starts? – supersam654 Oct 12 '19 at 01:54
  • Do you mean B is deponds on A, so it has to be started after A is functional ready? InitContainer is not the right choice, maybe you can take a look at [pod liveness/readiness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). – Hang Du Oct 12 '19 at 03:25
  • I mean that A should run for several seconds before B， because A is a server application so that the final type of A is Running，not Completed，maybe readiness probe is the answer for my question， I will try it latter. – edselwang Oct 14 '19 at 03:17

1 Answers1

3

If A and B are part of the same pod, then initContainer is the legacy way to establish ordering.

From the Kubernetes Pod lifecycle, I suppose you mean "Running, but no Terminated"

A pod liveness/readiness probe is in your case a better fit, since the server will not accept request until ready.

Read "Straight to the Point: Kubernetes Probes" from Peter Malina

Both readiness and liveness probe run in parallel throughout the life of a container.

  • Use the liveness probe to detect an internal failure and restart the container (e.g. HTTP server down).
  • Use the readiness probe to detect if you can serve traffic (e.g. established DB connection) and wait (not restart) for the container.

A dead container is also not a ready container.
To serve traffic, all containers within a pod must be ready.

You can add a pod readiness gate (stable from 1.14) to specify additional conditions to be evaluated for Pod readiness.

Read also "Kubernetes Liveness and Readiness Probes: How to Avoid Shooting Yourself in the Foot" from Colin Breck

"Should Health Checks call other App Health Checks" compares that approach with the InitContainer approach

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250