This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Resources

Detailed configuration of resources managed by CAP Operator

1 - CAPApplication

How to configure the CAPApplication resource

Here’s an example of a fully configured CAPApplication:

apiVersion: sme.sap.com/v1alpha1
kind: CAPApplication
metadata:
  name: cap-app
  namespace: cap-ns
spec:
  btp:
    services:
      - class: xsuaa
        name: cap-uaa
        secret: cap-uaa-bind
      - class: saas-registry
        name: cap-saas-reg
        secret: cap-saas-reg-bind
      - class: service-manager
        name: cap-service-manager
        secret: cap-svc-man-bind
      - class: destination
        name: cap-destination
        secret: cap-bem-02-dest-bind
      - class: html5-apps-repo
        name: cap-html5-repo-host
        secret: cap-html5-repo-bind
      - class: html5-apps-repo
        name: cap-html5-repo-runtime
        secret: cap-html5-rt-bind
      - class: portal
        name: cap-portal
        secret: cap-portal-bind
      - class: business-logging
        name: cap-business-logging
        secret: cap-business-logging-bind
  btpAppName: cap-app
  domainRefs:
  - kind: Domain
    name: cap-app-01-primary
  - kind: ClusterDomain
    name: common-external-domain
  providerSubaccountId: 7a49218f-c750-4e1f-a248-7f1cefa13010

The btp.services array specifies all SAP BTP service instances and their corresponding Kubernetes Secrets (containing credentials) required by the application. These service instances are assumed to exist in the provider subaccount. You can use operators such as cf-service-operator or sap-btp-service-operator to declaratively create these service instances and their credentials as Kubernetes resources.

The providerSubaccountId identifies the provider subaccount linked to the application. The combination of providerSubaccountId and btpAppName (equivalent to XSAPPNAME) must be unique, as it is used in various SAP BTP service and application constructs.

The provider section is deprecated and may be completely ommited as of version 0.31.0 even for multi-tenant applications, this also skips the creation of a provider tenant.

The domainRefs section references one or more Domain or ClusterDomain resources.

NOTE: While the same secondary domain can technically be shared across applications using ClusterDomain, tenant subdomains must be unique across all applications sharing that domain.

NOTE: The provider section must always be omitted for services-only applications.

The optional rolloutOnCredentialUpdate field enables automatic rolling restarts of affected Deployments when the referenced BTP service credential Secrets are updated. See Rollout on Credential Update for details.

2 - CAPApplicationVersion

How to configure the CAPApplicationVersion resource

The CAPApplicationVersion has the following high-level structure:

apiVersion: sme.sap.com/v1alpha1
kind: CAPApplicationVersion
metadata:
  name: cav-cap-app-v1
  namespace: cap-ns
spec:
  version: 3.2.1 # <-- semantic version (must be unique within the versions of a CAP application)
  capApplicationInstance: cap-app
  registrySecrets: # <-- image pull secrets to be used in the workloads
    - regcred
  workloads: # <-- define deployments and jobs used for this application version
    - name: "cap-backend"
      deploymentDefinition: # ...
      consumedBTPServices: # ...
    - name: "app-router"
      deploymentDefinition: # ...
      consumedBTPServices: # ...
    - name: "service-content"
      jobDefinition: # ...
      consumedBTPServices: # ...
    - name: "tenant-operation"
      jobDefinition: # ...
      consumedBTPServices: # ...
  tenantOperations: # ... <-- (optional)
  • A CAPApplicationVersion is always associated with a CAPApplication in the same namespace, referenced via the capApplicationInstance attribute.
  • The workloads array defines the software components of the application. Examples include a deployment for the CAP application server or a job for tenant operations. Each workload must have either a deploymentDefinition or a jobDefinition. See the next section for details.
  • The optional tenantOperations attribute defines a sequence of steps (jobs) to execute during tenant operations (provisioning, upgrade, or deprovisioning).

The CAPApplicationVersion resource is immutable — its spec must not be modified after deployment. This is enforced by webhooks, which we recommend keeping active (the default).

Workloads with deploymentDefinition

name: cap-backend
consumedBTPServices: # <-- an array of service instance names referencing the SAP BTP services defined in the CAPApplication resource
  - cap-uaa
  - cap-saas-reg
