Introduction
As you may already know, SAP Automation Pilot is innovatively designed to iron out operational complexities within SAP BTP solutions. Perfectly compatible with the SAP Neo ecosystem (although a multi-cloud account is necessary for utilization), its contribution extends to Cloud Foundry end customers too, offering significant value and operational ease.
SAP BTP now looks towards Kubernetes as a cutting-edge platform which is able to address the major challenges within SAP Neo and Cloud Foundry. Human operators who run workloads on Kubernetes often aim to automate repeatable administrative tasks. In the world of Kubernetes, automation takes the form of Kubernetes operators representing the idea of writing code to automate a task beyond what Kubernetes itself provides.
Recognizing this, SAP Automation Pilot is set to offer customers an opportunity to create and execute Kubernetes operators, leveraging the same user-friendly low-code/no-code tools already available in our service for alternate environments. Essentially, the SAP Automation Pilot operator concept for Kubernetes puts an end to developing custom and intricate operators for Kubernetes.
What are Kubernetes operators?
To answer this question, you first need to learn what a custom resource is:
A custom resource is an extension of the Kubernetes API that is not necessarily available in a default Kubernetes installation. It represents a customization of a particular Kubernetes installation.
An operator is a custom Kubernetes controller manager that uses custom resources to manage applications and their components. High-level configuration and settings are provided by the user within a custom resource.
The Kubernetes operator translates the high-level directives into the low-level actions, based on best practices embedded within the operator’s logic.
Kubernetes Operators in a Nutshell
Operators in SAP Automation Pilot
The Kubernetes operators, in nature, are very similar to the SAP Automation Pilot commands:
- They are stateless and require a structured input to work.
- Everything is executed asynchronously, whenever there are available resources.
So, the SAP Automation Pilot team decided to advance towards providing its customers with the ability to design and implement Kubernetes operators without the need to understand the Kubernetes mechanics or write code of varying complexity (usually using Go as a programming language). Now they just need to create SAP Automation Pilot k8s-related commands replacing the time-consuming effort of writing custom and complex operators for Kubernetes. What else? Of course, these commands can be applied with ease.
SAP Automation Pilot – Native Integration within Kubernetes
Proposed Solution
Furthermore, SAP Automation Pilot designed a custom Kubernetes operator called a remote work processor. It is written in Go and communicates with both Kubernetes and SAP Automation Pilot. The remote work processor is a full-blown operator, as far as Kubernetes is concerned, but its orchestration logic happens inside the SAP Automation Pilot backend. In summary, this capability is designed to make Kubernetes think an SAP Automation Pilot k8s-related command is a Kubernetes operator.
By introducing the remote work processor as a custom Kubernetes operator, SAP Automation Pilot can now act as a native actor within the Kubernetes cluster, performing tasks and sending results back to the SAP Automation Pilot backend. And you do not have to worry if your Kubernetes cluster is behind a firewall and its endpoints are not available on the Internet. Thanks to this specific configuration, the communication is intentionally inverted from the custom Kubernetes operator to the SAP Automation Pilot backend. Entirely controlled by customers, the remote work processor itself executes HTTP requests and scripts with whatever credentials and admin privileges it is given access to. This avoids the exposure to any additional security risks, for example the credentials do not leave the private environment.
SAP Automation Pilot – Remote Work Processor Overview
Once the remote work processor is onboarded, the customer can:
- Manage the operator entities to model Kubernetes-specific scenarios.
- Generate Kubernetes manifests for their operator entities.
- Deploy the Kubernetes manifests in their own Kubernetes clusters with no additional changes (although they are possible and encouraged).
- Manage the active sessions of each deployed operator.
- Execute the SAP Automation Pilot commands based on Kubernetes reconciliation events.
A reconciler is an entity that defines the behavior of a single reconciliation loop. It describes the Kubernetes entities that must be observed (identified by their apiVersion, kind, namespace, and labels) and the task that must be performed on the desired state (represented by the SAP Automation Pilot commands).
A session is a transient entity that represents an active connection between a remote work processor and the SAP Automation Pilot backend. It contains metadata and various health information related to the connection. Each session has a unique identifier of the form <TENANT>-<OPERATOR-NAME>:<ENV>:<INSTANCE-ID>. It prevents collisions and allows multiple remote work processors from the same or different Kubernetes clusters to connect to the Kubernetes operator:
- TENANT – the ID of the tenant, for example T000000
- OPERATOR-NAME – the name of the operator that the remote work processor connects to.
- ENV – the environment provided to the remote work processor during its setup. The value is chosen by the tenant.
- INSTANCE-ID – the unique identifier of the Kubernetes worker pod. It uses the Kubernetes object UID which is unique across the whole cluster.
How can customers build secure Kubernetes operators in a local session via SAP Automation Pilot?
This new functionality is now available in the SAP Automation Pilot UI and every existing or future customer tenant can take advantage of it in case of Kubernetes-specific scenarios or use-cases.
The remote work processor itself is an open-source component that is freely available and consumable from the public artifact repositories – github.com or docker.io. Customer tenants do not need any additional licenses and entitlements to consume it except having an active SAP Automation Pilot subscription (either free or standard plan).
It is easy to configure the remote work processor and your desired k8s-related commands, as well as design their behavior via the SAP Automation Pilot UI.
Conclusion
Simplifying the development of the Kubernetes operators is nothing less than an opportunity to enable our SAP customers to receive more value, compared to the users of a typical Kubernetes ecosystem.