Serverless

• OpenShift Serverless 现在使用 Knative Serving 1.3。
• OpenShift Serverless 现在使用 Knative Eventing 1.3。
• OpenShift Serverless 现在使用 Kourier 1.3。
• OpenShift Serverless 现在使用 Knative kn CLI 1.3。
• OpenShift Serverless 现在使用 Knative Kafka 1.3。
• kn func CLI 插件现在使用 func 0.24。
• 现在，提供了对 Knative 服务的 init 容器支持(GA)。
• OpenShift Serverless 逻辑现在作为技术预览提供。它启用了定义声明工作流模型来管理无服务器应用程序。
• 现在，您可以在 OpenShift Serverless 中使用成本管理服务。

• 当集群中存在太多 secret 时，将 OpenShift Serverless 与 Red Hat OpenShift Service Mesh 集成会导致 net-istio-controller pod 在启动时耗尽内存。

  现在，可以启用 secret 过滤，这会导致 net-istio-controller 只考虑带有 networking.internal.knative.dev/certificate-uid 标签的 secret，从而减少所需的内存量。

• OpenShift Serverless 功能技术预览现在默认使用 Cloud Native Buildpacks 构建容器镜像。

• Kafka 代理、Kafka 源和 Kafka sink 禁用 Federal Information Processing Standards(FIPS)模式。

• 在 OpenShift Serverless 1.23 中，删除了 KafkaBindings 和 kafka-binding Webhook 的支持。但是，现有 kafkabindings.webhook.sources.knative.dev MutatingWebhookConfiguration 可能保留，指向 kafka-source-webhook 服务，该服务不再存在。

  对于集群上 KafkaBindings 的某些规格，kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration 可能会被配置，将任何创建和更新事件传递给各种资源，如 Deployment、Knative Services 或 Jobs，然后 Webhook 会失败。

  要临时解决这个问题，请在升级到 OpenShift Serverless 1.23 后从集群中删除 kafkabindings.webhook.sources.knative.dev MutatingWebhookConfiguration：

  $ oc delete mutatingwebhookconfiguration kafkabindings.webhook.kafka.sources.knative.dev

  Copy to Clipboard Toggle word wrap

• OpenShift Serverless 现在使用 Knative Serving 1.2。
• OpenShift Serverless 现在使用 Knative Eventing 1.2。
• OpenShift Serverless 现在使用 Kourier 1.2。
• OpenShift Serverless 现在使用 Knative(kn)CLI 1.2。
• OpenShift Serverless 现在使用 Knative Kafka 1.2。
• kn func CLI 插件现在使用 func 0.24。
• 现在，可以在 Kafka 代理中使用 kafka.eventing.knative.dev/external.topic 注解。此注解可以使用现有的外部管理主题，而不是代理自行创建内部主题。
• kafka-ch-controller 和 kafka-webhook Kafka 组件不再存在。这些组件已被 kafka-webhook-eventing 组件替代。
• OpenShift Serverless 功能技术预览现在默认使用 Source-to-Image(S2I)来构建容器镜像。

• Kafka 代理、Kafka 源和 Kafka sink 禁用 Federal Information Processing Standards(FIPS)模式。
• 如果您删除了包含 Kafka 代理的命名空间，如果在代理被删除前删除了代理的 auth.secret.ref.name secret，命名空间终结器可能无法删除。

• 使用大量 Knative 服务运行 OpenShift Serverless 时，可能会导致运行的 Knativeivator pod 接近其默认的内存限值 600MB。如果使用的内存达到这个限值，则这些 pod 可能会重启。通过修改 KnativeServing 自定义资源，可以配置激活器部署的请求和限值：

  apiVersion: operator.knative.dev/v1alpha1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    deployments:
    - name: activator
      resources:
      - container: activator
        requests:
          cpu: 300m
          memory: 60Mi
        limits:
          cpu: 1000m
          memory: 1000Mi

  Copy to Clipboard Toggle word wrap
• 如果您使用 Cloud Native Buildpacks 作为功能的本地构建策略，kn func 将无法自动启动 podman，或使用 SSH 隧道到远程守护进程。这些问题的解决方法是，在部署功能前，在本地开发计算机上已在运行 Docker 或 podman 守护进程。
• On-cluster 功能构建当前针对 Quarkus 和 Golang 运行时会失败。它们适用于 Node、Typescript、Python 和 Springboot 运行时。

