Win $20,000. Help build the future of education. Answer the call. Learn more

Extend Knative configurations with customized manifests

The version v0.17.0 release of Knative Operator implements customized manifests for Knative installation. The custom resource of Knative Operator is the single source of truth for configuring the Knative components. However, the CustomResourceDefinition API of Knative Operator is not extensive enough to support all the configuration options by the typed API. Knative Operator targets customized manifests as the ultimate solution to resort to, if it cannot meet the administrators’ needs. This tutorial explains in detail what you can do with this feature.

Prerequisites

You need to install Kubectl for managing development environments. In addition, you need to set up a Kubernetes cluster v1.16 or newer as your environment to install Knative Operator. You can use the Kubernetes service from any major cloud provider, such as the IBM Cloud Kubernetes service, and set up your connection based on the guidance provided. If you choose to use a local Kubernetes cluster on your own machine, based on your operating system, you can select minikube or Docker Desktop.

Estimated time

Based on your familiarity with Knative, it will take you about 10-15 minutes to go through all the scenarios for using customized manifests.

Steps

Install Istio for Knative

Knative Serving relies on Istio to redirect the incoming traffic to the internal microservices. Follow the instructions for installing Istio for Knative.

Run the following command to install the 0.17 release of Knative Operator:

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

Run the following command to verify the Knative Operator:

kubectl get deployment knative-operator

The deployment should show a Ready status, such as this output:

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

Run the following command to track the log of the Knative Operator:

kubectl logs -f deploy/knative-operator

The lifecycles of the Knative Serving and Eventing components are controlled by the Knative Operator custom resources Knative Serving CR and Knative Eventing CR, respectively. To install each component, Serving or Eventing, you just create the corresponding CR.

Both Serving and Eventing CRs use the field spec.version to specify the version of the component. By default, Knative Operator installs the latest component bundled in the operator image. Knative Operator aligns with the Knative Serving and Eventing in terms of the version number. For example, the latest Knative Serving that the Knative Operator 0.19.x can install is also 0.19.x. The last digit x as the patch number can vary, but Knative Operator 0.19.x does not bundle 0.20.x Knative Serving inside the operator. By default, Knative Operator 0.19.x cannot install Knative Serving 0.20.x. However, with customized manifests, you can specify the URLs of any manifests available, breaking the version limitation. You can specify the 0.20.x Knative manifests as customized manifests for Knative Operator 0.19.x. Without customized manifests, you would need to wait for the Knative Operator 0.20.x release to install Knative Serving 0.20.x.

Install or upgrade to a newer version of Knative

The latest Knative Serving bundled in Knative Operator v0.17.0 is v0.17.1. The latest Knative Eventing bundled in Knative Operator v0.17.0 is v0.17.2.

To install Knative Serving v0.17.2 with Knative Operator v0.17.0, you use the spec.manifests field in the Knative Operator CR to define the links of the Knative manifests. You can copy the links you need from the Knative Serving manifests v0.17.2 and then edit the YAML file 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: 0.17.2
  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/v0.17.0/net-istio.yaml

The order of the list of manifests is critical and is based on a “first come first install” principle. We put the CRD and the core component first, other components second, post install jobs third, and the network plugin net-istio at the end.

The annotation ${VERSION} in the URLs is replaced by the spec.version automatically. The network plugin net-istio can have a different version, so we specify a version number in our example.

To install Knative Eventing v0.17.3 with Knative Operator v0.17.0, you can leverage spec.manifests the same way you did for Knative Serving. Copy the valid links of all the Knative Eventing manifests v0.17.3 and then edit the YAML file 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://github.com/knative/eventing/releases/download/v${VERSION}/eventing-core.yaml
    -URL: https://github.com/knative/eventing/releases/download/v${VERSION}/in-memory-channel.yaml
    -URL: https://github.com/knative/eventing/releases/download/v${VERSION}/mt-channel-broker.yaml
    -URL: https://github.com/knative/eventing/releases/download/v${VERSION}/eventing-sugar-controller.yaml
    -URL: https://github.com/knative/eventing/releases/download/v${VERSION}/eventing-post-install-jobs.yaml

You need to install CRDs, core resources, in-memory channel, multitenancy channel broker, sugar controller, and post install jobs in the correct order.

With the support of customized manifests, you can leverage spec.manifests and spec.version to install a future release of Knative that is not available in the Knative Operator without waiting for a new release of Knative Operator. If you upgrade an existing Knative Serving or Eventing with Operator to the expected version, make sure it goes up only one minor version. Knative Operator does not support upgrades across multiple minor versions. For example, if your existing Knative Serving is at v0.16.2, you can only upgrade it to v0.17.x, and you cannot directly upgrade it to v0.18.x or above.

Install Knative based on your customized configurations

We encourage you to configure Knative with the Knative Operator CRs. For all the available configuration options with Knative Operator CRs, see Configuring the Serving Operator CR and Configuring the Eventing Operator CR.

However, Knative Operator CRs do not support or offer all of the possible configuration fields for configuring Knative. If you need to, you can change literally anything in customized manifests and specify them in the URLs for the CRs.

Once your changes are done to the manifests, you need to make them available and accessible to the Kubernetes cluster where you deploy your Knative Operator.

For Knative Serving, if you publish your serving.yaml consolidating all the Serving resources at https://my-serving/serving.yaml and would like to use net-istio available at https://my-net-istio/net-istio.yaml, update the YAML file with the following content to install your customized Serving manifest:

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

For Knative Eventing, if you publish your eventing.yaml consolidating all the Eventing resources at https://my-eventing/eventing.yaml, update the YAML file with the following content to install your customized Serving manifest:

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 publish your customized manifest into multiple YAML files as the Knative community always does. When you do so, be aware that the list of URLs defined in spec.manifests is order-critical.

Install a network plug-in other than net-istio

The Knative Operation working group is creating the design and implementation of supporting multiple ingresses with the Operator APIs, but Knative Operator officially only supports Istio as the ingress gateway. The network ingress plug-in is currently bundled with the Knative Serving component. However, because you can specify the link of each artifact in customized manifests, you can customize the network ingress plug-in.

For example, if you want to use the ingress gateway Kourier for Knative Serving, you can update the YAML file 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: 0.17.2
  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-kourier/releases/download/v0.17.0/kourier.yaml
  config:
    network:
      ingress.class: "kourier.ingress.networking.knative.dev"

Instead of using net-istio, you specify net-kourier as the network ingress plug-in. Besides, you specify kourier.ingress.networking.knative.dev as the ingress class for the ConfigMap config-network. Until Knative Operator officially supports multiple ingresses, you can use custom manifests as an alternative to use other network ingress plug-ins besides net-istio.

Summary

With customized manifests, you can extend the Knative configurations beyond the Knative Operator’s scope. All types of configurations are now possible with Knative Operator. Knative Operator APIs configure Knative based on the manifests. If you have configuration requests unable to meet with Knative Operator APIs, you can always customize the Knative manifests and use them as the base for the Knative Operator to load and install.