This topic describes how to use the Tanzu Kubernetes Grid installer interface to deploy a management cluster to vSphere, Amazon Elastic Compute Cloud (Amazon EC2), and Microsoft Azure. The Tanzu Kubernetes Grid installer interface guides you through the deployment of the management cluster, and provides different configurations for you to select or reconfigure. If this is the first time that you are deploying a management cluster to a given infrastructure provider, it is recommended to use the installer interface.

Prerequisites

Before you can deploy a management cluster, you must make sure that your environment meets the requirements for the target infrastructure provider.

General Prerequisites

vSphere Prerequisites

Amazon EC2 Prerequisites

Microsoft Azure Prerequisites

Start the Installer Interface

Warning: The tanzu management-cluster create command takes time to complete. While tanzu management-cluster create is running, do not run additional invocations of tanzu management-cluster create on the same bootstrap machine to deploy multiple management clusters, change context, or edit ~/.kube-tkg/config.

  1. On the machine on which you downloaded and installed the Tanzu CLI, run the tanzu management-cluster create command with the --ui option.

    tanzu management-cluster create --ui
    

    The installer interface launches in a browser and takes you through steps to configure the management cluster.

    • To make the installer interface appear locally if you are SSH-tunneling in to the bootstrap machine or X11-forwarding its display, you may need to run tanzu management-cluster create --ui with the --browser none option described in Installer Interface Options below.

    The tanzu management-cluster create --ui command saves the settings from your installer input in a cluster configuration file. After you confirm your input values on the last pane of the installer interface, the installer saves them to ~/.config/tanzu/tkg/clusterconfigs with a generated filename of the form UNIQUE-ID.yaml.

    By default Tanzu Kubernetes Grid saves the kubeconfig for all management clusters in the ~/.kube-tkg/config file. If you want to save the kubeconfig file for your management cluster to a different location, set the KUBECONFIG environment variable before running tanzu management-cluster create.

    KUBECONFIG=/path/to/mc-kubeconfig.yaml
    

    If the prerequisites are met, tanzu management-cluster create --ui launches the Tanzu Kubernetes Grid installer interface.

    By default, tanzu management-cluster create --ui opens the installer interface locally, at http://127.0.0.1:8080 in your default browser.

    The Installer Interface Options section below explains how you can change where the installer interface runs, including running it on a different machine from the tanzu CLI.

  2. Click the Deploy button for VMware vSphere, Amazon EC2, or Microsoft Azure.

    Tanzu Kubernetes Grid installer interface welcome page with Deploy to vSphere button

Installer Interface Options

By default, tanzu management-cluster create --ui opens the installer interface locally, at http://127.0.0.1:8080 in your default browser. You can use the --browser and --bind options to control where the installer interface runs:

  • --browser specifies the local browser to open the interface in.
    • Supported values are chrome, firefox, safari, ie, edge, or none.
    • Use none with --bind to run the interface on a different machine, as described below.
  • --bind specifies the IP address and port to serve the interface from.

Warning: Serving the installer interface from a non-default IP address and port could expose the tanzu CLI to a potential security risk while the interface is running. VMware recommends passing in to the --bind option an IP and port on a secure network.

Use cases for --browser and --bind include:

  • If another process is already using http://127.0.0.1:8080, use --bind to serve the interface from a different local port.
  • To make the installer interface appear locally if you are SSH-tunneling in to the bootstrap machine or X11-forwarding its display, you may need to use –browser none.
  • To run the tanzu CLI and create management clusters on a remote machine, and run the installer interface locally or elsewhere:

    1. On the remote bootstrap machine, run tanzu management-cluster create --ui with the following options and values:

      • --bind: an IP address and port for the remote machine
      • --browser: none
      tanzu management-cluster create --ui --bind 192.168.1.87:5555 --browser none
      
    2. On the local UI machine, browse to the remote machine's IP address to access the installer interface.

Configure the Infrastructure Provider

The options to configure the infrastructure provider section of the installer interface depend on which provider you are using.

