Package Manager ¶

1. Install using Homebrew.

   brew install vmware-tanzu/tanzu/tanzu-community-edition
   

2. Run the configure command displayed after Homebrew completes installation.

   {HOMEBREW-INSTALL-LOCATION}/configure-tce.sh
   

   This puts all the Tanzu plugins in the correct location. The first time you run the tanzu command the installed plugins and plugin repositories are initialized. This action might take a minute.

Direct Download ¶

If you prefer to not use a package manager, you can download releases on GitHub. Download and unpack the release for your operating system. Then, run the script install.sh (Linux/Mac) or install.bat (Windows).

Package Manager ¶

Install using Chocolatey, in Powershell, as an administrator.

choco install tanzu-community-edition

Direct Download ¶

If you prefer to not use a package manager, you can download releases on GitHub. Download and unpack the release for your operating system. Then, run the script install.sh (Linux/Mac) or install.bat (Windows).

Create Microsoft Azure Clusters ¶

This section describes setting up management and workload clusters for Microsoft Azure.

Deploy a Management Cluster ¶

There are some prerequisites this process will assume. Refer to the Prepare to Deploy a Cluster to Azure docs for instructions on accepting image licenses and preparing your Azure account.

1. Initialize the Tanzu Community Edition installer interface.

   tanzu management-cluster create --ui
   

   Note: If you are bootstrapping from a Windows machine and encounter an unable to ensure prerequisites error, see the following troubleshooting topic.

2. Choose Azure from the provider tiles.

   

3. Fill out the IaaS Provider section.

   

   • A: Your account’s Tenant ID.
   • B: Your Client ID.
   • C: Your Client secret.
   • D: Your Subscription ID.
   • E: The Azure Cloud in which to deploy. For example, “Public Cloud”, “US Government Cloud”, etc.
   • F: The region of Azure you’d like all networking, compute, etc to be created within.
   • G: The public key you’d like to use for your VM instances. This is how you’ll SSH into control plane and worker nodes.
   • H: Whether to use an existing

     resource group or create a new one.

   • I: The existing resource group, or the name to provide the new resource group.

4. Fill out the VNET settings.

   

   • A: Whether to create a new

     Virtual Network in Azure or use an existing one. If using an existing one, you must provide its VNET name. For initial deployments, it is recommended to create a new Virtual Network. This will ensure the installer takes care of all networking creation and configuration.

   • B: The Resource Group under which to create the VNET.
   • C: The name to use when creating a new VNET.
   • D: The CIDR block to use for this VNET.
   • E: The name for the control plane subnet.
   • F: The CIDR block to use for the control plane subnet. This range should be within the VNET CIDR.
   • G: The name for the worker node subnet.
   • H: The CIDR block to use for the worker node subnet. This range should be within the VNET CIDR and not overlap with the control plane CIDR.
   • I: Whether to deploy without a publicly accessible IP address. Access to the cluster will be limited to your Azure private network only. Various ways for connecting to your private cluster

     can be found in the Azure private cluster documentation.

5. Fill out the Management Cluster Settings.

   

   • A: Choose between Development profile with one control plane node, or Production, which features a highly-available three node control plane. Additionally, choose the instance type you’d like to use for control plane nodes.
   • B: Name the cluster. This is a friendly name that will be used to reference your cluster in the Tanzu CLI and kubectl.
   • C: The instance type to be used for each node creation. See the instances types documentation to understand trade-offs between CPU, memory, pricing and more.
   • D: Whether to enable Cluster API’s machine health checks.
   • E: Choose whether you’d like to enable Kubernetes API server auditing.

6. If you would like additional metadata to be tagged in your soon-to-be-created Azure infrastructure, fill out the Metadata section.

7. Fill out the Kubernetes Network section.

   

   • A: Set the CIDR for Kubernetes Services (Cluster IPs). These are internal IPs that, by default, are only exposed and routable within Kubernetes.
   • B: Set the CIDR range for Kubernetes Pods. These are internal IPs that, by default, are only exposed and routable within Kubernetes.
   • C: Set a network proxy that internal traffic should egress through to access external network(s).

