“Three Amigos” - Docker, Kubernetes, CloudManager - Friends Indeed

Panic is in the air! The recent announcement that Kubernetes is deprecating support for Docker, has created some confusion in the community. Kubernetes and Docker leads, and community experts more broadly, where quick to clarify matters and reduce anxiety about what does it mean, and how and what it affects. We want to contribute to that clarification further, and add some reasons why Docker and Kubernetes continue to be good friends, and why additional tools like Cloud Manager can further enhance and extend that friendship.

Multi-Cluster CDN

What’s Changing?

Kubernetes as a container orchestration runtime is made of many different moving parts. The container runtime proper, responsible for pulling images from a registry and running containers, is a core component but not the only one. Until now, Kubernetes has been using Docker for that. This is what is changing. Docker is being deprecated in favor of other runtimes, which are more light-weighted and more compliant with standards such as the Container Runtime Interface (CRI). Like Kubernetes, Docker is made of several moving parts. Beyond the container runtime proper, other components exist which are more UX centric, and are not really needed by Kubernetes. Overall, Docker components and interfaces were created long before Kubernetes was a thing, so this development is not fully unexpected. At the technical level, the main reason for this deprecation notice is that a custom adapter had to be created to interface Kubernetes with Docker (dockershim), since the native interface exposed by Docker is not fully CRI compliant.

Does this affect people and organizations that are currently using Docker and/or Kubernetes, and the way they setup their pipelines? Only marginally… Container images created with Docker will still continue to be fully compatible with Kubernetes future runtime(s). What may change is the settings used when provisioning or operating Kubernetes clusters, both in third-party provider clouds and on-premises.

On the other hand, the move is suggestive that Kubernetes can be used without Docker in the loop. Other tool for building images, setting up CI/CD pipelines, and managing containers, become on-par alternatives to Docker.

Empowering Docker Desktop with Cloud Manager

All this said, Docker is not going away any time soon. The availability of Docker Desktop, which can be used to setup a Kubernetes pseudo-cluster in the developer/tester/devops laptop seemly, makes it a desirable tool and environment for development of container-based solutions. This allows experimentation and testing of cloud-native applications and microservice architectures in a local environment, similar to the one in place for cloud deployments (in production or otherwise).

What is missing in Docker Desktop is a fancy way to deploy apps and services, and interact with the resources in the local Kubernetes pseudo-cluster. For this, Docker stack assumes that other tools in the Kubernetes ecosystem will be used (command-line or web-interactive).

This is where Cloud Manager, an enhanced web dashboard for Kubernetes, comes in. Cloud Manager is designed from the ground-up to support multiple clusters, possibly from different cloud-providers. And it can be used also to manage the local pseudo-cluster setup by Docker Desktop. This means that it can be used as a further help and in alignment with Docker Desktop main purpose, of providing a seemly experience in moving from the local dev-test environment to the cloud (or on-premises real clusters). In fact, Cloud Manager provides a complete visual environment to perform a variety of tasks missing in Docker Desktop, and somewhat spread thin across different other tools, including: deploying apps without need to write complex manifest files, troubleshoot deployments by checking logs and tweaking configuration, deploy services from marketplace catalogs, setup simplified CICD pipeline based on Tekton, and more.

Lunching Cloud Manager – Practical Walk-through

Lunching Cloud Manager with Docker is super simple, and connecting to the local Kubernetes pseudo-cluster likewise. Type the command-line below:

docker run -p5005:2500 einnovator/einnovator-devops cm -d

This runs the latest version of Cloud Manager in a docker container named cm. Open the web browser in URL http://localhost:5005 to access the console and get started. You are asked to setup the admin account. Type admin as username, admin123 (or your favorite) as password, and type your email (case you forget the pass).

With basic settings Cloud Manager runs in single-user mode (for smaller resource usage footprint). It also uses an embedded database HSQLDB for local persistence (e.g. to store cluster access credentials, catalogs info, and other data.) To preserve the state of the database after you shutdown and restart Cloud Manager, you can use a Docker volume from a host directory, as follows:

docker run -v /tmp/devops:/data -p5005:2500 einnovator/einnovator-devops cm -d

Connecting to Local Cluster

You can connect to the local pseudo-cluster setup by Docker Desktop from Cloud Manager by clicking Add Cluster. The credentials to the local cluster are stored in the YAML configuration file .kube/config, under your home folder. Type cat ~/.kube/config from the terminal to view the content. In WindowsOS, should be cat ~\.kube\config. Select as credential type Certificate, and copy&paste the following info from the config file:

Name: docker-desktop
Server URL: https://kubernetes.docker.internal:6443
certificate-authority-data: (encoded CA certificate)
client-certificate-data: (encoded user certificate)
client-key-data: (encoded user private key)

Click Save, and you are done. You should see the Cluster dashboard page showing the node list of the cluster – which includes, in this case, only your laptop.

From Local to the Cloud

With Cloud Manager up&running, and connected to your local pseudo-cluster, you are free to start exploring and doing useful work. You deploy, manage, and troubleshoot your apps (without needing manifest files), install support services (e.g. DBs and message-brokers), setup CICD pipelines, and pretty much anything needed to test your apps and architecture locally.

Once you apps are ready to deploy to the cloud (or other on-premises cluster), you can import additional clusters. If you are felling lazy, you can recreate your deployments and settings to the clusters by indulging in extensive copy&paste from the local cluster. Alternativelly, you can repeating the same steps as done for the local cluster.

Wrapping Up, Going Forward

I’ve echoed the message of thes Kubernetes and Docker leads, by highlighting that the recent announcement of deprecation of Docker as a Kubernetes runtime is less reason to worry about that it might seams at first from the headlines. Docker and Kubernetes will continue to be invaluable tools and runtimes (even if not strictly essential) to realize your cloud evolution. Tools like Cloud Manager, an advanced dashboard for Kubernetes, further reinforce the view that Kubernetes ecosystem remains healthy and fully-integrated. Furthermore, the transition from local development&test environment to cloud environments, as championed by Docker Desktop, is well supported by tools like Cloud Manager as well.