Configure a vSphere Infrastructure Provider

  1. In the IaaS Provider section, enter the IP address or fully qualified domain name (FQDN) for the vCenter Server instance on which to deploy the management cluster.

    Support for IPv6 addresses in Tanzu Kubernetes Grid is limited; see Deploy Clusters on IPv6 (vSphere Only). If you are not deploying to an IPv6-only networking environment, you must provide IPv4 addresses in the following steps.

  2. Enter the vCenter Single Sign On username and password for a user account that has the required privileges for Tanzu Kubernetes Grid operation, and click Connect.

    Configure the connection to vSphere

  3. Verify the SSL thumbprint of the vCenter Server certificate and click Continue if it is valid.

    For information about how to obtain the vCenter Server certificate thumbprint, see Obtain vSphere Certificate Thumbprints.

    Verify vCenter Server certificate thumbprint

  4. If you are deploying a management cluster to a vSphere 7 instance, confirm whether or not you want to proceed with the deployment.

    On vSphere 7, the vSphere with Tanzu option includes a built-in supervisor cluster that works as a management cluster and provides a better experience than a separate management cluster deployed by Tanzu Kubernetes Grid. Deploying a Tanzu Kubernetes Grid management cluster to vSphere 7 when vSphere with Tanzu is not enabled is supported, but the preferred option is to enable vSphere with Tanzu and use the Supervisor Cluster. VMware Cloud on AWS and Azure VMware Solution do not support a supervisor cluster, so you need to deploy a management cluster. For information, see Add a vSphere7 Supervisor Cluster as a Management Cluster.

    To reflect the recommendation to use vSphere with Tanzu when deploying to vSphere 7, the Tanzu Kubernetes Grid installer behaves as follows:

    • If vSphere with Tanzu is enabled, the installer informs you that deploying a management cluster is not possible, and exits.
    • If vSphere with Tanzu is not enabled, the installer informs you that deploying a Tanzu Kubernetes Grid management cluster is possible but not recommended, and presents a choice:
      • Configure vSphere with Tanzu opens the vSphere Client so you can configure your Supervisor Cluster as described in Configuring and Managing a Supervisor Cluster in the vSphere documentation.
      • Deploy TKG Management Cluster allows you to continue deploying a management cluster, against recommendation for vSphere 7, but as required for VMware Cloud on AWS and Azure VMware Solution. When using vSphere 7, the preferred option is to enable vSphere with Tanzu and use the built-in Supervisor Cluster instead of deploying a Tanzu Kubernetes Grid management cluster.

    Deploy management cluster to vSphere 7

  5. Select the datacenter in which to deploy the management cluster from the Datacenter drop-down menu.

  6. Paste the contents of your SSH public key into the text box and click Next.

    Select datacenter and provide SSH public key

For the next steps, go to Configure the Management Cluster Settings.

Configure a Amazon EC2 Infrastructure Provider

  1. In the IaaS Provider section, select how to provide the credentials for your Amazon EC2 account. You have two options:

    • Credential Profile (recommended): Select an already existing AWS credential profile. If you select a profile, the access key and session token information configured for your profile are passed to the Installer without displaying actual values in the UI. For information about setting up credential profiles, see Credential Files and Profiles.

      Select Credential Profile

    • One-Time Credentials: Enter AWS account credentials directly in the Access Key ID and Secret Access Key fields for your Amazon EC2 account. Optionally specify an AWS session token in Session Token if your AWS account is configured to require temporary credentials. For more information on acquiring session tokens, see Using temporary credentials with AWS resources.

      Enter AWS Credentials

  2. In Region, select the AWS region in which to deploy the management cluster.

    If you intend to deploy a production management cluster, this region must have at least three availability zones.

  3. Click Connect, and if the connection is successful, click Next.
  4. In the VPC for AWS section, do one of the following:

    • To create a new VPC, select Create new VPC on AWS, check that the pre-filled CIDR block is available, and click Next. If the recommended CIDR block is not available, enter a new IP range in CIDR format for the management cluster to use. The recommended CIDR block for VPC CIDR is 10.0.0.0/16.

      Create a new VPC

    • To use an existing VPC, select Select an existing VPC and select the VPC ID from the drop-down menu. The VPC CIDR block is filled in automatically when you select the VPC. If you are deploying the management cluster in an internet-restricted environment, such as a proxied or air-gapped environment, select the This is not an internet facing VPC check box.

      Use an existing VPC

For the next steps, go to Configure the Management Cluster Settings.

Configure a Microsoft Azure Infrastructure Provider

