Gateway deployment

Airlock Microgateway supports the Kubernetes Gateway API. You use Gateway API resources to define a Gateway instance and the reverse proxy specific behavior. In this setup, the Microgateway Operator acts as the Gateway API controller. When you create the CR Gateway, the Operator creates a Deployment and a matching Service that exposes the configured listener ports.

You can deploy your Microgateway in one of the following patterns:

Ingress: Exposed to clients outside the cluster.
In-cluster Gateway: Reachable only from within the cluster.
Both patterns use the same Kubernetes Gateway API resources. The main difference is how the Service in front of the Microgateway Engine is exposed.

For a comparison of the two deployment patterns, see System architectures.

Prerequisites

Airlock Microgateway is installed (see Installation and upgrade).

Configuration

Create the GatewayClass

A GatewayClass represents a class of Gateways managed by a specific controller. The spec.controllerName tells Kubernetes which controller is responsible for reconciling this GatewayClass and all associated resources.

For Airlock Microgateway, spec.controllerName must match the controller name configured for the Microgateway Operator (Helm chart setting). The default value is: microgateway.airlock.com/gatewayclass-controller

Example

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: airlock-microgateway
spec:
  controllerName: microgateway.airlock.com/gatewayclass-controller
  description: GatewayClass for Airlock Microgateway.

Info

When installing the Microgateway Operator via Helm, a default GatewayClass named airlock-microgateway may already be created. If it exists, you can reuse it.

Create the Gateway

A Gateway defines listeners for your Microgateway (ports, protocols, hostnames, and TLS settings). When the Microgateway Operator accepts the configuration, it creates:

A Deployment in the same namespace as the Gateway.
A Service with the same name as the Gateway, exposing the configured listener ports.

Example

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-example
  namespace: example-backend-gw
spec:
  gatewayClassName: airlock-microgateway
  infrastructure:
    parametersRef:
      group: microgateway.airlock.com
      kind: GatewayParameters
      name: gateway-parameters-example
  listeners:
    - name: http
      hostname: "*.example.com"       
      port: 80
      protocol: HTTP
    - name: https
      hostname: "*.example.com"   
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: downstream-server-certificate

You can optionally create a GatewayParameters custom resource in the same namespace as the Gateway and reference it via spec.infrastructure.parametersRef to override Microgateway defaults (for example, the Service type and annotations). If you are happy with the defaults, omit the infrastructure.parametersRef section.

Especially for Ingress deployments, make sure TLS is configured appropriately. To configure a publicly trusted certificate, cert-manager can be used to obtain and manage it. See Configuring the HTTP-01 Gateway API solver for details.

Variant A: Ingress Gateway (RECOMMENDED)

For Ingress, you typically expose the Microgateway using a Kubernetes Service of type LoadBalancer so that your cloud provider assigns an external IP address and DNS name.

Use the CR GatewayParameters to configure the Service type and cloud-provider specific annotations to make the setup work.

Example

apiVersion: microgateway.airlock.com/v1alpha1
kind: GatewayParameters
metadata:
  name: gateway-parameters-example
  namespace: example-backend-gw
spec:
  kubernetes:
    service:
      type: LoadBalancer
      externalTrafficPolicy: Local
      # Optional: configure cloud-specific annotations for the Service.
      # If not required, omit the annotations section.
      annotations:
        ...

Reference the GatewayParameters from your Gateway using spec.infrastructure.parametersRef..

Adjust the annotations to match your cloud provider. If your setup does not require any annotations, omit the annotations section completely.

Amazon Elastic Kubernetes Service (EKS) with LoadBalancer:

Example

spec:
  kubernetes:
    service:
      type: LoadBalancer
      externalTrafficPolicy: Local 
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing

Azure Kubernetes Service (AKS) with LoadBalancer:

Example

spec:
  kubernetes:
    service:
      type: LoadBalancer
      externalTrafficPolicy: Local 
      annotations:
        service.beta.kubernetes.io/azure-load-balancer-internal: "false"

Google Kubernetes Engine (GKE) with LoadBalancer:

Example

spec:
  kubernetes:
    service:
      type: LoadBalancer
      externalTrafficPolicy: Local

Variant B: In-cluster Gateway

For an in-cluster Gateway you usually do not need an external load balancer. A Kubernetes Service of type ClusterIP is sufficient, so only workloads inside the cluster can reach the Gateway.

ClusterIP is the default Service type of Microgateway. Therefore, you do not need a GatewayParameters resource just to configure the Service type. You can either:

Omit spec.infrastructure.parametersRef in the Gateway
Set the Service type explicitly using GatewayParameters as shown below.

Example

apiVersion: microgateway.airlock.com/v1alpha1
kind: GatewayParameters
metadata:
  name: gateway-parameters-example
  namespace: example-backend-gw
spec:
  kubernetes:
    service:
      type: ClusterIP