Serving

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 已安装 Knative (kn) CLI。
• 您已创建了一个项目，或者具有适当的角色和权限访问项目，以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

• 创建 Knative 服务：

  $ kn service create <service-name> --image <image> --tag <tag-value>

  Copy to Clipboard Toggle word wrap

  其中：

  • --image 是应用的镜像的 URI。

  • --tag 是一个可选标志，可用于向利用服务创建的初始修订版本添加标签。

    示例命令

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

    Copy to Clipboard Toggle word wrap

    输出示例

    Creating service 'showcase' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "showcase" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'showcase' created with latest revision 'showcase-00001' and URL:
    http://showcase-default.apps-crc.testing

    Copy to Clipboard Toggle word wrap

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 您已创建了一个项目，或者具有适当的角色和权限访问项目，以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
• 安装 OpenShift CLI (oc) 。

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 已安装 Knative (kn) CLI。

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 已安装 oc CLI。
• 您已创建了 Knative 服务。

先决条件

• 安装 OpenShift CLI (oc) 。

• 170 Knative Services
• 每个 Knative Service 的 1-2 个修订版本
• 89 测试场景主要侧重于测试 control plane
• 48 重新创建 Knative Services 被删除并重新创建的情况
• 41 稳定场景，在请求速度缓慢但持续发送到系统

流程

• 您可以使用 KnativeServing 自定义资源(CR)为最小工作负载配置 Knative Serving：

  KnativeServing CR 中的最小工作负载配置

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

  1

  
    workloads:
      - name: activator
        replicas: 2 

  2

  
        resources:
          - container: activator
            requests:
              cpu: 250m 

  3

  
              memory: 60Mi 

  4

  
            limits:
              cpu: 1000m
              memory: 600Mi
      - name: controller
        replicas: 1 

  5

  
        resources:
          - container: controller
            requests:
              cpu: 10m
              memory: 100Mi
            limits: 

  6

  
              cpu: 200m
              memory: 300Mi
      - name: webhook
        replicas: 2
        resources:
          - container: webhook
            requests:
              cpu: 100m 

  7

  
              memory: 60Mi
            limits:
              cpu: 200m
              memory: 200Mi
    podDisruptionBudgets: 

  8

  
      - name: activator-pdb
        minAvailable: 1
      - name: webhook-pdb
        minAvailable: 1

  Copy to Clipboard Toggle word wrap

  1

  把它设置为 1 可将所有系统组件扩展到一个副本。

  2

  激活器应始终扩展到至少 2 个实例，以避免停机。

  3

  Activator CPU 请求不应小于 250m，因为 HorizontalPodAutoscaler 将使用此请求作为扩展和缩减的引用。

  4

  将内存请求调整为上表中的空闲值。另外，根据您的预期负载调整内存限值（这可能需要自定义测试来查找最佳值）。

  5

  一个 Webhook 和一个控制器足以满足最小工作负载的情况

  6

  这些限制足以满足最小工作负载的情况，但可能需要根据您的具体工作负载进行调整。

  7

  Webhook CPU 请求不应小于 100m，因为 HorizontalPodAutoscaler 将使用此请求作为扩展和缩减的引用。

  8

  将 PodDistruptionBudgets 调整为小于 replicas 的值，以避免节点维护期间出现问题。

• 所有 data-plane 组件在更高的请求和限值上增加 CPU 使用量，因此必须测试并可能会增加 CPU 请求和限值。
• activator 组件可能需要更多内存，当它需要缓冲更多或较大的请求有效负载时，因此可能需要增加内存请求和限值。
• 一个 activator pod 可以在开始增加延迟前每秒处理大约 2500 个请求，在某些情况下会导致错误。
• 一个 3scale-kourier-gateway 或 istio-ingressgateway pod 也可以在开始增加延迟前每秒处理大约 2500 个请求，在某些情况下会导致错误。
• 每个 data-plane 组件最多消耗 1 个 vCPU 来每秒处理 2500 个请求。请注意，这高度依赖于有效负载大小和 Knative Service 后端的响应时间。