IMPORTANT: If this is the first time that you are deploying a management cluster to Azure with a new version of Tanzu Kubernetes Grid, for example v1.4.0, make sure that you have accepted the base image license for that version. For information, see Accept the Base Image License in Prepare to Deploy Management Clusters to Microsoft Azure.

  1. In the IaaS Provider section, enter the Tenant ID, Client ID, Client Secret, and Subscription ID values for your Azure account. You recorded these values when you registered an Azure app and created a secret for it using the Azure Portal.

    Configure the connection to Azure

  2. Select your Azure Environment, either Public Cloud or US Government Cloud. You can specify other environments by deploying from a configuration file and setting AZURE_ENVIRONMENT.
  3. Click Connect. The installer verifies the connection and changes the button label to Connected.
  4. Select the Azure region in which to deploy the management cluster.
  5. Paste the contents of your SSH public key, such as .ssh/id_rsa.pub, into the text box.

  6. Under Resource Group, select either the Select an existing resource group or the Create a new resource group radio button.

    • If you select Select an existing resource group, use the drop-down menu to select the group, then click Next.

      Select existing resource group

    • If you select Create a new resource group, enter a name for the new resource group and then click Next.

      Create new resource group

  7. In the VNET for Azure section, select either the Create a new VNET on Azure or the Select an existing VNET radio button.

    • If you select Create a new VNET on Azure, use the drop-down menu to select the resource group in which to create the VNET and provide the following:

      • A name and a CIDR block for the VNET. The default is 10.0.0.0/16.
      • A name and a CIDR block for the control plane subnet. The default is 10.0.0.0/24.
      • A name and a CIDR block for the worker node subnet. The default is 10.0.1.0/24.

      Create a new VNET on Azure

      After configuring these fields, click Next.

    • If you select Select an existing VNET, use the drop-down menus to select the resource group in which the VNET is located, the VNET name, the control plane and worker node subnets, and then click Next.

      Select an existing VNET

    • To make the management cluster private, as described in Azure Private Clusters, enable the Private Azure Cluster checkbox.

Configure the Management Cluster Settings