deploymentDefinition:
  type: CAP # <-- possible values are CAP / Router / Additional / Service
  image: some.repo.example.com/cap-app/server:3.22.11 # <-- container image
  env: # <-- (optional) same as in core v1 pod.spec.containers.env
    - name: SAY
      value: "I'm GROOT"
  replicas: 3 # <-- (optional) replicas for scaling
  ports:
    - name: app-port
      port: 4004
      routerDestinationName: cap-server-url
    - name: tech-port
      port: 4005
  monitoring:
    scrapeConfig:
      port: tech--port
    deletionRules:
      expression: scalar(sum(avg_over_time(current_sessions{job="cav-cap-app-v1-cap-backend-svc",namespace="cap-ns"}[2h]))) <= bool 5

The type of the deployment indicates how the operator handles this workload (for example, injection of destinations used by the Approuter). Valid values are:

  • CAP to indicate a CAP application server. Only one workload of this type is allowed.
  • Router to indicate a version of the Approuter. Only one workload of this type is allowed.
  • Additional to indicate supporting components deployed alongside the CAP application server.
  • Service to indicate workloads that are tenant-agnostic.

You can define optional attributes such as replicas, env, resources, probes, securityContext, initContainers, and ports to configure the deployment.

Port configuration

You can define which ports (and how many) exposed by a deployment container are made available inside the cluster (via Services of type ClusterIP). The port definition includes a name in addition to the port number being exposed.

For deploymentDefinition types other than Router, you can specify a routerDestinationName that is used as a named destination injected into the Approuter.

The port configurations are not mandatory and can be omitted. When omitted, the operator applies the following defaults:

  • For workloads of type CAP, the default port 4004 is added to the Service, and a destination named srv-api is added to the Approuter referencing this service port (any existing destinations environment configuration for this workload is preserved, with only the URL overwritten).
  • For workloads of type Router, port 5000 is exposed in the Service. This Service is used as the target for HTTP traffic reaching the application domain (domains are specified in the CAPApplication resource).

NOTE: If multiple ports are configured for a workload of type Router, the first port is used to target external traffic to the application domain.

Monitoring configuration

For each deployment workload in a CAPApplicationVersion, you can define:

  1. Deletion rules: Criteria based on metrics that, when satisfied, indicate the workload can be removed.
  2. Scrape configuration: Defines how metrics are scraped from the workload service.

Details of how to configure workload monitoring can be found here.

Workloads with jobDefinition

workloads:
  # ... deployment workloads have been omitted in this example
  - name: "content-deployer"
    consumedServices: # ...
    jobDefinition:
      type: Content
      image: some.repo.example.com/cap-app/content:1.0.1
  - name: "tenant-operation"
    consumedServices: # ...
    jobDefinition:
      type: TenantOperation
      image: some.repo.example.com/cap-app/server:3.22.11
      backoffLimit: 2 # <-- determines retry attempts for the job on failure (default is 6)
      ttlSecondsAfterFinished: 300 # <-- the job will be cleaned up after this duration
      env:
        - name: CDS_ENV
          value: production
        - name: CDS_CONFIG
          value: '{ "requires":{"cds.xt.DeploymentService":{"hdi": { "create":{ "database_id": "16e25c51-5455-4b17-a4d7-43545345345" } } } } }'
  - name: "notify-upgrade"
    consumedServices: # ...
    jobDefinition:
      type: CustomTenantOperation
      image: # ...
      command: ["npm", "run", "notify:upgrade"] # <-- custom entry point for the container allows reuse of a container image with multiple entry points
      backoffLimit: 1
  - name: "create-test-data"
    consumedServices: # ...
    jobDefinition:
      type: CustomTenantOperation
      image: # ...
      command: ["npm", "run ", "deploy:testdata"]

Workloads with a jobDefinition represent a job that executes at a particular point in the lifecycle of the application or tenant. The following values are allowed for type in such workloads:

  • Content: A content deployer job that deploys SAP BTP service-specific content from the application version. This job runs as soon as a new CAPApplicationVersion resource is created in the cluster. Multiple workloads of this type may be defined, and the order in which they run can be specified via ContentJobs.
  • TenantOperation: A job executed during provisioning, upgrade, or deprovisioning of a tenant (CAPTenant). These jobs are controlled by the operator and use the cds/mtxs APIs to perform HDI content deployment by default. A workload of type TenantOperation must always be defined in the CAPApplicationVersion for multi-tenant applications. If cds/mtxs APIs are used, command can be specified to trigger tenant operations with a custom command.
  • CustomTenantOperation: An optional job that runs before or after the TenantOperation, allowing the application to perform tenant-specific tasks (for example, creating test data).

