App Connect Integration Runtime reference

Content server

When you use the App Connect Dashboard to upload or import BAR files for deployment to integration servers or integration runtimes, the BAR files are stored in a content server that is associated with the Dashboard instance. The content server is created as a container in the Dashboard deployment and can either store uploaded (or imported) BAR files in a volume in the container’s file system, or store them within a bucket in a simple storage service that provides object storage through a web interface.

The location of a BAR file in the content server is generated as a BAR URL when a BAR file is uploaded or imported to the Dashboard. This location is specified by using the Bar URL field or spec.barURL parameter in the Dashboard custom resource (CR).

While creating an integration server or integration runtime, you can choose only one BAR file to deploy from the content server and must reference its BAR URL in the content server. The integration server or runtime then uses this BAR URL to download the BAR file on startup, and processes the applications appropriately.

If you are creating an integration server or integration runtime from the Dashboard, and use the Integrations view to specify a single BAR file to deploy, the location of this file in the content server will be automatically set in the Bar URL field or spec.barURL parameter in the Properties (or Server) view. For more information, see Creating an integration server to run your BAR file resources (for Designer integrations), Creating an integration server to run IBM App Connect Enterprise Toolkit integrations, and Creating an integration runtime to run your BAR file resources.

If you are creating an integration server or integration runtime from the Red Hat OpenShift web console or CLI, or the Kubernetes CLI, and want to deploy a BAR file from the content server, you must obtain the BAR file location from the BAR files page (which presents a view of the content server) in the Dashboard. You can do so by using Display BAR URL in the BAR file's options menu to view and copy the supplied URL. You can then paste this value in spec.barURL in the integration server or integration runtime custom resource (CR). For more information, see Integration Server reference: Creating an instance and Integration Runtime reference: Creating an instance.

The location of a BAR file in the content server is typically generated in the following format:

• Integration server:

  https://dashboardName-dash:3443/path?token

• Integration runtime:

  https://dashboardName-dash.namespaceName:3443/path?token

For example:

https://mydashboardname-dash:3443/v1/directories/CustomerDbV1?0a892497-ea3b-4961-aefb-bc0c36479678

https://mydashboardname-dash.ace-test:3443/v1/directories/CustomerDatabaseV1?9b7aa053-656d-4a30-a31c-123a45f8ebfd

1

External repository

(Applicable only if spec.version resolves to 12.0.1.0-r1 or later)

While creating an integration server or integration runtime, you can choose to deploy multiple BAR files, which are stored in an external HTTPS repository system, to the integration server or integration runtime. You might find this option useful if you have set up continuous integration and continuous delivery (CI/CD) pipelines to automate and manage your DevOps processes, and are building and storing BAR files in a repository system such as JFrog Artifactory.

This option enables you to directly reference one or more BAR files in your integration server or integration runtime CR without the need to manually upload or import the BAR files to the content server in the App Connect Dashboard or build a custom image. You will need to provide basic (or alternative) authentication credentials for connecting to the external endpoint where the BAR files are stored, and can do so by creating a configuration object of type BarAuth. When you create your integration server or integration runtime, you must then reference this configuration object.

Some considerations apply if deploying multiple BAR files:

• Ensure that all of the applications can coexist (with no names that clash).
• Ensure that you provide all of the configurations that are needed for all of the BAR files.
• All of the BAR files must be accessible by using the single set of credentials that are specified in the configuration object of type BarAuth.

Multiple

Custom image

You can build a custom server runtime image that contains all the configuration for the integration server or integration runtime, including all the BAR files or applications that are required, and then use this image to deploy an integration server or integration runtime.

For example:

image-registry.openshift-image-registry.svc:5000/imageName

This image must be built from the version that is specified as the spec.version value in the CR. Channels are not supported when custom images are used.

Multiple

apiVersion

The API version that identifies which schema is used for this integration runtime.

appconnect.ibm.com/v1beta1

kind

The resource type.

IntegrationRuntime

metadata.name

A unique short name by which the integration runtime can be identified.

metadata.namespace

The namespace (project) in which the integration runtime is deployed.

The namespace in which you create an instance or object must be no more than 40 characters in length.

spec.barURL

Identifies the location of one or more BAR files that can be deployed to the integration runtime. Can be either of these values:

• The URL of the location where a (single) BAR file is stored in the content server of the App Connect Dashboard; for example:

  https://mydashboardname-dash.ace-test:3443/v1/directories/CustomerDatabaseV1?9b7aa053-656d-4a30-a31c-123a45f8ebfd

  This URL is generated when a BAR file is uploaded to the App Connect Dashboard while deploying an integration runtime or imported from the BAR files page. If you want to use a previously uploaded (or imported) BAR file to deploy an integration runtime, you can display the URL in the Dashboard as described in Managing BAR files, and then set this URL as the value of spec.barURL.

• One or more co-related BAR files in an external repository such as Artifactory. Specify the URL to each file including the file name; for example:

  https://artifactory.com/myrepo/getHostnameAPI.bar

  https://artifactory.com/myrepo/CustomerDatabaseV1.bar

  Tip: If you are using GitHub as an external repository, you must specify the raw URL.

  The BAR files that you specify must all be accessible by using the same authentication credentials; for example, basic authentication or no authentication. You must define these credentials by creating a configuration of type BarAuth and then add the configuration name to spec.configurations. For information about the supported authentication credentials and details of how to create this configuration object, see BarAuth type (or BarAuth type if using the Dashboard) and Configuration reference.

If you want to use a custom server runtime image to deploy an integration runtime, use spec.template.spec.containers.image to specify this image.

spec.configurations[]

An array of existing configurations that you want to apply to one or more BAR files being deployed. These configurations must be in the same namespace as the integration runtime. To specify a configuration, use the metadata.name value that was specified while creating that configuration.

For information about creating configurations, see Configuration reference. To see examples of how to specify one or more values for spec.configurations, see Creating an instance from the Red Hat OpenShift web console and Creating an instance from the Red Hat OpenShift or Kubernetes CLI.

spec.dashboardUsers.bypassGenerate

Indicates whether to bypass the generation of users when not using the App Connect Dashboard.

Valid values are true and false.

• Set this value to false if you want to use the Dashboard to deploy BAR files from the content server or an external repository, and want to ensure that web users (user IDs) are created on the integration runtime to allow the Dashboard to connect to it with the appropriate permissions. (Automatically creates web users with admin permissions, read-only permissions, and no access, and generates a secret named integrationRuntimeName-ir to store data about these web users.)
• Set this value to true if you want to bypass the generation of users because you intend to deploy BAR files from an external repository without using the Dashboard.

spec.defaultAppName

A name for the default application for the deployment of independent resources.

DefaultApplication

spec.defaultNetworkPolicy.enabled

(Only applicable if spec.version resolves to 12.0.7.0-r2 or later)

Indicate whether to enable the creation of a default network policy that restricts traffic to the integration runtime pods.

Valid values are true and false.

• Defaults to true, which automatically creates a default network policy.
• Set this value to false to disable the creation of a default network policy so that you can create a custom network policy that defines which connections are allowed.

For more information, see About network policy in the Red Hat OpenShift documentation, or Network Policies in the Kubernetes documentation.

true

spec.desiredRunState

(Only applicable if spec.version resolves to 13.0.2.2-r1 or later)

Specify whether to stop or start the integration runtime. The stop or start action is applied to all replica pods that are provisioned for the integration runtime to ensure that a consistent state is maintained across the pods.

If you omit this parameter or leave its value blank, a default value of running is assumed.