This section applies to all infrastructure providers.

  1. In the Management Cluster Settings section, select the Development or Production tile.

    • If you select Development, the installer deploys a management cluster with one control plane node and one worker node.
    • If you select Production, the installer deploys a highly available management cluster with three control plane nodes and one worker node.
  2. In either of the Development or Production tiles, use the Instance type drop-down menu to select from different combinations of CPU, RAM, and storage for the control plane node VM or VMs.

    Choose the configuration for the control plane node VMs depending on the expected workloads that it will run. For example, some workloads might require a large compute capacity but relatively little storage, while others might require a large amount of storage and less compute capacity. If you select an instance type in the Production tile, the instance type that you selected is automatically selected for the Worker Node Instance Type. If necessary, you can change this.

    If you plan on registering the management cluster with Tanzu Mission Control, ensure that your Tanzu Kubernetes clusters meet the requirements listed in Requirements for Registering a Tanzu Kubernetes Cluster with Tanzu Mission Control in the Tanzu Mission Control documentation.

    • vSphere: Select a size from the predefined CPU, memory, and storage configurations. The minimum configuration is 2 CPUs and 4 GB memory.
    • Amazon EC2: Select an instance size. The drop-down menu lists choices alphabetically, not by size. The minimum configuration is 2 CPUs and 8 GB memory. The list of compatible instance types varies in different regions. For information about the configuration of the different sizes of instances, see Amazon EC2 Instance Types.
    • Microsoft Azure: Select an instance size. The minimum configuration is 2 CPUs and 8 GB memory. The list of compatible instance types varies in different regions. For information about the configurations of the different sizes of node instances for Azure, see Sizes for virtual machines in Azure.

    Select the control plane node configuration

  3. Optionally enter a name for your management cluster.

    If you do not specify a name, Tanzu Kubernetes Grid automatically generates a unique name. If you do specify a name, that name must end with a letter, not a numeric character, and must be compliant with DNS hostname requirements as outlined in RFC 952 and amended in RFC 1123.

  4. (Optional) Deselect the Machine Health Checks checkbox if you want to disable MachineHealthCheck. You can enable or disable MachineHealthCheck on clusters after deployment by using the CLI. For instructions, see Configure Machine Health Checks for Tanzu Kubernetes Clusters.

  5. (Optional) Select the Enable Audit Logging checkbox to record requests made to the Kubernetes API server. For more information, see Audit Logging.

  6. Configure additional settings that are specific to your infrastructure provider.

    vSphere:

    1. Under Worker Node Instance Type, select the configuration for the worker node VM.
    2. Under Control Plane Endpoint Provider, select Kube-Vip or NSX Advanced Load Balancer to choose the component to use for the control plane API server.

      You can also use NSX Advanced Load Balancer as a load balancer for workloads, as configured in the VMware NSX Advanced Load Balancer pane, described below.

      To use NSX Advanced Load Balancer, you must first deploy it in your vSphere environment. For information, see Install NSX Advanced Load Balancer.

    3. Under Control Plane Endpoint, enter a static virtual IP address or FQDN for API requests to the management cluster. This setting is required if you are using Kube-Vip.

      Ensure that this IP address is not in your DHCP range, but is in the same subnet as the DHCP range. If you mapped an FQDN to the VIP address, you can specify the FQDN instead of the VIP address. For more information, see Static VIPs and Load Balancers for vSphere.

      Configure vSphere Control Plane endpoint

    Amazon EC2:

    1. In EC2 Key Pair, specify the name of an AWS EC2 key pair that is already registered with your Amazon EC2 account and in the region where you are deploying the management cluster. You may have set this up in Configure AWS Account Credentials and SSH Key.
    2. (Optional) Disable the Bastion Host checkbox if a bastion host already exists in the availability zone(s) in which you are deploying the management cluster.

      If you leave this option enabled, Tanzu Kubernetes Grid creates a bastion host for you.

    3. If this is the first time that you are deploying a management cluster to this AWS account, select the Automate creation of AWS CloudFormation Stack checkbox.

      This CloudFormation stack creates the identity and access management (IAM) resources that Tanzu Kubernetes Grid needs to deploy and run clusters on Amazon EC2. For more information, see Required IAM Resources in Prepare to Deploy Management Clusters to Amazon EC2.

    4. Configure Availability Zones:

      1. From the Availability Zone 1 drop-down menu, select an availability zone for the management cluster. You can select only one availability zone if you selected the Development tile. See the image below.

        Configure the cluster

      2. From the AZ1 Worker Node Instance Type drop-down menu, select select the configuration for the worker node VM from the list of instances that are available in this availability zone.

      3. If you selected the Production tile above, use the Availability Zone 2, Availability Zone 3, and AZ Worker Node Instance Type drop-down menus to select three unique availability zones for the management cluster.

        Note: In v1.4.0, if you select Production, Tanzu Kubernetes Grid deploys only one worker node, AZ1 Worker Node Instance Type, instead of three worker nodes. This is a known issue; for more information, see Deployment Issues in VMware Tanzu Kubernetes Grid 1.4 Release Notes. The control plane nodes are distributed across Availability Zone 1, Availability Zone 2, and Availability Zone 3.

      4. If you selected an existing VPC in the previous step, use the VPC public subnet and VPC private subnet drop-down menus to select existing subnets on the VPC.

        If you are deploying a production management cluster, select subnets for all three availability zones. Public subnets are not available if you selected This is not an internet facing VPC in the previous section. The image below shows the Development tile.

        Set the VPC subnets

    Azure:

    Under Worker Node Instance Type, select the configuration for the worker node VM.

  7. Click Next.

If you are deploying the management cluster to vSphere, go to Configure VMware NSX Advanced Load Balancer.

If you are deploying the management cluster to Amazon EC2 or Azure, go to Configure Metadata.

(vSphere Only) Configure VMware NSX Advanced Load Balancer

VMware NSX Advanced Load Balancer provides an L4+L7 load balancing solution for vSphere. NSX Advanced Load Balancer includes a Kubernetes operator that integrates with the Kubernetes API to manage the lifecycle of load balancing and ingress resources for workloads. To use NSX Advanced Load Balancer, you must first deploy it in your vSphere environment. For information, see Install NSX Advanced Load Balancer.

In the optional VMware NSX Advanced Load Balancer section, you can configure Tanzu Kubernetes Grid to use NSX Advanced Load Balancer. By default all workload clusters will use the load balancer.