Sequencing tenant operations

A tenant operation refers to provisioning, upgrade, or deprovisioning, which are executed in the context of a CAP application for individual tenants (using the cds/mtxs or similar modules provided by CAP). Within the workloads, two types of jobs are valid for such operations: TenantOperation and CustomTenantOperation.

The TenantOperation is mandatory for all tenant operations.

In addition, you can choose which CustomTenantOperation jobs run for a specific operation and in which order. For example, a CustomTenantOperation that deploys test data to the tenant database schema should run during provisioning but must not run during deprovisioning.

The field tenantOperations specifies which jobs run during the different tenant operations and their execution order.

spec:
  workloads: # ...
  tenantOperations:
    provisioning:
      - workloadName: "tenant-operation"
      - workloadName: "create-test-data"
    upgrade:
      - workloadName: "notify-upgrade"
        continueOnFailure: true # <-- indicates the overall operation may proceed even if this step fails
      - workloadName: "tenant-operation"
      - workloadName: "create-test-data"
    # <-- as the deprovisioning steps are not specified, only the `TenantOperation` workload (first available) will be executed

In the example above, for each tenant operation, the valid jobs (steps) and their execution order are specified. Each step in an operation is defined with:

  • workloadName refers to the job workload executed in this operation step.
  • continueOnFailure is valid only for CustomTenantOperation steps and indicates whether the overall tenant operation can proceed when this step fails.

NOTE:

  • tenantOperations is only required if CustomTenantOperations are used. If not specified, each operation consists only of the TenantOperation step (the first one found in workloads).
  • A workload of type TenantOperation must always be present in the CAPApplicationVersion. The previous behaviour of falling back to the CAP deployment workload when no TenantOperation job was defined is no longer supported.
  • The tenantOperations sequencing applies only to tenants provisioned (or deprovisioned) on this CAPApplicationVersion and to tenants being upgraded to it.

Sequencing content jobs

When you create a CAPApplicationVersion, you can define multiple content jobs. The order in which these jobs run is important, as some jobs may depend on the output of others. The ContentJobs property specifies the execution order of content jobs.

spec:
  workloads: # ...
  tenantOperations: # ...
  contentJobs:
    - content-deployer-service
    - content-deployer-ui

ServiceExposures Configuration

See Service Exposure page for details.

Other attributes can be configured as documented.

Port configuration

You can define which ports (and how many) exposed by a deployment container are made available inside the cluster (via Services of type ClusterIP). The port definition includes a name in addition to the port number being exposed.

For service-only workloads, the routerDestinationName is not relevant.

The port configurations are mandatory and cannot be omitted.

Full Example

apiVersion: sme.sap.com/v1alpha1
kind: CAPApplicationVersion
metadata:
  name: cav-cap-app-v1
  namespace: cap-ns
