Knative – Installing Knative

V0.23-Docs: Prerequisites

Mon, 01 Jan 0001 00:00:00 +0000

Before installing Knative, you must meet the following prerequisites:

System requirements

For prototyping purposes, Knative will work on most local deployments of Kubernetes. For example, you can use a local, one-node cluster that has 2 CPU and 4GB of memory.

For production purposes, it is recommended that:

If you have only one node in your cluster, you will need at least 6 CPUs, 6 GB of memory, and 30 GB of disk storage.
If you have multiple nodes in your cluster, for each node you will need at least 2 CPUs, 4 GB of memory, and 20 GB of disk storage.

NOTE: The system requirements provided are recommendations only. The requirements for your installation may vary, depending on whether you use optional components, such as a networking layer.

Prerequisites

Before installation, you must meet the following prerequisites:

You have a cluster that uses Kubernetes v1.18 or newer.
You have installed the kubectl CLI.
Your Kubernetes cluster must have access to the internet, since Kubernetes needs to be able to fetch images. (To pull from a private registry, see Deploying images from a private container registry)

Next Steps: Install Knative Serving and Eventing

You can install the Serving component, Eventing component, or both on your cluster. If you’re planning on installing both, we recommend starting with Knative Serving.

V0.23-Docs: Installing Knative Serving using YAML files

Mon, 01 Jan 0001 00:00:00 +0000

This topic describes how to install Knative Serving by applying YAML files using the kubectl CLI.

Prerequisites

Before installation, you must meet the prerequisites. See Knative Prerequisites.

Install the Serving component

To install the serving component:

Install the required custom resources:

kubectl apply -f https://github.com/knative/serving/releases/download/v0.23.0/serving-crds.yaml

Install the core components of Knative Serving:

kubectl apply -f https://github.com/knative/serving/releases/download/v0.23.0/serving-core.yaml

For information about the YAML files in the Knative Serving and Eventing releases, see Installation files.

Install a networking layer

The networking layer in Knative Serving is responsible for incoming requests and the associated responses for your Knative installation. Knative enables you to choose a networking layer and then translates Knative’s resources into the specific configuration for your chosen networking solution.

You can choose a networking layer based on what you are familiar with, what is already installed on your cluster, or what is suitable for your use case. For prototyping purposes, if you have no preference for a networking layer, choose Kourier. For production use cases, Istio is a common choice.

The tabs below expand to show instructions for installing a networking layer. Follow the procedure for the networking layer of your choice:

The following commands install Ambassador and enable its Knative integration.

Create a namespace to install Ambassador in:
```
kubectl create namespace ambassador
```

Install Ambassador:

kubectl apply --namespace ambassador \
  -f https://getambassador.io/yaml/ambassador/ambassador-crds.yaml \
  -f https://getambassador.io/yaml/ambassador/ambassador-rbac.yaml \
  -f https://getambassador.io/yaml/ambassador/ambassador-service.yaml

Give Ambassador the required permissions:

kubectl patch clusterrolebinding ambassador -p '{"subjects":[{"kind": "ServiceAccount", "name": "ambassador", "namespace": "ambassador"}]}'

Enable Knative support in Ambassador:

kubectl set env --namespace ambassador  deployments/ambassador AMBASSADOR_KNATIVE_SUPPORT=true

To configure Knative Serving to use Ambassador by default:

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress.class":"ambassador.ingress.networking.knative.dev"}}'

Fetch the External IP or CNAME:
```
kubectl --namespace ambassador get service ambassador
```
Save this for configuring DNS below.

The following commands install Contour and enable its Knative integration.

Install a properly configured Contour:

kubectl apply -f https://github.com/knative/net-contour/releases/download/v0.23.0/contour.yaml

Install the Knative Contour controller:

kubectl apply -f https://github.com/knative/net-contour/releases/download/v0.23.0/net-contour.yaml

To configure Knative Serving to use Contour by default:

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress.class":"contour.ingress.networking.knative.dev"}}'

Fetch the External IP or CNAME:
```
kubectl --namespace contour-external get service envoy
```
Save this for configuring DNS below.

For a detailed guide on Gloo integration, see Installing Gloo for Knative in the Gloo documentation.

The following commands install Gloo and enable its Knative integration.

Make sure glooctl is installed (version 1.3.x and higher recommended):
```
glooctl version
```
If it is not installed, you can install the latest version using:
```
curl -sL https://run.solo.io/gloo/install | sh
export PATH=$HOME/.gloo/bin:$PATH
```
Or following the Gloo CLI install instructions.

Install Gloo and the Knative integration:

glooctl install knative --install-knative=false

Fetch the External IP or CNAME:
```
glooctl proxy url --name knative-external-proxy
```
Save this for configuring DNS below.

The following commands install Istio and enable its Knative integration.

Install a properly configured Istio (Advanced installation)

kubectl apply -f https://github.com/knative/net-istio/releases/download/v0.23.0/istio.yaml

Install the Knative Istio controller:

kubectl apply -f https://github.com/knative/net-istio/releases/download/v0.23.0/net-istio.yaml

Fetch the External IP or CNAME:

kubectl --namespace istio-system get service istio-ingressgateway

Save this for configuring DNS below.

The following commands install Kong and enable its Knative integration.

Install Kong Ingress Controller:

kubectl apply -f https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/0.9.x/deploy/single/all-in-one-dbless.yaml

To configure Knative Serving to use Kong by default:

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress.class":"kong"}}'

Fetch the External IP or CNAME:
```
kubectl --namespace kong get service kong-proxy
```
Save this for configuring DNS below.

The following commands install Kourier and enable its Knative integration.

Install the Knative Kourier controller:

kubectl apply -f https://github.com/knative/net-kourier/releases/download/v0.23.0/kourier.yaml

To configure Knative Serving to use Kourier by default:

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress.class":"kourier.ingress.networking.knative.dev"}}'

Fetch the External IP or CNAME:
```
kubectl --namespace kourier-system get service kourier
```
Save this for configuring DNS below.

Verify the installation

Monitor the Knative components until all of the components show a STATUS of Running or Completed:

kubectl get pods --namespace knative-serving

Configure DNS

You can configure DNS to prevent the need to run curl commands with a host header.

The tabs below expand to show instructions for configuring DNS. Follow the procedure for the DNS of your choice:

We ship a simple Kubernetes Job called “default domain” that will (see caveats) configure Knative Serving to use sslip.io as the default DNS suffix.

kubectl apply -f https://github.com/knative/serving/releases/download/v0.23.0/serving-default-domain.yaml

Caveat: This will only work if the cluster LoadBalancer service exposes an IPv4 address or hostname, so it will not work with IPv6 clusters or local setups like Minikube. For these, see “Real DNS” or “Temporary DNS”.

To configure DNS for Knative, take the External IP or CNAME from setting up networking, and configure it with your DNS provider as follows:

If the networking layer produced an External IP address, then configure a wildcard A record for the domain:

# Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == A 35.233.41.212

If the networking layer produced a CNAME, then configure a CNAME record for the domain:

# Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == CNAME a317a278525d111e89f272a164fd35fb-1510370581.eu-central-1.elb.amazonaws.com

Once your DNS provider has been configured, direct Knative to use that domain:

# Replace knative.example.com with your domain suffix
kubectl patch configmap/config-domain \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"knative.example.com":""}}'

If you are using curl to access the sample applications, or your own Knative app, and are unable to use the “Magic DNS (sslip.io)” or “Real DNS” methods, there is a temporary approach. This is useful for those who wish to evaluate Knative without altering their DNS configuration, as per the “Real DNS” method, or cannot use the “Magic DNS” method due to using, for example, minikube locally or IPv6 clusters.

To access your application using curl using this method:

After starting your application, get the URL of your application:

kubectl get ksvc

The output should be similar to:

NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
helloworld-go   http://helloworld-go.default.example.com   helloworld-go-vqjlf   helloworld-go-vqjlf   True

Instruct curl to connect to the External IP or CNAME defined by the networking layer in section 3 above, and use the -H "Host:" command-line option to specify the Knative application’s host name. For example, if the networking layer defines your External IP and port to be http://192.168.39.228:32198 and you wish to access the above helloworld-go application, use:
```
curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198
```
In the case of the provided helloworld-go sample application, the output should, using the default configuration, be:
```
Hello Go Sample v1!
```

Refer to the “Real DNS” method for a permanent solution.

Next steps

After installing Knative Serving:

Installing Knative Eventing using YAML files
To add optional enhancements to your installation, see Installing optional extensions.
To easily interact with Knative Services, install the kn CLI

V0.23-Docs: Installing Knative Eventing using YAML files

Mon, 01 Jan 0001 00:00:00 +0000

This topic describes how to install Knative Eventing by applying YAML files using the kubectl CLI.

Prerequisites

Before installation, you must meet the prerequisites. See Knative Prerequisites.

Install the Eventing component

To install the Eventing component:

Install the required custom resource definitions (CRDs):

kubectl apply -f https://github.com/knative/eventing/releases/download/v0.23.0/eventing-crds.yaml

Install the core components of Eventing:

kubectl apply -f https://github.com/knative/eventing/releases/download/v0.23.0/eventing-core.yaml

For information about the YAML files in the Knative Serving and Eventing releases, see Installation files.

Verify the installation

Monitor the Knative components until all of the components show a STATUS of Running:

kubectl get pods --namespace knative-eventing

Optional: Install a default channel (messaging) layer

The tabs below expand to show instructions for installing a default channel layer. Follow the procedure for the channel of your choice:

First, Install Apache Kafka for Kubernetes

Then install the Apache Kafka channel:

curl -L "https://github.com/knative-sandbox/eventing-kafka/releases/download/v0.23.0/channel-consolidated.yaml" \
 | sed 's/REPLACE_WITH_CLUSTER_URL/my-cluster-kafka-bootstrap.kafka:9092/' \
 | kubectl apply -f -

To learn more about the Apache Kafka channel, try our sample

Install the Google Cloud Pub/Sub channel:

# This installs both the Channel and the GCP Sources.
kubectl apply -f https://github.com/google/knative-gcp/releases/download/v0.23.0/cloud-run-events.yaml

To learn more about the Google Cloud Pub/Sub channel, try our sample

The following command installs an implementation of channel that runs in-memory. This implementation is nice because it is simple and standalone, but it is unsuitable for production use cases.

kubectl apply -f https://github.com/knative/eventing/releases/download/v0.23.0/in-memory-channel.yaml

First, Install NATS Streaming for Kubernetes

Then install the NATS Streaming channel:

kubectl apply -f https://github.com/knative-sandbox/eventing-natss/releases/download/v0.23.0/300-natss-channel.yaml

Optional: Install a broker layer:

The tabs below expand to show instructions for installing the broker layer. Follow the procedure for the broker of your choice:

The following commands install the Apache Kafka broker, and run event routing in a system namespace, knative-eventing, by default.

Install the Kafka controller by entering the following command:

kubectl apply -f https://github.com/knative-sandbox/eventing-kafka-broker/releases/download/v0.23.0/eventing-kafka-controller.yaml

Install the Kafka broker data plane by entering the following command:

kubectl apply -f https://github.com/knative-sandbox/eventing-kafka-broker/releases/download/v0.23.0/eventing-kafka-broker.yaml

For more information, see the Kafka broker documentation.

The following command installs an implementation of broker that utilizes channels and runs event routing components in a System Namespace, providing a smaller and simpler installation.

kubectl apply -f https://github.com/knative/eventing/releases/download/v0.23.0/mt-channel-broker.yaml

To customize which broker channel implementation is used, update the following ConfigMap to specify which configurations are used for which namespaces:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-br-defaults
  namespace: knative-eventing
data:
  default-br-config: |
    # This is the cluster-wide default broker channel.
    clusterDefault:
      brokerClass: MTChannelBasedBroker
      apiVersion: v1
      kind: ConfigMap
      name: imc-channel
      namespace: knative-eventing
    # This allows you to specify different defaults per-namespace,
    # in this case the "some-namespace" namespace will use the Kafka
    # channel ConfigMap by default (only for example, you will need
    # to install kafka also to make use of this).
    namespaceDefaults:
      some-namespace:
        brokerClass: MTChannelBasedBroker
        apiVersion: v1
        kind: ConfigMap
        name: kafka-channel
        namespace: knative-eventing

The referenced imc-channel and kafka-channel example ConfigMaps would look like:

apiVersion: v1
kind: ConfigMap
metadata:
  name: imc-channel
  namespace: knative-eventing
data:
  channelTemplateSpec: |
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel    
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: kafka-channel
  namespace: knative-eventing
data:
  channelTemplateSpec: |
    apiVersion: messaging.knative.dev/v1alpha1
    kind: KafkaChannel
    spec:
      numPartitions: 3
      replicationFactor: 1

NOTE: In order to use the KafkaChannel make sure it is installed on the cluster as discussed above.

Next steps

After installing Knative Eventing:

To easily interact with Knative Eventing components, install the kn CLI
To add optional enhancements to your installation, see Installing optional extensions
Installing Knative Serving using YAML files

V0.23-Docs: Installing optional extensions

Mon, 01 Jan 0001 00:00:00 +0000

To add extra features to your Knative Serving or Eventing installation, you can install extensions by applying YAML files using the kubectl CLI.

For information about the YAML files in the Knative Serving and Eventing releases, see Installation files.

Prerequisites

Before you install any optional extensions, you must install Knative Serving or Eventing. See Installing Serving using YAML files and Installing Eventing using YAML files.

Install optional Serving extensions

The tabs below expand to show instructions for installing each Serving extension.

Knative also supports the use of the Kubernetes Horizontal Pod Autoscaler (HPA) for driving autoscaling decisions. The following command will install the components needed to support HPA-class autoscaling:

kubectl apply -f https://github.com/knative/serving/releases/download/v0.23.0/serving-hpa.yaml

Knative supports automatically provisioning TLS certificates via cert-manager. The following commands will install the components needed to support the provisioning of TLS certificates via cert-manager.

First, install cert-manager version 0.12.0 or higher

Next, install the component that integrates Knative with cert-manager:

kubectl apply -f https://github.com/knative/net-certmanager/releases/download/v0.23.0/release.yaml

Now configure Knative to automatically configure TLS certificates.

Knative supports automatically provisioning TLS certificates using Let’s Encrypt HTTP01 challenges. The following commands will install the components needed to support that.

First, install the net-http01 controller:

kubectl apply -f https://github.com/knative/net-http01/releases/download/v0.23.0/release.yaml

Next, configure the certificate.class to use this certificate type.

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"certificate.class":"net-http01.certificate.networking.knative.dev"}}'

Lastly, enable auto-TLS.

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"autoTLS":"Enabled"}}'

If you are using a Certificate implementation that supports provisioning wildcard certificates (e.g. cert-manager with a DNS01 issuer), then the most efficient way to provision certificates is with the namespace wildcard certificate controller. The following command will install the components needed to provision wildcard certificates in each namespace:

kubectl apply -f https://github.com/knative/serving/releases/download/v0.23.0/serving-nscert.yaml

Note this will not work with HTTP01 either via cert-manager or the net-http01 options.

The DomainMapping CRD allows a user to map a Domain Name that they own to a specific Knative Service.

kubectl apply -f https://github.com/knative/serving/releases/download/v0.23.0/serving-domainmapping-crds.yaml
kubectl wait --for=condition=Established --all crd
kubectl apply -f https://github.com/knative/serving/releases/download/v0.23.0/serving-domainmapping.yaml

