What’s new in Kubernetes 1.7?

Kubernetes is one of the popular platforms for container orchestration and management. After focusing more on the stability front in 1.6, Kubernetes 1.7 has more than fifty new features and more focus on federation, extensibility, security, and other ways of deploying, scaling, and managing containerized applications. Here are some new features that make Kubernetes 1.7 more stable and popular.

Major features in Kubernetes 1.7:

API aggregation: The main benefit of this feature, compared to Kubernetes 1.6, is user-provided API servers that can be aggregated with the rest of the Kubernetes API.
The aggregation layer enables installing additional Kubernetes-style APIs in your cluster. These can be pre-built, existing 3rd parties solutions like service-catalog, or user-created APIs like apiserver-builder. API aggregation layer runs in kube-apiserver.

The aggregation layer will do nothing until an extension resource is registered. Users must add an API-service object to register their API, which “claims” the URL path in the Kubernetes API. At that point, the aggregation layer will proxy anything sent to that API path (e.g.,/apis/myextension.mycompany.io/v1/…) to the registered API Service.
Container Runtime Interface (CRI): With an improvement in CRI, Kubernetes has added new RPC calls along with some enhancements like improved debuggability, added container, and image file system metrics or stats, which can help you retrieve container metrics from container runtime. Metrics calls added in 1.7 do not allow Kubelet to gather metrics from container runtime. It is expected to enable Kubelet to optionally consume the container metrics from the API in the 1.8 release.
Extensible External Admission Control: This alpha feature is added in this release. The main motive behind this feature is to provide options to add custom business logic to the API server for changing objects as they are created and validating policy. Admins and integrators can now define policies to admit content into their Kubernetes cluster.
This is an alpha feature, so it is disabled by default. To turn it on, you must include “GenericAdmissionWebhook” in the --admission-control flag when starting the apiserver. If you have multiple kube-apiserver replicas, all should have the same flag setting.

Consider a use case where your infrastructure requires all Pod resources to have a common set of labels, and you do not want any Pod to be persisted to Kubernetes. If these needs are not met, you can write your external admission webhook to do this validation and respond accordingly.
Encrypting secrets in etcd: etcd is a strong, consistent, and highly available key-value store that Kubernetes uses for persistent storage of all its API objects. Previously all secrets were stored in plaintext on a tmpfs file on the nodes, and unfortunately, any user who can access the Kubernetes API could see all the secrets.
In this release, Kubernetes added an encryption mechanism that allows sensitive data stored in the etcd key-value store to be encrypted at the datastore level. This allows users of Kubernetes not only 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.

This modularized approach is added to store sensitive information and credentials in the system.
Limit node access to API: This feature is added to limit a node’s access to secrets and other information to Pods running only on that particular node. This will prevent the unauthorized node from accessing secrets globally in the cluster. These unauthorized nodes can only modify their own Node API object and Pod objects bound to themselves.
This is, again, an improved security feature that helps an organization to limit access to sensitive information across nodes. This will be an advantage for using Kubernetes for data and security-centric applications.
The Network Policy API: Promoted to stable in this release, this feature will help you define how groups of Pods can communicate with each other and other network endpoints. It is implemented by the network plugin. Resources use labels to select Pods and define rules which specify what traffic is allowed to the selected Pods.
Audit logs improvements: With this release, audit logs stored by the API server are now more customizable and extensible, with support for event filtering and webhooks. They also provide richer data for system audits. This will help you filter out useful logging information from a large set of data and will enable you to debug your problem faster.
Local Storage: This was one of the most frequently requested features for stateful applications and is introduced as an alpha feature. The standard PVC/PV interface and StorageClasses in StatefulSets can help you access local storage volumes. This will help organizations manage applications requiring local storage for performance reasons.
StorageOS Plugin: A new StorageOS Volume plugin provides highly-available cluster-wide persistent volumes from local or attached node storage. StorageOS can be used as a storage provider for your Kubernetes cluster. StorageOS runs as a container within your Kubernetes environment making local storage accessible from any node within the Kubernetes cluster. Data can be replicated to protect against node failure. At its core, StorageOS provides block storage. You may choose the filesystem type installation to make devices usable from within containers.

Additional features of Kubernetes in 1.7:

Kubelet TLS bootstrapping: This release now supports client and server certificate rotation.
StatefulSet: This is a new beta feature in 1.7, which will allow automated updates of stateful applications such as Kafka, Zookeeper, and etcd, using a range of update strategies, including rolling updates. We can expect a better performance by providing faster scaling and start-up for applications that do not require ordering through Pod Management Policy.

Some deprecations:

Third-Party Resource (TPR): Kubernetes 1.7 deprecated Third-Party Resource (TPR) to replace them with Custom Resource Definitions (CRD), which provide a cleaner API. It also helps resolve issues and corner cases raised during the beta period of TPR. The Kubernetes community already expects the removal of TPR in the 1.8 release. So, if you use the TPR beta feature, consider migrating them to CRD.

Kubernetes 1.7 release targets to improve security, storage, and extensibility features to make the DevOps program even better suited for enterprise customers. Kubernetes 1.6 release was focused on scale and automation, and this latest release is clearly attempting to further lay the foundations for adopting Kubernetes within enterprise organizations.