-
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
Fixes and refinements
Refinement edits
Minor edit to rebuild
Copy and refinement edits
Added note about IBM Z and IBM Power platforms and Kourier.
Fixed link
Format fix
|
|
||
| The Knative `net-kourier` ingress 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 described 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). |
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 link to install-serving-with-yaml-on-IBM-Z-and-IBM-P.md returns a 404 because it is not yet in the Nav.
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.
This should be a relative link, e.g. ../install/yaml-install/serving/install-serving-with-yaml-on-IBM-Z-and-IBM-P.yaml.
Absolute links like this won't work when we build the different documentation versions, and they wouldn't work right between newer and older documentation versions even if you got the URL to line up at one point in time.
| 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, 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.
Decision to make - bring the topic into this tab or not?
| @@ -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.
| 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.
I added this ConfigMap patch step that might not be correct. Or does Istio make the ingress controller connection without the ConfigMap?
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 Istio may be the default value if one is not set, but doing this explicitly shouldn't hurt.
|
/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 |
| 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: |
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?
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.
Knative Serving reads the configmap, so updating the ConfigMap configures Knative Serving. (This usage is correct.)
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.
| 1. Install the Knative Contour 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.
We have a macro which will use the same version as the documentation:
| kubectl apply -f https://github.com/knative/net-kourier/releases/latest/download/kourier.yaml | |
| kubectl apply -f {{ artifact(org="knative-extensions", repo="net-kourier", file="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.
Although, I'm realizing this should probably be net-contour and contour.yaml...
| 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: |
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.
Knative Serving reads the configmap, so updating the ConfigMap configures Knative Serving. (This usage is correct.)
| @@ -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.
| 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.
I believe that Istio may be the default value if one is not set, but doing this explicitly shouldn't hurt.
| kubectl get pods -n knative-serving | ||
| ``` | ||
|
|
||
| The ingress controllers, that have been tested for Knative, have the following base names: |
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 commas here don't seem quite right.
Maybe phrase this as the "The Knative team tests the following ingress controllers:"?
| - 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. |
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.
This is actually slightly different -- each ingress controller only manages ingress objects that are annotated with its key. Knative Serving uses a default value of the key based on the network-config ConfigMap. So this is somewhat of a cooperative process between the ingress controller and the core Knative controller.
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 end result is effectively the same, but the mechanism is different, which seemed important to correct in the documentation.)
|
|
||
| ## 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. |
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.
Folks shouldn't need both Kourier and Istio -- one or the other should be sufficient, depending on need.
| look: neo | ||
| --- | ||
| flowchart LR | ||
| K1["Knative<br>net-kourier"] -- creates --> K2["Ingress 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.
"Ingress" is confusing here, as Kubernetes has an "Ingress" object type which is different from the Knative networking.internal.knative.dev Ingress type. We called it "Ingress" because it was what we wanted Ingress to be, and every actual Ingress implementation had a different name for the "better Ingress" implementation.
We generally refer to the Knative version of Ingress from networking.internal as "KIngress".
|
|
||
| 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). |
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 should make clear that Kourier is a perfectly fine choice for all platforms, but for these IBM platforms, it's the only option.
Link fix
Co-authored-by: Evan Anderson <evan.k.anderson@gmail.com>
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