Extending on-premise systems via Kyma runtime

[jamie_cawley]

With the latest release of Kyma, connectivity to on premise systems can now be achieved using the SAP Cloud Connector. Running as an on-premise agent, the SAP Cloud Connector provides a secure tunnel to connect SAP BTP applications and on-premise systems. This is accomplished by using the Connectivity Proxy which is a software component deployed into the Kyma Cluster that interacts with systems exposed by the SAP Cloud Connector.

The provisioning of the Connectivity Proxy is handled by the Kyma Control Plane which is a component that manages Kyma runtimes. Once the creation of a service instance and service binding of the Connectivity Proxy is detected by the Kyma Control Plane, the Connectivity Proxy will be provisioned in the runtime into the namespace kyma-system. From within the Kyma runtime it will be accessible using the URL connectivity-proxy.kyma-system.svc.cluster.local:20003.

You can find the configuration details as well as an example application in the connectivity-proxy folder of the Kyma Runtime Extension Sample repo. The help documentation can also be found here.

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. 

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.

[LuizGomes]

Is your example expected to work with a SAP S/4HANA ?

[jamie_cawley]

The connectivity proxy can be used to connect to an on premise S4HANA system, but the example uses a locally running nodejs app.

Regards,

Jamie

[LuizGomes]

Do you have any examples of a connection to S4 using nodesjs? Similar to your example but a scenario a little closer to reality.

[quovadis]

Hello

you could take a look at this https://blogs.sap.com/2022/04/07/veridisquo.-reaching-sap-lob-destinations-with-connectivity-proxy-a...

I hope that helps

[jamie_cawley]

This is for S4HANA Cloud, but same principle would apply

https://github.com/SAP-samples/kyma-runtime-extension-samples/tree/main/s4hana-materialstock-functio...

Regards,

Jamie

[LuizGomes]

Thanks for your reply, it was exactly what I needed and it worked. A very simple approach. Thanks for the article. An unusual thing happened, the database that is in the same cluster and in the same namespace reset, the data was lost. after the command: kubectl label namespaces <your namespace> istio-injection=enabled, the namespace is the default. Did it already happen to you?

[LuizGomes]

Thanks for your answer, I have scenarios with the SDK and I'm going to test them. I noticed that you don't create a connectivity_proxy service, is that right? And even for PUT and POST does something change in this example?

[quovadis]

Hello 015454888556565665685989,

OK. Glad my article was of help you; kind regards;Piotr

PS.

What was the reason you had to enable istio for your default namespace? How many nodes does your cluster have? More than one ?

Re your database; is it your postgres deployment ? does it have a pvc? if yes, a pvc (it is a pod as well) should be still there (you can check it is present using kyma dashboard or kubectl); Please let us know;

[LuizGomes]

What was the reason you had to enable istio for your default namespace?

R: Follow this guide: https://github.com/SAP-samples/kyma-runtime-extension-samples/tree/main/connectivity-proxy

 

How many nodes does your cluster have? More than one ?

R: One

 

is it your postgres deployment ? does it have a pvc?

R: Yes the postgres pod is there. As well as the pvc that is connected to it. but the databases disappeared on Friday after that command and today again.

 

As it is in dev it has no impact. I'm trying to understand if it was this command or some kyma update, because even the access roles are gone.

[quovadis]

Ok Now I recall your postgres bit as you are using LB  to access the postgres service you must not have istio enabled for its deployment; you can annotate istio out in your postgres deployment, restart it and it should go back to normal

I hope that helps

[LuizGomes]

So the istio is enabled for the entire Default namespace but not for the postgres deployment, right? I need to understand what impact this label can have. If I disable the default namespace will the connection to the cloud connector stop working as well?

[quovadis]

Hello,

The bottom line is you are using a LB for your postgres service. Thus you need take istio out from its deployment....

Why don't you go back to the answer I have already given you on this ? I hope that helps; Piotr