spec:
  version: 3.2.1
  capApplicationInstance: cap-app
  registrySecrets:
    - regcred
  workloads:
    - name: cap-backend
      consumedBTPServices:
        - cap-uaa
        - cap-service-manager
        - cap-saas-reg
      deploymentDefinition:
        type: CAP
        image: some.repo.example.com/cap-app/server:3.22.11
        env:
          - name: CDS_ENV
            value: production
          - name: CDS_CONFIG
            value: '{ "requires":{"cds.xt.DeploymentService":{"hdi": { "create":{ "database_id": "16e25c51-5455-4b17-a4d7-43545345345" } } } } }'
        replicas: 3
        ports:
          - name: app-port
            port: 4004
            routerDestinationName: cap-server-url
          - name: tech-port
            port: 4005
            appProtocol: grpc
        monitoring:
          scrapeConfig:
            port: tech--port
          deletionRules:
            expression: scalar(sum(avg_over_time(current_sessions{job="cav-cap-app-v1-cap-backend-svc",namespace="cap-ns"}[2h]))) <= bool 5
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 4005
          initialDelaySeconds: 20
          periodSeconds: 10
          timeoutSeconds: 2
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 4005
          initialDelaySeconds: 20
          periodSeconds: 10
          timeoutSeconds: 2
        resources:
          limits:
            cpu: 200m
            memory: 500Mi
          requests:
            cpu: 20m
            memory: 50Mi
        securityContext:
          runAsUser: 1000
          runAsGroup: 2000
    - name: "app-router"
      consumedBTPServices:
        - cap-uaa
        - cap-saas-reg
        - cap-html5-repo-rt
      deploymentDefinition:
        type: Router
        image: some.repo.example.com/cap-app/router:4.0.1
        env:
          - name: PORT
            value: "3000"
        ports:
          - name: router-port
            port: 3000
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 3000
          initialDelaySeconds: 20
          periodSeconds: 10
          timeoutSeconds: 2
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 3000
          initialDelaySeconds: 20
          periodSeconds: 10
          timeoutSeconds: 2
        resources:
          limits:
            cpu: 200m
            memory: 500Mi
          requests:
            cpu: 20m
            memory: 50Mi
        podSecurityContext:
          runAsUser: 2000
          fsGroup: 2000
    - name: "service-content"
      consumedServices:
        - cap-uaa
        - cap-portal
        - cap-html5-repo-host
      jobDefinition:
        type: Content
        image: some.repo.example.com/cap-app/content:1.0.1
        securityContext:
          runAsUser: 1000
          runAsGroup: 2000
    - name: "ui-content"
      consumedServices:
        - cap-uaa
        - cap-portal
        - cap-html5-repo-host
      jobDefinition:
        type: Content
        image: some.repo.example.com/cap-app/ui-content:1.0.1
        securityContext:
          runAsUser: 1000
          runAsGroup: 2000
    - name: "tenant-operation"
      consumedServices: # ...
      jobDefinition:
        type: TenantOperation
        image: some.repo.example.com/cap-app/server:3.22.11
        backoffLimit: 2
        ttlSecondsAfterFinished: 300
        env:
          - name: CDS_ENV
            value: production
          - name: CDS_CONFIG
            value: '{ "requires":{"cds.xt.DeploymentService":{"hdi": { "create":{ "database_id": "16e25c51-5455-4b17-a4d7-43545345345" } } } } }'
    - name: "notify-upgrade"
      consumedServices: []
      jobDefinition:
        type: CustomTenantOperation
        image: some.repo.example.com/cap-app/server:3.22.11
        command: ["npm", "run", "notify:upgrade"]
        backoffLimit: 1
    - name: "create-test-data"
      consumedServices:
        - cap-service-manager
      jobDefinition:
        type: CustomTenantOperation
        image: some.repo.example.com/cap-app/server:3.22.11
        command: ["npm", "run ", "deploy:testdata"]
  tenantOperations:
    provisioning:
      - workloadName: "tenant-operation"
      - workloadName: "create-test-data"
    upgrade:
      - workloadName: "notify-upgrade"
        continueOnFailure: true
      - workloadName: "tenant-operation"
      - workloadName: "create-test-data"
  contentJobs:
    - service-content
    - ui-content

NOTE: The CAP Operator workloads support several configurations (drawn from the Kubernetes API), which can be found in the API reference:

The supported configurations are intentionally kept minimal to keep the overall API simple, covering only the most commonly used options.

Note: initContainers have access to nearly the same environment variables as the main container, including the VCAP_SERVICES environment variable.

3 - CAPTenant

How to configure the CAPTenant resource

The CAPTenant resource indicates the existence of a tenant in the related application (or one that is currently being provisioned). The resource starts with a Provisioning state and moves to Ready when successfully provisioned. Managing tenants as Kubernetes resources allows you to control not only the lifecycle of the entity, but also other requirements that must be fulfilled for the application to serve tenant-specific requests (for example, creating networking resources).

apiVersion: sme.sap.com/v1alpha1
kind: CAPTenant
metadata:
  name: cap-app-consumer-ge455
  namespace: cap-ns
spec:
  capApplicationInstance: cap-app
  subDomain: consumer-x
  tenantId: cb46733-1279-48be-fdf434-aa2bae55d7b5
  version: "1"
  versionUpgradeStrategy: always

The specification contains attributes relevant to SAP BTP that identify a tenant, such as tenantId and subDomain.

The version field corresponds to the CAPApplicationVersion on which the tenant is provisioned or to which it was upgraded. When a newer CAPApplicationVersion is available, the operator automatically increments the tenant version, which triggers the upgrade process. The versionUpgradeStrategy defaults to always, but can be set to never in exceptional cases to prevent automatic upgrades of the tenant.

4 - CAPTenantOperation

How to configure the CAPTenantOperation resource
apiVersion: sme.sap.com/v1alpha1
kind: CAPTenantOperation
metadata:
  name: cap-app-consumer-ge455-77kb9
  namespace: cap-ns
