Kubernetes is best known for its orchestration capabilities – a mechanism that manages the lifecycle of microservices by scheduling, deploying, launching, monitoring, and controlling multiple containers in a distributed environment.
At the heart of the orchestration engine lies an efficient control plane that acts as an interface between the infrastructure and the operators. The control plane exposes a uniform API and taxonomy to perform a standard set of operations on the resources. Behind the scenes, the control plane interacts with various independent resources responsible for managing the compute, network, and storage engines.
Think of the control plane as a façade that speaks a familiar language understood by the users of Kubernetes – the developers and operators. This façade is used to manage the lifecycle of various Kubernetes-native objects such as pods , deployments, statefulsets, services, jobs, and even external resources such as virtual machines, ERP instances, IoT devices and more. Though virtual machines and ERP instances are not native resources to Kubernetes, it is made possible through the extensibility of the control plane.
Within a short span of five years, Kubernetes has emerged as the operating system of the cloud. It is offered as a managed service by almost every public cloud provider. Irrespective of where Kubernetes runs, users can safely assume that the control plane is always consistent.
Another key development in the cloud native ecosystem is the rise of operators. An operator extends orchestration capabilities beyond containers to custom resources such as virtual machines, traditional database servers, managed cloud services, and anything else that may be automated via scripts.
MORE FOR YOU
The operator framework exploits the Kubernetes control plane to expose the same API familiar to the users while talking to the external resources through the native interfaces. The external resources are registered as custom resource definition (CRD) and custom resources (CR). Thus the operator becomes the bridge between the custom resources registered with Kubernetes and the actual workflow required to manage the resources.
For example, users can request a vSphere virtual machine through Kubernetes by defining the custom resource specifications in a standard YAML format. When submitted, the control plane and the operator work together in translating the call to the vSphere virtual machine manager. Starting with vSphere 7.0, VMware relied on the same model to expose both Kubernetes control plane and traditional vSphere APIs to cater to both audiences.
Crossplane, an open source project from UpBound, exploits the Kubernetes control plane to expose a consistent interface to the public cloud services. It essentially transforms Kubernetes into a universal control plane that can orchestrate the lifecycle of public cloud-based services such as virtual machines, database instances, Big Data clusters, machine learning jobs, and other managed services offered by the hyperscalers.
Crossplane enables the Kubernetes and the cloud native community to use familiar YAML specifications to provision, monitor, and manage cloud services without the need to learn cloud-specific APIs, tools, SDKs, and proprietary domain-specific languages used for templates such AWS CloudFormation, Azure Resource Manager, and Google Cloud Deployment Manager.
Cloud native developers and operators can easily mix and match the definitions of Kubernetes-native services with cloud provider-specific services in YAML. When submitted to the Kubernetes control plane, Crossplane takes over the responsibility of orchestrating the managed services while Kubernetes efficiently tackles the lifecycle of native microservices-based applications. Developers need to register Crossplane with an existing Kubernetes cluster along with the credentials needed to talk to the cloud platform. This integration brings modern workloads and traditional cloud services to a level playing field.
Crossplane supports mainstream cloud platforms, including Alibaba Cloud, Amazon Web Services, Equinix Metal, Google Cloud Platform and Microsoft Azure. It essentially brings Kubernetes-styled declarative and API-driven configuration and management to infrastructure running on-premises or the cloud. Through this approach, infrastructure managed through Crossplane becomes accessible via kubectl, the command-line tool used by Kubernetes users.
In July 2020, Crossplane became a Cloud Native Computing Foundation (CNCF) sandbox project. Within a year, the CNCF Technical Oversight Committee (TOC) has voted to accept Crossplane as a CNCF incubating project. It joins other CNCF incubating technologies such as Argo, Buildpacks, CloudEvents, CNI, Contour, Cortex, CRI-O, Dragonfly, emissary-ingress, Falco and Flux.
The creators of Crossplane, UpBound, offer a commercial, enterprise-grade, hosted control plane that customers can use without managing the infrastructure themselves. UpBound control plane acts as a consistent interface between the users and the registered cloud providers by exposing a uniform deployment model. It also comes with a registry which is a collection of tools to accelerate the registration and configuration of various resource providers.
Crossplane takes the concept of Infrastructure as Code (IaC) to the next level through its tight integration with Kubernetes. Organizations can leverage it to create declarative, versioned deployment configurations while taking advantage of proven CI/CD practices based on GitOps.