Considerations for using a remote Kubernetes cluster
When you want to use a remote Kubernetes cluster as a location to run the supported tests or test resources, you must read the considerations first.
Before you want to run any of the supported tests or test resources on Rational® Test Automation
Server that are configured to run
on a remote Kubernetes cluster, you must have completed the following tasks:
- Verified that the Kubernetes cluster that you want to use is a supported one by referring to the OS, platform, and containers that are specified for Rational® Test Automation Server in System Requirements.
- Kept a suitable kubeconfig file with access to the remote Kubernetes cluster in a folder on the computer that you want to use to access an instance of Rational® Test Automation Server.
You must be familiar with the administration of a Kubernetes cluster. When you as the
cluster administrator, set up the remote Kubernetes cluster must consider the following
requirements:
- You must have a kubeconfig file with access to the remote
Kubernetes cluster in a folder on the computer that you want to use to access an
instance of Rational® Test Automation
Server.Note: If the kubeconfig file references certificate files by using filepaths then the certificate data must be embedded in the kubeconfig file to make it usable by Rational® Test Automation Server. If the kubeconfig file contains multiple contexts, then only the current context is required.You can use the following kubectl command to create a suitable kubeconfig file called portable-config in the current folder. The portable-config file contains embedded certificate data and the information used by the current context:
kubectl config view --flatten --minify > portable-config
- You must ensure that the remote Kubernetes cluster is able to access the Rational® Test Automation
Server image registry
which is the same registry that you used to install Rational® Test Automation
Server. There is no need
to copy the Rational® Test Automation
Server image
to the remote Kubernetes cluster but the remote cluster must be able to access
the image registry at test runtime.If the remote cluster that you want to use is a Lightweight Kubernetes (k3s) cluster, it might require a Secret to pull the Rational® Test Automation Server image. You must run the following command on the remote k3s cluster:
kubectl create secret docker-registry cp.icr.io \ -n {remote-namespace} \ --docker-server=cp.icr.io \ --docker-username=cp \ --docker-password={your_entitlement_key} \ --docker-email={example@abc.com}Notes:- You must replace {remote-namespace} with the value of the namespace that you have used for the remote cluster.
- If the user name contains any special characters, such as $, you must enclose it within single quotation-marks.
- You can replace {example@abc.com} with the email address of the administrator, if required.
- You need not configure separate licenses for running on the remote cluster because the licenses are consumed from the pool of available licenses that are configured for the team space on Rational® Test Automation Server. The licenses are returned to the pool when the test run is completed on the remote cluster.
- You must ensure that the Rational® Test Automation Server domain is accessible from the remote cluster so that the pod in the cluster is able to communicate with Rational® Test Automation Server.
- You must ensure that the appropriate PriorityClass exists on the remote cluster if you want to control the priority given to the remote execution pod by the scheduler. The same PriorityClass that is used by the Rational® Test Automation Server execution pod is used by the remote execution pod. If the named PriorityClass does not exist in the remote cluster, then no PriorityClass is specified by the remote execution pod.
- You must provide the Ingress details such as Ingress type, Ingress host pattern, and Ingress secret when you register a remote cluster with your team space on Rational® Test Automation Server. These configurations are required when you want to run virtual services on the remote cluster and run tests from the remote cluster that use static agents.
- You can enter the code snippets for nodeSelectors and
tolerations in a yaml format, if you
want to use nodeSelectors and tolerations
on the remote cluster. You can enter these in the fields provided in the
Advanced configuration dialog when you register a
remote cluster with your team space on Rational® Test Automation
Server.
For more information about nodeSelector, see nodeSelector and for tolerations, see Tolerations.
Restrictions: The following
restrictions apply when you want to run the supported tests on a remote Kubernetes
cluster:
- Using the UserLibs that are required for running certain API Suites are not supported on the remote cluster.
- Running of Compound Tests that contain performance tests, which require the NodePort access to connect to static agents, are not supported on the remote cluster.
When you plan to run any of the test assets or resources on a remote Kubernetes cluster
from a project on Rational® Test Automation
Server, you
must complete the following tasks:
| Tasks | More information... | |
|---|---|---|
| 1 | Register a remote Kubernetes cluster with a team space on Rational® Test Automation Server. | Registering a remote Kubernetes cluster |
| 2 | View remote Kubernetes clusters added to a team space. | Viewing remote Kubernetes clusters |
| 3 | Add a remote Kubernetes cluster to a project in a team space. | Adding a remote Kubernetes cluster to a project |
| 4.1 | Configure a run for your test that you want to run on the remote
Kubernetes cluster by performing the following actions:
|
|
| 4.2 | Configure a run of the virtual service resources that you want to run
on the remote Kubernetes cluster by performing the following actions:
|