Install optional Eventing extensions

The tabs below expand to show instructions for installing each Eventing extension.

Install the Kafka controller:

kubectl apply -f https://github.com/knative-sandbox/eventing-kafka-broker/releases/download/v0.23.0/eventing-kafka-controller.yaml

Install the Kafka Sink data plane:

kubectl apply -f https://github.com/knative-sandbox/eventing-kafka-broker/releases/download/v0.23.0/eventing-kafka-sink.yaml

For more information, see the Kafka Sink documentation.

The following command installs the Eventing Sugar Controller:

kubectl apply -f https://github.com/knative/eventing/releases/download/v0.23.0/eventing-sugar-controller.yaml

The Knative Eventing Sugar Controller will react to special labels and annotations and produce Eventing resources. For example:

When a Namespace is labeled with eventing.knative.dev/injection=enabled, the controller will create a default broker in that namespace.
When a Trigger is annotated with eventing.knative.dev/injection=enabled, the controller will create a Broker named by that Trigger in the Trigger’s Namespace.

The following command enables the default Broker on a namespace (here default):

kubectl label namespace default eventing.knative.dev/injection=enabled

The following command installs the single-tenant Github source:

kubectl apply -f https://github.com/knative-sandbox/eventing-github/releases/download/v0.23.0/github.yaml

The single-tenant GitHub source creates one Knative service per GitHub source.

The following command installs the multi-tenant GitHub source:

kubectl apply -f https://github.com/knative-sandbox/eventing-github/releases/download/v0.23.0/mt-github.yaml

The multi-tenant GitHub source creates only one Knative service handling all GitHub sources in the cluster. This source does not support logging or tracing configuration yet.

To learn more about the Github source, try our sample

The following command installs the Apache Camel-K Source:

kubectl apply -f https://github.com/knative-sandbox/eventing-camel/releases/download/v0.23.0/camel.yaml

To learn more about the Apache Camel-K source, try our sample

The following command installs the Apache Kafka Source:

kubectl apply -f https://github.com/knative-sandbox/eventing-kafka/releases/download/v0.23.0/source.yaml

To learn more about the Apache Kafka source, try our sample

The following command installs the GCP Sources:

# This installs both the Sources and the Channel.
kubectl apply -f https://github.com/google/knative-gcp/releases/download/v0.23.0/cloud-run-events.yaml

To learn more about the Cloud Pub/Sub source, try our sample.

To learn more about the Cloud Storage source, try our sample.

To learn more about the Cloud Scheduler source, try our sample.

To learn more about the Cloud Audit Logs source, try our sample.

The following command installs the Apache CouchDB Source:

kubectl apply -f https://github.com/knative-sandbox/eventing-couchdb/releases/download/v0.23.0/couchdb.yaml

To learn more about the Apache CouchDB source, read the documentation.

The following command installs the VMware Sources and Bindings:

kubectl apply -f https://github.com/vmware-tanzu/sources-for-knative/releases/download/v0.23.0/release.yaml

To learn more about the VMware sources and bindings, try our samples.

Next steps

To easily interact with Knative Services and Eventing components, install the kn CLI

V0.23-Docs: Knative Operator installation

Mon, 01 Jan 0001 00:00:00 +0000

Knative provides a Kubernetes Operator to install, configure and manage Knative. You can install the Serving component, Eventing component, or both on your cluster.

NOTE: The Knative Operator is still in Alpha phase. It has not been tested in a production environment, and should be used for development or test purposes only.

Prerequisites

You have a cluster that uses Kubernetes v1.18 or newer.
You have installed the kubectl CLI.
If you have only one node in your cluster, you will need at least 6 CPUs, 6 GB of memory, and 30 GB of disk storage.
If you have multiple nodes in your cluster, for each node you will need at least 2 CPUs, 4 GB of memory, and 20 GB of disk storage.
Your Kubernetes cluster must have access to the internet, since Kubernetes needs to be able to fetch images, such as gcr.io/knative-releases/knative.dev/operator/cmd/operator:<version>.

You have installed Istio.

Installing the latest release

You can find information about the different released versions of the Knative Operator on the Releases page.

Install the latest stable Operator release:

kubectl apply -f https://github.com/knative/operator/releases/download/v0.23.0/operator.yaml

Verify your installation

Verify your installation:

kubectl get deployment knative-operator

If the operator is installed correctly, the deployment shows a Ready status:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
knative-operator   1/1     1            1           19h

Track the log

Track the log of the operator:

kubectl logs -f deploy/knative-operator

Installing the Knative Serving component

Create and apply the Knative Serving CR:
You can install the latest available Knative Serving in the operator by applying a YAML file containing the following:
```
apiVersion: v1
kind: Namespace
metadata:
 name: knative-serving
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
```
If you do not specify a version by using spec.version, the operator defaults to the latest available version.
You do not need to upgrade the operator to a newer version to install new releases of Knative Serving. If Knative Serving launches a new version, e.g. {{spec.version}}, you can install it by applying a YAML file containing the following:
```
apiVersion: v1
kind: Namespace
metadata:
 name: knative-serving
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  version: {{spec.version}}
  manifests:
    - URL: https://github.com/knative/serving/releases/download/v${VERSION}/serving-core.yaml
    - URL: https://github.com/knative/serving/releases/download/v${VERSION}/serving-hpa.yaml
    - URL: https://github.com/knative/serving/releases/download/v${VERSION}/serving-post-install-jobs.yaml
    - URL: https://github.com/knative/net-istio/releases/download/v${VERSION}/net-istio.yaml
```
The field spec.version is used to set the version of Knative Serving. Replace {{spec.version}} with the correct version number. The tag ${VERSION} is automatically replaced with the version number from spec.version by the operator.

The field spec.manifests is used to specify one or multiple URL links of Knative Serving component. Do not forget to add the valid URL of the Knative network ingress plugin. Knative Serving component is still tightly-coupled with a network ingress plugin in the operator. As in the above example, you can use net-istio. The ordering of the URLs is critical. Put the manifest you want to apply first on the top.
The operator provides you the flexibility to install customized Knative Serving based your own requirements. As long as the manifests of customized Knative Serving are accessible to the operator, they can be installed.

There are two modes available for you to install the customized manifests: overwrite mode and append mode. With the overwrite mode, you need to define all the manifests for Knative Serving to install, because the operator will no long install any available default manifests. With the append mode, you only need to define your customized manifests, and the customized manifests are installed, after default manifests are applied.
1. You can use the overwrite mode to customize all the Knative Serving manifests. For example, the version of the customized Knative Serving is {{spec.version}}, and it is available at https://my-serving/serving.yaml. You choose net-istio as the ingress plugin, which is available at https://my-net-istio/net-istio.yaml. You can create the content of Serving CR as below to install your Knative Serving and the istio ingress:
```
apiVersion: v1
kind: Namespace
metadata:
 name: knative-serving
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  version: {{spec.version}}
  manifests:
    - URL: https://my-serving/serving.yaml
    - URL: https://my-net-istio/net-istio.yaml
```
You can make the customized Knative Serving 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 Serving, by leveraging both spec.version and spec.manifests. Do not skip either field.
1. You can use the append mode to add your customized manifests into the default manifests. For example, you only customize a few resources, and make them available at https://my-serving/serving-custom.yaml. You still need to install the default Knative Serving. In this case, you can create the content of Serving CR as below:
```
apiVersion: v1
kind: Namespace
metadata:
 name: knative-serving
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  version: {{spec.version}}
  additionalManifests:
    - URL: https://my-serving/serving-custom.yaml
```
Knative operator will install the default manifests of Knative Serving at the version {{spec.version}}, and then install your customized manifests based on them.
Verify the Knative Serving deployment:

kubectl get deployment -n knative-serving

