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 example illustrates a simple setup with a service mesh of one web application, the Microgateway Operator and the Istiod container. The Web application container has the Microgateway Engine and the Istio proxy injected as sidecars.

• The three namespaces are:
• 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).

Within the Kubernetes cluster, the Microgateway Operator container is responsible to inject and configure the Airlock Microgateway containers in the Web application Pods. This means, injecting the Microgateway Network Manager init container and Microgateway Engine container as sidecars to the Web application container. For this to happen, the Microgateway Operator protects the Web application Pod based on annotations like sidecar.microgateway.airlock.com/... at the time of deployment.

1. A Web client wants to access a 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.
   Inside the Web application Pod, the traffic is received first by the Istio proxy and then forwarded to the Microgateway Engine container, which applies the configured routes to the incoming traffic before forwarding it to the Web application container.

• Istiod has injected the istio-init container as an init container, which reconfigures the Pod's network. This is why the traffic is first routed to the Istio proxy (Istio can be operated also with a CNI plugin instead of the istio-init container. If so, the network will be reconfigured through the CNI plugin and there is no istio-init container. All the rest of the documentation still applies.)
• Because the Microgateway Network Manager is injected as an init container, which reconfigures the Pod's network, it is ensured that all traffic is first routed to the Istio proxy and afterwards to the Microgateway Engine container. Finally, the traffic will be forwarded to the web application.
• When operating Airlock Microgateway in a Istio setup, the annotation sidecar.microgateway.airlock.com/serviceMesh: "istio" must be added to the Pod definition.
4. The Microgateway Engine container writes logs to /dev/stdout. These logs can be collected by a logging Service and e.g. visualized 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. The Microgateway Operator knows based on the annotation microgateway.airlock.com/inject which Pods the Airlock Microgateway containers should be injected.
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 which 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. In case these resources have been altered, the Microgateway Operator sends an update to the Microgateway Engine with the new configuration.

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 together 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