.png)
What is Pre-provisioned Infrastructure
Pre-provisioned as an infrastructure type allows the deployment of Kubernetes using 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 cloud. Pre-provisioned and vSphere are a combination of the physical (on-premises bare metal) and virtual servers (VMware® vSphere).
Where is Pre-provisioned used?
Pre-provisioned environments are often used in bare metal deployments, where you deploy your OS (such as RHEL® or Ubuntu™, and so on) 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 of th needed details to the pre-provisioned provider 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, and so on). DKP installs Kubernetes, monitoring and logging apps, as well as its own user interface.
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.