Applying Machine Learning to DevOps

Kubernetes is King when it comes to container orchestration, but it's still lacking! Where are the de-init containers when you need them?

Written by Rory Savage in October 13, 2018   |   Link

Everyone will agree that Kubernetes is the King of container orchestration in the datacenter, cloud, lab, or just about anywhere you have the need for container management. Why? Well, to put simply, Kubernetes offers many features that makes life easy when it comes to container management and orchestration. In today's blog entry, I want to emphasize on the orchestation aspect. Where Kubernetes shines, and where it's lacking. (I realize with that statement, I am aready opening myself up to criticism) -- but I seriously don't care because what I am about to highlight makes perfect sense and hopefully dear kubelings, you will agree.

When it comes to orchestration Kubernetes offers many cool features for PODs, such as init containers and pod-lifecycle hooks. Let's talk about init containers, why and what they can do. With init-containers, a POD can have those containers run before the app containers are started. These init containers always run to completion (also, you can chain these init containers together so that each one must complete sucessfully before the next one is started.) In other words, you can have prep-1 container start before prep-2, etc, etc... and they all have to succeed prior to the application container starting. How awesome is that? Maybe you need to have a series of prep-work done prior to the container start up? This would be ideal especially if the prep work was handled by code which could not live alongside the application code... brilliant!

Extending this concept even further, Kubernetes also includes a container-lifecycle-hook for container PostStart and PreStop. These hook handlers can execute a specific command such as a script in the respective container, or execute a HTTP request against a specific endpoint on the container. So this is really awesome! Meaning, let's say I have a complicated appication broken up into various microservices. One of my applications requires a reqistration process using code which can not live in the application container. This will be haneled by the init container concept mentioned about, and the PostStart lifecycle hooks.

While Kubernetes nailed it with init containers, and PostStart hooks, it's missing de-init containers! Perhaps I can't simply kill off the POD when we are through with it, perhaps we also have to go through a series of deregiration processes? This is where Kubernetes falls short. Why have the dual concept of init containers and PreStart hooks, but not include the same duality for termination? Why not have de-init containers which offers the same funcationality and behavior as init containers?

Docker-In-Docker: An ungly work-around for Kubernetes' lack of de-init containers

I can not go into great detail as to what I am trying to accomplish, you will just have to take my word for it: simply put -- my application containers can not share the same code as the code which performs the registration/deregistration processes. While the init-container feautre of Kubernetes nails it, not having a de-init container means it's time to get creative. So I have turned to Docker In Docker. Esentially what I am doing is on POD termination, I am having the PreStop container life-cycle event, fire a secure script which in returns, re-calls the same init-container used in the application registration process, and then deregister the container from the system. It works, and works well, but it's not ideal. For those of you struggeling with the same problem, this is a work around which works for me -- and perhaps it can work for you as well, at least until Google with all of their wisdom adds de-init containers to the K8S framework. :)