-
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. -
Use the wait command to monitor the cluster control-plane readiness:
-
(Optional) If you have overrides for your clusters, you must specify the secret as part of the create cluster command.
DOCKER_REGISTRY_ADDRESS
: the address of an existing Docker registry accessible in the VPC that the new cluster nodes will be configured to use a mirror registry when pulling images.DOCKER_REGISTRY_CA
: (optional) the path on the bastion machine to the Docker registry CA. Konvoy will configure the cluster nodes to trust this CA. This value is only needed if the registry is using a self-signed certificate and the AMIs are not already configured to trust this CA.
-
Depending on the cluster size, it will take a few minutes to create. After the creation, use this command to get the Kubernetes kubeconfig for the new cluster and begin deploying workloads:
Verify your Calico installation
Before exploring the new cluster, confirm your calico
installation is correct.
By default, Calico automatically detects the IP to use for each node using the first-found
method. This is not always appropriate for your particular nodes. In that case, you must modify Calico’s configuration to use a different method.
An alternative is to use the interface
method by providing the interface ID to use. Follow the steps outlined in this section to modify Calico’s configuration. In this example, all cluster nodes use ens192
as the interface name.
Get the pods running on your cluster with this command:
To edit the installation file, run the command:
Change the value for spec.calicoNetwork.nodeAddressAutodetectionV4
to interface: ens192
, and save the file:
Save this file. You may need to delete the node feature discovery worker pod in the node-feature-discovery
namespace if that pod has failed. After you delete it, Kubernetes replaces the pod as part of its normal reconciliation.
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. The built-in virtual IP uses the kube-vip project.
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
Confirm that your Calico installation is correct.
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
Confirm that your Calico installation is correct.
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
Confirm that your Calico installation is correct.
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
Confirm that your Calico installation is correct.
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:
-
Generate the yaml manifests for the cluster using the
--dry-run
and-o yaml
flags, along with the desireddkp cluster create
command: -
To modify the service subnet, add or edit the
spec.clusterNetwork.services.cidrBlocks
field of theCluster
object: -
To modify the pod subnet, edit the
Cluster
and calico-cniConfigMap
resources:Cluster: Add or edit the
spec.clusterNetwork.pods.cidrBlocks
field:ConfigMap: Edit the
data."custom-resources.yaml".spec.calicoNetwork.ipPools.cidr
field with your desired pod subnet:
When you provision the cluster, the configured pod and service subnets will be applied.
Confirm that your Calico installation is correct.