• OpenShift Serverless 现在使用 Knative Serving 1.1。
• OpenShift Serverless 现在使用 Knative Eventing 1.1。
• OpenShift Serverless 现在使用 Kourier 1.1。
• OpenShift Serverless 现在使用 Knative(kn)CLI 1.1。
• OpenShift Serverless 现在使用 Knative Kafka 1.1。
• kn func CLI 插件现在使用 func 0.23。
• init 容器支持 Knative 服务现在作为技术预览提供。
• 持久性卷声明(PVC)对 Knative 服务的支持现在作为技术预览提供。
• knative-serving、knative-serving-ingress、knative-eventing 和 knative-kafka 系统命名空间现在默认具有 knative.openshift.io/part-of: "openshift-serverless" 标签。
• 添加了 Knative Eventing - Kafka Broker/Trigger 仪表板，它允许在 web 控制台中视觉化 Kafka 代理并触发指标。
• 添加了 Knative Eventing - KafkaSink 仪表板，它允许在 web 控制台中视觉化 KafkaSink 指标。
• Knative Eventing - Broker/Trigger 仪表板现在被称为 Knative Eventing - 基于频道的代理/Trigger。
• knative.openshift.io/part-of: "openshift-serverless" 标签已替换 knative.openshift.io/system-namespace 标签。
• Knative Serving YAML 配置文件中的命名样式从 camel 问题单（ExampleName）改为连字符格式(example-name)。从这个版本开始，在创建或编辑 Knative Serving YAML 配置文件时使用连字符格式表示法。

• Kafka 代理、Kafka 源和 Kafka sink 禁用 Federal Information Processing Standards(FIPS)模式。

• OpenShift Serverless 现在使用 Knative Serving 1.0
• OpenShift Serverless 现在使用 Knative Eventing 1.0。
• OpenShift Serverless 现在使用 Kourier 1.0.
• OpenShift Serverless 现在使用 Knative(kn)CLI 1.0。
• OpenShift Serverless 现在使用 Knative Kafka 1.0。
• kn func CLI 插件现在使用 func 0.21。
• Kafka sink 现在作为技术预览提供。
• Knative 开源项目已开始弃用发现配置密钥，而是统一使用 kebab-cased 键。因此，OpenShift Serverless 1.18.0 发行注记中提到的 defaultExternalScheme 键现已弃用，并被 default-external-scheme 键替代。密钥的使用说明保持不变。

• 在 OpenShift Serverless 1.20.0 中，存在一个与发送事件相关的问题，会影响使用 kn event send 向服务发送事件。这个问题现已解决。
• 在 OpenShift Serverless 1.20.0(func 0.20)中，使用 http 模板创建的 TypeScript 功能无法在集群中部署。这个问题现已解决。
• 在 OpenShift Serverless 1.20.0(func 0.20)中，使用 gcr.io registry 部署功能会失败，并出现错误。这个问题现已解决。
• 在 OpenShift Serverless 1.20.0(func 0.20)中，使用 kn func create 命令创建 Springboot 功能项目目录，然后运行 kn func build 命令失败并显示错误消息。这个问题现已解决。
• 在 OpenShift Serverless 1.19.0(func 0.19)中，一些运行时无法使用 podman 来构建功能。这个问题现已解决。

• 目前，域映射控制器无法处理包含当前不支持的路径的代理 URI。

  这意味着，如果要使用 DomainMapping 自定义资源(CR)将自定义域映射到代理，则必须使用代理的 ingress 服务配置 DomainMapping CR，并将代理的确切路径附加到自定义域：

  DomainMapping CR 示例

  apiVersion: serving.knative.dev/v1alpha1
  kind: DomainMapping
  metadata:
    name: <domain-name>
    namespace: knative-eventing
  spec:
    ref:
      name: broker-ingress
      kind: Service
      apiVersion: v1

  Copy to Clipboard Toggle word wrap

  代理的 URI 为 <domain-name>/<broker-namespace>/<broker-name>。

• OpenShift Serverless 现在使用 Knative Serving 0.26。
• OpenShift Serverless 现在使用 Knative Eventing 0.26。
• OpenShift Serverless 现在使用 Kourier 0.26。
• OpenShift Serverless 现在使用 Knative(kn)CLI 0.26。
• OpenShift Serverless 现在使用 Knative Kafka 0.26。
• kn func CLI 插件现在使用 func 0.20。

