-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Create Configure Knative Networking 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?
Conversation
Create file - table test
✅ Deploy Preview for knative ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Formatting test
More writing
Snippet testing
snippet testing
Snippet name fix
Formatting tests
Formatting fix
Formmating
Typo fix
Formatting
Updates
Snippet formatting
Misc edits
Link issue fix
Minor edit to rebuild
Format fix
| @@ -0,0 +1,35 @@ | |||
| Use the following steps to install Istio and set it as the ingress conroller. | |||
|
|
|||
| 1. Install a properly configured Istio: | |||
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.
The artifact "macros" are not rendering to provide the URL. I wasn't able to find this one.
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.
You may need a space between ) }} for the macro to work. I can take a look this weekend.
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.
Yep, I see this not working, but I haven't yet figured out why. I'm guessing it's the combination of macros and snippets that is doing it.
|
/assign @dprotaso @evankanderson |
Updated Gateway API steps
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: iRaindrop The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixed typos and tweaking
Minor edit to rebuild
Consistency edits
|
|
||
| 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" |
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.
A little context on these mermaid charts. Evan created the one for Gateway API and I did the others with AI help and I also added the Controller to the Gateway API.
Hence, they need tech reviewed as they could be misleading!
evankanderson
left a comment
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.
I got to this much later than I intended to (and I need to update the charts). A few corrections to the first half, and I may need to actually get out a cluster and cycle through the gateways for the details on each one.
| @@ -0,0 +1,35 @@ | |||
| Use the following steps to install Istio and set it as the ingress conroller. | |||
|
|
|||
| 1. Install a properly configured Istio: | |||
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.
You may need a space between ) }} for the macro to work. I can take a look this weekend.
Link fix
Co-authored-by: Evan Anderson <evan.k.anderson@gmail.com>
Moved page up in Nav, moved 'Detect current state' section down. Also format edits.
H3 to H2 - Determine current state
|
Moved the page up a level next to the Networking options node. |
evankanderson
left a comment
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.
Sorry for the bit of a left-turn on this review. I'd been reviewing this in isolation, but then I realized that some of the content looked familiar from the YAML install documentation, and I'd really prefer not to duplicate those docs.
This current document seems to partially duplicate the "installing with YAML" document, but adds some additional context. The DNS bit seems unnecessary, as it's simply the same as the existing "installing with YAML" content, so I'd avoid duplicating that.
I think the diagrams and what the different installations are good explanation content, but I'd be concerned about mixing the how-to and explanation into the same document. Maybe rather than including the "Install and configure" sections (which mostly cover install without configure), we could add details on the configuration options for each ingress option. Off the top of my head:
- Contour
config-contourhas settings for visibility, CORS policy, timeouts, and TLS secrets
- Gateway
config-gatewayhas the twoexternal-gatewaysandlocal-gatewayslists
- Istio
config-istiohas similar (but not identical)external-gatewaysandlocal-gatewayslists
- Kourier
- Doesn't really have any settings, because it's lightweight and Knative-only
| is running. | ||
|
|
||
| In these cases, see the "Real DNS" or "No DNS" tabs. | ||
| This configuration works only if the cluster `LoadBalancer` Service exposes an IPv4 address or hostname. It does not work with IPv6 clusters or local setups such as minikube, unless [`minikube tunnel`](https://minikube.sigs.k8s.io/docs/commands/tunnel/) is running, and should consider using the "Real DNS" or "No DNS" tabs. |
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.
"It does not work with ...., and should consider" seems to have changed the subject of the sentence.
| - Configure Knative networking: serving/config-network-adapters.md | ||
| - Networking Options: | ||
| - Configure the ingress gateway: serving/setting-up-custom-ingress-gateway.md |
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.
It's odd to have this up one level from "Networking options" and "Configure the ingress gateway", which feel like related tasks.
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.
I see your point. I'll put it back.
| look: neo | ||
| --- | ||
| flowchart LR | ||
| K1["Knative<br>net-kourier"] -- creates --> K2["KIngress objects"] |
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.
net-kourier doesn't create KIngress objects; it reads objects created by serving. I think a more accurate diagram would have two parts. One is common for all network layers:
flowchart LR
route["Route object"] -- "read by" --> serving-core("Serving<br>controller") -- creates --> KIngress["Ingress object<br>networking.internal.knative.dev<br>(KIngress)"]
And then for Kourier, the chart would look like
flowchart LR
KIngress["KIngress<br>Class:kourier.ingress.networking.knative.dev"] -- "read by" --> controller("net-kourier<br>controller") -- programs --> envoy("Envoy deployment<br>kourier-system namespace")
I'll update the other diagrams with just the second-part diagrams.
| 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. |
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.
I believe that Kourier is installed by the quickstart, but other installations need to explicitly install it.
I wouldn't say it's an alternative for the Istio ingress so much as it's a lightweight implementation of the KIngress resource for clusters which don't need other ingress features.
| 1. Install a properly configured Istio: | ||
|
|
||
| ```bash | ||
| kubectl apply -l knative.dev/crd-install=true -f {{ artifact(repo="net-istio",org="knative-extensions",file="istio.yaml") }} |
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.
@dprotaso -- do we still need our own istio.yaml?
| kubectl apply -f {{ artifact(repo="net-istio",file="net-istio.yaml") }} | ||
| ``` | ||
|
|
||
| 1. Set the `config-network` ConfigMap to use Istio: |
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.
Elsewhere, we call this "Configure...". Can we use the same language in each tab for this step?
| === "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). |
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.
The referenced document contains configuration details for customizing the Istio configuration. It's not separate from the "Istio" configuration, but instead provides additional configuration detail.
|
|
||
| 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). |
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.
We test Istio, Contour, and Envoy Gateway implementation at this point. I don't think we ever intend to implement Gateway API support for Kourier. (Also, Envoy Gateway and other Gateway API implementations will probably never get a separate support path like Istio and Contour did -- that was basically a stepping stone before Gateway API existed.)
|
|
||
| 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. |
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.
In particular, it's determined by the configuration in config-gateway, that I described in an earlier comment.
Co-authored-by: Evan Anderson <evan.k.anderson@gmail.com>
| 1. Install the Knative Kourier controller: | ||
|
|
||
| ```bash | ||
| kubectl apply -f https://github.com/knative/net-kourier/releases/latest/download/kourier.yaml |
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.
Same placeholder pattern should be usable here:
| kubectl apply -f https://github.com/knative/net-kourier/releases/latest/download/kourier.yaml | |
| kubectl apply -f {{ artifact(repo="net-kourier",file="kourier.yaml") }} |
The content for the Kourier, Contour, Gateway API, and Istio is could be helpful consolidated as opposed to separate install and config topics.
Proposed Changes