You can also stop or start the integration runtime from its tile on the Runtimes page in your App Connect Dashboard instance. For more information, see Stopping and starting a deployed integration runtime.

running

spec.flowType.designerAPIFlow

Indicate whether to enable the runtime for API flows that are authored in App Connect Designer.

Valid values are true and false.

false

spec.flowType.designerEventFlow

Indicate whether to enable the runtime for event-driven flows that are authored in App Connect Designer.

Valid values are true and false.

false

spec.flowType.toolkitFlow

Indicate whether to enable the runtime for flows that are built in the IBM App Connect Enterprise Toolkit.

Valid values are true and false.

false

spec.forceFlowBasicAuth.enabled

Indicate whether to enable basic authentication on all HTTP input flows.

Valid values are true and false.

false

spec.forceFlowBasicAuth.secretName

Specify the name of a manually created secret that stores the basic authentication credentials (that is, a username and password) to use on all HTTP input flows. Alternatively, omit this setting to use an automatically generated secret. This secret is required if spec.forceFlowBasicAuth.enabled is set to true.

If you do not specify a value, a secret named integrationRuntimeName-ingress-basic-auth is automatically generated, where integrationRuntimeName is the metadata.name value of the integration runtime.

If you want to provide your own secret, you must create it in the namespace where the integration runtime will be deployed. You can do so from the Red Hat OpenShift web console, or from the Red Hat OpenShift or Kubernetes CLI.

• You can use the following Secret (YAML) resource to create the secret from the web console (by using the Import YAML icon ) or from the CLI (by running oc apply -f resourceBAuthFile.yaml or kubectl apply -f resourceBAuthFile.yaml).

  apiVersion: v1
  kind: Secret
  metadata:
    name: secretName
    namespace: namespaceName
  data:
    configuration: Base64-encoded_basicAuthCredentials
  type: Opaque

  To obtain the value of Base64-encoded_basicAuthCredentials, you can use (operating system-specific) commands such as base64, echo, or certutil to Base64 encode the username and password in a file or string. For example, run the following command on Linux to directly Base64-encocde the username and password from the command line:

  echo -n 'local::basicAuthOverride basicAuth_username basicAuth_password' | base64

• Alternatively, create the secret by running the following command from the required namespace:
  

  oc create secret generic secretName --from-literal=configuration=Base64-encoded_basicAuthCredentials

  

  kubectl create secret generic secretName --from-literal=configuration=Base64-encoded_basicAuthCredentials

spec.forceFlowsHTTPS.enabled

Indicate whether to force all HTTP Input nodes and SOAP Input nodes in all deployed flows (including their usage for inbound connections to applications, REST APIs, and integration services) in the integration runtime to use Transport Layer Security (TLS).

Valid values are true and false.

When spec.forceFlowsHTTPS.enabled is set to true, you must also ensure that spec.restApiHTTPS.enabled is set to true.

false

spec.forceFlowsHTTPS.secretName

Specify the name of a secret that stores a user-supplied public certificate/private key pair to use for enforcing TLS. (You can use tools such as keytool or OpenSSL to generate the certificate and key if required, but do not need to apply password protection.)

This secret is required if spec.forceFlowsHTTPS.enabled is set to true.

You must create the secret in the namespace where the integration runtime will be deployed, and can do so from the Red Hat OpenShift web console, or from the Red Hat OpenShift or Kubernetes CLI. Use your preferred method to create the secret. For example, you can use the following Secret (YAML) resource to create the secret from the web console (by using the Import YAML icon ) or from the CLI (by running oc apply -f resourceFile.yaml or kubectl apply -f resourceFile.yaml):

apiVersion: v1
kind: Secret
metadata:
  name: secretName
  namespace: namespaceName
data:
  tls.crt: "base64Encoded_crt_publicCertificate"
  tls.key: "base64Encoded_key_privateKey"
type: kubernetes.io/tls

Or you can create the secret by running the following command from the required namespace:

oc create secret tls secretName --key filename.key --cert filename.crt

kubectl create secret tls secretName --key filename.key --cert filename.crt

spec.ingress.enabled

(Only applicable in an IBM Cloud Kubernetes Service environment and if spec.version resolves to 13.0.2.1-r1 or later)

Indicate whether to automatically create ingress resources for your deployed integration runtime. In Kubernetes environments, ingress resources are required to expose your integration runtimes to external traffic.

Valid values are true and false.

• To automatically create ingress resources for the integration runtime in your IBM Cloud Kubernetes Service environment, set spec.ingress.enabled to true. Also ensure that spec.license.use is set to an AppConnectEnterprise* style license.

  For more information, see Automatically creating ingress definitions for IBM App Connect instances in an IBM Cloud Kubernetes Service cluster.

• To manually create ingress resources for the integration runtime, set spec.ingress.enabled to false (the default). Specify this setting if you are working in a Kubernetes environment other than IBM Cloud Kubernetes Service. You will need to manually create the ingress resources after the integration runtime is created. For more information, see Manually creating ingress definitions for external access to your IBM App Connect instances in Kubernetes environments.

false

spec.ingress.domain

(Only applicable in an IBM Cloud Kubernetes Service environment and if spec.version resolves to 13.0.2.1-r1 or later)

If you do not want the ingress routes for the integration runtime to be constructed with the IBM-provided ingress subdomain of your IBM Cloud Kubernetes Service cluster, specify a preferred custom subdomain that is created in the cluster.

This parameter is applicable only if spec.ingress.enabled is set to true.

spec.java.version

(Only applicable if spec.version resolves to 13.0.5.0-r1 or later)

Specify which Java Runtime Environment (JRE) version to use in the deployment and the runtime pods for the integration runtime.

Limitations apply to some message flow nodes and capabilities, and to some types of security configuration when certain JRE versions are used with IBM App Connect Enterprise. Use this parameter to specify a Java version that is compatible with the content of the Toolkit integration that is deployed as an integration runtime. Applications that are deployed to an integration runtime might fail to start if the Java version is incompatible.

Valid values are 8 or 17. If you do not specify a value, the default value is used.

Example:

spec:
  java:
    version: '8'

17

spec.license.accept

An indication of whether the license should be accepted.

Valid values are true and false. To install, this value must be set to true.

false

spec.license.license

See Licensing reference for IBM App Connect Operator for the valid values.

spec.license.use

See Licensing reference for IBM App Connect Operator for the valid values.

For more information about specifying this value on Kubernetes, see Using Cloud Pak for Integration licenses with integration runtimes in a Kubernetes environment.

spec.logFormat

The format used for the container logs that are output to the container's console.

Valid values are basic and json.

basic

spec.metrics.disabled

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

Indicate whether to disable the generation of message flow statistics, accounting data, and resource statistics for the deployed integration.

Valid values are true and false.

• Set this value to true to stop the metrics from being generated by default for the deployed integration.
• Set this value to false to enable the generation of these metrics for the deployed integration in the Dashboard UI. When enabled, you can view the metrics at a pod-specific level as described in Viewing detailed information about a deployed integration runtime.

If you are working in a Kubernetes environment, ensure that spec.metrics.disabled is set to true because metrics are not provided out of the box on Kubernetes environments.

false

spec.nodePortService.ports[].name

(Only applicable if spec.version resolves to 13.0.3.0-r1 or later)

The name of a port definition on a dedicated NodePort service that is created to expose the integration runtime pods to external (as well as internal) traffic. The name must contain only lowercase alphanumeric characters and a hyphen (-), and begin and end with an alphanumeric character.

If you need to expose more than one port for the NodePort service, you can use the collection of spec.nodePortService.ports[].* parameters to configure multiple port definitions as an array.

