Serving

流程

1. 创建包含以下示例代码的 YAML 文件：

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: showcase
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/showcase
             env:
               - name: GREET
                 value: Bonjour

2. 导航到包含 YAML 文件的目录，并通过应用 YAML 文件来部署应用程序：

   $ oc apply -f <filename>

流程

1. 进入 Serverless → Serving 页面。
2. 在 Create 列表中，选择 Service。
3. 手动输入 YAML 或 JSON 定义，或者将文件拖放到编辑器中。
4. 点 Create。

流程

1. 在离线模式下，创建一个本地 Knative 服务描述符文件：

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

   输出示例

   Service 'showcase' created in namespace 'test'.

   • --target ./ 标志启用脱机模式，并将 ./ 指定为用于存储新目录树的目录。

     如果您没有指定现有目录，但使用文件名，如 --target my-service.yaml，则不会创建目录树。相反，当前目录中只创建服务描述符 my-service.yaml 文件。

     文件名可以具有 .yaml、.yml 或 .json 扩展名。选择 .json 以 JSON 格式创建服务描述符文件。

   • namespace test 选项将新服务放在 test 命名空间中。

     如果不使用 --namespace，且您登录到 OpenShift Container Platform 集群，则会在当前命名空间中创建描述符文件。否则，描述符文件会在 default 命名空间中创建。

2. 检查创建的目录结构：

   $ tree ./

   输出示例

   ./
   └── test
       └── ksvc
           └── showcase.yaml
   
   2 directories, 1 file

   • 使用 --target 指定的当前 ./ 目录包含新的 test/ 目录，它在指定的命名空间后命名。
   • test/ 目录包含 ksvc，它在资源类型后命名。
   • ksvc 目录包含描述符文件 showcase.yaml，根据指定的服务名称命名。

3. 检查生成的服务描述符文件：

   $ cat test/ksvc/showcase.yaml

   输出示例

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     creationTimestamp: null
     name: showcase
     namespace: test
   spec:
     template:
       metadata:
         annotations:
           client.knative.dev/user-image: quay.io/openshift-knative/showcase
         creationTimestamp: null
       spec:
         containers:
         - image: quay.io/openshift-knative/showcase
           name: ""
           resources: {}
   status: {}

4. 列出新服务的信息：

   $ kn service describe showcase --target ./ --namespace test

   输出示例

   Name:       showcase
   Namespace:  test
   Age:
   URL:
   
   Revisions:
   
   Conditions:
     OK TYPE    AGE REASON

   • --target ./ 选项指定包含命名空间子目录的目录结构的根目录。

     另外，您可以使用 --target 选项直接指定 YAML 或 JSON 文件名。可接受的文件扩展包括 .yaml、.yml 和 .json。

   • --namespace 选项指定命名空间，与 kn 通信包含所需服务描述符文件的子目录。

     如果不使用 --namespace，并且您登录到 OpenShift Container Platform 集群，kn 会在以当前命名空间命名的子目录中搜索该服务。否则，kn 在 default/ 子目录中搜索。

5. 使用服务描述符文件在集群中创建服务：

   $ kn service create -f test/ksvc/showcase.yaml

   输出示例

   Creating service 'showcase' in namespace 'test':
   
     0.058s The Route is still working to reflect the latest desired specification.
     0.098s ...
     0.168s Configuration "showcase" is waiting for a Revision to become ready.
    23.377s ...
    23.419s Ingress has not yet been reconciled.
    23.534s Waiting for load balancer to be ready
    23.723s Ready to serve.
   
   Service 'showcase' created to latest revision 'showcase-00001' is available at URL:
   http://showcase-test.apps.example.com

流程

1. 查找应用程序 URL:

   $ oc get ksvc <service_name>

   输出示例

   NAME       URL                                   LATESTCREATED    LATESTREADY      READY   REASON
   showcase   http://showcase-default.example.com   showcase-00001   showcase-00001   True