• Kafka 代理现在作为技术预览提供。

  重要

  FIPS 不支持 Kafka 代理（当前为技术预览）。

• kn event 插件现在作为技术预览提供。
• kn service create 命令的 --min-scale 和 --max-scale 标志已弃用。使用 --scale-min 和 --scale-max 标志。

• OpenShift Serverless 使用 HTTPS 的默认地址部署 Knative 服务。将事件发送到集群中的资源时，发件人不会配置集群证书颁发机构(CA)。这会导致事件交付失败，除非集群使用全局接受的证书。

  例如，向公开访问的地址发送事件可正常工作：

  $ kn event send --to-url https://ce-api.foo.example.com/

  Copy to Clipboard Toggle word wrap

  另一方面，如果服务使用由自定义 CA 发布的 HTTPS 证书的公共地址，则此交付会失败：

  $ kn event send --to Service:serving.knative.dev/v1:event-display

  Copy to Clipboard Toggle word wrap

  将事件发送到其他可寻址的对象（如代理或频道）不受此问题的影响，并可以正常工作。

• Kafka 代理目前无法在启用了联邦信息处理标准(FIPS)模式的集群中工作。

• 如果您使用 kn func create 命令创建 Springboot 功能项目目录，后续的 kn func build 命令运行会失败并显示以下错误消息：

  [analyzer] no stack metadata found at path ''
  [analyzer] ERROR: failed to : set API for buildpack 'paketo-buildpacks/ca-certificates@3.0.2': buildpack API version '0.7' is incompatible with the lifecycle

  Copy to Clipboard Toggle word wrap

  作为临时解决方案，您可以在功能配置文件 func.yaml 中将 builder 属性更改为 gcr.io/paketo-buildpacks/builder:base。

• 使用 gcr.io registry 部署功能会失败并显示以下错误消息：

  Error: failed to get credentials: failed to verify credentials: status code: 404

  Copy to Clipboard Toggle word wrap

  作为临时解决方案，请使用与 gcr.io 不同的 registry，如 quay.io 或 docker.io。

• 使用 http 模板创建的 TypeScript 功能无法在集群中部署。

  作为临时解决方案，在 func.yaml 文件中替换以下部分：

  buildEnvs: []

  Copy to Clipboard Toggle word wrap

  使用这个：

  buildEnvs:
  - name: BP_NODE_RUN_SCRIPTS
    value: build

  Copy to Clipboard Toggle word wrap

• 在 func 版本 0.20 中，一些运行时可能无法使用 podman 构建功能。您可能会看到类似如下的错误消息：

  ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF

  Copy to Clipboard Toggle word wrap

  • 这个问题存在以下临时解决方案：

    1. 通过在 service ExecStart 定义中添加 --time=0 来更新 podman 服务：

       服务配置示例

       ExecStart=/usr/bin/podman $LOGGING system service --time=0

       Copy to Clipboard Toggle word wrap

    2. 运行以下命令来重启 podman 服务：

       $ systemctl --user daemon-reload

       Copy to Clipboard Toggle word wrap

       $ systemctl restart --user podman.socket

       Copy to Clipboard Toggle word wrap

  • 或者，您可以使用 TCP 公开 podman API：

    $ podman system service --time=0 tcp:127.0.0.1:5534 &
    export DOCKER_HOST=tcp://127.0.0.1:5534

    Copy to Clipboard Toggle word wrap

• OpenShift Serverless 现在使用 Knative Serving 0.25。
• OpenShift Serverless 现在使用 Knative Eventing 0.25。
• OpenShift Serverless 现在使用 Kourier 0.25。
• OpenShift Serverless 现在使用 Knative(kn)CLI 0.25。
• OpenShift Serverless 现在使用 Knative Kafka 0.25。
• kn func CLI 插件现在使用 purc 0.19。
• KafkaBinding API 在 OpenShift Serverless 1.19.0 中已弃用，并将在以后的发行版本中删除。
• HTTPS 重定向现在被支持，并可以为集群或每个 Knative 服务配置。