When you specify the set of spec.nodePortService.ports[].* parameters, the IBM App Connect Operator automatically creates a Kubernetes service with the defined ports and with a virtual IP address for access. The NodePort service is created in the same namespace as the integration runtime and is named in the format integrationRuntimeName-np-ir. For example, if the metadata.name value for the integration runtime is ir-toolkit, the NodePort service is named ir-toolkit-np-ir.

The following example shows the set of fields in a port definition:

spec:
  nodePortService:
    ports:
      - name: port-tcp
        protocol: TCP
        port: 9910
        nodePort: 32000
        targetPort: 9910

spec.nodePortService.ports[].nodePort

(Only applicable if spec.version resolves to 13.0.3.0-r1 or later)

The port on which each node in the cluster listens for incoming requests for the NodePort service. The incoming traffic is routed to the corresponding pods.

The port number must be in the range 30000 to 32767.

Ensure that this port is not being used by another service. You can check which node ports are already in use by running the following command and then checking under the PORT(S) column in the output:

oc get svc -n namespaceName

kubectl get svc -n namespaceName

You can either specify a specific port number, or omit spec.nodePortService.ports[].nodePort to automatically assign an available port in the 30000-32767 range. To find the port that is automatically assigned, run the oc describe service or kubectl describe service command (as shown in the following example), or run the oc get service or kubectl get service command, where integrationRuntimeName-np-ir is the name of the NodePort service.

oc describe service integrationRuntimeName-np-ir

kubectl describe service integrationRuntimeName-np-ir

status:
  nodePortService:
    ports:
      - name: tcpip-server
        protocol: TCP
        port: 9910
        nodePort: 30001

spec.nodePortService.ports[].port

(Only applicable if spec.version resolves to 13.0.3.0-r1 or later)

The port that exposes the NodePort service to pods within the cluster.

spec.nodePortService.ports[].protocol

(Only applicable if spec.version resolves to 13.0.3.0-r1 or later)

The protocol of the port. Valid values are TCP, SCTP, and UDP.

spec.nodePortService.ports[].targetPort

(Only applicable if spec.version resolves to 13.0.3.0-r1 or later)

The port on which the pods listen for connections from the NodePort service.

The port number must be in the range 1 to 65535.

spec.replicas

The number of replica pods to run for each deployment.

Increasing the number of replicas will proportionally increase the resource requirements.

1

spec.restApiHTTPS.enabled

Indicate whether to enable HTTPS-based REST API flows, which in turn ensures that the correct endpoint is configured for the deployed integration.

Valid values are true and false.

• Set the value to true to indicate that you are using HTTPS-based REST API flows (with TLS configured). You must have configured all HTTP Input nodes and SOAP Input nodes in all flows in the integration to use TLS either by setting spec.forceFlowsHTTPS.enabled to true or by using mechanisms such as the server.conf.yaml file while developing the flows in IBM App Connect Enterprise. When set to true (with the prerequisite configuration), the endpoint for the deployed integration is secured with https. The true setting uses port 7843 by default.
• Set the value to false if you are not using HTTPS-based REST API flows. When set to false, the endpoint is configured as http. The false setting uses port 7800 by default.

If using a Kubernetes environment other than IBM Cloud Kubernetes Service, this setting is ignored. Instead, the protocol that is defined in the ingress definition for this integration runtime, which you will need to create later, will be used. For more information, see Manually creating ingress definitions for external access to your IBM App Connect instances in Kubernetes environments. In an IBM Cloud Kubernetes Service cluster, this setting is applicable only for a 13.0.2.1-r1 or later integration runtime if Ingress/Enabled is set to true to automatically create ingress resources for the deployed integration runtime. For more information, see Automatically creating ingress definitions for external access to your IBM App Connect instances on IBM Cloud Kubernetes Service.

false

spec.routes.disabled

Indicate whether to disable the automatic creation of HTTP and HTTPS OpenShift routes, which externally expose a service that identifies the set of integration runtime pods.

Valid values are true and false.

• Set the value to false (the default) to enable the automatic creation of routes.
• Set the value to true to disable the automatic creation of routes.

false

spec.routes.domain

An alias or DNS that can optionally be used to point to the endpoint for HTTPS flows in the integration runtime. This value must conform to the DNS 952 subdomain conventions. If unspecified, a hostname is automatically generated for the HTTPS route.

The path is constructed as follows, where CRname is the metadata.name value, CRnamespace is the metadata.namespace value, and specRoutesDomainValue is the spec.routes.domain value:

CRname-https-CRnamespace.specRoutesDomainValue

After a route is created, the spec.routes.domain setting cannot be changed.

spec.routes.metadata.annotations

Specify one or more custom annotations (as arbitrary metadata) to apply to the routes that are created during deployment. Specify each annotation as a name/value pair in the format key: value. For example:

spec:
  routes:
    metadata:
      annotations:
        key1: value1
        key2: value2

spec.routes.timeout

The timeout value (in seconds) on the OpenShift routes.

spec.serverless.knativeService.enabled

Indicate whether to enable Knative service to provide support for serverless deployments.

Valid values are true and false. Set this value to true to enable a serverless Knative service deployment.

false

spec.serverless.knativeService.imagePullSecrets.name

The name of a secret that contains the credentials for pulling images from the registry where they are stored.

For more information, see Deploying images from a private container registry.

spec.serverless.knativeService.template.spec.containerConcurrency

The maximum number of concurrent requests that are allowed per container of the revision. The default of 0 (zero) indicates that concurrency to the application is not limited, and the system decides the target concurrency for the autoscaler.

0

spec.serverless.knativeService.template.spec.containers.image

The path for the image to run in this container, including the tag.

spec.serverless.knativeService.template.spec.containers.imagePullPolicy

Indicate whether you want images to be pulled every time, never, or only if they're not present.

Valid values are Always, Never, and IfNotPresent.

IfNotPresent

spec.serverless.knativeService.template.spec.containers.name

The name of the container to be configured.

spec.serverless.knativeService.template.spec.priority

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Pod priority settings control which pods get killed, rescheduled, or started to allow the most important pods to keep running.

spec.serverless.knativeService.template.spec.priority specifies an integer value, which various system components use to identify the priority of the (serverless) integration runtime pod. The higher the value, the higher the priority.

If the priority admission controller is enabled, you cannot manually specify a priority value because the admission controller automatically uses the spec.serverless.knativeService.template.spec.priorityClassName setting to populate this field with a resolved value.

spec.serverless.knativeService.template.spec.priorityClassName

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

A priority class name that maps to the integer value of a pod priority in spec.serverless.knativeService.template.spec.priority. If specified, this class name indicates the pod's priority (or importance) relative to other pods.

Valid values are as follows:

• Specify either of these built-in Kubernetes classes, which mark a pod as critical and indicate the highest priorities: system-node-critical or system-cluster-critical. system-node-critical is the highest available priority.
• To specify any other priority class, create a PriorityClass object with that class name. For more information, see Pod Priority and Preemption in the Kubernetes documentation.

If you do not specify a class name, the priority is set as follows:

• The class name of an identified PriorityClass object, which has its globalDefault field set to true, is assigned.
• If there is no PriorityClass object with a globalDefault setting of true, the priority of the pod is set to 0 (zero).

spec.serverless.knativeService.template.spec.timeoutSeconds

The maximum duration in seconds that the request routing layer will wait for a request delivered to a container to begin replying (send network traffic). If unspecified, a system default will be provided.

spec.serverless.knativeService.template.spec.tolerations[].effect

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