2. 向集群发出请求并观察其输出。

   HTTP 请求示例（使用 HTTPie 工具）

   $ http showcase-default.example.com

   HTTPS 请求示例

   $ https showcase-default.example.com

   输出示例

   HTTP/1.1 200 OK
   Content-Type: application/json
   Server: Quarkus/2.13.7.Final-redhat-00003 Java/17.0.7
   X-Config: {"sink":"http://localhost:31111","greet":"Ciao","delay":0}
   X-Version: v0.7.0-4-g23d460f
   content-length: 49
   
   {
       "artifact": "knative-showcase",
       "greeting": "Ciao"
   }

3. 可选。如果您的系统中没有安装 HTTPie 工具，您可以使用 curl 工具：

   HTTPS 请求示例

   $ curl http://showcase-default.example.com

   输出示例

   {"artifact":"knative-showcase","greeting":"Ciao"}

4. 可选。如果您在证书链中收到与自签名证书相关的错误，您可以在 HTTPie 命令中添加 --verify=no 标志来忽略错误：

   $ https --verify=no showcase-default.example.com

   输出示例

   HTTP/1.1 200 OK
   Content-Type: application/json
   Server: Quarkus/2.13.7.Final-redhat-00003 Java/17.0.7
   X-Config: {"sink":"http://localhost:31111","greet":"Ciao","delay":0}
   X-Version: v0.7.0-4-g23d460f
   content-length: 49
   
   {
       "artifact": "knative-showcase",
       "greeting": "Ciao"
   }

   重要

   在生产部署中不能使用自签名证书。这个方法仅用于测试目的。

5. 可选。如果 OpenShift Container Platform 集群配置有证书颁发机构 (CA) 签名但尚未为您的系统配置全局证书，您可以使用 curl 命令指定此证书。证书的路径可使用 --cacert 标志传递给 curl 命令：

   $ curl https://showcase-default.example.com --cacert <file>

   输出示例

   {"artifact":"knative-showcase","greeting":"Ciao"}

流程

1. 修改您的服务使其包含其他容器。只有一个容器可以处理请求，因此为一个容器指定一个 端口。以下是有两个容器的示例配置：

   多容器配置

   apiVersion: serving.knative.dev/v1
   kind: Service
   ...
   spec:
     template:
       spec:
         containers:
           - name: first-container 1
             image: gcr.io/knative-samples/helloworld-go
             ports:
               - containerPort: 8080 2
           - name: second-container 3
             image: gcr.io/knative-samples/helloworld-java

   1

   第一个容器配置。

   2

   第一个容器的端口规格。

   3

   第二个容器配置。

流程

1. 要启用 Knative Serving 使用 PVC 并写入它们，请修改 KnativeServing 自定义资源 (CR) 使其包含以下 YAML：

   启用具有写入访问的 PVC

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

   • kubernetes.podspec-persistent-volume-claim 扩展控制持久性卷 (PV) 是否可以用于 Knative Serving。
   • kubernetes.podspec-persistent-volume-write 扩展控制 Knative Serving 是否使用写入访问权限。

2. 要声明 PV，请修改您的服务使其包含 PV 配置。例如，您可能具有以下配置的持久性卷声明：

   注意

   使用支持您要请求的访问模式的存储类。例如，您可以将 ocs-storagecluster-cephfs 存储类用于 ReadWriteMany 访问模式。

   ocs-storagecluster-cephfs 存储类被支持，并来自 Red Hat OpenShift Data Foundation。

   PersistentVolumeClaim 配置

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

   在这种情况下，若要声明具有写访问权限的 PV，请修改服务，如下所示：

   Knative 服务 PVC 配置

   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

   卷挂载规格。

   2

   持久性卷声明规格。

   3

   启用只读访问的标记。

   注意

   要在 Knative 服务中成功使用持久性存储，您需要额外的配置，如 Knative 容器用户的用户权限。

流程

1. 创建或更新 KnativeServing 资源，并确保它在 spec 中包含 internal-encryption: "true" 字段：

   ...
   spec:
     config:
       network:
         internal-encryption: "true"
   ...

2. 重启 knative-serving 命名空间中的 activator pod 来加载证书：

   $ oc delete pod -n knative-serving --selector app=activator

流程

