Image Source

What is a Service Mesh?

A service mesh is a tool that brings reliability, security, and observability features to applications. It inserts such features at the platform layer rather than the application layer. 

The service mesh consists of a scalable collection of network proxies deployed along with the application code. They constitute the mesh’s data plane and are collectively controlled through its control plane. These proxies handle communication between microservices.

The service mesh model has become popular as cloud native applications have gained more traction. Such applications can have hundreds of services, and each service can have hundreds of instances. In such a scenario, service-to-service communication is complex yet crucial for the application’s runtime behavior. Hence, managing it is important for better performance, security, and reliability.

What is SAP Kyma?

SAP Kyma is an open source project consisting of a set of projects united to simplify the integration and extension of monolithic software. It is built on top of Kubernetes technologies. The involved projects target needs related to important backend aspects like:

• microservice architecture
• authentication
• logging
• monitoring
• event consumption

Additionally, through its service catalog, you can connect to cloud services made available by public cloud providers. You can connect to these services using open service brokers or the services you have connected to Kyma through the application connector. Through this connector, you can connect to any application and expose its events and secure your APIs.  

One use case is that you can use a connected application’s events and trigger microservices or serverless functions without worrying about its dependencies. Additionally, you can use a connected system’s APIs to integrate different systems or extra information related to an event’s flow. Finally, you can expose the microservices and the serverless functions to other applications.  

Kyma Service Mesh Features

Communication between services, proxying, service discovery, traceability, and security are all accomplished by Kyma Service Mesh. Istio’s open platform is used by Kyma Service Mesh to provide the above functionality.

Kyma Dex, a Service Mesh component, integrates any OpenID Connect-compliant or SAML2-based enterprise authentication server with the application. Kyma employs Kiali to allow validation, observe Istio Service Mesh, and offer information about microservices containing the Service Mesh and their relationships.

The following are some of the features of Service Mesh:

Security

As discussed earlier, mutual TLS is enabled across the cluster in a STRICT mode. As a result, users can rest assured that only the workload will accept only encrypted traffic between a client and a server validated by both parties’ certificates. In addition, it ensures the security of each service’s identification by utilizing a trusted system for managing keys and certificates.

Having a sidecar proxy allows the user to request authentication for the service, which is a further step toward ensuring the safety of the network. In addition, the use of a customized authentication provider is made possible by Istio’s support for request authentication with jwt, known as json web token validation.

Observability

Istio generates various kinds of telemetry to give service mesh observability, such as Kiali and Kyma. Kiali is a tool available as a standalone Kyma component. Kyma configures Istio to produce the metrics required to support Kiali capabilities that simplify maintaining, visualizing, and debugging the service mesh.

Kyma offers Grafana dashboards that are Istio-specific for the component’s monitoring. In addition, workload and mesh control plane visibility is improved when combined with metrics provided by the Istio sidecar. All of these significant observability features are made available by the Istio service mesh, which would only be achievable with the instrumentation code in the program.

Traffic Management

Traffic management is a crucial component of a service mesh. No configuration is needed for this traffic management if the sidecar is injected into all workloads. 

Developers can employ methods like canary releases and A/B testing to improve the speed and consistency of software releases when they take advantage of traffic shifting or request routing. Mirroring or fault injection can be used for testing and auditing to increase the robustness of the applications.

Resiliency

The resilience of applications is a fundamental problem within traffic management. Application libraries have historically implemented resilience mechanisms like timeouts, circuit breakers, and retries. On the other hand, service mesh allows outsourcing such activities to mesh itself, with compatible configuration options across languages.

Configuring Kyma with Istio Service Mesh

To deliver its service mesh functionalities, Kyma uses Istio Service Mesh, customized to the implementation’s specific needs. Kyma Service Mesh’s primary principle is to inject every service’s pods with the Envoy sidecar proxy. Envoy intercepts inter-services communication and regulates it by applying and enforcing the destination rules. 

You can manage mTLS traffic at a Namespace level or in services by creating the appropriate DestinationRules and Peer Authentications. Hence, if sidecar injection is disabled in a service or Namespace, you must manage the traffic configuration by creating the destination rules and peer authentications.

You can install Istio in Kyma using the istioctl tool. A configuration file containing an IstioOperator custom resource’s instance drives the istioctl tool. Here are the configuration changes for customizing Istio to work with Kyma:

• Both the Istio data and control plane use distroless images.
• Automatic sidecar injection is disabled by default.
• Resource requests and limits associated with Istio sidecars are changed to fit the needs of evaluation and production profiles.
• Mutual TLS is enabled across the cluster in a STRICT mode.
• Global tracing is configured to use the Zipkin protocol for sending requests to Kyma’s tracing component. 
• Ingress Gateway undergoes expansion and handles the following ports for Kyma deployments:
  • 31400
• HTTP 1.0 is enabled in outbound HTTP listeners through the PILOT_HTTP10 flag in the Istiod component’s environment variables.
• IstioOperator’s configuration file is modified, and Kyma settings are changed to customize the configuration.

Conclusion

In this article, I explained the basics of SAP Kyma and how it works with the Istio service mesh solution. I covered the basic service mesh features you can leverage with Kyma and Istio, and showed the main configuration parameters required to configure these solutions to work together. I hope this will be useful as you level up your SAP Kyma networking and security capabilities.