Chapter 6. Administer

Procedure

1. Modify the KnativeEventing custom resource (CR) to add configuration details for the config-br-default-channel config map:

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

   1

   In spec.config, you can specify the config maps that you want to add modified configurations for.

   2

   The default backing channel type configuration. In this example, the default channel implementation for the cluster is KafkaChannel.

   3

   The number of partitions for the Kafka channel that backs the broker.

   4

   The replication factor for the Kafka channel that backs the broker.

2. Apply the updated KnativeEventing CR:

   $ oc apply -f <filename>

Procedure

1. To enable Knative Serving to use PVCs and write to them, modify the KnativeServing custom resource (CR) to include the following YAML:

   Enabling PVCs with write access

   ...
   spec:
     config:
       features:
         "kubernetes.podspec-persistent-volume-claim": enabled
         "kubernetes.podspec-persistent-volume-write": enabled
   ...

   • The kubernetes.podspec-persistent-volume-claim extension controls whether persistent volumes (PVs) can be used with Knative Serving.
   • The kubernetes.podspec-persistent-volume-write extension controls whether PVs are available to Knative Serving with the write access.

2. To claim a PV, modify your service to include the PV configuration. For example, you might have a persistent volume claim with the following configuration:

   Note

   Use the storage class that supports the access mode that you are requesting. For example, you can use the ocs-storagecluster-cephfs class for the ReadWriteMany access mode.

   PersistentVolumeClaim configuration

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: example-pv-claim
     namespace: my-ns
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: ocs-storagecluster-cephfs
     resources:
       requests:
         storage: 1Gi

   In this case, to claim a PV with write access, modify your service as follows:

   Knative service PVC configuration

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     namespace: my-ns
   ...
   spec:
    template:
      spec:
        containers:
            ...
            volumeMounts: 1
              - mountPath: /data
                name: mydata
                readOnly: false
        volumes:
          - name: mydata
            persistentVolumeClaim: 2
              claimName: example-pv-claim
              readOnly: false 3

   1

   Volume mount specification.

   2

   Persistent volume claim specification.

   3

   Flag that enables read-only access.

   Note

   To successfully use persistent storage in Knative services, you need additional configuration, such as the user permissions for the Knative container user.

Procedure

1. In the Administrator perspective, navigate to Operators Installed Operators.
2. Check that the Project dropdown at the top of the page is set to Project: knative-eventing.
3. In the list of Provided APIs for the OpenShift Serverless Operator, find the Knative Kafka box and click Create Instance.

4. Configure the KnativeKafka object in the Create Knative Kafka page.

   Important

   To use the Kafka channel, source, broker, or sink on your cluster, you must toggle the enabled switch for the options you want to use to true. These switches are set to false by default. Additionally, to use the Kafka channel, broker, or sink you must specify the bootstrap servers.

   Example KnativeKafka custom resource

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
       name: knative-kafka
       namespace: knative-eventing
   spec:
       channel:
           enabled: true 1
           bootstrapServers: <bootstrap_servers> 2
       source:
           enabled: true 3
       broker:
           enabled: true 4
           defaultConfig:
               bootstrapServers: <bootstrap_servers> 5
               numPartitions: <num_partitions> 6
               replicationFactor: <replication_factor> 7
       sink:
           enabled: true 8

   1

   Enables developers to use the KafkaChannel channel type in the cluster.

   2

   A comma-separated list of bootstrap servers from your AMQ Streams cluster.

   3

   Enables developers to use the KafkaSource event source type in the cluster.

   4

   Enables developers to use the Knative Kafka broker implementation in the cluster.

   5

   A comma-separated list of bootstrap servers from your Red Hat AMQ Streams cluster.

   6

   Defines the number of partitions of the Kafka topics, backed by the Broker objects. The default is 10.

   7

   Defines the replication factor of the Kafka topics, backed by the Broker objects. The default is 3.

   8

   Enables developers to use a Kafka sink in the cluster.

   Note

   The replicationFactor value must be less than or equal to the number of nodes of your Red Hat AMQ Streams cluster.

   1. Using the form is recommended for simpler configurations that do not require full control of KnativeKafka object creation.
   2. Editing the YAML is recommended for more complex configurations that require full control of KnativeKafka object creation. You can access the YAML by clicking the Edit YAML link in the top right of the Create Knative Kafka page.
