Prerequisites

• You have installed OpenShift Serverless Operator and Knative Serving on your cluster.
• You have installed the Knative (kn) CLI.
• You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Procedure

• Create a Knative service:

  $ kn service create <service_name> --image <image> --tag <tag_value>

  Copy code to clipboard

  Where:

  • --image is the URI of the image for the application.

  • --tag is an optional flag that you can use to add a tag to the initial revision that Knative creates with the service.

    You get an output similar to the following example command:

    $ kn service create showcase \
        --image quay.io/openshift-knative/showcase

    Copy code to clipboard

    You get an output similar to the following example:

    Creating service 'showcase' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "showcase" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'showcase' created with latest revision 'showcase-00001' and URL:
    http://showcase-default.apps-crc.testing

    Copy code to clipboard

Prerequisites

• You have installed OpenShift Serverless Operator and Knative Serving on your cluster.
• You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
• Install the OpenShift CLI (oc).

Prerequisites

• You have installed OpenShift Serverless Operator and Knative Serving on your cluster.
• You have installed the Knative (kn) CLI.

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving your cluster.
• You have installed the oc CLI.
• You have created a Knative service.

Prerequisites

• Install the OpenShift CLI (oc).

• 170 Knative Services
• 1-2 Revisions per Knative Service
• 89 test scenarios mainly focused on testing the control plane
• 48 re-creating scenarios where Knative Services are deleted and re-created
• 41 stable scenarios, in which requests are slowly but continuously sent to the system

Procedure

• You can configure Knative Serving for minimal workloads using the KnativeServing custom resource (CR):

  A minimal workload configuration in KnativeServing CR

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 1 1
    workloads:
      - name: activator
        replicas: 2 2
        resources:
          - container: activator
            requests:
              cpu: 250m 3
              memory: 60Mi 4
            limits:
              cpu: 1000m
              memory: 600Mi
      - name: controller
        replicas: 1 5
        resources:
          - container: controller
            requests:
              cpu: 10m
              memory: 100Mi
            limits: 6
              cpu: 200m
              memory: 300Mi
      - name: webhook
        replicas: 2
        resources:
          - container: webhook
            requests:
              cpu: 100m 7
              memory: 60Mi
            limits:
              cpu: 200m
              memory: 200Mi
    podDisruptionBudgets: 8
      - name: activator-pdb
        minAvailable: 1
      - name: webhook-pdb
        minAvailable: 1

  Copy code to clipboard

  1

  Setting this to 1 scales all system components to one replica.

  2

  Always scale the activator to at least 2 instances to avoid downtime.

  3

  Set the activator CPU request to at least 250m, because the HorizontalPodAutoscaler uses this value to scale the activator up or down.

  4

  Adjust memory requests to the idle values from the earlier table. Also adjust memory limits according to your expected load (this might need custom testing to find the best values).

  5

  One webhook and one controller are enough for a minimal-workload scenario

  6

  These limits are enough for a minimal-workload scenario, but they also might need adjustments depending on your concrete workload.

  7

  Set the webhook CPU request to at least 100m, because the HorizontalPodAutoscaler uses this value to scale the webhook up or down.

  8

  Adjust the PodDistruptionBudgets to a value lower than replicas, to avoid problems during node maintenance.

• All data-plane components are mostly increasing CPU usage on higher requests and payload scenarios, so the CPU requests and limits have to be tested and potentially increased.
• The activator component might require additional memory when it buffers more or larger request payloads. In such cases, increase the memory requests and limits.
• One activator pod can handle about 2500 requests per second before it starts to increase latency and, at some point, leads to errors.
• One 3scale-kourier-gateway or istio-ingressgateway pod can also handle about 2500 requests per second before it starts to increase latency and, at some point, leads to errors.
• Each of the data-plane components consumes up to 1 vCPU of CPU for handling 2500 requests per second. Note that this highly depends on the payload size and the response times of the Knative Service backend.

Procedure

