Serving

流程

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

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-delivery
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"

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

   $ oc apply -f <filename>

流程

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

流程

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

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \
       --target ./ \
       --namespace test

   输出示例

   Service 'event-display' 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
           └── event-display.yaml
   
   2 directories, 1 file

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

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

   $ cat test/ksvc/event-display.yaml

   输出示例

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

4. 列出新服务的信息：

   $ kn service describe event-display --target ./ --namespace test

   输出示例

   Name:       event-display
   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/event-display.yaml

   输出示例

   Creating service 'event-display' in namespace 'test':
   
     0.058s The Route is still working to reflect the latest desired specification.
     0.098s ...
     0.168s Configuration "event-display" 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 'event-display' created to latest revision 'event-display-00001' is available at URL:
   http://event-display-test.apps.example.com

流程

1. 查找应用程序 URL:

   $ oc get ksvc <service_name>

   输出示例

   NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
   event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

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

   HTTP 请求示例

   $ curl http://event-delivery-default.example.com

   HTTPS 请求示例

   $ curl https://event-delivery-default.example.com

   输出示例

   Hello Serverless!

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

   $ curl https://event-delivery-default.example.com --insecure

   输出示例

   Hello Serverless!

   重要

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

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

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

   输出示例

   Hello Serverless!

流程

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 配置。例如，您可能具有以下配置的持久性卷声明：

   注意

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

   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. 在 spec 中创建一个包含 internal-encryption: "true" 字段的 Knative 服务：

   ...
   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 列表。

   图 4.1. 无服务器应用程序

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

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

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

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

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

      

流程

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

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

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

   示例命令

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

   输出示例

   $ example-service-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. 找到应用程序主机。请参阅验证无服务器应用程序部署中的相关内容。

2. 查找 ingress 网关的公共地址：

   $ oc -n knative-serving-ingress get svc kourier

   输出示例

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
   kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

   公共地址位于 EXTERNAL-IP 字段，在本例中是 a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com。

3. 手动在 HTTP 请求的主机标头中设置应用程序的主机，但将请求定向到 ingress 网关的公共地址。

   $ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com

   输出示例

   Hello Serverless!

   您还可以对入口网关发出直接 gRPC 请求：

   import "google.golang.org/grpc"
   
   grpc.Dial(
       "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
       grpc.WithAuthority("hello-default.example.com:80"),
       grpc.WithInsecure(),
   )

   注意

   如上例所示，请确保将对应的端口（默认为 80）附加到两个主机中。

流程

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/v1alpha1
   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/v1alpha1
   kind: DomainMapping
   metadata:
    name: example.com
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

   路由域映射示例

   apiVersion: serving.knative.dev/v1alpha1
   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 选项。例如，如果该服务命名为 example-service，请选择 Edit example-service 选项。

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/v1alpha1
   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/v1alpha1
   kind: DomainMapping
   metadata:
    name: custom-ksvc-domain.example.com
    namespace: default
   spec:
    ref:
      name: example-service
      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/v1alpha1
   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