Skip to content

Commit 2a4ba9b

Browse files
kahirokunnkahirokunn
authored
Add Gateway API ingress with Knative Operator blog post (#6633)
Signed-off-by: kahirokunn <okinakahiro@gmail.com>
1 parent c5953ed commit 2a4ba9b

2 files changed

Lines changed: 119 additions & 1 deletion

File tree

‎docs/blog/.nav.yml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -45,6 +45,7 @@ nav:
4545
- releases/announcing-knative-v0-3-release.md
4646
- releases/announcing-knative-v0-2-release.md
4747
- Articles:
48+
- articles/gateway-api-ingress-with-knative-operator.md
4849
- articles/Enhancing-func-cli-ux.md
4950
- articles/knative-eventing-eda-agents.md
5051
- articles/kubevirt_meets_eventing.md
@@ -119,4 +120,3 @@ nav:
119120
- events/install-fest-04-2022.md
120121
- events/knative-at-kubecon-eu-2019.md
121122
- events/knative-at-kubecon-seattle.md
122-

‎docs/blog/articles/gateway-api-ingress-with-knative-operator.md‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
# Managing Gateway API ingress with the Knative Operator
2+
3+
**Author: kahirokunn**
4+
5+
_In this blog post you will learn how to use the Knative Operator to manage Knative Serving with Gateway API ingress._
6+
7+
Starting with Knative v1.22, the Knative Operator supports `net-gateway-api` as an ingress option for Knative Serving. If your platform already standardizes on Kubernetes Gateway API resources such as `GatewayClass`, `Gateway`, and `HTTPRoute`, you can now keep the Knative ingress choice and gateway configuration together in the Operator-managed `KnativeServing` custom resource.
8+
9+
Gateway API support in Knative is currently in beta. You must install a Gateway API implementation in your cluster before using `net-gateway-api`. Knative currently tests `net-gateway-api` against the Istio, Contour, and Envoy Gateway implementations. For tested versions, see the [`net-gateway-api` test version documentation](https://github.com/knative-extensions/net-gateway-api/blob/release-1.22/docs/test-version.md).
10+
11+
## What the Operator manages
12+
13+
The Operator does not replace your Gateway API implementation. It works with a Gateway API controller in the cluster, such as Istio, Contour, or Envoy Gateway, and with `Gateway` resources that Knative can use.
14+
15+
The Operator manages the Knative side of the installation. It installs the `net-gateway-api` networking layer, sets the Knative Serving ingress class, and passes gateway configuration into the `config-gateway` ConfigMap through the `KnativeServing` CR.
16+
17+
At a minimum, the `KnativeServing` CR needs to enable the Gateway API networking plugin and set the Serving ingress class:
18+
19+
```yaml
20+
apiVersion: operator.knative.dev/v1beta1
21+
kind: KnativeServing
22+
metadata:
23+
name: knative-serving
24+
namespace: knative-serving
25+
spec:
26+
ingress:
27+
gateway-api:
28+
enabled: true
29+
config:
30+
network:
31+
ingress-class: "gateway-api.ingress.networking.knative.dev"
32+
```
33+
34+
This tells the Operator to install the Gateway API networking plugin and configure Knative Serving to use it. It does not install a Gateway API implementation, and it relies on the default Gateway names unless you configure `spec.config.gateway`.
35+
36+
If `spec.config.gateway` is omitted, `net-gateway-api` falls back to its built-in Istio-oriented gateway names: `istio-system/knative-gateway` for external traffic and `istio-system/knative-local-gateway` for cluster-local traffic. That is only useful when your Gateway API implementation provides those resources. For Envoy Gateway, Contour, or custom Gateway names, configure the gateways explicitly.
37+
38+
## Configure gateways for your environment
39+
40+
Most clusters need more than the minimal ingress selection. Knative also needs to know which external and local gateways it should use.
41+
42+
The `spec.config.gateway` field maps to Knative's `config-gateway` ConfigMap. The values should match the `GatewayClass`, `Gateway`, and Service resources created by your Gateway API implementation.
43+
44+
The following example uses Envoy Gateway with one external gateway and one local gateway. This keeps external and cluster-local traffic on separate Gateway resources:
45+
46+
```yaml
47+
apiVersion: operator.knative.dev/v1beta1
48+
kind: KnativeServing
49+
metadata:
50+
name: knative-serving
51+
namespace: knative-serving
52+
spec:
53+
ingress:
54+
gateway-api:
55+
enabled: true
56+
config:
57+
network:
58+
ingress-class: "gateway-api.ingress.networking.knative.dev"
59+
gateway:
60+
external-gateways: |
61+
- class: eg-external
62+
gateway: eg-external/eg-external
63+
service: eg-external/knative-external
64+
supported-features:
65+
- HTTPRouteRequestTimeout
66+
local-gateways: |
67+
- class: eg-internal
68+
gateway: eg-internal/eg-internal
69+
service: eg-internal/knative-internal
70+
supported-features:
71+
- HTTPRouteRequestTimeout
72+
domain:
73+
example.com: ""
74+
```
75+
76+
## External and local gateways
77+
78+
The external and local gateway settings serve different traffic paths. `external-gateways` is used for routes that should be reachable from outside the cluster. `local-gateways` is used for cluster-local routes, where the Gateway implementation should expose an internal Service such as `ClusterIP`.
79+
80+
Keeping those Gateway resources separate gives platform teams a clearer boundary between public ingress and private in-cluster traffic. In the Envoy Gateway example above, `eg-external/knative-external` is the externally reachable Service, while `eg-internal/knative-internal` is the internal Service for local traffic.
81+
82+
## Verify the route
83+
84+
After applying the `KnativeServing` manifest and waiting for the Operator to finish reconciling Knative Serving, deploy a sample Knative Service and send traffic through the external Gateway. The command below uses `eg-external/knative-external` from the Envoy Gateway configuration above:
85+
86+
```bash
87+
kubectl apply -f - <<'EOF'
88+
apiVersion: serving.knative.dev/v1
89+
kind: Service
90+
metadata:
91+
name: helloworld-go
92+
spec:
93+
template:
94+
spec:
95+
containers:
96+
- image: gcr.io/knative-samples/helloworld-go
97+
env:
98+
- name: TARGET
99+
value: Go Sample v1
100+
EOF
101+
102+
export LB_IP=$(kubectl -n eg-external get svc knative-external \
103+
-o jsonpath='{.status.loadBalancer.ingress[0].ip}')
104+
105+
curl -H "Host: helloworld-go.default.example.com" "http://$LB_IP"
106+
```
107+
108+
The response should look like this:
109+
110+
```bash
111+
Hello Go Sample v1!
112+
```
113+
114+
## Conclusion
115+
116+
Gateway API ingress can now be declared as part of the Operator-managed Serving installation, while platform teams keep control over the Gateway API implementation that fits their clusters. Knative Serving, ingress selection, gateway references, and domain configuration can all be reviewed and applied as one `KnativeServing` resource.
117+
118+
For more details, see the [Gateway API tab in the Knative Operator installation documentation](https://knative.dev/docs/install/operator/knative-with-operators/#__tabbed_1_4) and the [KnativeServing CR configuration documentation](https://knative.dev/docs/install/operator/configuring-serving-cr/#configure-the-gateway-api-ingress).

0 commit comments

Comments
 (0)