To prevent pods from being scheduled onto inappropriate nodes, use taints together with tolerations. Tolerations allow scheduling, but don't guarantee scheduling because the scheduler also evaluates other parameters as part of its function. Apply one or more taints to a node (by running oc taint or kubectl taint with a key, value, and taint effect) to indicate that the node should repel any pods that do not tolerate the taints. Then, apply toleration settings (effect, key, operator, toleration period, and value) to a pod to allow it to be scheduled on the node if the pod's toleration matches the node's taint. For more information, see Taints and Tolerations in the Kubernetes documentation.

If you need to specify one or more tolerations for a serverless integration runtime pod, you can use the collection of spec.serverless.knativeService.template.spec.tolerations[].* parameters to define an array.

For spec.serverless.knativeService.template.spec.tolerations[].effect, specify the taint effect that the toleration should match. (The taint effect on a node determines how that node reacts to a pod that is not configured with appropriate tolerations.) Leave the effect empty to match all taint effects. Alternatively, specify one of these values: NoSchedule, PreferNoSchedule, or NoExecute.

spec.serverless.knativeService.template.spec.tolerations[].key

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Specify the taint key that the toleration applies to. Leave the key empty and set spec.serverless.knativeService.template.spec.tolerations[].operator to Exists to match all taint keys, values, and effects.

spec.serverless.knativeService.template.spec.tolerations[].operator

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Specify an operator that represents a key's relationship to the value in spec.serverless.knativeService.template.spec.tolerations[].value. Valid operators are Exists and Equal. Exists is equivalent to a wildcard for the toleration value, and indicates that the pod can tolerate all taints of a particular category.

Equal

spec.serverless.knativeService.template.spec.tolerations[].tolerationSeconds

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Optionally specify a period of time in seconds that determines how long the pod stays bound to a node with a matching taint before being evicted. Applicable only for a toleration with a NoExecute effect (which indicates that a pod without the appropriate toleration should immediately be evicted from the node).

By default, no value is set, which means that a pod that tolerates the taint will never be evicted. Zero and negative values are treated as 0 (evict immediately).

spec.serverless.knativeService.template.spec.tolerations[].value

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Specify the taint value that the toleration matches to. If the operator is Exists, leave this value empty.

spec.service.ports[].name

The name of a port definition on the service (defined by spec.service.type), which is created for accessing the set of pods. The name must contain only lowercase alphanumeric characters and a hyphen (-), and begin and end with an alphanumeric character.

If you need to expose more than one port for the service, you can use the collection of spec.service.ports[].* parameters to configure multiple port definitions as an array.

spec.service.ports[].nodePort

The port on which each node listens for incoming requests for the service. Applicable when spec.service.type is set to NodePort to expose the service externally.

The port number must be in the range 30000 to 32767.

Ensure that this port is not being used by another service. You can check which node ports are already in use by running the following command and then checking under the PORT(S) column in the output:

oc get svc -n namespaceName

kubectl get svc -n namespaceName

spec.service.ports[].port

The port that exposes the service to pods within the cluster.

spec.service.ports[].protocol

The protocol of the port. Valid values are TCP, SCTP, and UDP.

spec.service.ports[].targetPort

The port on which the pods will listen for connections from the service.

The port number must be in the range 1 to 65535.

spec.service.type

The type of service to create for accessing the set of pods:

• ClusterIP: Specify this value to expose the service internally, for access by applications inside the cluster. This value is the default.
• NodePort: Specify this value to expose the service at a static port (specified by using spec.service.ports[].nodePort), for external traffic. If you want to use NodePort, you must work with your cluster administrator to configure external access to the cluster. For more information, see Configuring ingress cluster traffic using a NodePort in the OpenShift documentation.

  The following example shows a custom port definition for external traffic:

  spec:
    service:
      ports:
        - name: config-abc
          nodePort: 32000
          port: 9910
          protocol: TCP
          targetPort: 9920
      type: NodePort

  Note:

  When you set the service type to NodePort, the existing default ports of 7800, 7843, and 7600 (which are used for the http and https transports, and the administration REST API) are automatically assigned NodePort values on the service. If you try to manually specify node ports for these default ports by adding a spec.service.ports[].* array in the integration runtime CR, you will obtain an error. To set node ports for the default ports, all you need to do is set spec.service.type to NodePort and then omit the spec.service.ports[].* section, as shown in the following example.

  spec:
    service:
      type: NodePort

  To identify the NodePort values that are automatically assigned to the default ports, you can run the oc describe service or kubectl describe service command, or the oc get service or kubectl get service command. In the following example, integrationRuntimeName-ir represents the service name, where integrationRuntimeName is the metadata.name value for the integration runtime.

  

  oc describe service integrationRuntimeName-ir

  

  kubectl describe service integrationRuntimeName-ir

ClusterIP

spec.startupResources.*

(Only applicable if spec.version resolves to 13.0.5.1-r1 or later)

Specify CPU resources for the startup phase of the integration runtime to optimize container startup performance without increasing licensing costs. This feature allows you to allocate higher CPU resources during the container startup phase and then dynamically reduce them to lower values for the running (licensed) phase. For example, you might want to improve the initialization time for an integration runtime that contains a large number of flows. During startup, the IBM License Service does not count the container as running, so no VPC usage occurs until the pod is fully ready.

You can specify the following parameters:

• spec.startupResources.limits.cpu: The upper limit of CPU cores that are allocated for the startup phase. Specify an integer, a fractional (for example, 0.5), or a millicore value (for example, 100m, equivalent to 0.1 core).
• spec.startupResources.requests.cpu: The minimum number of CPU cores that are allocated for the startup phase. Specify an integer, a fractional (for example, 0.5), or a millicore value (for example, 100m, equivalent to 0.1 core).

The following example allocates 2000m CPU during container creation. After the App Connect processes are initialized, the IBM App Connect Operator automatically scales down the pod to the default or custom CPU values that are specified in spec.template.spec.containers[].resources.limits.cpu and spec.template.spec.containers[].resources.requests.cpu for the runtime container.

spec:
  startupResources:
    limits:
      cpu: 2000m
    requests:
      cpu: 2000m

For more information, see Dynamic CPU Allocation for Faster Startup in IntegrationRuntimes.

spec.strategy.type

The update strategy for replacing old pods on always-on deployments:

• Recreate: Specify this value to terminate all of the existing pods before creating new ones.
• RollingUpdate: Specify this value to allow your deployment's pod template to be updated with no downtime by incrementally replacing the pods with new ones. This value is the default.

RollingUpdate

spec.telemetry.tracing.openTelemetry.enabled

Indicate whether to enable OpenTelemetry tracing for all message flows in a Toolkit integration that you want to deploy to the integration runtime.

Valid values are true and false.

false

spec.telemetry.tracing.openTelemetry.endpoint

An endpoint of the OpenTelemetry agent that will receive the OpenTelemetry span data. The default is status.hostIP:4317, where status.hostIP represents the primary IP address of the node that the pod is assigned to.

• For grpc, you can specify a preferred endpoint to export the OpenTelemetry span data to by using the format host_or_IPaddress:port; for example, 192.0.2.0:4317 or telemetryagent.host.com:4317.
• For http/json, you can specify an HTTP/JSON URL to export the OpenTelemetry span data to; for example, http://hostname:port/v1/traces or http://localhost:4318.

status.hostIP:4317

spec.telemetry.tracing.openTelemetry.protocol

An OpenTelemetry Protocol (OTLP) to use to send data to your Observability system:

