What's new in Kubernetes 1.7? Extensibility rules

A little more than three years after the first public commit for Kubernetes, the 1.7 release is ready to be released. What's new in this release? You'll find a lot of interesting new features, but the overarching theme of 1.7 is "extensibility" with a side of security features and much more. Let's take a look at what Kubernetes 1.7 will bring.

How Features Appear in Kubernetes
As you probably know, Kubernetes is one of the prime upstream projects for the Red Hat OpenShift family. As such, we spend a lot of time working upstream to introduce, collaborate on, and review code that goes into Kubernetes. Major features don't just materialize in a single release cycle for Kubernetes fully baked, they go through extensive review and development.

New features in Kubernetes are considered "alpha" in their first release, which means they're not turned on by default in the builds. Users can opt to use them, but they're not considered "production ready" by the upstream community. Beta features are considered well-tested and once a feature is in beta, it will not be dropped from Kubernetes – but it may change. Beta features are enabled by default.

Finally, once features are considered stable they will continue to appear in Kubernetes releases "for many subsequent versions," and aren't subject to changes the way beta or alpha feature Application Programming Interfaces (APIs) are.

Improved Extensibility
A major focus for the 1.7 release is extensibility, to allow Kubernetes to expand its scope and functionality without bloating the core project. Here's some of the features that make up Kubernetes extensibility focus in 1.7:

• Custom Resource Definitions -- Third Party Resources are moving to a new API group, which lays the foundation for adding new features to custom resources later on. Custom Resource Definitions (CRDs) will allow extension of the Kubernetes API to provide features not in core Kubernetes that look like first-class APIs to users. This is in beta for Kubernetes 1.7.

• Extensible External Admission Control -- This feature adds extensible policy and security checks to Kubernetes. Admins and integrators will be able to define their own policies to admit content into their Kubernetes cluster. This is in alpha for Kubernetes 1.7.

• API Aggregation -- Along with work on CRDs, the API Aggregation feature helps to add to Kubernetes' extensibility by letting user-provided API servers be served with the rest of the Kubernetes API. This feature moves to beta for 1.7.

An Eye on Security
Extensibility isn't the only focus for 1.7. Security, as always, is important for upstream Kubernetes and 1.7 delivers some interesting improvements there.

• Encrypting secrets in etcd -- The goal for this feature, in alpha as of 1.7, is to allow sensitive data stored in the etcd key-value store to be encrypted at the datastore level. This allows users of Kubernetes to go beyond encrypting data on-disk, but also to encrypt data in etcd to help protect it from being read by malicious parties via the Kubernetes API.

• Limit node access to API -- This adds a new authorization mode and admission plugin that can limit a Kubernetes node's access to specific APIs. This is designed to limit a node’s access to secrets, and other information, to only pods running on that particular node., This will prevent any node from accessing secrets globally in the cluster.. This is in beta as of 1.7.

Other Noteworthy Developments in 1.7
Kubernetes 1.7 has a few features not in the extensibility or security categories that bear mentioning.

• DaemonSet Updates -- This feature, beta in 1.7, adds the option to automate pod updates when a DaemonSet spec has been changed.

• StatefulSet Upgrades -- Going beta in 1.7, StatefulSet Upgrades allow StatefulSets to be marked for upgrade automatically rather than requiring each StatefulSet pod to be deleted and then recreated with a new updated image.

• Support for "burst mode" with StatefulSets -- Appearing in alpha in 1.7, this feature would allow Kubernetes' StatefulSets to support rapid, out-of-order changes to scale up or down as demand requires.

• NetworkPolicy Now Stable -- The NetworkPolicy feature has been promoted to stable in Kubernetes 1.7. This allows users to use labels to select pods and define rules to specify the network traffic allowed to and from those pods. (historically, and by default, pods in Kubernetes are not isolated. They accept traffic from any source).

Overall, Kubernetes 1.7 represents another strong release from the Kubernetes community. It delivers a number of features that will help keep Kubernetes at the forefront of deploying, scaling, and managing containerized applications.

Coming Soon to OpenShift
The features that are appearing today in Kubernetes will help shape the next release of OpenShift, due in the coming months. We work with the larger Kubernetes community to drive features that are important to OpenShift users, and then work to stabilize and ready these features to meet the most demanding workloads.

The 1.7 release features will roll into OpenShift Origin first, and then will appear in OpenShift Online thereafter. After extensive testing in our online environments, those features will be baked into Red Hat OpenShift Container Platform which can be deployed on premise or in the cloud by customers.

Additional Resources:
Upcoming Kubernetes 1.7 related talks on OpenShift Commons:

• What’s New in Kubernetes 1.7: Features/Functions/Futures with Clayton Coleman (Red Hat)

• Distributed Tracing with Jaeger and Prometheus on Kubernetes with-Yuri-Shkuro (Uber) and Gary Brown (Red Hat)

• Kubernetes Service Catalog Deep Dive with Paul Morie and Andrew Block (Red Hat)

• Kubernetes Technical Road Map Update with Aparna Sinha (Google)

Check out the entire calendar of OpenShift Commons Briefings and Tech Talks here: http://commons.openshift.org/events.html