1. 将 knative.openshift.io/system-namespace=true 标签添加到需要访问应用程序的每个 Knative 系统命名空间：

   1. 标记 knative-serving 命名空间：

      $ oc label namespace knative-serving knative.openshift.io/system-namespace=true

   2. 标记 knative-serving-ingress 命名空间：

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true

   3. 标记 knative-eventing 命名空间：

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true

   4. 标记 knative-kafka 命名空间：

      $ oc label namespace knative-kafka knative.openshift.io/system-namespace=true

2. 在应用程序命名空间中创建一个 NetworkPolicy 对象，允许从带有 knative.openshift.io/system-namespace 标签的命名空间访问：

   NetworkPolicy 对象示例

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: <network_policy_name> 1
     namespace: <namespace> 2
   spec:
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             knative.openshift.io/system-namespace: "true"
     podSelector: {}
     policyTypes:
     - Ingress

   1

   为您的网络策略提供名称。

   2

   应用程序所在的命名空间。

1. 点 Knative 服务在侧面面板中查看其概述信息。

2. 点 Resources 选项卡，查看服务的 Revisions 和 Routes 列表。

   图 6.1. 无服务器应用程序

   
3. 点侧边面板顶部的由 S 图标代表的服务，查看服务详情概述。
4. 点 YAML 选项卡，在 YAML 编辑器中修改服务配置，然后点 Save。例如，将 timeoutseconds 从 300 改为 301。这个配置更改会触发新修订版本。在 Topology 视图中会显示最新的修订，服务 Resources 选项卡现在会显示两个修订版本。

5. 在 Resources 选项卡中，点 Set Traffic Distribution 查看流量分布对话框：

   1. 在 Splits 字段中为两个修订版本添加流量百分比。
   2. 添加标签以便为这两个修订版本创建自定义 URL。

   3. 点 Save 查看两个节点，分别代表 Topology 视图中的两个修订版本。

      图 6.2. 无服务器应用程序修订

      

流程

1. 创建并部署应用程序作为 Knative 服务。

2. 通过查看以下命令的输出，查找部署服务时创建的第一个修订版本的名称：

   $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

   示例命令

   $ oc get ksvc showcase -o=jsonpath='{.status.latestCreatedRevisionName}'

   输出示例

   $ showcase-00001

3. 在服务 spec 中添加以下 YAML 以将入站流量发送到修订版本：

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 100 # All traffic goes to this revision
   ...

4. 验证您可以在 URL 输出中运行以下命令来查看您的应用程序：

   $ oc get ksvc <service_name>

5. 通过修改服务的 template 规格中至少有一个字段来部署应用程序的第二个修订版本。例如，您可以修改服务的 image 或 env 环境变量。您可以通过应用服务 YAML 文件重新部署服务，如果安装了 Knative (kn) CLI，也可以使用 kn service update 命令。

6. 运行以下命令，查找您在重新部署服务时创建的第二个最新的修订版本的名称：

   $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

   此时，服务的第一个和第二个修订版本都已部署并运行。

7. 更新您的现有服务，以便为第二个修订版本创建新的测试端点，同时仍然将所有其他流量发送到第一个修订版本：

   使用测试端点更新的服务 spec 示例

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 100 # All traffic is still being routed to the first revision
       - revisionName: <second_revision_name>
         percent: 0 # No traffic is routed to the second revision
         tag: v2 # A named route
   ...

   在通过重新应用 YAML 资源重新部署此服务后，应用的第二个修订现已被暂存。没有流量路由到主 URL 的第二个修订版本，Knative 会创建一个名为 v2 的新服务来测试新部署的修订版本。

8. 运行以下命令，获取第二个修订版本的新服务的 URL：

   $ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"

   在将任何流量路由到之前，您可以使用此 URL 验证新版本的应用运行正常。

9. 再次更新您的现有服务，以便 50% 的流量发送到第一个修订版本，50% 发送到第二个修订版本：

   更新的服务 spec 在修订版本间分割流量 50/50 的示例

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 50
       - revisionName: <second_revision_name>
         percent: 50
         tag: v2
   ...

10. 当您准备好将所有流量路由到应用程序的新版本时，请再次更新该服务，将 100% 的流量发送到第二个修订版本：

    更新的服务 spec 将所有流量发送到第二个修订版本的示例

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 0
        - revisionName: <second_revision_name>
          percent: 100
          tag: v2
    ...

    提示

    如果您不计划回滚修订版本，您可以删除第一个修订版本，而不是将其设置为流量的 0%。然后，不可路由的修订版本对象会被垃圾回收。

