This section includes tips to help you to troubleshoot common problems that you might encounter when installing Tanzu Kubernetes Grid and deploying Tanzu Kubernetes clusters.

Many of these procedures use the kind CLI on your bootstrap machine. To install kind, see Installation in the kind documentation.

Clean Up After an Unsuccessful Management Cluster Deployment

Problem

An unsuccessful attempt to deploy a Tanzu Kubernetes Grid management cluster leaves orphaned objects in your cloud infrastructure and on your bootstrap machine.

Solution

  1. Monitor your tanzu management-cluster create command output either in the terminal or Tanzu Kubernetes Grid installer interface. If the command fails, it prints a help message that includes the following: "Failure while deploying management cluster... To clean up the resources created by the management cluster: tkg delete mc...."
  2. Run tanzu management-cluster delete YOUR-CLUSTER-NAME. This command removes the objects that it created in your infrastructure and locally.

You can also use the alternative methods described below:

  • Bootstrap machine cleanup:

    • To remove a kind cluster, use the kind CLI. For example:

      kind get clusters
      kind delete cluster --name tkg-kind-example1234567abcdef
      
    • To remove Docker objects, use the docker CLI. For example, docker rm, docker rmi, and docker system prune.

      CAUTION: If you are running Docker processes that are not related to Tanzu Kubernetes Grid on your system, remove unneeded Docker objects individually.

  • Infrastructure provider cleanup:

    • vSphere: Locate, power off, and delete the VMs and other resources that were created by Tanzu Kubernetes Grid.
    • AWS: Log in to your Amazon EC2 dashboard and delete the resources manually or use an automated solution.
    • Azure: In Resource Groups, open your AZURE_RESOURCE_GROUP. Use checkboxes to select and Delete the resources that were created by Tanzu Kubernetes Grid, which contain a timestamp in their names.

Delete Users, Contexts, and Clusters with kubectl

To clean up your kubectl state by deleting some or all of its users, contexts, and clusters:

  1. Open your ~/.kube/config and ~/.kube-tkg/config files.

  2. For the user objects that you want to delete, run:

    kubectl config unset users.USER-NAME
    kubectl config unset users.USER-NAME --kubeconfig ~/.kube-tkg/config
    

    Where USER-NAME is the name property of each top-level user object, as listed in the config files.

  3. For the context objects that you want to delete, run:

    kubectl config unset contexts.CONTEXT-NAME
    kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
    

    Where CONTEXT-NAME is the name property of each top-level context object, as listed in the config files, typically of the form contexts.mycontext-admin@mycontext.

  4. For the cluster objects that you want to delete, run:

    kubectl config unset clusters.CLUSTER-NAME
    kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
    

    Where CLUSTER-NAME is the name property of each top-level cluster object, as listed in the config files.

  5. If the config files list the current context as a cluster that you deleted, unset the context:

    kubectl config unset current-context
    kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
    
  6. If you deleted management clusters that are tracked by the tanzu CLI, delete them from the tanzu CLI's state by running tanzu config server delete as described in Delete Management Clusters from Your Tanzu CLI Configuration.

    • To see the management clusters that the tanzu CLI tracks, run tanzu login.

Kind Cluster Remains after Deleting Management Cluster

Problem

Running tanzu management-cluster delete removes the management cluster, but fails to delete the local kind cluster from the bootstrap machine.

Solution

  1. List all running kind clusters and remove the one that looks like tkg-kind-unique_ID

    kind delete cluster --name tkg-kind-unique_ID
    
  2. List all running clusters and identify the kind cluster.

    docker ps -a
    
  3. Copy the container ID of the kind cluster and remove it.

    docker kill container_ID
    

Machines Stuck After Management Cluster Fails to Deploy

Problem

Your management cluster fails to deploy because machines are stuck, waiting for remediation.

Solution

For a management cluster that you deployed with the dev plan, that only has one control plane node, you must redeploy the management cluster. For management clusters with more than one control plane node, you can identify and delete the stuck machines.

  1. Retrieve the status of the management cluster. For example:

    kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
    
  2. Find the names of the stuck machines from the output of the previous step. A stuck machine is WaitingForRemediation. For example, the name of the stuck machine is my-mgmt-cluster-zpc7t in the following output:

    status:
     conditions:
     - lastTransitionTime: "2021-08-25T15:44:23Z"
       message: KCP can't remediate if current replicas are less or equal then 1
       reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
       severity: Warning
       status: "False"
       type: Ready
    
  3. Increase the machine health check (MHC) timeout values for the control plane nodes to greater than the default, 5m. For example:

    tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
    

    For more information about updating a MachineHealthCheck object, see Create or Update a MachineHealthCheck Object in Configure Machine Health Checks for Tanzu Kubernetes Clusters.

  4. Set kubectl to the context of your management cluster. For example:

    kubectl config use-context mgmt-cluster-admin@mgmt-cluster
    
  5. Delete the stuck machines.

    kubectl delete machine MACHINE-NAME
    

    Where MACHINE-NAME is the name of the machine you located in an earlier step.

  6. Wait for the KubeadmControlPlane controller to redeploy the machine.