8. Fill out the Identity Management section.

   

   • A: Select whether you want to enable identity management. If this is off, certificates (via kubeconfig) are used to authenticate users. For most development scenarios, it is preferred to keep this off.
   • B: If identity management is on, choose whether to authenticate using

     OIDC or LDAPS.

   • C: Fill out connection details for identity management.

9. Fill out the OS Image section.

   

   • A: The Azure image to use for Kubernetes host VMs. This list should populate based on known images uploaded by VMware. These images are publicly accessible for your use. Choose based on your preferred Linux distribution.

10. Skip the TMC Registration section.

11. Click the Review Configuration button.

    For your record, the configuration settings have been saved to ${HOME}/.config/tanzu/tkg/clusterconfigs.

12. Deploy the cluster.

    If you experience issues deploying your cluster, visit the Troubleshooting documentation.

13. Validate the management cluster started successfully.

    tanzu management-cluster get
    

    The output will look similar to the following:

    NAME         NAMESPACE   STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES       
    mgmt         tkg-system  running  1/1           1/1      v1.21.2+vmware.1  management
    
    Details:
    
    NAME                                                            READY  SEVERITY  REASON  SINCE  MESSAGE
    /mgmt                                                           True                     5m38s
    ├─ClusterInfrastructure - AzureCluster/mgmt                     True                     5m42s
    ├─ControlPlane - KubeadmControlPlane/mgmt-control-plane         True                     5m38s
    │ └─Machine/mgmt-control-plane-d99g5                            True                     5m41s
    └─Workers
      └─MachineDeployment/mgmt-md-0
        └─Machine/mgmt-md-0-bc94f54b4-tgr9h                         True                     5m41s
    
    Providers:
    
    NAMESPACE                          NAME                   TYPE                    PROVIDERNAME  VERSION  WATCHNAMESPACE
    capi-kubeadm-bootstrap-system      bootstrap-kubeadm      BootstrapProvider       kubeadm       v0.3.23
    capi-kubeadm-control-plane-system  control-plane-kubeadm  ControlPlaneProvider    kubeadm       v0.3.23
    capi-system                        cluster-api            CoreProvider            cluster-api   v0.3.23
    capz-system                        infrastructure-azure   InfrastructureProvider  azure         v0.4.15
    

14. Capture the management cluster’s kubeconfig.

    tanzu management-cluster kubeconfig get <MGMT-CLUSTER-NAME> --admin
    

    Where <MGMT-CLUSTER-NAME> should be set to the name returned by tanzu management-cluster get above.
    
    For example, if your management cluster is called ‘mgmt’, you will see a message similar to:

    Credentials of workload cluster 'mgmt' have been saved.
    You can now access the cluster by running 'kubectl config use-context mgmt-admin@mgmt'
    

15. Set your kubectl context to the management cluster.

    kubectl config use-context <MGMT-CLUSTER-NAME>-admin@<MGMT-CLUSTER-NAME>
    

    Where <MGMT-CLUSTER-NAME> should be set to the name returned by tanzu management-cluster get.

16. Validate you can access the management cluster’s API server.

    kubectl get nodes
    
    NAME                       STATUS   ROLES                  AGE    VERSION
    mgmt-control-plane-vkpsm   Ready    control-plane,master   111m   v1.21.2+vmware.1
    mgmt-md-0-qbbhk            Ready    <none>                 109m   v1.21.2+vmware.1
    

Deploy a Workload Cluster ¶

1. Next you will create a workload cluster. First, setup a workload cluster configuration file.

   cp  ~/.config/tanzu/tkg/clusterconfigs/<MGMT-CONFIG-FILE> ~/.config/tanzu/tkg/clusterconfigs/workload1.yaml
   

   • Where <MGMT-CONFIG-FILE> is the name of the management cluster YAML configuration file

   • This step duplicates the configuration file that was created when you deployed your management cluster. The configuration file will either have the name you assigned to the management cluster, or if no name was assigned, it will be a randomly generated name.

   • This duplicated file will be used as the configuration file for your workload cluster. You can edit the parameters in this new file as required. For an example of a workload cluster template, see Azure Workload Cluster Template.

   • In the next two steps you will edit the parameters in this new file (workload1) and then use the file to deploy a workload cluster.

