knative
/
docs
mirror of https://github.com/knative/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Clean up broken formatting in Operator install docs (#4932) 

* Clean up operator docs formatting

* A few more fixes
This commit is contained in:
Samia Nneji 2022-04-21 12:57:30 +01:00 committed by GitHub
parent e58f571f9b
commit 844b6f0f7d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 130 additions and 124 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
docs/install/operator/configuring-eventing-cr.md
View File

@ -1,7 +1,7 @@
# Configuring the Eventing Operator custom resource # Configuring the Eventing Operator custom resource
You can configure the Knative Eventing operator by modifying settings in the KnativeEventing custom resource (CR). You can configure the Knative Eventing operator by modifying settings in the KnativeEventing custom resource (CR).
Knative Eventing can be configured with the following options: You can configure Knative Eventing with the following options:
- [Installing a specific version of Eventing](#installing-a-specific-version-of-eventing) - [Installing a specific version of Eventing](#installing-a-specific-version-of-eventing)
- [Installing customized Knative Eventing](#installing-customized-knative-eventing) - [Installing customized Knative Eventing](#installing-customized-knative-eventing)
@ -45,11 +45,12 @@ The Operator provides you with the flexibility to install Knative Eventing custo
As long as the manifests of customized Knative Eventing are accessible to the Operator, you can install them. 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_. There are two modes available for you to install customized manifests: _overwrite mode_ and _append mode_.
With overwrite mode, you must define all manifests needed for Knative Eventing to install because the Operator will With overwrite mode, under `.spec.manifests`, you must define all manifests needed for Knative Eventing
no longer install any default manifests. With append mode, you only need to define your customized manifests. 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. The customized manifests are installed after default manifests are applied.
**Overwrite mode:** ### Overwrite mode
Use overwrite mode when you want to customize all Knative Eventing manifests to be installed. Use overwrite mode when you want to customize all Knative Eventing manifests to be installed.
@ -83,7 +84,7 @@ This example installs the customized Knative Eventing at version `$spec_version`
We strongly recommend you to specify the version and the valid links to the customized Knative Eventing, by leveraging 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. both `spec.version` and `spec.manifests`. Do not skip either field.
**Append mode:** ### Append mode
You can use append mode to add your customized manifests into the default manifests. You can use append mode to add your customized manifests into the default manifests.
@ -113,7 +114,7 @@ This example installs the default Knative Eventing, and installs your customized
Knative Operator installs the default manifests of Knative Eventing at the version `$spec_version`, and then Knative Operator installs the default manifests of Knative Eventing at the version `$spec_version`, and then
installs your customized manifests based on them. installs your customized manifests based on them.
### Setting a default channel ## 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. 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.
@ -149,7 +150,7 @@ spec:
!!! note !!! note
The `clusterDefault` setting determines the global, cluster-wide default channel type. You can configure channel defaults for individual namespaces by using the `namespaceDefaults` setting. The `clusterDefault` setting determines the global, cluster-wide default channel type. You can configure channel defaults for individual namespaces by using the `namespaceDefaults` setting.
### Setting the default channel for the broker ## Setting the default channel for the broker
If you are using a channel-based broker, you can change the default channel type for the broker from InMemoryChannel to KafkaChannel, by updating the `config-br-default-channel` ConfigMap. If you are using a channel-based broker, you can change the default channel type for the broker from InMemoryChannel to KafkaChannel, by updating the `config-br-default-channel` ConfigMap.
@ -203,36 +204,38 @@ Some images are defined by using the environment variable in Knative Eventing. T
This example shows how you can define custom image links that can be defined in the KnativeEventing CR using the simplified format This example shows how you can define custom image links that can be defined in the KnativeEventing CR using the simplified format
`docker.io/knative-images/${NAME}:{CUSTOM-TAG}`. `docker.io/knative-images/${NAME}:{CUSTOM-TAG}`.
In the following example: In this example:
- The custom tag `latest` is used for all images. - The custom tag `latest` is used for all images.
- All image links are accessible without using secrets. - All image links are accessible without using secrets.
- Images are defined in the accepted format `docker.io/knative-images/${NAME}:{CUSTOM-TAG}`. - Images are defined in the accepted format `docker.io/knative-images/${NAME}:{CUSTOM-TAG}`.
To define your image links:
1. Push images to the following image tags: 1. Push images to the following image tags:
| Deployment | Container | Docker image | | Deployment | Container | Docker image |
|----|----|----| |----|----|----|
| `eventing-controller` | `eventing-controller` | `docker.io/knative-images/eventing-controller:latest` | | `eventing-controller` | `eventing-controller` | `docker.io/knative-images/eventing-controller:latest` |
| | `eventing-webhook` | `docker.io/knative-images/eventing-webhook:latest` | | | `eventing-webhook` | `docker.io/knative-images/eventing-webhook:latest` |
| `broker-controller` | `eventing-controller` | `docker.io/knative-images/broker-eventing-controller:latest` | | `broker-controller` | `eventing-controller` | `docker.io/knative-images/broker-eventing-controller:latest` |
| | `controller` | `docker.io/knative-images/controller:latest` | | | `controller` | `docker.io/knative-images/controller:latest` |
| | `dispatcher` | `docker.io/knative-images/dispatcher:latest` | | | `dispatcher` | `docker.io/knative-images/dispatcher:latest` |
2. Define your the KnativeEventing CR with following content: 2. Define your KnativeEventing CR with following content:
```yaml ```yaml
apiVersion: operator.knative.dev/v1beta1 apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing kind: KnativeEventing
metadata: metadata:
name: knative-eventing name: knative-eventing
namespace: knative-eventing namespace: knative-eventing
spec: spec:
registry: registry:
default: docker.io/knative-images/${NAME}:latest default: docker.io/knative-images/${NAME}:latest
override: override:
broker-controller/eventing-controller: docker.io/knative-images-repo1/broker-eventing-controller:latest broker-controller/eventing-controller: docker.io/knative-images-repo1/broker-eventing-controller:latest
``` ```
- `${NAME}` maps to the container name in each `Deployment` resource. - `${NAME}` maps to the container name in each `Deployment` resource.
- `default` is used to define the image format for all containers, except the container `eventing-controller` in the deployment `broker-controller`. To replace the image for this container, use the `override` - `default` is used to define the image format for all containers, except the container `eventing-controller` in the deployment `broker-controller`. To replace the image for this container, use the `override`
@ -243,17 +246,17 @@ In the following example:
If your custom image links are not defined in a uniform format, you will need to individually include each link in the KnativeEventing CR. If your custom image links are not defined in a uniform format, you will need to individually include each link in the KnativeEventing CR.
For example, to define the following list of images: For example, given the following list of images:
| Deployment | Container | Docker Image | | Deployment | Container | Docker Image |
|----|----|----| |----|----|----|
| `eventing-controller` | `eventing-controller` | `docker.io/knative-images/eventing-controller:latest` | | `eventing-controller` | `eventing-controller` | `docker.io/knative-images-repo1/eventing-controller:latest` |
| | `eventing-webhook` | `docker.io/knative-images/eventing-webhook:latest` | | | `eventing-webhook` | `docker.io/knative-images-repo2/eventing-webhook:latest` |
| | `controller` | `docker.io/knative-images/controller:latest` | | | `controller` | `docker.io/knative-images-repo3/imc-controller:latest` |
| | `dispatcher` | `docker.io/knative-images/dispatcher:latest` | | | `dispatcher` | `docker.io/knative-images-repo4/imc-dispatcher:latest` |
| `broker-controller` | `eventing-controller` | `docker.io/knative-images/broker-eventing-controller:latest` | | `broker-controller` | `eventing-controller` | `docker.io/knative-images-repo5/broker-eventing-controller:latest` |
The KnativeEventing CR must be modified to include the full list. For example: You must modify the KnativeEventing CR to include the full list. For example:
```yaml ```yaml
apiVersion: operator.knative.dev/v1beta1 apiVersion: operator.knative.dev/v1beta1

109
docs/install/operator/configuring-serving-cr.md
View File

@ -1,6 +1,6 @@
# Configuring the Knative Serving Operator custom resource # Configuring the Knative Serving Operator custom resource
Knative Serving can be configured with the following options: You can configure Knative Serving with the following options:
- [Version configuration](#version-configuration) - [Version configuration](#version-configuration)
- [Install customized Knative Serving](#install-customized-knative-serving) - [Install customized Knative Serving](#install-customized-knative-serving)
@ -42,16 +42,17 @@ enables upgrading or downgrading the Knative Serving version, without needing to
The Operator provides you with the flexibility to install Knative Serving customized to your own requirements. As long The Operator provides you with the flexibility to install Knative Serving customized to your own requirements. As long
as the manifests of customized Knative Serving are accessible to the Operator, you can install them. as the manifests of customized Knative Serving 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 There are two modes available for you to install customized manifests: _overwrite mode_ and _append mode_.
overwrite mode, you must define all manifests needed for Knative Serving to install because the Operator will no With overwrite mode, under `.spec.manifests`, you must define all manifests needed for
longer install any default manifests. With append mode, you only need to define your customized manifests. The Knative Serving to install because the Operator will no longer install any default manifests.
customized manifests are installed after default manifests are applied. 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:** ### Overwrite mode
You can use overwrite mode when you want to customize all Knative Serving manifests. You can use overwrite mode when you want to customize all Knative Serving manifests.
For example, if you want to install Knative Serving and istio ingress and you want customize both components, you can For example, if you want to install Knative Serving and Istio ingress and you want customize both components, you can
create the following YAML file: create the following YAML file:
```yaml ```yaml
@ -83,7 +84,7 @@ This example installs the customized Knative Serving at version `$spec_version`
We strongly recommend you to specify the version and the valid links to the customized Knative Serving, by leveraging We strongly recommend you to specify the version and the valid links to the customized Knative Serving, by leveraging
both `spec_version` and `spec.manifests`. Do not skip either field. both `spec_version` and `spec.manifests`. Do not skip either field.
**Append mode:** ### Append mode
You can use append mode to add your customized manifests into the default manifests. You can use append mode to add your customized manifests into the default manifests.
@ -130,61 +131,63 @@ must be created in the same namespace as the Knative Serving Deployments. See
[deploying images from a private container registry](../../serving/deploying-from-private-registry.md) for configuration details. [deploying images from a private container registry](../../serving/deploying-from-private-registry.md) for configuration details.
### Download images in a predefined format without secrets: ### Download images in a predefined format without secrets
This example shows how you can define custom image links that can be defined in the CR using the simplified format This example shows how you can define custom image links that can be defined in the CR using the simplified format
`docker.io/knative-images/${NAME}:{CUSTOM-TAG}`. `docker.io/knative-images/${NAME}:{CUSTOM-TAG}`.
In the following example: In the following example:
- the custom tag `v0.13.0` is used for all images - The custom tag `latest` is used for all images.
- all image links are accessible without using secrets - All image links are accessible without using secrets.
- images are pushed as `docker.io/knative-images/${NAME}:{CUSTOM-TAG}` - Images are pushed as `docker.io/knative-images/${NAME}:{CUSTOM-TAG}`.
First, you need to make sure your images pushed to the following image tags: To define your image links:
| Container | Docker Image | 1. Push images to the following image tags:
|----|----|
|`activator` | `docker.io/knative-images/activator:v0.13.0` |
| `autoscaler` | `docker.io/knative-images/autoscaler:v0.13.0` |
| `controller` | `docker.io/knative-images/controller:v0.13.0` |
| `webhook` | `docker.io/knative-images/webhook:v0.13.0` |
| `autoscaler-hpa` | `docker.io/knative-images/autoscaler-hpa:v0.13.0` |
| `net-istio-controller` | `docker.io/knative-images/net-istio-controller:v0.13.0` |
| `queue-proxy` | `docker.io/knative-images/queue-proxy:v0.13.0` |
Then, you need to define your operator CR with following content: | Container | Docker Image |
|----|----|
|`activator` | `docker.io/knative-images/activator:latest` |
| `autoscaler` | `docker.io/knative-images/autoscaler:latest` |
| `controller` | `docker.io/knative-images/controller:latest` |
| `webhook` | `docker.io/knative-images/webhook:latest` |
| `autoscaler-hpa` | `docker.io/knative-images/autoscaler-hpa:latest` |
| `net-istio-controller` | `docker.io/knative-images/net-istio-controller:latest` |
| `queue-proxy` | `docker.io/knative-images/queue-proxy:latest` |
```yaml 2. Define your operator CR with following content:
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing ```yaml
metadata: apiVersion: operator.knative.dev/v1beta1
name: knative-serving kind: KnativeServing
namespace: knative-serving metadata:
spec: name: knative-serving
registry: namespace: knative-serving
default: docker.io/knative-images/${NAME}:v0.13.0 spec:
``` registry:
default: docker.io/knative-images/${NAME}:latest
```
### Download images individually without secrets ### Download images individually without secrets
If your custom image links are not defined in a uniform format by default, you will need to individually include each If your custom image links are not defined in a uniform format by default, you will need to individually include each
link in the CR. link in the CR.
For example, to given the following images: For example, given the following images:
| Container | Docker Image | | Container | Docker Image |
|----|----| |----|----|
| `activator` | `docker.io/knative-images-repo1/activator:v0.13.0` | | `activator` | `docker.io/knative-images-repo1/activator:latest` |
| `autoscaler` | `docker.io/knative-images-repo2/autoscaler:v0.13.0` | | `autoscaler` | `docker.io/knative-images-repo2/autoscaler:latest` |
| `controller` | `docker.io/knative-images-repo3/controller:v0.13.0` | | `controller` | `docker.io/knative-images-repo3/controller:latest` |
| `webhook` | `docker.io/knative-images-repo4/webhook:v0.13.0` | | `webhook` | `docker.io/knative-images-repo4/webhook:latest` |
| `autoscaler-hpa` | `docker.io/knative-images-repo5/autoscaler-hpa:v0.13.0` | | `autoscaler-hpa` | `docker.io/knative-images-repo5/autoscaler-hpa:latest` |
| `net-istio-controller` | `docker.io/knative-images-repo6/prefix-net-istio-controller:v0.13.0` | | `net-istio-controller` | `docker.io/knative-images-repo6/prefix-net-istio-controller:latest` |
| `net-istio-webhook` | `docker.io/knative-images-repo6/net-istio-webhooko:v0.13.0` | | `net-istio-webhook` | `docker.io/knative-images-repo6/net-istio-webhooko:latest` |
| `queue-proxy` | `docker.io/knative-images-repo7/queue-proxy-suffix:v0.13.0` | | `queue-proxy` | `docker.io/knative-images-repo7/queue-proxy-suffix:latest` |
The Operator CR should be modified to include the full list: You must modify the Operator CR to include the full list. For example:
```yaml ```yaml
apiVersion: operator.knative.dev/v1beta1 apiVersion: operator.knative.dev/v1beta1
@ -195,14 +198,14 @@ metadata:
spec: spec:
registry: registry:
override: override:
activator: docker.io/knative-images-repo1/activator:v0.13.0 activator: docker.io/knative-images-repo1/activator:latest
autoscaler: docker.io/knative-images-repo2/autoscaler:v0.13.0 autoscaler: docker.io/knative-images-repo2/autoscaler:latest
controller: docker.io/knative-images-repo3/controller:v0.13.0 controller: docker.io/knative-images-repo3/controller:latest
webhook: docker.io/knative-images-repo4/webhook:v0.13.0 webhook: docker.io/knative-images-repo4/webhook:latest
autoscaler-hpa: docker.io/knative-images-repo5/autoscaler-hpa:v0.13.0 autoscaler-hpa: docker.io/knative-images-repo5/autoscaler-hpa:latest
net-istio-controller/controller: docker.io/knative-images-repo6/prefix-net-istio-controller:v0.13.0 net-istio-controller/controller: docker.io/knative-images-repo6/prefix-net-istio-controller:latest
net-istio-webhook/webhook: docker.io/knative-images-repo6/net-istio-webhook:v0.13.0 net-istio-webhook/webhook: docker.io/knative-images-repo6/net-istio-webhook:latest
queue-proxy: docker.io/knative-images-repo7/queue-proxy-suffix:v0.13.0 queue-proxy: docker.io/knative-images-repo7/queue-proxy-suffix:latest
``` ```
!!! note !!! note
@ -348,12 +351,12 @@ The key in `spec.config.istio` is in the format of `gateway.<gateway_namespace>.
Update `spec.ingress.istio.knative-local-gateway` to select the labels of the new cluster-local ingress gateway: Update `spec.ingress.istio.knative-local-gateway` to select the labels of the new cluster-local ingress gateway:
### Default local gateway name: ### Default local gateway name
Go through the [installing Istio](../installing-istio.md#installing-istio-without-sidecar-injection) guide to use local cluster gateway, Go through the [installing Istio](../installing-istio.md#installing-istio-without-sidecar-injection) guide to use local cluster gateway,
if you use the default gateway called `knative-local-gateway`. if you use the default gateway called `knative-local-gateway`.
### Non-default local gateway name: ### Non-default local gateway name
If you create custom local gateway with a name other than `knative-local-gateway`, update `config.istio` and the If you create custom local gateway with a name other than `knative-local-gateway`, update `config.istio` and the
`knative-local-gateway` selector: `knative-local-gateway` selector:

72
docs/install/operator/knative-with-operators.md
View File

@ -50,7 +50,7 @@ kubectl logs -f deploy/knative-operator
### Upgrade the existing custom resources ### Upgrade the existing custom resources
If you are upgrading an existing Operator install from v1.2 (or earlier) to v1.3 (or later), run the following command 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`: to upgrade the existing custom resources to `v1beta1`:
```bash ```bash
@ -68,28 +68,28 @@ To create the custom resource for the latest available Knative Serving in the Op
1. Copy the following YAML into a file: 1. Copy the following YAML into a file:
```yaml ```yaml
apiVersion: v1 apiVersion: v1
kind: Namespace kind: Namespace
metadata: metadata:
name: knative-serving name: knative-serving
--- ---
apiVersion: operator.knative.dev/v1beta1 apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing kind: KnativeServing
metadata: metadata:
name: knative-serving name: knative-serving
namespace: knative-serving namespace: knative-serving
``` ```
!!! note !!! note
When you don't specify a version by using `spec.version` field, the Operator defaults to the latest available version. When you don't specify a version by using `spec.version` field, the Operator defaults to the latest available version.
1. Apply the YAML file by running the command: 1. Apply the YAML file by running the command:
```bash ```bash
kubectl apply -f <filename>.yaml kubectl apply -f <filename>.yaml
``` ```
Where `<filename>` is the name of the file you created in the previous step. Where `<filename>` is the name of the file you created in the previous step.
### Install the networking layer ### Install the networking layer
@ -279,27 +279,27 @@ To create the custom resource for the latest available Knative Eventing in the O
1. Copy the following YAML into a file: 1. Copy the following YAML into a file:
```yaml ```yaml
apiVersion: v1 apiVersion: v1
kind: Namespace kind: Namespace
metadata: metadata:
name: knative-eventing name: knative-eventing
--- ---
apiVersion: operator.knative.dev/v1beta1 apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing kind: KnativeEventing
metadata: metadata:
name: knative-eventing name: knative-eventing
namespace: knative-eventing namespace: knative-eventing
``` ```
!!! note !!! note
When you do not specify a version by using `spec.version` field, the Operator defaults to the latest available version. When you do not specify a version by using `spec.version` field, the Operator defaults to the latest available version.
1. Apply the YAML file by running the command: 1. Apply the YAML file by running the command:
```bash ```bash
kubectl apply -f <filename>.yaml kubectl apply -f <filename>.yaml
``` ```
Where `<filename>` is the name of the file you created in the previous step. Where `<filename>` is the name of the file you created in the previous step.