• To fine-tune your installation, use the earlier findings combined with your own test results to configure the KnativeServing custom resource:

  A high workload configuration in KnativeServing CR

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 2 1
    workloads:
      - name: component-name 2
        replicas: 2 3
        resources:
          - container: container-name
            requests:
              cpu: 4
              memory:
            limits:
              cpu:
              memory:
    podDisruptionBudgets: 5
      - name: name-of-pod-disruption-budget
        minAvailable: 1

  Copy code to clipboard

  1

  Set this parameter to at least 2 to make sure you always have at least two instances of every component running. You can also use workloads to override the replicas for certain components.

  2

  Use the workloads list to configure specific components. Use the deployment name of the component and set the replicas field.

  3

  For the activator, webhook, and 3scale-kourier-gateway components, which use horizontal pod autoscalers (HPAs), the replicas field sets the minimum number of replicas. The actual number of replicas depends on the CPU load and scaling done by the HPAs.

  4

  Set the requested and limited CPU and memory according to at least the idle consumption while also taking the earlier findings and your own test results into consideration.

  5

  Adjust the PodDistruptionBudgets to a value lower than replicas to avoid problems during node maintenance. The default minAvailable sets to 1, so if you increase the required replicas, you must also increase minAvailable.

• You do not set the min-scale annotation.
• You enable scaling to zero.
• You use the KPA class.

Procedure

• Optional: Set the autoscaling.knative.dev/target annotation for your Knative service in the spec of the Service custom resource:

  Example service spec

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: showcase
    namespace: default
  spec:
    template:
      metadata:
        annotations:
          autoscaling.knative.dev/target: "200"

  Copy code to clipboard

• Optional: Use the kn service command to specify the --concurrency-target flag:

  $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

  Copy code to clipboard

  Example command to create a service with a concurrency target of 50 requests

  $ kn service create showcase --image quay.io/openshift-knative/showcase --concurrency-target 50

  Copy code to clipboard

Procedure

• Optional: Set the containerConcurrency spec for your Knative service in the spec of the Service custom resource:

  Example service spec

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: showcase
    namespace: default
  spec:
    template:
      spec:
        containerConcurrency: 50

  Copy code to clipboard

  The default value is 0, which means that the system does not limit the number of simultaneous requests that can reach a single service replica.

  A value greater than 0 sets the exact number of requests that can reach a single service replica at one time. In this example, the system limits concurrency to 50 requests.

• Optional: Use the kn service command to specify the --concurrency-limit flag:

  $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

  Copy code to clipboard

  Example command to create a service with a concurrency limit of 50 requests

  $ kn service create showcase --image quay.io/openshift-knative/showcase --concurrency-limit 50

  Copy code to clipboard

Prerequisites

• You have installed OpenShift Serverless Operator and Knative Serving on your cluster.
• You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
• You are using the default Knative Pod Autoscaler. The scale to zero feature is not available if you are using the Kubernetes Horizontal Pod Autoscaler.

Procedure

• Change the enable-scale-to-zero spec in the KnativeServing custom resource (CR):

  Example KnativeServing CR

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      autoscaler:
        enable-scale-to-zero: "false" 1

  Copy code to clipboard

  1

  The enable-scale-to-zero spec accepts either true or false. When you set the value to true, the system enables scale-to-zero. When you set the value to false, the system scales applications down to the configured minimum scale bound. The default value is true.

Prerequisites

• You have installed OpenShift Serverless Operator and Knative Serving on your cluster.
• You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
• You are using the default Knative Pod Autoscaler. The scale-to-zero feature is not available if you are using the Kubernetes Horizontal Pod Autoscaler.

Procedure

• Modify the scale-to-zero-grace-period spec in the KnativeServing custom resource (CR):

  Example KnativeServing CR

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      autoscaler:
        scale-to-zero-grace-period: "30s" 1

  Copy code to clipboard

  1

  The grace period time in seconds. The default value is 30 seconds.

Prerequisites

• You have installed OpenShift Serverless Operator and Knative Serving on your cluster.
• You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.

Procedure

• Enable the use of init containers by adding the kubernetes.podspec-init-containers flag to the KnativeServing CR:

  Example KnativeServing CR

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      features:
        kubernetes.podspec-init-containers: enabled
  ...

  Copy code to clipboard

• The service image takes a long time to pull due to its size.
• The service takes a long time to become READY because of initial cache priming.
• The cluster relies on autoscaling to allocate resources for new pods.

