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

Clean up operator configmap docs (#4620) 

Co-authored-by: Ashleigh Brennan <abrennan@redhat.com>
This commit is contained in:
Knative Prow Robot 2022-01-06 10:42:02 -08:00 committed by GitHub
parent ffb92a90a4
commit 73fd6a18fb
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 51 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
config/nav.yml
View File

@ -41,6 +41,7 @@ nav:
# Operator Installation
- Install with Knative Operator:
- Installing with the Operator: install/operator/knative-with-operators.md
- Configuring Knative by using the Operator: install/operator/configuring-with-operator.md
- Configuring Knative Eventing CRDs: install/operator/configuring-eventing-cr.md
- Configuring Knative Serving CRDs: install/operator/configuring-serving-cr.md
# kn Installation

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

@ -1,11 +1,3 @@
---
title: "Configuring the Eventing Operator custom resource"
weight: 60
type: "docs"
aliases:
- /docs/operator/configuring-eventing-cr/
---
# Configuring the Eventing Operator custom resource
You can configure the Knative Eventing operator by modifying settings in the KnativeEventing custom resource (CR).
@ -36,16 +28,6 @@ If Knative Eventing is already managed by the Operator, updating the `spec.versi
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.
## Configuring Knative Eventing using ConfigMaps
The Operator manages the Knative Eventing installation. It overwrites any updates to ConfigMaps which are used to configure Knative Eventing.
The KnativeEventing CR allows you to set values for these ConfigMaps by using the Operator.
All Knative Eventing ConfigMaps are created in the same namespace as the KnativeEventing CR. You can use the KnativeEventing CR as a unique entry point to edit all ConfigMaps.
Knative Eventing has multiple ConfigMaps that are named with the prefix `config-`.
The `spec.config` in the KnativeEventing CR has one `<name>` entry for each ConfigMap, named `config-<name>`, with a value which will be used for the ConfigMap `data`.
### 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.

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

@ -3,7 +3,6 @@
The Knative Serving Operator can be configured with the following options:
- [Version configuration](#version-configuration)
- [Knative Serving configuration by ConfigMap](#knative-serving-configuration-by-configmap)
- [Private repository and private secret](#private-repository-and-private-secrets)
- [SSL certificate for controller](#ssl-certificate-for-controller)
- [Replace the default istio-ingressgateway service](#replace-the-default-istio-ingressgateway-service)
@ -37,68 +36,6 @@ enables upgrading or downgrading the Knative Serving version, without needing to
!!! important
The Knative Operator only permits upgrades or downgrades by one minor release version at a time. For example, if the current Knative Serving deployment is version v0.22.0, you must upgrade to v0.23.0 before upgrading to v0.24.0.
## Knative Serving configuration by ConfigMap
The Operator manages the Knative Serving installation. It overwrites any updates to ConfigMaps which are used to configure Knative Serving.
The KnativeServing custom resource (CR) allows you to set values for these ConfigMaps by using the Operator.
Knative Serving has multiple ConfigMaps that are named with the prefix `config-`.
The `spec.config` in the KnativeServing CR has one `<name>` entry for each ConfigMap, named `config-<name>`, with a value which will be used for the ConfigMap `data`.
In the [setup a custom domain example](../../serving/using-a-custom-domain.md), you can see the content of the ConfigMap
`config-domain` is:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: config-domain
namespace: knative-serving
data:
example.org: |
selector:
app: prod
example.com: ""
```
Using the operator, specify the ConfigMap `config-domain` using the operator CR:
```yaml
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
name: knative-serving
namespace: knative-serving
spec:
config:
domain:
example.org: |
selector:
app: prod
example.com: ""
```
You can apply values to multiple ConfigMaps. This example sets `stable-window` to 60s in `config-autoscaler` as well as specifying `config-domain`:
```yaml
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
name: knative-serving
namespace: knative-serving
spec:
config:
domain:
example.org: |
selector:
app: prod
example.com: ""
autoscaler:
stable-window: "60s"
```
All the ConfigMaps are created in the same namespace as the operator CR. You can use the operator CR as the
unique entry point to edit all of them.
## Private repository and private secrets
You can use the `spec.registry` section of the operator CR to change the image references to point to a private registry or [specify imagePullSecrets](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod):

50
docs/install/operator/configuring-with-operator.md Normal file
View File

@ -0,0 +1,50 @@
# Configuring Knative by using the Operator
The Operator manages the configuration of a Knative installation, including propagating values from the `KnativeServing` and `KnativeEventing` custom resources to system [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/).
Any updates to ConfigMaps which are applied manually are overwritten by the Operator. However, modifying the Knative custom resources allows you to set values for these ConfigMaps.
Knative has multiple ConfigMaps that are named with the prefix `config-`.
All Knative ConfigMaps are created in the same namespace as the custom resource that they apply to. For example, if the `KnativeServing` custom resource is created in the `knative-serving` namespace, all Knative Serving ConfigMaps are also created in this namespace.
The `spec.config` in the Knative custom resources have one `<name>` entry for each ConfigMap, named `config-<name>`, with a value which is be used for the ConfigMap `data`.
## Examples
You can specify that the `KnativeServing` custom resource uses the `config-domain` ConfigMap as follows:
```yaml
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
name: knative-serving
namespace: knative-serving
spec:
config:
domain:
example.org: |
selector:
app: prod
example.com: ""
```
You can apply values to multiple ConfigMaps. This example sets `stable-window` to 60s in the `config-autoscaler` ConfigMap, as well as specifying the `config-domain` ConfigMap:
```yaml
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
name: knative-serving
namespace: knative-serving
spec:
config:
domain:
example.org: |
selector:
app: prod
example.com: ""
autoscaler:
stable-window: "60s"
```