# Service Mesh

> Using Istio's Service Mesh Features

---

Site [llms.txt](/llms.txt)

---

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](https://istio.io/latest/about/service-mesh/):

> 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 is[Istio's own documentation](https://istio.io/latest/docs/).

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:

```yaml
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](https://istio.io/latest/docs/tasks/security/authentication/authn-policy/#enable-mutual-tls-per-namespace-or-workload).

## 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](https://zivgitlab.uni-muenster.de/wwu-it/kube/examples/-/tree/main/egress).

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