集成

流程

1. 创建为 Knative 服务签名的 root 证书和私钥：

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

2. 创建通配符证书：

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

3. 为通配符证书签名：

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

4. 使用通配符证书创建 secret：

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

   此证书由 OpenShift Serverless 与 Service Mesh 集成时创建的网关获取，以便入口网关使用此证书提供流量。

流程

1. 在 Knative Serving 自定义资源 (CR) 的 observability spec 中将 prometheus 指定为 metrics.backend-destination ：

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

   此步骤可防止默认禁用指标。

2. 应用以下网络策略来允许来自 Prometheus 命名空间中的流量：

   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. 修改并重新应用 istio-system 命名空间中的默认 Service Mesh control plane，使其包含以下 spec：

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

流程

1. 将您要与 Service Mesh 集成的命名空间作为成员添加到 ServiceMeshMemberRoll 对象中：

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

   1

   要与 Service Mesh 集成的命名空间列表。

2. 应用 ServiceMeshMemberRoll 资源：

   $ oc apply -f <filename>

3. 创建允许 Knative 系统 Pod 到 Knative 服务流量的网络策略：

   1. 对于您要与 Service Mesh 集成的每个命名空间，创建一个 NetworkPolicy 资源：

      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

      添加您要与 Service Mesh 集成的命名空间。

      注意

      knative.openshift.io/part-of: "openshift-serverless" 标签添加到 OpenShift Serverless 1.22.0 中。如果使用 OpenShift Serverless 1.21.1 或更早版本，请将 knative.openshift.io/part-of 标签添加到 knative-serving 和 knative-serving-ingress 命名空间。

      将标签添加到 knative-serving 命名空间：

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

      将标签添加到 knative-serving-ingress 命名空间：

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

   2. 应用 NetworkPolicy 资源：

      $ oc apply -f <filename>

流程

1. 确保租户的所有 Red Hat OpenShift Serverless 项目都是与成员相同的 ServiceMeshMemberRoll 对象的一部分：

   apiVersion: maistra.io/v1
   kind: ServiceMeshMemberRoll
   metadata:
    name: default
    namespace: istio-system
   spec:
    members:
      - knative-serving    # static value, needs to be here, see setup page
      - knative-eventing   # static value, needs to be here, see setup page
      - team-alpha-1       # example OpenShift project that belongs to the team-alpha tenant
      - team-alpha-2       # example OpenShift project that belongs th the team-alpha tenant
      - team-bravo-1       # example OpenShift project that belongs to the team-bravo tenant
      - team-bravo-2       # example OpenShift project that belongs th the team-bravo tenant

   属于网格的所有项目都必须以严格模式强制 mTLS。这会强制 Istio 只接受与 client-certificate 存在的连接，并允许 Service Mesh sidecar 使用 AuthorizationPolicy 对象验证原始源。