流程

• 要微调安装，请使用之前的发现以及您自己的测试结果来配置 KnativeServing 自定义资源：

  KnativeServing CR 中的高工作负载配置

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

  1

  
    workloads:
      - name: component-name 

  2

  
        replicas: 2 

  3

  
        resources:
          - container: container-name
            requests:
              cpu: 

  4

  
              memory:
            limits:
              cpu:
              memory:
    podDisruptionBudgets: 

  5

  
      - name: name-of-pod-disruption-budget
        minAvailable: 1

  Copy to Clipboard Toggle word wrap

  1

  将此参数设置为至少 2 个，以确保每个组件都至少有两个实例正在运行。您还可以使用 工作负载 覆盖某些组件的副本。

  2

  使用 工作负载 列表配置特定组件。使用组件的部署名称并设置 replicas 字段。

  3

  对于 activator、webhook 和 3scale-kourier-gateway 组件（使用 pod 横向自动扩展(HPAs)），replicas 字段会设置最小副本数。实际的副本数取决于 HPAs 完成的 CPU 负载和扩展。

  4

  至少根据空闲消耗设置请求和限制 CPU 和内存，同时考虑之前的发现和您自己的测试结果。

  5

  将 PodDistruptionBudgets 调整为小于 副本 的值，以避免节点维护期间出现问题。默认 minAvailable 设置为 1，因此如果您增加所需的副本，还必须增加 minAvailable。

• 不设置 min-scale 注解
• 启用扩展到零
• 使用类 KPA

流程

• 可选：在 Service 自定义资源的 spec 中为您的 Knative 服务设置 autoscaling.knative.dev/target 注解：

  服务规格示例

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: showcase
    namespace: default
  spec:
    template:
      metadata:
        annotations:
          autoscaling.knative.dev/target: "200"

  Copy to Clipboard Toggle word wrap

• 可选： 使用 kn service 命令指定 --concurrency-target 标志：

  $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

  Copy to Clipboard Toggle word wrap

  创建服务的示例，并发目标为 50 请求

  $ kn service create showcase --image quay.io/openshift-knative/showcase --concurrency-target 50

  Copy to Clipboard Toggle word wrap

流程

• 可选：在 Service 自定义资源的 spec 中为您的 Knative 服务设置 containerConcurrency spec：

  服务规格示例

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: showcase
    namespace: default
  spec:
    template:
      spec:
        containerConcurrency: 50

  Copy to Clipboard Toggle word wrap

  默认值为 0，这意味着允许同时访问服务的一个副本的请求数量没有限制。

  大于 0 的值指定允许一次传输到服务的一个副本的请求的确切数量。这个示例将启用 50 个请求的硬并发限制。

• 可选： 使用 kn service 命令指定 --concurrency-limit 标志：

  $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

  Copy to Clipboard Toggle word wrap

  创建服务且并发限制为 50 个请求的命令示例

  $ kn service create showcase --image quay.io/openshift-knative/showcase --concurrency-limit 50

  Copy to Clipboard Toggle word wrap

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 在 OpenShift Container Platform 上具有集群管理员权限，或者具有 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 的集群或专用管理员权限。
• 使用默认的 Knative Pod Autoscaler。如果使用 Kubernetes Horizontal Pod Autoscaler，则缩减为零功能将不可用。

流程

• 在 KnativeServing 自定义资源 (CR) 中修改 enable-scale-to-zero spec：

  KnativeServing CR 示例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      autoscaler:
        enable-scale-to-zero: "false" 

  1

  Copy to Clipboard Toggle word wrap

  1

  enable-scale-to-zero spec 可以是 "true" 或 "false"。如果设置为 true，则会启用 scale-to-zero。如果设置为 false，应用程序将缩减至配置的最小扩展绑定。默认值为 "true"。

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 在 OpenShift Container Platform 上具有集群管理员权限，或者具有 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 的集群或专用管理员权限。
• 使用默认的 Knative Pod Autoscaler。如果使用 Kubernetes Horizontal Pod Autoscaler，则缩减为零功能将不可用。