11. 访问第一个修订版本的 URL，以验证没有更多流量发送到应用程序的旧版本。

流程

1. 创建包含您要传播到 OpenShift Container Platform 路由的标签或注解的 Knative 服务：

   • 使用 YAML 创建服务：

     使用 YAML 创建的服务示例

     apiVersion: serving.knative.dev/v1
     kind: Service
     metadata:
       name: <service_name>
       labels:
         <label_name>: <label_value>
       annotations:
         <annotation_name>: <annotation_value>
     ...

   • 要使用 Knative (kn) CLI 创建服务，请输入：

     使用 kn 命令创建的服务示例

     $ kn service create <service_name> \
       --image=<image> \
       --annotation <annotation_name>=<annotation_value> \
       --label <label_value>=<label_value>

2. 通过检查以下命令的输出来验证 OpenShift Container Platform 路由是否已使用您添加的注解或标签创建：

   验证命令示例

   $ oc get routes.route.openshift.io \
        -l serving.knative.openshift.io/ingressName=<service_name> \ 1
        -l serving.knative.openshift.io/ingressNamespace=<service_namespace> \ 2
        -n knative-serving-ingress -o yaml \
            | grep -e "<label_name>: \"<label_value>\""  -e "<annotation_name>: <annotation_value>" 3

   1

   使用服务的名称。

   2

   使用创建服务的命名空间。

   3

   将您的值用于标签和注解名称和值。

流程

1. 创建包含 service.knative.openshift.io/disableRoute=true 注解的 Knative 服务：

   重要

   service.knative.openshift.io/disableRoute=true 注解指示 OpenShift Serverless 不自动为您创建路由。但是，该服务仍然会显示 URL 并达到 Ready 状态。除非使用与 URL 中主机名相同的主机名创建自己的路由，此 URL 才能在外部工作。

   1. 创建 Knative Service 资源：

      资源示例

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: <service_name>
        annotations:
          serving.knative.openshift.io/disableRoute: "true"
      spec:
        template:
          spec:
            containers:
            - image: <image>
      ...

   2. 应用 Service 资源：

      $ oc apply -f <filename>

   3. 可选。使用 kn service create 命令创建 Knative 服务：

      kn 命令示例

      $ kn service create <service_name> \
        --image=gcr.io/knative-samples/helloworld-go \
        --annotation serving.knative.openshift.io/disableRoute=true

2. 验证没有为服务创建 OpenShift Container Platform 路由：

   示例命令

   $ $ oc get routes.route.openshift.io \
     -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME \
     -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE \
     -n knative-serving-ingress

   您将看到以下输出：

   No resources found in knative-serving-ingress namespace.

3. 在 knative-serving-ingress 命名空间中创建 Route 资源：

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     annotations:
       haproxy.router.openshift.io/timeout: 600s 1
     name: <route_name> 2
     namespace: knative-serving-ingress 3
   spec:
     host: <service_host> 4
     port:
       targetPort: http2
     to:
       kind: Service
       name: kourier
       weight: 100
     tls:
       insecureEdgeTerminationPolicy: Allow
       termination: edge 5
       key: |-
         -----BEGIN PRIVATE KEY-----
         [...]
         -----END PRIVATE KEY-----
       certificate: |-
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE-----
       caCertificate: |-
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE----
     wildcardPolicy: None

   1

   OpenShift Container Platform 路由的超时值。您必须设置与 max-revision-timeout-seconds 设置相同的值（默认为 600s ）。

   2

   OpenShift Container Platform 路由的名称。

   3

   OpenShift Container Platform 路由的命名空间。这必须是 knative-serving-ingress。

   4

   用于外部访问的主机名。您可以将其设置为 <service_name>-<service_namespace>.<domain>。

   5

   您要使用的证书。目前，只支持 边缘（edge） 终止。

4. 应用 Route 资源：

   $ oc apply -f <filename>

流程

1. 在 knative-serving-ingress 命名空间中部署服务器证书：

   $ export san="knative"

   注意

   需要主题备用名称(SAN)验证，以便这些证书能够向 <app_name>.<namespace>.svc.cluster.local 提供请求。

