Until the advent of SAP Business Technology Platform (SAP BTP), Kyma runtime based on open-source Kyma 2.0 the managed came with some restrictions concerning access on the Kubernetes layer. While Kyma runtime per se offers an opinionated stack of components that you do not have to take care about from a management perspective, you could also not break-out of this stack and e.g., install your own components that might have served your use-case very well.
These times are gone with recent updates of SAP BTP, Kyma runtime – you now have many more degrees of freedom, but they come at a price as you will see.
First things first: as you can see in the release notes you have full cluster control. Technically this means that you can do anything in the Kubernetes cluster that you would want to do, from simple configuration to installation of new components. This gives you many desired degrees of freedom and allows you to cover even more use-cases with the fitting component stack.
As SAP BTP, Kyma runtime is a managed offering there are some things you must keep in mind in this context, namely do not touch any resources:
That are labeled "reconciler.kyma-project.io/managed-by=reconciler”
That are living in the "kube-system" namespace
But what happens if you changed some of these components by accident? The update comes with a safe-guarding measure to help you in this context. The so-called reconciliation service of Kyma (https://github.com/kyma-incubator/reconciler) aims to assure that Kyma workloads and configuration are intact and working.This service checks the setup periodically and tries to fix changes to the resources. As you can imagine there are tons of scenarios that could occur and not every single one of them can be anticipated. Perhaps the reconciler cannot fix the corrupted setup. Then you must follow the usual incident process to get your setup corrected.
The baseline (that we all know very well since Spiderman) therefore is: “With great power comes great responsibility” – although Kyma tries to keep you covered.
Technical Heads Up
While everything from a let’s say “legal” perspective is mentioned now, there is one technical aspect you must keep in mind when installing your own components into Kyma.
Kyma is an opinionated stack and not a vanilla Kubernetes cluster. One prominent member of this stack is the service mesh Istio (https://istio.io/)whichprovides great capabilities to your cluster. Technically this is done via sidecars that get injected into the services in the namespaces. While this is intended for your applications that you deploy and run on Kyma, this might not be desirable for components that you deploy to Kyma. At best they do not work at all (yes, I mean that serious, as this is obvious at once), at worst they are kind of running and can cause strange side-effects at spots you would not expect them to (and give you some headache to figure out what is really going wrong).
What is a good approach in case you want to install your own components?
First, read the documentation and troubleshooting guides of the component you want to install in Kyma and check if there are any side-effects with respect to installing the component along with a service mesh in general and with Istio specifically. If you are lucky, you get a concise description of what to do.
Maybe you do not find any hints on the installation alongside Istio, but either your installation failed, or you expect side-effects. What can you do then? Usually new components get installed in a dedicated namespace and this gives you the chance to switch off the Istio-triggered injection of sidecars into the services of the component. The approach is the following:
Create the namespace via kubectl create ns <my-shiny-new-component>
Attach the label “istio-injection=disabled” to the namespace via: kubectl label namespace <my-shiny-new-component> istio-injection=disabled
This is also possible from the new Kyma dashboard. In contrast to the 1.2x release you need to jump to the “advanced tab” and activate the toggle “Disable sidecar injection” (which applies the corresponding label) there as shown in the screenshot:
Of course, this also means that all the functionality of Istio will not be applied to that namespace.
Another aspect you must keep in mind is that some components you want to install can have an overlap in the concerns that they cover. One example of such an overlap is Istio and Dapr when looking at mTLS.
As before, check the documentation of the component you want to install to check such side effects. The mitigation is usually also component-specific and there is no silver-bullet to avoid them
To make things a bit more tangible you find a walk-through the installation of Dapr (https://dapr.io/) including a sample app leveraging Dapr in Kyma. So, if you want to look at code and try it in your Kyma cluster, we have prepared something for you in our SAP samples repository on GitHub
As a side note: If you are suing Visual Studio Code, we have something for your. This sample can be opened as a workspace and contains a CodeTour to guide you through the code. Last but not least there is a dev container available that should support in getting your hands dirty.
I also tried to install KEDA (https://keda.sh/) as event-driven autoscaler into a Kyma cluster. I would not have expected any side effects, but guess what, there are some. In case you want to install KEDA into your cluster (and there are a lot of good reasons why you should), disable the Istio sidecar injection for the namespace you install KEDA into. This will prevent you from having some trouble (… or others in case you install KEDA without that and then leave for the weekend/vacation, not that I would ever do something like that)
Looking forward to your feedback and comments here.
If you have further questions around Kyma, feel free to post them in the answers area of the SAP Community, here is a link.
To stay up to date with everything Kyma, make sure to visit our Kyma topic page.