Provisioning Kubernetes
Last updated
Last updated
Kubernetes provides a Common API to defining application needs. The desired state needed to run, maintain , manage an application effectively can be defined and provided to Kubernetes through its API.
Kubernetes then converts these requirements to drive the underlying infrastructure. To do this Kubernetes needs to understand what infrastructure providers are available in the environment. Kubernetes has standard plugins to talk to different providers. The upstream Kubernetes project along with various organizations and Open Source projects have made it possible to plugin Kubernetes with a broad spectrum of providers, building a huge ecosystem. Below is a view of the ecosystem that works with upstream Kubernetes ( it's not meant to be readable 😊)
The Challenge really isn't picking the right project or integration ( ok, maybe it is, but not the biggest problem). Most organization will have an infrastructure , environments,tool sets that they are already used to and would want Kubernetes to integrate into these environments.
The real challenge is building a Kubernetes cluster in an automated way, such that its not a snowflake and and it has all the plugins that are needed ( for e.g, a Storage provider compatible with CSI, a Network Provider compatible with CNI, a Log aggregator that understands what Kubernetes does) in every node of the cluster, along with standard Kubernetes modules.
For e,g, If one wants to deploy a Kubernetes cluster in vSphere, each node of the cluster must have the necessary components that enable them to provision a Persistent Volume using vSphere Datastores. Each node must have a network plugin such that pods within Kubernetes can be attached to the undelay network in the datacenter. Without the right modules, one can throw as many desired state API's at the Kubernetes cluster but the cluster won't be able to provision anything meaningful.
In the next chapter we look at various tools available to provision Kubernetes on different environments.
