CAP Operator Overview
An overview of the architecture
CAP Operator is comprised of the following components:
- CAP Controller: a native Kubernetes controller that reconciles custom resources defined as part of the operator
- Webhooks: validating webhooks to ensure consistency of custom resource objects submitted to the Kubernetes API server
- Subscription Server: web server for handling HTTP requests submitted by the SAP BTP
saas-registry service instances during tenant subscription (and unsubscribe)
The following diagram depicts how the main components interact when deployed to a cluster:
Looking for more details about the CAP Operator components? Go to the next pages.
1 - Controller
Reconciliation of custom resource objects
To implement the CAP controller, you use the client-go from Kubernetes, which provides the required tools and utilities to interact with the Kubernetes API server. It manages custom resources that are 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 servicesCAPApplicationVersion: defines a child resource of the CAPApplication, which contains container images that will be used to deploy application components (workloads) of a specific versionCAPTenant: represents a child resource of the CAPApplication which corresponds to an SAP BTP subaccount subscribed to the applicationCAPTenantOperation: 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.
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 that have been installed in the cluster.
During the creation of a saas-registry service instance (in the provider subaccount), callback URLs are configured, which point to the subscription server routes.
When a consumer tenant subscribes to an application managed by the operator, a subscription callback is received by the subscription server, which then generates the CAPTenant custom resource object.
The subscription server returns an Accepted (202) response code and starts a routine/thread, which keeps polling for the tenant status until the changes to the CAPTenant are then independently reconciled by the controller.
Once the tenant provisioning process has completed (or has failed), the tracking routine will return the appropriate status to the SaaS Registry via an asynchronous callback (by obtaining the necessary authorization token).
(More details about asynchronous tenant subscription.)
Such an asynchronous processing allows us to avoid timeouts during synchronous calls, as well as schedule dedicated jobs (via CAPTenantOperation) for completion of the subscription and perform any further tasks required in the cluster (for example, create a VirtualService corresponding to the tenant subdomain).