2. 生成 root 密钥和证书：

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

3. 生成使用 SAN 验证的服务器密钥：

   $ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \
     -subj "/CN=Example/O=Example" \
     -addext "subjectAltName = DNS:$san"

4. 创建服务器证书：

   $ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \
     -days 365 -in tls.csr \
     -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt

5. 为 Kourier 本地网关配置 secret：

   1. 从前面的步骤创建的证书，在 knative-serving-ingress 命名空间中部署 secret：

      $ oc create -n knative-serving-ingress secret tls server-certs \
          --key=tls.key \
          --cert=tls.crt --dry-run=client -o yaml | oc apply -f -

   2. 更新 KnativeServing 自定义资源 (CR) spec，以使用 Kourier 网关创建的 secret：

      KnativeServing CR 示例

      ...
      spec:
        config:
          kourier:
            cluster-cert-secret: server-certs
      ...

流程

1. 将 serverless.openshift.io/default-enable-http2=true 注解添加到 KnativeServing 自定义资源中：

   $ oc annotate knativeserving <your_knative_CR> -n knative-serving serverless.openshift.io/default-enable-http2=true

2. 添加注解后，您可以验证 Kourier 服务的 appProtocol 值是否为 h2c ：

   $ oc get svc -n knative-serving-ingress kourier -o jsonpath="{.spec.ports[0].appProtocol}"

   输出示例

   h2c

3. 现在，您可以对外部流量使用 HTTP/2 协议的 gRPC 框架，例如：

   import "google.golang.org/grpc"
   
   grpc.Dial(
      YOUR_URL, 1
      grpc.WithTransportCredentials(insecure.NewCredentials())), 2
   )

   1

   您的 ksvc URL。

   2

   您的证书。

流程

1. 运行以下命令输出集群中服务的信息：

   $ oc get ksvc

   输出示例

   NAME         URL                                                             LATESTCREATED      LATESTREADY        READY   REASON
   hello-dev    https://hello-dev-default.dev.serverless.cluster.example.com    hello-dev-00001    hello-dev-00001    True
   hello-prod   https://hello-prod-default.prod.serverless.cluster.example.com  hello-prod-00001   hello-prod-00001   True

2. 运行以下命令，验证您的服务是否使用正确的路由和所选入口分片：

   $ oc get route -n knative-serving-ingress -o jsonpath='{range .items[*]}{@.metadata.name}{" "}{@.spec.host}{" "}{@.status.ingress[*].routerName}{"\n"}{end}'

   输出示例

   route-19e6628b-77af-4da0-9b4c-1224934b2250-323461616533 hello-prod-default.prod.serverless.cluster.example.com ingress-prod
   route-cb5085d9-b7da-4741-9a56-96c88c6adaaa-373065343266 hello-dev-default.dev.serverless.cluster.example.com ingress-dev

流程

1. 在您的服务中添加 sidecar.istio.io/inject="true" 注解：

   服务示例

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
   ...

   1

   添加 sidecar.istio.io/inject="true" 注解。

   2

   您必须在 Knative 服务中将注解 sidecar.istio.io/rewriteAppHTTPProbers: "true" 设置为 OpenShift Serverless 版本 1.14.0 或更新的版本，然后使用 HTTP 探测作为 Knative 服务的就绪度探测。

2. 应用 Service 资源：

   $ oc apply -f <filename>

3. 在 ServiceMeshMemberRoll 对象的每个无服务器应用程序命名空间中创建一个 RequestAuthentication 资源：

   apiVersion: security.istio.io/v1beta1
   kind: RequestAuthentication
   metadata:
     name: jwt-example
     namespace: <namespace>
   spec:
     jwtRules:
     - issuer: testing@secure.istio.io
       jwksUri: https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json

4. 应用 RequestAuthentication 资源：

   $ oc apply -f <filename>

5. 通过创建以下 AuthorizationPolicy 资源，允许从 ServiceMeshMemberRoll 对象中的每个无服务器应用程序命名空间的系统 pod 访问 RequestAuthenticaton 资源：

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allowlist-by-paths
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - to:
       - operation:
           paths:
           - /metrics 1
           - /healthz 2

   1

   由系统 pod 收集指标的应用程序上的路径。

   2

   系统 pod 探测到应用程序的路径。

