Short lived kubernetes container (/sidekick) in a pod (in a Replication Controller)

I have a ReplicationController containing two containers in a pod, the first is a long-living pod, the second does a few maintenance tasks when the RC starts up a POD. However as the second container is short lived, it stops itself when it finishes its start tasks.
When Kuberbetes notices this, it kills off the POD and starts a new one…

What is the correct way to handle this in Kuberbetes?

  • Is Docker running within WSL or connecting back to Windows?
  • Minimal delta between Docker images
  • Logstash with fluent input codec not working
  • how to communicate containers running in same machine using the host machine ip address
  • Collectd pushes the actual host system metrics to graphite instead of the docker container's restricted system metrics
  • How to get stdin from php for java docker container at runtime
  • How to allow HTTP requests to other docker containers with RSpec?
  • docker import data in mongodb successfull but nothing in database
  • docker push fails due to “unauthorized: authentication required”, using gitlab
  • docker cp from host to container is not working
  • Character encoding of the HTML document was not declared in docker Eureka
  • Docker: RUN pip install boto succeeds but is missing from the resulting image
  • One Solution collect form web for “Short lived kubernetes container (/sidekick) in a pod (in a Replication Controller)”

    As you already noticed, by design all containers in a pod are destined to live and die together. It’s a bit hard to tell what your best alternative would be without knowing what kind of maintenance task your sidekick needs to perform exactly. Generally speaking, I can think of three approaches:

    1. Keep your maintenance container running. This is probably a fairly ugly solution as it wastes resources. It really only makes sense if the maintenance task can benefit from running periodically.

    2. Move the maintenance task over to your primary container, effectively converting your multi-container pod into a single-container one. I assume that you can run the task asynchronously (as you would already be able to run it in a separate container); if, for some reasons, you cannot, consider modifying readiness and liveness probes accordingly so that your container is given enough time to finish any boot-up procedures before becoming eligible for termination.

    3. Consider adjusting your design so that the maintenance task may run as a separate pod (or maybe even as a job). You’d then need to manage any dependencies and wiring yourself by putting together Kubernetes primitives properly.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.