Examine and Register a Newly-Deployed Standalone Management Cluster

This topic explains how to verify and retrieve details from a newly-deployed standalone management cluster in Tanzu Kubernetes Grid, and provides links for how to register it with Tanzu Mission Control.

Management Cluster Networking

During the deployment of the management cluster, either from the installer interface or the CLI, Tanzu Kubernetes Grid creates a temporary management cluster using a Kubernetes in Docker, kind, cluster on the bootstrap machine. Then, Tanzu Kubernetes Grid uses it to provision the final management cluster on the platform of your choice, depending on whether you are deploying to vSphere, Amazon Web Services (AWS), or Microsoft Azure. After the deployment of the management cluster finishes successfully, Tanzu Kubernetes Grid deletes the temporary kind cluster.

When Tanzu Kubernetes Grid creates a management cluster for the first time, it also creates a folder ~/.config/tanzu/tkg/providers that contains all of the files required by Cluster API to create the management cluster.

The Tanzu Kubernetes Grid installer interface saves the settings for the management cluster that it creates into a cluster configuration file ~/.config/tanzu/tkg/clusterconfigs/UNIQUE-ID.yaml, where UNIQUE-ID is a generated filename. The installer also generates a Kubernetes-style, class-based object spec for the management cluster’s Cluster object, that is saved in a file with the same name as the management cluster. This class-based object spec is provided for information only. Deploying management clusters from a class-based object spec is not yet supported. For more information about cluster types in TKG 2.x, see Workload Clusters in About Tanzu Kubernetes Grid.

Important

By default, unless you set the KUBECONFIG environment variable to save the kubeconfig for a cluster to a specific file, all clusters that you deploy from the Tanzu CLI are added to a shared .kube-tkg/config file. If you delete the shared .kube-tkg/config file, all management clusters become orphaned and thus unusable.

Management Cluster Networking

When you deploy a management cluster, pod-to-pod networking with Antrea is automatically enabled in the management cluster.

Verify the Deployment of the Management Cluster

After the deployment of the management cluster completes successfully, you can obtain information about your management cluster by:

• Locating the management cluster objects in vSphere, AWS, or Azure
• Using the Tanzu CLI and kubectl

View Management Cluster Objects in vSphere, AWS, or Azure

The objects deployed depend on whether you deployed the management cluster to vSphere, AWS, or Azure.

vSphere

Go to the resource pool that you designated when you deployed the management cluster. You should see the following VMs or instances:

• One or three control plane VMs, for development or production control plane, respectively, with names similar to CLUSTER-NAME-control-plane-sx5rp
• One or three worker node VMs, for development or production, respectively, with names similar to CLUSTER-NAME-md-0-6b8db6b59d-kbnk4

AWS

Go to the Instances view of your Amazon EC2 dashboard. You should see the following VMs or instances:

• One or three control plane VMs on Amazon EC2, for development or production control plane, respectively, with names similar to CLUSTER-NAME-control-plane-bcpfp
• One or three worker node VMs, for development or production, respectively, with names similar to CLUSTER-NAME-md-0-dwfnm
• An EC2 bastion host VM with the name CLUSTER-NAME-bastion

Azure

Go to the resource group that you designated when you deployed the management cluster. You should see the following VMs or instances:

• One or three control plane VMs, for development or production control plane, respectively, with names similar to CLUSTER-NAME-control-plane-rh7xv
• One or three worker node VMs, for development or production, respectively, with names similar to CLUSTER-NAME-md-0-rh7xv
• Disk and Network Interface resources for the control plane and worker node VMs, with names based on the same name patterns

If you did not specify a name for the management cluster, CLUSTER-NAME is something similar to tkg-mgmt-vsphere-20200323121503 or tkg-mgmt-aws-20200323140554.

View Management Cluster Details With Tanzu CLI and kubectl

Tanzu CLI provides commands that facilitate many of the operations that you can perform with your management cluster. However, for certain operations, you still need to use kubectl.

When you deploy a management cluster, the kubectl context is not automatically set to context of the management cluster. Tanzu Kubernetes Grid provides two contexts for every management cluster and workload cluster:

• The admin context of a cluster gives you full access to that cluster.
  • If you implemented identity management on the cluster, using the admin context allows you to run kubectl operations without requiring authentication with your identity provider (IDP).
  • If you did not implement identity management on the management cluster, you must use the admin context to run kubectl operations.
• If you implemented identity management on the cluster, using the regular context requires you to authenticate with your IDP before you can run kubectl operations on the cluster.

Before you can run kubectl operations on a management cluster, you must obtain its kubeconfig.

