Kubernetes configuration settings

This section describes how to configure settings for a Kubernetes image on the OpenText Enterprise Performance Engineering server.

Configure Kubernetes settings

When using a Kubernetes orchestrator with Dockerized host images, you configure the following Kubernetes behavior in the kubernetes.config file. The configuration supports the following capabilities:

  • Image pull policy configuration

  • Access to containerized load generators

  • Load balancer IP allocation timeout and connection delays

  • Kubernetes service annotations

  • Service account auto‑mount control

  • Kubernetes health probes

  • TLS verification control

  • Pod and container security context settings

  • Persistent storage using PersistentVolumeClaims (PVCs)

  • Node taints and tolerations

Note:  

  • Always restart IIS (iisreset) after updating kubernetes.config for changes to take effect. We recommend backing up the file because it is deleted during uninstall or upgrade.

  • If upgrading from a version earlier than 25.1, add the following lines to the </configSections> section, then restart IIS:

    <section name="GlobalSecurityContext" type="PC.DynamicHostProvision.Common.SecurityContextConfig, PC.DynamicHostProvision.Common"/>

    <section name="Tolerations" type="PC.DynamicHostProvision.Common.TolerationsConfig, PC.DynamicHostProvision.Common"/>

Configure the image pull policy

The image pull policy determines how Kubernetes pulls container images during pod creation or updates.

Policy value Description

IfNotPresent (EKS)

Pull If Not Present (AKS)

Pulls the image only if it does not already exist on the node.

This is the default value if no value is set, or if the pull policy key is missing from the configuration file.

Always (EKS)

Pull Always (AKS)

Always pull the image from the registry.

Never (EKS)

Pull Never (AKS)

Never pulls the image.

To configure the image pull policy:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Add the ImagePullPolicy key under <appsettings>.

    Example - EKS:

    Copy code
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <appSettings>
        <add key="DeploymentAPIVersion" value="apps/v1"/>
        <add key="PodAPIVersion" value="v1"/>
        <add key="ServiceAPIVersion" value="v1"/>
        <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
        <add key="ImagePullPolicy" value="Always" />
      </appSettings>
    </configuration>
  3. If your cluster uses a private registry:

    1. In Docker Hub, sign in to your private registry by running docker login.

    2. Create a Kubernetes registry secret:

      Copy code
      kubectl create secret generic <secret name> \   
         --from-file=.dockerconfigjson=<path/to/.docker/config.json> \   
         --type=kubernetes.io/dockerconfigjson
    3. Record the secret name and configure it in Administration > Orchestration. For details, see Add and configure the orchestrator.

  4. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Define access to containerized load generators

You can define how Kubernetes pods, or containerized load generators, are accessed based on your cluster configuration. If you use a load balancer such as AKS, use the cloud provider load balancer. For on-premises Kubernetes, you can connect to pods through a node port or a load balancer with an external IP. A node is the machine that runs the pods or containers.

Example: This diagram shows the implementation of the load balancer service with external IP flow.

Load balancer service with external IP flow

To define how containerized load generators are accessed:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Under <appsettings>, add the KubernetesAccessType key with one of the following values.

    Value Description
    NodePortNodeNames

    Exposes services on an internal cluster IP.

    This is the default if no value is set, or if the access type key is missing.

    NodePortExternalIPs

    Exposes services through a static port on each node’s external IP.

    LoadBalancerIngress

    Uses the cloud provider’s load balancer. This enables provisioning load generators that are set up in different networks to the Controller.

    Note:

    • Azure Kubernetes Service (AKS) and Amazon Elastic Kubernetes Service (EKS) load balancers with External IPs are currently supported. For supported versions, see the Supported Protocols guide available from Support Matrix.

    • When using this access type, you can set a timeout for waiting for all Load Balancer IPs to be allocated. For details, see Set load balancer IP timeout and pod connection delay.

    The external IP is displayed in the performance test as follows:

    External IP in the performance test

    Copy code
    Example of configuring Kubernetes with the NodePortExternalIPs access type.
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <appSettings>
        <add key="DeploymentAPIVersion" value="apps/v1"/>
        <add key="PodAPIVersion" value="v1"/>
        <add key="ServiceAPIVersion" value="v1"/>
        <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
        <add key="KubernetesAccessType" value="NodePortExternalIPs"/>
      </appSettings>
    </configuration>
  3. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Set load balancer IP timeout and pod connection delay