• 在以前的版本中，Kafka 频道分配程序仅在响应前等待本地提交成功，这可能会在 Apache Kafka 节点失败时导致事件丢失。Kafka 频道分配程序现在会在响应前等待所有同步副本提交。

• 在 func 版本 0.19 中，一些运行时可能无法使用 podman 构建功能。您可能会看到类似如下的错误消息：

  ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF

  Copy to Clipboard Toggle word wrap

  • 这个问题存在以下临时解决方案：

    1. 通过在 service ExecStart 定义中添加 --time=0 来更新 podman 服务：

       服务配置示例

       ExecStart=/usr/bin/podman $LOGGING system service --time=0

       Copy to Clipboard Toggle word wrap

    2. 运行以下命令来重启 podman 服务：

       $ systemctl --user daemon-reload

       Copy to Clipboard Toggle word wrap

       $ systemctl restart --user podman.socket

       Copy to Clipboard Toggle word wrap

  • 或者，您可以使用 TCP 公开 podman API：

    $ podman system service --time=0 tcp:127.0.0.1:5534 &
    export DOCKER_HOST=tcp://127.0.0.1:5534

    Copy to Clipboard Toggle word wrap

• OpenShift Serverless 现在使用 Knative Serving 0.24.0。
• OpenShift Serverless 现在使用 Knative Eventing 0.24.0。
• OpenShift Serverless 现在使用 Kourier 0.24.0。
• OpenShift Serverless 现在使用 Knative(kn)CLI 0.24.0。
• OpenShift Serverless 现在使用 Knative Kafka 0.24.7。
• kn func CLI 插件现在使用 func 0.18.0。

• 在即将到来的 OpenShift Serverless 1.19.0 发行版本中，外部路由的 URL 方案将默认为 HTTPS 以增强安全性。

  如果您不希望此更改应用到工作负载，您可以在升级到 1.19.0 前覆盖默认设置，方法是将以下 YAML 添加到 KnativeServing 自定义资源(CR)：

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "http"
  ...

  Copy to Clipboard Toggle word wrap

  如果您想在 1.18.0 中应用更改，请添加以下 YAML：

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "https"
  ...

  Copy to Clipboard Toggle word wrap

• 在接下来的 OpenShift Serverless 1.19.0 发行版本中，公开 Kourier 网关的默认服务类型将是 ClusterIP，而不是 LoadBalancer。

  如果您不希望此更改应用到工作负载，您可以在升级到 1.19.0 前覆盖默认设置，方法是将以下 YAML 添加到 KnativeServing 自定义资源(CR)：

  ...
  spec:
    ingress:
      kourier:
        service-type: LoadBalancer
  ...

  Copy to Clipboard Toggle word wrap
• 现在，您可以在 OpenShift Serverless 中使用 emptyDir 卷。详情请参阅 OpenShift Serverless 文档中的 Knative Serving 文档。
• 现在，当您使用 kn func 创建功能时，Rust 模板可用。

• 1.4 之前的 Camel-K 版本与 OpenShift Serverless 1.17.0 不兼容。Camel-K 中的问题已被解决，Camel-K 版本 1.4.1 可以用于 OpenShift Serverless 1.17.0。

• 在以前的版本中，如果您为 Kafka 频道或新 Kafka 源创建新订阅，则 Kafka 数据平面可能会在新创建的订阅或 sink 报告就绪状态后准备好发送信息。

  因此，数据平面没有报告就绪状态时发送的信息可能没有传送到订阅者或 sink。

  在 OpenShift Serverless 1.18.0 中，这个问题已被解决，初始消息不再丢失。有关此问题的更多信息，请参阅 知识库文章 #6343981。

• 较旧版本的 Knative kn CLI 可能会使用较旧版本的 Knative Serving 和 Knative Eventing API。例如，kn CLI 版本 0.23.2 使用 v1alpha1 API 版本。

  另一方面，较新的 OpenShift Serverless 发行版本可能不再支持旧的 API 版本。例如，OpenShift Serverless 1.18.0 不再支持 kafkasources.sources.knative.dev API 的版本 v1alpha1。

  因此，使用带有较新的 OpenShift Serverless 的 Knative kn CLI 的旧版本可能会产生错误，因为 kn 无法找到过时的 API。例如，kn CLI 的 0.23.2 版本无法用于 OpenShift Serverless 1.18.0。

  为避免出现问题，请使用适用于 OpenShift Serverless 发行版本的最新 kn CLI 版本。对于 OpenShift Serverless 1.18.0，使用 Knative kn CLI 0.24.0。