1. On the bootstrap machine, run the tanzu context use command to see the available management clusters and which one is the current login context for the CLI.

   For more information, see List Management Clusters and Change Context.

2. To see the details of the management cluster, run tanzu mc get.

   For more information, see See Management Cluster Details.

3. To retrieve a kubeconfig for the management cluster, run the tanzu mc kubeconfig get command as described in Retrieve Management Cluster kubeconfig.

4. Set the context of kubectl to the management cluster.

   kubectl config use-context my-mgmt-cluster-admin@my-mgmt-cluster
   

5. Use kubectl commands to examine the resources of the management cluster.

   For example, run kubectl get nodes, kubectl get pods, or kubectl get namespaces to see the nodes, pods, and namespaces running in the management cluster.

Retrieve Management Cluster kubeconfig

The tanzu mc kubeconfig get command retrieves kubeconfig configuration information for the current management cluster, with options as follows:

• --export-file FILE

  • Without option: Add the retrieved cluster configuration information to the kubectl CLI’s current kubeconfig file, whether it is the default ~/.kube/config or set by the KUBECONFIG environment variable.
  • With option: Write the cluster configuration to a standalone kubeconfig file FILE that you can share with others.

• --admin

  • Without option: Generate a standard kubeconfig that requires the user to authenticate with an external identity provider, and grants them access to cluster resources based on their assigned roles. To generate a standard, non-admin kubeconfig, identity management and role-based access control (RBAC) must be configured on the cluster.
    • The context name for this kubeconfig includes a tanzu-cli- prefix. For example, tanzu-cli-id-mgmt-test@id-mgmt-test.
  • With option: Generate an admin kubeconfig containing embedded credentials that lets the user access the cluster without logging in to an identity provider, and grants full access to the cluster’s resources. If identity management is not configured on the cluster, you must specify the --admin option.
    • The context name for this kubeconfig includes an -admin suffix. For example, id-mgmt-test-admin@id-mgmt-test.

For example, to generate a standalone kubeconfig file to share with someone to grant them full access to your current management cluster:

tanzu mc kubeconfig get --admin --export-file MC-ADMIN-KUBECONFIG

To retrieve a kubeconfig for a workload cluster, run tanzu cluster kubeconfig get as described in Retrieve Workload Cluster kubeconfig.

Register Your Management Cluster with Tanzu Mission Control

Registering Tanzu Kubernetes Grid management clusters with Tanzu Mission Control allows you to provision and manage workload clusters by using the Tanzu Mission Control dashboard interface. To register your Tanzu Kubernetes Grid management cluster with Tanzu Mission Control:

• You must be a member of VMware Cloud Services organization that has access to Tanzu Mission Control. For more information, see Getting Started with VMware Tanzu Mission Control in the Tanzu Mission Control documentation.
• Management clusters that you register in Tanzu Mission Control must be production clusters with multiple control plane nodes. This configuration allows Tanzu Mission Control to support complete lifecycle management for workload clusters that are managed by the management cluster. For more information, see Requirements for Registering a Tanzu Kubernetes Cluster with Tanzu Mission Control in the Tanzu Mission Control documentation.

Supported Target Platforms

At time of publication, you can only register Tanzu Kubernetes Grid management clusters that are deployed on certain target platforms. For a list of currently supported providers, see Requirements for Registering a Tanzu Kubernetes Cluster with Tanzu Mission Control in the Tanzu Mission Control documentation.

AWS

Before deploying your management cluster on AWS, ensure that the tkg-cloud-vmware-com CloudFormation stack in the target AWS account includes the IAM permissions listed in Permissions Required by Tanzu Mission Control. These permissions are included automatically when you create or update the CloudFormation stack by running the tanzu mc permissions aws set command.

If you configured the IAM permissions defined in the CloudFormation stack manually, you must add the permissions listed in Permissions Required by Tanzu Mission Control to the nodes.tkg.cloud.vmware.com IAM policy or role.

Procedure

After you have deployed your management cluster through the Tanzu Kubernetes Grid installer interface or the Tanzu CLI, follow these instructions in the Tanzu Mission Control documentation:

1. Register a Management Cluster with Tanzu Mission Control and then Complete the Registration of a Management Cluster.

2. (Optional) After you successfully register a management cluster, you can add any existing workload clusters that are currently managed by the management cluster to Tanzu Mission Control. To manage these clusters in Tanzu Mission Control, see Add a Workload Cluster into Tanzu Mission Control Management.

What to Do Next

You can now use Tanzu Kubernetes Grid to start deploying workload clusters. For information, see Deploy Workload Clusters.

If you need to deploy more than one management cluster, on any or all of vSphere, Azure, and AWS, see Managing 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, and how to opt in or out of the CEIP.