Hide navigation

Service Mesh


Kyma Service Mesh is the component responsible for service-to-service communication, proxying, service discovery, traceability, and security. Kyma Service Mesh is based on Istio open platform. The main principle of Kyma Service Mesh operation is the process of injecting Pods of every service with an Envoy - a sidecar proxy which intercepts the communication between the services and regulates it by applying and enforcing the rules you create. Kyma Dex, which is also a part of the Service Mesh, allows you to integrate any OpenID Connect-compliant identity provider or a SAML2-based enterprise authentication server with your solution.

See this Istio diagram to understand the relationship between the Istio components and Services.

Sidecar Proxy Injection

By default, the Istio sidecar injector watches all Pod creation operations on all Namespaces and injects the newly created Pods with a sidecar proxy.

You can disable sidecar proxy injection for either an entire Namespace or a single Deployment.

  • To disable sidecar proxy injection for a Namespace, set the istio-injection label value to disabled for the Namespace in which you want to disable the sidecar proxy injection. Use this command: kubectl label namespace {YOUR_NAMESPACE} istio-injection=disabled
  • To disable sidecar proxy injection for a Deployment, add this annotation to the Deployment configuration file: sidecar.istio.io/inject: "false"

Read the Installing the Sidecar document to learn more about sidecar proxy injection.

Istio patch

As a core component, Istio installs with every Kyma deployment by default. The installation consists of two steps:

  1. Istio installs using the official, raw charts from the currently supported release. The charts that are currently used are stored in the resources/istio directory. The installation is customized by enabling security in Istio.

NOTE: Every installation of Istio for Kyma must have security enabled.

  1. A custom Istio patch is applied to further customize the Istio installation. A Kubernetes job introduces these changes:
  • Sets a memory limit for every sidecar.
  • Modifies Istio components to use Zipkin in the kyma-system Namespace, instead of the default istio-system.
  • Adds a webhook to the Istio Pilot.
  • Creates a TLS certificate for the Ingress Gateway.
  • Deletes all resources related to the prometheus, tracing, grafana, and servicegraphcharts.
  • Enables sidecar injection in all Namespaces, except those labeled with istio-injection: disabled.

To learn more about the custom Istio patch applied in Kyma, see the components/istio-kyma-patch/ directory.

Use an existing Istio installation with Kyma

You can use an existing installation of Istio running on Kubernetes with Kyma. The custom Istio patch is applied to such an installation.

NOTE: You cannot skip applying the Istio patch in the Kyma installation process.

To allow such implementation, you must install Kyma without Istio. Read this document for more details.

Istio RBAC configuration

As a core component, Istio is installed with Kyma by default. The ClusterRbacConfig custom resource (CR), which defines the global behavior of Istio, is created as a part of the installation process.

The default Istio RBAC configuration is defined in this file.

Override the default configuration

To override the default configuration of Istio RBAC, edit the ClusterRbacConfig CR on a running cluster. This CR is created in the kyma-system Namespace and therefore requires admin permissions to edit it.

To show the current Istio RBAC configuration in the yaml format, run:

Click to copy
kubectl get -n kyma-system clusterrbacconfig -o yaml

To edit the Istio RBAC configuration, run:

Click to copy
kubectl edit -n kyma-system clusterrbacconfig

NOTE: The ClusterRbacConfig object is a singleton, which means that only a single object of this kind can exist in a cluster. Additionally, the only valid name for the object is default. As such, the best way to customize Istio RBAC is by editing the existing ClusterRbacConfig object.