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,GatewayandHTTPRoutereconciliation, 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.