Faq

faq.md# Frequently Asked Questions

1 Installation Issues During Initial Setup: Cleaning and Reinstalling¶

Note: This applies only to situations where problems occur during initial installation and you need to completely remove and reinstall. Please confirm carefully before executing the following cleanup steps!

If installation issues arise and you need to completely remove everything and reinstall, you must clean the following three areas before restarting the installation from LauncherGuance:

1.1 Clean Up InstalledGuance Application Services¶

To clean up the variousGuance application services installed in Kubernetes, enter the Launcher container on the operation machine and run the cleanup script provided with Launcher:

kubectl exec -it launcher-xxxxxxxx-xxx -n launcher /bin/bash

1.2 Clean Up Automatically Created Databases in MySQL¶

Enter the Launcher container, which includes a MySQL client tool. Use the following command to connect to yourGuanceMySQL instance:

mysql -h <mysql 实例 host> -u root -P <mysql 端口> -p  

drop database df_core;
drop user df_core;
drop database df_message_desk;
drop user df_message_desk;
drop database df_func;
drop user df_func;
drop database df_dialtesting;
drop user df_dialtesting;

1.3 Clean Up Automatically Created Users in InfluxDB¶

If you are using InfluxDB as the time series engine, connect to InfluxDB using the influx client tool and execute the following two user cleanup commands:

drop user user_wr;
drop user user_ro;

2 Deployment Considerations¶

2.1 Can I manually modify the Kubernetes resources automatically generated by the installer after deployment?¶

You should not manually modify them, because when a new version is released later and you upgrade using Launcher, it will regenerate resources such as Deployment, Service, and Ingress based on the configuration provided during installation (ConfigMaps are an exception; the information in ConfigMap configuration items can be freely modified, but arbitrary changes may cause abnormal program behavior).

3 Certificate Renewal for Standalone Container Rancher Server¶

3.1 What to Do If the Certificate Has Not Expired¶

The Rancher server can operate normally. If you upgrade to Rancher v2.0.14+, v2.1.9+, or v2.2.2+, it will automatically check the certificate validity period. If it finds that the certificate is about to expire, it will automatically generate a new certificate. Therefore, for a standalone container Rancher server, you only need to upgrade the Rancher version to one that supports automatic SSL certificate renewal before the certificate expires. No other actions are required.

3.2 What to Do If the Certificate Has Already Expired¶

The Rancher server cannot operate normally. Even if you upgrade to Rancher v2.0.14+, v2.1.9+, or v2.2.2+, you may still encounter certificate errors. If this occurs, follow these steps:

1. Normally upgrade the Rancher version to v2.0.14+, v2.1.9+, or v2.2.2+.

2. Execute the following commands:

3. For v2.0 or v2.1

docker exec -ti <rancher_server_id>mv /var/lib/rancher/management-state/certs/bundle.json /var/lib/rancher/management-state/certs/bundle.json-bak

• For v2.2+

docker exec -ti <rancher_server_id>mv /var/lib/rancher/management-state/tls/localhost.crt /var/lib/rancher/management-state/tls/localhost.crt-bak

• For v2.3+

 docker exec -ti <rancher_server_id>mv /var/lib/rancher/k3s/server/tls /var/lib/rancher/k3s/server/tlsbak

 # Execute twice; first time to request the certificate, second time to load the certificate and start
 docker restart <rancher_server_id>

• For v2.4+

  a. exec into the Rancher server

kubectl --insecure-skip-tls-verify -n kube-system delete secrets k3s-serving
kubectl --insecure-skip-tls-verify delete secret serving-cert -n cattle-system
rm -f /var/lib/rancher/k3s/server/tls/dynamic-cert.json

 b. Restart the Rancher server

docker restart <rancher_server_id>

 c. Execute the following command to refresh the parameters

curl --insecure -sfL https://server-url/v3

1. Restart the Rancher Server container

docker restart <rancher_server_id>

4 Handling Inability to Manage Kubernetes Clusters Due to Expired Rancher Server Certificates¶

