Cleanup eventing CR docs (#5154)

Co-authored-by: Ashleigh Brennan <abrennan@redhat.com>
This commit is contained in:
Knative Prow Robot 2022-07-29 12:52:38 +01:00 committed by GitHub
parent 40762a0652
commit 5fa435eaa7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 141 additions and 122 deletions

View File

@ -2,111 +2,6 @@
You can configure the Knative Eventing operator by modifying settings in the `KnativeEventing` custom resource (CR).
## Installing a specific version of Eventing
Cluster administrators can install a specific version of Knative Eventing by using the `spec.version` field. For example,
if you want to install Knative Eventing v0.19.0, you can apply the following KnativeEventing CR:
```yaml
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: "1.6"
```
You can also run the following command to make the equivalent change:
```bash
kn operator install --component eventing -v 1.6 -n knative-eventing
```
If `spec.version` is not specified, the Knative Operator will install the latest available version of Knative Eventing.
If users specify an invalid or unavailable version, the Knative Operator will do nothing. The Knative Operator always
includes the latest 3 minor release versions.
If Knative Eventing is already managed by the Operator, updating the `spec.version` field in the KnativeEventing CR enables upgrading or downgrading the Knative Eventing version, without requiring modifications to the Operator.
Note that the Knative Operator only permits upgrades or downgrades by one minor release version at a time. For example,
if the current Knative Eventing deployment is version 0.18.x, you must upgrade to 0.19.x before upgrading to 0.20.x.
## Installing customized Knative Eventing
The Operator provides you with the flexibility to install Knative Eventing customized to your own requirements.
As long as the manifests of customized Knative Eventing are accessible to the Operator, you can install them.
There are two modes available for you to install customized manifests: _overwrite mode_ and _append mode_.
With overwrite mode, under `.spec.manifests`, you must define all manifests needed for Knative Eventing
to install because the Operator will no longer install any default manifests.
With append mode, under `.spec.additionalManifests`, you only need to define your customized manifests.
The customized manifests are installed after default manifests are applied.
### Overwrite mode
Use overwrite mode when you want to customize all Knative Eventing manifests to be installed.
For example, if you want to install a customized Knative Eventing only, you can create and apply the following
Eventing CR:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: $spec_version
manifests:
- URL: https://my-eventing/eventing.yaml
```
This example installs the customized Knative Eventing at version `$spec_version` which is available at
`https://my-eventing/eventing.yaml`.
!!! attention
You can make the customized Knative Eventing available in one or multiple links, as the `spec.manifests` supports a list of links.
The ordering of the URLs is critical. Put the manifest you want to apply first on the top.
We strongly recommend you to specify the version and the valid links to the customized Knative Eventing, by leveraging
both `spec.version` and `spec.manifests`. Do not skip either field.
### Append mode
You can use append mode to add your customized manifests into the default manifests.
For example, if you only want to customize a few resources but you still want to install the default Knative Eventing,
you can create and apply the following Eventing CR:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: $spec_version
additionalManifests:
- URL: https://my-eventing/eventing-custom.yaml
```
This example installs the default Knative Eventing, and installs your customized resources available at
`https://my-eventing/eventing-custom.yaml`.
Knative Operator installs the default manifests of Knative Eventing at the version `$spec_version`, and then
installs your customized manifests based on them.
## Setting a default channel
If you are using different channel implementations, like the KafkaChannel, or you want a specific configuration of the InMemoryChannel to be the default configuration, you can change the default behavior by updating the `default-ch-webhook` ConfigMap.
@ -278,9 +173,21 @@ You can also run the following commands to make the equivalent change:
```bash
kn operator configure images --component eventing --deployName eventing-controller --imageKey eventing-controller --imageURL docker.io/knative-images-repo1/eventing-controller:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --deployName eventing-webhook --imageKey eventing-webhook --imageURL docker.io/knative-images-repo2/eventing-webhook:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --deployName imc-controller --imageKey controller --imageURL docker.io/knative-images-repo3/imc-controller:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --deployName imc-dispatcher --imageKey dispatcher --imageURL docker.io/knative-images-repo4/imc-dispatcher:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --deployName broker-controller --imageKey eventing-controller --imageURL docker.io/knative-images-repo5/broker-eventing-controller:latest -n knative-eventing
```
@ -308,10 +215,25 @@ You can also run the following commands to make the equivalent change:
```bash
kn operator configure images --component eventing --deployName eventing-controller --imageKey eventing-controller --imageURL docker.io/knative-images-repo1/eventing-controller:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --deployName eventing-webhook --imageKey eventing-webhook --imageURL docker.io/knative-images-repo2/eventing-webhook:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --deployName imc-controller --imageKey controller --imageURL docker.io/knative-images-repo3/imc-controller:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --deployName imc-dispatcher --imageKey dispatcher --imageURL docker.io/knative-images-repo4/imc-dispatcher:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --deployName broker-controller --imageKey eventing-controller --imageURL docker.io/knative-images-repo5/broker-eventing-controller:latest -n knative-eventing
```
```bash
kn operator configure images --component eventing --imageKey DISPATCHER_IMAGE -controller --imageURL docker.io/knative-images-repo5/DISPATCHER_IMAGE:latest -n knative-eventing
```
@ -399,16 +321,16 @@ spec:
- container: eventing-controller
requests:
cpu: 300m
memory: 100Mi
memory: 100M
limits:
cpu: 1000m
memory: 250Mi
memory: 250M
```
You can also run the following command to make the equivalent change:
```bash
kn operator configure resources --component eventing --deployName eventing-controller --container eventing-controller --requestCPU 300m --requestMemory 100Mi --limitCPU 1000m --limitMemory 250Mi -n knative-eventing
kn operator configure resources --component eventing --deployName eventing-controller --container eventing-controller --requestCPU 300m --requestMemory 100M --limitCPU 1000m --limitMemory 250M -n knative-eventing
```
### Override the nodeSelector

View File

@ -15,17 +15,12 @@ The following table describes the supported versions of Serving and Eventing for
Before you install the Knative Serving and Eventing components, first install the Knative Operator.
### Upgrade the existing custom resources
!!! warning
Knative Operator 1.5 is the last version that supports CRDs with both `v1alpha1` and `v1beta1`. If you are upgrading an existing Operator install from v1.2 or earlier to v1.3 or later, run the following command to upgrade the existing custom resources to `v1beta1` before installing the current version:
Knative Operator 1.5 is the last version supporting the CRDs with both `v1alpha1` and `v1beta1`. If you are upgrading
an existing Operator install from v1.2 or earlier to v1.3 or later, run the following command to upgrade the existing
custom resources to `v1beta1` before installing the current version:
```bash
kubectl create -f https://github.com/knative/operator/releases/download/knative-v1.5.1/operator-post-install.yaml
```
### Install the latest Knative Operator release
```bash
kubectl create -f https://github.com/knative/operator/releases/download/knative-v1.5.1/operator-post-install.yaml
```
To install the latest stable Operator release, run the command:
@ -64,10 +59,9 @@ To track the log of the Operator, run the command:
kubectl logs -f deploy/knative-operator
```
## Installing the Knative Serving component
## Install Knative Serving
To install Knative Serving you must create a custom resource (CR), add a networking
layer to the CR, and configure DNS.
To install Knative Serving you must create a custom resource (CR), add a networking layer to the CR, and configure DNS.
### Create the Knative Serving custom resource
@ -275,7 +269,7 @@ Knative Serving with different ingresses:
{% include "real-dns-operator.md" %}
{% include "temporary-dns.md" %}
## Installing the Knative Eventing component
## Install Knative Eventing
To install Knative Eventing you must apply the custom resource (CR).
Optionally, you can install the Knative Eventing component with different event sources.
@ -310,6 +304,109 @@ To create the custom resource for the latest available Knative Eventing in the O
Where `<filename>` is the name of the file you created in the previous step.
### Installing a specific version of Eventing
Cluster administrators can install a specific version of Knative Eventing by using the `spec.version` field. For example, if you want to install Knative Eventing v1.6, you can apply the following KnativeEventing CR:
```yaml
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: "1.6"
```
You can also run the following command to make the equivalent change:
```bash
kn operator install --component eventing -v 1.6 -n knative-eventing
```
If `spec.version` is not specified, the Knative Operator installs the latest available version of Knative Eventing.
If users specify an invalid or unavailable version, the Knative Operator will do nothing. The Knative Operator always
includes the latest 3 minor release versions.
If Knative Eventing is already managed by the Operator, updating the `spec.version` field in the KnativeEventing CR enables upgrading or downgrading the Knative Eventing version, without requiring modifications to the Operator.
Note that the Knative Operator only permits upgrades or downgrades by one minor release version at a time. For example, if the current Knative Eventing deployment is version 1.4, you must upgrade to 1.5 before upgrading to 1.6.
### Installing customized Knative Eventing
The Operator provides you with the flexibility to install Knative Eventing customized to your own requirements.
As long as the manifests of customized Knative Eventing are accessible to the Operator, you can install them.
There are two modes available for you to install customized manifests: _overwrite mode_ and _append mode_.
With overwrite mode, under `.spec.manifests`, you must define all manifests needed for Knative Eventing
to install because the Operator will no longer install any default manifests.
With append mode, under `.spec.additionalManifests`, you only need to define your customized manifests.
The customized manifests are installed after default manifests are applied.
#### Overwrite mode
Use overwrite mode when you want to customize all Knative Eventing manifests to be installed.
For example, if you want to install a customized Knative Eventing only, you can create and apply the following
Eventing CR:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: $spec_version
manifests:
- URL: https://my-eventing/eventing.yaml
```
This example installs the customized Knative Eventing at version `$spec_version` which is available at
`https://my-eventing/eventing.yaml`.
!!! attention
You can make the customized Knative Eventing available in one or multiple links, as the `spec.manifests` supports a list of links.
The ordering of the URLs is critical. Put the manifest you want to apply first on the top.
We strongly recommend you to specify the version and the valid links to the customized Knative Eventing, by leveraging
both `spec.version` and `spec.manifests`. Do not skip either field.
#### Append mode
You can use append mode to add your customized manifests into the default manifests.
For example, if you only want to customize a few resources but you still want to install the default Knative Eventing,
you can create and apply the following Eventing CR:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
version: $spec_version
additionalManifests:
- URL: https://my-eventing/eventing-custom.yaml
```
This example installs the default Knative Eventing, and installs your customized resources available at
`https://my-eventing/eventing-custom.yaml`.
Knative Operator installs the default manifests of Knative Eventing at the version `$spec_version`, and then
installs your customized manifests based on them.
### Installing Knative Eventing with event sources
Knative Operator can configure the Knative Eventing component with different event sources.