• OpenShift Serverless 现在使用 Knative Serving 0.23.0。
• OpenShift Serverless 现在使用 Knative Eventing 0.23.0。
• OpenShift Serverless 现在使用 Kourier 0.23.0。
• OpenShift Serverless 现在使用 Knative kn CLI 0.23.0。
• OpenShift Serverless 现在使用 Knative Kafka 0.23.0。
• kn func CLI 插件现在使用 func 0.17.0.

• 在即将到来的 OpenShift Serverless 1.19.0 发行版本中，外部路由的 URL 方案将默认为 HTTPS 以增强安全性。

  如果您不希望此更改应用到工作负载，您可以在升级到 1.19.0 前覆盖默认设置，方法是将以下 YAML 添加到 KnativeServing 自定义资源(CR)：

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "http"
  ...

  Copy to Clipboard Toggle word wrap
• mTLS 功能现在正式发布 (GA)。
• 现在，在使用 kn func 创建函数时，typeScript 模板可用。

• Knative Eventing 0.23.0 中的 API 版本更改：

  • KafkaChannel API 的 v1alpha1 版本已在 OpenShift Serverless 版本 1.14.0 中弃用，它已被删除。如果配置映射的 ChannelTemplateSpec 参数包含对此旧版本的引用，您必须更新 spec 的这一部分以使用正确的 API 版本。

• 如果您试图将较旧版本的 Knative kn CLI 与较新的 OpenShift Serverless 发行版本搭配使用，则不会找到 API，并出现错误。

  例如，如果您使用 kn CLI 的 1.16.0 发行版本，它使用版本 0.22.0，其 1.17.0 OpenShift Serverless 发行版本使用 Knative Serving 和 Knative Eventing API 的 0.23.0 版本，则 CLI 无法正常工作，因为它仍然会查找过时的 0.22.0 API 版本。

  确保您使用 OpenShift Serverless 发行版本的最新 kn CLI 版本来避免问题。

• 此发行版本中的相应 web 控制台仪表板中不会监控或显示 Kafka 频道指标。这是因为 Kafka 分配程序协调过程中的中断更改。

• 如果您为 Kafka 频道或新 Kafka 源创建新订阅，在新创建的订阅或 sink 报告就绪状态后 Kafka 数据平面可能会延迟分配信息。

  因此，在 data plane 没有报告就绪状态时发送的信息可能无法传送到订阅者或 sink。

  有关此问题和可能的解决方案的更多信息，请参阅知识库文章 #6343981。

• Camel-K 1.4 发行版本与 OpenShift Serverless 版本 1.17.0 不兼容。这是因为 Camel-K 1.4 使用 Knative 版本 0.23.0 中删除的 API。目前，这个问题还没有可用的临时解决方案。如果您需要在 OpenShift Serverless 中使用 Camel-K 1.4，请不要升级到 OpenShift Serverless 版本 1.17.0。

  注意

  这个问题已被解决，Camel-K 版本 1.4.1 与 OpenShift Serverless 1.17.0 兼容。

• OpenShift Serverless 现在使用 Knative Serving 0.22.0。
• OpenShift Serverless 现在使用 Knative Eventing 0.22.0。
• OpenShift Serverless 现在使用 Kourier 0.22.0。
• OpenShift Serverless 现在使用 Knative kn CLI 0.22.0。
• OpenShift Serverless 现在使用 Knative Kafka 0.22.0。
• kn func CLI 插件现在使用 func 0.16.0。
• kn func emit 命令已添加到功能 kn 插件中。您可以使用此命令发送事件来测试本地部署的功能。

• 在升级到 OpenShift Serverless 1.16.0 前，您必须将 OpenShift Container Platform 升级到 4.6.30、4.7.11 或更高版本。

• AMQ Streams Operator 可能会阻止安装或升级 OpenShift Serverless Operator。如果发生这种情况，Operator Lifecycle Manager (OLM) 会抛出以下错误：

  WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.

  Copy to Clipboard Toggle word wrap

  您可以在安装或升级 OpenShift Serverless Operator 前卸载 AMQ Streams Operator，从而解决这个问题。然后您可以重新安装 AMQ Streams Operator。