When using LoadBalancerIngress, you can configure the load balancer IP timeout and pod connection delay.

To set a timeout for Kubernetes to get load balancer external IPs:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Under <appsettings>, add one of the following keys.

    Key Description
    WaitForIngressIPsTimeOut

    Timeout, in minutes, for allocating all load balancer IPs (default: 5).

    This is useful where numerous Docker load generators are provisioned in the test.

    ConnectToPodDelay

    Delay, in seconds, before the Controller connects to pods (default: 15).

    We recommend increasing the value if you encounter connecting to host (Docker LGs) errors.

    Copy code
    Example of timeout for load balancer external IPs and delay connecting to pod:
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <appSettings>
        <add key="DeploymentAPIVersion" value="apps/v1"/>
        <add key="PodAPIVersion" value="v1"/>
        <add key="ServiceAPIVersion" value="v1"/>
        <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
        <add key="KubernetesAccessType" value="LoadBalancerIngress"/>
        <add key="WaitForIngressIPsTimeOut" value="5"/> <!--in minutes-->
        <add key="ConnectToPodDelay" value="15"/> <!--in seconds-->
      </appSettings>
    </configuration>
  3. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Add Kubernetes service annotations

You can use annotations to attach non-identifying metadata to Kubernetes services.

To define annotations in services:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Under <appsettings>, add a key named Annotations and enter a key and value using the following format.

    Copy code

    For a single annotation:

    <add key="Annotations" value="{'key':'value'}"/>
    Copy code

    For multiple annotations:

    <add key="Annotations" value="{'key1':'value1','key2':'value2'}"/>
    Copy code
    Example of Kubernetes service annotations:
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <appSettings>
        <add key="DeploymentAPIVersion" value="apps/v1"/>
        <add key="PodAPIVersion" value="v1"/>
        <add key="ServiceAPIVersion" value="v1"/>
        <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
        <add key="Annotations" value="{'service.beta.kubernetes.io/azure-load-balancer-internal':'true'}" />
       </appSettings>
    </configuration>
  3. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Deactivate service account auto-mount

By default, Kubernetes mounts a service account token into every pod. If API access is not required, deactivate auto‑mount for improved security. Deactivating service auto-mount hardens cluster accessibility to the API server.

To deactivate the auto-mount service account token:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Under <appsettings>, add a key named AutoMountServiceAccountToken with a value of false.

    Copy code
    Example of deactivating the service auto-mount:
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <appSettings>
        <add key="DeploymentAPIVersion" value="apps/v1"/>
        <add key="PodAPIVersion" value="v1"/>
        <add key="ServiceAPIVersion" value="v1"/>
        <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
        <add key="WaitForIngressIPsTimeOut" value="5"/> <!--in minutes-->
        <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
        <add key="AutomountServiceAccountToken" value="false"/> <!--This is used for hardening cluster accessibility to the API server.-->
        <add key="ConnectToPodDelay" value="15"/> <!--in seconds-->
      </appSettings>
    </configuration>
  3. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Enable Kubernetes health checks

Startup, liveness, and readiness probes are supported using TCP sockets for performing health checks on your Kubernetes application and container.

