What’s new in Kubernetes 1.8
4 October 2017 | 0
The latest version of the open source container orchestration framework Kubernetes, Kubernetes 1.8, promotes some long-gestating, long-awaited features to beta or even full production release. And it adds more alpha and beta features as well. The new additions and promotions:
- Role-based security features.
- Expanded auditing and logging functions.
- New and improved ways to run both interactive and batch workloads.
- Many new alpha-level features, designed to become full-blown additions over the next couple of releases.
Kubernetes 1.8’s new security features
Earlier versions of Kubernetes introduced role-based access control (RBAC) as a beta feature. RBAC lets an admin define access permissions to Kubernetes resources, such as pods or secrets, and then grant (‘bind’) them to one or more users. Permissions can be for changing things (‘create’, ‘update’, ‘patch’) or just obtaining information about them (‘get’, ‘list’, ‘watch’). Roles can be applied on a single namespace or across an entire cluster, via two distinct APIs.
Kubernetes already had a policy system for networking, including filtering incoming traffic to pods. Kubernetes 1.8 adds beta support for filtering outbound traffic as well. Right now, filtering in both directions is limited to a list of destination ports and peers, so things like rate limiting aren’t yet available through Kubernetes’s interfaces. (You can accomplish such things directly in containers using a custom network bridge.)
Another networking feature promoted to beta is automatic TLS certificate rotation for Kubelet, the agent software that runs on each Kubernetes node. TLS certificates used by Kubernetes internally have a one-year lifespan, and it’s easy to forget to regenerate those certificates. The new feature, when enabled, automatically generates new certs for Kubelet when the current ones are almost expired.
Kubernetes 1.8’s new auditing features
Introduced in Kubernetes 1.7 as an alpha feature, auditing has been kicked up a notch to beta status in Kubernetes 1.8. This includes formatting for audit logs, policies for controlling which elements of a cluster can be logged and by whom, and webhooks to relay events to external services.
Promoting auditing to beta means that the audit event format will make only backward-compatible changes. In other words, it’s a signal that Kubernetes developers can start building production functionality with the feature. An example of that backward compatibility for the auditing framework is the audit2rbac tool, which can generate RBAC profiles from audit events.
Kubernetes 1.8’s new workload features
Another alpha-to-beta promotion in Kubernetes 1.8 is the set of workload APIs. These provide a way to orchestrate applications based on their overall behaviours – for example, a batch job or cron-style job that runs and terminates, versus a daemon that runs continuously.
Some of the workload APIs are set to be promoted out of beta sooner than others. Four of the most common – Deployment, DaemonSet, ReplicaSet, and StatefulSet – should be in full production status as of Kubernetes 1.9. The batch APIs (Job and CronJob) will follow later, but developers can get an idea now of how they’re meant to work.
Some applications can already use the workload APIs, but only in a provisional way. Apache Spark, for example, has a fork that runs directly on Kubernetes, although those features won’t be officially available in either Spark or Kubernetes for some time yet.
Other new alpha and beta features in Kubernetes 1.8
Other, as-yet-unfinished features have been included in Kubernetes 1.8 as either alpha or beta additions:
- Cri-containerd (in beta) lets you use Containerd instead of the Docker daemon, as a possible way to reduce direct dependencies on Docker.
- Volume snapshots (in alpha) lets you take snapshots of Kubernetes volumes using a Kubernetes API call. It’s absolutely not ready for production right now, because it doesn’t even ensure that snapshots are consistent when taken.
- Volume resising (in alpha) lets you manipulatge the size of volumes, again using a Kubernetes API call. Note that volume resizing changes only the underlying volume size and not the file system on the volume, because that file system could be anything.
IDG News Service