5. Click Create after you have completed any of the optional configurations for Kafka. You are automatically directed to the Knative Kafka tab where knative-kafka is in the list of resources.

Verification

1. Click on the knative-kafka resource in the Knative Kafka tab. You are automatically directed to the Knative Kafka Overview page.

2. View the list of Conditions for the resource and confirm that they have a status of True.

   

   If the conditions have a status of Unknown or False, wait a few moments to refresh the page.

3. Check that the Knative Kafka resources have been created:

   $ oc get pods -n knative-eventing

   Example output

   NAME                                        READY   STATUS    RESTARTS   AGE
   kafka-broker-dispatcher-7769fbbcbb-xgffn    2/2     Running   0          44s
   kafka-broker-receiver-5fb56f7656-fhq8d      2/2     Running   0          44s
   kafka-channel-dispatcher-84fd6cb7f9-k2tjv   2/2     Running   0          44s
   kafka-channel-receiver-9b7f795d5-c76xr      2/2     Running   0          44s
   kafka-controller-6f95659bf6-trd6r           2/2     Running   0          44s
   kafka-source-dispatcher-6bf98bdfff-8bcsn    2/2     Running   0          44s
   kafka-webhook-eventing-68dc95d54b-825xs     2/2     Running   0          44s

Procedure

1. Modify the kafka-broker-config config map, or create your own config map that contains the following configuration:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: <config_map_name> 1
     namespace: <namespace> 2
   data:
     default.topic.partitions: <integer> 3
     default.topic.replication.factor: <integer> 4
     bootstrap.servers: <list_of_servers> 5

   1

   The config map name.

   2

   The namespace where the config map exists.

   3

   The number of topic partitions for the Kafka broker. This controls how quickly events can be sent to the broker. A higher number of partitions requires greater compute resources.

   4

   The replication factor of topic messages. This prevents against data loss. A higher replication factor requires greater compute resources and more storage.

   5

   A comma separated list of bootstrap servers. This can be inside or outside of the OpenShift Container Platform cluster, and is a list of Kafka clusters that the broker receives events from and sends events to.

   Important

   The default.topic.replication.factor value must be less than or equal to the number of Kafka broker instances in your cluster. For example, if you only have one Kafka broker, the default.topic.replication.factor value should not be more than "1".

   Example Kafka broker config map

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: kafka-broker-config
     namespace: knative-eventing
   data:
     default.topic.partitions: "10"
     default.topic.replication.factor: "3"
     bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"

2. Apply the config map:

   $ oc apply -f <config_map_filename>

3. Specify the config map for the Kafka Broker object:

   Example Broker object

   apiVersion: eventing.knative.dev/v1
   kind: Broker
   metadata:
     name: <broker_name> 1
     namespace: <namespace> 2
     annotations:
       eventing.knative.dev/broker.class: Kafka 3
   spec:
     config:
       apiVersion: v1
       kind: ConfigMap
       name: <config_map_name> 4
       namespace: <namespace> 5
   ...

   1

   The broker name.

   2

   The namespace where the broker exists.

   3

   The broker class annotation. In this example, the broker is a Kafka broker that uses the class value Kafka.

   4

   The config map name.

   5

   The namespace where the config map exists.

4. Apply the broker:

   $ oc apply -f <broker_filename>

Procedure

1. Navigate to the Serverless Serving page.
2. In the Create list, select Service.
3. Manually enter YAML or JSON definitions, or by dragging and dropping a file into the editor.
4. Click Create.

Procedure

1. Create a root certificate and private key that signs the certificates for your Knative services:

   $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
       -subj '/O=Example Inc./CN=example.com' \
       -keyout root.key \
       -out root.crt

2. Create a wildcard certificate:

   $ openssl req -nodes -newkey rsa:2048 \
       -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \
       -keyout wildcard.key \
       -out wildcard.csr