• 如果使用 mTLS 启用 Service Mesh，则 Knative Serving 的指标会被默认禁用，因为 Service Mesh 会防止 Prometheus 提取指标。有关启用 Knative Serving 指标以用于 Service Mesh 和 mTLS 的说明，请参阅 Serverless 文档中的"集成 Service Mesh with OpenShift Serverless"部分。

• 如果您部署启用了 Istio ingress 的 Service Mesh CR，您可能会在 istio-ingressgateway pod 中看到以下警告：

  2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 found

  Copy to Clipboard Toggle word wrap

  您的 Knative 服务也可能无法访问。

  您可以按照以下的临时解决方案，通过重新创建 knative-local-gateway 服务来解决这个问题：

  1. 删除 istio-system 命名空间中现有的 knative-local-gateway 服务：

     $ oc delete services -n istio-system knative-local-gateway

     Copy to Clipboard Toggle word wrap

  2. 创建并应用包含以下 YAML 的 knative-local-gateway 服务：

     apiVersion: v1
     kind: Service
     metadata:
      name: knative-local-gateway
      namespace: istio-system
      labels:
        experimental.istio.io/disable-gateway-port-translation: "true"
     spec:
      type: ClusterIP
      selector:
        istio: ingressgateway
      ports:
        - name: http2
          port: 80
          targetPort: 8081

     Copy to Clipboard Toggle word wrap

• 如果您在集群中有 1000 个 Knative 服务，然后执行 Knative Serving 的重新安装或升级，则在 KnativeServing 自定义资源(CR)变为 Ready 后创建第一个新服务会有一个延迟。

  3scale-kourier-control 服务会在创建新服务前协调所有以前存在的 Knative 服务。因此，新服务在状态被更新为 Ready 前，大约会有 800 秒的时间处于 IngressNotConfigured 或 Unknown 状态。

• 如果您为 Kafka 频道或新 Kafka 源创建新订阅，在新创建的订阅或 sink 报告就绪状态后 Kafka 数据平面可能会延迟分配信息。

  因此，在 data plane 没有报告就绪状态时发送的信息可能无法传送到订阅者或 sink。

  有关此问题和可能的解决方案的更多信息，请参阅知识库文章 #6343981。

• OpenShift Serverless 现在使用 Knative Serving 0.21.0。
• OpenShift Serverless 现在使用 Knative Eventing 0.21.0。
• OpenShift Serverless 现在使用 Kourier 0.21.0。
• OpenShift Serverless 现在使用 Knative kn CLI 0.21.0。
• OpenShift Serverless 现在使用 Knative Kafka 0.21.1。
• OpenShift Serverless 功能现在作为技术预览提供。

• 如果您为 Kafka 频道或新 Kafka 源创建新订阅，在新创建的订阅或 sink 报告就绪状态后 Kafka 数据平面可能会延迟分配信息。

  因此，在 data plane 没有报告就绪状态时发送的信息可能无法传送到订阅者或 sink。

  有关此问题和可能的解决方案的更多信息，请参阅知识库文章 #6343981。

• OpenShift Serverless 现在使用 Knative Serving 0.20.0。
• OpenShift Serverless 使用 Knative Eventing 0.20.0。
• OpenShift Serverless 现在使用 Kourier 0.20.0。
• OpenShift Serverless 现在使用 Knative kn CLI 0.20.0。
• OpenShift Serverless 现在使用 Knative Kafka 0.20.0。

• OpenShift Serverless 上的 Knative Kafka 现已正式发布（GA）。

  重要

  仅支持 OpenShift Serverless 上的 KafkaChannel 和 KafkaSource 对象的 v1beta1 API 版本。不要使用这些 API 的 v1alpha1 版本，因为这个版本现已弃用。

• 对于 OpenShift Container Platform 4.6 及更新的版本，用于安装和升级 OpenShift Serverless 的 Operator 频道已更新为 stable。

• OpenShift Serverless 现在在 IBM Power Systems、IBM Z 和 LinuxONE 上被支持，但以下功能除外，这些功能不被支持：

  • Knative Kafka 功能。
  • OpenShift Serverless 功能开发人员预览。

• Kafka 频道的订阅有时无法标记为 READY，并处于 SubscriptionNotMarkedReadyByChannel 状态。您可以通过重启 Kafka 频道的分配程序来解决这个问题。

