Octopus CRDs

The Octopus CRDs live in the API group gateway.octopus.io, version v1alpha1, and are all namespaced. They expose Octopus-native features (auth providers, plugin chains, rate limiting, Rhai scripting, subdomain conventions) that the portable Gateway API does not model. Install them with octopus crd | kubectl apply -f - or the vendored bundle — see Install.

OctopusGateway01

OctopusGateway is a virtual gateway: a named scope that binds a set of hostnames, groups the routes under them, and pushes inherited policy defaults down to its child routes. See Virtual gateways for the full model (convention path-split, isolation tiers, FARP binding).

apiVersion: gateway.octopus.io/v1alpha1
kind: OctopusGateway
metadata:
  name: platform-api
  namespace: octopus-system
spec:
  listen: "0.0.0.0:8080"
  gatewayClassName: octopus
  hostnames: ["api.example.cloud"]
  isolation: shared
  farpBinding: true
  defaultPolicy:
    authProvider: jwt
    timeoutSeconds: 30
    cors:
      allowedOrigins: ["https://app.example.cloud"]
      allowedMethods: ["GET", "POST"]
      allowCredentials: true
      maxAge: 600

OctopusRoute02

A full route. The path is used as-is as a native router pattern (it supports :param and *wildcard), and upstream references an OctopusUpstream by name (or a discovered service). One route is produced per method.

apiVersion: gateway.octopus.io/v1alpha1
kind: OctopusRoute
metadata:
  name: orders
  namespace: shop
spec:
  parentRefs: ["edge"]
  path: /orders
  methods: ["GET", "POST"]
  upstream: orders-up
  priority: 5
  stripPrefix: /orders
  authProvider: jwt
  requireScopes: ["orders:read"]
  timeoutSeconds: 30
  rateLimit:
    requests: 100
    windowSeconds: 60
  plugins: ["request-id"]

Convention (subdomain routing)

When convention is set, the route becomes a single wildcard-host route (*.<baseDomain>) whose backend is derived per request from the host — instead of declaring a route per tenant.

apiVersion: gateway.octopus.io/v1alpha1
kind: OctopusRoute
metadata:
  name: tenants
  namespace: default
spec:
  path: /*rest
  methods: ["GET"]
  upstream: unused           # ignored when a convention derives the backend
  convention:
    baseDomain: platform.com
    layout: ["service", "namespace"]   # orders.acme.platform.com → svc `orders` in ns `acme`
    port: 8080
    backendStrategy: ServiceDNS

OctopusUpstream03

An explicit upstream cluster, referenced by name from OctopusRoute.upstream.

apiVersion: gateway.octopus.io/v1alpha1
kind: OctopusUpstream
metadata:
  name: orders-up
  namespace: shop
spec:
  lbStrategy: least_conn
  targets:
    - host: 10.0.0.1
      port: 8080
      weight: 3
    - host: 10.0.0.2
      port: 8080

OctopusPolicy04

OctopusPolicy is a GEP-713 policy attachment: it never creates routes, it enriches the routes produced by the resource it targets via targetRef. With overrideRoute: true it overrides the target's inline settings; otherwise it only fills gaps ("default" semantics).

Supported targetRef.kind values are HTTPRoute, GRPCRoute (both in group gateway.networking.k8s.io), and OctopusRoute (group gateway.octopus.io). A policy targets routes in its own namespace. Other kinds are ignored.

apiVersion: gateway.octopus.io/v1alpha1
kind: OctopusPolicy
metadata:
  name: orders-auth
  namespace: shop
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: api-route
  authProvider: jwt
  rateLimit:
    requests: 100
    windowSeconds: 60
  overrideRoute: false

Reconciling alongside Gateway API05

Octopus CRDs and Gateway API resources are translated into the same intermediate route table and merged into one live router (alongside your static config). A common pattern: define portable routing with HTTPRoute/GRPCRoute, then layer Octopus-specific behavior onto those routes with an OctopusPolicy. Or skip the Gateway API entirely and use OctopusRoute + OctopusUpstream for full-fidelity Octopus routing. See Operator for the merge and precedence model and Gateway API for the Gateway API field mappings.