3. Sign the wildcard certificate:

   $ openssl x509 -req -days 365 -set_serial 0 \
       -CA root.crt \
       -CAkey root.key \
       -in wildcard.csr \
       -out wildcard.crt

4. Create a secret by using the wildcard certificate:

   $ oc create -n istio-system secret tls wildcard-certs \
       --key=wildcard.key \
       --cert=wildcard.crt

   This certificate is picked up by the gateways created when you integrate OpenShift Serverless with Service Mesh, so that the ingress gateway serves traffic with this certificate.

Procedure

1. Add the namespaces that you would like to integrate with Service Mesh to the ServiceMeshMemberRoll object as members:

   apiVersion: maistra.io/v1
   kind: ServiceMeshMemberRoll
   metadata:
     name: default
     namespace: istio-system
   spec:
     members: 1
       - knative-serving
       - <namespace>

   1

   A list of namespaces to be integrated with Service Mesh.

   Important

   This list of namespaces must include the knative-serving namespace.

2. Apply the ServiceMeshMemberRoll resource:

   $ oc apply -f <filename>

3. Create the necessary gateways so that Service Mesh can accept traffic:

   Example knative-local-gateway object using HTTP

   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway
   metadata:
     name: knative-ingress-gateway
     namespace: knative-serving
   spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 443
           name: https
           protocol: HTTPS
         hosts:
           - "*"
         tls:
           mode: SIMPLE
           credentialName: <wildcard_certs> 1
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway
   metadata:
    name: knative-local-gateway
    namespace: knative-serving
   spec:
    selector:
      istio: ingressgateway
    servers:
      - port:
          number: 8081
          name: http
          protocol: HTTP 2
        hosts:
          - "*"
   ---
   apiVersion: v1
   kind: Service
   metadata:
    name: knative-local-gateway
    namespace: istio-system
    labels:
      experimental.istio.io/disable-gateway-port-translation: "true"
   spec:
    type: ClusterIP
    selector:
      istio: ingressgateway
    ports:
      - name: http2
        port: 80
        targetPort: 8081

   1

   Add the name of the secret that contains the wildcard certificate.

   2

   The knative-local-gateway serves HTTP traffic. Using HTTP means that traffic coming from outside of Service Mesh, but using an internal hostname, such as example.default.svc.cluster.local, is not encrypted. You can set up encryption for this path by creating another wildcard certificate and an additional gateway that uses a different protocol spec.

   Example knative-local-gateway object using HTTPS

   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway
   metadata:
     name: knative-local-gateway
     namespace: knative-serving
   spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 443
           name: https
           protocol: HTTPS
         hosts:
           - "*"
         tls:
           mode: SIMPLE
           credentialName: <wildcard_certs>

4. Apply the Gateway resources:

   $ oc apply -f <filename>

5. Install Knative Serving by creating the following KnativeServing custom resource definition (CRD), which also enables the Istio integration:

   apiVersion: operator.knative.dev/v1alpha1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   spec:
     ingress:
       istio:
         enabled: true 1
     deployments: 2
     - name: activator
       annotations:
         "sidecar.istio.io/inject": "true"
         "sidecar.istio.io/rewriteAppHTTPProbers": "true"
     - name: autoscaler
       annotations:
         "sidecar.istio.io/inject": "true"
         "sidecar.istio.io/rewriteAppHTTPProbers": "true"

   1

   Enables Istio integration.

   2

   Enables sidecar injection for Knative Serving data plane pods.

6. Apply the KnativeServing resource:

   $ oc apply -f <filename>

7. Create a Knative Service that has sidecar injection enabled and uses a pass-through route:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
     namespace: <namespace> 1
     annotations:
       serving.knative.openshift.io/enablePassthrough: "true" 2
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 3
           sidecar.istio.io/rewriteAppHTTPProbers: "true"
       spec:
         containers:
         - image: <image_url>

   1

   A namespace that is part of the Service Mesh member roll.

   2

   Instructs Knative Serving to generate an OpenShift Container Platform pass-through enabled route, so that the certificates you have generated are served through the ingress gateway directly.

   3

   Injects Service Mesh sidecars into the Knative service pods.