2. In the new workload cluster file (~/.config/tanzu/tkg/clusterconfigs/workload1.yaml), edit the CLUSTER_NAME parameter to assign a name to your workload cluster. For example,

   CLUSTER_CIDR: 100.96.0.0/11
   CLUSTER_NAME: my-workload-cluster
   CLUSTER_PLAN: dev
   

   • If you did not specify a name for your management cluster, the installer generated a random unique name. In this case, you must manually add the CLUSTER_NAME parameter and assign a workload cluster name. The workload cluster names must be must be 42 characters or less and must comply with DNS hostname requirements as described here: RFC 1123
   • If you specified a name for your management cluster, the CLUSTER_NAME parameter is present and needs to be changed to the new workload cluster name.
   • The other parameters in workload1.yaml are likely fine as-is. Validation is performed on the file prior to applying it, so the tanzu command will return a message if something necessary is omitted. However, you can change parameters as required. Reference an example configuration template here: Azure Workload Cluster Template.

3. Create your workload cluster.

   tanzu cluster create <WORKLOAD-CLUSTER-NAME> --file ~/.config/tanzu/tkg/clusterconfigs/workload1.yaml
   

4. Validate the cluster starts successfully.

   tanzu cluster list
   

5. Capture the workload cluster’s kubeconfig.

   tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --admin
   

6. Set your kubectl context to the workload cluster.

   kubectl config use-context <WORKLOAD-CLUSTER_NAME>-admin@<WORKLOAD-CLUSTER-NAME>
   

7. Verify you can see pods in the cluster.

   kubectl get pods --all-namespaces
   
   NAMESPACE     NAME                                                    READY   STATUS    RESTARTS   AGE
   kube-system   antrea-agent-9d4db                                      2/2     Running   0          3m42s
   kube-system   antrea-agent-vkgt4                                      2/2     Running   1          5m48s
   kube-system   antrea-controller-5d594c5cc7-vn5gt                      1/1     Running   0          5m49s
   kube-system   coredns-5d6f7c958-hs6vr                                 1/1     Running   0          5m49s
   kube-system   coredns-5d6f7c958-xf6cl                                 1/1     Running   0          5m49s
   kube-system   etcd-tce-guest-control-plane-b2wsf                      1/1     Running   0          5m56s
   kube-system   kube-apiserver-tce-guest-control-plane-b2wsf            1/1     Running   0          5m56s
   kube-system   kube-controller-manager-tce-guest-control-plane-b2wsf   1/1     Running   0          5m56s
   kube-system   kube-proxy-9825q                                        1/1     Running   0          5m48s
   kube-system   kube-proxy-wfktm                                        1/1     Running   0          3m42s
   kube-system   kube-scheduler-tce-guest-control-plane-b2wsf            1/1     Running   0          5m56s
   

⚠️ If bootstrapping docker-based clusters on Windows, see our Windows guide ¶

Create Local Docker Clusters ¶

This section describes setting up a management and workload cluster on your local workstation using Docker.

⚠️: Tanzu Community Edition support for Docker is experimental and may require troubleshooting on your system.

Note: Bootstrapping a cluster to Docker from a Windows bootstrap machine is currently experimental.

Prerequisites ¶

The following additional configuration is needed for the Docker engine on your local client machine (with no other containers running):

⚠️ Warning on DockerHub Rate Limiting ¶

When using the Docker (CAPD) provider, the load balancer image (HA Proxy) is pulled from DockerHub. DockerHub limits pulls per user and this can especially impact users who share a common IP, in the case of NAT or VPN. If DockerHub rate-limiting is an issue in your environment, you can pre-pull the load balancer image to your machine by running the following command.