• grpc: Choose this option for protobuf-encoded data using gRPC Remote Procedure Call (gRPC) wire format over an HTTP/2 connection.
• http/json: Choose this option for JSON-encoded data over an HTTP connection.

grpc

spec.telemetry.tracing.openTelemetry.timeout

Specify a connection timeout period in seconds.

10s

spec.telemetry.tracing.openTelemetry.tls.caCertificate

For secure communication, specify the name of the secret key that contains the certificate authority (CA) public certificate.

ca.crt

spec.telemetry.tracing.openTelemetry.tls.secretName

For secure communication, specify the name of the secret that contains the certificate authority (CA) public certificate.

spec.template.spec.affinity

Specify custom affinity settings that control the placement of pods on nodes.

The default settings allow the pod to be placed on a supported platform and, where possible, spread the replicas across hosts. The default settings are as follows. Note that the labelSelector entries are automatically generated.

spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: kubernetes.io/arch
                    operator: In
                    values:
                      - amd64
                      - s390x
                      - ppc64le
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    <copy of the pod labels>
                topologyKey: kubernetes.io/hostname

You can overwrite the default settings for spec.template.spec.affinity.nodeAffinity or spec.template.spec.affinity.podAntiAffinity with custom settings.

Custom settings are supported for nodeAffinity, podAffinity, and podAntiAffinity.

For more information about spec.template.spec.affinity.nodeAffinity definitions, see Controlling pod placement on nodes using node affinity rules and Placing pods relative to other pods using affinity and anti-affinity rules in the OpenShift documentation, and Assigning Pods to Nodes in the Kubernetes documentation.

spec.template.spec.containers[].env

Define custom environment variables that you want to set for a specific App Connect container in the deployment by directly specifying a name and value for each environment variable. For example, you can set a container's timezone by declaring a TZ environment variable with a value that is set to a valid TZ identifier (such as Africa/Abidjan).

The spec.template.spec.containers[].env parameter exposes the Kubernetes API for declaring environment variables in the container, and as such follows the same schema. For any named container, you can set one or more environment variables in either of the following ways:

• Add a name/value pair for each environment variable.
• Specify an environment variable name and then inject the environment variable's value into the running container from one of these sources: a ConfigMap key, a pod-level field, a container resource (supports limits and requests), or the key of a secret in the pod's namespace. You can optionally indicate whether the ConfigMap or its key, or the secret, must be defined.

The following example specifies name/value pairs for two environment variables for the runtime container (and also includes default resource settings).

spec:
  template:
    spec:
      containers:
        - name: runtime
          env:
            - name: MY_CUSTOM_ENV_VAR
              value: 'true'
            - name: ANOTHER_ENV_VAR
              value: '100'
          resources:
            requests:
              cpu: 300m
              memory: 368Mi
          ...

The following example shows the fields that you can complete to specify a custom environment variable name for the runtime container and to inject an environment variable value from a ConfigMap key, a pod field, a container resource, or the key of a secret in the pod's namespace.

spec:
  template:
    spec:
      containers:
        - name: runtime
          env:
            - name: ENVIRONMENT_VARIABLE_NAME_01
              valueFrom:
                configMapKeyRef:
                  name: CONFIGMAP_NAME
                  key: CONFIGMAP_KEY
                  optional: true_OR_false
                fieldRef:
                  fieldPath: PATH_OF_FIELD_TO_SELECT_IN_THE_SPECIFIED_API_VERSION
                  apiVersion: VERSION_OF_SCHEMA FOR_THE_fieldPath
                resourceFieldRef:
                  containerName: CONTAINER_NAME
                  resource: CONTAINER_RESOURCE_NAME
                secretKeyRef:
                  name: SECRET_NAME
                  key: VALID_SECRET_KEY
                  optional: true_OR_false

You can also set environment variables by using the spec.template.spec.containers[].envFrom parameter.

spec.template.spec.containers[].envFrom

(Only applicable if spec.version resolves to 12.0.12.4-r1 or later)

Define custom environment variables that you want to set for a specific App Connect container in the deployment by referencing one or more ConfigMaps or secrets. All of the key/value pairs in a referenced ConfigMap or secret are set as environment variables for the named container.

The spec.template.spec.containers[].envFrom parameter exposes the Kubernetes API for declaring environment variables in the container, and as such follows the same schema. For any named container, you can set one or more environment variables by specifying an array of ConfigMaps or secrets whose environment variables you want to inject into the container. You can optionally specify a string value to prepend to each key in a ConfigMap and also indicate whether the ConfigMap or secret must be defined.

The following example shows the fields that you can complete to set environment variables for the runtime container.

spec:
  template:
    spec:
      containers:
        - name: runtime
          envFrom:
            - configMapRef:
                name: CONFIGMAP_NAME
                optional: true_OR_false
              secretRef:
                name: SECRET_NAME
                optional: true_OR_false
              prefix: CONFIGMAP_KEY_PREFIX

You can also set environment variables by using the spec.template.spec.containers[].env parameter.

spec.template.spec.containers[].name

The name of a container that is created in the pod when the integration runtime is deployed, and which you want to configure. The name that you specify must be valid for the type of integration being deployed:

• runtime

  The runtime container is deployed to provide runtime support for Toolkit integrations or Designer integrations.

• designerflows

  The designerflows container is deployed to provide support for connectors in Designer integrations and for API flows in Designer integrations.

• designereventflows
• proxy

  The designereventflows container and accompanying proxy container are deployed to provide support for event-driven flows in Designer integrations.

For each container array, you can configure your preferred custom settings for the spec.template.spec.containers[].image, spec.template.spec.containers[].imagePullPolicy, spec.template.spec.containers[].livenessProbe.*, spec.template.spec.containers[].readinessProbe.*, spec.template.spec.containers[].resources., and spec.template.spec.containers[].startupProbe.* parameters.

spec.template.spec.containers[].image

The name of the custom server image to use; for example, image-registry.openshift-image-registry.svc:5000/imageName. This image must be built from the version that is specified as the apiVersion value. Channels are not supported when custom images are used.

spec.template.spec.containers[].imagePullPolicy

Indicate whether you want images to be pulled every time, never, or only if they're not present.

Valid values are Always, Never, and IfNotPresent.

IfNotPresent

spec.template.spec.containers[].lifecycle.postStart.exec.command[]

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

An array of (one or more) commands to execute immediately after a named container is created (or started).

The working directory for the command is the root ('/') in the container's file system. The command executes without being run in a shell, which means that traditional shell instructions ('|', etc) will not work. To use a shell, explicitly call out to that shell. An exit status of 0 (zero) indicates a live or healthy status, and a non-zero value indicates an unhealthy status.

For more information, see Container Lifecycle Hooks and Attach Handlers to Container Lifecycle Events in the Kubernetes documentation.

spec.template.spec.containers[].lifecycle.postStart.httpGet.host

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

Specify the host name to connect to, to perform the HTTP request on the container pod immediately after it starts. Defaults to the pod IP. You can alternatively set Host in spec.pod.containers.runtime.lifecycle.postStart.httpGet.httpHeaders.

spec.template.spec.containers[].lifecycle.postStart.httpGet.httpHeaders

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

Specify one or more custom headers to set in the HTTP request to be performed on the container pod immediately after it starts. For each header, specify a header field name and header field value in the following format:

spec:
  template:
    spec:
      containers:
          lifecycle:
            postStart:
              httpGet:
                httpHeaders:
                  - name: headerFieldName1
                    value: headerFieldValue1
                  - name: headerFieldName2
                    value: headerFieldValue2

spec.template.spec.containers[].lifecycle.postStart.httpGet.path

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