spec:
  capApplicationVersionInstance: cav-cap-app-v2
  operation: upgrade
  steps:
    - continueOnFailure: true
      name: tenant-operation
      type: CustomTenantOperation
    - name: tenant-operation
      type: TenantOperation
    - name: create-test-data
      type: CustomTenantOperation
  subDomain: consumer-x
  tenantId: cb46733-1279-48be-fdf434-aa2bae55d7b5

The example above shows a CAPTenantOperation for an upgrade operation. In addition to tenant details, it specifies the CAPApplicationVersion to use. For upgrade and provisioning operations, this is the target version; for deprovisioning, it is the tenant’s current version.

The operation executes a series of steps (jobs) specified in or derived from the CAPApplicationVersion. Each step refers to a workload of type TenantOperation or CustomTenantOperation. When CAP Operator creates a CAPTenantOperation, at least one step of type TenantOperation must be present (this is the job that performs the database schema update using CAP-provided modules).

CustomTenantOperation jobs are hooks that the application can execute before or after the TenantOperation. To help applications identify the execution context, each job receives the following environment variables:

  • CAPOP_APP_VERSION: The semantic version from the relevant CAPApplicationVersion
  • CAPOP_TENANT_ID: The tenant identifier
  • CAPOP_TENANT_OPERATION: The operation type — provisioning, deprovisioning, or upgrade
  • CAPOP_TENANT_SUBDOMAIN: The subdomain (from the subaccount) of the tenant
  • CAPOP_TENANT_TYPE: The tenant type — provider or consumer
  • CAPOP_APP_NAME: The BTP app name from the corresponding CAPApplication
  • CAPOP_GLOBAL_ACCOUNT_ID: The global account identifier from the corresponding CAPApplication (Deprecated: Will be removed soon).
  • CAPOP_PROVIDER_SUBACCOUNT_ID: The provider subaccount identifier from the corresponding CAPApplication
  • CAPOP_PROVIDER_TENANT_ID: The provider tenant identifier (if it exists) from the corresponding CAPApplication (Deprecated: Will be removed soon).
  • CAPOP_PROVIDER_SUBDOMAIN: The provider tenant subdomain (if it exists) from the corresponding CAPApplication (Deprecated: Will be removed soon).

All of the above environment variables are also available on the corresponding initContainers, along with relevant VCAP_SERVICES credentials.

5 - CAPTenantOutput

How to configure the CAPTenantOutput resource

CAPTenantOutput can be used to add additional data to the asynchronous callback parameters sent by the SaaS Provisioning service during tenant onboarding. The resource is not reconciled; it is consumed by the subscription server to generate additional callback data. It has the following structure:

apiVersion: sme.sap.com/v1alpha1
kind: CAPTenantOutput
metadata:
  name: cap-app-consumer-output
  namespace: cap-ns
  labels:
    sme.sap.com/btp-tenant-id: cb46733-1279-48be-fdf434-aa2bae55d7b5
spec:
  subscriptionCallbackData: '{foo: bar}'

The example above shows a resource associated with a tenant via the sme.sap.com/btp-tenant-id label, which must be set by consumers.

6 - Domain

How to configure the Domain resource

A Domain resource is namespace-scoped. All sub-resources — Gateway, DNSEntry, and (with Gardener certificate manager) the Certificate — are created in the same namespace as the Domain.

apiVersion: sme.sap.com/v1alpha1
kind: Domain
metadata:
  namespace: cap-app-01
  name: cap-app-01-primary
spec:
  domain: my.cluster.shoot.url.k8s.example.com
  ingressSelector:
    app: istio-ingressgateway
    istio: ingressgateway
  tlsMode: Simple       # Simple (default), Mutual, or OptionalMutual
  dnsMode: Wildcard     # None (default), Wildcard, Subdomain, or Custom
  dnsTarget: public-ingress.cluster.domain  # Optional
  certConfig:           # Optional; only relevant when tlsMode is Mutual or OptionalMutual
    additionalCACertificate: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----

Fields

domain — the DNS domain name. The TLS certificate is issued for the wildcard *.domain.

ingressSelector — label selector used to locate the Istio Ingress Gateway pods. The operator discovers the gateway’s namespace and load balancer service from these pods, and applies the selector to the Istio Gateway resource.

tlsMode — TLS mode for the Istio Gateway:

  • Simple (default) — server-side TLS only.
  • Mutual — mutual TLS; client certificate required.
  • OptionalMutual — mutual TLS; client certificate optional.

