The Kubernetes 1.11 release is set to become generally available on June 27, providing users of the container orchestration system with networking, configuration and operations improvements.
Among the highlights of Kubernetes 1.11 is the CoreDNS domain name service reaching general availability. The IPVS load balancing feature has now also reached general availability status in Kubernetes 1.11, enabling scalability improvements. Plus, Custom Resource Definition gets a boost with new versioning capabilities that aim to ease operations. Finally, Kubernetes nodes, known as “kubelets” in 1.11, now benefit from a new dynamic configuration capability.
“Kubernetes has a configuration facility for services called ConfigMaps,” Josh Berkus, Kubernetes community manager at Red Hat and Kubernetes 1.11 release lead, told eWEEK. “In 1.11, admins can configure each node to use a specific ConfigMap for kubelet configuration and once that’s done, then the kubelet config can be updated on the fly by updating the ConfigMap.”
Kubernetes 1.11 is the second major release for Kubernetes in 2018, following the 1.10 milestone that was released on March 26.
Kubernetes is a container orchestration and cloud-native application infrastructure platform that was originally developed by Google and has been operated as an open-source Cloud Native Computing Foundation (CNCF) project since July 2015. Leadership of Kubernetes releases changes for each milestone, with Kubernetes 1.10 led by Red Hat’s Berkus and the 1.12 release set to be led by Tim Pepper, orchestration and containers lead in the VMware Open Source Technology Center.
“One of the broad areas of feature improvement in 1.11 is enhanced persistent volume support,” Pepper said. “While Kubernetes has a focus on enabling stateless microservices, the reality is that enterprise users have a mix of workloads today, including ones that are stateful. These workloads benefit from improved connections to software defined storage.”
While CoreDNS is now generally available for Kubernetes 1.11, Berkus said it’s still just an option and the existing KubeDNS is still available for users.
The IPVS load balancing feature does, however, replace a more complicated method that Kubernetes administrators have been using involving iptables to enable scalability. Gaetano Borgione, senior staff engineer in the Cloud Native Apps Business Unit at VMware, explained that packet processing ability and provisioning of rules take a significant performance penalty toll when applied on scaled environments, and IPVS addresses many of those concerns providing a more scalable and better performing solution.
“IPVS is an improvement toward a more compelling way to address iptables scalability issues in a definitive fashion,” Borgione told eWEEK.
With IPVS load balancing becoming GA in Kubernetes 1.11, Red Hat sees a stable replacement option for implementing Kubernetes Services using iptables, according to Stephen Augustus, specialist solution architect of OpenShift at Red Hat. In the iptables scenario, routing rules are handled in a table, which is parsed sequentially to determine where to route traffic.
“Unfortunately, with exponential increases in the routes stored, like one might see in an orchestrated environment like Kubernetes, performance will degrade as the iptables attempts to process existing routes and insert new ones,” Augustus told eWEEK. “IPVS uses a kernel space hash table to determine routing, which in certain situations can be orders of magnitude faster.”
The Custom Resource Definition (CRD) model first landed in the Kubernetes 1.7 release in June 2017, providing an easy way to define and retrieve new extensions to the Kubernetes API. In Kubernetes 1.11, the CRD Versioning model is being introduced, providing further extensibility.
Augustus explained that the current state of affairs for managing the life cycle of a CRD involves understanding what objects a CRD manipulates, understanding the fields of those objects, including what is and isn’t immutable and, in many cases, manually converting currently existing objects to adjust fields.
“In introducing CRD versioning, we’ll see CRD development more closely parallel Kubernetes object development,” Augustus said. “Users and operators can begin to build the same sort of API contracts that one would come to expect natively from the platform.”
Kubernetes 1.11 also introduces multiple new features as beta, including new priority and pre-emption capabilities that enable more dynamic scheduling capabilities for workloads.
Several features didn’t mature in time to become part of the new release. TLS Bootstrap, a feature that has been in various stages of development since the Kubernetes 1.4 update in October 2016, has still not graduated to full general availability status.
“Brand-new [alpha] features that got pulled from the release included debugging containers, resizing for CSI volumes, node-level user namespace mapping, and built-in Seccomp management,” Berkus said. “Whether or not those features or others are in 1.12 depends on several factors I can’t predict, such as contributor availability, SIG and company priorities, and what blocked the feature in the first place.”
While there are multiple features in the alpha and beta stages currently, it’s not clear yet which ones will be ready for the next release.
“Despite the outward appearance of a waterfall-like regular release cadence, in a large dynamic community like Kubernetes there really is more of an agile or lean style of defer commitment,” Pepper said. “The individual SIGs [Special Interest Groups] are currently discussing what feature work they intend to target for the 1.12 release, but what goes in ultimately will be what is ready.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.