To enable Kubernetes health probes:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Under <appsettings>, enable the required probes listed below by changing the key value to true.

    Key Description
    EnableStartupProbe

    The Startup probe determines if the application that runs in a container has started. If it has started, Kubernetes allows other probes to start functioning. Otherwise, the kubelet shuts down and restarts the container. This is used to protect slow starting containers.

    Default values:

    • initialDelaySeconds="0"

    • periodSeconds="10"

    • timeoutSeconds="1"

    • failureThreshold="3"

    EnableLivenessProbe

    The Liveness probe determines if a container is operating. If it does not operate, the kubelet shuts down and restarts the container.

    Default values:

    • initialDelaySeconds="0"

    • periodSeconds="10"

    • timeoutSeconds="1"

    • failureThreshold="3"

    EnableReadinessProbe

    The Readiness probe determines if the application that runs in a container is ready to accept requests. If it is ready, Kubernetes allows matching services to send traffic to the pod. If it is not ready, the endpoints controller removes this pod from all matching services. If a failed pod is not restarted, the performance test fails.

    Default values:

    • initialDelaySeconds="0"

    • periodSeconds="10"

    • timeoutSeconds="1"

    • successThreshold="1"

    • failureThreshold="3"

  3. To customize probe values, uncomment the selected probes (in the section above <appsettings>), and enter values of your choice.

    Copy code
    Example of Startup probe with customized failure threshold:
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <!-- Do not modify the configSections -->
      <configSections>
        <section name="StartupProbe" type="PC.DynamicHostProvision.Common.ProbeConfig, PC.DynamicHostProvision.Common"/>
        <section name="LivenessProbe" type="PC.DynamicHostProvision.Common.ProbeConfig, PC.DynamicHostProvision.Common"/>
        <section name="ReadinessProbe" type="PC.DynamicHostProvision.Common.ProbeConfig, PC.DynamicHostProvision.Common"/>
        <section name="GlobalSecurityContext" type="PC.DynamicHostProvision.Common.SecurityContextConfig, PC.DynamicHostProvision.Common"/>
        <section name="Tolerations" type="PC.DynamicHostProvision.Common.TolerationsConfig, PC.DynamicHostProvision.Common"/>
     </configSections>

      <!-- Uncomment the sections below to apply custom values to probes -->
      <StartupProbe initialDelaySeconds="0" periodSeconds="10" timeoutSeconds="1" failureThreshold="5" />
      <!-- <LivenessProbe initialDelaySeconds="0" periodSeconds="10" timeoutSeconds="1" failureThreshold="3" /> -->
      <!-- <ReadinessProbe initialDelaySeconds="0" periodSeconds="10" timeoutSeconds="1" successThreshold="1" failureThreshold="3" /> -->

      <appSettings>
        <add key="DeploymentAPIVersion" value="apps/v1"/>
        <add key="PodAPIVersion" value="v1"/>
        <add key="ServiceAPIVersion" value="v1"/>
        <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
        <add key="WaitForIngressIPsTimeOut" value="5"/> <!--in minutes-->
        <add key="EnableStartupProbe" value="true"/>
        <add key="EnableLivenessProbe" value="false"/>
        <add key="EnableReadinessProbe" value="false"/>
        <add key="AutomountServiceAccountToken" value="true"/>
      </appSettings>
    </configuration>
  4. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Notes and limitations

The following notes and limitations are applicable when using Kubernetes health probes.

Area Description
Startup probes

Use the Startup probe settings with caution because they can cause permanent test run failure. In most cases, set the initialDelaySeconds value to 60 seconds for the Startup probe. You do not need the following key if the Startup probe is used.

<add key=" ConnectToPodDelay" value="5"/> <!--in seconds-->

Liveness and Readiness probes
  • These probes should only be used in cases where the cluster policy requires that probes are configured and without them the user cannot run a performance test.

  • These probes do not recover Vusers during a performance test. As a result, we recommend using the Startup probe, and adding about a 60 second delay, to avoid cases where the remote agent service has not started yet. Otherwise the test will fail.

Liveness probe and EKS

Avoid using only the Liveness probe, because this may cause permanent failure in EKS.

