Installing Knative using the 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.
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.21 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.
Install the Knative Operator
Before you install the Knative Serving and Eventing components, first install the Knative Operator.
Install the latest Knative Operator release
To install the latest stable Operator release, run the command:
kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.2.0/operator.yaml
You can find information about the released versions of the Knative Operator on the releases page.
Verify your Knative Operator installation
Because the Operator is installed to the
default
namespace, ensure you set the current namespace todefault
by running the command:kubectl config set-context --current --namespace=default
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
Installing the Knative Serving component
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
Install the current version (default)
To create the custom resource for the latest available Knative Serving in the Operator:
Copy the following YAML into a file:
apiVersion: v1
kind: Namespace
metadata:
name: knative-serving
---
apiVersion: operator.knative.dev/v1alpha1
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.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 another version of Knative Serving
You can install a new release of Knative Serving without upgrading the Operator. To install a new version of Knative Serving:
Create 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: "<new-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
Where
<new-version>
is the Knative version you want to use, for example1.0
. This field is used to set the version of Knative Serving and to automatically replace the tag${VERSION}
.Attention
The field
spec.manifests
is used to specify one or multiple URL links of the Knative Serving component. The ordering of the URLs is critical. Put the manifest you want to apply first on the top.You must add a valid URL of the Knative network ingress plugin. You can use
net-istio
. Knative Serving component is tightly-coupled with a network ingress plugin in the Operator.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 customized Knative Serving
The Operator provides you with the flexibility to install Knative Serving customized to your own requirements. As long as the manifests of customized Knative Serving 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, you must define all manifests needed for Knative Serving to install because the Operator will no longer install any default manifests. With append mode, you only need to define your customized manifests. The customized manifests are installed after default manifests are applied.
Overwrite mode:
You can use overwrite mode when you want to customize all Knative Serving manifests.
For example, if you want to install Knative Serving and istio ingress and you want customize both components, you can create the following YAML file:
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
This example installs the customized Knative Serving at version $spec_version
which is available at https://my-serving/serving.yaml
, and the customized ingress plugin net-istio
which is available at https://my-net-istio/net-istio.yaml
.
Attention
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.
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 Serving, you can create the following YAML file:
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
This example installs the default Knative Serving, and installs your customized resources available at https://my-serving/serving-custom.yaml
.
Knative Operator installs the default manifests of Knative Serving at the version $spec_version
, and then installs your customized manifests based on them.
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:
Kourier (Choose this if you are not sure)
The following steps install Kourier and enable its Knative integration:
To configure Knative Serving to use Kourier, add
spec.ingress.kourier
andspec.config.network
to your Serving CR YAML file as follows: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"
Apply the YAML file for your Serving CR by running the command:
kubectl apply -f <filename>.yaml
Where
<filename>
is the name of your Serving CR file.Fetch the External IP or CNAME by running the command:
kubectl --namespace knative-serving get service kourier
Save this for configuring DNS later.
Istio (default)
The following steps install Istio to enable its Knative integration:
If you installed Istio under a namespace other than the default
istio-system
:Add
spec.config.istio
to your Serving CR 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 namespaceknative-serving
.<istio-namespace>
is the namespace where Istio is installed.
Apply the YAML file for your Serving CR by running the command:
kubectl apply -f <filename>.yaml
Where
<filename>
is the name of your Serving CR file.
Fetch the External IP or CNAME by running the command:
kubectl get svc istio-ingressgateway -n <istio-namespace>
Save this for configuring DNS later.
Contour
The following steps install Contour and enable its Knative integration:
Install a properly configured Contour:
kubectl apply --filename https://github.com/knative/net-contour/releases/download/knative-v1.2.0/contour.yaml
To configure Knative Serving to use Contour, add
spec.ingress.contour
spec.config.network
to your Serving CR YAML file as follows: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"
Apply the YAML file for your Serving CR by running the command:
kubectl apply -f <filename>.yaml
Where
<filename>
is the name of your Serving CR file.Fetch the External IP or CNAME by running the command:
kubectl --namespace contour-external get service envoy
Save this for configuring DNS later.
Verify the Knative Serving deployment
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
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:
Magic DNS (sslip.io)
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://github.com/knative/serving/releases/download/knative-v1.2.0/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.
Real 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
spec.config.domain
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": ""
...
Temporary DNS
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 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 behttp://192.168.39.228:32198
and you wish to access thehelloworld-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
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
Install the current version (default)
To create the custom resource for the latest available Knative Eventing in the Operator:
Copy the following YAML into a file:
apiVersion: v1
kind: Namespace
metadata:
name: knative-eventing
---
apiVersion: operator.knative.dev/v1alpha1
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.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 another version of Knative Eventing
You can install a new release of Knative Eventing without upgrading the Operator. To install a new version of Knative Eventing:
Create 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: "<new-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
Where
<new-version>
is the Knative version you want to use, for example1.0
. This field is used to set the version of Knative Eventing and to automatically replace the tag${VERSION}
.Attention
The field
spec.manifests
is used to specify one or multiple URL links of the Knative Serving component. The ordering of the URLs is critical. Put the manifest you want to apply first on the top.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 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, you must define all manifests needed for Knative Eventing to install because the Operator will no longer install any default manifests. With append mode, 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/v1alpha1
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
.
Attention
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.
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/v1alpha1
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:
Ceph
To configure Knative Eventing to install Ceph as the event source:
Add
spec.source.ceph
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
ceph:
enabled: true
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.
Apache CouchDB
To configure Knative Eventing to install Apache CouchDB as the event source:
Add
spec.source.couchdb
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
couchdb:
enabled: true
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.
GitHub
To configure Knative Eventing to install GitHub as the event source:
Add
spec.source.github
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
github:
enabled: true
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.
GitLab
To configure Knative Eventing to install GitLab as the event source:
Add
spec.source.gitlab
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
gitlab:
enabled: true
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.
Apache Kafka
To configure Knative Eventing to install Kafka as the event source:
Add
spec.source.kafka
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
kafka:
enabled: true
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.
NATS Streaming
To configure Knative Eventing to install NATS Streaming as the event source:
Add
spec.source.natss
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
natss:
enabled: true
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.
Prometheus
To configure Knative Eventing to install Prometheus as the event source:
Add
spec.source.prometheus
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
prometheus:
enabled: true
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.
RabbitMQ
To configure Knative Eventing to install RabbitMQ as the event source,
Add
spec.source.rabbitmq
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
rabbitmq:
enabled: true
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.
Redis
To configure Knative Eventing to install Redis as the event source:
Add
spec.source.redis
to your Eventing CR YAML file as follows:apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
# ...
source:
redis:
enabled: true
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.
Verify the Knative Eventing deployment
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
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.2.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/