Files
homelab-design/decisions/0010-use-envoy-gateway.md
Billy D. 832cda34bd feat: add comprehensive architecture documentation
- Add AGENT-ONBOARDING.md for AI agents
- Add ARCHITECTURE.md with full system overview
- Add TECH-STACK.md with complete technology inventory
- Add DOMAIN-MODEL.md with entities and bounded contexts
- Add CODING-CONVENTIONS.md with patterns and practices
- Add GLOSSARY.md with terminology reference
- Add C4 diagrams (Context and Container levels)
- Add 10 ADRs documenting key decisions:
  - Talos Linux, NATS, MessagePack, Multi-GPU strategy
  - GitOps with Flux, KServe, Milvus, Dual workflow engines
  - Envoy Gateway
- Add specs directory with JetStream configuration
- Add diagrams for GPU allocation and data flows

Based on analysis of homelab-k8s2 and llm-workflows repositories
and kubectl cluster-info dump data.
2026-02-01 14:30:05 -05:00

2.5 KiB

Use Envoy Gateway for Ingress

  • Status: accepted
  • Date: 2025-12-01
  • Deciders: Billy Davies
  • Technical Story: Selecting ingress controller for cluster

Context and Problem Statement

We need an ingress solution that supports:

  • Gateway API (modern Kubernetes standard)
  • gRPC for ML inference
  • WebSocket for real-time chat/voice
  • Header-based routing for A/B testing
  • TLS termination

Decision Drivers

  • Gateway API support (HTTPRoute, GRPCRoute)
  • WebSocket support
  • gRPC support
  • Performance at edge
  • Active development
  • Envoy ecosystem familiarity

Considered Options

  • NGINX Ingress Controller
  • Traefik
  • Envoy Gateway
  • Istio Gateway
  • Contour

Decision Outcome

Chosen option: "Envoy Gateway", because it's the reference implementation of Gateway API with full Envoy feature set.

Positive Consequences

  • Native Gateway API support
  • Full Envoy feature set
  • WebSocket and gRPC native
  • No Istio complexity
  • CNCF graduated project (Envoy)
  • Easy integration with observability

Negative Consequences

  • Newer than alternatives
  • Less documentation than NGINX
  • Envoy configuration learning curve

Pros and Cons of the Options

NGINX Ingress

  • Good, because mature
  • Good, because well-documented
  • Good, because familiar
  • Bad, because limited Gateway API
  • Bad, because commercial features gated

Traefik

  • Good, because auto-discovery
  • Good, because good UI
  • Good, because Let's Encrypt
  • Bad, because Gateway API experimental
  • Bad, because less gRPC focus

Envoy Gateway

  • Good, because Gateway API native
  • Good, because full Envoy features
  • Good, because extensible
  • Good, because gRPC/WebSocket native
  • Bad, because newer project
  • Bad, because less community content

Istio Gateway

  • Good, because full mesh features
  • Good, because Gateway API
  • Bad, because overkill without mesh
  • Bad, because resource heavy

Contour

  • Good, because Envoy-based
  • Good, because lightweight
  • Bad, because Gateway API evolving
  • Bad, because smaller community

Configuration Example

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: companions-chat
spec:
  parentRefs:
    - name: eg-gateway
      namespace: network
  hostnames:
    - companions-chat.lab.daviestechlabs.io
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: companions-chat
          port: 8080