Kubernetes cluster with an Istio service mesh

This article shows the architecture of a small Istio service mesh with only one Airlock Microgateway-protected web application deployed in a Kubernetes cluster. Istiod converts the high-level routing rules into Envoy-specific configurations of the Envoy proxies that are deployed as sidecars. These Envoy sidecars are injected into each Pod forming the Istio data plane.
However, in Airlock Microgateway, the Microgateway Operator Pod is not a typical manageable web application but a technical component that manages the Microgateway functionality. Hence, the Microgateway Operator does not need to be maintained by the Istio control plane.

The simple example shows a setup with a service mesh of a single web application, the Microgateway Operator and the Istiod Container in a single Node. In the Web application Pod the Microgateway Engine and the Istio-proxy/Istio-init are injected as sidecars.

• Namespaces in our example:
• istio-system working as the Istio control plane.
• airlock-microgateway-system with the Microgateway Operator Pod, which is not part of the service mesh (no Istio proxy sidecar).
• application with a web application secured by Airlock Microgateway and part of the service mesh (with Istio proxy sidecar).
• kube-system used for system processes, i.e., to install a Microgateway CNI plugin in Airlock Microgateway Nodes. This Namespace is not part of the Istio service mesh.

Within the Kubernetes cluster, the Microgateway Operator Container is responsible for injecting and configuring the Airlock Microgateway Containers, i.e., the Microgateway Engine in the Web application Pods. For operating Airlock Microgateway in an Istio setup, the sidecar injection is triggered by a sidecar.microgateway.airlock.com/serviceMesh: "istio" annotation, which must be added to the Pod definition.

1. A Web client wants to access the Web application. The request is sent to the Istio Ingress controller of the Kubernetes cluster.
2. The Istio Ingress controller accepts the traffic from outside the cluster and forwards it to the Web application Service.
3. The Web application Service forwards the traffic to the Web application Pod.
   The traffic routing configuration inside the Web Application Pod is as follows:
• Istiod injects the istio-init Container, which reconfigures the Pod's network to route all traffic to the Istio proxy.
  (Istio can also be operated with a CNI plugin instead of the istio-init container.)
• The Microgateway CNI plugin reconfigures the Pod's network behind the istio proxy to route the traffic from the istio proxy to the Microgateway Engine Container and finally to the web application.
4. The Microgateway Engine Container writes logs to /dev/stdout. A logging service can collect and visualize these logs in a graphical reporting solution.
5. The Prometheus Pod scrapes metrics from the Microgateway Engine Containers that can be visualized e.g., using Grafana.

1. The Microgateway Operator reads its configuration from the Microgateway Operator Configuration at startup and watches for events such as Pod create, update or delete.
2. When a Web application Pod is created with a sidecar.microgateway.airlock.com/inject annotation, two things happen:
• The Microgateway Operator injects the Microgateway Engine container.
• The Microgateway CNI plugin configures the routing within the Web application Pod so that all traffic is led through the Microgateway Engine.
3. The CustomResource SidecarGateway includes a podSelector that selects the group of Pods to which the configuration applies.
4. The CustomResource SidecarGateway refers to other resources that should be applied.
5. The Microgateway Operator reads the involved configuration and sends it to the Microgateway Engine.
6. The Microgateway Operator watches the Microgateway Engine configuration resources. If these resources have been altered, the Microgateway Operator sends an update to the Microgateway Engine with the new configuration.
7. The Microgateway License Guard is configured by the Microgateway Operator, depending on the current license. The License Guard monitors the traffic of Microgateway Engine Pods and can enforce threshold limits.

1. The Istiod provides service discovery, configuration and certificate management for the injected Istio proxy sidecars. The Istiod contains Pilot, Citadel and Galley components that form the Istio control plane.
2. The Istio proxy sidecars transparently route the traffic from and to the Microgateway Engine. These proxy sidecars are part of the Istio data plane.

• External links:
• Istio architecture