Architectures of K8s Gateway API-based sidecarless mode installations

The articles of this chapter address the sidecarless Airlock Microgateway installation and deployment forms with one or more Microgateway Engine Pods deployed using the K8s Gateway API. Each Microgateway Engine Pod can route traffic (i.e. defined in HTTPRoute resource) to multiple Services and application Pods. Unlike in sidecar-based Microgateway deployments, the routing inside the application Pods is not reconfigured – a Microgateway CNI plugin is therefore not required.

The Kubernetes Gateway API is a Kubernetes API specification defining a standard way to configure and manage application traffic routing in Kubernetes clusters. It becomes a superset of the classic Kubernetes Ingress functionality with powerful and granular control, including expanded protocol support and routing options. For more information, see the official Kubernetes Gateway API documentation.

East-west traffic

East-west traffic is traffic from server to server within a data center, i.e. within a cluster. East-west traffic works just as well with classic Ingress or an Airlock Microgateway with K8's Gateway API for ingress traffic. The traffic is directly routed through the Microgateway Engine.

East-west-traffic

North-south traffic

North-south traffic is traffic from outside a cluster into a cluster and vice versa. Depending on your requirements and preferences, north-south traffic may be based on one of the following basic setups using Airlock Microgateways.

Solution with dedicated Microgateways per namespace and a classic Ingress controller

Solution with a shared Microgateway as an Ingress controller

North-south traffic with classic Ingress controller
North-south traffic with Gateway API for ingress
  • Independent Airlock Microgateways for strong isolation:
    • Isolated session handling per Namespace.
    • Suitable for multi-tenant requirements.
  • Suitable for heterogeneous Namespaces for mixed clusters where an Airlock Microgateway may not always be required.
  • Upstream traffic routing is managed by the Ingress controller.
  • Shared Airlock Microgateway for ingress traffic:
    • Secure external traffic by default.
    • A shared Microgateway deployment is easy to maintain.
    • Scaling is independent of the number of application Namespaces.
    • Application Namespaces with north-south traffic only require an HTTPRoute resource pointing to the shared Gateway resource.
    • Application Namespaces with combined north-south and east-west traffic require an additional sidecarless Microgateway deployment (within the application Namespace) to secure the east-west traffic.
  • Upstream traffic routing is managed by the shared Microgateway and distributed HTTPRoute resources.

For sidecar-based deployments with Ingress controller and CNI plugin, see articles in chapter Architectures of sidecar-based mode deployments.

Management roles and responsibilities

The Kubernetes Gateway API features a concept of three distinctive roles to address the differing needs of the users to balance usability, flexibility, and control.

  • The following primary roles have been defined:
  • The Infrastructure provider manages the GatewayClass resource.
  • The Cluster operator manages the Gateway resource and may define cluster-wide routing limitations for xRoute resources such as HTTPRoute.
  • Developers manage the routing by *Route resources such as HTTPRoute and of course, they also manage their application Services and Pods.
K8S_Gateway_API_management_roles_en-us.drawio

Depending on the environment, a single human may take on multiple roles.

Sidecarless without a service mesh

This article shows the architecture of a web application protected by Airlock Microgateway using the K8s Gateway API, deployed in a Kubernetes cluster. The example illustrates the setup without service mesh. It is the most simple functional sidecarless setup – with a single Microgateway Engine Pod securing Web application containers. The setup shows two namespaces, one for the Microgateway Operator Pod and a second one with the Microgateway Engine and Web application Pods.

Kubernetes deployment of Airlock MGW with Gateway API.drawio

Traffic handling

  1. A Web client wants to access the Web application. The Service of type LoadBalancer works as a single outward-facing endpoint and exposes the Microgateway Engine to ingress traffic.
  2. The Microgateway Engine accepts the traffic from outside and inside the cluster, processes and forwards or blocks traffic according to the configuration set in the CR ContentSecurityPolicy and CR AccessControlPolicy.
  3. The Microgateway Engine forwards traffic to the Web application Service as configured by the Gateway and HTTPRoute CRs.
  4. The Microgateway Engine deployment writes logs to /dev/stdout. A logging service can collect and visualize these logs in a graphical reporting solution.
  5. The Prometheus deployment scrapes metrics from the Microgateway Engine containers that can be visualized, e.g., using Grafana.

Configuration handling

  1. The Microgateway Operator read its configuration from the Microgateway Operator Configuration during startup.
  2. The Microgateway Operator watches for new or changed GatewayClass, Gateway, HTTPRoute, and other K8s Gateway API resources.
  3. New Gateway resources trigger the Microgateway Operator to deploy Service(s) and Microgateway Engine deployments. The K8s Gateway API configuration is generated based on different resources:
    • The GatewayClass resource represents the class of gateway (here: Airlock Microgateway) that can be instantiated.
    • The Gateway resource represents precisely the deployment of a Microgateway. It specifies the target namespace, the hostnames, ports, protocol, downstream TLS settings, and which routes can be attached to a listener.
    • The HTTPRoute (or other future supported Route CRs) resources contain routing configurations between the Airlock Microgateway and the web application service so that traffic is routed through the Microgateway Engine as configured. Airlock Microgateway uses a security-by-default strategy and applies built-in security measures to all routes.
  4. If one of the K8s Gateway API resources has been altered, the Microgateway Operator updates the Microgateway Engine with the new configuration.
  5. CRDs for custom configurations like DenyRules, Limits, etc., and the ContentSecurityPolicy are optional.
    • The ContentSecurityPolicy and AccessControlPolicy are Direct Attached Policies extending the K8s Gateway API resources – this allows custom deny rules, limits, authorization/access control and other settings to be added.
    • The GatewayParameters defines the configuration settings for deploying a Gateway in a Kubernetes cluster, including options for logging, service type, deployment strategy, and resource management. It can be referenced by either a GatewayClass or a Gateway.
  6. If one of the optional Microgateway resources has been altered, the Microgateway Operator updates the Microgateway Engine with the new configuration.