If Knative Serving has been successfully deployed, all deployments of the Knative Serving will show READY status. Here is a sample output:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
activator          1/1     1            1           18s
autoscaler         1/1     1            1           18s
autoscaler-hpa     1/1     1            1           14s
controller         1/1     1            1           18s
istio-webhook      1/1     1            1           12s
networking-istio   1/1     1            1           12s
webhook            1/1     1            1           17s

Check the status of Knative Serving Custom Resource:

kubectl get KnativeServing knative-serving -n knative-serving

If Knative Serving is successfully installed, you should see:

NAME              VERSION             READY   REASON
knative-serving   <version number>    True

Installing the Knative Serving component with different network layers

Knative Operator can configure Knative Serving component with different network layer options. Istio is the default network layer, if the ingress is not specified in the Knative Serving CR. Click on each tab below to see how you can configure Knative Serving with different ingresses:

The following commands install Ambassador and enable its Knative integration.

Create a namespace to install Ambassador in:
```
kubectl create namespace ambassador
```

Install Ambassador:

kubectl apply --namespace ambassador \
  --filename https://getambassador.io/yaml/ambassador/ambassador-crds.yaml \
  --filename https://getambassador.io/yaml/ambassador/ambassador-rbac.yaml \
  --filename https://getambassador.io/yaml/ambassador/ambassador-service.yaml

Give Ambassador the required permissions:

kubectl patch clusterrolebinding ambassador -p '{"subjects":[{"kind": "ServiceAccount", "name": "ambassador", "namespace": "ambassador"}]}'

Enable Knative support in Ambassador:

kubectl set env --namespace ambassador  deployments/ambassador AMBASSADOR_KNATIVE_SUPPORT=true

To configure Knative Serving to use Ambassador, apply the content of the Serving CR as below:

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    network:
      ingress.class: "ambassador.ingress.networking.knative.dev"
EOF

Fetch the External IP or CNAME:
```
kubectl --namespace ambassador get service ambassador
```
Save this for configuring DNS below.

The following commands install Contour and enable its Knative integration.

Install a properly configured Contour:

kubectl apply --filename https://github.com/knative/net-contour/releases/download/v0.23.0/contour.yaml

To configure Knative Serving to use Contour, apply the content of the Serving CR as below:

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    contour:
      enabled: true
  config:
    network:
      ingress.class: "contour.ingress.networking.knative.dev"
EOF

Fetch the External IP or CNAME:
```
kubectl --namespace contour-external get service envoy
```
Save this for configuring DNS below.

For a detailed guide on Gloo integration, see Installing Gloo for Knative in the Gloo documentation.

The following commands install Gloo and enable its Knative integration.

Make sure glooctl is installed (version 1.3.x and higher recommended):
```
glooctl version
```
If it is not installed, you can install the latest version using:
```
curl -sL https://run.solo.io/gloo/install | sh
export PATH=$HOME/.gloo/bin:$PATH
```
Or following the Gloo CLI install instructions.

Install Gloo and the Knative integration:

glooctl install knative --install-knative=false

To configure Knative Serving to use Gloo, apply the content of the Serving CR as below:

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
EOF

There is no need to configure the ingress class to use the gloo.

Fetch the External IP or CNAME:
```
glooctl proxy url --name knative-external-proxy
```
Save this for configuring DNS below.

The following commands install Kong and enable its Knative integration.

Install Kong Ingress Controller:

kubectl apply --filename https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/0.9.x/deploy/single/all-in-one-dbless.yaml

To configure Knative Serving to use Kong, apply the content of the Serving CR as below:

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    network:
      ingress.class: "kong"
EOF

Fetch the External IP or CNAME:
```
kubectl --namespace kong get service kong-proxy
```
Save this for configuring DNS below.

The following commands install Kourier and enable its Knative integration.

To configure Knative Serving to use Kourier, apply the content of the Serving CR as below:

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    kourier:
      enabled: true
  config:
    network:
      ingress.class: "kourier.ingress.networking.knative.dev"
EOF

Fetch the External IP or CNAME:
```
kubectl --namespace knative-serving get service kourier
```
Save this for configuring DNS below.

Configure DNS
We ship a simple Kubernetes Job called “default domain” that will (see caveats) configure Knative Serving to use sslip.io as the default DNS suffix.
```
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.23.0/serving-default-domain.yaml
```
Caveat: This will only work if the cluster LoadBalancer service exposes an IPv4 address or hostname, so it will not work with IPv6 clusters or local setups like Minikube. For these, see “Real DNS” or “Temporary DNS”.
To configure DNS for Knative, take the External IP or CNAME from setting up networking, and configure it with your DNS provider as follows:
- If the networking layer produced an External IP address, then configure a wildcard A record for the domain:
```
# Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == A 35.233.41.212
```
- If the networking layer produced a CNAME, then configure a CNAME record for the domain:
```
# Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == CNAME a317a278525d111e89f272a164fd35fb-1510370581.eu-central-1.elb.amazonaws.com
```
Once your DNS provider has been configured, add the following section into your existing Serving CR, and apply it:
```
# Replace knative.example.com with your domain suffix
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    domain:
      "knative.example.com": ""
  ...
```
If you are using curl to access the sample applications, or your own Knative app, and are unable to use the “Magic DNS (sslip.io)” or “Real DNS” methods, there is a temporary approach. This is useful for those who wish to evaluate Knative without altering their DNS configuration, as per the “Real DNS” method, or cannot use the “Magic DNS” method due to using, for example, minikube locally or IPv6 clusters.

To access your application using curl using this method:
1. After starting your application, get the URL of your application:
  kubectl get ksvc
  The output should be similar to:
  NAME URL LATESTCREATED LATESTREADY READY REASON helloworld-go http://helloworld-go.default.example.com helloworld-go-vqjlf helloworld-go-vqjlf True
2. Instruct curl to connect to the External IP or CNAME defined by the networking layer in section 3 above, and use the -H "Host:" command-line option to specify the Knative application’s host name. For example, if the networking layer defines your External IP and port to be http://192.168.39.228:32198 and you wish to access the above helloworld-go application, use:
  curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198
  In the case of the provided helloworld-go sample application, using the default configuration, the output should be:
```
Hello Go Sample v1!
```
Refer to the “Real DNS” method for a permanent solution.
Monitor the Knative components until all of the components show a STATUS of Running or Completed:
```
kubectl get pods --namespace knative-serving
```

Installing the Knative Eventing component

Create and apply the Knative Eventing CR:
You can install the latest available Knative Eventing in the operator by applying a YAML file containing the following:
```
apiVersion: v1
kind: Namespace
metadata:
 name: knative-eventing
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
```
If you do not specify a version by using spec.version, the operator defaults to the latest available version.
You do not need to upgrade the operator to a newer version to install new releases of Knative Eventing. If Knative Eventing launches a new version, e.g. {{spec.version}}, you can install it by applying a YAML file containing the following:
```
apiVersion: v1
kind: Namespace
metadata:
 name: knative-eventing
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: {{spec.version}}
  manifests:
    - URL: https://github.com/knative/eventing/releases/download/v${VERSION}/eventing.yaml
    - URL: https://github.com/knative/eventing/releases/download/v${VERSION}/eventing-post-install-jobs.yaml
```
The field spec.version is used to set the version of Knative Eventing. Replace {{spec.version}} with the correct version number. The tag ${VERSION} is automatically replaced with the version number from spec.version by the operator.

The field spec.manifests is used to specify one or multiple URL links of Knative Eventing component. Do not forget to add the valid URL of the Knative network ingress plugin. The ordering of the URLs is critical. Put the manifest you want to apply first on the top.
The operator provides you the flexibility to install customized Knative Eventing based your own requirements. As long as the manifests of customized Knative Eventing are accessible to the operator, they can be installed.

