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.
• The CNI plugin of the Node configures the network routing between Engine and Web application container.

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 Web application Service.
3. The Web application Service forwards the traffic to the Web application Pod.
   In this Pod, all traffic is routed through the Microgateway Engine container and subsequently to the Web application container as configured by the Microgateway CNI plugin.
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.