If you are using LDAP or OIDC identity management, after your management cluster is created you must integrate NSX ALB with your identity provider as described in Add a Load Balancer for an Identity Provider on vSphere.

  1. For Controller Host, enter the IP address or FQDN of the Controller VM.
  2. Enter the username and password that you set for the Controller host when you deployed it.
  3. Paste the contents of the Certificate Authority that is used to generate your Controller Certificate into the Controller Certificate Authority text box and click Verify Credentials.

    If you have a self-signed Controller Certificate, the Certificate Authority is the same as the Controller Certificate.

  4. Use the Cloud Name drop-down menu to select the cloud that you created in your NSX Advanced Load Balancer deployment.

    For example, Default-Cloud.

  5. Use the Service Engine Group Name drop-down menu to select a Service Engine Group.

    For example, Default-Group.

  6. For Workload VIP Network Name and Management VIP Network Name, use the drop-down menus to select the name of the network where the load balancer floating IP Pool resides.

    The VIP network for NSX Advanced Load Balancer must be present in the same vCenter Server instance as the Kubernetes network that Tanzu Kubernetes Grid uses. This allows NSX Advanced Load Balancer to discover the Kubernetes network in vCenter Server and to deploy and configure Service Engines.

    You can see the network in the Infrastructure > Networks view of the NSX Advanced Load Balancer interface.

  7. For Workload VIP Network CIDR and Management VIP Network CIDR, use the drop-down menu to select the CIDR of the subnet to use for the load balancer VIP.

    This comes from one of the VIP Network's configured subnets. You can see the subnet CIDR for a particular network in the Infrastructure > Networks view of the NSX Advanced Load Balancer interface.

  8. (Optional) Enter one or more cluster labels to identify clusters on which to selectively enable NSX Advanced Load Balancer or to customize NSX Advanced Load Balancer Settings per group of clusters.

    By default, all clusters that you deploy with this management cluster will enable NSX Advanced Load Balancer. All clusters will share the same VMware NSX Advanced Load Balancer Controller, Cloud, Service Engine Group, and VIP Network as you entered previously. This cannot be changed later. To only enable the load balancer on a subset of clusters, or to preserve the ability to customize NSX Advanced Load Balancer settings for a group of clusters, add labels in the format key: value. For example team: tkg.

    This is useful in the following scenarios:

    • You want to configure different sets of workload clusters to different Service Engine Groups to implement isolation or to support more Service type Load Balancers than one Service Engine Group's capacity.
    • You want to configure different sets of workload clusters to different Clouds because they are deployed in separate sites.

    NOTE: Labels that you define here will be used to create a label selector. Only workload cluster Cluster objects that have the matching labels will have the load balancer enabled. As a consequence, you are responsible for making sure that the workload cluster's Cluster object has the corresponding labels. For example, if you use team: tkg, to enable the load balancer on a workload cluster, you will need to perform the following steps after deployment of the management cluster:

    1. Set kubectl to the management cluster's context.

      kubectl config set-context management-cluster@admin
      
    2. Label the Cluster object of the corresponding workload cluster with the labels defined. If you define multiple key-values, you need to apply all of them.

      kubectl label cluster <cluster-name> team=tkg
      

    Configure NSX Advanced Load Balancer

  9. Click Next to configure metadata.

Configure Metadata

This section applies to all infrastructure providers.

In the optional Metadata section, optionally provide descriptive information about this management cluster.

Any metadata that you specify here applies to the management cluster and to the Tanzu Kubernetes clusters that it manages, and can be accessed by using the cluster management tool of your choice.

  • Location: The geographical location in which the clusters run.
  • Description: A description of this management cluster. The description has a maximum length of 63 characters and must start and end with a letter. It can contain only lower case letters, numbers, and hyphens, with no spaces.
  • Labels: Key/value pairs to help users identify clusters, for example release : beta, environment : staging, or environment : production. For more information, see Labels and Selectors in the Kubernetes documentation.
    You can click Add to apply multiple labels to the clusters.

Add cluster metadata

If you are deploying to vSphere, click Next to go to Configure Resources. If you are deploying to Amazon EC2 or Azure, click Next to go to Configure the Kubernetes Network and Proxies.

