diff --git a/config/nav.yml b/config/nav.yml index a827ba68355..8dfa981d823 100644 --- a/config/nav.yml +++ b/config/nav.yml @@ -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 diff --git a/docs/install/operator/configuring-eventing-cr.md b/docs/install/operator/configuring-eventing-cr.md index 63b8944e7e2..438e234a976 100644 --- a/docs/install/operator/configuring-eventing-cr.md +++ b/docs/install/operator/configuring-eventing-cr.md @@ -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 `` entry for each ConfigMap, named `config-`, 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. diff --git a/docs/install/operator/configuring-serving-cr.md b/docs/install/operator/configuring-serving-cr.md index 78db977f4d0..d5df4ed4d52 100644 --- a/docs/install/operator/configuring-serving-cr.md +++ b/docs/install/operator/configuring-serving-cr.md @@ -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 `` entry for each ConfigMap, named `config-`, 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): diff --git a/docs/install/operator/configuring-with-operator.md b/docs/install/operator/configuring-with-operator.md new file mode 100644 index 00000000000..5f04cb066af --- /dev/null +++ b/docs/install/operator/configuring-with-operator.md @@ -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 `` entry for each ConfigMap, named `config-`, 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" +```