Specify the path to access on the HTTP server when performing the HTTP request on the container pod immediately after it starts.

spec.template.spec.containers[].lifecycle.postStart.httpGet.scheme

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

Specify the scheme to use for connecting to the host when performing the HTTP request on the runtime container pod immediately after it starts.

HTTP

spec.template.spec.containers[].lifecycle.preStop.exec.command[]

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

An array of (one or more) commands to execute inside a named container before its pod is terminated.

Use the spec.template.spec.containers[].lifecycle.preStop.* settings to configure the lifecycle of the container to allow existing transactions to complete before the pod is terminated due to an API request or a management event (such as failure of a liveness or startup probe, or preemption). This allows rolling updates to occur without breaking transactions (unless they are long running). The countdown for the pod's termination grace period begins before the preStop hook is executed.

The working directory for the command is the root ('/') in the container's file system. The command executes without being run in a shell, which means that traditional shell instructions ('|', etc) will not work. To use a shell, explicitly call out to that shell. An exit status of 0 (zero) indicates a live or healthy status, and a non-zero value indicates an unhealthy status.

For example, this default preStop setting ensures that rolling updates do not result in lost messages on the runtime:

spec:
  template:
    spec:
      containers:
          lifecycle:
            preStop:
              exec:
                command:
                  - sh
                  - -c
                  - "sleep 5"

For more information, see Container Lifecycle Hooks and Attach Handlers to Container Lifecycle Events in the Kubernetes documentation.

spec.template.spec.containers[].lifecycle.preStop.httpGet.host

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

Specify the host name to connect to, to perform the HTTP request on the container pod before its termination. Defaults to the pod IP. You can alternatively set Host in spec.pod.containers.runtime.lifecycle.preStop.httpGet.httpHeaders.

spec.template.spec.containers[].lifecycle.preStop.httpGet.httpHeaders

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

Specify one or more custom headers to set in the HTTP request to be performed on the container pod before its termination. For each header, specify a header field name and header field value in the following format:

spec:
  template:
    spec:
      containers:
          lifecycle:
            preStop:
              httpGet:
                httpHeaders:
                  - name: headerFieldName1
                    value: headerFieldValue1
                  - name: headerFieldName2
                    value: headerFieldValue2

spec.template.spec.containers[].lifecycle.preStop.httpGet.path

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

Specify the path to access on the HTTP server when performing the HTTP request on the container pod before its termination.

spec.template.spec.containers[].lifecycle.preStop.httpGet.scheme

(Only applicable if spec.version resolves to 12.0.7.0-r5 or later)

Specify the scheme to use for connecting to the host when performing the HTTP request on the container pod before its termination.

HTTP

spec.template.spec.containers[].livenessProbe.failureThreshold

The number of times the liveness probe can fail before taking an action to restart the container. (The liveness probe checks whether the container is still running or needs to be restarted.)

1

spec.template.spec.containers[].livenessProbe.initialDelaySeconds

How long to wait (in seconds) before performing the first probe to check whether the container is still running. Increase this value if your system cannot start the container in the default time period.

360

spec.template.spec.containers[].livenessProbe.periodSeconds

How often (in seconds) to perform a liveness probe to check whether the container is still running.

10

spec.template.spec.containers[].livenessProbe.timeoutSeconds

How long (in seconds) before the liveness probe (which checks whether the container is still running) times out.

5

spec.template.spec.containers[].readinessProbe.failureThreshold

The number of times the readiness probe can fail before taking an action to mark the pod as Unready. (The readiness probe checks whether the container is ready to accept traffic.)

1

spec.template.spec.containers[].readinessProbe.initialDelaySeconds

How long to wait (in seconds) before performing the first probe to check whether the container is ready.

10

spec.template.spec.containers[].readinessProbe.periodSeconds

How often (in seconds) to perform a readiness probe to check whether the container is ready.

5

spec.template.spec.containers[].readinessProbe.timeoutSeconds

How long (in seconds) before the readiness probe (which checks whether the container is ready) times out.

3

spec.template.spec.containers[].resources.limits.cpu

The upper limit of CPU cores that are allocated for running the container. Specify an integer, a fractional (for example, 0.5), or a millicore value (for example, 100m, equivalent to 0.1 core). For more information, see Resource Management for Pods and Containers in the Kubernetes documentation.

When you create an integration runtime, no CPU limits are set on the resource if spec.license.use is set to AppConnectEnterpriseNonProductionFREE or CloudPakForIntegrationNonProductionFREE. If required, either use spec.template.spec.containers[].resources.limits.cpu to set the CPU limits, or configure CPU limits for the namespace as described in Configure Memory and CPU Quotas for a Namespace in the Kubernetes documentation.

1

spec.template.spec.containers[].resources.limits.ephemeral-storage

100Mi

spec.template.spec.containers[].resources.limits.memory

The memory upper limit (in bytes) that is allocated for running the container. Specify an integer with a suffix of E, P, T, G, M, K, or a power-of-two equivalent of Ei, Pi, Ti, Gi, Mi, Ki.

1Gi

spec.template.spec.containers[].resources.requests.cpu

The minimum number of CPU cores that are allocated for running the container. Specify an integer, a fractional (for example, 0.5), or a millicore value (for example, 100m, equivalent to 0.1 core). For more information, see Resource Management for Pods and Containers in the Kubernetes documentation.

300m

spec.template.spec.containers[].resources.requests.ephemeral-storage

50Mi

spec.template.spec.containers[].resources.requests.memory

The minimum memory (in bytes) that is allocated for running the container. Specify an integer with a suffix of E, P, T, G, M, K, or a power-of-two equivalent of Ei, Pi, Ti, Gi, Mi, Ki.

256Mi

spec.template.spec.containers[].startupProbe.failureThreshold

The number of times the startup probe can fail before taking action. (The startup probe checks whether the application in the container has started. Liveness and readiness checks are disabled until the startup probe has succeeded.)

For more information about startup probes, see Protect slow starting containers with startup probes in the Kubernetes documentation.

120

spec.template.spec.containers[].startupProbe.initialDelaySeconds

How long to wait (in seconds) before performing the first probe to check whether the runtime application has started. Increase this value if your system cannot start the application in the default time period.

0

spec.template.spec.containers[].startupProbe.periodSeconds

How often (in seconds) to perform a startup probe to check whether the runtime application has started.

5

spec.template.spec.containers[].volumeMounts

Details of where to mount one or more named volumes into a container.

Follows the Volume Mount specification at https://pkg.go.dev/k8s.io/api@v0.20.3/core/v1#VolumeMount. For more information, see Volumes in the Kubernetes documentation.

Specify custom settings for your volume mounts as an array.

spec:
  template:
    spec:
      containers:
        - resources:
            requests:
              cpu: 300m
              memory: 368Mi
          volumeMounts:
            - name: volume-name1
              mountPath: /mypath1
              readOnly: true
              subPath: mysubdir1
              mountPropagation: HostToContainer
          name: runtime
        - volumeMounts:
            - name: volume-name2
              mountPath: /mypath2
              readOnly: true
              subPath: mysubdir2
              mountPropagation: HostToContainer
          name: designerflows
      volumes:
        - name: volume-name1
          ...
        - name: volume-name2
          ...

The following example illustrates how to add an empty directory (as a volume) to the /cache folder in an integration runtime's pod. The mount into the runtime container is read-write by default.

spec:
  template:
    spec:
      containers:
        - resources:
            requests:
              cpu: 300m
              memory: 368Mi
          volumeMounts:
            - name: cache-volume
              mountPath: /cache
          name: runtime
      volumes:
        - name: cache-volume
          emptyDir: {}

