What Can I Do If an On-Premises Cluster Fails to Be Connected?

Symptom

This section describes how to troubleshoot cluster connection exceptions and provides solutions. The following exceptions may occur when a cluster is connected to UCS:

• You have registered a cluster to UCS and deployed proxy-agent in the cluster, but the console always displays an error message, indicating that the cluster is waiting for connection or fails to get registered after the connection times out.
  

  If the cluster registration fails, click in the upper right corner to register it again and locate the fault as guided in Troubleshooting.

• If the status of a connected cluster is unavailable, rectify the fault by referring to Troubleshooting in this section.

Troubleshooting

Table 1 explains the error messages for you to locate faults.

Check Item 1: proxy-agent

After the cluster is unregistered from UCS, the authentication information contained in the original proxy-agent configuration file becomes invalid. You need to delete the proxy-agent pods deployed in the cluster. To connect the cluster to UCS again, download the proxy-agent configuration file from the UCS console again and use it for re-deployment.

1. Log in to the master node of the destination cluster.
2. Check the deployment of the cluster agent.

   kubectl -n kube-system get pod | grep proxy-agent

   Expected output for successful deployment:

   proxy-agent-*** 1/1 Running 0 9s

   If proxy-agent is not in the Running state, run the kubectl -n kube-system describe pod proxy-agent-*** command to view the pod alarms. For details, see What Can I Do If proxy-agent Fails to Be Deployed?.

   

   By default, proxy-agent is deployed with two pods, and can provide services as long as one pod is running properly. However, one pod cannot ensure high availability.

3. Print the pod logs of proxy-agent and check whether the agent program can connect to UCS.

   kubectl -n kube-system logs proxy-agent-*** | grep "Start serving"

   If no "Start serving" log is printed but the proxy-agent pods are working, check other check items.

Check Item 2: Network Connection Between the Cluster and UCS

For clusters connected through a public network:

1. Check whether a public IP is bound to the cluster or a public NAT gateway is configured.
2. Check whether the outbound traffic of the cluster security group is allowed. To perform access control on the outbound traffic, contact technical support to obtain the destination IP and port number.
3. After rectifying network faults, delete the existing proxy-agent pods to rebuild pods. Check whether the logs of the new pods contain "Start serving".

   kubectl -n kube-system logs proxy-agent-*** | grep "Start serving"

4. If desired logs are printed, refresh the UCS console page and check whether the cluster is properly connected.

For clusters connected through a private network:

1. Check whether the outbound traffic of the cluster security group is allowed. To perform access control on the outbound traffic, contact technical support to obtain the destination IP and port number.
2. Rectify the network connection faults between the cluster and UCS or IDC.
   Refer to the following guides according to your network connection type:

   • Direct Connect: Troubleshooting
   • Virtual Private Network (VPN): Troubleshooting

3. Rectify the VPC endpoint fault. The VPC endpoint status must be Accepted. If the VPC endpoint is deleted by mistake, create one again. For details, see How Do I Restore a Deleted VPC Endpoint for a Cluster Connected Over a Private Network?.
   Figure 1 Checking the VPC endpoint status
   

4. After rectifying network faults, delete the existing proxy-agent pods to rebuild pods. Check whether the logs of the new pods contain "Start serving".

   kubectl -n kube-system logs proxy-agent-*** | grep "Start serving"

5. If desired logs are printed, refresh the UCS console page and check whether the cluster is properly connected.

Check Item 3: kube-apiserver

When connecting a cluster to UCS, the error message shown in Figure 2 may be displayed, saying "please check the health status of kube apiserver: ...".

Figure 2 Abnormal kube-apiserver

This indicates that proxy-agent cannot communicate with the API server in the cluster. Users may have different network configurations for the cluster to connect to UCS. Therefore, UCS does not provide any unified solution for this fault. You need to rectify it on your own and try again.

1. Log in to the UCS console. In the navigation pane, choose Fleets.
2. Log in to the master node of the destination cluster and check whether the proxy-agent pods can access the apiserver of the destination cluster.

   Example command:

   kubectl exec -ti proxy-agent-*** -n kube-system /bin/bash
   # Access kube-apiserver of the cluster.
   curl -kv https://kubernetes.default.svc.cluster.local/readyz

   If the access fails, rectify the cluster network fault, register the cluster to UCS again, and re-deploy proxy-agent.

Check Item 4: Cluster Authentication Information Changes

If the error message "cluster responded with non-successful status: [401][Unauthorized]" is displayed, the IAM network connection may be faulty, according to the /var/paas/sys/log/kubernetes/auth-server.log of the three master nodes in the cluster. Ensure that the IAM domain name resolution and the IAM service connectivity are normal.

The common issue logs are as follows:

• Failed to authenticate token: *******: dial tcp: lookup iam.myhuaweicloud.com on *.*.*.*:53: no such host

  This log indicates that the node is not capable of resolving iam.myhuaweicloud.com. Configure the corresponding domain name resolution by referring to Preparing for Installation.

• Failed to authenticate token: Get *******: dial tcp *.*.*.*:443: i/o timeout

  This log indicates that the node's access to IAM times out. Ensure that the node can communicate with IAM properly.

• currently only supports Agency token

  This log indicates that the request is not initiated by UCS. Currently, on-premises clusters can only be connected to UCS using IAM tokens.

• IAM assumed user has no authorization/iam assumed user should allowed by TEAdmin

  This log indicates that the connection between UCS and the cluster is abnormal. Contact Huawei technical support for troubleshooting.

• Failed to authenticate token: token expired, please acquire a new token

  This log indicates that the token has expired. Run the date command to check whether the time difference is too large. If yes, synchronize the time and check whether the cluster is working. If the fault persists for a long time, you may need to reinstall the cluster. In this case, contact Huawei technical support.

After the preceding problem is resolved, run the crictl ps | grep auth | awk '{print $1}' | xargs crictl stop command to restart the auth-server container.