docker pull kindest/haproxy:v20210715-a6da3463

This behavior will eventually be addressed in

https://github.com/vmware-tanzu/community-edition/issues/897.

Before You Begin ¶

To optimise your Docker system and ensure a successful deployment, you may wish to complete the next two optional steps.

1. (Optional): Stop all existing containers.

   docker kill $(docker ps -q)
   

2. (Optional): Run the following command to prune all existing containers, volumes, and images.

   Warning: Read the prompt carefully before running the command, as it erases the majority of what is cached in your Docker environment. While this ensures your environment is clean before starting, it also significantly increases bootstrapping time if you already had the Docker images downloaded.

    docker system prune -a --volumes
   

Deploy a Management Cluster ¶

1. Initialize the Tanzu Community Edition installer interface.

   tanzu management-cluster create --ui
   

   Note: If you are bootstrapping from a Windows machine and encounter an unable to ensure prerequisites error, see the following troubleshooting topic.

2. Complete the configuration steps in the installer interface for Docker and create the management cluster. The following configuration settings are recommended:

   • The Kubernetes Network Settings are auto-filled with a default CNI Provider and Cluster Service CIDR.
   • Docker Proxy settings are experimental and are to be used at your own risk.
   • We will have more complete tanzu cluster bootstrapping documentation available here in the near future.
   • If you ran the prune command in the previous step, expect this to take some time, as it’ll download an image that is over 1GB.

3. (Alternative method) It is also possible to use the command line to create a Docker based management cluster:

   tanzu management-cluster create -i docker --name <MGMT-CLUSTER-NAME> -v 10 --plan dev --ceip-participation=false
   

   • <MGMT-CLUSTER-NAME> must end with a letter, not a numeric character, and must be compliant with DNS hostname requirements described here: RFC 1123.

4. Validate the management cluster started:

   tanzu management-cluster get
   

   The output should look similar to the following:

   NAME                                               READY  SEVERITY  REASON  SINCE  MESSAGE
   /tkg-mgmt-docker-20210601125056                                                                 True                     28s
   ├─ClusterInfrastructure - DockerCluster/tkg-mgmt-docker-20210601125056                          True                     32s
   ├─ControlPlane - KubeadmControlPlane/tkg-mgmt-docker-20210601125056-control-plane               True                     28s
   │ └─Machine/tkg-mgmt-docker-20210601125056-control-plane-5pkcp                                  True                     24s
   │   └─MachineInfrastructure - DockerMachine/tkg-mgmt-docker-20210601125056-control-plane-9wlf2
     └─MachineDeployment/tkg-mgmt-docker-20210601125056-md-0
       └─Machine/tkg-mgmt-docker-20210601125056-md-0-5d895cbfd9-khj4s                              True                     24s
         └─MachineInfrastructure - DockerMachine/tkg-mgmt-docker-20210601125056-md-0-d544k
   
   
   Providers:
   
     NAMESPACE                          NAME                   TYPE                    PROVIDERNAME  VERSION  WATCHNAMESPACE
     capd-system                        infrastructure-docker  InfrastructureProvider  docker        v0.3.10
     capi-kubeadm-bootstrap-system      bootstrap-kubeadm      BootstrapProvider       kubeadm       v0.3.14
     capi-kubeadm-control-plane-system  control-plane-kubeadm  ControlPlaneProvider    kubeadm       v0.3.14
     capi-system                        cluster-api            CoreProvider            cluster-api   v0.3.14
   

5. Capture the management cluster’s kubeconfig and take note of the command for accessing the cluster in the message, as you will use this for setting the context in the next step.

   tanzu management-cluster kubeconfig get <MGMT-CLUSTER-NAME> --admin
   

   • Where <MGMT-CLUSTER-NAME> should be set to the name returned by tanzu management-cluster get.
   • For example, if your management cluster is called ‘mtce’, you will see a message similar to:

   Credentials of cluster 'mtce' have been saved.
   You can now access the cluster by running 'kubectl config use-context mtce-admin@mtce'
   

