Kubernetes 1.7 Brings Extensibility, Security Hardening and the Network Policy API
Kubernetes 1.7 has been released with focus on extensibility and security as well as a host of new features.
The release includes four stable features, seven in beta and 19 in alpha. Kubernetes releases are scheduled for every three months from a release team including members from Google, CoreOS, Mirantis, Red Hat, Microsoft and others. In all, more than 375 people contributed to the new release.
Alpha features are not turned on by default; users can opt to use them, but they’re not considered “production ready” by the upstream community. Beta features are considered well-tested and are turned on by default, but they might change later on, Red Hat’s Joe Brockmeier explained in a blog post.
Improved extensibility aims to expand the scope and functionality of Kubernetes without bloating the core project, he says.
The network policy API for restricting container network traffic, source IP handling for load balancers, the StorageOS volume plugin, and cloud storage metrics are the four features deemed stable in 1.7.
“Promotion to ‘stable’ represents features that have proven their production readiness and are locked in for many subsequent releases. While these are often aren’t the most exciting release items, they display commitment to a Kubernetes core that others can build on top of,” said Eric Chiang, software engineer at CoreOS, who co-leads the Kubernetes Authorization and Authentication special interest group.
Those features include:
- Custom Resource Definitions: CRDs are in beta and Third Party Resources are moving to a new API group for 1.7, but by version 1.8, Custom Resource Definitions will be the supported extension mechanism and the Third Party Resources will be entirely deprecated, according to a post from CoreOS’s Eric Chiang. CRDs will allow extension of the Kubernetes API to provide features not in core Kubernetes that look like first-class APIs to users.
- Extensible External Admission Control: This alpha feature enables admins and integrators to define their own extensible policy and security checks for admitting content into their Kubernetes cluster.
- API Aggregation: In beta, it allows community members to write their own API servers. New APIs can be developed and tested in separate aggregated servers, unblocking the backlog of API proposals awaiting core Kubernetes team review
Security enhancements in 1.7 include the node authorizer plug-in to limit kubelet access and client/server Transport Layer Security (TLS) certificate rotation. In addition:
- The Network Policy API — Implemented through a network plug-in, it allows users to set and enforce rules governing which pods can communicate with each other.
- Encrypting secrets in etc: This alpha feature allows sensitive data stored in the etcd key-value store to be encrypted at the datastore level. This goes beyond encrypting data on disk, allowing the API server to symmetrically encrypt data before passing it to etcd.
- Limit node access to API: This new authorization mode and admission plugin, in beta, is designed to limit a node’s access to sensitive information solely to pods running on that particular node — no accessing secrets globally in the cluster.
Other notable features include:
- DaemonSet Updates: This beta feature adds the option to automate pod updates. 1.7 adds rollback and history capability.
- StatefulSet Upgrades: Also in beta, StatefulSet Upgrades can be automated, using a range of update strategies including rolling updates.
- Support for “burst mode” with StatefulSets: It allows rapid, out-of-order changes to StatefulSets for scaling up or down according to demand. In alpha.
- NetworkPolicy Now Stable: Promoted to stable status, this feature allows labeling to select pods and define rules to specify the network traffic allowed to and from those pods, rather than accepting traffic from any source.
- Local persistent storage: An alpha feature allowing users to request from a StorageClass that their Pods be executed on nodes with locally attached storage. This method will be a more reliable model of storing local persistent data as compared to hostPath.
The Cloud Native Computing Foundation, which manages the Kubernetes project, cites continuing growth in the use of Kubernetes, noting it’s the most-used CNCF project in production.
There are several projects under way for running a Kubernetes cluster locally, even for those who just want to tinker with it, such as minikube, kubeadm or kargo.
In a recent episode of The New Stack Analysts podcast, the topic was “Where is Kubernetes Going Now?” It featured Donnie Berkholz, a former analyst with 451 Research, and now vice president of IT service delivery at Carlson Wagonlit Travel; Krishnan Subramanian, founder and chief research advisor at Rishidot Research; and Janakiram MSV, principal at Janikiram & Associates. Check it out:
The Cloud Native Computing Foundation, CoreOS, and Red Hat are sponsors of The New Stack.
Feature image via Pixabay.