Failed Validation, Credentials Error on Amazon EC2

Problem

Running tanzu management-cluster create fails with an error similar to the following:

Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain

Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request

Solution

Tanzu Kubernetes Grid uses the default AWS credentials provider chain. Before creating a management or a workload cluster on Amazon EC2, you must configure your AWS account credentials as described in Configure AWS Credentials.

Failed Validation, Legal Terms Error on Azure

Before creating a management or workload cluster on Azure, you must accept the legal terms that cover the VM image used by cluster nodes. Running tanzu management-cluster create or tanzu cluster create without having accepted the license fails with an error like:

User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.

If this happens, accept the legal terms and try again:

Deploying a Tanzu Kubernetes Cluster Times Out, but the Cluster Is Created

Problem

Running tanzu cluster create fails with a timeout error similar to the following:

I0317 11:11:16.658433 clusterclient.go:341] Waiting for resource my-cluster of type *v1alpha3.Cluster to be up and running
E0317 11:26:16.932833 common.go:29]
Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be provisioned (this may take a few minutes): cluster control plane is still being initialized
E0317 11:26:16.933251 common.go:33]

Solution

Use the --timeout flag to specify the time to wait for the cluster provisioning to complete. The default waiting time is 30 minutes.

tanzu cluster create --timeout TIME

Where TIME is the length of time, in minutes, to wait for the completion of cluster provisioning. For example:

--timeout 60m

Note: The time required may depend on the region.

Pods Are Stuck in Pending on Cluster Due to vCenter Connectivity

Problem

When you run kubectl get pods -A on the created cluster, some pods remain in pending.

You run kubectl describe pod -n pod-namespace pod-name on an affected pod and review events and see the following event:

n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate

Solution

Ensure there is connectivity and firewall rules in place to ensure communication between the cluster and vCenter. For firewall ports and protocols requirements, see Ports and Protocols

Tanzu Kubernetes Grid UI Does Not Display Correctly on Windows

Problem

When you run the tanzu management-cluster create --ui command on a Windows system, the UI opens in your default browser, but the graphics and styling are not applied. This happens because a Windows registry is set to application/x-css.

Solution

  1. In Windows search, enter regedit to open the Registry Editor utility.
  2. Expand HKEY_CLASSES_ROOT and select .js.
  3. Right-click Content Type and select Modify.
  4. Set the Value to application/javascript and click OK.
  5. Run the tanzu management-cluster create --ui command again to relaunch the UI.

Running tanzu management-cluster create on macOS Results in kubectl Version Error

Problem

If you run the tanzu management-cluster create command on macOS with the latest stable version of Docker Desktop, tanzu management-cluster create fails with the error message:

Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.17.0

This happens because Docker Desktop symlinks kubectl 1.15 into the path.

Solution

Place a newer supported version of kubectl in the path before Docker's version.

Connect to Cluster Nodes with SSH

You can use SSH to connect to individual nodes of management clusters or Tanzu Kubernetes clusters. To do so, the SSH key pair that you created when you deployed the management cluster must be available on the machine on which you run the SSH command. Consquently, you must run ssh commands on the machine on which you run tanzu commands.

The SSH keys that you register with the management cluster, and consequently that are used by any Tanzu Kubernetes clusters that you deploy from the management cluster, are associated with the following user accounts:

  • vSphere management cluster and Tanzu Kubernetes nodes running on both Photon OS and Ubuntu: capv
  • Amazon EC2 bastion nodes: ubuntu
  • Amazon EC2 management cluster and Tanzu Kubernetes nodes running on Ubuntu: ubuntu
  • Amazon EC2 management cluster and Tanzu Kubernetes nodes running on Amazon Linux: ec2-user
  • Azure management cluster and Tanzu Kubernetes nodes (always Ubuntu): capi

To connect to a node by using SSH, run one of the following commands from the machine that you use as the bootstrap machine:

  • vSphere nodes: ssh capv@node_address
  • Amazon EC2 bastion nodes and management cluster and workload nodes on Ubuntu: ssh ubuntu@node_address
  • Amazon EC2 management cluster and Tanzu Kubernetes nodes running on Amazon Linux: ssh ec2-user@node_address
  • Azure nodes: ssh capi@node_address