流程

• 在 KnativeServing 自定义资源 (CR) 中修改 scale-to-zero-grace-period spec：

  KnativeServing CR 示例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      autoscaler:
        scale-to-zero-grace-period: "30s" 

  1

  Copy to Clipboard Toggle word wrap

  1

  宽限期（以秒为单位）。默认值为 30 秒。

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 在 OpenShift Container Platform 上具有集群管理员权限，或者具有 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 的集群或专用管理员权限。

流程

• 通过在 KnativeServing CR 中添加 kubernetes.podspec-init-containers 标记来启用 init 容器的使用：

  KnativeServing CR 示例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      features:
        kubernetes.podspec-init-containers: enabled
  ...

  Copy to Clipboard Toggle word wrap

• 服务镜像的大小需要很长时间才能拉取。
• 由于初始缓存 priming，该服务需要很长时间才能变为 READY。
• 集群依赖于自动扩展来为新 pod 分配资源。

流程

• 通过修改部署配置，为您的服务定义启动探测。以下示例显示了有两个容器的配置：

  定义的星号探测示例

  apiVersion: serving.knative.dev/v1
  kind: Service
  # ...
  spec:
    template:
      spec:
         containers:
          - name: first-container
            image: <image>
            ports:
              - containerPort: 8080
            # ...
            startupProbe: 

  1

  
            httpGet:
              port: 8080
              path: "/"
          - name: second-container
            image: <image>
            # ...
            startupProbe: 

  2

  
            httpGet:
              port: 8081
              path: "/"

  Copy to Clipboard Toggle word wrap

  1

  启动 第一容器 的 探测.

  2

  第二容器 启动探测.

• initialDelaySeconds
• failureThreshold
• periodSeconds
• timeoutSeconds

流程

• 要配置 progress deadline 设置，请在部署配置中使用注解。

  进程截止时间设置为 60 秒的示例

  apiVersion: serving.knative.dev/v1
  kind: Service
  ...
  spec:
    template:
      metadata:
         annotations:
              serving.knative.dev/progress-deadline: "60s"
      spec:
          containers:
              - image: ghcr.io/knative/helloworld-go:latest

  Copy to Clipboard Toggle word wrap

流程

• 在 KnativeServing CR 中，使用标签重新路由的 registry 列表修改 registry SkippingTagResolving 设置：

  配置的标签解析跳过示例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      deployment:
        registriesSkippingTagResolving: "registry.example.com, another.registry.com"

  Copy to Clipboard Toggle word wrap

流程

• 在 KnativeServing CR 中，配置 runtime-class-name 设置：

  配置的 runtime-class-name 设置示例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      deployment:
        runtime-class-name: |
          kata: {}
          gvisor:
            selector:
              my-label: selector

  Copy to Clipboard Toggle word wrap

• 服务镜像的大小需要很长时间才能拉取。
• 由于初始缓存 priming，该服务需要很长时间才能变为 READY。
• 集群依赖于自动扩展来为新 pod 分配资源。

流程

