Clearly, Kubernetes is an elegant solution to an important problem. Kubernetes allows us to run containerized applications at scale without drowning in the details of balancing loads, networking containers, ensuring high availability for apps, or managing updates or rollbacks. So much complexity is hidden safely away.
But using Kubernetes is not without its challenges. takes some work, and many of the management and maintenance tasks around Kubernetes are downright thorny.
As active as Kubernetes development is, we can’t expect the main project to solve every problem immediately. Fortunately, the community around Kubernetes is finding solutions to those problems that, for one reason or another, the Kubernetes team hasn’t zeroed in on.
Here are three new projects emerging around Kubernetes that set out to make the container orchestrator less knotty to deploy, maintain, work with, and oversee.
, a company with the stated mission of making Kubernetes easier to use. Rather than provide its own distribution of Kubernetes, as other vendors in the space have done, the company has focused on delivering open source tooling designed to enhance the experience of working with the original, upstream edition of Kubernetes.
Earlier this month, Heptio delivered its first projects, and . Ark is a disaster recovery system for Kubernetes clusters—a way to snapshot, back up, and restore container-based applications. Ark records the state of both Kubernetes API objects and Persistent Volume (PV) disks. The default example lets you work with an S3-compatible storage service (“Minio”), but Ark can make use of storage on all of the major cloud providers—Amazon Web Services, Google Cloud Platform, and Microsoft Azure.
What Ark does not yet do is provide a full lift-and-shift solution for moving an existing Kubernetes cluster between environments. For that, Heptio says, Ark will need to support the migration of persistent volume snapshots across cloud providers, a feature that isn’t there yet.
The other project, Sonobuoy, checks a given Kubernetes installation to see if it can pass the tests used to certify Kubernetes version releases.
, maker of a collaborative coding platform for containerized applications, recently released a project that helps fill in many of the gaps in managing a Kubernetes cluster.
—pronounced “Cube-dee” and short for “Kubernetes daemon”—bundles together a slew of useful functions into a single daemon process. Kubed can perform periodic cluster snapshots, provide temporary storage for deleted objects (in case you need them again), perform automatic event forwarding, deliver notifications via various channels, and more.
Kubernetes can also store log data in instances of Elasticsearch or InfluxDB, but cleaning up older data is the users’ responsibility. One Kubed feature, janitors, automates this process by cleaning up log data after a specified period of time. Kubed doesn’t yet support the ability to perform dry runs of such cleanups, but to add that functionality.
The Kubed project is currently in an alpha, unstable state, with many breaking changes planned for the future. Among the features in the works are support for Kubernetes’s recently rolled-out (CRDs) and making the Kubed API available via the Kubernetes User API Server, which Kubernetes provides to allow companion apps to extend its API set.
The project aims to help users build and manage infrastructure for Kubernetes on various cloud services. Like Puppet and other modern tools for managing infrastructure, Kubicorn has embraced a declarative philosophy: The user describes the state they want to see in their cluster, and Kubicorn makes sure the state of the cluster is kept in sync with that target.
Kubicorn is meant to work both as a stand-alone tool and as a library that can be invoked by other tools. By the same token, Kubicorn draws on existing tooling in Kubernetes, such as the kubeadm tool. As such, Kubicorn is meant to complement existing workflows rather than displace them.
A major part of Kubicorn’s approach is the use of snapshots. Kubicorn works by allowing a user to define the state of their cluster, apply that state atomically (if it doesn’t work, it’s rolled back), and to capture that state as a snapshot. Those snapshots can then be used for new deployments as well.
Note that Kubicorn is not an official Kubernetes project, and it is still considered to be experimental. It shouldn’t be used for production work.
But of course the time is ripe for experimenting with Kubernetes. You might want to bring Kubicorn, Kubed, and Heptio along for the ride.