Procedure

• Define startup probes for your service by modifying your deployment configuration. The following example shows a configuration with two containers:

  Example of defined starup probes

  apiVersion: serving.knative.dev/v1
  kind: Service
  # ...
  spec:
    template:
      spec:
         containers:
          - name: first-container
            image: <image>
            ports:
              - containerPort: 8080
            # ...
            startupProbe: 1
            httpGet:
              port: 8080
              path: "/"
          - name: second-container
            image: <image>
            # ...
            startupProbe: 2
            httpGet:
              port: 8081
              path: "/"

  Copy code to clipboard

  1

  Startup probe of the first-container.

  2

  Startup probe of the second-container.

• initialDelaySeconds
• failureThreshold
• periodSeconds
• timeoutSeconds

Procedure

• To configure the progress deadline setting, use an annotation in your deployment configuration.

  Example of progress deadline set to 60 seconds

  apiVersion: serving.knative.dev/v1
  kind: Service
  ...
  spec:
    template:
      metadata:
         annotations:
              serving.knative.dev/progress-deadline: "60s"
      spec:
          containers:
              - image: ghcr.io/knative/helloworld-go:latest

  Copy code to clipboard

Procedure

• In your KnativeServing CR, modify the registriesSkippingTagResolving setting with the list of registries for which tag resoution will be skipped:

  Example of configured tag resolution skipping

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      deployment:
        registriesSkippingTagResolving: "registry.example.com, another.registry.com"

  Copy code to clipboard

Procedure

• In your KnativeServing CR, configure the runtime-class-name setting:

  Example of configured runtime-class-name setting

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      deployment:
        runtime-class-name: |
          kata: {}
          gvisor:
            selector:
              my-label: selector

  Copy code to clipboard

• The service image takes a long time to pull due to its size.
• The service takes a long time to become READY because of initial cache priming.
• The cluster relies on autoscaling to allocate resources for new pods.

Procedure

• To get the current Envoy bootstrap configuration, run the following command:

  Example command

  $ oc get cm kourier-bootstrap -n knative-serving-ingress -o yaml

  Copy code to clipboard

  For example, with the default configuration, the example command produces the following output:

  Example output

  Name:         kourier-bootstrap
  Namespace:    knative-serving-ingress
  Labels:       app.kubernetes.io/component=net-kourier
                app.kubernetes.io/name=knative-serving
                app.kubernetes.io/version=release-v1.10
                networking.knative.dev/ingress-provider=kourier
                serving.knative.openshift.io/ownerName=knative-serving
                serving.knative.openshift.io/ownerNamespace=knative-serving
  Annotations:  manifestival: new

  Copy code to clipboard

  Example Data output

  dynamic_resources:
    ads_config:
      transport_api_version: V3
      api_type: GRPC
      rate_limit_settings: {}
      grpc_services:
      - envoy_grpc: {cluster_name: xds_cluster}
    cds_config:
      resource_api_version: V3
      ads: {}
    lds_config:
      resource_api_version: V3
      ads: {}
  node:
    cluster: kourier-knative
    id: 3scale-kourier-gateway
  static_resources:
    listeners:
      - name: stats_listener
        address:
          socket_address:
            address: 0.0.0.0
            port_value: 9000
        filter_chains:
          - filters:
              - name: envoy.filters.network.http_connection_manager
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                  stat_prefix: stats_server
                  http_filters:
                    - name: envoy.filters.http.router
                      typed_config:
                        "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
                  route_config:
                    virtual_hosts:
                      - name: admin_interface
                        domains:
                          - "*"
                        routes:
                          - match:
                              safe_regex:
                                regex: '/(certs|stats(/prometheus)?|server_info|clusters|listeners|ready)?'
                              headers:
                                - name: ':method'
                                  string_match:
                                    exact: GET
                            route:
                              cluster: service_stats
    clusters:
      - name: service_stats
        connect_timeout: 0.250s
        type: static
        load_assignment:
          cluster_name: service_stats
          endpoints:
            lb_endpoints:
              endpoint:
                address:
                  pipe:
                    path: /tmp/envoy.admin
      - name: xds_cluster
        # This keepalive is recommended by envoy docs.
        # https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
        typed_extension_protocol_options:
          envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
            "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
            explicit_http_config:
              http2_protocol_options:
                connection_keepalive:
                  interval: 30s
                  timeout: 5s
        connect_timeout: 1s
        load_assignment:
          cluster_name: xds_cluster
          endpoints:
            lb_endpoints:
              endpoint:
                address:
                  socket_address:
                    address: "net-kourier-controller.knative-serving-ingress.svc.cluster.local."
                    port_value: 18000
        type: STRICT_DNS
  admin:
    access_log:
    - name: envoy.access_loggers.stdout
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
    address:
      pipe:
        path: /tmp/envoy.admin
  layered_runtime:
    layers:
      - name: static-layer
        static_layer:
          envoy.reloadable_features.override_request_timeout_by_gateway_timeout: false

  Copy code to clipboard

  Example BinaryData output

  Events:  <none>

  Copy code to clipboard

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving.
• You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.