6. Set your kubectl context to the management cluster.

   kubectl config use-context <MGMT-CLUSTER-NAME>-admin@<MGMT-CLUSTER-NAME>
   

7. Validate you can access the management cluster’s API server.

   kubectl get nodes
   

   You will see output similar to:

   NAME                         STATUS   ROLES                  AGE   VERSION
   guest-control-plane-tcjk2    Ready    control-plane,master   59m   v1.20.4+vmware.1
   guest-md-0-f68799ffd-lpqsh   Ready    <none>                 59m   v1.20.4+vmware.1
   

Deploy a Workload Cluster ¶

1. Create your workload cluster.

   tanzu cluster create <WORKLOAD-CLUSTER-NAME> --plan dev
   

2. Validate the cluster starts successfully.

   tanzu cluster list
   

3. Capture the workload cluster’s kubeconfig.

   tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --admin
   

4. Set your kubectl context accordingly.

   kubectl config use-context <WORKLOAD-CLUSTER-NAME>-admin@<WORKLOAD-CLUSTER-NAME>
   

5. Verify you can see pods in the cluster.

   kubectl get pods --all-namespaces
   

   The output will look similar to the following:

   NAMESPACE     NAME                                                    READY   STATUS    RESTARTS   AGE
   kube-system   antrea-agent-9d4db                                      2/2     Running   0          3m42s
   kube-system   antrea-agent-vkgt4                                      2/2     Running   1          5m48s
   kube-system   antrea-controller-5d594c5cc7-vn5gt                      1/1     Running   0          5m49s
   kube-system   coredns-5d6f7c958-hs6vr                                 1/1     Running   0          5m49s
   kube-system   coredns-5d6f7c958-xf6cl                                 1/1     Running   0          5m49s
   kube-system   etcd-tce-guest-control-plane-b2wsf                      1/1     Running   0          5m56s
   kube-system   kube-apiserver-tce-guest-control-plane-b2wsf            1/1     Running   0          5m56s
   kube-system   kube-controller-manager-tce-guest-control-plane-b2wsf   1/1     Running   0          5m56s
   kube-system   kube-proxy-9825q                                        1/1     Running   0          5m48s
   kube-system   kube-proxy-wfktm                                        1/1     Running   0          3m42s
   kube-system   kube-scheduler-tce-guest-control-plane-b2wsf            1/1     Running   0          5m56s
   

You now have local clusters running on Docker. The nodes can be seen by running the following command:

docker ps

The output will be similar to the following:

CONTAINER ID   IMAGE                                                         COMMAND                  CREATED             STATUS             PORTS                                  NAMES
33e4e422e102   projects.registry.vmware.com/tkg/kind/node:v1.20.4_vmware.1   "/usr/local/bin/entr…"   About an hour ago   Up About an hour                                          guest-md-0-f68799ffd-lpqsh
4ae2829ab6e1   projects.registry.vmware.com/tkg/kind/node:v1.20.4_vmware.1   "/usr/local/bin/entr…"   About an hour ago   Up About an hour   41637/tcp, 127.0.0.1:41637->6443/tcp   guest-control-plane-tcjk2
c0947823840b   kindest/haproxy:2.1.1-alpine                                  "/docker-entrypoint.…"   About an hour ago   Up About an hour   42385/tcp, 0.0.0.0:42385->6443/tcp     guest-lb
a2f156fe933d   projects.registry.vmware.com/tkg/kind/node:v1.20.4_vmware.1   "/usr/local/bin/entr…"   About an hour ago   Up About an hour                                          mgmt-md-0-b8689788f-tlv68
128bf25b9ae9   projects.registry.vmware.com/tkg/kind/node:v1.20.4_vmware.1   "/usr/local/bin/entr…"   About an hour ago   Up About an hour   40753/tcp, 127.0.0.1:40753->6443/tcp   mgmt-control-plane-9rdcq
e59ca95c14d7   kindest/haproxy:2.1.1-alpine                                  "/docker-entrypoint.…"   About an hour ago   Up About an hour   35621/tcp, 0.0.0.0:35621->6443/tcp     mgmt-lb

