[What’s new with Kyma 2.0] – Installing your own Components


Disclaimer: This blog post focuses on Kyma runtime version 2.0 on SAP BTP. Keep in mind that adjustments might be needed at a higher release of Kyma.

What happened until now 

Until the advent of Kyma 2.0 the managed Kyma offering on SAP Business Technology Platform (SAP BTP) came with some restrictions concerning the access on Kubernetes layer. While Kyma 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 Kyma 2.0 on SAP BTP – you now have many more degrees of freedom, but they come at a price as you will see.  

What’s new with Kyma 2.0

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 Kyma on SAP BTP 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 incident? Kyma 2.0 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. So maybe the reconciler cannot fix the corrupted setup, well 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/) which provides great capabilities to your cluster. Technically this is done via side-cars that get injected to 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 of 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 
  • Install your component into the namespace 

The Istio control plane will respect the labeling and will not do any side-car-injections into the namespace (for more details see e.g. https://istio.io/latest/blog/2019/data-plane-setup/). 

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.

Overlapping Concerns 

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  

Walk Through 

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. 

Other Components 

I also tried to install KEDA (https://keda.sh/) 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 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.