Skip to main content

kubernetes-on-premise

Prerequisites​

This guide assumes you have both the Transparent Proxy (version >= 1.4.0) and Connectivity Proxy (version >= 2.11.0) installed in your cluster. For Kyma the Transparent Proxy is available as a module that can be enabled as described here. The Connectivity Proxy can be installed as described here.

Background Information​

When using the Transparent Proxy your app performs requests against the Transparent Proxy without explicit authentication, relying on the secure network communication provided by Kyma via Istio. The Transparent Proxy will obtain the relevant destination from the destination service and use it to forward the request via the Connectivity Proxy to the On-Premise system. Consequently, your app itself does not interact with destination or connectivity service at all and thus your application pods do not require bindings to these two services.

Please note that the current implementation of the Transparent Proxy does not yet cover all use cases.

Constraints when using the Transparent Proxy
  • Private Link not yet supported
tip

This approach is conceptually different from what you may be used to from a Cloud Foundry environment. The official documentation of the Transparent Proxy gives more information on the architecture.

Create a Kubernetes Resource​

For the creation of the necessary Kubernetes Resources, please refer to our Java documentation.

Executing Requests​

In your application you can now configure a destination to execute requests:

import {
  registerDestination,
  getTenantId,
  retrieveJwt
} from '@sap-cloud-sdk/connectivity';

const destination = {
  name: 'registered-destination',
  url: 'http://my-destination.namespace/'
  // for principal propagation make sure to set the forwardAuthToken flag to true:
  // forwardAuthToken: true
};
await registerDestination(destination, options);

const result = await myEntityApi
  .requestBuilder()
  .getAll()
  // for a subscriber tenant make sure to send the tenant header:
  // .addCustomHeaders({ 'X-Tenant-Id': getTenantId(retrieveJwt(request)) })
  .execute({ destinationName: 'registered-destination' });
// for principal propagation make sure the send the auth token:
// .execute({ destinationName: 'registered-destination', jwt: retrieveJwt(request) });
  • Replace namespace in the URL with the namespace you installed the Transparent Proxy into.

The code above shows an example how you can then use the destination object to perform an OData request against the system.

Connecting to Cloud systems

The above approach is not limited to destinations of proxy type ON_PREMISE, INTERNET destinations are supported as well.

Troubleshooting​

When using proxy servers it can be difficult to troubleshoot issues as it is often not obvious where exactly the error occurred. For example, with the Transparent Proxy errors might occur on the target system (e.g. OData service), the Destination Service or the Transparent Proxy itself.

To make troubleshooting easier the Transparent Proxy adds additional response headers to provide more information about where an error occurred. For the above example of executing OData requests you can access the response headers as follows:

const result = await myEntityApi
  .requestBuilder()
  .getAll()
  .execute('registered-destination')
  .catch(err => {
    console.error('Error Headers:', err.rootCause?.response?.headers);
  });
List of headers added by the Transparent Proxy
  • X-Error-Origin - the source of the error
  • X-Proxy-Server - the proxy server (Transparent Proxy)
  • X-Error-Message - thorough error message
  • X-Error-Internal-Code - set only when the source of the error is the XSUAA or Destination service. The value is the HTTP code returned from one of these services.
  • X-Request-Id is sent with the response in all requests, both successful and failed