The above reflects 1 management cluster and 1 workload cluster, both featuring 1 control plane node and 1 worker node. Each cluster gets an haproxy container fronting the control plane node(s). This enables scaling the control plane into an HA configuration.

🛠️: For troubleshooting failed bootstraps, you can exec into a container and use the kubeconfig at /etc/kubernetes/admin.conf to access the API server directly. For example:

$ docker exec -it 4ae /bin/bash

root@guest-control-plane-tcjk2:/# kubectl --kubeconfig=/etc/kubernetes/admin.conf get nodes

NAME                         STATUS   ROLES                  AGE   VERSION
guest-control-plane-tcjk2    Ready    control-plane,master   67m   v1.20.4+vmware.1
guest-md-0-f68799ffd-lpqsh   Ready    <none>                 67m   v1.20.4+vmware.1

In the above 4ae is a control plane node.

⚠️: If the Docker host machine is rebooted, the cluster will need to be re-created. Support for clusters surviving a host reboot is tracked in issue

#832.

Create vSphere Clusters ¶

This section describes setting up a management and workload cluster on vSphere.

Import a Base Image Template into vSphere ¶

Before you can deploy a cluster to vSphere, you must import a base image template into vSphere that contains the OS and Kubernetes versions that the cluster nodes run on. These are available in VMware Customer Connect. For each supported pair of OS and Kubernetes versions, VMware publishes a base image template in OVA format, for deploying clusters to vSphere. After you import the OVA into vSphere, you must convert the resulting VM into a VM template.

1. Open the Tanzu Community Edition product page on VMware Customer Connect.

   If you do not have a Customer Connect account, register here.

2. Ensure you have the version selected corresponding to your installation.

   

3. Locate and download the machine image (OVA) for your desired operating system and Kubernetes version.

   

4. Log in to your vCenter instance.

5. In vCenter, right-click on your datacenter and choose Deploy OVF Template.

   

6. Follow the prompts, browsing to the local file that is the .ova downloaded in a previous step.

7. Allow the template deployment to complete.

   

8. Right-click on the newly imported OVF template and choose Template > Convert to Template.

   

9. Verify the template is added by selecting the VMs and Templates icon and locating it within your datacenter.

   

Deploy a Management Cluster ¶

1. Initialize the Tanzu Community Edition installer interface.

   tanzu management-cluster create --ui
   

   Note: If you are bootstrapping from a Windows machine and encounter an unable to ensure prerequisites error, see the following troubleshooting topic.

2. Choose VMware vSphere from the provider tiles.

   

3. Fill out the IaaS Provider section.

   

   • A: The IP or DNS name pointing at your vCenter instance. This is the same instance you uploaded the OVA to in previous steps.
   • B: The username, with elevated privileges, that can be used to create infrastructure in vSphere.
   • C: The password corresponding to that username.
   • D: With the above filled out, connect to the instance to continue. You may be prompted to verify the SSL fingerprint for vCenter.
   • E: The datacenter you’ll deploy Tanzu Community Edition into. This should be the same datacenter you uploaded the OVA to.
   • F: The public key you’d like to use for your VM instances. This is how you’ll SSH into control plane and worker nodes.

4. Fill out the Management Cluster Settings.

   

   • A: Choose between Development profile, with 1 control plane node or Production, which features a highly-available three node control plane. Additionally, choose the instance type you’d like to use for control plane nodes.
   • B: Name the cluster. This is a friendly name that will be used to reference your cluster in the Tanzu CLI and kubectl.
   • C: Choose whether to enable Cluster API’s machine health checks.
   • D: Choose how to expose your control plane endpoint. If you have NSX available and would like to use it, choose NSX Advanced Load Balancer, otherwise choose Kube-vip, which will expose a virtual IP in your network.
   • E: Set the IP address your Kubernetes API server should be accessible from. This should be an IP that is routable in your network but excluded from your DHCP range.
   • F: Set the instance type you’d like to use for workload nodes.
   • G: Choose whether you’d like to enable Kubernetes API server auditing.