dnsMode — controls DNS entry creation (Gardener external-dns-management only; ignored otherwise):

  • None (default) — no DNS entries created.
  • Wildcard — creates a single *.domain entry pointing to dnsTarget.
  • Subdomain — creates <subdomain>.domain entries for each subdomain observed across referencing applications.
  • Custom — creates entries defined by dnsTemplates; each template has a name and target field rendered as Go templates. Available variables: {{.domain}}, {{.dnsTarget}}, {{.subDomain}}. See Custom DNS Templates for details.

dnsTarget (optional) — the load balancer hostname or IP address to use as the DNS target. Resolved in order: explicit dnsTarget field → DNS_TARGET environment variable → load balancer service annotation on the Istio Ingress Gateway service.

certConfig.additionalCACertificate (optional) — PEM-encoded CA certificate Istio uses to verify client certificates when tlsMode is Mutual or OptionalMutual. See Configuring Additional CA Certificates for details.

Created resources

Sub-resources are mainly created in the Domain namespace:

  • Istio Gateway — always created.
  • DNSEntry — Gardener DNS manager only.
  • Certificate (Gardener cert-manager) — the certificate’s secretRef points to the Istio Ingress Gateway namespace, which supports cross-namespace secret references.
  • Certificate (cert-manager) — created in the Istio Ingress Gateway namespace; cert-manager does not support cross-namespace secret references.
  • CA certificate Secret — created in the Istio Ingress Gateway namespace; only when certConfig.additionalCACertificate is set.

7 - ClusterDomain

How to configure the ClusterDomain resource

A ClusterDomain resource is cluster-scoped and intended for domains shared across multiple applications or namespaces. All sub-resources — Gateway, DNSEntry, and (with Gardener certificate manager) the Certificate — are created in the namespace where CAP Operator is installed.

apiVersion: sme.sap.com/v1alpha1
kind: ClusterDomain
metadata:
  name: common-external-domain
spec:
  domain: my.example.com
  ingressSelector:
    app: istio-ingressgateway
    istio: ingressgateway
  tlsMode: Simple       # Simple (default), Mutual, or OptionalMutual
  dnsMode: Subdomain    # None (default), Wildcard, Subdomain, or Custom
  dnsTarget: public-ingress.cluster.domain  # Optional
  certConfig:           # Optional; only relevant when tlsMode is Mutual or OptionalMutual
    additionalCACertificate: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----

Fields

domain — the DNS domain name. The TLS certificate is issued for the wildcard *.domain.

ingressSelector — label selector used to locate the Istio Ingress Gateway pods. The operator discovers the gateway’s namespace and load balancer service from these pods, and applies the selector to the Istio Gateway resource.

tlsMode — TLS mode for the Istio Gateway:

  • Simple (default) — server-side TLS only.
  • Mutual — mutual TLS; client certificate required.
  • OptionalMutual — mutual TLS; client certificate optional.

dnsMode — controls DNS entry creation (Gardener external-dns-management only; ignored otherwise):

  • None (default) — no DNS entries created.
  • Wildcard — creates a single *.domain entry pointing to dnsTarget.
  • Subdomain — creates <subdomain>.domain entries for each subdomain observed across referencing applications.
  • Custom — creates entries defined by dnsTemplates; each template has a name and target field rendered as Go templates. Available variables: {{.domain}}, {{.dnsTarget}}, {{.subDomain}}. See Custom DNS Templates for details.

dnsTarget (optional) — the load balancer hostname or IP address to use as the DNS target. Resolved in order: explicit dnsTarget field → DNS_TARGET environment variable → load balancer service annotation on the Istio Ingress Gateway service.

certConfig.additionalCACertificate (optional) — PEM-encoded CA certificate Istio uses to verify client certificates when tlsMode is Mutual or OptionalMutual. See Configuring Additional CA Certificates for details.

Created resources

Sub-resources are mainly created in the CAP Operator namespace:

  • Istio Gateway — always created.
  • DNSEntry — Gardener DNS manager only.
  • Certificate (Gardener cert-manager) — the certificate’s secretRef points to the Istio Ingress Gateway namespace, which supports cross-namespace secret references.
  • Certificate (cert-manager) — created in the Istio Ingress Gateway namespace; cert-manager does not support cross-namespace secret references.
  • CA certificate Secret — created in the Istio Ingress Gateway namespace; only when certConfig.additionalCACertificate is set.