KONG-36 PoC/Deep Dive: Gloo

https://folio-org.atlassian.net/browse/KONG-36

1 Gloo API Gateway Architecture: Kubernetes vs Local Deployment with Consul & Vault
- 1.1 Executive Summary
- 1.2 Kubernetes Model
- 1.3 Local Model (Standalone)
- 1.4 Docker Compose file example for running locally
2 Evaluating Route Expression Support in Gloo API Gateway
3 Migration Workflow and Results
4 Community Health Analysis – Gloo API Gateway
5 Governance Model
6 SOLO ’s Role and Influence
7 Community Contribution Patterns
8 Enterprise / OSS Split – Risk Assessment

Gloo API Gateway Architecture: Kubernetes vs Local Deployment with Consul & Vault

Executive Summary

Outlines and compares the two primary deployment architectures for the Gloo API Gateway: Kubernetes-native and Local (VM/Bare-metal). The choice of architecture fundamentally changes how Gloo is configured, managed, and integrated into our environment.

Kubernetes-native : This model is operator-based, running Gloo entirely within a Kubernetes cluster. It leverages Custom Resource Definitions (CRDs) for all configuration and relies on native Kubernetes primitives for service discovery, secrets, and high availability.
Local (VM/ECS) : This model is process-based, running Gloo components as services on hosts/VM. It is designed for non-Kubernetes environments and integrates directly with HashiCorp Consul for service discovery, configuration storage HashiCorp Vault for secrets management.

Kubernetes Model

Gloo control plane watches CRDs (VirtualService, Upstream) for route changes and configuration.
Secrets are managed in K8s
Service discovery leverages K8s services and endpoints
Envoy proxies run as pods and are dynamically updated by Gloo’s xDS management server.

Local Model (Standalone)

Gloo reads config (routes, upstreams, settings) directly from Consul KV .
Vault provides secrets/key material for TLS, auth, Lambda integration.
Service discovery leverages Consul agent, which Gloo queries for registered services.
Envoy proxies run Docker containers receive configuration updates from the Gloo control plane.

Docker Compose file example for running locally

version: '3'

services:

  # consul
  # note: this consul instance is being run in dev mode
  # and should not be used in production
  consul:
    image: "consul:${CONSUL_VERSION:-1.10.0}"
    working_dir: /
    command:
      - "agent"
      - "-dev"
      - "--client=0.0.0.0"
      - "--node=consul-dev"
    ports:
      - "8400:8400"
      - "8500:8500"
      - "8600:8600"
      - "8600:8600/udp"
    restart: always

  # vault
  # note: this vault instance is being run in dev mode
  # and should not be used in production
  vault:
    image: "vault:${VAULT_VERSION:-1.6.0}"
    working_dir: /
    command:
      - "server"
      - "-dev"
      - "-dev-root-token-id=root"
      - "-dev-listen-address=0.0.0.0:8200"
    ports:
      - "8200:8200"
    restart: always


  # Gloo components
  gloo:
    image: ${GLOO_REPO:-quay.io/solo-io}/gloo:${GLOO_VERSION:-1.10.0}
    working_dir: /
    command:
      - "--dir=/data/"
    volumes:
      - ./data:/data/
    ports:
      - "9977:9977"
    restart: always

  discovery:
    image: ${GLOO_REPO:-quay.io/solo-io}/discovery:${GLOO_VERSION:-1.14.6}
    working_dir: /
    command:
      - "--dir=/data/"
    volumes:
      - ./data:/data/
    restart: always

  gateway-proxy:
    image: ${GLOO_REPO:-quay.io/solo-io}/gloo-envoy-wrapper:${GLOO_VERSION:-1.14.6}
    entrypoint: ["envoy"]
    command: ["-c", "/config/envoy.yaml", "--disable-hot-restart"]
    volumes:
      - ./data/envoy-config.yaml:/config/envoy.yaml:ro
    ports:
      - "8080:8080"
      - "8443:8443"
      - "19000:19000"
    restart: always

Evaluating Route Expression Support in Gloo API Gateway

Our infrastructure relies on complex route expressions in Kong, such as matching methods, paths, and headers using regular expressions. It is essential to ensure that these rules can be reliably imported and function as expected when migrating to another gateway like Gloo API Gateway.

During my research, I confirmed that Gloo API Gateway offers equivalent functionality.

Example: Migrated Kong Route Using Gloo API Gateway regex approaches


yaml
apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: mod-courses-1.5.0-SNAPSHOT.170-vs
  namespace: gloo-system
spec:
  virtualHost:
    domains:
    - '*'
    routes:
    - matchers:
      - methods:
        - POST
        regex: ^/coursereserves/courselistings/([^/]+)/courses$
      routeAction:
        single:
          upstream:
            name: mod-courses-1.5.0-SNAPSHOT.170
            namespace: gloo-system
    - matchers:
      - methods:
        - PUT
        regex: ^/coursereserves/roles/([^/]+)$
      routeAction:
        single:
          upstream:
            name: mod-courses-1.5.0-SNAPSHOT.170
            namespace: gloo-system

Migration Workflow and Results

To validate this approach, I developed a Python script that automatically migrates all routes from our Spring testing environment into a local Gloo API Gateway instance. The migration script, included with this documentation, provides a solid foundation for building production-ready migration tooling.

Community Health Analysis – Gloo API Gateway

Governance Model

Gloo API Gateway was originally developed by SOLO and has recently been donated to the Cloud Native Computing Foundation (CNCF) to benefit the broader open-source ecosystem. CNCF vendor-neutral governance helps ensure open licensing and protects the project from unilateral changes.

SOLO ’s Role and Influence

SOLO remains the original creator and a significant contributor to Gloo Gateway. The company continues to invest heavily in engineering resources and enterprise support, building commercial offerings and cloud services that extend core open-source functionality.

Community Contribution Patterns

Gloo Gateway has participation from a growing worldwide community, with contributions from multiple companies as well as individuals across the cloud-native and Kubernetes space. Detailed metrics comparing SOLO contributions to the broader ecosystem have not been published, but CNCF stewardship is expected to diversify contributions and maintain healthy project momentum.

Enterprise / OSS Split – Risk Assessment

Positive Factors:

CNCF governance protects against sudden licensing or ownership changes.
Increasing enterprise adoption and integrations for advanced use cases like multi-cloud, security, and AI workloads.
Active efforts to foster an open and diverse contributor base.

Warning Signs:

SOLO continues to exert strong influence as the founder and primary investor.
Commercial offerings may introduce enterprise-exclusive features that are not always mirrored in open source.
Business strategy relies on monetizing Gloo Gateway through enhanced enterprise products.