• 要获取当前的 Envoy bootstrap 配置，请运行以下命令：

  示例命令

  $ oc get cm kourier-bootstrap -n knative-serving-ingress -o yaml

  Copy to Clipboard Toggle word wrap

  例如，在默认配置中，example 命令会生成包含以下摘录的输出：

  输出示例

  Name:         kourier-bootstrap
  Namespace:    knative-serving-ingress
  Labels:       app.kubernetes.io/component=net-kourier
                app.kubernetes.io/name=knative-serving
                app.kubernetes.io/version=release-v1.10
                networking.knative.dev/ingress-provider=kourier
                serving.knative.openshift.io/ownerName=knative-serving
                serving.knative.openshift.io/ownerNamespace=knative-serving
  Annotations:  manifestival: new

  Copy to Clipboard Toggle word wrap

  数据 输出示例

  dynamic_resources:
    ads_config:
      transport_api_version: V3
      api_type: GRPC
      rate_limit_settings: {}
      grpc_services:
      - envoy_grpc: {cluster_name: xds_cluster}
    cds_config:
      resource_api_version: V3
      ads: {}
    lds_config:
      resource_api_version: V3
      ads: {}
  node:
    cluster: kourier-knative
    id: 3scale-kourier-gateway
  static_resources:
    listeners:
      - name: stats_listener
        address:
          socket_address:
            address: 0.0.0.0
            port_value: 9000
        filter_chains:
          - filters:
              - name: envoy.filters.network.http_connection_manager
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                  stat_prefix: stats_server
                  http_filters:
                    - name: envoy.filters.http.router
                      typed_config:
                        "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
                  route_config:
                    virtual_hosts:
                      - name: admin_interface
                        domains:
                          - "*"
                        routes:
                          - match:
                              safe_regex:
                                regex: '/(certs|stats(/prometheus)?|server_info|clusters|listeners|ready)?'
                              headers:
                                - name: ':method'
                                  string_match:
                                    exact: GET
                            route:
                              cluster: service_stats
    clusters:
      - name: service_stats
        connect_timeout: 0.250s
        type: static
        load_assignment:
          cluster_name: service_stats
          endpoints:
            lb_endpoints:
              endpoint:
                address:
                  pipe:
                    path: /tmp/envoy.admin
      - name: xds_cluster
        # This keepalive is recommended by envoy docs.
        # https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
        typed_extension_protocol_options:
          envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
            "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
            explicit_http_config:
              http2_protocol_options:
                connection_keepalive:
                  interval: 30s
                  timeout: 5s
        connect_timeout: 1s
        load_assignment:
          cluster_name: xds_cluster
          endpoints:
            lb_endpoints:
              endpoint:
                address:
                  socket_address:
                    address: "net-kourier-controller.knative-serving-ingress.svc.cluster.local."
                    port_value: 18000
        type: STRICT_DNS
  admin:
    access_log:
    - name: envoy.access_loggers.stdout
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
    address:
      pipe:
        path: /tmp/envoy.admin
  layered_runtime:
    layers:
      - name: static-layer
        static_layer:
          envoy.reloadable_features.override_request_timeout_by_gateway_timeout: false

  Copy to Clipboard Toggle word wrap

  BinaryData 输出示例

  Events:  <none>

  Copy to Clipboard Toggle word wrap

先决条件

• 安装了 OpenShift Serverless Operator 和 Knative Serving。
• 在 OpenShift Container Platform 上具有集群管理员权限，或者具有 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 的集群或专用管理员权限。

流程

• 通过更改 KnativeServing 自定义资源(CR)中的 spec.ingress.kourier.bootstrap-configmap 字段来指定自定义 bootstrap 配置映射：

  KnativeServing CR 示例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    config:
      network:
        ingress-class: kourier.ingress.networking.knative.dev
    ingress:
      kourier:
        bootstrap-configmap: my-configmap
        enabled: true
  # ...

  Copy to Clipboard Toggle word wrap

先决条件

• 安装了 OpenShift Serverless Operator 和 Knative Serving。
• 在 OpenShift Container Platform 上具有集群管理员权限，或者具有 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 的集群或专用管理员权限。

先决条件

• 安装 OpenShift CLI (oc) 。
• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。

先决条件

• 安装了 OpenShift Serverless Operator 和 Knative Serving。
• 在 OpenShift Container Platform 上，或具有 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 的集群管理员权限。

流程

• 选择配置修订超时的适当方法：

  • 要在全局范围内配置修订超时，请在 KnativeServing 自定义资源(CR)中设置 revision-timeout-seconds 字段：

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      config:
        defaults:
          revision-timeout-seconds: "300"

    Copy to Clipboard Toggle word wrap

  • 通过在服务定义中设置 timeoutSeconds 字段来配置每个修订版本的超时：

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      namespace: my-ns
    spec:
      template:
        spec:
          timeoutSeconds: 300
          containers:
          - image: ghcr.io/knative/helloworld-go:latest

    Copy to Clipboard Toggle word wrap

