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

Return to the regular view of this page.

CAP Operator Overview

An overview of the architecture

CAP Operator consists of the following components:

  1. CAP Controller: A native Kubernetes controller that reconciles custom resources defined as part of the operator.
  2. Webhooks: Validating webhooks that ensure consistency of custom resource objects submitted to the Kubernetes API server.
  3. Subscription Server: A web server that handles HTTP requests submitted by SAP BTP saas-registry service instances during tenant subscription and unsubscription.

The following diagram shows how the main components interact when deployed to a cluster:

cluster-components

For more details about each component, see the following pages.

1 - Controller

Reconciliation of custom resource objects

The CAP controller uses client-go from Kubernetes, which provides the tools and utilities needed to interact with the Kubernetes API server and manage the custom resources included in CAP Operator.

The controller uses Informers to watch certain resources and invokes registered event handlers when these resources are modified. To streamline the processing of such notifications, rate limiting queues are implemented, which store the changes and allow the processing of these items in independent reconciliation threads (go routines). Such a design allows sequential processing of the changed items and avoids conflicts.

The following namespaced custom resources have been defined to be reconciled by the CAP controller:

  • CAPApplication: defines a high-level application, its domains, and the consumed SAP BTP services
  • CAPApplicationVersion: defines a child resource of the CAPApplication, which contains container images that will be used to deploy application components (workloads) of a specific version
  • CAPTenant: represents a child resource of the CAPApplication which corresponds to an SAP BTP subaccount subscribed to the application
  • CAPTenantOperation: represents a provisioning, deprovisioning, or upgrade operation on a tenant that is scheduled as a child resource of a CAPTenant and executed as a sequence of specified steps.

Parent-child relationships between custom resources are established by defining owner references for the children.

controller

2 - Subscription Server

Integration with SAP Software-as-a-Service Provisioning service (SaaS)

The Subscription Server handles HTTP requests from the SAP Software-as-a-Service Provisioning service for tenant subscription operations on SAP Cloud Application Programming Model applications installed in the cluster.

During the creation of a saas-registry service instance (in the provider subaccount), callback URLs are configured to point to the subscription server routes.

When a consumer tenant subscribes to an application managed by the operator, the subscription server receives the callback, validates the request, and creates a CAPTenant custom resource object for the identified CAPApplication.

The subscription server returns an Accepted (202) response and starts a background routine that polls for tenant status while the CAPTenant changes are independently reconciled by the controller.

Once the tenant provisioning process completes (or fails), the tracking routine returns the appropriate status to the SaaS Registry via an asynchronous callback.

subscription

(More details about asynchronous tenant subscription.)

This asynchronous approach avoids timeouts during synchronous calls and enables scheduling dedicated jobs (via CAPTenantOperation) for completing the subscription and performing any additional cluster tasks (for example, creating a VirtualService for the tenant subdomain).