spec.template.spec.hostAliases.hostnames[]

One or more hostnames that you want to map to an IP address (as a host alias), to facilitate host name resolution. Use with spec.template.spec.hostAliases.ip.

Specify the hostname without an http:// or https:// prefix. The hostname can include only lowercase alphanumeric characters, hyphen (-) or period (.) symbols, and must start and end with an alphanumeric character; for example:

xyz.example.com

Each host alias is added as an entry to a pod's /etc/hosts file.

Example settings:

spec:
  template:
    spec:
      hostAliases:
        - hostnames:
            - somehostname.com
            - anotherhostname.com
          ip: 192.0.2.0

For more information about host aliases and the hosts file, see the Kubernetes documentation.

spec.template.spec.hostAliases.ip

An IP address that you want to map to one or more hostnames (as a host alias), to facilitate host name resolution. Use with spec.template.spec.hostAliases.hostnames[].

Each host alias is added as an entry to a pod's /etc/hosts file.

spec.template.spec.imagePullSecrets.name

The secret used for pulling images.

spec.template.spec.metadata.annotations

Specify one or more custom annotations (as arbitrary metadata) to apply to each pod that is created during deployment. Specify each annotation as a key/value pair in the format key: value. For example:

spec:
  template:
    spec:
      metadata:
        annotations:
          key1: value1
          key2: value2

For example, you can add a spec.template.spec.metadata.annotations.restart value to trigger a rolling restart of your integration runtime pods, as described in Restarting integration server or integration runtime pods.

The custom annotations that you specify will be merged with the default (generated) annotations. If duplicate annotation keys are detected, the custom value will overwrite the default value.

spec.template.spec.metadata.labels

Specify one or more custom labels (as classification metadata) to apply to each pod that is created during deployment. Specify each label as a key/value pair in the format labelKey: labelValue. For example:

spec:
  template:
    spec:
      metadata:
        labels:
          key1: value1
          key2: value2

The custom labels that you specify will be merged with the default (generated) labels. If duplicate label keys are detected, the custom value will overwrite the default value.

spec.template.spec.nodeSelector

Specify a set of key/value pairs that must be matched against the node labels to decide whether App Connect pods can be scheduled on that node. Only nodes matching all of these key/value pairs in their labels will be selected for scheduling App Connect pods. For more information, see nodeSelector and Assign Pods to Nodes in the Kubernetes documentation.

spec:
  template:
    spec:
      nodeSelector:
        Name_1: value1
        Name_2: value2

spec.template.spec.podSecurityContext.fsGroup

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

The spec.template.spec.podSecurityContext settings define privilege and access control settings for an integration runtime pod's containers and volumes when applicable. When set, this additional SecurityContext is copied into the runtime pod spec.

Specifies a special supplemental group that applies to all container processes in the integration runtime pod. Specify an integer value; for example, 2000.

spec.template.spec.podSecurityContext.fsGroupChangePolicy

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

Defines the behavior for changing the ownership and permission of a volume before being exposed inside the integration runtime pod. This parameter applies only to volume types that support fsGroup-based ownership (and permissions), and has no effect on ephemeral volume types such as secret, configmaps, and emptydir.

Valid values are OnRootMismatch and Always. If not specified, Always is used.

For more information, see Configure volume permission and ownership change policy for Pods.

spec.template.spec.podSecurityContext.runAsGroup

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

Specifies that all processes in any containers of the integration runtime pod run with the primary group ID (GID). The primary GID of the containers is set to root (0) if this parameter is omitted. Specify the GID as an integer; for example, 3000.

spec.template.spec.podSecurityContext.runAsNonRoot

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

Indicates whether the container must run as a non-root user.

spec.template.spec.podSecurityContext.runAsUser

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

Specifies that all processes run with this user ID (UID) for any containers in the integration runtime pod. If unspecified, the value defaults to the user that is specified in the image metadata. Specify the UID as an integer; for example, 1000.

spec.template.spec.podSecurityContext.seccompProfile.localhostProfile

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

The spec.template.spec.podSecurityContext.seccompProfile parameters specify the Seccomp options that are used by the containers in the integration runtime pod.

A preconfigured profile that is defined in a file on the node. The profile must be a descending path, relative to the kubelet's configured Seccomp profile location.

Required only if spec.template.spec.podSecurityContext.seccompProfile.type is set to Localhost.

For more information, see Set the Seccomp Profile for a Container.

spec.template.spec.podSecurityContext.seccompProfile.type

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

The type of Seccomp profile to apply. Valid options are:

• Localhost: Use a profile that is defined in a file on the node.
• RuntimeDefault: Use the container runtime default profile.
• Unconfined: No profile should be applied.

For more information, see Set the Seccomp Profile for a Container.

spec.template.spec.podSecurityContext.seLinuxOptions.level

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

The spec.template.spec.podSecurityContext.seLinuxOptions parameters define the SELinux context to be applied to all containers. If unspecified, the container runtime allocates a random SELinux context for each container. For more information, see Assign SELinux labels to a Container.

An SELinux level label that applies to the container.

spec.template.spec.podSecurityContext.seLinuxOptions.role

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

An SELinux role label that applies to the container.

spec.template.spec.podSecurityContext.seLinuxOptions.type

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

An SELinux type label that applies to the container.

spec.template.spec.podSecurityContext.seLinuxOptions.user

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

An SELinux user label that applies to the container.

spec.template.spec.podSecurityContext.supplementalGroups

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

Sets the supplementalGroups on the pod to enable a filesystem to be mounted with the correct permissions so that it can be processed by the runtime.

Specify an array of groups to apply to the first process that is run in each container, in addition to the container's primary GID, the fsGroup (if specified), and group memberships defined in the container image for the UID of the container process. If unspecified, no additional groups are added to any container.

Group memberships that are defined in the container image for the UID of the container process are still effective, even if they are not included in this array.

spec:
  template:
    spec:
      podSecurityContext:
        supplementalGroups:
          - 5555

spec.template.spec.podSecurityContext.sysctls

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

An array of namespaced sysctl kernel parameters that can be applied to all containers in the integration runtime pod. (sysctl is a Linux-specific command-line tool that is used to configure kernel parameters.)

Specify the properties as name/value pairs. Pods with unsupported sysctl values (by the container runtime) might fail to launch.

spec:
  template:
    spec:
      podSecurityContext:
        sysctls:
          - name: kernel.shm_rmid_forced
            value: '0'

For more information, see Using sysctls in a Kubernetes Cluster.

spec.template.spec.podSecurityContext.windowsOptions.gmsaCredentialSpec

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

The spec.template.spec.podSecurityContext.windowsOptions parameters define Windows-specific settings to apply to all containers.

Defines where the GMSA admission webhook inlines the contents of the GMSA credential spec that is specified in spec.template.spec.podSecurityContext.windowsOptions.gmsaCredentialSpecName.

spec.template.spec.podSecurityContext.windowsOptions.gmsaCredentialSpecName

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

The name of the GMSA credential spec to use.

spec.template.spec.podSecurityContext.windowsOptions.hostProcess

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

Indicates whether a container should be run as a HostProcess container.

Valid values are true and false.

All of a pod's containers must have the same effective HostProcess value; a mix of HostProcess containers and non-HostProcess containers is not allowed.

spec.template.spec.podSecurityContext.windowsOptions.runAsUserName

(Only applicable if spec.version resolves to 12.0.10.0-r2 or later)

The username in Windows to run the entry point of the container process. If unspecified, defaults to the user that is specified in the image metadata. Specify the username as a string.

