Learn Multigress - History, Background & Why Use Multigress

#Introduction

Traffic management in Kubernetes once meant a single narrow path: the Ingress object controlled by a single controller with a mountain of annotations. For years this pattern survived, but it started to feel cramped as applications grew more complex. The need emerged for a more expressive, vendor-neutral API capable of handling ingress, egress, and mesh at the same time.

Episode 1 discusses why Multigress exists, how it fits into the cloud native ecosystem, its comparison with other solutions like Ingress Controller, API Gateway, and Istio Gateway, and the main use cases that make it compelling. This episode is narrative — minimal commands — but this is exactly where you'll understand why this series is worth following to the end.

You don't need to install anything in this episode. Jot down any questions that come up while reading, and make sure they're all answered by the time we reach episode 2.

#Why Multigress Exists in the Cloud Native Ecosystem

#Problems with Classic Ingress

The Ingress object was born to solve a simple need: routing HTTP by host and path. Unfortunately, its spec is far too minimal. Features like rewrite, authentication, rate limiting, and TLS passthrough are not available in the core API. Each controller ends up inventing its own annotations, making configuration non-portable, hard to validate, and impossible to move between implementations.

The most common problems include:

• Vendor-specific annotations make configuration non-portable.
• Security features like authentication and rate limiting are not standardized.
• There's no uniform status model for diagnosis.
• Configuration duplication across controllers is hard to avoid.
• Controller upgrades can change behavior without warning.

#The Birth of the Gateway API

Out of those limitations, the Kubernetes community created the Gateway API — a superset of Ingress with explicit GatewayClass, Gateway, and HTTPRoute concepts. This API supports features that previously required annotations, and provides clear status and conditions for every resource.

Resources that used to need dozens of Ingress annotations can now simply be declared as objects with explicit fields. That's what makes configuration validatable by tools like kubeconform, which we'll use in episode 19.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo-route
spec:
  parentRefs:
    - name: main-gateway
  hostnames:
    - "echo.example.com"
  rules:
    - backendRefs:
        - name: echo
          port: 80

Notice: no annotations at all. The kubectl apply -f route.yaml command is enough to apply the configuration above to any Gateway API implementation.

#Multigress's Position in the Cloud Native Stack

Multigress was born as an answer to two needs at once: a standard API and a lightweight runtime. Architecturally, Multigress consists of two layers:

• Control plane: a controller that listens to Gateway API resources and translates them into proxy configuration.
• Data plane: the proxy that actually processes traffic, Envoy-based by default with a HAProxy option.

The workflow is simple: you write Gateway and HTTPRoute, the controller reads them, and the data plane is updated without downtime. This architecture is covered in detail in episode 2.

#Multigress vs Other Solutions

You need to understand Multigress's position so you don't pick the wrong tool:

• Ingress Controller: only handles inbound traffic (north-south) with a minimal API that relies on annotations.
• API Gateway: focuses on API management, authentication, and quotas; generally runs outside Kubernetes.
• Istio Gateway: part of a service mesh, strong for east-west and mTLS, but heavyweight if you only need ingress.
• Multigress: unifies ingress, egress, and gatewaying in a single Gateway API-based control plane, with a lightweight, scalable Envoy or HAProxy data plane.

Multigress is not a service mesh replacement. It is a standalone gateway layer that can be installed alongside a mesh when needed. This comparison becomes relevant again in episodes 13 and 17.

Multigress's core value lies in its consistency: one declarative way to handle traffic in every direction, with strong validation through the Gateway API.

kubectl api-resources | grep -i gateway

If no implementation is installed yet, the output only shows the built-in resources. That's normal before episode 3.

#Main Use Cases

#Ingress and Edge Routing

The most basic use case: receive HTTP or HTTPS traffic from outside, terminate TLS at the gateway, then direct requests to the right Service based on host and path. This is what you'll build starting in episode 3.

#Egress

Multigress can also serve as the exit point for traffic. All requests from pods to the outside world pass through a single egress gateway so policies, logging, and access control can be applied centrally. Full details are in episode 13.

#Service Mesh Gatewaying

When installed alongside a mesh like Istio, Multigress can act as a gateway that understands workload identity. Incoming traffic is verified and forwarded with mTLS all the way to the backend pod, opening up zero-trust patterns at the edge.

#Multi-Cluster Edge Routing

The last use case, which is on the rise: edge routing across clusters. A single entry point forwards requests to the right cluster based on location or latency — the full topic in episode 17.

The four use cases above aren't a rigid list. They can be combined, and most production patterns we'll cover use more than one at a time.

#Closing

Episode 1 explained why Multigress exists: the limitations of classic Ingress gave birth to the Gateway API, and Multigress is one of its implementations that unifies ingress, egress, and gatewaying in a single control plane and data plane architecture.

The key takeaways:

• Classic Ingress is too minimal, and annotations make configuration non-portable.
• The Gateway API is a superset of Ingress with the GatewayClass, Gateway, and route concepts.
• Multigress is a Gateway API implementation with an Envoy or HAProxy data plane.
• Multigress differs from Ingress Controller, API Gateway, and Istio Gateway.
• Main use cases: ingress, egress, service mesh gatewaying, and multi-cluster edge routing.

In the next episode 2 we'll dissect the core concepts and main architecture of Multigress — the roles of control plane and data plane, the components of the multigress controller, the Gateway API, and the Envoy or HAProxy backend, the flow from GatewayClass to HTTPRoute, and integration with Multigress-specific CRDs. Make sure the concepts from episode 1 have sunk in before moving on.