Skip to content

Knative Operator installation

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

Feature Availability: beta since Knative v0.25
  • beta features are well-tested and enabling them is considered safe. Support for the overall feature will not be dropped, though details may change in incompatible ways.

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 2 CPUs and 4 GB of memory.

    Tip

    You can install a local distribution of Knative for development use by following the Getting started guide.

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

Caution

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

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://storage.googleapis.com/knative-nightly/operator/latest/operator.yaml

Verify your 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

Track the log of the operator:

kubectl logs -f deploy/knative-operator

Installing the Knative Serving component

Create and apply the Knative Serving CR:

Install Current Serving

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 example mentioned earlier, 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 in the following example 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 follows: 
    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:

  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
net-istio-webhook      1/1     1            1           12s
net-istio-controller   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

Installing Knative Serving with different networking 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 of the following tabs to see how you can configure Knative Serving with different ingresses:

The following commands install Istio and enable its Knative integration.

  1. Install Istio.

  2. To configure Knative Serving to use Istio, copy the following YAML into a file: 

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

  3. If Istio is installed under a namespace other than the default istio-system, add the spec.config.istio field to the YAML file as follows: 

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

    Where:

    • <local-gateway-namespace> is the local gateway namespace, which is the same as Knative Serving namespace knative-serving.
    • <istio-namespace> is the namespace where Istio is installed.

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

  5. Fetch the External IP or CNAME by running the command: 

    kubectl get svc istio-ingressgateway -n <istio-namespace>

    Save this for configuring DNS later.

The following commands install Ambassador and enable its Knative integration.

  1. Create a namespace to install Ambassador in: 

    kubectl create namespace ambassador

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

  3. Give Ambassador the required permissions: 

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

  4. Enable Knative support in Ambassador: 

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

  5. To configure Knative Serving to use Ambassador, copy the following YAML into a file: 

    apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    network:
      ingress.class: "ambassador.ingress.networking.knative.dev"

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

  7. Fetch the External IP or CNAME by running the command: 

    kubectl --namespace ambassador get service ambassador

    Save this for configuring DNS later.

The following commands install Contour and enable its Knative integration.

  1. Install a properly configured Contour: 

    kubectl apply --filename https://storage.googleapis.com/knative-nightly/net-contour/latest/contour.yaml

  2. To configure Knative Serving to use Contour, copy the following YAML into a file: 

    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"

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

  4. Fetch the External IP or CNAME by running the command: 

    kubectl --namespace contour-external get service envoy

    Save this for configuring DNS later.

The following commands install Kourier and enable its Knative integration.

  1. To configure Knative Serving to use Kourier, copy the following YAML into a file: 

    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"

  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.

  3. Fetch the External IP or CNAME by running the command: 

    kubectl --namespace knative-serving get service kourier

    Save this for configuring DNS later.

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:

Knative provides a Kubernetes Job called default-domain that configures Knative Serving to use sslip.io as the default DNS suffix.

kubectl apply -f https://storage.googleapis.com/knative-nightly/serving/latest/serving-default-domain.yaml

Warning

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 unless minikube tunnel is running.

In these cases, see the "Real DNS" or "Temporary DNS" tabs.

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 mentioned in section 3, 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 helloworld-go application mentioned earlier, 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 is: 
    Hello Go Sample v1!
    Refer to the "Real DNS" method for a permanent solution.

Installing the Knative Eventing component

  1. 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 to install your Knative Eventing as follows:
    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 follows:
    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

Installing with different eventing sources

Installing the Knative Eventing component with different eventing sources

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

To configure Knative Eventing to install Ceph as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    ceph:
      enabled: true
EOF

To configure Knative Eventing to install Apache CouchDB as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    couchdb:
      enabled: true
EOF

To configure Knative Eventing to install GitHub as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    github:
      enabled: true
EOF

To configure Knative Eventing to install GitLab as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    gitlab:
      enabled: true
EOF

To configure Knative Eventing to install Kafka as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    kafka:
      enabled: true
EOF

To configure Knative Eventing to install NATS Streaming as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    natss:
      enabled: true
EOF

To configure Knative Eventing to install Prometheus as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    prometheus:
      enabled: true
EOF

To configure Knative Eventing to install RabbitMQ as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    rabbitmq:
      enabled: true
EOF

To configure Knative Eventing to install Redis as the eventing source, apply the content of the Eventing CR as follows: 

cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    redis:
      enabled: true
EOF

Uninstall Knative

Removing the Knative Serving component

Remove the Knative Serving CR:

kubectl delete KnativeServing knative-serving -n knative-serving

Removing Knative Eventing component

Remove the Knative Eventing CR:

kubectl delete KnativeEventing knative-eventing -n knative-eventing

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 Operator:

If you have installed Knative using the Release page, remove the operator using the following command:

kubectl delete -f https://storage.googleapis.com/knative-nightly/operator/latest/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

Back to top

We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose. Learn more.

× OK