(vSphere Only) Configure Resources

  1. In the Resources section, select vSphere resources for the management cluster to use, and click Next.

    • Select the VM folder in which to place the management cluster VMs.
    • Select the vSphere datastores for the management cluster to use. The storage policy for the VMs can be specified only when you deploy the management cluster from a configuration file.
    • Select the cluster, host, or resource pool in which to place the management cluster.

    If appropriate resources do not already exist in vSphere, without quitting the Tanzu Kubernetes Grid installer, go to vSphere to create them. Then click the refresh button so that the new resources can be selected.

    Select vSphere resources

Configure the Kubernetes Network and Proxies

This section applies to all infrastructure providers.

  1. In the Kubernetes Network section, configure the networking for Kubernetes services and click Next.

    • (vSphere only) Under Network Name, select a vSphere network to use as the Kubernetes service network.
    • Review the Cluster Service CIDR and Cluster Pod CIDR ranges. If the recommended CIDR ranges of 100.64.0.0/13 and 100.96.0.0/11 are unavailable, update the values under Cluster Service CIDR and Cluster Pod CIDR.

    Configure the Kubernetes service network

  2. (Optional) To send outgoing HTTP(S) traffic from the management cluster to a proxy, for example in an internet-restricted environment, toggle Enable Proxy Settings and follow the instructions below to enter your proxy information. Tanzu Kubernetes Grid applies these settings to kubelet, containerd, and the control plane.

    You can choose to use one proxy for HTTP traffic and another proxy for HTTPS traffic or to use the same proxy for both HTTP and HTTPS traffic.

    1. To add your HTTP proxy information:

      1. Under HTTP Proxy URL, enter the URL of the proxy that handles HTTP requests. The URL must start with http://. For example, http://myproxy.com:1234.
      2. If the proxy requires authentication, under HTTP Proxy Username and HTTP Proxy Password, enter the username and password to use to connect to your HTTP proxy.
    2. To add your HTTPS proxy information:

      • If you want to use the same URL for both HTTP and HTTPS traffic, select Use the same configuration for https proxy.
      • If you want to use a different URL for HTTPS traffic, do the following:

        1. Under HTTPS Proxy URL, enter the URL of the proxy that handles HTTPS requests. The URL must start with http://. For example, http://myproxy.com:1234.
        2. If the proxy requires authentication, under HTTPS Proxy Username and HTTPS Proxy Password, enter the username and password to use to connect to your HTTPS proxy.
    3. Under No proxy, enter a comma-separated list of network CIDRs or hostnames that must bypass the HTTP(S) proxy. If your management cluster runs on the same network as your infrastructure, behind the same proxy, set this to your infrastructure CIDRs or FQDNs so that the management cluster communicates with infrastructure directly.

      For example, noproxy.yourdomain.com,192.168.0.0/24.

      • vSphere: Your No proxy list must include the following:
        • The IP address or hostname for vCenter. Traffic to vCenter cannot be proxied.
        • The CIDR of the vSphere network that you selected under Network Name. The vSphere network CIDR includes the IP address of your Control Plane Endpoint. If you entered an FQDN under Control Plane Endpoint, add both the FQDN and the vSphere network CIDR to No proxy. Internally, Tanzu Kubernetes Grid appends localhost, 127.0.0.1, the values of Cluster Pod CIDR and Cluster Service CIDR, .svc, and .svc.cluster.local to the list that you enter in this field.
      • Amazon EC2: Internally, Tanzu Kubernetes Grid appends localhost, 127.0.0.1, your VPC CIDR, Cluster Pod CIDR, and Cluster Service CIDR, .svc, .svc.cluster.local, and 169.254.0.0/16 to the list that you enter in this field.
      • Azure: Internally, Tanzu Kubernetes Grid appends localhost, 127.0.0.1, your VNET CIDR, Cluster Pod CIDR, and Cluster Service CIDR, .svc, .svc.cluster.local, 169.254.0.0/16, and 168.63.129.16 to the list that you enter in this field.

      Important: If the management cluster VMs need to communicate with external services and infrastructure endpoints in your Tanzu Kubernetes Grid environment, ensure that those endpoints are reachable by the proxies that you configured above or add them to No proxy. Depending on your environment configuration, this may include, but is not limited to, your OIDC or LDAP server, Harbor, and in the case of vSphere, NSX-T and NSX Advanced Load Balancer.

Configure Identity Management