• 如果您为 Kafka 频道或新 Kafka 源创建新订阅，在新创建的订阅或 sink 报告就绪状态后 Kafka 数据平面可能会延迟分配信息。

  因此，在 data plane 没有报告就绪状态时发送的信息可能无法传送到订阅者或 sink。

  有关此问题和可能的解决方案的更多信息，请参阅知识库文章 #6343981。

• 快速部署无服务器容器。
• 自动缩放 pod

• 频道和订阅，或者
• 代理和触发器。

• Node.js
• Python
• Go
• Quarkus
• TypeScript

• 功能入门。

• 创建代理

• 没有可用的事件持久性。如果 Pod 停机，则 Pod 上的事件将会丢失。
• InMemoryChannel 频道没有实现事件排序，因此同时接收到的两个事件可能会以任何顺序传送给订阅者。
• 如果订阅者拒绝某个事件，则不会默认重新发送尝试。您可以通过修改 Subscription 对象中的 delivery 规格来配置重新发送尝试。

• 创建频道。
• 如果您是集群管理员，可以配置频道的默认设置。请参阅配置频道默认设置。

• OpenShift Serverless 支持在受限网络环境中安装。
• OpenShift Serverless 目前无法在单个集群的多租户配置中使用。

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 已登陆到 OpenShift Container Platform Web 控制台。

• 安装 OpenShift Serverless Operator 后，您可以安装 Knative Serving 或 安装 Knative Eventing。

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 已登陆到 OpenShift Container Platform Web 控制台。
• 已安装 OpenShift Serverless Operator。

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 已安装 OpenShift Serverless Operator。
• 安装 OpenShift CLI(oc)。

• 如果要使用 Knative 事件驱动的架构，您可以安装 Knative Eventing。

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 已登陆到 OpenShift Container Platform Web 控制台。
• 已安装 OpenShift Serverless Operator。

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 已安装 OpenShift Serverless Operator。
• 安装 OpenShift CLI(oc)。

• 如果要使用 Knative 服务，可以安装 Knative Serving。

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 安装 OpenShift CLI(oc)。

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 安装 OpenShift CLI(oc)。

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 您已卸载了 Knative Serving 并移除了 OpenShift Serverless Operator。
• 安装 OpenShift CLI(oc)。

流程

• 运行以下命令删除 OpenShift Serverless CRD：

  $ oc get crd -oname | grep 'knative.dev' | xargs oc delete

  Copy to Clipboard Toggle word wrap

先决条件

• 已登陆到 OpenShift Container Platform Web 控制台。

• OpenShift Serverless Operator 和 Knative Serving 已安装在 OpenShift Container Platform 集群中。

  重要

  如果 libc 不可用，您在运行 CLI 命令时可能会看到以下错误：

  $ kn: No such file or directory

  Copy to Clipboard Toggle word wrap
• 如果要使用验证步骤，您必须安装 OpenShift (oc) CLI。

验证

• 运行以下命令检查是否已创建了正确的 Knative CLI 资源和路由：

  $ oc get ConsoleCLIDownload

  Copy to Clipboard Toggle word wrap

  输出示例

  NAME                  DISPLAY NAME                                             AGE
  kn                    kn - OpenShift Serverless Command Line Interface (CLI)   2022-09-20T08:41:18Z
  oc-cli-downloads      oc - OpenShift Command Line Interface (CLI)              2022-09-20T08:00:20Z

  Copy to Clipboard Toggle word wrap

  $ oc get route -n openshift-serverless

  Copy to Clipboard Toggle word wrap

  输出示例

  NAME   HOST/PORT                                  PATH   SERVICES                      PORT       TERMINATION     WILDCARD
  kn     kn-openshift-serverless.apps.example.com          knative-openshift-metrics-3   http-cli   edge/Redirect   None

  Copy to Clipboard Toggle word wrap

先决条件

• 您的红帽帐户必须具有有效的 OpenShift Container Platform 订阅。

先决条件

• 如果您不使用 RHEL 或 Fedora，请确保将 libc 安装在库路径的目录中。

  重要

  如果 libc 不可用，您在运行 CLI 命令时可能会看到以下错误：

  $ kn: No such file or directory

  Copy to Clipboard Toggle word wrap

