Create the Cluster

Create a Kubernetes cluster using the infrastructure definition

With the inventory, and the control plane endpoint defined, use the dkp binary to create a Konvoy cluster. The following command relies on the pre-provisioned cluster API infrastructure provider to initialize the Kubernetes control plane and worker nodes on the hosts defined in the inventory.

NOTE: When specifying the `cluster-name`, you must use the same `cluster-name` as used when defining your inventory objects.

dkp create cluster preprovisioned --cluster-name ${CLUSTER_NAME} --control-plane-endpoint-host <control plane endpoint host> --control-plane-endpoint-port <control plane endpoint port, if different than 6443>

Depending on the cluster size, it will take a few minutes to be created. After the creation, use this command to get the Kubernetes kubeconfig for the new cluster and begin deploying workloads:

dkp get kubeconfig -c ${CLUSTER_NAME} > ${CLUSTER_NAME}.conf

Use the built-in Virtual IP

As explained in Define the Control Plane Endpoint, we recommend using an external load balancer for the control plane endpoint, but provide a built-in virtual IP when an external load balancer is not available. To use the virtual IP, add these flags to the create cluster command:

Virtual IP Configuration Flag
Network interface to use for Virtual IP. Must exist on all control plane machines. --virtual-ip-interface string
IPv4 address. Reserved for use by the cluster. --control-plane-endpoint string

Virtual IP Example

dkp create cluster preprovisioned \
    --cluster-name ${CLUSTER_NAME} \
    --control-plane-endpoint-host 196.168.1.10 \
    --virtual-ip-interface eth1

Provision on the Flatcar Linux OS

When provisioning onto the Flatcar Container Linux distribution, you must instruct the bootstrap cluster to make some changes related to the installation paths. To accomplish this, add the --os-hint flatcar flag to the above create cluster command.

Flatcar Linux Example

dkp create cluster preprovisioned \
    --cluster-name ${CLUSTER_NAME} \
    --os-hint flatcar

Use an HTTP Proxy

If you require http proxy configurations, you can apply them during the create operation by adding the appropriate flags to the create cluster command:

Proxy configuration Flag
HTTP proxy for control plane machines --control-plane-http-proxy string
HTTPS proxy for control plane machines --control-plane-https-proxy string
No Proxy list for control plane machines --control-plane-no-proxy strings
HTTP proxy for worker machines --worker-http-proxy string
HTTPS proxy for worker machines --worker-https-proxy string
No Proxy list for worker machines --worker-no-proxy strings

HTTP Proxy Example

dkp create cluster preprovisioned \
    --cluster-name ${CLUSTER_NAME} \
    --control-plane-http-proxy http://proxy.example.com:8080 \
    --control-plane-https-proxy https://proxy.example.com:8080 \
    --control-plane-no-proxy "127.0.0.1,10.96.0.0/12,192.168.0.0/16,kubernetes,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.default.svc.cluster.local,.svc,.svc.cluster,.svc.cluster.local" \
    --worker-http-proxy http://proxy.example.com:8080 \
    --worker-https-proxy https://proxy.example.com:8080 \
    --worker-no-proxy "127.0.0.1,10.96.0.0/12,192.168.0.0/16,kubernetes,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.default.svc.cluster.local,.svc,.svc.cluster,.svc.cluster.local"

Use an alternative mirror

To apply Docker registry configurations during the create operation, add the appropriate flags to the create cluster command:

Docker registry configuration Flag
CA certificate chain to use while communicating with the registry mirror using TLS --registry-mirror-cacert file
URL of a container registry to use as a mirror in the cluster --registry-mirror-url string

This is useful when using an internal registry and when Internet access is not available (air-gapped installations).

When the cluster is up and running, you can deploy and test workloads.

Alternative Mirror Example

dkp create cluster preprovisioned \
    --cluster-name ${CLUSTER_NAME} \
    --registry-mirror-cacert /tmp/registry.pem \
    --registry-mirror-url https://registry.example.com

Use alternate pod or service subnets

In Konvoy, the default pod subnet is 192.168.0.0/16, and the default service subnet is 10.96.0.0/12. If you wish to change the subnets you can do so with the following steps:

  1. Generate the yaml manifests for the cluster using the --dry-run and -o yaml flags, along with the desired dkp cluster create command:

    dkp create cluster preprovisioned --cluster-name ${CLUSTER_NAME} --control-plane-endpoint-host <control plane endpoint host> --control-plane-endpoint-port <control plane endpoint port, if different than 6443> --dry-run -o yaml > cluster.yaml
    
  2. To modify the service subnet, add or edit the spec.kubeadmConfigSpec.clusterConfiguration.networking.serviceSubnet field of the KubeadmControlPlane object:

    kind: KubeadmControlPlane
    spec:
      kubeadmConfigSpec:
        clusterConfiguration:
          networking:
            serviceSubnet: 192.168.0.0/24
    
  3. To modify the pod subnet, add or edit the spec.kubeadmConfigSpec.clusterConfiguration.networking.podSubnet field of the KubeadmControlPlane object:

    kind: KubeadmControlPlane
    spec:
      kubeadmConfigSpec:
        clusterConfiguration:
          networking:
            podSubnet: 172.16.0.0/16
    
  4. On the bootstrap cluster, modify the data."custom-resources.yaml".spec.calicoNetwork.ipPools.cidr value of the calico-cni-preprovisioned (calico-cni-preprovisioned-flatcar for flatcar) ConfigMap with your desired pod subnet:

    kubectl edit configmap calico-cni-preprovisioned
    

When you provision the cluster, the configured pod and service subnets will be applied.