This section applies to all infrastructure providers. For information about how Tanzu Kubernetes Grid implements identity management, see Prepare External Identity Management.

  1. In the Identity Management section, optionally disable Enable Identity Management Settings .

    Configure external Identity Provider

    You can disable identity management for proof-of-concept deployments, but it is strongly recommended to implement identity management in production deployments. If you disable identity management, you can reenable it later. For instructions on how to reenable identity management, see Enable Identity Management in an Existing Deployment.

  2. If you enable identity management, select OIDC or LDAPS.

    OIDC:

    Provide details of your OIDC provider account, for example, Okta.

    • Issuer URL: The IP or DNS address of your OIDC server.
    • Client ID: The client_id value that you obtain from your OIDC provider. For example, if your provider is Okta, log in to Okta, create a Web application, and select the Client Credentials options in order to get a client_id and secret.
    • Client Secret: The secret value that you obtain from your OIDC provider.
    • Scopes: A comma separated list of additional scopes to request in the token response. For example, openid,groups,email.
    • Username Claim: The name of your username claim. This is used to set a user's username in the JSON Web Token (JWT) claim. Depending on your provider, enter claims such as user_name, email, or code.
    • Groups Claim: The name of your groups claim. This is used to set a user's group in the JWT claim. For example, groups.

    Configure external Identity Provider

    LDAPS:

    Provide details of your company's LDAPS server. All settings except for LDAPS Endpoint are optional.

    • LDAPS Endpoint: The IP or DNS address of your LDAPS server. Provide the address and port of the LDAP server, in the form host:port.
    • Bind DN: The DN for an application service account. The connector uses these credentials to search for users and groups. Not required if the LDAP server provides access for anonymous authentication.
    • Bind Password: The password for an application service account, if Bind DN is set.

    Provide the user search attributes.

    • Base DN: The point from which to start the LDAP search. For example, OU=Users,OU=domain,DC=io.
    • Filter: An optional filter to be used by the LDAP search.
    • Username: The LDAP attribute that contains the user ID. For example, uid, sAMAccountName.

    Provide the group search attributes.

    • Base DN: The point from which to start the LDAP search. For example, OU=Groups,OU=domain,DC=io.
    • Filter: An optional filter to be used by the LDAP search.
    • Name Attribute: The LDAP attribute that holds the name of the group. For example, cn.
    • User Attribute: The attribute of the user record that is used as the value of the membership attribute of the group record. For example, distinguishedName, dn.
    • Group Attribute: The attribute of the group record that holds the user/member information. For example, member.

    Paste the contents of the LDAPS server CA certificate into the Root CA text box.

    (Optional) Verify the LDAP settings.

    • Click the Verify LDAP Configuration option.
    • Enter a user name and group name.
      Note: In Tanzu Kubernetes Grid v1.4.x, these fields are ignored and revert to cn for the user name and ou for the group name. For updates on this known issue, see the VMware Tanzu Kubernetes Grid 1.4 Release Notes.
    • Click Start. After completion of verification, if you see any failures, you must examine them closely in the subsequent steps.

    Note: The LDAP host performs this check, and not the Management Cluster nodes. So your LDAP configuration might work even if this verification fails.

    Configure external Identity Provider

  3. Click Next to go to Select the Base OS Image.

Select the Base OS Image

In the OS Image section, use the drop-down menu to select the OS and Kubernetes version image template to use for deploying Tanzu Kubernetes Grid VMs, and click Next.

How Base OS Image Choices are Generated

The OS Image drop-down menu includes OS images that meet all of the following criteria:

  • The image is available in your IaaS.
    • On vSphere, you must import images as described in Import the Base Image Template into vSphere. You can import an image now, without quitting the installer interface. After you import it, use the Refresh button to make it appear in the drop-down menu.
    • On Azure, you must accept the license as described in Accept the Base Image License in Prepare to Deploy Management Clusters to Microsoft Azure.
  • The OS image is listed in the Bill of Materials (BoM) file of the Tanzu Kubernetes release (TKr) for the Kubernetes version that the management cluster runs on.
    • Tanzu Kubernetes Grid v1.4 management clusters run on Kubernetes v1.21.2.
    • To use a custom image, you modify the TKr's BoM file to list the image, as explained in Build Machine Images.
    • vSphere, AWS, and Azure images are listed in the BoM's ova, ami, and azure blocks, respectively.
  • The image name in the IaaS matches its identifier in the TKr BoM:
    • vSphere, AWS, and Azure images are identified by their version, id, and sku field values, respectively.