If the cluster certificate has expired, upgrading to Rancher v2.0.14, v2.1.9, or higher will not rotate the certificate. Rancher uses an Agent to update certificates; if the certificate has expired, it cannot connect to the Agent.

4.1 Solution¶

You can manually adjust the node time, setting it back slightly. Since the Agent only communicates with the Kubernetes master and the Rancher Server, if the Rancher Server certificate has not expired, you only need to adjust the time on the Kubernetes master node. Adjustment command:

# Disable NTP synchronization to prevent automatic time updates
timedatectl set-ntp false
# Modify the node time
timedatectl set-time '2019-01-01 00:00:00'

Then upgrade the Rancher Server. After the certificate rotation is complete, restore the time synchronization.

timedatectl set-ntp true

openssl x509 -in /etc/kubernetes/ssl/kube-apiserver.pem -noout -dates

5 Why Is the Created DataWay Not Visible in the Frontend¶

5.1 Common Causes¶

• The DataWay service deployed to the server is not running properly.
• The DataWay service configuration file is incorrect; the listening port or workspace token is not configured correctly.
• The DataWay service runtime configuration is incorrect; check the DataWay logs to locate the issue.
• The server where DataWay is deployed cannot communicate with the Kodo service (including missing correct resolution of the df-kodo service in the server's hosts file).
• The Kodo service is abnormal; confirm by checking the Kodo service logs.
• The df-kodo ingress service is not configured correctly. This manifests as being unable to access http|https://df-kodo.<xxxx>:<port>

6 Why Can't I Use the Synthetic Monitoring Service¶

6.1 Root Cause Analysis¶

• The deployedGuance application is in an offline environment, and the physical node network cannot reach the internet (common).
• The self-hosted probe node has a network issue.
• The regional ISP network is abnormal.
• The synthetic test task was created incorrectly.

7 Common Deployment Issues and Solutions¶

7.1 describe pods Reports unbound immediate PersistentVolumeClaims Error¶

• Check the PVCs:

NAMESPACE    NAME                                     STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
default      opensearch-single-opensearch-single-0    Bound     pvc-0da2cb6f-1cb9-4630-b0ab-512ce57743a8   16Gi       RWO            openebs-hostpath   19d
launcher     persistent-data                          Pending                                                                        df-nfs-storage     6m3s
middleware   data-es-cluster-0                        Bound     pvc-36e48f5a-37b3-4c28-ad14-059265ee3009   50Gi       RWO            openebs-hostpath   18d

The persistent-data PVC status is Pending.

• Check the status of the nfs-subdir-external-provisioner container:

kubectl get pods -n kube-system  | grep nfs-subdir-external-provisioner
nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr   0/1     ContainerCreating   0             7h7m

• Check the nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr information:

kubectl describe  -n kube-system pods nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr
....
  Type     Reason       Age                     From     Message
  ----     ------       ----                    ----     -------
  Warning  FailedMount  30m (x49 over 6h53m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[nfs-subdir-external-provisioner-root], unattached volumes=[kube-api-access-5p4qn nfs-subdir-external-provisioner-root]: timed out waiting for the condition
  Warning  FailedMount  5m27s (x136 over 7h4m)  kubelet  Unable to attach or mount volumes: unmounted volumes=[nfs-subdir-external-provisioner-root], unattached volumes=[nfs-subdir-external-provisioner-root kube-api-access-5p4qn]: timed out waiting for the condition
  Warning  FailedMount  74s (x217 over 7h6m)    kubelet  MountVolume.SetUp failed for volume "nfs-subdir-external-provisioner-root" : mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs 10.200.14.112:/nfsdata /var/lib/kubelet/pods/3970ff5f-5dbf-419e-a6af-3080508d2524/volumes/kubernetes.io~nfs/nfs-subdir-external-provisioner-root
Output: mount: wrong fs type, bad option, bad superblock on 10.200.14.112:/nfsdata,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

wrong fs type, bad option The cause is that nfs-utils is not installed.

• Install nfs-utils

Run the following command on the host:

yum install nfs-utils