2. 在 knative-serving 和 knative-eventing 命名空间中创建带有 AuthorizationPolicy 对象的配置：

   knative-default-authz-policies.yaml 配置文件示例

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: deny-all-by-default
     namespace: knative-eventing
   spec: { }
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: deny-all-by-default
     namespace: knative-serving
   spec: { }
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-mt-channel-based-broker-ingress-to-imc-dispatcher
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "imc-dispatcher"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-mt-channel-based-broker-ingress-to-kafka-channel
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-channel-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-kafka-channel-to-mt-channel-based-broker-filter
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "broker-filter"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/knative-kafka-channel-data-plane" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-imc-to-mt-channel-based-broker-filter
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "broker-filter"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/imc-dispatcher" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-broker-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-broker-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-sink-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-sink-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-channel-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-channel-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-traffic-to-activator
     namespace: knative-serving
   spec:
     selector:
       matchLabels:
         app: activator
     action: ALLOW
     rules:
       - from:
           - source:
               namespaces: [ "knative-serving", "istio-system" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-traffic-to-autoscaler
     namespace: knative-serving
   spec:
     selector:
       matchLabels:
         app: autoscaler
     action: ALLOW
     rules:
       - from:
           - source:
               namespaces: [ "knative-serving" ]

   这些策略限制了 Serverless 系统组件之间的网络通信的访问规则。具体来说，它们强制执行以下规则：

   • 拒绝 knative-serving 和 knative-eventing 命名空间中未明确允许的所有流量
   • 允许来自 istio-system 和 knative-serving 命名空间的流量来激活器
   • 允许从 knative-serving 命名空间到自动扩展的流量
   • 在 knative-eventing 命名空间中允许 Apache Kafka 组件的健康探测
   • 在 knative-eventing 命名空间中允许基于频道的代理的内部流量

3. 应用授权策略配置：

   $ oc apply -f knative-default-authz-policies.yaml

4. 定义哪些 OpenShift 项目可以相互通信。对于此通信，租户的每个 OpenShift 项目都需要以下内容：

   • 一个 AuthorizationPolicy 对象将直接传入的流量限制到租户的项目
   • 一个 AuthorizationPolicy 对象使用 knative-serving 项目中运行的 Serverless 的激活器组件限制传入的流量
   • 一个 AuthorizationPolicy 对象，允许 Kubernetes 在 Knative Services 上调用 PreStopHooks

   安装 helm 工具并为每个租户创建所需资源，而不是手动创建这些策略：

   安装 helm 工具

   $ helm repo add openshift-helm-charts https://charts.openshift.io/

   为 team alpha创建配置示例

   $ helm template openshift-helm-charts/redhat-knative-istio-authz --version 1.31.0 --set "name=team-alpha" --set "namespaces={team-alpha-1,team-alpha-2}" > team-alpha.yaml

   为 团队 bravo创建示例配置

   $ helm template openshift-helm-charts/redhat-knative-istio-authz --version 1.31.0 --set "name=team-bravo" --set "namespaces={team-bravo-1,team-bravo-2}" > team-bravo.yaml

5. 应用授权策略配置：

   $ oc apply -f team-alpha.yaml team-bravo.yaml

流程

1. 在两个租户的命名空间中部署 Knative Services：

   team-alpha的命令示例

   $ kn service create test-webapp -n team-alpha-1 \
       --annotation-service serving.knative.openshift.io/enablePassthrough=true \
       --annotation-revision sidecar.istio.io/inject=true \
       --env RESPONSE="Hello Serverless" \
       --image docker.io/openshift/hello-openshift

   team-bravo的命令示例

   $ kn service create test-webapp -n team-bravo-1 \
       --annotation-service serving.knative.openshift.io/enablePassthrough=true \
       --annotation-revision sidecar.istio.io/inject=true \
       --env RESPONSE="Hello Serverless" \
       --image docker.io/openshift/hello-openshift

   或者，使用以下 YAML 配置：

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: test-webapp
     namespace: team-alpha-1
     annotations:
       serving.knative.openshift.io/enablePassthrough: "true"
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
           - image: docker.io/openshift/hello-openshift
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"
   ---
   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: test-webapp
     namespace: team-bravo-1
     annotations:
       serving.knative.openshift.io/enablePassthrough: "true"
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
           - image: docker.io/openshift/hello-openshift
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"

2. 部署 curl pod 来测试连接：

   $ cat <<EOF | oc apply -f -
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: curl
     namespace: team-alpha-1
     labels:
       app: curl
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: curl
     template:
       metadata:
         labels:
           app: curl
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
         - name: curl
           image: curlimages/curl
           command:
           - sleep
           - "3600"
   EOF

3. 使用 curl 命令验证配置。

   通过集群本地域测试 team-alpha-1 → team-alpha-1，这是允许的：

   示例命令

   $ oc exec deployment/curl -n team-alpha-1 -it -- curl -v http://test-webapp.team-alpha-1:80

   输出示例

   HTTP/1.1 200 OK
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:49:59 GMT
   server: envoy
   x-envoy-upstream-service-time: 9
   
   Hello Serverless!

   通过外部域测试 team-alpha-1 到 team-alpha-1 连接，允许：

   示例命令

   $ EXTERNAL_URL=$(oc get ksvc -n team-alpha-1 test-webapp -o custom-columns=:.status.url --no-headers) && \
   oc exec deployment/curl -n team-alpha-1 -it -- curl -ik $EXTERNAL_URL

   输出示例

   HTTP/2 200
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:55:30 GMT
   server: istio-envoy
   x-envoy-upstream-service-time: 3629
   
   Hello Serverless!

   通过集群的本地域测试 team-alpha-1 到 team-bravo-1 连接，这是不允许的：

   示例命令

   $ oc exec deployment/curl -n team-alpha-1 -it -- curl -v http://test-webapp.team-bravo-1:80

   输出示例

   * processing: http://test-webapp.team-bravo-1:80
   *   Trying 172.30.73.216:80...
   * Connected to test-webapp.team-bravo-1 (172.30.73.216) port 80
   > GET / HTTP/1.1
   > Host: test-webapp.team-bravo-1
   > User-Agent: curl/8.2.0
   > Accept: */*
   >
   < HTTP/1.1 403 Forbidden
   < content-length: 19
   < content-type: text/plain
   < date: Wed, 26 Jul 2023 12:55:49 GMT
   < server: envoy
   < x-envoy-upstream-service-time: 6
   <
   * Connection #0 to host test-webapp.team-bravo-1 left intact
   RBAC: access denied

   通过外部域测试 team-alpha-1 到 team-bravo-1 连接，允许：

   示例命令

   $ EXTERNAL_URL=$(oc get ksvc -n team-bravo-1 test-webapp -o custom-columns=:.status.url --no-headers) && \
   oc exec deployment/curl -n team-alpha-1 -it -- curl -ik $EXTERNAL_URL

   输出示例

   HTTP/2 200
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:56:22 GMT
   server: istio-envoy
   x-envoy-upstream-service-time: 2856
   
   Hello Serverless!

4. 删除为验证创建的资源：

   $ oc delete deployment/curl -n team-alpha-1 && \
   oc delete ksvc/test-webapp -n team-alpha-1 && \
   oc delete ksvc/test-webapp -n team-bravo-1

流程

1. 在 OpenShift Container Platform web 控制台 Developer 视角中，导航到 +Add 并选择 Import from Git 选项。

   

2. 在 Import from Git 对话框中，执行以下操作来指定项目元数据：

   • 指定 Git 存储库 URL。
   • 如有必要，指定上下文目录。这是包含应用源代码根目录的存储库内的子目录。
   • 可选：指定应用程序名称。默认情况下使用存储库名称。
   • 选择 Serverless Deployment 资源类型。
   • 选择 Add pipeline 复选框。管道根据源代码自动选择，其视觉化显示在方案中。

   • 指定任何其他相关设置。

     
3. 点 Create 创建服务。

4. 在服务创建启动后，您将进入 Topology 屏幕，其中会视觉化您的服务和相关触发器，以及您可以与之交互的位置。

   

5. 可选：通过进入到 Pipelines 页面来验证管道是否已创建并部署了该服务：

   

6. 要查看管道的详情，点 Pipelines 页面中的管道。

   

7. 要查看当前管道运行的详情，请点 Pipelines 页面中运行的名称。

   

流程

1. 创建 Knative 服务并使用 --limit nvidia.com/gpu=1 标志将 GPU 资源要求限制设置为 1：

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

   GPU 资源要求限制为 1 表示该服务有 1 个专用的 GPU 资源。服务不共享 GPU 资源。所有需要 GPU 资源的其他服务都必须等待 GPU 资源不再被使用为止。

   限值为 1 个 GPU 意味着超过使用 1 个 GPU 资源的应用程序会受到限制。如果服务请求超过 1 个 GPU 资源，它将部署到可以满足 GPU 资源要求的节点。

2. 可选。对于现有服务，您可以使用 --limit nvidia.com/gpu=3 标志将 GPU 资源要求限制改为 3：

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