The next edition of Kubernetes, version 1.9, is scheduled to be released later Friday and will come with support for Windows containers, as well as an alpha version of a new container storage API.
It also features a range of general improvements in stability, including a stable API for Workloads, an umbrella feature first introduced last December, according to Ihor Dvoretskyi, developer advocate at the Cloud Native Computing Foundation and Kubernetes 1.9 release features lead.
Overall, there are four four APIs moved to general availability:
- Deployment: A basic way to describe the desired state for a running application, including a ReplicaSet.
- ReplicaSet: According to a Deployment’s configuration, this ensures 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: For workloads that need persistent state even if containers are killed and restarted. StatefulSets also provide persistence for things like network identification for containers or the order in which containers start and stop.
The move to stable means users no longer have to worry about using them for mission-critical workloads, knowing the API interface won’t change into something they will need to recode their own apps to continue using.
“If you’re writing something for Kubernetes, it will be much easier to do that with much-simplified APIs,” he said.
Support for Windows Server has been widely anticipated. Microsoft in October changed its Azure Container Service platform’s acronym from ACS to AKS to reflect its focus on Kubernetes.
At the recent KubeCon event, Microsoft announced Virtual Kubelet, a connector that allows users to target Azure Container Instances (ACI), a service that speeds the creation and deployment of containers on Azure, as well as support for Heptio’s Ark backup and recovery utility and Tigera’s Calico network security policies.
Though Windows Server support has been moved to beta status, it’s not yet ready for the production environment, Dvoretskyi said.
“At the same time, beta means it will be stable soon. If you’re planning to build something with Kubernetes in a Windows environment, it’s a good time to get started with it. Once it reaches stable status, you will have some experience working with it,” he said. It will allow you to use Windows servers to add nodes to the Kubernetes cluster, and Windows Workloads will run natively on Windows machines.
Developers will still have a Linux control plane for managing the Windows pods inside a Kubernetes cluster, but those who want to write applications targeting a Windows environment will be able to.
Cloudbase, Apprenda and Red Hat have announced support for Windows Server Containers in Kubernetes 1.9.
The Container Storage Interface (CSI), a cross-industry standards initiative, is a response to storage vendor interest in Kubernetes, Dvoretskyi said. It’s an alpha feature, meaning it’s not recommended for production use and must be explicitly enabled.
Container storage interface will enable users to plug in and swap storage for the Kubernetes cluster.
“Previously, if you wanted to use other storage solutions with your Kubernetes cluster, you had to ensure they were available by default in the code base of Kubernetes. This also made it difficult for storage vendors who wanted to provide storage solutions for Kubernetes. This makes it much easier for vendors to provide storage options for Kubernetes,” Dvoretskyi said.
Other new features:
- An alpha version of a hardware acceleration allowing the use of GPUs as a resource for machine learning workloads.
- Alpha support for IPv6 addressing.
- Faster validation for Custom Resource Definition (CRD) data. CRDs let admins customize and extend a Kubernetes installation without jeopardizing compatibility with new versions of Kubernetes.
In addition, the CNCF announced the Certified Kubernetes Conformance Program, which verifies that workloads running on any certified Kubernetes distribution or platform will work correctly on other certified Kubernetes distributions or platforms, now includes more than 40 projects.
The emergence of standards for the network, storage and runtime interface, as well as the conformance program and associated extensibility mechanisms to service mesh projects such as Istio, are indicators of maturity for Kubernetes, Aparna Sinha, group project manager for Kubernetes at Google, said during a podcast with The New Stack from KubeCon.
“The service broker pieces are signs of maturity because we’re moving up the stack,” she said. “It’s not just about networking, operating systems and container runtimes — those are being standardized — now we’re moving up the stack and thinking about how do we make sure the services are authenticated and secured.”
She predicted 2018 will be the year of security in the container and Kubernetes space.
“As of 1.9, many features are designed for this purpose. Kubernetes’s use of the Container Network Interface (CNI) has enabled a rich ecosystem of networking options. Custom Resource Definitions (CRDs) and aggregated API servers allow users to extend the API while preserving a familiar workflow for custom controllers and operators. Webhook plugins for authentication and authorization have allowed integrations with a variety of identity providers and policy engines. The list goes on and on,” he said.
Components that need to be moved to external projects include the cloud-controller-manager, CSI for external storage, and the longstanding goal of moving kubeadm to its own repo, but these will take time, he said.
Another new feature, however, devstats.k8s.io, collects metrics for GitHub repos under the Kubernetes organization. It can be used to create summaries of contributions by individuals or companies, to provide insight into the project’s pace as a whole.
Feature image via Pixabay.