6. 应用 AuthorizationPolicy 资源：

   $ oc apply -f <filename>

7. 对于作为 ServiceMeshMemberRoll 对象中成员的每个无服务器应用程序命名空间，请创建以下 AuthorizationPolicy 资源：

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-jwt
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - from:
       - source:
          requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]

8. 应用 AuthorizationPolicy 资源：

   $ oc apply -f <filename>

验证

1. 如果您尝试使用 curl 请求来获取 Knative 服务 URL，则会被拒绝：

   示例命令

   $ curl http://hello-example-1-default.apps.mycluster.example.com/

   输出示例

   RBAC: access denied

2. 使用有效 JWT 验证请求。

   1. 获取有效的 JWT 令牌：

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   2. 使用 curl 请求标头中的有效令牌访问该服务：

      $ curl -H "Authorization: Bearer $TOKEN"  http://hello-example-1-default.apps.example.com

      现在允许请求：

      输出示例

      Hello OpenShift!

流程

1. 在您的服务中添加 sidecar.istio.io/inject="true" 注解：

   服务示例

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
   ...

   1

   添加 sidecar.istio.io/inject="true" 注解。

   2

   您必须在 Knative 服务中将注解 sidecar.istio.io/rewriteAppHTTPProbers: "true" 设置为 OpenShift Serverless 版本 1.14.0 或更新的版本，然后使用 HTTP 探测作为 Knative 服务的就绪度探测。

2. 应用 Service 资源：

   $ oc apply -f <filename>

3. 在作为 ServiceMeshMemberRoll 对象的成员的无服务器应用程序命名空间中创建策略，该策略只允许具有有效 JSON Web Tokens（JWT）的请求：

   重要

   路径 /metrics 和 /healthz 必须包含在 excludePaths 中，因为它们是从 knative-serving 命名空间中的系统 pod 访问的。

   apiVersion: authentication.istio.io/v1alpha1
   kind: Policy
   metadata:
     name: default
     namespace: <namespace>
   spec:
     origins:
     - jwt:
         issuer: testing@secure.istio.io
         jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/jwks.json"
         triggerRules:
         - excludedPaths:
           - prefix: /metrics 1
           - prefix: /healthz 2
     principalBinding: USE_ORIGIN

   1

   由系统 pod 收集指标的应用程序上的路径。

   2

   系统 pod 探测到应用程序的路径。

4. 应用 Policy 资源：

   $ oc apply -f <filename>

验证

1. 如果您尝试使用 curl 请求来获取 Knative 服务 URL，则会被拒绝：

   $ curl http://hello-example-default.apps.mycluster.example.com/

   输出示例

   Origin authentication failed.

2. 使用有效 JWT 验证请求。

   1. 获取有效的 JWT 令牌：

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   2. 使用 curl 请求标头中的有效令牌访问该服务：

      $ curl http://hello-example-default.apps.mycluster.example.com/ -H "Authorization: Bearer $TOKEN"

      现在允许请求：

      输出示例

      Hello OpenShift!

流程

1. 在与您要映射的目标 CR 相同的命名空间中创建一个包含 DomainMapping CR 的 YAML 文件：

   apiVersion: serving.knative.dev/v1beta1
   kind: DomainMapping
   metadata:
    name: <domain_name> 1
    namespace: <namespace> 2
   spec:
    ref:
      name: <target_name> 3
      kind: <target_type> 4
      apiVersion: serving.knative.dev/v1

   1

   要映射到目标 CR 的自定义域名。

   2

   DomainMapping CR 和目标 CR 的命名空间。

   3

   映射到自定义域的目标 CR 名称。

   4

   映射到自定义域的 CR 类型。

   服务域映射示例

   apiVersion: serving.knative.dev/v1beta1
   kind: DomainMapping
   metadata:
    name: example.com
    namespace: default
   spec:
    ref:
      name: showcase
      kind: Service
      apiVersion: serving.knative.dev/v1

   路由域映射示例

   apiVersion: serving.knative.dev/v1beta1
   kind: DomainMapping
   metadata:
    name: example.com
    namespace: default
   spec:
    ref:
      name: example-route
      kind: Route
      apiVersion: serving.knative.dev/v1

