Chapter 9. Integrations

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/v1beta1
   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. Create a Knative service and set the GPU resource requirement limit to 1 by using the --limit nvidia.com/gpu=1 flag:

   $ kn service create hello --image <service-image> --limit nvidia.com/gpu=1

   A GPU resource requirement limit of 1 means that the service has 1 GPU resource dedicated. Services do not share GPU resources. Any other services that require GPU resources must wait until the GPU resource is no longer in use.

   A limit of 1 GPU also means that applications exceeding usage of 1 GPU resource are restricted. If a service requests more than 1 GPU resource, it is deployed on a node where the GPU resource requirements can be met.

2. Optional. For an existing service, you can change the GPU resource requirement limit to 3 by using the --limit nvidia.com/gpu=3 flag:

   $ kn service update hello --limit nvidia.com/gpu=3