In Kubernetes version 1.7, the container orchestration and management system is gaining slew of new security, stateful application, and extensibility features
Kubernetes 1.6 was mainly about stabilising and bringing to term long-planned changes, such as using version 3 of the ETCD distributed key-value store. But many of Kubernetes 1.7’s new features are only in the alpha stage, more signals of how Kubernetes is trying to be more useful in a broader range of scenarios. Other new capabilities bring in features previously relegated to other parts of the container ecosystem.
Storage and state
Several updated features in Kubernetes 1.7 revolve around managing persistent state. The most common way to do that is to associate running groups of containers (“pods” in Kubernetes parlance) with different kinds of storage volumes: NFS shares, iSCSI targets, or storage at cloud services such as Amazon Web Services or Azure.
Kubernetes 1.7 adds the ability to map a local storage device as well, a convenient way to let a pod workload access data on the same system where running Kubernetes’s native APIs.
Still, the use of local storage doesn’t seem wise in a lot of Kubernetes scenarios. It looks like it will be most useful for quick-and-dirty applications, or single-system development nodes like those spun up with Minikube. Also, right now many aspects of Kubernetes 1.7’s local storage are primitive or flaky. For example, it does not yet allow local block devices as a volume source. But the long-term plan appears to make local storage a first-class citizen among Kubernetes’s other storage solutions.
Another change to Kubernetes’s state-handling is around managing applications that have persistent state. StatefulSets, used to handle state across an application pod, now has the Updates feature to allow stateful applications—like Kubernetes’s own ETCD—to be updated automatically, but without the update process compromising their state.
Security and secrets
Applications often need to keep “secrets,” or pieces of data associated with the application that should not be transmitted or stored in plaintext. API keys or service passwords are often used as secrets. Kubernetes 1.7 can now store secrets in namespaces, encrypted at rest. It can also control which pods can talk to what secrets by way of the new node authoriser addition.
This feature, while also promising, is still also only alpha-quality right now. Any secrets trusted to it in its current incarnation may have to be decrypted and re-encrypted before upgrading to a post-1.7 version of Kubernetes.
Other products, such as Docker Datacenter, can store secrets used in containers. You could use Kubernetes 1.7’s secrets system instead, but odds are in the long run it will be a complementary technology, not a replacement. Efforts are under way to create or enhance Kubernetes’s integrations with third-party vault products like Hashicorp Vault and Cyberark for secrets storage.
In Kubernetes 1.7, some previously beta security functions are now stable. The Network Policy API, for example, allows for rules that control how pods can communicate with each other, via plug-ins for Kubernetes’s networking subsystem.
Extensibility
Kubernetes has long used a system called the Third Party Resource (TPRs) to allow developers to add their own APIs. Version 1.7 has a new implementation of the same idea, the Custom Resource Definition (CRD), to make defining custom APIs a little less clunky. Your existing TPRs won’t be touched when you migrate to Kubernetes 1.7, but TPRs will be deprecated by Kubernetes 1.9, so it’s best to migrate any existing TPRs to CRDs now.
Another major extensibility change in Kubernetes 1.7 is API aggregation. It lets advanced Kubernetes developers add their own APIs to the cluster, in a deeper and more normative way than CRDs do.
Eric Chiang, software engineer at CoreOS, explains the difference between the two features this way: “CRDs are a lightweight way of having Kubernetes allocate scratch space in the existing API for custom resources. Aggregation is a completely pluggable way to customise Kubernetes’s API handling, such as specialised resource validation or ACL filtering not available for core resources.” He expects the majority of Kubernetes-native projects to continue to use CRDs, and a few large, “opinionated” projects to use aggregation.
Another set of refinements in Kubernetes 1.7 involves the Container Runtime Interface. This API lets container runtimes like Docker talk to Kubelet, the application Kubernetes uses to run each node in a cluster, so different runtimes do not need to each be integrated by hand with Kubernetes.
Docker may still be the de facto standard for container runtimes, but the makers of Docker and others have worked hard to decouple the runtimes from the container ecosystem as a whole. Features like this in Kubernetes 1.7 show that work has not stopped yet
IDG News Service
Ltd
