xin

Kubernetes Gateway

xin-gateway is a Gateway API controller whose data plane is the same binary as the controller. There is no sidecar to inject and no second proxy to operate.

Conformance: 32 of the 33 core Gateway API conformance tests pass. The one failure is request-header add and remove — a data-plane gap, not a controller one. It is listed here rather than rounded up to "conformant".

What it does

  • GatewayClass, Gateway and HTTPRoute reconciliation, with status written back
  • Hostname and path matching, header matching, backend weighting and traffic splitting
  • TLS termination at the Gateway listener
  • Controller and data plane in one process — one image to scan, one binary to patch

Install

curl -fsSL https://xinproxy.com/install.sh | sh -s -- --product xin-gateway

Or from the package feeds directly — xin-gateway is published for every architecture in both the apt and rpm repositories. See Releases.

A minimal Gateway

Register the class, then a Gateway that listens on port 80:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: xin
spec:
  controllerName: xinproxy.com/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web
  namespace: default
spec:
  gatewayClassName: xin
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same

Routing traffic

An HTTPRoute attaches to the Gateway and selects backends:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app
  namespace: default
spec:
  parentRefs:
    - name: web
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-svc
          port: 8080
          weight: 90
        - name: api-canary
          port: 8080
          weight: 10

Checking it took effect

kubectl get gateway web -o wide
kubectl describe httproute app

The controller writes Accepted and ResolvedRefs conditions onto the Gateway and each route. A route it cannot honour is reported as a condition rather than silently dropped — the same rule the config parser follows.

The other control-plane option

If your control plane speaks Envoy xDS rather than the Gateway API, xin-envoyd is the same data plane driven by xDS instead. The front ends are selected at compile time and do not link each other: xin-envoyd contains no configuration-file parser at all, and a build gate fails if one ever appears in its dependency graph.

Certificates by value over SDS are refused rather than mishandled — SDS is subscribed but not yet consumed.