Prerequisites for running HTTP virtual services in a Kubernetes cluster

You can find information about the tasks that you must complete before you configure a run of the HTTP virtual services in the HCL OneTest™ Server cluster or a remote Kubernetes cluster.

Important: The prerequisites do not apply when you use an API agent to run the HTTP virtual services.

Conditions for running of HTTP virtual services

Before you run the HTTP virtual services in the HCL OneTest™ Server cluster or a remote Kubernetes cluster, you must check for the following conditions and perform the actions indicated:
If... Then...

You want to route the HTTP traffic via the HTTP proxy either to the virtual service or live systems, based on routing rules.

You must set up the HTTP proxy. See Setting up intercepts.

You want to route the HTTP traffic to the virtual service via the HTTP proxy and the proxy is not configured to trust all certificates.

The trust store must be configured to include the certificate authority for the server certificate. See Certificate authority: Importing and extending lists.

A client application is sending requests directly to the virtual service.

The client application must trust the certificate authority for the server certificate. See Certificate authority: Importing and extending lists.

You are working with HCL OneTest™ Server V10.1.3, which is installed on Ubuntu.
HTTP virtual services are exposed via hostnames are of the following form:
in-<unique_id>.<INGRESS_DOMAIN>
Note: The DNS used by a computer that runs a client application or the HTTP proxy that routes traffic to the virtual service needs to resolve such hostnames to the IP address of the ingress domain.
You must perform the following actions that depend on the method you have used to set up the ingress domain:
  • If you used nip.io to form the ingress domain, then that virtual services host names are automatically resolved to the IP address of the ingress domain.
    For example, if you used nip.io to form the ingress domain as follows:
    10.1.2.3.nip.io
    The virtual services hostnames are resolved by nip.io to the IP address as 10.1.2.3.
  • If your ingress domain does not use nip.io then you must ensure that the DNS in use by the client application or the HTTP proxy can resolve hostnames of the virtual services to the IP address of the ingress domain. For example, if the ingress domain is as follows:
    myhost.mycom.com
    The DNS must resolve *.myhost.mycom.com to the IP address of myhost.mycom.com.

HTTPS virtual service endpoints

When you want to run an HTTP virtual service where the HTTP transport settings have Use SSL enabled, the virtual service endpoint that is exposed for the virtual service instance expects an HTTPS request on port 443. The exposed endpoint is managed by the same ingress controller or the HAProxy that is used for the server endpoints. The SSL/TLS termination occurs at the endpoint before the request is routed to the virtual service instance and results in the following implications:
  • The Virtualization (Server) SSL options that are specified in the HTTP transport have no effect.
  • The certificate served by the exposed virtual service endpoint is the same as that of server that is signed by the server certificate authority.