Copy code
Example of Liveness probe enabled:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <!-- Do not modify the configSections -->
  <configSections>
    <section name="StartupProbe" type="PC.DynamicHostProvision.Common.ProbeConfig, PC.DynamicHostProvision.Common"/>
    <section name="LivenessProbe" type="PC.DynamicHostProvision.Common.ProbeConfig, PC.DynamicHostProvision.Common"/>
    <section name="ReadinessProbe" type="PC.DynamicHostProvision.Common.ProbeConfig, PC.DynamicHostProvision.Common"/>
    <section name="GlobalSecurityContext" type="PC.DynamicHostProvision.Common.SecurityContextConfig, PC.DynamicHostProvision.Common"/>
    <section name="Tolerations" type="PC.DynamicHostProvision.Common.TolerationsConfig, PC.DynamicHostProvision.Common"/>
 </configSections>

  <!-- Uncomment sections to apply custom values to probes -->
  <!-- <StartupProbe initialDelaySeconds="60" periodSeconds="10" timeoutSeconds="1" failureThreshold="3" /> -->
  <LivenessProbe initialDelaySeconds="120" periodSeconds="10" timeoutSeconds="10" failureThreshold="2" />
  <!-- <ReadinessProbe initialDelaySeconds="0" periodSeconds="10" timeoutSeconds="300" successThreshold="1" failureThreshold="3" /> -->

  <appSettings>
    <add key="DeploymentAPIVersion" value="apps/v1"/>
    <add key="PodAPIVersion" value="v1"/>
    <add key="ServiceAPIVersion" value="v1"/>
    <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
    <add key="WaitForIngressIPsTimeOut" value="5"/> <!--in minutes-->
    <add key="KubernetesAccessType" value="LoadBalancerIngress"/>
    <add key="Annotations" value="{'service.beta.kubernetes.io/aws-load-balancer-internal':'true'}"/>
    <!-- <add key=" ConnectToPodDelay" value="120"/> --> 
    <add key="EnableStartupProbe" value="false"/>
    <add key="EnableLivenessProbe" value="true"/>
    <add key="EnableReadinessProbe" value="false"/>
  </appSettings>
</configuration>

Deactivate TLS verification

By default, all requests sent to a Kubernetes cluster require a CA certificate and a TLS handshake. Otherwise, the request from OpenText Enterprise Performance Engineering to Kubernetes fails. You can deactivate TLS certificate verification in the Kubernetes configuration file.

Note: For security reasons, we do not recommend deactivating TLS verification.

To deactivate TLS verification for requests sent to a Kubernetes cluster:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Under <appsettings>, add a key named EnableSslCertificateVerification with a value of false.

    Copy code
    Example of deactivating TLS verification:
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <appSettings>
        <add key="DeploymentAPIVersion" value="apps/v1"/>
        <add key="PodAPIVersion" value="v1"/>
        <add key="ServiceAPIVersion" value="v1"/>
        <add key="CreateDeploymentTimeout" value="10"/> <!--in seconds-->
        <add key="EnableSslCertificateVerification" value="false"/>
       </appSettings>
    </configuration>
  3. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Configure pod and container security settings

You can control security permissions for a specific container or pod using Kubernetes SecurityContext.

You can specify the user ID, Group ID, and fsGroup, to provide the security permissions .

To define user permissions for a container or pod:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Uncomment the GlobalSecurityContext section, and enter a value for the runAsUser field, or use the default user ID (1000). All processes in the container run with the specified user ID.

    Note:  

    • Applies to Linux containers only.

    • If runAsGroup is set, you must also set runAsUser.

  3. (Optional) Specify runAsGroup and fsGroup as needed. In version 26.3 and later, when using PVCs with fsGroup, set fsGroupChangePolicy to avoid recursive permission updates on every mount.

  4. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Pod and container security settings (available in version 26.3)

The integration with Kubernetes supports additional pod and container SecurityContext fields, summarized below.

Field name

Level

Description
fsGroupChangePolicy Pod

Controls when Kubernetes changes ownership and permissions for volume content when fsGroup is set.

Possible values: OnRootMismatch, Always

Use OnRootMismatch with PVCs to avoid recursive ownership updates across the entire volume on each mount.

allowPrivilegeEscalation Container

Controls whether the container runs in privileged mode.

Possible values: true, false

privileged Container

Runs the container in privileged mode.

Possible values: true, false

seccompProfile Container / Pod

Specifies the seccomp profile applied to the container.

Possible values: RuntimeDefault, Unconfined, Localhost

Note: For the Localhost option, a localhostProfile must be specified.

Example:

<seccompProfile type="Localhost" localhostProfile="profiles/test-profile.json" />

In this example, the file must exist at:

