Python Kubernetes Initializer
The goal of this project is to make it very easy to write an initializer for Kubernetes 1.7.
If you're interested in editing the project, see the developer getting-started page.
Example initializers are in the examples folder.
This library is written using Python 3.6, and isn't distributed as a Python 2 package. Much of it should work in Python 2.
The main entrypoint is the
InitializerController, which wraps per-type
ResourceController is responsible for fetching resources of a specific type from the Kubernetes
API, handling them (per the initializer contract), and then updating them in Kubernetes. API
communication is delegated to the
ResourceHandler class, which has a few helper methods for
creating common API objects.
The Dangers of Pod Initializers
Controller-Created Pods Require Initialization
When an initializer is created on pods, all pods created through the API are affected. This includes pods created by built-in controllers, like the Job controller and the ReplicaSet controller.
Because of this, it's important to design any pod initializer to be low-latency, and to handle both
kubectl) pods, as well as automatically-created pods.
Unbounded Pod Creation
As of Kubernetes 1.7, the API server will wait for all initializers to complete before returning a newly-created object. This means that slow or failing initializers will result in a client-side timeout during object creation.
Some controllers (like the Job controller) will retry creation indefinitely on client error, including for timeouts. This means that a pod-targeted initializer that's slow or broken can result in an unbounded number of pods awaiting initialization. Because of this, you should be careful assigning an initializer to pods, and should be very sure that it's robust if you do. You also should ensure your initializer is looking for uninitialized pods frequently enough that clients won't time out.