5. If you choose NSX as your Control Plane Endpoint Provider in the above step, fill out the VMware NSX Advanced Load Balancer section.

6. If you would like additional metadata to be tagged in your soon-to-be-created vSphere infrastructure, fill out the Metadata section.

7. Fill out the Resources section.

   

   • A: Set the VM folder you’d like new virtual machines to be created in. By default, this will be ${DATACENTER_NAME}/vm/
   • B: Set the

     Datastore you’d like volumes to be created within.

   • C: Set the servers or resource pools within the data center you’d like VMs, networking, etc to be created in.

8. Fill out the Kubernetes Network section.

   

   • A: Select the vSphere network where host/virtual machine networking will be setup in.
   • B: Set the CIDR for Kubernetes Services (Cluster IPs). These are internal IPs that, by default, are only exposed and routable within Kubernetes.
   • C: Set the CIDR range for Kubernetes Pods. These are internal IPs that, by default, are only exposed and routable within Kubernetes.
   • D: Set a network proxy that internal traffic should egress through to access external network(s).

9. Fill out the Identity Management section.

   

   • A: Select whether you want to enable identity management. If this is off, certificates (via kubeconfig) are used to authenticate users. For most development scenarios, it is preferred to keep this off.
   • B: If identity management is on, choose whether to authenticate using

     OIDC or LDAPS.

   • C: Fill out connection details for identity management.

10. Fill out the OS Image section.

    

    • A: The OVA image to use for Kubernetes host VMs. This list should populate based on the OVA you uploaded in previous steps. If it’s missing, you may have uploaded an incompatible OVA.

11. Skip the TMC Registration section.

12. Click the Review Configuration button.

    For your record, the configuration settings have been saved to ${HOME}/.config/tanzu/tkg/clusterconfigs.

13. Deploy the cluster.

    If you experience issues deploying your cluster, visit the Troubleshooting documentation.

14. Validate the management cluster started successfully.

    tanzu management-cluster get
    

15. Capture the management cluster’s kubeconfig.

    tanzu management-cluster kubeconfig get <MGMT-CLUSTER-NAME> --admin
    

    Where <<MGMT-CLUSTER-NAME> should be set to the name returned by tanzu management-cluster get above.
    
    For example, if your management cluster is called ‘mtce’, you will see a message similar to:

    Credentials of cluster 'mtce' have been saved.
    You can now access the cluster by running 'kubectl config use-context mtce-admin@mtce'
    

16. Set your kubectl context to the management cluster.

    kubectl config use-context <MGMT-CLUSTER-NAME>-admin@<MGMT-CLUSTER-NAME>
    

    Where <MGMT-CLUSTER-NAME> should be set to the name returned by tanzu management-cluster get.

17. Validate you can access the management cluster’s API server.

    kubectl get nodes
    
    NAME         STATUS   ROLES                  AGE    VERSION
    10-0-1-133   Ready    <none>                 123m   v1.20.1+vmware.2
    10-0-1-76    Ready    control-plane,master   125m   v1.20.1+vmware.2
    

Deploy a Workload Cluster ¶

1. Next you will create a workload cluster. First, create a workload cluster configuration file by taking a copy of the management cluster YAML configuration file that was created when you deployed your management cluster. This example names the workload cluster configuration file workload1.yaml.

   cp  ~/.config/tanzu/tkg/clusterconfigs/<MGMT-CONFIG-FILE> ~/.config/tanzu/tkg/clusterconfigs/workload1.yaml
   

   • Where <MGMT-CONFIG-FILE> is the name of the management cluster YAML config file. The management cluster YAML configuration file will either have the name you assigned to the management cluster, or if no name was assigned, it will be a randomly generated name.

   • The duplicated file (workload1.yaml) will be used as the configuration file for your workload cluster. You can edit the parameters in this new file as required. For an example of a workload cluster template, see vSphere Workload Cluster Template.

     • In the next two steps you will edit the parameters in this new file (workload1.yaml) and then use the file to deploy a workload cluster.