PS. You indeed require istio enabled when using the connectivity proxy; so the "easiest" is to have istio disabled for your postgres deployment via the deployment annotation mechanism,  or alternatively, you could keep your postgres deployment in a dedicated namespace where istio injection is disabled for the namespace (that's a default behaviour when creating a new namespace with kyma dashboard)

[jamie_cawley]

That example is for the cloud, so there is no need for the cloud connector/connectivity proxy. They would be needed for a on premise/private cloud scenario.

Jamie

[v_sathish16]

Thanks for this blog,we have a requirement as below:

SAP -> SAP CC -> KYMA-Endpoint

we want to use the SAP CC to call a secured APIRule in our SAP BTP Kyma environment so  that we do not go over the unsecured internet.

Do you know how and  any document to refer to?we have the following specific question:

We expect that we need to configure a Kubernetes Clsuter for this in the SCC:

But where can we find the URL and the service URL needed for the configuration in the KYMA environment?

Regards,

Sathishkumar V

[korayyersel_q]

Hi jamie.cawley

simple and easy to understand example, thanks a lot. I have deployed the three YAML files from the gitrepo. For the first ca. 10 minutes the curl call responds with

"Couldn't resolve proxy 'connectivity-proxy.kyma-system.svc.cluester.local'"

after that it turns to

"Failed to connect to connectivity-proxy.kyma-system.svc.cluster.local port 20003: Connection refused"

After that I wanted to simplify my test deployment to rule out any errors. Here is what I did:

1. Create Kyma Environment (free plan)


2. Deploy only https://github.com/SAP-samples/kyma-runtime-extension-samples/blob/main/connectivity-proxy/k8s/conne...


3. Create interactive pod:
   

   kubectl run curl --image=radial/busyboxplus:curl -i --tty

   
   


4. And try to curl my on-premise endpoint:
   

   curl --proxy http://connectivity-proxy.kyma-system.svc.cluster.local:20003 http://localhost:xxx

   
   


5. Here is the result
   
   
   
   • For the first 10 Minutes "Couldn't resolve proxy 'connectivity-proxy.kyma-system.svc.cluester.local'"
   
   
   • After that "Failed to connect to connectivity-proxy.kyma-system.svc.cluster.local port 20003: Connection refused"
   
   
   • And now after waiting over the weekend "Recv failure: Connection reset by peer"
   
   
   
   

I don't see anything happening on the cloud connector side. It is a local CC installation. But the curl call doesn't reach it. Is there any change to trace/monitor the proxy? I have a feeling that something is wrong with the connectivity proxy/binding.

Best Regards,

Koray

[jamie_cawley]

Do you see the connectivity proxy pod running? You can check with

kubectl get pod connectivity-proxy-0 -n kyma-system

[korayyersel_q]

Hi Jamie,

thanks for the quick reply. Right after I have posted my question I found this help page: https://help.sap.com/docs/CP_CONNECTIVITY/cca91383641e40ffbe03bdc78f00f681/e7a04d9b30144f40ab0ca3b27.... With the kubectl command

kubectl get pod connectivity-proxy-0 -n kyma-system

I could see the instance. I even switched the log level but actually, it didn't help. I could not even reach the proxy. There were no traces for my curl calls. Anyways after that I wanted to have a clean start. I have deleted the cluster and started from scratch. Now it is working. Either there was a temporaryy issue or I've missed a step. Here is a summary of the steps, that I have taken for the working PoC (maybe it helps someone):

1. Install Cloud Connector locally and connect it with the BTP Subaccount


2. Start a local docker container on port 5050. For example
   

   docker run -ti --rm -p 5050:5050 vad1mo/hello-world-rest​

   
   


3. Make sure that CC exposes localhost:5050 and that the endpoint is reachable.


4. Create Kyma instance and login with kubectl


5. Enable Istio (not sure I have missed this step on my first try)
   

   kubectl label namespaces default istio-injection=enabled

   
   


6. Create connectivity proxy instance
   

   kubectl apply -f .\connectivity-proxy-instance.yaml

   
   


7. Run the following command until the pod is listed. Make sure that the proxy pod is created. This took around 10 minutes in my case
   

   kubectl get pod connectivity-proxy-0 -n kyma-system​

   
    


8. Change the log level to trace more
   

   kubectl exec connectivity-proxy-0 -n kyma-system -it -- connectivity-proxy-operations logging change-log-level DEBUG

   
   


9. Run curl pod
   

   kubectl run curl --image=radial/busyboxplus:curl -i --tty

   
   


10. Try to reach your on-prem endpoint
    

    curl --proxy http://connectivity-proxy.kyma-system.svc.cluster.local:20003 http://localhost:5050

    
    

 

Regards,

Koray

[LuizGomes]

after update to kyma 2.11 statefull/connectivy-proxy not found

[jamie_cawley]

Hi Luiz,

Have you tried to create a new instance of it? If it still does not appear I would suggest creating a ticket so the support team can investigate it.

Regards,

Jamie

[LuizGomes]

Hi Jamie,

 

This generated negative impacts, so we opened a ticket to get a position from the SAP team.

 

It is not possible to do this intervention with each update.

Is it possible to choose when to receive an update in the Kyma runtime?

 

[jamie_cawley]

It is not possible to choose when you receive an update currently, but please share you feedback through the support ticket.

Regards,

Jamie