Procedure

• Specify a custom bootstrapping config map by changing the spec.ingress.kourier.bootstrap-configmap field in the KnativeServing custom resource (CR):

  Example KnativeServing CR

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    config:
      network:
        ingress-class: kourier.ingress.networking.knative.dev
    ingress:
      kourier:
        bootstrap-configmap: my-configmap
        enabled: true
  # ...

  Copy code to clipboard

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving.
• You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.

Prerequisites

• Install the OpenShift CLI (oc).
• OpenShift Serverless Operator and Knative Serving are installed on your cluster.

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving.

• You have the required permissions for your cluster:

  • Cluster administrator permissions on OpenShift Container Platform
  • Cluster administrator or dedicated administrator permissions on Red Hat OpenShift Service on AWS
  • Cluster administrator or dedicated administrator permissions on OpenShift Dedicated

Procedure

• Choose the appropriate method to configure the revision timeout:

  • To configure the revision timeout globally, set the revision-timeout-seconds field in the KnativeServing custom resource (CR):

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      config:
        defaults:
          revision-timeout-seconds: "300"

    Copy code to clipboard

  • To configure the timeout per revision by setting the timeoutSeconds field in your service definition:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      namespace: my-ns
    spec:
      template:
        spec:
          timeoutSeconds: 300
          containers:
          - image: ghcr.io/knative/helloworld-go:latest

    Copy code to clipboard
  Note

  To set the revision timeout to a value over 600 seconds (10 minutes), you must increase the default OpenShift Container Platform route timeout and the maximum revision timeout.

  For instructions on how to configure timeouts for requests exceeding the default 600 seconds (10 minutes), see "Long-running requests".

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving.

• You have the required permissions for your cluster:

  • Cluster administrator permissions on OpenShift Container Platform
  • Cluster administrator or dedicated administrator permissions on Red Hat OpenShift Service on AWS
  • Cluster administrator or dedicated administrator permissions on OpenShift Dedicated

Procedure

• To configure the maximum revision timeout, set the max-revision-timeout-seconds field in the KnativeServing custom resource (CR):

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    config:
      defaults:
        max-revision-timeout-seconds: "600"

  Copy code to clipboard
  Note

  To set the maximum revision timeout to a value over 600 seconds (10 minutes), you must increase the default OpenShift Container Platform route timeout.

  For instructions on how to configure timeouts for requests exceeding the default 600 seconds (10 minutes), see "Long-running requests".

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving.

• You have the required permissions for your cluster:

  • Cluster administrator permissions on OpenShift Container Platform
  • Cluster administrator or dedicated administrator permissions on Red Hat OpenShift Service on AWS
  • Cluster administrator or dedicated administrator permissions on OpenShift Dedicated

Procedure

