Kubernetes is one of the fastest-moving open source projects. Alpha, beta, and production-ready features seem to be released on a weekly basis, and just when you are in awe of a new feature, something even cooler comes out.
When you think of the Kubernetes ecosystem, you also need to consider other tangential projects. For example, in November, CoreOS (the same company that created etcd) released the operator concept, a primitive allowing users to easily install and manage applications such as etcd clusters or Prometheus . On January 10, a version of Flannel (one possible overlay network for Kubernetes) was released, allowing users to potentially use the k8s apiserver (in lieu of etcd) as a datastore . If you want to stay in the loop, I’d recommend subscribing to the GitHub release feeds and blogs for Kubernetes and related projects .
With my Kubernetes PSA out of the way, I’ll now chat about some of the interesting trends that myself and others have noticed regarding Kubernetes.
Simplifying Installation and Management
One of the most common complaints regarding Kubernetes has been the difficulty in the setup and installation process. Each Kubernetes cluster consists of setting up a etcd cluster, kube-apiserver, controller manager, and the scheduler. Furthermore, each node of the cluster requires a container runtime, kubelet, kube-proxy, a networking setup, and possibly an in-cluster DNS. TLS certificates are also often utilized to secure communication between each component of the cluster. Much of this setup is either done manually or via an infrastructure orchestration tool.
With the release of
kops, however, this became significantly easier.
kops is a tool that fully automates the creation of a Kubernetes cluster (currently supported on AWS), analogous to the way users of GKE are able to create one-click Kubernetes clusters . In other words,
kops handles infrastructure orchestration and installs all necessary software.
This isn’t, however, what every user requires. For those desiring automation but also a certain level of flexibility,
kubeadm is a far better option .
kubeadm does not (and will likely never) manage infrastructure provisioning, but can easily be integrated into an orchestration tool. Most excitingly,
kubeadm promises to become more modular and incorporate features such as component updates. As these changes come to fruition, users will have another mode by which they can have self-hosted Kubernetes clusters .
Another new tool related to cluster management, which takes everything a step further, is Kubernetes federated clusters—i.e. the concept of having a cluster of many clusters . Federated clusters are very similar to standard clusters; however, this time, the federated control plane manages different clusters. Cluster federation was introduced in v1.3, but increasingly, more resources have come to be federated, making this feature all the more powerful. Using federated ingress and replica sets, for example, your application will be truly HA and resilient to region-specific failures or data center failures.
Many organizations leveraging Kubernetes require extensibility and flexibility. Two new features, the container runtime interface (CRI), and third-party resources, are perfect examples of this.
Although Docker is one of the most popular container options, it does have notable flaws, and an increasing number of teams are looking to leverage alternatives such as rkt . With the advent of the CRI, Kubernetes users will easily be able to transition to different container runtimes with ease . Although this feature is very much in its infancy, it looks quite promising.
Third-party resources were released far earlier in comparison to the CRI, but I felt it vital to highlight this feature, as it has already been leveraged by a high-profile user . The aforementioned CoreOS operators leverage third-party resources to enable users to manage applications . Third-party resources are a way for users who wish to build on top of the Kubernetes API to create their own custom resource.
The final trend I want to highlight is Kubernetes resources that are stateful. Many of the earlier k8s resources (pods, daemonsets, replicasets) are ideal for stateless applications that can be created, destroyed, or restarted at will without relying on a stored state. Many users, however, require state. And with the creation of stateful sets, and eventually, the jobs resource, this became possible.
A stateful set (similar to a daemonset) creates several pods. Each pod, however, is given a unique ordinal index, a static hostname, and a static SRV record. If a pod from a stateful set is destroyed, it will be recreated with the same hostname, index, and SRV record, although the IP address may change. This is particularly useful, for instance, with applications with a scale greater than one, in which each instance needs an individual but static identification. Note that stateful sets may also be utilized along with persistent volumes.
Jobs are also another useful feature of Kubernetes . Unlike a single pod, a job that fails to complete is restarted until it successfully completes, within a deadline. This requires that jobs be idempotent, but is far more useful than, for example, the average manual one-off job. Scheduled jobs also became available in v1.4, and, similar to the standard jobs resources, can also retry a job upon failure, leverage parallelism, etc.
This post is by no means fully inclusive of all new Kubernetes features. In fact, there are several fairly cool features (such as init containers) which were not delved into here—but I highly suggest you investigate . Instead, I’ve chosen to highlight some emerging trends, and key areas that Kubernetes enthusiasts may want to watch.
About the Author
Sneha Inguva is an enthusiastic software engineer currently working on building developer tooling at DigitalOcean. She has worked at a variety of startups in the last few years, and has a unique perspective on building and deploying software in eclectic verticals (education, 3D printing, and casinos, to name a few). When she isn’t bashing away on a project or reading about the latest emerging technology, she is busy rescuing animals or practicing martial arts.
We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!