What’s new in Kubernetes containers
The latest version of the open source container orchestration framework Kubernetes, Kubernetes 1.9, brings to the container-orchestration framework both full-blown and beta-test versions of significant new features:
- The general availability of the Workloads API.
- Beta support for Windows Server.
- An alpha version of a new container storage API.
What’s new in Kubernetes 1.9
Kubernetes 1.9 was released in December 2017.
Production version of the Workloads API
Promoted to beta in Kubernetes 1.8 and now in production release in Kubernetes 1.9, the Apps Workloads API provides ways to define workloads based on their behaviors, such as long-running apps that need persistent state.
Version 1 of the Apps Workloads API brings four APIs to general availability:
- Deployment. A basic way to describe the desired state for a running application, including a ReplicaSet.
- ReplicaSet. This ensures, via a Deployment’s configuration, that an app has enough running container instances (“replicas”) to satisfy its definition.
- Daemonset. A deployment for an app that runs continuously regardless of what other apps might be running, such as a logging or monitoring solution.
- StatefulSet. This is used for workloads that need persistent state even if containers are killed and restarted. StatefulSets also provide persistency for things like network identification for containers or the order in which containers start and stop.
Another set of Workloads APIs, Job and CronJob (collectively called the Batch Workloads APIs), are used for workloads that run on a scheduled basis and then terminate. The Batch Workloads APIs are still in beta.
Beta support for Windows Server
After Microsoft added native support for Docker containers to Windows, the next logical step was for other apps that used Docker, like Kubernetes, to follow suit. Kubernetes 1.9 now provisionally supports the use of Kubernetes on Windows Server.
To test Kubernetes on Windows Server, you need Windows Server 2016 and Docker 1.12. Right now, the Kubernetes control plane can run only on Linux. In other words, you can schedule containers to run on Windows Server from a Linux controller, but you can’t use Windows Server as a controller instead of Linux.
The first alpha of the Container Storage Interface (CSI)
One of Kubernetes’s key features since the beginning has been abstraction of resources, including storage, from applications. Unfortunately, container storage hasn’t really had a standard; most every container solution has implemented its own way of handling storage, Kubernetes included.
The good news is that a subgroup of the Cloud Native Computing Foundation, the CNCF Storage Working Group, has devised its own standard for storage in container clusters, the Container Storage Interface (CSI) standard. Kubernetes 1.9 has an alpha version of a CSI plugin, to allow storage volume plugins to be developed entirely independently from Kubernetes itself. The project is still in the early stages, but Kubernetes’s developers are confident it’s a step in the right direction.
Other new features in Kubernetes 1.9
Some of the other additions and modifications include:
- An alpha version of a hardware acceleration addition to Kubernetes, allowing the use of GPUs as a resource. This will better enable Kubernetes to be an underpinning for machine learning workloads.
- Alpha support for IPv6 addressing.
- Faster validation for Custom Resource Definition (CRD) data. CRDs let admins customize and extend a given Kubernetes installation, but without jeopardizing compatibility when new versions of Kubernetes come along.
What’s new in Kubernetes 1.8
Kubernetes 1.8 was released in October 2017.
New security features in Kubernetes 1.8
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.
Auditing features in Kubernetes 1.8
Introduced in Kubernetes 1.7 as an alpha feature, auditing is 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.
Workload features in Kubernetes 1.8
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 behaviors—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—are in full production status as of Kubernetes 1.9. The batch APIs (Job and CronJob) will follow later, but Kubernetes 1.8 gives developers an idea 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 are 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 resizing (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.
Source: InfoWorld – Cloud Computing
Recent Comments