Kubernetes cluster without a service mesh

This article shows the architecture of a web application deployed in a Kubernetes cluster and protected by Airlock Microgateway. This example illustrates the setup if no service mesh is used. This is the most simple functional setup – with Airlock Microgateway injected which secures a single Web application container. The setup shows two namespaces, one for the Microgateway Operator Pod and a second one with the Web application Pod.

The Microgateway Operator container injects the Microgateway Engine Container into web application Pods annotated with sidecar.microgateway.airlock.com/inject: "true". The Operator configures the Engine based on Custom Resources that contain the Engine configuration.

1. A Web client wants to access the Web application. The request is sent to the Ingress controller of the Kubernetes cluster.
2. The Ingress controller accepts the traffic from outside the cluster and forwards it to the Kubernetes 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 Microgateway Engine container, which applies the configured routes to the incoming traffic before forwarding it to the Web application container.


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 Microgateway Engine container.

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 sidecar.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.