Troubleshooting issues

• Slow connection speeds.
• Insufficient CPU, memory, or disk resources.
• A firewall that was configured incorrectly is already enabled.

• To identify the issue, you can perform a diagnostic check by running the following command:

  journalctl -u k3s

  This command displays the log that you can use to check for the problem.
• Run the following command to see which pods are running and which pods are not running:

  kubectl get pods -A

  Run the following command to get details about a specific pod:

  kubectl describe pod -n <namespace> <pod name>

• Follow the on-screen instructions to resolve the errors.
• Some issues can be solved by re-running the following script:

  sudo ./k3s-init.sh

kubectl get cm -n kube-system coredns -ojsonpath="{.data.Corefile}"

 .:53 {
   :
      forward . 8.8.8.8 9.9.9.9
   :
  }

sudo ./ubuntu-set-dns.sh --server 8.8.8.8 --server 9.9.9.9

sudo ./ubuntu-set-dns.sh --help

You can’t request to join a project that has no owners

1. Start the Docker daemon manually in a terminal window on the remote Docker host computer.
2. Click the Test Connection in the New docker host dialog on the Agents and Intercepts page.
3. Look for any messages that might indicate the root cause of the problem such as bad certificate.

$ docker --tlsverify \
    –-tlscacert=ca.pem \
    -–tlscert=cert.pem \
    -–tlskey=key.pem \
    -H=$HOST:2376 version

• The schedule has two user groups configured to run on static agents when the schedule was created in Test Performance 10.1.
• One of the user groups is disabled and the asset is committed to the remote repository.

• The schedule was created in Test Performance 10.1.
• The user group that is disabled is not removed or deleted from the test resources.
• The agent configured on the disabled user group is already added as an agent to the server project and is available for selection.

• By using Test Performance 10.1.1.
  Perform the following steps:

  1. Open the schedule in Test Performance 10.1.1.
  2. Save the schedule and the project.
  3. Commit your test asset to the remote repository.
  4. Proceed to configure a run for the schedule on Test Hub 10.1.1.
• By using Test Performance 10.1.
  Perform the following steps:

  1. Select the disabled user group.
  2. Click Remove.
  3. Save the schedule and the project.
  4. Commit your test asset to the remote repository.
  5. Proceed to configure a run for the schedule on Test Hub 10.1.1.

• Postman
• JMeter
• JUnit

• When many tests are run simultaneously on the default cluster location and you observe the following issues:
  • Out of memory errors.
  • Observe that the test runs are slow with a high CPU usage.
  • The Kubernetes pods are getting evicted.
• When you run an AFT suite that contains multiple Web UI tests and you observe the following issues:
  • Error stating that the browser might not be installed or the browser version is unsupported.
  • Error stating multiple random time-outs or an internal error.
• When you run VU schedules that contain multiple Web UI test or large number of virtual users or a combination of Web UI, performance, and API tests, and you observe the following issue:
  • The test run hangs and the inadequacy of memory can be inferred as the cause in the logs.

• Many tests are run in parallel.
• The memory that is used by the tests during the test run exceeds the allocated default memory of 1 GB.
• The default memory of the container is not adequate for the test run.
• Pods are evicted due to low node memory.