-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Create Configure Network Adapters page #6518
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
cbc1aa6
14b81f4
3b315cb
9a212b2
2300e4f
e6167d0
d283146
5062101
916f3b4
81fd46e
d10ab27
9aec3ac
1c48767
205ecae
310d9eb
84f0b03
92d24f1
55a8c41
e35130c
77cb4b8
a019583
fb9a9f0
e39c0ae
f346e57
c277d3d
2578283
4d49145
4fad8ae
8b39f84
8986808
761be15
f7a24a0
3905026
a4512c4
49db831
41240db
631c56f
73e845f
6dbb22a
497620d
359f605
8e5bf80
5c032f4
9cf4980
187c0a1
3e2a67f
1c05b86
dddacd1
129133a
f300403
d475c32
6f6fb4b
1eeda2e
614e293
ee0d3f0
d70fae5
aa5c536
1425f02
6659e07
9059d0d
1d76ef9
7c0cb5d
d21ff02
89a5b3c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| Use the following steps to install and enable Contour and set it as the ingress conroller. | ||
|
|
||
| 1. Install the Knative Contour controller: | ||
|
|
||
| ```bash | ||
| kubectl apply -f https://github.com/knative/net-kourier/releases/latest/download/kourier.yaml | ||
| ``` | ||
|
|
||
| 1. Configure Knative Serving to use Contour: | ||
|
|
||
| ```bash | ||
| kubectl patch configmap/config-network \ | ||
| --namespace knative-serving \ | ||
| --type merge \ | ||
| --patch '{"data":{"ingress-class":"contour.ingress.networking.knative.dev"}}' | ||
| ``` | ||
|
|
||
| 1. Verify the installation by having a pod with the base name of `contour` in the results. | ||
|
|
||
| ```bash | ||
| kubectl get pods -n knative-serving | ||
| ``` | ||
|
|
||
| 1. Get the external IP address (FQDN) to configure DNS records: | ||
|
|
||
| ```bash | ||
| kubectl --namespace contour-external get service envoy | ||
| ``` |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| Use the following steps to install and configure the Knative Gateway API. | ||
|
|
||
| 1. Install the Knative Gateway API channel: | ||
|
|
||
| ```bash | ||
| kubectl apply -f {{ artifact(repo="net-gateway-api",org="knative-extensions",file="net-gateawy-api.yaml")}} | ||
| ``` | ||
|
|
||
| 1. Configure Knative Serving to use Knative Gateway API channel: | ||
|
|
||
| ```bash | ||
| kubectl patch configmap/config-network \ | ||
| --namespace knative-serving \ | ||
| --type merge \ | ||
| --patch '{"data":{"ingress-class":"gateway-api.ingress.networking.knative.dev"}}' | ||
| ``` | ||
|
|
||
| 1. Get the external IP address (FQDN) to configure DNS records: | ||
|
|
||
| ```bash | ||
| kubectl get gateway --all-namespaces | ||
| ``` | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| Use the following steps to install Istio and set it as the ingress conroller. | ||
|
|
||
| 1. Install a properly configured Istio: | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The artifact "macros" are not rendering to provide the URL. I wasn't able to find this one. |
||
|
|
||
| ```bash | ||
| kubectl apply -l knative.dev/crd-install=true -f {{ artifact(repo="net-istio",org="knative-extensions",file="istio.yaml")}} | ||
| kubectl apply -f {{ artifact(repo="net-istio",org="knative-extensions",file="istio.yaml")}} | ||
| ``` | ||
|
|
||
| 1. Install the Knative Istio controller: | ||
|
|
||
| ```bash | ||
| kubectl apply -f {{ artifact(repo="net-istio",file="net-istio.yaml")}} | ||
| ``` | ||
|
|
||
| <!-- 1. Set the `config-network` ConfigMap to use Istio: | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added this ConfigMap patch step that might not be correct. Or does Istio make the ingress controller connection without the ConfigMap? |
||
|
|
||
| ```bash | ||
| kubectl patch configmap/config-network \ | ||
| --namespace knative-serving \ | ||
| --type merge \ | ||
| --patch '{"data":{"ingress-class":"istio.ingress.networking.knative.dev"}}' | ||
| ``` --> | ||
|
|
||
| 1. Verify the installation by having pods with the base name of `istio` and `istio-webhook` in the results. | ||
|
|
||
| ```bash | ||
| kubectl get pods -n knative-serving | ||
| ``` | ||
|
|
||
| 1. Get the external IP address (FQDN) to configure DNS records: | ||
|
|
||
| ```bash | ||
| kubectl --namespace istio-system get service istio-ingressgateway | ||
| ``` | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| Use the following steps to install Kourier and set it as the ingress controller. | ||
|
|
||
| 1. Install the Knative Kourier controller: | ||
|
|
||
| ```bash | ||
| kubectl apply -f https://github.com/knative/net-kourier/releases/latest/download/kourier.yaml | ||
| ``` | ||
|
|
||
| 1. Configure Knative Serving to use Kourier by default: | ||
|
|
||
| ```bash | ||
| kubectl patch configmap/config-network \ | ||
| --namespace knative-serving \ | ||
| --type merge \ | ||
| --patch '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}' | ||
| ``` | ||
|
|
||
| 1. Verify the installation by having pods with the base name of `kourier-controller` and `kourier-gateway` in the results. | ||
|
|
||
| ```bash | ||
| kubectl get pods -n knative-serving | ||
| ``` | ||
|
|
||
| 1. Get the external IP address (FQDN) to configure DNS records: | ||
|
|
||
| ```bash | ||
| kubectl --namespace kourier-system get service kourier | ||
| ``` |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,187 @@ | ||
| --- | ||
| audience: administrator | ||
| components: | ||
| - serving | ||
| function: how-to | ||
| --- | ||
|
|
||
| # Configure Knative networking | ||
|
|
||
| This page provides installation and configuration guidance for Knative networking. You can configure Ingress controls, service-meshes, and gateways. | ||
|
|
||
| ### Determine current state | ||
|
|
||
| Use the following command to determine which ingress controllers are installed and their status. | ||
|
|
||
| ```bash | ||
| kubectl get pods -n knative-serving | ||
| ``` | ||
|
|
||
| The ingress controllers, that have been tested for Knative, have the following base names: | ||
|
|
||
| - Kourier: `kourier-control-*`, and `kourier-gateway-*`. Kourier is included in the Knative Serving installation should appear in the results when your cluster is first created. | ||
| - Contour: `contour-*` | ||
| - Istio: `istio-webhook-*`. The main Istio control plane pods such as `istiod-*` are in the `istio-system` namespace. Knative adds the `istio-webhook-*` pod in the `knative-serving` namespace when Istio is the chosen networking layer. | ||
|
|
||
| The `network-config` ConfigMap sets which controller to use with the ingress controller key. This key is patched with the name of any new controller. See [Changing the ingress controller](#change-the-controller) for important information about using this key. | ||
|
|
||
| ## Network layer options | ||
|
|
||
| Review the following tabs to determine the optimal networking layer for your cluster. For most users, the Kourier ingress controller is sufficient in conjunction the default Istio gateway, which is also included in the Knative Serving installation. You can expand your capabilities with the Contour ingress, a full-feature service mesh with Istio, and the Kubernetes Gateway API. | ||
|
|
||
| === "Kourier" | ||
|
|
||
| ```mermaid | ||
| --- | ||
| config: | ||
| theme: default | ||
| layout: elk | ||
| look: neo | ||
| --- | ||
| flowchart LR | ||
| K1["Knative<br>net-kourier"] -- creates --> K2["Ingress objects"] | ||
| K2 --> K3["Class: kourier.ingress.networking.knative.dev"] | ||
| ``` | ||
|
|
||
| The Kourier ingress controller, `net-kourier`, is installed with Knative Serving. Kourier is a lightweight alternative for the Istio ingress as its deployment consists only of an envoy proxy and a control plane. If Kourier is satisfactory, no further configurations are required. | ||
|
|
||
| Kourier is the only supported ingress controller for the IBM Z and IBM Power platforms, and requires additional steps as documented in [Install Serving with YAML on IBM-Z and IBM-P](/versioned/install/yaml-install/serving/install-serving-with-yaml-on-IBM-Z-and-IBM-P.md). | ||
|
|
||
| **Install and configure Kourier** | ||
|
|
||
| --8<-- "netadapter-kourier.md" | ||
|
|
||
| === "Contour" | ||
|
|
||
| ```mermaid | ||
| --- | ||
| config: | ||
| theme: default | ||
| layout: elk | ||
| look: neo | ||
| --- | ||
| flowchart LR | ||
| C1["Knative<br>net-contour"] -- creates --> C2["Ingress objects"] | ||
| C2 --> C3["Class: contour.ingress.networking.knative.dev"] | ||
| ``` | ||
|
|
||
| The Contour ingress controller, `net-contour`, bridges Knative's KIngress resources to Contour's HTTPProxy resources. A good choice for clusters that already run non-Knative apps, teams who want to use a single Ingress controller, and are already using Contour envoy but don't need a full-feature service mesh. | ||
|
|
||
| **Install and configure Contour** | ||
|
|
||
| --8<-- "netadapter-contour.md" | ||
|
|
||
| === "Istio" | ||
|
|
||
| ```mermaid | ||
| --- | ||
| config: | ||
| theme: default | ||
| layout: elk | ||
| --- | ||
| flowchart LR | ||
| I1["Knative net-istio"] -- creates --> I2["Service + Gateway"] | ||
| I2 --> I3["Class: istio.ingress.networking.knative.dev<br>No native Ingress objects"] | ||
| ``` | ||
|
|
||
| The Knative `net-istio` is a KIngress controller for Istio. It's a full-feature service mesh that also functions as a Knative ingress. Good for enterprises already running Istio or needing advanced service mesh features. | ||
|
|
||
| **Install and configure Istio** | ||
|
|
||
| --8<-- "netadapter-istio.md" | ||
|
|
||
| === "Ingress Gateway" | ||
|
|
||
| ```mermaid | ||
| --- | ||
| config: | ||
| layout: elk | ||
| theme: default | ||
| look: neo | ||
| --- | ||
| flowchart LR | ||
| Client["External Client"] --> CGW["Custom Ingress Gateway"] | ||
| CGW --> KIGW["Knative Ingress Gateway"] & Client | ||
| KIGW --> Revision["Knative Revision"] & CGW | ||
| Revision --> KIGW | ||
| ``` | ||
|
|
||
| Knative has a default Istio integration without the full-feature service mesh. The `knative-ingress-gateway` in the `knative-serving` namespace is a shared Istio gateway resource that handles all incoming (north-south) traffic to Knative services. This gateway points to the underlying `istio-ingressgateway` service in the `istio-system` namespace. You can replace this gateway with one of your own. | ||
|
|
||
| **Install and configure Ingress Gateway** | ||
|
|
||
| See [Configuring the Ingress gateway](setting-up-custom-ingress-gateway.md). | ||
|
|
||
| === "Gateway API" | ||
|
|
||
| ```mermaid | ||
| --- | ||
| config: | ||
| layout: elk | ||
| theme: default | ||
| --- | ||
| flowchart LR | ||
| subgraph net-gateway-api["net-gateway-api controller"] | ||
| GW["Gateway"] | ||
| Route["Knative Route"] | ||
| HR["HTTPRoute"] | ||
| end | ||
| subgraph underlying["Underlying Controller<br>(Contour │ Istio │ Envoy Gateway │ …)"] | ||
| Controller["GatewayClass Controller"] | ||
| end | ||
| KSvc["Knative Service"] --> Route | ||
| Route -- translates to --> GW & HR | ||
| GW --> Controller | ||
| HR --> Controller | ||
| Controller -- routes traffic to --> Pods["Your Pods"] | ||
|
|
||
| style net-gateway-api fill:#e3f2fd,stroke:#1976d2 | ||
| style underlying fill:#fff3e0,stroke:#ef6c00 | ||
| ``` | ||
|
|
||
| The Knative `net-gateway-api` is a KIngress implementation and testing for Knative integration with the [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/). Good for teams adopting the Gateway API to unify ingress across Kubernetes. | ||
|
|
||
| The Kubernetes Gateway API requires a controller or service mesh. Istio and Contour implementations are tested though other Gateway API implementations should work. Currently, there is no native Gateway API support for Kourier. For more information see [Tested Gateway API version and Ingress](https://github.com/knative-extensions/net-gateway-api/blob/main/docs/test-version.md). | ||
|
|
||
| The controller that Knative uses is determined by which Gateway API-compatible controller you install and configure in your cluster. | ||
|
|
||
| **Install and configure Gateway API** | ||
|
|
||
| --8<-- "netadapter-gatewayapi.md" | ||
|
|
||
| ## Configure DNS | ||
|
|
||
| --8<-- "dns.md" | ||
| --8<-- "real-dns-yaml.md" | ||
| --8<-- "no-dns.md" | ||
|
|
||
| ## Changing the ingress controller | ||
|
|
||
| If you want to change the ingress controllers, install and configure the new controller as instructed in the [Network layer options](#network-layer-options). There is no requirement to remove ingress controllers that are not in use. | ||
|
|
||
| You can determine the controller in use by examining the `config-network.yaml`: | ||
|
|
||
| ```bash | ||
| kubectl get cm config-network -n knative-serving -o yaml | ||
| ``` | ||
|
|
||
| Look for the `ingress-class` key. It could also be the `ingress.class` key with a dot. The dash usage is more current and supersedes any key with the dot. In the following example, the `ingress.class` key was initially set for the Kourier controller, but is now set to Contour because the ingress key with a dash takes precedence. | ||
|
|
||
| ```yml | ||
| ingress-class: contour.ingress.networking.knative.dev | ||
| ingress.class: kourier.ingress.networking.knative.dev | ||
| ``` | ||
|
|
||
| If you want to switch back to a previously installed controller, patch the `config-network` ConfigMap with the new controller. In the following example Kourier is used because of the dash in `ingress-class`. | ||
|
|
||
| ```bash | ||
| kubectl patch cm config-network -n knative-serving \ | ||
| --type merge -p '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}' | ||
| ``` | ||
|
|
||
| You can remove an unused key with a dot with the following command: | ||
|
|
||
| ```bash | ||
| ubectl patch configmap config-network -n knative-serving \ | ||
| --type=json -p='[{"op": "remove", "path": "/data/ingress.class"}]' | ||
| ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is channel the right word? Doesn't the ConfigMap need to configure the underlying ingress controller?