Because the SSH key is present on the system on which you are running the ssh command, no password is required.

Recover Management Cluster Credentials

If you have lost the credentials for a management cluster, for example by inadvertently deleting the .kube-tkg/config file on the system on which you run tanzu commands, you can recover the credentials from the management cluster control plane node.

  1. Run tanzu management-cluster create to recreate the .kube-tkg/config file.
  2. Obtain the public IP address of the management cluster control plane node, from vSphere, Amazon EC2, or Azure.
  3. Use SSH to log in to the management cluster control plane node.

    See Connect to Cluster Nodes with SSH above for the credentials to use for each infrastructure provider.

  4. Access the admin.conf file for the management cluster.

    sudo vi /etc/kubernetes/admin.conf
    

    The admin.conf file contains the cluster name, the cluster user name, the cluster context, and the client certificate data.

  5. Copy the cluster name, the cluster user name, the cluster context, and the client certificate data into the .kube-tkg/config file on the system on which you run tanzu commands.

Restore ~/.config/tanzu Directory

Problem

The ~/.config/tanzu directory on the bootstrap machine has been accidentally deleted or corrupted. The tanzu CLI creates and uses this directory, and cannot function without it.

Solution

To restore the contents of the ~/.config/tanzu directory:

  1. To identify existing Tanzu Kubernetes Grid management clusters, run:

    kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
    

    The command output lists names and contexts of all management clusters created or added by the tkg (v1.2) or tanzu CLI.

  2. For each management cluster listed in the output, restore it to the ~/.config/tanzu directory and CLI by running:

    tanzu login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
    

Disable nfs-utils on Photon OS Nodes

Problem

In Tanzu Kubernetes Grid v1.1.2 and later, nfs-utils is enabled by default. If you do not require nfs-utils, you can remove it from cluster node VMs.

Solution

To disable nfs-utils on clusters that you deploy with Tanzu Kubernetes Grid v1.1.2 or later, use SSH to log in to the cluster node VMs and run the following command:

tdnf erase nfs-utils

For information about using nfs-utils on clusters deployed with Tanzu Kubernetes Grid v1.0 or 1.1.0, see Enable or Disable nfs-utils on Photon OS Nodes in the VMware Tanzu Kubernetes Grid 1.1.x Documentation.

Requests to NSX Advanced Load Balancer VIP fail with the message no route to host

Problem

If the total number of LoadBalancer type Service is large, and if all of the Service Engines are deployed in the same L2 network, requests to the NSX Advanced Load Balancer VIP can fail with the message no route to host.

This occurs because the default ARP rate limit on Service Engines is 100.

Solution

Set the ARP rate limit to a larger number. This parameter is not tunable in NSX Advanced Load Balancer Essentials, but it is tunable in NSX Advanced Load Balancer Enterprise Edition.

Tanzu CLI Cannot Reach Management Cluster

Problem

Failure messages are seen when running tkg or tanzu CLI commands on a Tanzu Kubernetes Grid (TKG). The failure message is see on an installation that is a year old and was upgraded at least once since initial installation.

Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying

The failure messages are seen because the relevant certificate has expired.

Solution

This is a known issue that affects TKG 1.2 and later. For a workaround, see Renew CLI Certificate and Cannot access the clusters using tkg/tanzu cli commands in Tanzu Kubernetes Grid.

Post-Deploy Pinniped Job Fails

Problem

Upgrading to Tanzu Kubernetes Grid v1.4.0 returns an error similar to the following:

 Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again

Solution

This error may occur if the Pinniped post-deploy job conflicts with a component's upgrade process. Follow these steps to delete and redeploy the job.

  1. Delete the Pinniped post-deploy job.

    kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
    
  2. Wait about 5 minutes for kapp-controller to redeploy the post-deploy job.

  3. Check the status of the Pinniped app.

    kubectl get app -n tkg-system pinniped
    NAME       DESCRIPTION           SINCE-DEPLOY   AGE
    pinniped   Reconcile succeeded   5s             49m
    

    If the DESCRIPTION shows Reconciling, wait a few minutes, then check again. Once it shows Reconcile succeeded continue to the next step.

  4. Check the status of the Pinniped post-deploy job.

    kubectl get jobs -n pinniped-supervisor
    NAME                             COMPLETIONS   DURATION   AGE
    pinniped-post-deploy-job-ver-1   1/1           9s         62s
    

For more information about troubleshooting the configuration of core packages, see Update and Troubleshoot Core Add-On Configuration.

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