集成

流程

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

   Copy to Clipboard Toggle word wrap

2. 创建通配符证书：

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

   Copy to Clipboard Toggle word wrap

3. 为通配符证书签名：

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   此证书由 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"
   ...

   Copy to Clipboard Toggle word wrap

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

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: {}
   ...

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

流程

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

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

   1

   
   ...

   Copy to Clipboard Toggle word wrap

   1

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

2. 应用 ServiceMeshMemberRoll 资源：

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

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
      ...

      Copy to Clipboard Toggle word wrap

      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

      Copy to Clipboard Toggle word wrap

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

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

      Copy to Clipboard Toggle word wrap

   2. 应用 NetworkPolicy 资源：

      $ oc apply -f <filename>

      Copy to Clipboard Toggle word wrap

流程

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

   Copy to Clipboard Toggle word wrap

   属于网格的所有项目都必须以严格模式强制 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" ]

   Copy to Clipboard Toggle word wrap

   这些策略限制了 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

   Copy to Clipboard Toggle word wrap

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/

   Copy to Clipboard Toggle word wrap

   为 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

   Copy to Clipboard Toggle word wrap

   为 团队 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

   Copy to Clipboard Toggle word wrap

5. 应用授权策略配置：

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

   Copy to Clipboard Toggle word wrap

流程

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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   或者，使用以下 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!"

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   输出示例

   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!

   Copy to Clipboard Toggle word wrap

   通过外部域测试 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

   Copy to Clipboard Toggle word wrap

   输出示例

   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!

   Copy to Clipboard Toggle word wrap

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

   示例命令

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

   Copy to Clipboard Toggle word wrap

   输出示例

   * 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

   Copy to Clipboard Toggle word wrap

   通过外部域测试 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

   Copy to Clipboard Toggle word wrap

   输出示例

   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!

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

流程

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

   

   View larger image

   

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

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

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

     

     View larger image

     
3. 点 Create 创建服务。

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

   

   View larger image

   

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

   

   View larger image

   

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

   

   View larger image

   

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

   

   View larger image

   

流程

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

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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap