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. Getting up and running with Kubernetes 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.
Two of the creators of Kubernetes decamped from Google to form Heptio, 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, Heptio Ark and Heptio Sonobuoy. 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.
Kubernetes deployments are often modified heavily by vendors or by users, potentially rendering them incompatible with updates. Sonobuoy’s job is to discover whether those changes have created incompatibilities. The state of the cluster can also be dumped out and used for diagnostic reporting, and the tests run by Sonobuoy can be expanded by way of a plug-in architecture.
Sonobuoy is still in the early stages of development, though, as it doesn’t yet check for all the issues identifies in Kubernetes’s own conformance tests. The long-term plan is to keep it in close synchrony with the test suite created by the core Kubernetes team.
AppsCode, 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.
Kubed—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 an issue is open 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 Custom Resource Definitions (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 Kubicorn 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.
3 open source projects that make Kubernetes easier have 905 words, post on www.infoworld.com at 2017-08-09 03:33:05. This is cached page on Technology Breaking News. If you want remove this page, please contact us.