By Tim Anderson, translated by Wang Qiang, curated by Tina
The newly released Kubernetes 1.31 marks a significant milestone, with the complete removal of built-in cloud provider integration code, a move describedby the team as the largest migration in Kubernetes history. This change, however, might disrupt existing scripts, as the only remaining cloud provider parameter for kubeletis now external.
Previously, Kubernetes included support for five cloud providers—Google Cloud, Microsoft Azure, Amazon Web Services (AWS), OpenStack, and VMware vSphere—within its core code (in-tree). While this approachoffered convenience, it undermined Kubernetes’s commitment to being a vendor-neutral platform. The inclusion of these providers also led to code bloat and made updates more challenging due to the built-in nature of the provider code, increasing the potential for securityvulnerabilities.
In late 2018, a Kubernetes Enhancement Proposal (KEP-2395) was proposed to remove these built-in cloud providers. However, the proposal acknowledged that Kubernetes users will need to deploy a CCM (Cloud Controller Manager) add-on to their cluster. Previously, userscould enable the cloud controller loop of the kubernetes-controller-manager via command-line flags.
Cloud Controller Manager Takes the Lead
The Cloud Controller Manager, no longer optional, now has documentation to support users in deploying their CCM, such as this document for AWS (https://github.com/kubernetes/cloud-provider-aws/blob/master/docs/getting_started.md) and this one for Azure (https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/).
The complexity of migrating to the new version stems from numerous impacted components and critical code paths that rely onthe built-in integrations, as the Cloud Provider SIG (Special Interest Group) explained earlier this year. Users need to build four new subsystems from scratch, covering CCM, API server network proxy, kubelet credential provider, and storage migration.
Kubelet, an agent running on each VM (virtual machine) or nodein a Kubernetes cluster, is at the heart of this change. The team claims that the migration has yielded significant results, removing approximately 1.5 million lines of code and reducing the binary size of core components by about 4…
The Future of Vendor Neutrality
This move towards a truly vendor-neutralKubernetes platform is a major step for the project. It allows for greater flexibility and scalability, as users can now choose the cloud provider that best suits their needs without being tied to a specific integration. While the transition might require some initial effort, the long-term benefits of this change are undeniable.
References:
*KEP-2395: Remove in-tree cloud providers
* AWS Cloud Controller ManagerDocumentation
* Azure Cloud Controller Manager Documentation
Views: 0