2. 将 DomainMapping CR 应用为 YAML 文件：

   $ oc apply -f <filename>

流程

1. 导航到 Topology 页面。
2. 右键单击您要映射到某个域的服务，然后选择包含服务名称的 Edit 选项。例如，如果服务命名为 showcase，请选择 Edit showcase 选项。

3. 在 Advanced options 部分中，点 Show advanced Routing options。

   1. 如果要映射到该服务的域映射 CR 已存在，您可以在域映射列表中选择。
   2. 如果要创建新域映射 CR，在框中输入域名，然后选择 Create 选项。例如，如果您在 example.com 中 键入，则 Create 选项为 Create "example.com"。
4. 单击 Save，将更改保存到您的服务。

验证

1. 导航到 Topology 页面。
2. 单击您创建的服务。
3. 在服务信息窗口的 Resources 选项卡中，您可以看到您映射到域映射中列出的服务的域。

流程

1. 导航到 CustomResourceDefinitions，并使用搜索框查找 DomainMapping 自定义资源定义 (CRD) 。
2. 点 DomainMapping CRD，然后导航到 Instances 选项卡。
3. 单击 Create DomainMapping。

4. 修改 DomainMapping CR 的 YAML，使其为您的实例包含以下信息：

   apiVersion: serving.knative.dev/v1beta1
   kind: DomainMapping
   metadata:
    name: <domain_name> 1
    namespace: <namespace> 2
   spec:
    ref:
      name: <target_name> 3
      kind: <target_type> 4
      apiVersion: serving.knative.dev/v1

   1

   要映射到目标 CR 的自定义域名。

   2

   DomainMapping CR 和目标 CR 的命名空间。

   3

   映射到自定义域的目标 CR 名称。

   4

   映射到自定义域的 CR 类型。

   到 Knative 服务的域映射示例

   apiVersion: serving.knative.dev/v1beta1
   kind: DomainMapping
   metadata:
    name: custom-ksvc-domain.example.com
    namespace: default
   spec:
    ref:
      name: showcase
      kind: Service
      apiVersion: serving.knative.dev/v1

流程

1. 创建 Kubernetes TLS secret：

   $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>

2. 将 networking.internal.knative.dev/certificate-uid: <id>' 标签添加到 Kubernetes TLS secret 中：

   $ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"

   如果使用第三方 secret 供应商（如 cert-manager），您可以配置 secret manager 来自动标记 Kubernetes TLS secret。cert-manager 用户可以使用提供的 secret 模板自动生成带有正确标签的 secret。在本例中，secret 过滤仅基于键，但这个值可以存储有用的信息，如 secret 包含的证书 ID。

   注意

   Red Hat OpenShift 的 cert-manager Operator 只是一个技术预览功能。如需更多信息，请参阅 为 Red Hat OpenShift 安装 cert-manager Operator 文档。

3. 更新 DomainMapping CR，以使用您创建的 TLS secret：

   apiVersion: serving.knative.dev/v1beta1
   kind: DomainMapping
   metadata:
     name: <domain_name>
     namespace: <namespace>
   spec:
     ref:
       name: <service_name>
       kind: Service
       apiVersion: serving.knative.dev/v1
   # TLS block specifies the secret to be used
     tls:
       secretName: <tls_secret_name>

验证

1. 验证 DomainMapping CR 状态是否为 True，输出中的 URL 列显示了使用 scheme https 的映射域：

   $ oc get domainmapping <domain_name>

   输出示例

   NAME                      URL                               READY   REASON
   example.com               https://example.com               True

2. 可选： 如果服务公开，请运行以下命令验证该服务是否可用：

   $ curl https://<domain_name>

   如果证书是自签名的，请通过在 curl 命令中添加 -k 标志来跳过验证。

流程

1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中，进入 OperatorHub → Installed Operators。
2. 选择 knative-serving 命名空间。
3. 点 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Serving 来进入 Knative Serving 选项卡。

4. 点 knative-serving，然后使用 knative-serving 页面中的 YAML 选项卡。

   

5. 修改 KnativeServing CR 中的副本数量：

   YAML 示例

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