Register with Tanzu Mission Control

This section applies to all infrastructure providers, however the functionality described in this section is being rolled out in Tanzu Mission Control.

NOTE: Registering a Tanzu Kubernetes Grid 1.4.0 management cluster is not supported. Tanzu Mission Control does not support cluster lifecycle management of 1.4.0 workload clusters. You can use Tanzu Mission Control with Tanzu Kubernetes Grid 1.4.0 by attaching your workload clusters to Tanzu Mission Control without registering them. For more information about attaching workload clusters to Tanzu Mission Control, see Attach an Existing Cluster.

  1. In the Registration URL field, copy and paste the registration URL you obtained from Tanzu Mission Control.

    Register with Tanzu Mission Control

  2. If the connection is successful, you can review the configuration YAML retrieved from the URL.

  3. Click Next.

Finalize the Deployment

This section applies to all infrastructure providers.

  1. In the CEIP Participation section, optionally deselect the check box to opt out of the VMware Customer Experience Improvement Program.

    You can also opt in or out of the program after the deployment of the management cluster. For information about the CEIP, see Manage Participation in CEIP and https://www.vmware.com/solutions/trustvmware/ceip.html.

  2. Click Review Configuration to see the details of the management cluster that you have configured.

    The image below shows the configuration for a deployment to vSphere.

    Review the management cluster configuration

    When you click Review Configuration, Tanzu Kubernetes Grid populates the cluster configuration file, which is located in the ~/.config/tanzu/tkg/clusterconfigs subdirectory, with the settings that you specified in the interface. You can optionally copy the cluster configuration file without completing the deployment. You can copy the cluster configuration file to another bootstrap machine and deploy the management cluster from that machine. For example, you might do this so that you can deploy the management cluster from a bootstrap machine that does not have a Web browser.

  3. (Optional) Under CLI Command Equivalent, click the Copy button to copy the CLI command for the configuration that you specified.

    Copying the CLI command allows you to reuse the command at the command line to deploy management clusters with the configuration that you specified in the interface. This can be useful if you want to automate management cluster deployment.

  4. (Optional) Click Edit Configuration to return to the installer wizard to modify your configuration.

  5. Click Deploy Management Cluster.

    Deployment of the management cluster can take several minutes. The first run of tanzu management-cluster create takes longer than subsequent runs because it has to pull the required Docker images into the image store on your bootstrap machine. Subsequent runs do not require this step, so are faster. You can follow the progress of the deployment of the management cluster in the installer interface or in the terminal in which you ran tanzu management-cluster create --ui. If the machine on which you run tanzu management-cluster create shuts down or restarts before the local operations finish, the deployment will fail. If you inadvertently close the browser or browser tab in which the deployment is running before it finishes, the deployment continues in the terminal.

    NOTE: The screen capture below shows the deployment status page in Tanzu Kubernetes Grid v1.4.0.

    Monitor the management cluster deployment

What to Do Next

  • Configure identity management: If you enabled OIDC or LDAP identity management for the management cluster, you must perform the post-deployment steps described in Configure Identity Management After Management Cluster Deployment to enable access. If you are using NSX Advanced Load Balancer (ALB) as your control plane endpoint, the post-deployment steps include integrating NSX ALB with your identity provider.
  • Save the configuration file: The installer saves the configuration of the management cluster to ~/.config/tanzu/tkg/clusterconfigs with a generated filename of the form UNIQUE-ID.yaml. After the deployment has completed, you can rename the configuration file to something memorable, for example the name that you provided to the management cluster, and save it in a different location for future use.
  • Deploy workload clusters: Once your management cluster is created, you can deploy Tanzu Kubernetes (workload) clusters as described in Deploy Tanzu Kubernetes Clusters.
  • Deploy another management cluster: To deploy more than one management cluster, on any or all of vSphere, Azure, and Amazon EC2, see Manage Your Management Clusters. This topic also provides information about how to add existing management clusters to your CLI instance, obtain credentials, scale and delete management clusters, add namespaces, and how to opt in or out of the CEIP.

For information about what happened during the deployment of the management cluster and how to connect kubectl to the management cluster, see Examine the Management Cluster Deployment.

check-circle-line exclamation-circle-line close-line
Scroll to top icon