Canonical Bolsters Kubernetes Availability
Canonical has added support for high-availability across multiple instances of MicroK8s, a lightweight instance of Kubernetes designed to be employed in edge computing scenarios or on workstations to advance development of containerized applications that will later be deployed on a larger Kubernetes cluster.
MicroK8s already makes it possible to cluster together multiple instances of MicroK8s. Now Canonical has extended that capability by embedding its Dqlite distributed SQL engine within its distribution of Kubernetes. That approach not only ensures a data store for stateful applications is always available in a distributed computing environment, but it also reduces the memory footprint of the cluster.
The MicroK8s distribution of Kubernetes provided by Canonical is free and can run on any distribution of Linux. Canonical delivers MiroK8s as a Snap, a method for packaging software using containers developed by Canonical. The company also leverages Snaps to create the Charmed Distribution for Kubernetes, which adds a collection of YAML files and hooks to make it easier to deploy Kubernetes with other associated technologies and applications packaged as Snaps on any public or private cloud based on virtual machines or bare-metal servers. For example, IT teams can use Charmed Distribution for Kubernetes to deploy either Dqlite or databases such as Oracle, SQL Server, MySQL and Postgres running in cloud computing environments as an alternative to the etcd key/value data store.
Greg Elkinbard, director of field engineering for Canonical, says Snaps also provides containers access to a shared file system. Today most containers are packaged with their own file system. However, he notes, in many instances, containers can share a file system, which shrinks the size of the containers. The portability of those containers is guaranteed by Kubernetes and the ability to run Snaps on multiple distributions of Linux.
In general, Elkinbard notes Docker containers are only one type of container in IT environments. Each container type accesses the same basic set of primitives. IT organizations will learn to mix and match Dockers containers, Snaps and eventually the container engine known as CRI-O optimized for Kubernetes as they best see fit, says Elkinbard.
Containers have, of course, been around for decades. Docker leveraged the concept of containers to create a highly portable alternative to relying on virtual machines. However, as container technologies evolve, interest in finding smaller alternatives to Docker containers is on the rise. IT teams are especially keen to deploy containerized applications on the network edge, where compute resources are often limited.
It may take a while for the relationships between all the container formats are fully formed. However, the next wave of containerized applications will, in many instances, be running on instances of Kubernetes that are smaller than the Docker containers widely deployed today. In many cases, those smaller distributions of Kubernetes will replace larger distributions of Kubernetes in the data center and on public clouds as well. After all, the first generation of any platform inevitably gets optimized to make maximum use of all the compute resources available.
