.png)
What is Pre-provisioned Infrastructure
Pre-provisioned as an infrastructure allows the deployment of Kubernetes DKP to pre-existing machines. Other providers such as vSphere, AWS, or Azure create, or provision, the machines themselves before Kubernetes is deployed. On most infrastructures (including vSphere and cloud providers), DKP provisions the actual nodes automatically as part of deploying a cluster. It creates the VMs using the appropriate image, then handles the networking and installation of Kubernetes. However, DKP can also work with pre-provisioned infrastructure in which you provision the VMs for the nodes themselves. Note that you can pre-provision nodes for DKP on bare metal, on vSphere, or even in the the cloud. Pre-provisioned and vSphere is a combination of the physical (on premises bare metal) and virtual servers (VMware vSphere).
Pre-provisioned environments are often used in bare metal deployments, where you deploy your OS (such as RHEL, CentOS, Ubuntu, etc) on physical machines. Creating a pre-provisioned cluster means that you, as an Infrastructure Ops Manager are responsible for allocating your compute resources, setting up networking, collecting IP and SSH information to be provided to DKP, etc. You can then provide all details to the pre-provisioned provider in order to deploy Kubernetes. These operations are done manually or with the help of other tools.
In pre-provisioned environments, DKP handles your cluster’s lifecycle (installation, upgrade, node management, etc.). DKP installs Kubernetes, monitoring and logging apps as well as the UI.
The main use cases for the pre-provisioned provider are:
On-premises clusters
Cloud or IAAS environments that do not currently have a D2iQ supported infrastructure provider
Cloud environments where you must use predefined infrastructure instead of having one of the supported cloud providers create it for you
In an environment with access to the internet, you retrieve artifacts from specialized repositories dedicated to them such as Docker images contained in DockerHub and Helm Charts that come from a dedicated Helm Chart repository. However, in an air-gapped environment, you need local repositories to store Helm charts, Docker images and other artifacts. Tools such as jFrog, Harbor and Nexus handle multiple types of artifacts in one local repository.