Service Mesh

For the service mesh in the University of Münster Kubernetes cluster, we utilize Istio. To describe the service mesh, we refer to Istio’s website:

Modern applications are typically architected as distributed collections of microservices, with each collection of microservices performing some discrete business function. A service mesh is a dedicated infrastructure layer that you can add to your applications. It allows you to transparently add capabilities like observability, traffic management, and security, without adding them to your own code. The term “service mesh” describes both the type of software you use to implement this pattern, and the security or network domain that is created when you use that software.

The best source for detailed information about the specific features of the service mesh isIstio’s own documentation.

However, in the following, let’s address some common questions related to the service mesh in the University of Münster Kubernetes cluster.

Adding a Service to the Service Mesh.

To make use of a service within the service mesh, for example, to expose it from the Ingressgateway, the service must first be added to the service mesh.

This is done through the Annotations networking.istio.io/exportTo. The value of this Annotation is a comma-separated list of Namespaces and . represents the own Namespace.

Adding a Pod into the Service Mesh.

To utilize certain functionalities such as mTLS or the Egress gateway, Istio needs control over the traffic of a pod. To achieve this, the pod is equipped with a Sidecar that intercepts incoming and outgoing traffic, thus enabling modifications.

By adding the label sidecar.istio.io/inject: "true" to a pod, Istio recognizes the need for such a Sidecar and adds it when the pod is created.

Using mTLS

To enable mTLS in a Namespace or for a subset of pods within a Namespace Istio’s PeerAuthentication Custom Resource can be used.

The following example enforces mTLS on all Pods in the Namespace:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: example
  namespace: example
spec:
  mtls:
    mode: STRICT

Keep in mind that all pods involved in the communication must now be aware within the service mesh.

For more detailed information about mTLS, take a look at Istio’s documentation.

Using the Egressgateway

If you require precise control over which traffic leaves the cluster, the Istio Egress gateway can be used for that purpose.

We have described the usage of the Egress gateway through several examples.

In most cases, however, the Cilium Routing feature and the Cilium Firewall should suffice.