• Choose the appropriate method to configure the revision response start timeout:

  • To configure the timeout globally, set the revision-response-start-timeout-seconds field in your KnativeServing custom resource (CR). If your required response start timeout exceeds the revision timeout, also adjust the revision-timeout-seconds field:

    Example of revision response start timeout globally set to 300 seconds (5 minutes)

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      config:
        defaults:
          revision-timeout-seconds: "600"
          revision-response-start-timeout-seconds: "300"

    Copy code to clipboard

  • To configure the timeout per revision, set the responseStartTimeoutSeconds field in your service definition. If your required response start timeout exceeds the revision timeout, also adjust the timeoutSeconds field:

    Example of a service definition with revision response start timeout set to 300 seconds (5 minutes)

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      namespace: my-ns
    spec:
      template:
        spec:
          timeoutSeconds: 600
          responseStartTimeoutSeconds: 300
          containers:
    # ...

    Copy code to clipboard

  Note

  To set the revision response start timeout and the revision timeout to a value over 600 seconds (10 minutes), you must increase the default OpenShift Container Platform route timeout and the maximum revision timeout.

  For instructions on how to configure timeouts for requests exceeding the default 600 seconds (10 minutes), see "Long-running requests".

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving.

• You have the required permissions for your cluster:

  • Cluster administrator permissions on OpenShift Container Platform
  • Cluster administrator or dedicated administrator permissions on Red Hat OpenShift Service on AWS
  • Cluster administrator or dedicated administrator permissions on OpenShift Dedicated

Procedure

• Choose the appropriate method to configure the revision idle timeout:

  • To configure the timeout globally, set the revision-idle-timeout-seconds field in your KnativeServing custom resource (CR):

    Example of revision idle timeout globally set to 300 seconds (5 minutes)

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      config:
        defaults:
          revision-idle-timeout-seconds: "300"

    Copy code to clipboard

  • To configure the timeout per revision, set the idleTimeoutSeconds field in your service definition:

    Example of a service definition with revision idle timeout set to 300 seconds (5 minutes)

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      namespace: my-ns
    spec:
      template:
        spec:
          idleTimeoutSeconds: 300
          containers:
    # ...

    Copy code to clipboard

• OpenShift Container Platform route
• OpenShift Serverless Serving
• Load balancer, depending on the cloud provider

• Native mTLS between all connections
• Serverless components are part of a service mesh
• Additional observability and metrics
• Authorization and authentication support
• Custom rules and configuration, as supported by Red Hat OpenShift Service Mesh

• A cluster-external route that is forwarded by the OpenShift router, for example myapp-namespace.example.com.
• A cluster-local route containing the cluster domain, for example myapp.namespace.svc.cluster.local. This domain can and should be used to call Knative services from Knative or other user workloads.

• In the serve mode, requests go directly to the Queue-Proxy sidecar container of the Knative service.
• In the proxy mode, requests first go through the Activator component in the knative-serving namespace.

• The Certificate Common Name (CN) or Subject Alternative Name (SAN) contains the cluster-local domains of a Knative Service, for example myapp.namespace.svc.cluster.local, myapp.namespace.svc, myapp.namespace.
• The cluster-local endpoint of the ingress-controller component uses SNI to select the certificates.
• To create the certificates, Knative relies on cert-manager, which needs to be installed and configured for the feature to work. For more information, see cert-manager Operator for Red Hat OpenShift.

• For OpenShift Serverless to get the certificates, cert-manager must be installed and configured.
• Specific SANs are used to verify each connection. Each component must trust the CA that signed the certificates. To satisfy this requirement, OpenShift Serverless system components consume and trust a bundle of CAs. The CA bundle must be provided by the cluster administrator.

• For cluster-local encryption, the issuer must be able to sign certificates for the following cluster-local domain types:

  • myapp.<namespace>
  • myapp.<namespace>.svc
  • myapp.<namespace>.svc.cluster.local

  As the CA usually is not within the cluster, verification using the Automated Certificate Management Environment (ACME) protocol (DNS01/HTTP01) is not possible. You can use an issuer that allows creating these certificates, such as the cert-manager CA issuer.

• For system-internal encryption, the issuer must be able to sign certificates with the following Subject Alternative Names (SANs):

  • kn-routing
  • names of format kn-user-<namespace>, where <namespace> is a namespace where Knative Services are created
  • data-plane.knative.dev

  Knative requires these SANs to verify connections between the internal components. Because this is not possible using the ACME protocol (DNS01/HTTP01), you must configure an issuer that allows creating these certificates, for example, cert-manager CA issuer.