8. Apply the Service resource:

   $ oc apply -f <filename>

Procedure

1. Specify prometheus as the metrics.backend-destination in the observability spec of the Knative Serving custom resource (CR):

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeServing
   metadata:
     name: knative-serving
   spec:
     config:
       observability:
         metrics.backend-destination: "prometheus"
   ...

   This step prevents metrics from being disabled by default.

2. Apply the following network policy to allow traffic from the Prometheus namespace:

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-from-openshift-monitoring-ns
     namespace: knative-serving
   spec:
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             name: "openshift-monitoring"
     podSelector: {}
   ...

3. Modify and reapply the default Service Mesh control plane in the istio-system namespace, so that it includes the following spec:

   ...
   spec:
     proxy:
       networking:
         trafficControl:
           inbound:
             excludedPorts:
             - 8444
   ...

Procedure

1. Add the namespaces that you would like to integrate with Service Mesh to the ServiceMeshMemberRoll object as members:

   apiVersion: maistra.io/v1
   kind: ServiceMeshMemberRoll
   metadata:
     name: default
     namespace: istio-system
   spec:
     members:
       - <namespace> 1
   ...

   1

   A list of namespaces to be integrated with Service Mesh.

2. Apply the ServiceMeshMemberRoll resource:

   $ oc apply -f <filename>

3. Create a network policy that permits traffic flow from Knative system pods to Knative services:

   1. For each namespace that you want to integrate with Service Mesh, create a NetworkPolicy resource:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-serving-system-namespace
        namespace: <namespace> 1
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                knative.openshift.io/part-of: "openshift-serverless"
        podSelector: {}
        policyTypes:
        - Ingress
      ...

      1

      Add the namespace that you want to integrate with Service Mesh.

      Note

      The knative.openshift.io/part-of: "openshift-serverless" label was added in OpenShift Serverless 1.22.0. If you are using OpenShift Serverless 1.21.1 or earlier, add the knative.openshift.io/part-of label to the knative-serving and knative-serving-ingress namespaces.

      Add the label to the knative-serving namespace:

      $ oc label namespace knative-serving knative.openshift.io/part-of=openshift-serverless

      Add the label to the knative-serving-ingress namespace:

      $ oc label namespace knative-serving-ingress knative.openshift.io/part-of=openshift-serverless

   2. Apply the NetworkPolicy resource:

      $ oc apply -f <filename>

Procedure

1. In the OpenShift Container Platform web console Administrator perspective, navigate to OperatorHub Installed Operators.
2. Select the knative-serving namespace.
3. Click Knative Serving in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Serving tab.

4. Click knative-serving, then go to the YAML tab in the knative-serving page.

   

5. Modify the number of replicas in the KnativeServing CR:

   Example YAML

   apiVersion: operator.knative.dev/v1alpha1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   spec:
     high-availability:
       replicas: 3

Procedure

1. In the OpenShift Container Platform web console Administrator perspective, navigate to OperatorHub Installed Operators.
2. Select the knative-eventing namespace.
3. Click Knative Eventing in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Eventing tab.

4. Click knative-eventing, then go to the YAML tab in the knative-eventing page.

   

5. Modify the number of replicas in the KnativeEventing CR:

   Example YAML

   apiVersion: operator.knative.dev/v1alpha1
   kind: KnativeEventing
   metadata:
     name: knative-eventing
     namespace: knative-eventing
   spec:
     high-availability:
       replicas: 3

Procedure

1. In the OpenShift Container Platform web console Administrator perspective, navigate to OperatorHub Installed Operators.
2. Select the knative-eventing namespace.
3. Click Knative Kafka in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Kafka tab.

4. Click knative-kafka, then go to the YAML tab in the knative-kafka page.

   

5. Modify the number of replicas in the KnativeKafka CR:

   Example YAML

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     name: knative-kafka
     namespace: knative-eventing
   spec:
     high-availability:
       replicas: 3