There are two modes available for you to install the customized manifests: overwrite mode and append mode. With the overwrite mode, you need to define all the manifests for Knative Eventing to install, because the operator will no long install any available default manifests. With the append mode, you only need to define your customized manifests, and the customized manifests are installed, after default manifests are applied.
1. You can use the overwrite mode to customize all the Knative Eventing manifests. For example, the version of the customized Knative Eventing is {{spec.version}}, and it is available at https://my-eventing/eventing.yaml. You can create the content of Eventing CR as below to install your Knative Eventing:
```
apiVersion: v1
kind: Namespace
metadata:
 name: knative-eventing
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: {{spec.version}}
  manifests:
    - URL: https://my-eventing/eventing.yaml
```
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.
1. You can use the append mode to add your customized manifests into the default manifests. For example, you only customize a few resources, and make them available at https://my-eventing/eventing-custom.yaml. You still need to install the default Knative eventing. In this case, you can create the content of Eventing CR as below:
```
apiVersion: v1
kind: Namespace
metadata:
 name: knative-eventing
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: {{spec.version}}
  additionalManifests:
    - URL: https://my-eventing/eventing-custom.yaml
```
Knative operator will install the default manifests of Knative Eventing at the version {{spec.version}}, and then install your customized manifests based on them.
Verify the Knative Eventing deployment:

kubectl get deployment -n knative-eventing

If Knative Eventing has been successfully deployed, all deployments of the Knative Eventing will show READY status. Here is a sample output:

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
broker-controller      1/1     1            1           63s
broker-filter          1/1     1            1           62s
broker-ingress         1/1     1            1           62s
eventing-controller    1/1     1            1           67s
eventing-webhook       1/1     1            1           67s
imc-controller         1/1     1            1           59s
imc-dispatcher         1/1     1            1           59s
mt-broker-controller   1/1     1            1           62s

Check the status of Knative Eventing Custom Resource:

kubectl get KnativeEventing knative-eventing -n knative-eventing

If Knative Eventing is successfully installed, you should see:

NAME               VERSION             READY   REASON
knative-eventing   <version number>    True

What’s next

V0.23-Docs: Installing Istio for Knative

Mon, 01 Jan 0001 00:00:00 +0000

This guide walks you through manually installing and customizing Istio for use with Knative.

If your cloud platform offers a managed Istio installation, we recommend installing Istio that way, unless you need to customize your installation.

Before you begin

You need:

A Kubernetes cluster created.
istioctl (v1.7 or later) installed.

Supported Istio versions

The current known-to-be-stable version of Istio tested in conjunction with Knative is v1.8.2. Versions in the 1.7 line are generally fine too. 1.8.0 and 1.8.1 have bugs that don’t work with Knative.

Installing Istio

When you install Istio, there are a few options depending on your goals. For a basic Istio installation suitable for most Knative use cases, follow the Installing Istio without sidecar injection instructions. If you’re familiar with Istio and know what kind of installation you want, read through the options and choose the installation that suits your needs.

You can easily customize your Istio installation with istioctl. The below sections cover a few useful Istio configurations and their benefits.

Choosing an Istio installation

You can install Istio with or without a service mesh:

Installing Istio without sidecar injection(Recommended default installation)
Installing Istio with sidecar injection

If you want to get up and running with Knative quickly, we recommend installing Istio without automatic sidecar injection. This install is also recommended for users who don’t need the Istio service mesh, or who want to enable the service mesh by manually injecting the Istio sidecars.

Installing Istio without sidecar injection

Run the following comand to install Istio.

istioctl install -y

Installing Istio with sidecar injection

If you want to enable the Istio service mesh, you must enable automatic sidecar injection. The Istio service mesh provides a few benefits:

Allows you to turn on mutual TLS, which secures service-to-service traffic within the cluster.
Allows you to use the Istio authorization policy, controlling the access to each Knative service based on Istio service roles.

To automatic sidecar injection, set autoInject: enabled in addition to above operator configuration.

    global:
      proxy:
        autoInject: enabled

Using Istio mTLS feature

Since there are some networking communications between knative-serving namespace and the namespace where your services running on, you need additional preparations for mTLS enabled environment.

Enable sidecar container on knative-serving system namespace.

kubectl label namespace knative-serving istio-injection=enabled

Set PeerAuthentication to PERMISSIVE on knative-serving system namespace.

cat <<EOF | kubectl apply -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "knative-serving"
spec:
  mtls:
    mode: PERMISSIVE
EOF

After you install the cluster local gateway, your service and deployment for the local gateway is named knative-local-gateway.

Updating the `config-istio` configmap to use a non-default local gateway

If you create a custom service and deployment for local gateway with a name other than knative-local-gateway, you need to update gateway configmap config-istio under the knative-serving namespace.

Edit the config-istio configmap:

kubectl edit configmap config-istio -n knative-serving

Replace the local-gateway.knative-serving.knative-local-gateway field with the custom service. As an example, if you name both the service and deployment custom-local-gateway under the namespace istio-system, it should be updated to:

custom-local-gateway.istio-system.svc.cluster.local

As an example, if both the custom service and deployment are labeled with custom: custom-local-gateway, not the default istio: knative-local-gateway, you must update gateway instance knative-local-gateway in the knative-serving namespace:

kubectl edit gateway knative-local-gateway -n knative-serving

Replace the label selector with the label of your service:

istio: knative-local-gateway

For the service above, it should be updated to:

custom: custom-local-gateway

If there is a change in service ports (compared to that of knative-local-gateway), update the port info in the gateway accordingly.

Verifying your Istio install

View the status of your Istio installation to make sure the install was successful. It might take a few seconds, so rerun the following command until all of the pods show a STATUS of Running or Completed:

kubectl get pods --namespace istio-system

Tip: You can append the --watch flag to the kubectl get commands to view the pod status in realtime. You use CTRL + C to exit watch mode.

Configuring DNS

Knative dispatches to different services based on their hostname, so it is recommended to have DNS properly configured.

To do this, begin by looking up the external IP address that Istio received:

$ kubectl get svc -nistio-system
NAME                    TYPE           CLUSTER-IP   EXTERNAL-IP    PORT(S)                                      AGE
istio-ingressgateway    LoadBalancer   10.0.2.24    34.83.80.117   15020:32206/TCP,80:30742/TCP,443:30996/TCP   2m14s
istio-pilot             ClusterIP      10.0.3.27    <none>         15010/TCP,15011/TCP,8080/TCP,15014/TCP       2m14s

This external IP can be used with your DNS provider with a wildcard A record. However, for a basic non-production set up, this external IP address can be used with sslip.io in the config-domain ConfigMap in knative-serving.

You can edit this by using the following command:

kubectl edit cm config-domain --namespace knative-serving

Given the external IP above, change the content to:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-domain
  namespace: knative-serving
data:
  # sslip.io is a "magic" DNS provider, which resolves all DNS lookups for:
  # *.{ip}.sslip.io to {ip}.
  34.83.80.117.sslip.io: ""

Istio resources

For the official Istio installation guide, see the Istio Kubernetes Getting Started Guide.
For the full list of available configs when installing Istio with istioctl, see the Istio Installation Options reference.

Clean up Istio

See the Uninstall Istio.

What’s next

Try the Getting Started with App Deployment guide for Knative serving.

V0.23-Docs: Checking the version of your Knative components

Mon, 01 Jan 0001 00:00:00 +0000

To obtain the version of the Knative component that you have running on your cluster, you query for the [component].knative.dev/release label with the following commands:

Knative Serving

kubectl get namespace knative-serving -o 'go-template={{index .metadata.labels "serving.knative.dev/release"}}'

Knative Eventing

kubectl get namespace knative-eventing -o 'go-template={{index .metadata.labels "eventing.knative.dev/release"}}'

V0.23-Docs: Configuring the Serving Operator Custom Resource

