.png)
Azure Create a New Cluster
Prerequisites
Before you begin, make sure you have created a Bootstrap cluster.
Name your Cluster
Give your cluster a unique name suitable for your environment.
Set the environment variable:
CODEexport CLUSTER_NAME=<azure-example>To create a cluster name that is unique, use the following command. This creates a unique name every time you run it, so use it with forethought:
CODEexport CLUSTER_NAME=azure-example-$(LC_CTYPE=C tr -dc 'a-z0-9' </dev/urandom | fold -w 5 | head -n1) echo $CLUSTER_NAMECODEazure-example-pf4a3
Important Notes for Azure Environments
To use a custom Azure Image when creating your cluster, you must create that Azure Image using KIB first and then use the flag
--compute-gallery-idto apply the image.
...
--compute-gallery-id "<Managed Image Shared Image Gallery Id>"
Important to remember: The --compute-gallery-id image will be in the format --compute-gallery-id /subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Compute/galleries/<gallery name>/images/<image definition name>/versions/<version id>.
Ensure your subnets do not overlap with your host subnet because they cannot be changed after cluster creation. If you need to change the Kubernetes subnets, you must do this at cluster creation. The default subnets used in DKP are:
spec:
clusterNetwork:
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/12Availability zones (AZs) are isolated locations within data center regions from which public cloud services originate and operate. Because all the nodes in a node pool are deployed in a single Availability Zone, you may wish to create additional node pools to ensure your cluster has nodes deployed in multiple Availability Zones.
By default, the control-plane Nodes will be created in 3 different zones. However, the default worker Nodes will reside in a single Availability Zone. You may create additional node pools in other Availability Zones with the dkp create nodepool command. See Microsoft’s documentation for more information on Availability Options for Azure VM.
Default Storage Provisioning: The below cluster creation directions instead describes how to create a cluster using Azure as the infrastructure provider provisioning clusters, which uses Azure Disks Container Storage Interface as the default StorageClass.
If you are using Azure as a Pre-provisioned environment: DKP uses localvolumeprovisioner as the default storage provider if creating a pre-provisioned Azure cluster. However, localvolumeprovisioner is not suitable for production use. You should use a Kubernetes CSI compatible storage that is suitable for production.
You can choose from any of the storage options available for Kubernetes. To disable the default that Konvoy deploys, set the default StorageClasslocalvolumeprovisioner as non-default. Then set your newly created StorageClass to be the default by following the commands in the Kubernetes documentation called Changing the Default Storage Class.
Create a New Azure Kubernetes Cluster
Generate the Kubernetes cluster objects. See dkp create cluster azure reference for the full list of cluster creation options.
(Optional) Use a local registry mirror. Configure your cluster to use an existing local registry as a mirror when attempting to pull images previously pushed to your registry.
Create a cluster:
dkp create cluster azure \
--cluster-name=${CLUSTER_NAME} \
--dry-run \
--output=yaml \
> ${CLUSTER_NAME}.yamlExpand the drop-downs for HTTP, FIPS and other flags to use during the cluster creation step above. For more information regarding this flag or others, please refer to the CLI section of the documentation for dkp create cluster and select your provider.
To allow DKP to create a cluster with Marketplace based images such as for Rocky Linux, the following flags are available. If these fields were specified in the override file during image creation, the flags must be used in cluster creation:
--plan-offer,--plan-publisherand--plan-sku- CODE
--plan-offer rockylinux-9 --plan-publisher erockyenterprisesoftwarefoundationinc1653071250513 --plan-sku rockylinux-9
If you see a similar error to "Creating a virtual machine from Marketplace image or a custom image sourced from a Marketplace image requires Plan information in the request." when creating a cluster, you must also set the following flags --plan-offer, --plan-publisher, --plan-sku. For example when creating a cluster with Rocky Linux VMs, add the following flags to your dkp create cluster azure command:
--plan-offer,--plan-publisherand--plan-sku
For more information regarding this flag or others, please refer to the CLI for the dkp create cluster section of the documentation and select your provider.
Output:
Generating cluster resourcesInspect or edit the cluster objects and familiarize yourself with Cluster API before editing the cluster objects as edits can prevent the cluster from deploying successfully. See Azure Customizing CAPI Clusters .
Familiarize yourself with Cluster API before editing the cluster objects as edits can prevent the cluster from deploying successfully.
For in-depth documentation about the objects, read Concepts in the Cluster API Book.
(Optional) Modify Control Plane Audit logs - Users can make modifications to the
KubeadmControlplanecluster-api object to configure differentkubeletoptions. See Configuring the Control Plane if you wish to configure your control plane beyond the existing options that are available from flags.Create the cluster from the objects generated during
dry run. A warning will appear in the console if the resource already exists and will require you to remove the resource or update your YAML.CODEkubectl create -f ${CLUSTER_NAME}.yaml
NOTE: If you used the --output-directory flag in your dkp create .. --dry-run step above, create the cluster from the objects you created by specifying the directory:
kubectl create -f <existing-directory>/Wait for the cluster control-plane to be ready:
CODEkubectl wait --for=condition=ControlPlaneReady "clusters/${CLUSTER_NAME}" --timeout=20mOutput:
CODEcluster.cluster.x-k8s.io/azure-example condition metAfter the objects are created on the API server, the Cluster API controllers reconcile them. They create infrastructure and machines. As they progress, they update the Status of each object. Konvoy provides a command to describe the current status of the cluster:
dkp describe cluster -c ${CLUSTER_NAME}Output:
NAME READY SEVERITY REASON SINCE MESSAGE
Cluster/azure-example True 3m4s
├─ClusterInfrastructure - AzureCluster/azure-example True 8m26s
├─ControlPlane - KubeadmControlPlane/azure-example-control-plane True 3m4s
│ ├─Machine/azure-example-control-plane-l8j9r True 3m9s
│ ├─Machine/azure-example-control-plane-slprd True 7m17s
│ └─Machine/azure-example-control-plane-xhxxg True 5m9s
└─Workers
└─MachineDeployment/azure-example-md-0 True 4m31s
├─Machine/azure-example-md-0-d67567c8b-2674r True 5m19s
├─Machine/azure-example-md-0-d67567c8b-mbmhk True 5m17s
├─Machine/azure-example-md-0-d67567c8b-pzg8k True 5m17s
└─Machine/azure-example-md-0-d67567c8b-z8km9 True 5m17sAs they progress, the controllers also create Events. List the Events using this command:
CODEkubectl get events | grep ${CLUSTER_NAME}For brevity, the example uses
grep. It is also possible to use separate commands to get Events for specific objects. For example,kubectl get events --field-selector involvedObject.kind="AzureCluster"andkubectl get events --field-selector involvedObject.kind="AzureMachine".
If changing the Calico encapsulation, D2iQ recommends changing it after cluster creation, but before production.
DKP uses Azure CSI as the default storage provider. You can use a Kubernetes CSI compatible storage solution that is suitable for production. See the Kubernetes documentation called Changing the Default Storage Class for more information.
If you’re not using the default, you cannot deploy an alternate provider until after the dkp create cluster is finished. However, it must be determined before Kommander installation.
Known Limitations
Be aware of these limitations in the current release of Konvoy.
The Konvoy version used to create a bootstrap cluster must match the Konvoy version used to create a workload cluster.
Konvoy supports deploying one workload cluster.
Konvoy generates a set of objects for one Node Pool.
Konvoy does not validate edits to cluster objects.