• Adding a CA bundle to a Container image on build-time. Note that this complicates CA rotation, as you must rebuild and redeploy every application when the CA rotates.
• Mounting a CA bundle to the filesystem, such as from a Secret or ConfigMap, and making sure your application uses it to verify TLS connections.
• Reading a CA bundle from an environment variable and making sure that your application uses it to verify TLS connections.
• Accessing a CA bundle from a secret or ConfigMap using Kubernetes API and making sure your application uses it to verify TLS connections.

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving on your cluster.
• You have installed the Knative (kn) CLI.
• You have created a Knative service.

Procedure

• Specify the revision of your service and what percentage of traffic you want to route to it by using the --traffic tag with a standard kn service update command:

  Example command

  $ kn service update <service_name> --traffic <revision>=<percentage>

  Copy code to clipboard

  Where:

  • <service_name> is the name of the Knative service that you are configuring traffic routing for.
  • <revision> is the revision that you want to configure to receive a percentage of traffic. You can either specify the name of the revision, or a tag that you assigned to the revision by using the --tag flag.
  • <percentage> is the percentage of traffic that you want to send to the specified revision.

• Optional: Specify the --traffic flag many times in a single command. For example, if you have a revision tagged as @latest and a revision named stable, you can specify the percentage of traffic that you want to split to each revision as follows:

  Example command

  $ kn service update showcase --traffic @latest=20,stable=80

  Copy code to clipboard

  If you have many revisions and do not specify the traffic percentage for the latest revision, the --traffic flag calculates it automatically. For example, if you have a third revision named example, and you use the following command:

  Example command

  $ kn service update showcase --traffic @latest=10,stable=60

  Copy code to clipboard

  The system sends the remaining 30% of traffic to the example revision, even though the command does not specify it.

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving on your cluster.
• You have logged in to the OpenShift Container Platform web console.

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving on the cluster.
• Install the OpenShift CLI (oc).

Prerequisites

• You must have the OpenShift Serverless Operator and Knative Serving installed on your OpenShift Container Platform cluster.
• Install the OpenShift CLI (oc).

Procedure

• Set the visibility for your service by adding the networking.knative.dev/visibility=cluster-local label:

  $ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local

  Copy code to clipboard

Verification

• Check that the URL for your service is now in the format http://<service_name>.<namespace>.svc.cluster.local, by entering the following command and reviewing the output:

  $ oc get ksvc

  Copy code to clipboard

  Example output

  NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
  hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True

  Copy code to clipboard

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving.
• You have administrator permissions.
• You have installed the OpenShift (oc) CLI.

Prerequisites

• Install OpenShift Serverless Operator and Knative Serving on your cluster.
• Install the OpenShift CLI (oc).
• Create a Knative service.
• Upgrade OpenShift Container Platform 4.10 or later.
• Enable HTTP/2 on OpenShift Ingress controller.

Procedure

• Use a label selector in the IngressController CR to configure OpenShift Serverless to match specific ingress shards with different domains:

  Example IngressController CR

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: ingress-dev 1
    namespace: openshift-ingress-operator
  spec:
    routeSelector:
      matchLabels:
        router: dev 2
    domain: "dev.serverless.cluster.example.com" 3
    # ...
  ---
  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: ingress-prod 4
    namespace: openshift-ingress-operator
  spec:
    routeSelector:
      matchLabels:
        router: prod 5
    domain: "prod.serverless.cluster.example.com" 6
    # ...

  Copy code to clipboard

  1

  Name of the first ingress shard.

  2

  A label selector to match the ingress-dev shard.

  3

  A custom domain for the ingress-dev shard.

  4

  Name of the second ingress shard.

  5

  A label selector to match the ingress-prod shard.

  6

  A custom domain for the ingress-prod shard.

Procedure

• In the KnativeServing CR, configure Serving to use the same domains and labels as your ingress shards by adding the spec.config.domain field:

  Example KnativeServing CR

  spec:
    config:
      domain: 1
        dev.serverless.cluster.example.com: |
          selector:
            router: dev
        prod.serverless.cluster.example.com: |
          selector:
            router: prod
    # ...

  Copy code to clipboard

  1

  These values need to match the values in the ingress shard configuration.