2. In the new workload cluster file (~/.config/tanzu/tkg/clusterconfigs/workload.yaml), edit the CLUSTER_NAME parameter to assign a name to your workload cluster. For example,

   CLUSTER_CIDR: 100.96.0.0/11
   CLUSTER_NAME: my-workload-cluster
   CLUSTER_PLAN: dev
   

   • If you did not specify a name for your management cluster, the installer generated a random unique name. In this case, you must manually add the CLUSTER_NAME parameter and assign a workload cluster name. The workload cluster names must be must be 42 characters or less and must comply with DNS hostname requirements as described here: RFC 1123
   • If you specified a name for your management cluster, the CLUSTER_NAME parameter is present and needs to be changed to the new workload cluster name.

3. In the workload cluster file (~/.config/tanzu/tkg/clusterconfigs/workload1.yaml), edit the VSPHERE_CONTROL_PLANE_ENDPOINT parameter to apply a viable IP.

   • This will be the API Server IP for your workload cluster. You must choose an IP that is routable and not used elsewhere in your network, e.g., out of your DHCP range.

   • The other parameters in workload1.yaml are likely fine as-is. Validation is performed on the file prior to applying it, so the tanzu command will return a message if something necessary is omitted. However, you can parameters as required. Reference an example configuration template here: vSphere Workload Cluster Template.

4. Create your workload cluster.

   tanzu cluster create <WORKLOAD-CLUSTER-NAME> --file ~/.config/tanzu/tkg/clusterconfigs/workload1.yaml
   

5. Validate the cluster starts successfully.

   tanzu cluster list
   

6. Capture the workload cluster’s kubeconfig.

   tanzu cluster kubeconfig get <WORKLOAD-CLUSTER-NAME> --admin
   

7. Set your kubectl context accordingly.

   kubectl config use-context <WORKLOAD-CLUSTER-NAME>-admin@<WORKLOAD-CLUSTER-NAME>
   

8. Verify you can see pods in the cluster.

   kubectl get pods --all-namespaces
   
   NAMESPACE     NAME                                                    READY   STATUS    RESTARTS   AGE
   kube-system   antrea-agent-9d4db                                      2/2     Running   0          3m42s
   kube-system   antrea-agent-vkgt4                                      2/2     Running   1          5m48s
   kube-system   antrea-controller-5d594c5cc7-vn5gt                      1/1     Running   0          5m49s
   kube-system   coredns-5d6f7c958-hs6vr                                 1/1     Running   0          5m49s
   kube-system   coredns-5d6f7c958-xf6cl                                 1/1     Running   0          5m49s
   kube-system   etcd-tce-guest-control-plane-b2wsf                      1/1     Running   0          5m56s
   kube-system   kube-apiserver-tce-guest-control-plane-b2wsf            1/1     Running   0          5m56s
   kube-system   kube-controller-manager-tce-guest-control-plane-b2wsf   1/1     Running   0          5m56s
   kube-system   kube-proxy-9825q                                        1/1     Running   0          5m48s
   kube-system   kube-proxy-wfktm                                        1/1     Running   0          3m42s
   kube-system   kube-scheduler-tce-guest-control-plane-b2wsf            1/1     Running   0          5m56s
   kube-system   kube-vip-tce-guest-control-plane-b2wsf                  1/1     Running   0          5m56s
   kube-system   vsphere-cloud-controller-manager-nwrg4                  1/1     Running   2          5m48s
   kube-system   vsphere-csi-controller-5b6f54ccc5-trgm4                 5/5     Running   0          5m49s
   kube-system   vsphere-csi-node-drnkz                                  3/3     Running   0          5m48s
   kube-system   vsphere-csi-node-flszf                                  3/3     Running   0          3m42s