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 is here with 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 of the 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 either be pre-built, existing 3rd party 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. To register their API, users must add an API-service object, 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 1.8 release.
• Extensible External Admission Control: This is an alpha feature added in this release. The main motive behind adding 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 will now be able to define their own policies to admit content into their Kubernetes cluster.

  This is an alpha feature, so it is disabled by default. To turn it on, you need to 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 which 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 was able to see all the secrets.

  In this release, Kubernetes added encryption mechanism which 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 is a feature 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 and these unauthorized nodes can only modify their own Node API object and Pod objects bound to themselves.

  This is again an improved security feature which helps an organization to limit access to sensitive information across nodes. This will be an added 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 audit. 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 to manage applications that require 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 better performance with the provision of 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 in resolving issues and cornering cases that were raised during the beta period of TPR. The Kubernetes community already expects removal of TPR in 1.8 release. So, if you are using 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 the adoption of Kubernetes within enterprise organizations.