spec.template.spec.priority

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Pod priority settings control which pods get killed, rescheduled, or started to allow the most important pods to keep running.

spec.template.spec.priority specifies an integer value, which various system components use to identify the priority of the (always-on) integration runtime pod. The higher the value, the higher the priority.

If the priority admission controller is enabled, you cannot manually specify a priority value because the admission controller automatically uses the spec.template.spec.priorityClassName setting to populate this field with a resolved value.

spec.template.spec.priorityClassName

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

A priority class name that maps to the integer value of a pod priority in spec.template.spec.priority. If specified, this class name indicates the pod's priority (or importance) relative to other pods.

Valid values are as follows:

• Specify either of these built-in Kubernetes classes, which mark a pod as critical and indicate the highest priorities: system-node-critical or system-cluster-critical. system-node-critical is the highest available priority.
• To specify any other priority class, create a PriorityClass object with that class name. For more information, see Pod Priority and Preemption in the Kubernetes documentation.

If you do not specify a class name, the priority is set as follows:

• The class name of an identified PriorityClass object, which has its globalDefault field set to true, is assigned.
• If there is no PriorityClass object with a globalDefault setting of true, the priority of the pod is set to 0 (zero).

spec.template.spec.tolerations[].effect

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

To prevent pods from being scheduled onto inappropriate nodes, use taints together with tolerations. Tolerations allow scheduling, but don't guarantee scheduling because the scheduler also evaluates other parameters as part of its function. Apply one or more taints to a node (by running oc taint or kubectl taint with a key, value, and taint effect) to indicate that the node should repel any pods that do not tolerate the taints. Then, apply toleration settings (effect, key, operator, toleration period, and value) to a pod to allow it to be scheduled on the node if the pod's toleration matches the node's taint. For more information, see Taints and Tolerations in the Kubernetes documentation.

If you need to specify one or more tolerations for an always-on integration runtime pod, you can use the collection of spec.template.spec.tolerations[].* parameters to define an array.

For spec.template.spec.tolerations[].effect, specify the taint effect that the toleration should match. (The taint effect on a node determines how that node reacts to a pod that is not configured with appropriate tolerations.) Leave the effect empty to match all taint effects. Alternatively, specify one of these values: NoSchedule, PreferNoSchedule, or NoExecute.

spec.template.spec.tolerations[].key

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Specify the taint key that the toleration applies to. Leave the key empty and set spec.template.spec.tolerations[].operator to Exists to match all taint keys, values, and effects.

spec.template.spec.tolerations[].operator

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Specify an operator that represents a key's relationship to the value in spec.template.spec.tolerations[].value. Valid operators are Exists and Equal. Exists is equivalent to a wildcard for the toleration value, and indicates that the pod can tolerate all taints of a particular category.

Equal

spec.template.spec.tolerations[].tolerationSeconds

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Optionally specify a period of time in seconds that determines how long the pod stays bound to a node with a matching taint before being evicted. Applicable only for a toleration with a NoExecute effect (which indicates that a pod without the appropriate toleration should immediately be evicted from the node).

By default, no value is set, which means that a pod that tolerates the taint will never be evicted. Zero and negative values are treated as 0 (evict immediately).

spec.template.spec.tolerations[].value

(Only applicable if spec.version resolves to 12.0.9.0-r2 or later)

Specify the taint value that the toleration matches to. If the operator is Exists, leave this value empty.

spec.template.spec.topologySpreadConstraint[].*

(Only applicable if spec.version resolves to 13.0.4.1-r1 or later)

Specify custom topology spread constraints that control how to distribute or spread pods across topological domains such as zones, nodes, or regions in a multi-zone or multi-node cluster. You can use these settings to configure high availability and fault tolerance by spreading workloads evenly across domains.

You can specify an array of topology spread constraints that allow you to define the following settings:

• A maximum skew value (required) that describes the degree to which the integration runtime pods might be unevenly distributed.
• A topology key (required) of node labels, which can be used to identify nodes that are in the same topology. Valid values include:
  • The well-known label keys such as kubernetes.io/hostname, which indicates that each node is a domain of that topology, and topology.kubernetes.io/zone, which indicates that each zone is a domain of that topology
  • Private (unqualified) label keys
• A whenUnsatisfiable value (required) of DoNotSchedule (the default) or ScheduleAnyway, which indicates whether the scheduler should schedule a pod that doesn't satisfy the spread constraint.
• A label selector that is used to find matching pods and calculate the number of pods in their corresponding topology domain.
• One or more matchLabelKeys values that define pod label keys which are used to select the pods over which spreading is calculated.
• A minimum number of eligible domains, each of which defines a particular instance of a topology whose nodes meet the requirements of nodeAffinityPolicy and nodeTaintsPolicy.
• A nodeAffinityPolicy value that defines how the pod's nodeAffinity/nodeSelector are treated when calculating the pod topology spread skew. Valid values are Honor, which includes only nodes that match nodeAffinity/nodeSelector in the calculations, and Ignore, which ignores nodeAffinity/nodeSelector and includes all nodes in the calculations.
• A nodeTaintsPolicy value that defines how node taints are treated when calculating the pod topology spread skew. Valid values are Honor, which includes nodes without taints as well as tainted nodes for which the incoming pod has a toleration, and Ignore, which ignores node taints and includes all nodes.

The following example shows the structure of the supported topology spread constraints parameters:

spec:
  template:
    spec:
      topologySpreadConstraint:
        - labelSelector:
            matchExpressions:
              - values:
                  - InOrNotInValue1
                  - InOrNotInValue2
                key: labelKey
                operator: In
            matchLabels:
              customkey: value
          matchLabelKeys:
            - podLabelKey1
            - podLabelKey2
          maxSkew: 2
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          minDomains: 5
          nodeAffinityPolicy: Ignore
          nodeTaintsPolicy: Honor

For more information about these settings and how they work together, see Pod Topology Spread Constraints in the Kubernetes documentation and Controlling pod placement by using pod topology spread constraints in the Red Hat OpenShift documentation.

For a tutorial on how to configure topology spread constraints for Dashboard and integration runtime pods, see Configuring topology spread constraints for App Connect Dashboard and integration runtime pods.

spec.template.spec.volumes

Details of one or more named volumes that can be provided to the pod, to use for persisting data. Each volume must be configured with the appropriate permissions to allow the integration runtime to read or write to it as required.

Follows the Volume specification at https://pkg.go.dev/k8s.io/api/core/v1#VolumeMount. For more information, see Volumes in the Kubernetes documentation.

Specify custom settings for your volume types as an array. Use spec.template.spec.volumes with spec.template.spec.containers[].volumeMounts.

The following example illustrates how to add an empty directory (as a volume) to the /cache folder in an integration runtime's pod. The mount into the runtime container is read-write by default.

spec:
  template:
    spec:
      containers:
        - resources:
            requests:
              cpu: 300m
              memory: 368Mi
          volumeMounts:
            - name: cache-volume
              mountPath: /cache
          name: runtime
      volumes:
        - name: cache-volume
          emptyDir: {}

spec.version

The product version that the integration runtime is based on. Can be specified by using a channel or as a fully qualified version. If you specify a channel, you must ensure that the license aligns with the latest fully qualified version in the channel.

If you are using IBM App Connect Operator 7.1.0 or later, the supported channels or versions will depend on the Red Hat OpenShift version that is installed in your cluster.

To view the available values that you can choose from and the licensing requirements, see spec.version values and Licensing reference for IBM App Connect Operator.

13.0

(Applicable only for integration runtimes at version 13.0.2.2-r1 or later)