The Kubernetes team has released version 1.8, which focuses on improved security and better stability, and has moved the Workloads API to beta. New mature features include role-based access control (RBAC), support for volume mount options, allowing privilege escalation, and support for high-level volume operation metrics.
RBAC and network policies are two powerful features that enforce compliance and help meet regulatory and security requirements. The cluster administrator can use RBAC to define various levels of fine-grained access to users and applications (service accounts) based on their scope of Kubernetes API resources. Network policies provide the required level of isolation among pods in a heterogeneous cluster environment.
For example, if an application server (origin) is the only one which connects to database servers (destination), admins can apply two policies; a first policy on the database pod to only allow inbound traffic from the application pod on a specific port, and a second policy on the application pod to send traffic to the database pod on a specific port. This can be done on the basis of namespaces or CIDR. By default, all pods (such as frontend pod, backend pod, database pod, caching pod etc) in a Kubernetes cluster can communicate freely with each other without any restrictions.
Some of the notable features that have graduated to beta include support for outbound traffic filtering from a pod through network policies, configuring automatic transport layer security (TLS) certificate rotation for Kubelet and the Workloads API. The Kubernetes team indicated that the Workloads API "provides abstractions and a stable foundation for migrating existing workloads to Kubernetes as well as developing cloud-native applications that target Kubernetes natively."
The Workloads API consists of Daemon Sets (pod management), Replica Sets (manages pod replication across nodes), Deployments (manage updates of pods and replica sets), Stateful Sets (pod management for stateful applications such as databases). One example of a project that uses the Workloads API is bootkube. For big-data workloads, the Workloads API now enables native Kubernetes support in Apache Stark.
The Kubernetes community is remarkably active with version 1.8 being the third release this year and a total of 40 features added to Kubernetes from (currently) 29 special interest groups (SIGs) and six working groups (WGs). A SIG is a group of contributors working towards a common purpose of advancing the project with respect to a specific topic, and a WG consists of members working on a new concept and helping in collaborating with different SIGs.
Kubernetes's developers have focused on feature depth for better stability rather than coming up with many new features.There are three feature lifecycle phases: alpha, beta, and stable. Alpha is the first installment of a feature, it is experimental and maybe even removed from later releases. Beta is a more advanced stage when a feature is waiting for feedback and improvements. In the stable phase the functionality of the feature is unlikely to change and is deemed ready for use in production.
There are roughly 40 new features in release 1.8, out of which 4 are stable, 16 are beta and the remaining are alpha. Some of the expected features in release 1.9 are a stable Workloads API, better integration with Prometheus, custom resource definitions (CRD), more node-level improvements in resource management and other general fixes.