What's new in Kubernetes 1.7, and should you care?
Nick Chase - July 02, 2017
Kubernetes 1.7 is out, focusing on production features such as security, extensibility, and stateful applications. Do you need it? Well, let's look at what it does for you.
The Network Policy API, which had been introduced in previous versions, is now classified as "stable". This API enables users to create rules that determine which pods can communicate with each other. By default, pods are "non-isolated" but you can also create "isolated" pods by creating a NetworkPolicy resource, ensuring that unauthorised services can't communicate with your pod.
For data that remains "at rest" such as Secrets and other resources stored in etcd, you now have the ability to protect that information from prying eyes (and programs) with encryption. (Encryption for at-rest data is considered to be "alpha", so you'll probably want to wait before using it on production systems.)
Moving a little deeper into the "guts" of Kubernetes, you can now improve security by rotating client and server certificates for Kubelet TLS bootstrapping, and audit logs now support event filtering and webhooks, and provide greater customization and richer data to keep track of what's going on in your system.
Finally, Kubernetes 1.7 addresses a security problem you might not have known you have: the kubelet on one node accessing secrets, pods, or other resources on other nodes. Kubernetes now includes the node authorizer and admission control plugin, which ensure that kubelet instances only access the appropriate objects.
For many people, "real world" is code for "stateful" applications such as databases, etcd, Zookeeper, and other "pets". Even though containers were originally targeted at "cattle", or stateless applications, StatefulSets (originally called "PetSets") were introduced a few months ago. At the time, they enabled users to create stateful applications on containers, but they didn't have the same robust update capabilities as their stateless counterparts, so updating these applications was more tedious and involved potential downtime. Kubernetes 1.7 fixes that problem by providing StatefulSet Updates. In addition, if your applications pods can be fired up in any order, you can now burst them for scaling using the Pod Management Policy, improving performance.
Also on the subject of updates, it was already possible to update DaemonSets, which fire up when a node first starts, but if there was a problem, you couldn't roll the DaemonSet back again. Now you can.
Getting back to persistence, however, there are also some improvements in storage. Because containers are designed to be transitory, it's important to make sure you understand how your data is being stored. One option that's available in Kubernetes 1.7 is a new StorageOS Volume plugin. StorageOS is a plugin that provides high availability cluster-wide storage volumes, making it possible to deploy databases and other applications that require persistent data.
Also, while storage is normally provided through the use of volumes, it's not always easy to provided storage volumes, particularly in dev and test situations. That's one reason developers have been asking for the ability to create local storage volumes; because they can be accessed as standard Persistent Volumes using StorageClasses, changing to a different type of volume doesn't require recoding later.
At the lowest level, there are enhancements to the Container Runtime Interface (CRI), which is what enables Kubernetes to run different kinds of containers. (It's not ALL about Docker, after all.) You can even run non-containers with projects such as Virtlet!
According to the Kubernetes 1.7 announcement from Mirantis' Ihor Dvoretskyi and Google's Aparna Sinha, "Container Runtime Interface (CRI) has been enhanced with New RPC calls to retrieve container metrics from the runtime. Validation tests for the CRI have been published and Alpha integration with containerd, which supports basic pod lifecycle and image management is now available. Read our previous in-depth post introducing CRI."
What this means is that you (or your Kubernetes distribution vendor) can add new functionality that can be accessed in a method similar to the core Kubernetes features.
In addition, Kubernetes 1.7 includes an alpha version of external admission controllers, which make it possible to add custom logic that the API server will execute to modify objects when they're created, as well as Policy-based Federated Resource Placement, which lets you create placement policies for the federated clusters. This way, if you have specific regulations you need to follow, or if you want to segregate resources based on pricing, performance, or other factors, you can use these policies to accomplish that.
All of this makes it possible to extend Kubernetes beyond its core capabilities; will vendors take advantage of these features to create differentiated versions of the technology? And if they do, will it create its own form of vendor lock-in?
Only time will tell.
Security
Especially in this age of cyberattacks, security is on everyone's mind, so it's no surprise that the Kubernetes community has been working on solutions in this area. In Kubernetes 1.7, these features are mostly "below the surface" -- meaning that users won't interact with them directly -- but not completely.The Network Policy API, which had been introduced in previous versions, is now classified as "stable". This API enables users to create rules that determine which pods can communicate with each other. By default, pods are "non-isolated" but you can also create "isolated" pods by creating a NetworkPolicy resource, ensuring that unauthorised services can't communicate with your pod.
For data that remains "at rest" such as Secrets and other resources stored in etcd, you now have the ability to protect that information from prying eyes (and programs) with encryption. (Encryption for at-rest data is considered to be "alpha", so you'll probably want to wait before using it on production systems.)
Moving a little deeper into the "guts" of Kubernetes, you can now improve security by rotating client and server certificates for Kubelet TLS bootstrapping, and audit logs now support event filtering and webhooks, and provide greater customization and richer data to keep track of what's going on in your system.
Finally, Kubernetes 1.7 addresses a security problem you might not have known you have: the kubelet on one node accessing secrets, pods, or other resources on other nodes. Kubernetes now includes the node authorizer and admission control plugin, which ensure that kubelet instances only access the appropriate objects.
Application development and stateful workloads
If you're more of a user than an operator, you'll be interested in features that are aimed at making Kuvernetes a more hospitable place for real world applications.For many people, "real world" is code for "stateful" applications such as databases, etcd, Zookeeper, and other "pets". Even though containers were originally targeted at "cattle", or stateless applications, StatefulSets (originally called "PetSets") were introduced a few months ago. At the time, they enabled users to create stateful applications on containers, but they didn't have the same robust update capabilities as their stateless counterparts, so updating these applications was more tedious and involved potential downtime. Kubernetes 1.7 fixes that problem by providing StatefulSet Updates. In addition, if your applications pods can be fired up in any order, you can now burst them for scaling using the Pod Management Policy, improving performance.
Also on the subject of updates, it was already possible to update DaemonSets, which fire up when a node first starts, but if there was a problem, you couldn't roll the DaemonSet back again. Now you can.
Getting back to persistence, however, there are also some improvements in storage. Because containers are designed to be transitory, it's important to make sure you understand how your data is being stored. One option that's available in Kubernetes 1.7 is a new StorageOS Volume plugin. StorageOS is a plugin that provides high availability cluster-wide storage volumes, making it possible to deploy databases and other applications that require persistent data.
Also, while storage is normally provided through the use of volumes, it's not always easy to provided storage volumes, particularly in dev and test situations. That's one reason developers have been asking for the ability to create local storage volumes; because they can be accessed as standard Persistent Volumes using StorageClasses, changing to a different type of volume doesn't require recoding later.
Extensibility
Unless you're a power-user, you're unlikely to need the extensibility features, but they're pretty exciting, so it's good to know they're there in case they'll solve a problem you run up against.At the lowest level, there are enhancements to the Container Runtime Interface (CRI), which is what enables Kubernetes to run different kinds of containers. (It's not ALL about Docker, after all.) You can even run non-containers with projects such as Virtlet!
According to the Kubernetes 1.7 announcement from Mirantis' Ihor Dvoretskyi and Google's Aparna Sinha, "Container Runtime Interface (CRI) has been enhanced with New RPC calls to retrieve container metrics from the runtime. Validation tests for the CRI have been published and Alpha integration with containerd, which supports basic pod lifecycle and image management is now available. Read our previous in-depth post introducing CRI."
API aggregation
The most powerful (and potentially interesting) new feature in this release, however, is called API aggregation. According to the documentation, "The aggregation layer enables installing additional Kubernetes-style APIs in your cluster. These can either be pre-built, existing 3rd party solutions, such as service-catalog, or user-created APIs like apiserver-builder, which can get you started."What this means is that you (or your Kubernetes distribution vendor) can add new functionality that can be accessed in a method similar to the core Kubernetes features.
In addition, Kubernetes 1.7 includes an alpha version of external admission controllers, which make it possible to add custom logic that the API server will execute to modify objects when they're created, as well as Policy-based Federated Resource Placement, which lets you create placement policies for the federated clusters. This way, if you have specific regulations you need to follow, or if you want to segregate resources based on pricing, performance, or other factors, you can use these policies to accomplish that.
All of this makes it possible to extend Kubernetes beyond its core capabilities; will vendors take advantage of these features to create differentiated versions of the technology? And if they do, will it create its own form of vendor lock-in?
Only time will tell.
Other resources
- Kubernetes: Kubernetes 1.7: Security Hardening, Stateful Application Updates and Extensibility
- New in Kubernetes 1.7: More extensibility with Custom Resource Definitions and API Aggregation | CoreOS
- The TPR is dead. Long live the CRD: Custom Resources in Kubernetes v1.7 | CoreOS
- Kubernetes 1.7 brings container community new security, extensibility features - SD Times