先决条件

• 已安装 Knative(kn)CLI。

流程

• 构建事件：

  $ kn event build --field <field-name>=<value> --type <type-name> --id <id> --output <format>

  Copy to Clipboard Toggle word wrap

  其中：

  • --field 标志将数据作为字段值对添加到事件中。您可以多次使用它。
  • --type 标志允许您指定指定事件类型的字符串。
  • --id 标志指定事件的 ID。

  • 您可以将 json 或 yaml 参数与 --output 标志一起使用，以更改事件的输出格式。

    所有这些标记都是可选的。

    构建简单的事件

    $ kn event build -o yaml

    Copy to Clipboard Toggle word wrap

    结果为 YAML 格式

    data: {}
    datacontenttype: application/json
    id: 81a402a2-9c29-4c27-b8ed-246a253c9e58
    source: kn-event/v0.4.0
    specversion: "1.0"
    time: "2021-10-15T10:42:57.713226203Z"
    type: dev.knative.cli.plugin.event.generic

    Copy to Clipboard Toggle word wrap

    构建示例事务事件

    $ kn event build \
        --field operation.type=local-wire-transfer \
        --field operation.amount=2345.40 \
        --field operation.from=87656231 \
        --field operation.to=2344121 \
        --field automated=true \
        --field signature='FGzCPLvYWdEgsdpb3qXkaVp7Da0=' \
        --type org.example.bank.bar \
        --id $(head -c 10 < /dev/urandom | base64 -w 0) \
        --output json

    Copy to Clipboard Toggle word wrap

    JSON 格式的结果事件

    {
      "specversion": "1.0",
      "id": "RjtL8UH66X+UJg==",
      "source": "kn-event/v0.4.0",
      "type": "org.example.bank.bar",
      "datacontenttype": "application/json",
      "time": "2021-10-15T10:43:23.113187943Z",
      "data": {
        "automated": true,
        "operation": {
          "amount": "2345.40",
          "from": 87656231,
          "to": 2344121,
          "type": "local-wire-transfer"
        },
        "signature": "FGzCPLvYWdEgsdpb3qXkaVp7Da0="
      }
    }

    Copy to Clipboard Toggle word wrap

先决条件

• 已安装 Knative(kn)CLI。

流程

• 发送事件：

  $ kn event send --field <field-name>=<value> --type <type-name> --id <id> --to-url <url> --to <cluster-resource> --namespace <namespace>

  Copy to Clipboard Toggle word wrap

  其中：

  • --field 标志将数据作为字段值对添加到事件中。您可以多次使用它。
  • --type 标志允许您指定指定事件类型的字符串。
  • --id 标志指定事件的 ID。
  • 如果您要将事件发送到公开的目的地，请使用 --to-url 标志指定 URL。

  • 如果要将事件发送到集群内 Kubernetes 资源，请使用 --to 标志指定目的地。

    • 使用 <Kind>:<ApiVersion>:<name> 格式指定 Kubernetes 资源。

  • --namespace 标志指定命名空间。如果省略，则会从当前上下文中获取命名空间。

    所有这些标志都是可选的，除了目的地规格外，您需要使用 --to-url 或 --to。

    以下示例显示向 URL 发送事件：

    示例命令

    $ kn event send \
        --field player.id=6354aa60-ddb1-452e-8c13-24893667de20 \
        --field player.game=2345 \
        --field points=456 \
        --type org.example.gaming.foo \
        --to-url http://ce-api.foo.example.com/

    Copy to Clipboard Toggle word wrap

    以下示例显示了将事件发送到 in-cluster 资源：

    示例命令

    $ kn event send \
        --type org.example.kn.ping \
        --id $(uuidgen) \
        --field event.type=test \
        --field event.data=98765 \
        --to Service:serving.knative.dev/v1:event-display

    Copy to Clipboard Toggle word wrap

• 在使用描述符文件对集群进行更改之前，您可以手动修改该文件。
• 您可以在本地跟踪版本控制系统中服务的描述符文件。这可让您在目标集群以外的位置重复使用描述符文件，例如在持续集成（CI）管道、开发环境或演示中。
• 您可以检查创建的描述符文件，以了解 Knative 服务的信息。特别是，您可以看到生成的服务如何受到传递给 kn 命令的不同参数的影响。