« Previous 1 2 3 4 5
When are Kubernetes and containers not a sensible solution?
Curb Complexity
Containers, Kubernetes, Rancher, OpenShift, Docker, Podman – if you have not yet worked in depth with containers and Kubernetes (aka K8s), you might sometimes get the impression that you have to learn a completely new language. Container-based orchestrated fleets with Kubernetes have clearly proven that they are not a flash in the pan, but all of this omnipresent lauding of containers is getting on the nerves of many. Whichever provider portfolio you assess, it seems that the decisive factor for success is answering a simple question: How do I get my entire portfolio cloud-ready as quickly as possible?
The problems and challenges inherent in containers and K8s are too often forgotten. I address this article to all admins who still view the container hype with a healthy pinch of skepticism. In concrete terms, the question is what are the use cases in which containers do not offer a meaningful alternative to existing or new setups. When does it make more sense to avoid the technical overhead of migration because a particular case will (hardly) benefit from migrating anyway?
Ceph as a Negative Example
If you are in an environment far removed from a greenfield, you can face some disadvantages. Ceph, the distributed object storage solution, is one example. If you believe the vendor Red Hat, containerized deployment is now the best way to roll out Ceph. All of the Ceph components come in the form of individual containers, which cephadm
then force-fits on systems.
This arrangement is all well and good, but if you are used to working with Ceph and then try to run a simple ceph -w
at the command-line interface (CLI) to discover the cluster status, you are in for a nasty surprise: Command not found
is what you will see in response. Logically, if all of the Ceph components are in containers, so are Ceph's CLI tools (
Buy this article as PDF
(incl. VAT)