Install by using the Knative Operator¶

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

The following table describes the supported versions of Serving and Eventing for the Knative Operator:

Prerequisites¶

Before installing Knative, you must meet the following prerequisites:

• For prototyping purposes, Knative works on most local deployments of Kubernetes. For example, you can use a local, one-node cluster that has 3 CPUs and 4 GB of memory.

  Tip

  You can install a local distribution of Knative for development purposes using the Knative Quickstart plugin

• For production purposes, it is recommended that:

  • If you have only one node in your cluster, you 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 need at least 2 CPUs, 4 GB of memory, and 20 GB of disk storage.
  • You have a cluster that uses Kubernetes v1.28 or newer.
  • You have installed the kubectl CLI.
  • Your Kubernetes cluster must have access to the internet, because Kubernetes needs to be able to fetch images. To pull from a private registry, see Deploying images from a private container registry.

Verifying image signatures¶

Knative releases from 1.9 onwards are signed with cosign.

1. Install cosign and jq.

2. Extract the images from a manifeset and verify the signatures.

curl -sSL https://github.com/knative/serving/releases/download/knative-v1.16.0/serving-core.yaml \
  | grep 'gcr.io/' | awk '{print $2}' | sort | uniq \
  | xargs -n 1 \
    cosign verify -o text \
      --certificate-identity=signer@knative-releases.iam.gserviceaccount.com \
      --certificate-oidc-issuer=https://accounts.google.com

Install the Knative Operator¶

Before you install the Knative Serving and Eventing components, first install the Knative Operator.

kubectl create -f https://github.com/knative/operator/releases/download/knative-v1.5.1/operator-post-install.yaml

To install the latest stable Operator release, run the command:

kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.16.0/operator.yaml

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

Verify your Knative Operator installation¶

1. Because the Operator is installed to the default namespace, ensure you set the current namespace to default by running the command:

   kubectl config set-context --current --namespace=default
   

2. Check the Operator deployment status by running the command:

   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¶

To track the log of the Operator, run the command:

kubectl logs -f deploy/knative-operator

Install Knative Serving¶

To install Knative Serving you must create a custom resource (CR), add a networking layer to the CR, and configure DNS.

Create the Knative Serving custom resource¶

To create the custom resource for the latest available Knative Serving in the Operator:

1. Copy the following YAML into a file:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: knative-serving
   ---
   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   

   Note

   When you don't specify a version by using spec.version field, the Operator defaults to the latest available version.

2. Apply the YAML file by running the command:

   kubectl apply -f <filename>.yaml
   

   Where <filename> is the name of the file you created in the previous step.

Install the networking layer¶

Knative Operator can configure the 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. If you choose to use the default Istio network layer, you must install Istio on your cluster. Because of this, you might find it easier to configure Kourier as your networking layer.

Click on each of the following tabs to see how you can configure Knative Serving with different ingresses:

Verify the Knative Serving deployment¶

1. Monitor the Knative deployments:

   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
   domain-mapping         1/1     1            1           12s
   domainmapping-webhook  1/1     1            1           12s
   webhook                1/1     1            1           17s
   

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

Configure DNS¶

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

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

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

Install Knative Eventing¶

To install Knative Eventing you must apply the custom resource (CR). Optionally, you can install the Knative Eventing component with different event sources.

Create the Knative Eventing custom resource¶

To create the custom resource for the latest available Knative Eventing in the Operator:

1. Copy the following YAML into a file:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: knative-eventing
   ---
   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeEventing
   metadata:
     name: knative-eventing
     namespace: knative-eventing
   

   Note

   When you do not specify a version by using spec.version field, the Operator defaults to the latest available version.

2. Apply the YAML file by running the command:

   kubectl apply -f <filename>.yaml
   

Where <filename> is the name of the file you created in the previous step.

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 v1.7, you can apply the following KnativeEventing CR:

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: "1.7"

You can also run the following command to make the equivalent change:

kn operator install --component eventing -v 1.7 -n knative-eventing

If spec.version is not specified, the Knative Operator installs 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 1.4, you must upgrade to 1.5 before upgrading to 1.6.

Installing customized Knative Eventing¶

The Operator provides you with the flexibility to install Knative Eventing customized to your own requirements. As long as the manifests of customized Knative Eventing are accessible to the Operator, you can install them.

There are two modes available for you to install customized manifests: overwrite mode and append mode. With overwrite mode, under .spec.manifests, you must define all manifests needed for Knative Eventing to install because the Operator will no longer install any default manifests. With append mode, under .spec.additionalManifests, you only need to define your customized manifests. The customized manifests are installed after default manifests are applied.

Overwrite mode¶

Use overwrite mode when you want to customize all Knative Eventing manifests to be installed.

For example, if you want to install a customized Knative Eventing only, you can create and apply the following Eventing CR:

apiVersion: v1
kind: Namespace
metadata:
  name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: $spec_version
  manifests:
  - URL: https://my-eventing/eventing.yaml

This example installs the customized Knative Eventing at version $spec_version which is available at https://my-eventing/eventing.yaml.

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.

Append mode¶

You can use append mode to add your customized manifests into the default manifests.

For example, if you only want to customize a few resources but you still want to install the default Knative Eventing, you can create and apply the following Eventing CR:

apiVersion: v1
kind: Namespace
metadata:
  name: knative-eventing
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  version: $spec_version
  additionalManifests:
  - URL: https://my-eventing/eventing-custom.yaml

This example installs the default Knative Eventing, and installs your customized resources available at https://my-eventing/eventing-custom.yaml.

Knative Operator installs the default manifests of Knative Eventing at the version $spec_version, and then installs your customized manifests based on them.

Installing Knative Eventing with event sources¶

Knative Operator can configure the Knative Eventing component with different event sources. Click on each of the following tabs to see how you can configure Knative Eventing with different event sources:

Verify the Knative Eventing deployment¶

1. Monitor the Knative deployments:

   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
   eventing-controller     1/1     1            1           43s
   eventing-webhook        1/1     1            1           42s
   imc-controller          1/1     1            1           39s
   imc-dispatcher          1/1     1            1           38s
   mt-broker-controller    1/1     1            1           36s
   mt-broker-filter        1/1     1            1           37s
   mt-broker-ingress       1/1     1            1           37s
   pingsource-mt-adapter   0/0     0            0           43s
   sugar-controller        1/1     1            1           36s
   

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

Uninstalling Knative¶

Knative Operator prevents unsafe removal of Knative resources. Even if the Knative Serving and Knative Eventing CRs are successfully removed, all the CRDs in Knative are still kept in the cluster. All your resources relying on Knative CRDs can still work.

Removing the Knative Serving component¶

To remove the Knative Serving CR run the command:

kubectl delete KnativeServing knative-serving -n knative-serving

Removing Knative Eventing component¶

To remove the Knative Eventing CR run the command:

kubectl delete KnativeEventing knative-eventing -n knative-eventing

Removing the Knative Operator:¶

If you have installed Knative using the release page, remove the operator by running the command:

kubectl delete -f https://github.com/knative/operator/releases/download/knative-v1.16.0/operator.yaml

If you have installed Knative from source, uninstall it using the following command while in the root directory for the source:

ko delete -f config/

What's next¶

• Configure Knative Serving using Operator
• Configure Knative Eventing using Operator