Procedure

• In your Service CR, add the label selector that matches a specific shard:

  Example Service CR

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: hello-dev
    labels:
      router: dev 1
  spec:
    template:
      spec:
        containers:
        - image: docker.io/openshift/hello-openshift
  ---
  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: hello-prod
    labels:
      router: prod 2
  spec:
    template:
      spec:
        containers:
        - image: docker.io/openshift/hello-openshift
    # ...

  Copy code to clipboard

  1 2

  The labels must match the configuration in the KnativeServing CR.

Prerequisites

• You have installed the OpenShift Serverless Operator, Knative Serving, and Red Hat OpenShift Service Mesh on your cluster.
• Install the OpenShift CLI (oc).
• You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Prerequisites

• You have installed the OpenShift Serverless Operator, Knative Serving, and Red Hat OpenShift Service Mesh on your cluster.
• Install the OpenShift CLI (oc).
• You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving on your cluster.
• Install the OpenShift CLI (oc).
• You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

• You have created a Knative service and control a custom domain that you want to map to that service.

  Note

  Your custom domain must point to the IP address of the OpenShift Container Platform cluster.

Prerequisites

• You have installed the OpenShift Serverless Operator and Knative Serving on your cluster.
• You have created a Knative service or route, and control a custom domain that you want to map to that CR.
• Your custom domain must point to the DNS of the OpenShift Container Platform cluster.
• You have installed the Knative (kn) CLI.
• You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Procedure

• Map a domain to a CR in the current namespace:

  $ kn domain create <domain_mapping_name> --ref <target_name>

  Copy code to clipboard

  You get an output similar to the following example command:

  $ kn domain create example.com --ref showcase

  Copy code to clipboard

  The --ref flag specifies an Addressable target CR for domain mapping.

  If you do not give a prefix when using the --ref flag, the system treats the target as a Knative service in the current namespace.

• Map a domain to a Knative service in a specified namespace:

  $ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>

  Copy code to clipboard

  You get an output similar to the following example command:

  $ kn domain create example.com --ref ksvc:showcase:example-namespace

  Copy code to clipboard

• Map a domain to a Knative route:

  $ kn domain create <domain_mapping_name> --ref <kroute:route_name>

  Copy code to clipboard

  You get an output similar to the following example command:

  $ kn domain create example.com --ref kroute:example-route

  Copy code to clipboard

Prerequisites

• You have logged in to the web console.
• You have installed the OpenShift Serverless Operator and Knative Serving on your cluster. Only a cluster administrator can complete this task.
• You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

• You have created a Knative service and control a custom domain that you want to map to that service.

  Note

  Your custom domain must point to the IP address of the OpenShift Container Platform cluster.

Prerequisites

• You have logged in to the web console.
• You have installed the OpenShift Serverless Operator.
• You have installed Knative Serving.

• You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads.

  Note

  Your custom domain must point to the IP address of the cluster.

Procedure

• In the KnativeServing CR, use the cipher-suites value to specify the cipher suites you want to enable:

  KnativeServing CR example

  spec:
    config:
      kourier:
        cipher-suites: ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-CHACHA20-POLY1305

  Copy code to clipboard

  Other cipher suites will be disabled. You can specify multiple suites by separating them with commas.

  Note

  The Kourier Gateway’s container image utilizes the Envoy proxy image, and the default enabled cipher suites depend on the version of the Envoy proxy.

Prerequisites

• You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
• A project that you created or that you have roles and permissions for to create applications and other workloads.
• Install the OpenShift Serverless Operator and Knative Serving.
• Install the OpenShift CLI (oc).

Prerequisites

• You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
• You have installed the OpenShift Serverless Operator and Knative broker for Apache Kafka on your cluster.

Procedure

• Override the default PDB for a specific resource by modifying the minAvailable configuration value in the KnativeServing custom resource (CR).

• The readiness probe timeout for net-kourier-controller is 10 seconds.
• The deployment specifies CPU and memory resource limits.
• The deployment runs with 3 replicas.
• The deployment includes the example-label: label label.
• The deployment includes the example-annotation: annotation annotation.
• The nodeSelector field selects nodes with the disktype: hdd label.