先决条件

• 安装了 OpenShift Serverless Operator 和 Knative Serving。
• 在 OpenShift Container Platform 上，或具有 Red Hat OpenShift Service on AWS 或 OpenShift Dedicated 的集群管理员权限。

流程

• 要配置最大修订超时，请在 KnativeServing 自定义资源(CR)中设置 max-revision-timeout-seconds 字段：

  If this value is increased, the activator `terminationGracePeriodSeconds` should also be increased to prevent in-flight requests being disrupted.

  Copy to Clipboard Toggle word wrap

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    config:
      defaults:
        max-revision-timeout-seconds: "600"

  Copy to Clipboard Toggle word wrap

• 它基于 envoy 代理。
• 它简单且轻量级。
• 它提供 Serverless 必须提供其一组功能的基本路由功能。
• 它支持基本可观察性和指标。
• 它支持 Knative Service 路由的基本 TLS 终止。
• 它只提供有限的配置和扩展选项。

• 所有连接之间的原生 mTLS
• Serverless 组件是服务网格的一部分
• 额外的可观察性和指标
• 授权和身份验证支持
• Red Hat OpenShift Service Mesh 支持的自定义规则和配置

• 由 OpenShift 路由器转发 的集群外部路由，如 myapp-namespace.example.com。
• 包含集群域的 cluster-local 路由，如 myapp.namespace.svc.cluster.local。这个域可用于从 Knative 或其他用户工作负载调用 Knative 服务。

• 在 serving 模式中，请求直接进入 Knative 服务的 Queue-Proxy sidecar 容器。
• 在代理模式中，请求首先通过 knative-serving 命名空间中的 Activator 组件。

• 证书通用名称(CN)或主题备用名称(SAN)包含 Knative Service 的 cluster-local 域，如 myapp.namespace.svc.cluster.local,myapp.namespace.svc,myapp.namespace.
• ingress-controller 组件的 cluster-local 端点使用 SNI 来选择证书。
• 要创建证书，Knative 依赖于 cert-manager，它需要安装和配置该功能才能正常工作。如需更多信息，请参阅 Red Hat OpenShift 的 cert-manager Operator。

• 要使 OpenShift Serverless 获取证书，必须安装并配置 cert-manager。
• 特定的 SAN 用于验证每个连接。每个组件都必须信任签发证书的 CA。为了满足此要求，OpenShift Serverless 系统组件会消耗并信任 CA 捆绑包。CA 捆绑包必须由集群管理员提供。

• 对于 cluster-local 加密，签发者必须能够为以下 cluster-local 域类型签名证书：

  • myapp.<namespace>
  • myapp.<namespace>.svc
  • myapp.<namespace>.svc.cluster.local

  由于 CA 通常不在集群中，因此无法使用自动证书管理环境(ACME)协议(DNS01/HTTP01)进行验证。您可以使用允许创建这些证书的签发者，如 cert-manager CA 签发者。

• 对于系统内部加密，签发者必须能够使用以下主题备用名称(SAN)签署证书：

  • kn-routing
  • 格式 kn-user-<namespace> 格式的名称，其中 &lt;namespace> 是创建 Knative 服务的命名空间
  • data-plane.knative.dev

  Knative 要求这些 SAN 验证内部组件之间的连接。由于无法使用 ACME 协议(DNS01/HTTP01)，所以您必须配置允许创建这些证书的签发者，如 cert-manager CA issuer。

• 将 CA 捆绑包添加到构建时的容器镜像。请注意，这会使 CA 轮转复杂，因为您必须在 CA 轮转时重建并重新部署每个应用程序。
• 将 CA 捆绑包挂载到文件系统，如 Secret 或 ConfigMap，并确保您的应用程序使用它来验证 TLS 连接。
• 从环境变量读取 CA 捆绑包，并确保您的应用程序使用它来验证 TLS 连接。
• 使用 Kubernetes API 从 secret 或 ConfigMap 访问 CA 捆绑包，并确保应用程序使用它来验证 TLS 连接。