/var/lib/kubelet/seccomp/profiles/ test-profile.json

capabilities.add Container

Linux capabilities explicitly added.

Possible values: Kubernetes‑supported capabilities such as ['SETUID','SETGID']

capabilities.drop Container

Linux capabilities explicitly removed.

Possible values: ['ALL']

Note:  

  • These fields are interdependent and should be configured carefully.

  • For seccompProfile of type Localhost, the referenced JSON file must exist on each Kubernetes node under:

    /var/lib/kubelet/seccomp/

  • readOnlyRootFilesystem is always set to false and is not configurable.

Copy code
Example of GlobalSecurityContext configuration using security context fields.
<GlobalSecurityContext>
    runAsUser="1001"
    runAsGroup="1001"
    runAsNonRoot="true"
    fsGroup=""
    allowPrivilegeEscalation="false"
    privileged="false">
    <seccompProfile type="RuntimeDefault" localhostProfile="" />
    <capabilities add="" drop="['ALL']" />
</GlobalSecurityContext>

Configure taint and toleration

Use tolerations to allow pods to be scheduled on tainted nodes.

To set taints and tolerations in Kubernetes (not related to OS node type):

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Uncomment the <Tolerations> section.

  3. Specify values for key, operator, and value. If required, include a value for SecurityContext.

    Copy code
    Example of tolerations:
    <Tolerations>
    <Entries>
    <add key="ssd" operator="" value="true" effect="NoSchedule" tolerationSeconds="" />
    <add key="" operator="" value="" effect="" tolerationSeconds="" />
    </Entries>
    </Tolerations>
  4. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

Note: Make sure that you set a matching taint under your node pool.

Configure persistent storage with PVCs

Available in versions: 26.3 and later

Use PersistentVolumeClaims (PVCs) to integrate Kubernetes persistent storage with load generator pods in supported on-premises Kubernetes, AKS, and EKS environments.

Persistent volume support is available for Linux and Windows load generators.

Note:  

  • PVCs are configured at the Kubernetes level, not at the physical storage level.

  • Storage backends and provisioning methods differ by environment. This configuration does not create directories on the storage backend; use subPath in your storage class if required.

  • Cloud platforms usually provision PersistentVolumes dynamically; on-premises environments may use static or dynamic provisioning. You manage the data lifecycle, while Kubernetes handles PersistentVolume selection and provisioning.

  • When using fsGroup in GlobalSecurityContext, set fsGroupChangePolicy to OnRootMismatch to avoid recursive permission updates.

  • Multiple PVCs are supported, provided each claim is correctly defined and mounted with a unique mount path.

You control which PVC is mounted, where it is mounted (mountPath), and whether the pod can write to it (readOnly).

The integration flow is: Pod -> PersistentVolumeClaim -> PersistentVolume -> Storage backend.

To enable persistent volumes in Kubernetes integration:

  1. Open kubernetes.config in the <Server_installdir>\dat folder.

  2. Uncomment the <PersistentVolumes> section.

    Copy code
    <PersistentVolumes>
      <Entries>
        <add name="<logical name>"
             claimName="<PersistentVolumeClaim name>"
             mountPath="<path inside the container>"
             readOnly="true|false" />
      </Entries>
    </PersistentVolumes>
  3. Set values for the following attributes.

    Attribute Description
    name Enter any logical name. A name that references the PVC helps identify the mount.
    claimName

    Enter your PVC name.

    mountPath

    Enter the path inside the container, for example /mnt/nas.

    readOnly

    Optional. Set to true or false.

  4. Restart IIS after updating kubernetes.config for changes to take effect. Run iisreset in a command line.

For details on running Windows Docker images in your cluster, see Run Windows Docker images.

Limitations

If the following error occurs:

container has runAsNonRoot and image has non-numeric user (lr_user);
cannot verify user is non-root

Cause:

The container image uses a named user instead of a numeric UID. When runAsNonRoot=true is set, Kubernetes cannot verify that the user is not root.

Resolution:

  • Use an image with a numeric user ID, or

  • Set runAsNonRoot="false" in GlobalSecurityContext.

See also