Mon, 01 Jan 0001 00:00:00 +0000

The Knative Serving operator can be configured with these options:

Version Configuration

Cluster administrators can install a specific version of Knative Serving by using the spec.version field. For example, if you want to install Knative Serving 0.16.0, you can apply the following KnativeServing custom resource:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  version: 0.16.0

If spec.version is not specified, the Knative Operator will install the latest available version of Knative Serving. 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. For example, if the current version of the Knative Operator is 0.16.x, the earliest version of Knative Serving available through the Operator is 0.14.0.

If Knative Serving is already managed by the Operator, updating the spec.version field in the KnativeServing resource enables upgrading or downgrading the Knative Serving version, without needing to change 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 Serving deployment is version 0.14.x, you must upgrade to 0.15.x before upgrading to 0.16.x.

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, you can see the content of the ConfigMap config-domain is:

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:

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 specify imagePullSecrets:

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.

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 docker.io/knative-images/${NAME}:{CUSTOM-TAG}.

In the example below:

the custom tag v0.13.0 is used for all images
all image links are accessible without using secrets
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:

Container	Docker Image
`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`
`networking-istio`	`docker.io/knative-images/networking-istio: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:

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:

Container	Docker Image
`activator`	`docker.io/knative-images-repo1/activator:v0.13.0`
`autoscaler`	`docker.io/knative-images-repo2/autoscaler:v0.13.0`
`controller`	`docker.io/knative-images-repo3/controller:v0.13.0`
`webhook`	`docker.io/knative-images-repo4/webhook:v0.13.0`
`autoscaler-hpa`	`docker.io/knative-images-repo5/autoscaler-hpa:v0.13.0`
`networking-istio`	`docker.io/knative-images-repo6/prefix-networking-istio:v0.13.0`
`queue-proxy`	`docker.io/knative-images-repo7/queue-proxy-suffix:v0.13.0`

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

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  registry:
    override:
      activator: docker.io/knative-images-repo1/activator:v0.13.0
      autoscaler: docker.io/knative-images-repo2/autoscaler:v0.13.0
      controller: docker.io/knative-images-repo3/controller:v0.13.0
      webhook: docker.io/knative-images-repo4/webhook:v0.13.0
      autoscaler-hpa: docker.io/knative-images-repo5/autoscaler-hpa:v0.13.0
      networking-istio: docker.io/knative-images-repo6/prefix-networking-istio:v0.13.0
      queue-proxy: docker.io/knative-images-repo7/queue-proxy-suffix:v0.13.0

Download images with secrets:

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:

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

SSL certificate for controller

To enable tag to digest resolution, 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

To set up custom ingress gateway, follow Step 1: Create Gateway Service and Deployment Instance.

Step 2: Update the Knative gateway

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

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    istio:
      enabled: true
      knative-ingress-gateway:
        selector:
          custom: ingressgateway

Step 3: Update Gateway ConfigMap

Additionally, you will need to update the Istio ConfigMap:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    istio:
      enabled: true
      knative-ingress-gateway:
        selector:
          custom: ingressgateway
  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}}.

Configuration of cluster local gateway

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

Default local gateway name:

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

Non-default local gateway name:

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

This example shows a service and deployment knative-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:
  ingress:
    istio:
      enabled: true
      knative-local-gateway:
        selector:
          custom: custom-local-gateway
  config:
    istio:
      local-gateway.knative-serving.knative-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 leader-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

System Resource Settings

The operator custom resource 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 Kubernetes resource settings.

For example, the following KnativeServing resource configures the activator to request 0.3 CPU and 100MB of RAM, and sets hard limits of 1 CPU, 250MB RAM, and 4GB of local storage:

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

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
      memory: 250Mi
      ephemeral-storage: 4Gi

Override system deployments

If you would like to override some configurations for a specific deployment, you can override the configuration by using spec.deployments in CR. Currently replicas, labels and annotations are supported.

For example, the following KnativeServing resource overrides the webhook to have 3 replicass, mylabel: foo labels and myannotataions: bar annotations, while other system deployments have 2 replicas by spec.high-availability.

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: ks
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2
  deployments:
  - name: webhook
    replicas: 3
    labels:
      mylabel: foo
    annotations:
      myannotataions: bar

NOTE: The labels and annotations settings override webhook’s labels and annotations in deployment and pod both.

V0.23-Docs: Installation files

Mon, 01 Jan 0001 00:00:00 +0000

This guide provides reference information about the YAML files in the Knative Serving and Eventing releases.

The YAML files in the releases include:

The custom resource definitions (CRDs) and core components required to install Knative.
Optional components that you can apply to customize your installation.

For information about installing these files, see Installing Serving using YAML files and Installing Eventing using YAML files.

Knative Serving installation files

The table below describes the installation files in the Knative Serving release:

File name	Description	Dependencies
serving-core.yaml	Required: Knative Serving core components.	serving-crds.yaml
serving-crds.yaml	Required: Knative Serving core CRDs.	none
serving-default-domain.yaml	Configures Knative Serving to use http://sslip.io as the default DNS suffix.	serving-core.yaml
serving-domainmapping-crds.yaml	CRDs used by the Domain Mapping feature.	none
serving-domainmapping.yaml	Components used by the Domain Mapping feature.	serving-domainmapping-crds.yaml
serving-hpa.yaml	Components to autoscale Knative revisions through the Kubernetes Horizontal Pod Autoscaler.	serving-core.yaml
serving-nscert.yaml	Components to provision TLS wildcard certificates.	serving-core.yaml
serving-post-install-jobs.yaml	Additional jobs after installing `serving-core.yaml`. Currently it is the same as `serving-storage-version-migration.yaml`.	serving-core.yaml
serving-storage-version-migration.yaml	Migrates the storage version of Knative resources, including Service, Route, Revision, and Configuration, from `v1alpha1` and `v1beta1` to `v1`. Required by upgrade from version 0.18 to 0.19.	serving-core.yaml

Knative Eventing installation files

The table below describes the installation files in the Knative Eventing release:

File name	Description	Dependencies
eventing-core.yaml	Required: Knative Eventing core components.	eventing-crds.yaml
eventing-crds.yaml	Required: Knative Eventing core CRDs.	none
eventing-post-install.yaml	Jobs required for upgrading to a new minor version.	eventing-core.yaml, eventing-crds.yaml
eventing-sugar-controller.yaml	Reconciler that watches for labels and annotations on certain resources to inject eventing components.	eventing-core.yaml
eventing.yaml	Combines `eventing-core.yaml`, `mt-channel-broker.yaml`, and `in-memory-channel.yaml`.	none
in-memory-channel.yaml	Components to configure In-Memory Channels.	eventing-core.yaml
mt-channel-broker.yaml	Components to configure Multi-Tenant (MT) Channel Broker.	eventing-core.yaml

V0.23-Docs: Collecting Logs with Fluentbit

Mon, 01 Jan 0001 00:00:00 +0000

This document describes how to set up Fluent Bit, a log processor and forwarder, to collect your kubernetes logs in a central directory. This is not required for running Knative, but can be helpful with Knative Serving, which will automatically delete pods (and their associated logs) when they are no longer needed. Note that Fluent Bit supports exporting to a number of other log providers; if you already have an existing log provider (for example, Splunk, Datadog, ElasticSearch, or Stackdriver), then you may only need the second part of setting up and configuring log forwarders.

Setting up log collection consists of two pieces: running a log forwarding DaemonSet on each node, and running a collector somewhere in the cluster (in our example, we use a StatefulSet which stores logs on a Kubernetes PersistentVolumeClaim, but you could also use a HostPath).

Setting up the collector

It’s useful to set up the collector before the forwarders, because you’ll need the address of the collector when configuring the forwarders, and the forwarders may queue logs until the collector is ready.

The fluent-bit-collector.yaml defines a StatefulSet as well as a Kubernetes Service which allows accessing and reading the logs from within the cluster. The supplied configuration will create the monitoring configuration in a namespace called logging. You can apply the configuration with:

kubectl apply --filename https://github.com/knative/docs/raw/main/docs/install/collecting-logs/fluent-bit-collector.yaml

The default configuration will classify logs into Knative, apps (pods with an app= label which aren’t Knative), and the default to logging with the pod name; this can be changed by updating the log-collector-config ConfigMap before or after installation. Once the ConfigMap is updated, you’ll need to restart Fluent Bit (for example, by deleting the pod and letting the StatefulSet recreate it).

To access the logs through your web browser:

kubectl port-forward --namespace logging service/log-collector 8080:80

And then visit http://localhost:8080/.

You can also open a shell in the nginx pod and search the logs using unix tools:

kubectl exec --namespace logging --stdin --tty --container nginx log-collector-0

Setting up the forwarders

For the most part, you can follow the Fluent Bit directions for installing on Kubernetes. Those directions will set up a Fluent Bit DaemonSet which forwards logs to ElasticSearch by default; when the directions call for creating the ConfigMap, you’ll want to either replace the elasticsearch configuration with this fluent-bit-configmap.yaml or add the following block to the ConfigMap and update the @INCLUDE output-elasticsearch.conf to be @INCLUDE output-forward.conf.

output-forward.conf: |
  [OUTPUT]
      Name            forward
      Host            log-collector.logging
      Port            24224
      Require_ack_response  True

If you are using a different log collection infrastructure (Splunk, for example), follow the directions in the FluentBit documentation on how to configure your forwarders.

Local collector

NOTE: This describes a development environment setup, and is not appropriate for production.

If you are using a local Kubernetes cluster for development (Kind, Docker Desktop, or Minikube), you can create a hostPath PersistentVolume to store the logs on your desktop OS. This will allow you to use all your normal desktop tools on the files without needing Kubernetes-specific tools.

The PersistentVolumeClaim will look something like this, but the hostPath will vary based on your Kubernetes software and host operating system. Some example values are documented below.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-logs
  labels:
    app: logs-collector
spec:
  accessModes:
    - "ReadWriteOnce"
  storageClassName: manual
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: logs-log-collector-0
    namespace: logging
  capacity:
    storage: 5Gi
  hostPath:
    path: <see below>

And then you’ll need to update the StatefulSet’s volumeClaimTemplates to reference the shared-logs volume, like this fragment of yaml:

volumeClaimTemplates:
  metadata:
    name: logs
  spec:
    accessModes: ["ReadWriteOnce"]
    volumeName: shared-logs

Kind

When creating your cluster, you’ll need to use a kind-config.yaml and specify extraMounts for each node, like so:

apiversion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
  - role: control-plane
    extraMounts:
      - hostPath: ./logs
        containerPath: /shared/logs
  - role: worker
    extraMounts:
      - hostPath: ./logs
        containerPath: /shared/logs

You can then use /shared/logs as the spec.hostPath.path in your PersistentVolume. Note that the directory path ./logs is relative to the directory that the Kind cluster was created in.

Docker Desktop

Docker desktop automatically creates some shared mounts between the host and the guest operating systems, so you only need to know the path to your home directory. Here are some examples for different operating systems:

Host OS	`hostPath`
Mac OS	`/Users/${USER}`
Windows	`/run/desktop/mnt/host/c/Users/${USER}/`
Linux	`/home/${USER}`

Minikube

Minikube requires an explicit command to mount a directory into the VM running Kubernetes. This command mounts the logs directory inside the current directory onto /mnt/logs in the VM:

minikube mount ./logs:/mnt/logs

You would then reference /mnt/logs as the hostPath.path in the PersistentVolume.

V0.23-Docs: Collecting Metrics with OpenTelemetry

Mon, 01 Jan 0001 00:00:00 +0000

This document describes how to set up the OpenTelemetry Collector to receive metrics from the Knative infrastructure components and distribute them to Prometheus. OpenTelemetry is a CNCF an observability framework for cloud-native software. The project provides a collection of tools, APIs, and SDKs. You use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) for analysis in order to understand your software’s performance and behavior. OpenTelemetry allows Knative to build provider-agnostic instrumentation into the platform, so that it’s easy to export metrics to multiple monitoring services without needing to rebuild or reconfigure the Knative binaries.

Setting up the collector

The collector provides a long-lived location where various Knative components can push metrics (and eventually traces) to be retained and collected by a monitoring service. For this example, we’ll configure a single collector instance using a ConfigMap and a Deployment. For more complex deployments, some of this can be automated using the opentelemetry-operator, but it’s also easy to manage this service directly. Note that you can attach other components (node agents, other services); this is just a simple sample.

First, create a namespace for the collector to run in:
```
kubectl create namespace metrics
```

And then create a Deployment, Service, and ConfigMap for the collector:

kubectl apply --filename https://raw.githubusercontent.com/knative/docs/master/docs/install/collecting-metrics/collector.yaml

Finally, update the config-observability ConfigMap in Knative Serving and Eventing

kubectl patch --namespace knative-serving configmap/config-observability \
  --type merge \
  --patch '{"data":{"metrics.backend-destination":"opencensus","request-metrics-backend-destination":"opencensus","metrics.opencensus-address":"otel-collector.metrics:55678"}}'
kubectl patch --namespace knative-eventing configmap/config-observability \
  --type merge \
  --patch '{"data":{"metrics.backend-destination":"opencensus","metrics.opencensus-address":"otel-collector.metrics:55678"}}'

You can check that metrics are being forwarded by loading the Prometheus export port on the collector:

kubectl port-forward --namespace metrics deployment/otel-collector 8889

And then fetch http://localhost:8889/metrics to see the exported metrics.

Setting up Prometheus

Prometheus is an open-source tool for collecting and aggregating timeseries metrics. Full configuration of Prometheus can be found at the website, but this document will provide a simple setup for scraping the OpenTelemetry Collector we set up in the previous section.

Install the Prometheus Operator. Note that the provided manifest installs the operator into the default namespace. If you want to install into another namespace, you’ll need to download the YAML manifest and update all the namespace references to your target namespace.
```
kubectl apply --filename https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/master/bundle.yaml
```
You’ll then need to set up a ServiceMonitor object to track the OpenTelemetry Collector, as well as a ServiceAccount with the ability to read Kubernetes services and pods (so that Prometheus can track the resource endpoints) and finally a Prometheus object to instantiate the actual Prometheus instance.
```
kubectl apply --filename prometheus.yaml
```

By default, the Prometheus instance will only be exposed on a private service named prometheus-operated; to access the console in your web browser, run:

kubectl port-forward --namespace metrics service/prometheus-operated 9090

And then access the console in your browser via http://localhost:9090.

V0.23-Docs: Configuring the Eventing Operator custom resource

Mon, 01 Jan 0001 00:00:00 +0000

You can configure the Knative Eventing operator by modifying settings in the KnativeEventing custom resource (CR).

NOTE: Kubernetes spec level policies cannot be configured using the Knative Operators.

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:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: 0.19.0

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.

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.

You can do this by modifying the KnativeEventing CR:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  config:
    default-ch-webhook:
      default-ch-config: |
        clusterDefault:
          apiVersion: messaging.knative.dev/v1beta1
          kind: KafkaChannel
          spec:
            numPartitions: 10
            replicationFactor: 1
        namespaceDefaults:
          my-namespace:
            apiVersion: messaging.knative.dev/v1
            kind: InMemoryChannel
            spec:
              delivery:
                backoffDelay: PT0.5S
                backoffPolicy: exponential
                retry: 5

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.

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.

You can do this by modifying the KnativeEventing CR:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  config:
    config-br-default-channel:
      channelTemplateSpec: |
        apiVersion: messaging.knative.dev/v1beta1
        kind: KafkaChannel
        spec:
          numPartitions: 6
          replicationFactor: 1

Private repository and private secrets

The Knative Eventing Operator CR is configured the same way as the Knative Serving Operator CR. See the documentation on Private repository and private secret.

Knative Eventing also specifies only one container within each Deployment resource. However, the container does not use the same name as its parent Deployment, which means that the container name in Knative Eventing is not the same unique identifier as it is in Knative Serving.

List of containers within each Deployment resource:

Component	Deployment name	Container name
Core eventing	`eventing-controller`	`eventing-controller`
Core eventing	`eventing-webhook`	`eventing-webhook`
Eventing Broker	`broker-controller`	`eventing-controller`
In-Memory Channel	`imc-controller`	`controller`
In-Memory Channel	`imc-dispatcher`	`dispatcher`

The default field can still be used to replace the images in a predefined format. However, if the container name is not a unique identifier, for example eventing-controller, you must use the override field to replace it, by specifying deployment/container as the unique key.

Some images are defined by using the environment variable in Knative Eventing. They can be replaced by taking advantage of the override field.

Download images in a predefined format without secrets

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

In the example below:

The custom tag latest is used for all images.
All image links are accessible without using secrets.
Images are defined in the accepted format docker.io/knative-images/${NAME}:{CUSTOM-TAG}.

Push images to the following image tags:

Deployment	Container	Docker image
`eventing-controller`	`eventing-controller`	`docker.io/knative-images/eventing-controller:latest`
	`eventing-webhook`	`docker.io/knative-images/eventing-webhook:latest`
`broker-controller`	`eventing-controller`	`docker.io/knative-images/broker-eventing-controller:latest`
	`controller`	`docker.io/knative-images/controller:latest`
	`dispatcher`	`docker.io/knative-images/dispatcher:latest`

Define your the KnativeEventing CR with following content:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  registry:
    default: docker.io/knative-images/${NAME}:latest
    override:
      broker-controller/eventing-controller: docker.io/knative-images-repo1/broker-eventing-controller:latest

- `${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`
field to specify individually, by using `broker-controller/eventing-controller` as the key.

Download images from different repositories without secrets

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:

Deployment	Container	Docker Image
`eventing-controller`	`eventing-controller`	`docker.io/knative-images/eventing-controller:latest`
	`eventing-webhook`	`docker.io/knative-images/eventing-webhook:latest`
	`controller`	`docker.io/knative-images/controller:latest`
	`dispatcher`	`docker.io/knative-images/dispatcher:latest`
`broker-controller`	`eventing-controller`	`docker.io/knative-images/broker-eventing-controller:latest`

The KnativeEventing CR must be modified to include the full list. For example:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  registry:
    override:
      eventing-controller/eventing-controller: docker.io/knative-images-repo1/eventing-controller:latest
      eventing-webhook/eventing-webhook: docker.io/knative-images-repo2/eventing-webhook:latest
      imc-controller/controller: docker.io/knative-images-repo3/imc-controller:latest
      imc-dispatcher/dispatcher: docker.io/knative-images-repo4/imc-dispatcher:latest
      broker-controller/eventing-controller: docker.io/knative-images-repo5/broker-eventing-controller:latest

If you want to replace the image defined by the environment variable, you must modify the KnativeEventing CR. For example, if you want to replace the image defined by the environment variable DISPATCHER_IMAGE, in the container controller, of the deployment imc-controller, and the target image is docker.io/knative-images-repo5/DISPATCHER_IMAGE:latest, the KnativeEventing CR would be as follows:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  registry:
    override:
      eventing-controller/eventing-controller: docker.io/knative-images-repo1/eventing-controller:latest
      eventing-webhook/eventing-webhook: docker.io/knative-images-repo2/eventing-webhook:latest
      imc-controller/controller: docker.io/knative-images-repo3/imc-controller:latest
      imc-dispatcher/dispatcher: docker.io/knative-images-repo4/imc-dispatcher:latest
      broker-controller/eventing-controller: docker.io/knative-images-repo5/broker-eventing-controller:latest
      DISPATCHER_IMAGE: docker.io/knative-images-repo5/DISPATCHER_IMAGE:latest

Download images with secrets

If your image repository requires private secrets for access, you must append the imagePullSecrets attribute to the KnativeEventing CR.

This example uses a secret named regcred. Refer to the Kubernetes documentation to create your own private secrets.

After you create the secret, edit the KnativeEventing CR:

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

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

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

Configuring the default broker class

Knative Eventing allows you to define a default broker class when the user does not specify one. The Operator provides two broker classes by default: ChannelBasedBroker and MTChannelBasedBroker.

The field defaultBrokerClass indicates which class to use; if empty, the ChannelBasedBroker is used.

The following example CR specifies MTChannelBasedBroker as the default:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  defaultBrokerClass: MTChannelBasedBroker

System resource settings

The KnativeEventing CR allows you to configure system resources for Knative system containers.

Requests and limits can be configured for the following containers:

eventing-controller
eventing-webhook
imc-controller
imc-dispatcher
mt-broker-ingress
mt-broker-ingress
mt-broker-controller

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

For example, the following KnativeEventing CR configures the eventing-webhook container to request 0.3 CPU and 100MB of RAM, and sets hard limits of 1 CPU, 250MB RAM, and 4GB of local storage:

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  resources:
  - container: eventing-webhook
    requests:
      cpu: 300m
      memory: 100Mi
    limits:
      cpu: 1000m
      memory: 250Mi

Knative – Installing Knative

V0.23-Docs: Prerequisites

System requirements

Prerequisites

Next Steps: Install Knative Serving and Eventing

V0.23-Docs: Installing Knative Serving using YAML files

Prerequisites

Install the Serving component

Install a networking layer

Verify the installation

Configure DNS

Next steps

V0.23-Docs: Installing Knative Eventing using YAML files

Prerequisites

Install the Eventing component

Verify the installation

Optional: Install a default channel (messaging) layer

Optional: Install a broker layer:

Next steps

V0.23-Docs: Installing optional extensions

Prerequisites

Install optional Serving extensions

Install optional Eventing extensions

Next steps

V0.23-Docs: Knative Operator installation

Prerequisites

Installing the latest release

Verify your installation

Track the log

Installing the Knative Serving component

Installing the Knative Serving component with different network layers

Installing the Knative Eventing component

What’s next

V0.23-Docs: Installing Istio for Knative

Before you begin

Supported Istio versions

Installing Istio

Choosing an Istio installation

Installing Istio without sidecar injection

Installing Istio with sidecar injection

Using Istio mTLS feature

Updating the config-istio configmap to use a non-default local gateway

Verifying your Istio install

Configuring DNS

Istio resources

Clean up Istio

What’s next

V0.23-Docs: Checking the version of your Knative components

V0.23-Docs: Configuring the Serving Operator Custom Resource

Version Configuration

Serving Configuration by ConfigMap

Private repository and private secrets

Download images in a predefined format without secrets:

Download images individually without secrets:

Download images with secrets:

SSL certificate for controller

Configuration of Knative ingress gateway

Step 2: Update the Knative gateway

Step 3: Update Gateway ConfigMap

Configuration of cluster local gateway

Default local gateway name:

Non-default local gateway name:

High availability

System Resource Settings

Override system deployments

V0.23-Docs: Installation files

Knative Serving installation files

Knative Eventing installation files

V0.23-Docs: Collecting Logs with Fluentbit

Setting up the collector

Setting up the forwarders

Local collector

Kind

Docker Desktop

Minikube

V0.23-Docs: Collecting Metrics with OpenTelemetry

Setting up the collector

Setting up Prometheus

V0.23-Docs: Configuring the Eventing Operator custom resource

Installing a specific version of Eventing

Updating the `config-istio` configmap to use a non-default local gateway