Podman to the Rescue?
Kubernetes is overkill for so many scenarios. The kubernetes api, on the other hand, is driving a surge of innovation by introducing important container patterns such as “pods”, “deployments”, and standardizing operational concepts like “liveness” & “readiness”. These capabilities are also being used to drive innovation in the Kubernetes (aka ‘K8s’) ecosystem. Examples include: helm, istio, calico, garden.io, Open Policy Agent (OPA), k3s, etc.
All of these ecosystem projects embrace kubernetes in all it’s glory.
Podman, however, is moving in a different and intriguing direction — using only the K8s api as a bridge to another runtime architecture. An architecture that is much simpler and easier to design for and manage than standard kubernetes.
For many apps, this capability could become a point-of-compatibility allowing the decision to use kubernetes to be delayed until the scale of the app (or the maturity of kubernetes ) justifies the move.
Despite the valuable innovation in the K8s ecosystem, operating Kubernetes is not trivial. There are many reasons it may not be the right answer. Here is one typical quote from a recent Datanami article:
“In Singla’s view, Kubernetes is an essential component for running complex apps at large scale, but it’s not usable by everybody, and it’s not necessary for every application. “I think it might be overkill, is the right word,” he said.”
There are similar opinions shared among practitioners on Twitter.
What if you had 100s of distributed IOT assets that each needed to run a handful of containers on a single host per device?
Will you really run kubernetes on each device?
Will you consume and automate the management of all the k8s abstractions for cluster-security, cluster-networking, cluster-volume-provisioning, cluster-patching, and cluster-debugging, etc? … I’ll also point out, you don’t even have a cluster!
The screenshot above shows the default components installed for “single node kubernetes” using Microk8s:
Despite all the marketing blurbs, it seems that some simplification is still possible.
If you want to see all horses in the “K8s Race to Simplicity”, this blog post is excellent. It discusses all these alternatives.
It is clear that “The Docker-Compose” model is a much better fit in the single IOT host scenario. For example, Volumes & Ports are directly mapped to the host rather than virtualized. Here is the entire yaml required for a simple webapp and database using compose:
So how can we leverage this simple, sustainable “Compose” model and avoid the complexity of the “Simplified Kubernetes” alternatives? How can we maintain optionality and some compatibility with Kubernetes while using a different runtime?
Luckily, Podman appears to offer an answer. It is much simpler for running containers on a single host — much closer to the compose model. It also supports running “pods” and “deployments”!
Here is an excerpt from the podman github readme:
“We believe that Kubernetes is the defacto standard for composing Pods and for orchestrating containers, making Kubernetes YAML a defacto standard file format. Hence, Podman allows the creation and execution of Pods from a Kubernetes YAML file (see podman-play-kube). Podman can also generate Kubernetes YAML based on a container or Pod (see podman-generate-kube), which allows for an easy transition from a local development environment to a production Kubernetes cluster. If Kubernetes does not fit your requirements, there are other third-party tools that support the docker-compose format such as kompose and podman-compose that might be appropriate for your environment.” — https://github.com/containers/podman
Since Podman can create and consume a k8s Pod.yml it creates a Win-Win for engineers and operators who recognize the value of simplicity and the importance of staying close to a ‘defacto standard’ for defining multi-container deployments.
Podman may never be a ‘drop-in’ replacement for kubernetes (the compatibility isn’t targeted for 100%). However, if you are looking to keep kubernetes within reach as a long-term option — or just want to use k8s in dev & non-prod environments, but then take advantage of a simpler platform and operational model for your IOT hosts then Podman could be an interesting option.
Thoughts?
