Configuring the Serving Operator Custom Resource

• Service Configuration by ConfigMap
• SSL certificate for controller
• Cluster local gateway
• System Resource Settings

Because the operator manages the Knative Serving installation, it will overwrite any updates to the which are used to configure Knative Serving. The KnativeServing custom resource allows you to set values for these ConfigMaps via the operator. Knative Serving has multiple ConfigMaps named with the prefix config-. The spec.config in KnativeServing has one entry <name> for each ConfigMap named config-<name>, with a value which will be used for the ConfigMap’s data.

In the , you can see the content of the ConfigMap config-domain is:

Using the operator, specify the ConfigMap config-domain using the operator CR:

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:

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 :

• default: this field defines a image reference template for all Knative images. The format is example-registry.io/custom/path/${NAME}:{CUSTOM-TAG}. If you use the same tag for all your images, the only difference is the image name. ${NAME} is a pre-defined variable in the operator corresponding to the container name. If you name the images in your private repo to align with the container names ( activator, autoscaler, controller, webhook, autoscaler-hpa, networking-istio, and queue-proxy), the default argument should be sufficient.

• override: a map from container name to the full registry location. This section is only needed when the registry images do not match the common naming format. For containers whose name matches a key, the value is used in preference to the image name calculated by default. If a container’s name does not match a key in override, the template in default is used.

• imagePullSecrets: a list of Secret names used when pulling Knative container images. The Secrets must be created in the same namespace as the Knative Serving Deployments. See deploying images from a private container registry for configuration details.

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}.

In the example below:

• all image links are accessible without using secrets
• images are pushed as docker.io/knative-images/${NAME}:{CUSTOM-TAG}

Then, you need to define your operator CR with following content:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  registry:
    default: docker.io/knative-images/${NAME}:v0.13.0

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 link in the CR.

For example, to given the following images:

The operator CR should be modified to include the full list:

If your image repository requires private secrets for access, include the imagePullSecrets attribute.

This example uses a secret named regcred. You must create your own private secrets if these are required:

• From existing docker credentials
• Create your own secret

After you create this secret, edit your operator CR by appending the content below:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  registry:
    ...
    imagePullSecrets:
      - name: regcred

The field imagePullSecrets expects a list of secrets. You can add multiple secrets to access the images as below:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  registry:
    ...
    imagePullSecrets:
      - name: regcred
      - name: regcred-2
      ...

To , the Knative Serving controller needs to access the container registry. To allow the controller to trust a self-signed registry cert, you can use the Operator to specify the certificate using a ConfigMap or Secret.

Specify the following fields in spec.controller-custom-certs to select a custom registry certificate:

• name: the name of the ConfigMap or Secret.
• type: either the string “ConfigMap” or “Secret”.

If you create a ConfigMap named testCert containing the certificate, change your CR:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  controller-custom-certs:
    name: testCert
    type: ConfigMap

Configuration of Knative ingress gateway

Step 2: Update the Knative gateway

Update spec.knative-ingress-gateway to select the labels of the new ingress gateway:

Additionally, you will need to update the Istio ConfigMap:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  knative-ingress-gateway:
    selector:
  config:
    istio:
      gateway.knative-serving.knative-ingress-gateway: "custom-ingressgateway.istio-system.svc.cluster.local"

The key in spec.config.istio is in the format of gateway.{{gateway_namespace}}.{{gateway_name}}.

Update spec.cluster-local-gateway to select the labels of the new cluster-local ingress gateway:

Default local gateway name:

Go through the guide to use local cluster gateway, if you use the default gateway called cluster-local-gateway.

If you create custom local gateway with a name other than cluster-local-gateway, update config.istio and the cluster-local-gateway selector:

This example shows a service and deployment custom-local-gateway in the namespace istio-system, with the label custom: custom-local-gw:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  cluster-local-gateway:
    selector:
      custom: custom-local-gateway
  config:
    istio:
      local-gateway.knative-serving.cluster-local-gateway: "custom-local-gateway.istio-system.svc.cluster.local"

High availability

By default, Knative Serving runs a single instance of each controller. The spec.high-availability field allows you to configure the number of replicas for the following master-elected controllers: controller, autoscaler-hpa, networking-istio. This field also configures the HorizontalPodAutoscaler resources for the data plane (activator):

The following configuration specifies a replica count of 3 for the controllers and a minimum of 3 activators (which may scale higher if needed):

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  high-availability:
    replicas: 3

The operator custom resource allows you allows you to configure system resources for the Knative system containers. Requests and limits can be configured for the following containers: activator, autoscaler, controller, webhook, autoscaler-hpa, networking-istio and queue-proxy.

To override resource settings for a specific container, create an entry in the spec.resources list with the container name and the .

If you would like to add another container autoscaler with the same configuration, you need to change your CR as below:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  resources:
  - container: activator
    requests:
      cpu: 300m
      memory: 100Mi
    limits:
      cpu: 1000m
      memory: 250Mi
      ephemeral-storage: 4Gi
  - container: autoscaler
    requests:
      cpu: 300m
      memory: 100Mi
    limits:
      cpu: 1000m
      ephemeral-storage: 4Gi