Kubernetes 1.16 includes a potentially great new feature called ephemeral containers.
Here’s the premise…
Container images are on a crusade to become as small and lightweight as possible. For example, a well-built container should only host your application code and required dependencies. Everything else is unwanted baggage.
This is magic form a performance and security perspective. But it’s a pain-in-the-rear when it comes to troubleshooting!
Here’s an example…
You’ve got a Pod that keeps failing, so you exec (attach) to a container in the Pod to try and troubleshoot. The problem is… the container doesn’t have a shell or any of the common debugging tools like `ping` and `curl`.
This makes troubleshooting really hard.
Ephemeral containers to the rescue
Kubernetes 1.16 introduces ephemeral containers as an early alpha feature.
Ephemeral is just a fancy word for temporary — something that doesn’t last long. In regards to containers, an ephemeral container is one that’s only used for a short period before going away.
Also, anything that is alpha is hard to enable, hard to configure, and will change quite a lot before becoming a stable feature.
Anyway, back on track
Two important things about ephemeral containers:
- An ephemeral container will be based on an image that has all the troubleshooting tools you need
- Ephemeral containers can be inserted into existing Pods
These two facts combine to massively improve troubleshooting capabilities!
Because an ephemeral container starts inside a running Pod, it has access to all of the shared kernel namespaces of the Pod. Getting rid of the buzzwords, this means the ephemeral container can see everything the other containers can see. It may even be able to see inside of the other containers.
In practical terms, you can attach to the ephemeral container to introspect and troubleshoot the other containers in the Pod. The ephemeral container will have access to shared memory, shared volumes, and even the process namespaces of other containers in the Pod.
When you’re finished troubleshooting, it goes away (ephemeral).
A tiny bit of detail
An ephemeral container is a special construct (EphemeralContainer) in Kubernetes 1.16+ under the core/v1 API. As such, they’re treated differently to normal containers. We’ve already mentioned that they can be temporarily added to running Pods. As well as this, the following differences and limitations currently apply:
- They cannot have resource requests or limits
- They cannot have network ports
- They cannot have startup, readiness, or liveness probes
- They cannot have a security context
- They will never be restarted when they exit
Conclusion
Ephemeral containers are a great addition to the Kubernetes API and will become an indispensable troubleshooting tool.
At the time of writing, they’re an alpha feature and really hard to enable and work with. In the future, we might be able to spin them up and attach to them with a command as simple as:
`$ kubectl debug -it pod <pod name> sh`
KubeCon workshop
If you’re gonna be at KubeCon in San Diego in November, check out my workshop on Monday 18th. It’ll be a great way to get you started for the conference, as well as a chance for us to connect. See you there!
YouTube
I also did a video explaining ephemeral containers with props. Enjoy.https://www.youtube.com/embed/mQ60Jm4wgFU
Share this post:
