• OpenShift Serverless 现在使用 Knative Serving 1.7。
• OpenShift Serverless 现在使用 Knative Eventing 1.7。
• OpenShift Serverless 现在使用 Kourier 1.7。
• OpenShift Serverless 现在使用 Knative (kn) CLI 1.7。
• OpenShift Serverless 现在使用 Knative Kafka 1.7。
• kn func CLI 插件现在使用 func 1.9.1 版本。
• Node.js 和 TypeScript 运行时现在正式发布 (GA)。
• OpenShift Serverless 功能的 Python 运行时现在作为技术预览提供。
• Knative Serving 的多容器支持现在作为技术预览提供。此功能允许您使用单个 Knative 服务来部署多容器 pod。

• 在 OpenShift Serverless 1.29 或更高版本中，Knative Eventing 的以下组件将从两个 pod 缩减为一个：

  • imc-controller
  • imc-dispatcher
  • mt-broker-controller
  • mt-broker-filter
  • mt-broker-ingress

• Serving CR 的 serverless.openshift.io/enable-secret-informer-filtering 注解现已弃用。该注解仅适用于 Istio，不适用于 Kourier。

  在 OpenShift Serverless 1.28 中，OpenShift Serverless Operator 允许注入 net-istio 和 net-kourier 的环境变量 ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID。

  要防止从 OpenShift Serverless 1.28 升级到一些将来的版本时出现问题，用户必须使用 networking.internal.knative.dev/certificate-uid:some_cuid 注解其 secret。

• 目前，IBM Power、IBM zSystems 和 IBM® LinuxONE 上的 OpenShift Serverless 功能不支持 Python 的运行时。

  Node.js、typetype 和 Quarkus 功能在这些架构中被支持。

• 在 Windows 平台上，因为 app.sh 文件权限，无法使用 Source-to-Image 构建器在本地构建、运行或部署 Python 功能。

  要临时解决这个问题，对 Linux 使用 Windows 子系统。

• OpenShift Serverless 现在使用 Knative Serving 1.6。
• OpenShift Serverless 现在使用 Knative Eventing 1.6。
• OpenShift Serverless 现在使用 Kourier 1.6。
• OpenShift Serverless 现在使用 Knative (kn) CLI 1.6。
• OpenShift Serverless 现在使用 Knative Kafka 1.6。
• kn func CLI 插件现在使用 func 1.8.1。
• 命名空间范围的代理现在作为技术预览提供。例如，此类代理可用于实施基于角色的访问控制 (RBAC) 策略。
• KafkaSink 现在使用 CloudEvent 二进制内容模式。二进制内容模式比结构化模式更高效，因为它使用其正文中的标头而不是 CloudEvent。例如，对于 HTTP 协议，它使用 HTTP 标头。
• 现在，您可以使用 OpenShift Container Platform 4.10 及更新的版本中的 OpenShift Route 通过 HTTP/2 协议使用 gRPC 框架。这提高了客户端和服务器间的通信效率和速度。
• Knative Operator Serving 和 Eventings CRD 的 API 版本 v1alpha1 在 1.27 中弃用。它将在以后的版本中删除。红帽强烈建议使用 v1beta1 版本。这不会影响现有安装，因为在升级 Serverless Operator 时 CRD 会被自动更新。
• 现在默认启用交付超时功能。它允许您指定每个发送的 HTTP 请求的超时时间。这个功能仍是一个技术预览。

• 在以前的版本中，Knative 服务有时没有处于 Ready 状态，报告等待负载均衡器就绪。这个问题已被解决。

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

• 命名空间范围的代理可能会在用户命名空间中保留 ClusterRoleBindings，即使删除了命名空间范围的代理。

  如果发生这种情况，删除用户命名空间中名为 rbac-proxy-reviews-prom-rb-knative-kafka-broker-data-plane-{{.Namespace}} 的 ClusterRoleBinding。

• 如果您将 net-istio 用于 Ingress，并使用 security.dataPlane.mtls: true 通过 SMCP 启用 mTLS，Service Mesh 为 *.local 主机部署 DestinationRule，这代表不允许对 OpenShift Serverless 使用 DomainMapping。

  要临时解决这个问题，部署 PeerAuthentication 来启用 mTLS，而不是使用 security.dataPlane.mtls: true。

• 带有 Quarkus 的 OpenShift Serverless 功能现在是 GA。
• OpenShift Serverless 现在使用 Knative Serving 1.5。
• OpenShift Serverless 现在使用 Knative Eventing 1.5。
• OpenShift Serverless 现在使用 Kourier 1.5。
• OpenShift Serverless 现在使用 Knative (kn) CLI 1.5。
• OpenShift Serverless 现在使用 Knative Kafka 1.5。
• OpenShift Serverless 现在使用 Knative Operator 1.3。
• kn func CLI 插件现在使用 func 1.8.1。
• 持久性卷声明 (PVC) 现在为 GA。PVC 为 Knative 服务提供持久性数据存储。

• 新的触发器过滤器功能现在作为技术预览提供。它允许用户指定一组过滤器表达式，其中每个表达式都会为每个事件评估为 true 或 false。

  要启用新的触发器过滤器，请在 operator 配置映射中 KnativeEventing 类型的部分中添加 new-trigger-filters: enabled 条目：

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeEventing
  ...
  ...
  spec:
    config:
      features:
        new-trigger-filters: enabled
  ...

• Knative Operator 1.3 为 operator.knative.dev 添加了 API 的更新 v1beta1 版本。

  要从 KnativeServing 和 KnativeEventing 自定义资源配置映射中的 v1alpha1 更新至 v1beta1，请编辑 apiVersion 键：

  KnativeServing 自定义资源配置映射示例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  ...

  KnativeEventing 自定义资源配置映射示例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeEventing
  ...

• 在以前的版本中，Kafka 代理、Kafka 源和 Kafka sink 禁用联邦信息处理标准 (FIPS) 模式。这个问题已被解决，现在 FIPS 模式可用。

• 如果您将 net-istio 用于 Ingress，并使用 security.dataPlane.mtls: true 通过 SMCP 启用 mTLS，Service Mesh 为 *.local 主机部署 DestinationRule，这代表不允许对 OpenShift Serverless 使用 DomainMapping。

  要临时解决这个问题，部署 PeerAuthentication 来启用 mTLS，而不是使用 security.dataPlane.mtls: true。

• OpenShift Serverless 现在使用 Knative Serving 1.4。
• OpenShift Serverless 现在使用 Knative Eventing 1.4。
• OpenShift Serverless 现在使用 Kourier 1.4。
• OpenShift Serverless 现在使用 Knative (kn) CLI 1.4。
• OpenShift Serverless 现在使用 Knative Kafka 1.4。
• kn func CLI 插件现在使用 func 1.7.0。
• 用于创建和部署功能的集成开发环境(IDE)插件现在可用于 Visual Studio Code 和 IntelliJ。

• Knative Kafka 代理现在是 GA。Knative Kafka 代理是 Knative 代理 API 的高性能实现，直接以 Apache Kafka 为目标。

  建议您不要使用 MT-Channel-Broker，而是使用 Knative Kafka 代理。

• Knative Kafka sink 现在为 GA。KafkaSink 使用 CloudEvent，并将其发送到 Apache Kafka 主题。事件可以在结构化或二进制内容模式中指定。
• 为内部流量启用 TLS 现在作为技术预览提供。

• 在以前的版本中，如果在存活度探测失败后重启容器，Knative Serving 会出现一个就绪度探测失败。这个问题已被解决。

• Kafka 代理、Kafka 源和 Kafka sink 禁用 Federal Information Processing Standards (FIPS) 模式。
• SinkBinding 对象不支持服务的自定义修订名称。

• Knative Serving Controller pod 添加了一个新的 informer 来监视集群中的 secret。informer 在缓存中包含 secret，这会增加控制器 pod 的内存消耗。

  如果 pod 内存不足，您可以通过增加部署的内存限值来解决此问题。

• 如果您将 net-istio 用于 Ingress，并使用 security.dataPlane.mtls: true 通过 SMCP 启用 mTLS，Service Mesh 为 *.local 主机部署 DestinationRule，这代表不允许对 OpenShift Serverless 使用 DomainMapping。

  要临时解决这个问题，部署 PeerAuthentication 来启用 mTLS，而不是使用 security.dataPlane.mtls: true。

• 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

• 如果您将 net-istio 用于 Ingress，并使用 security.dataPlane.mtls: true 通过 SMCP 启用 mTLS，Service Mesh 为 *.local 主机部署 DestinationRule，这代表不允许对 OpenShift Serverless 使用 DomainMapping。

  要临时解决这个问题，部署 PeerAuthentication 来启用 mTLS，而不是使用 security.dataPlane.mtls: true。

• 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 在代理被删除之前被删除，则命名空间终结器（finalizer）可能无法删除。

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

  apiVersion: operator.knative.dev/v1beta1
  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

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

• 如果您将 net-istio 用于 Ingress，并使用 security.dataPlane.mtls: true 通过 SMCP 启用 mTLS，Service Mesh 为 *.local 主机部署 DestinationRule，这代表不允许对 OpenShift Serverless 使用 DomainMapping。

  要临时解决这个问题，部署 PeerAuthentication 来启用 mTLS，而不是使用 security.dataPlane.mtls: true。

• 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 - 基于频道的代理/触发器。
• 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

  代理的 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/

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

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

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

• 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

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

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

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

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

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

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

  buildEnvs: []

  使用这个：

  buildEnvs:
  - name: BP_NODE_RUN_SCRIPTS
    value: build

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

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

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

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

       服务配置示例

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

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

       $ systemctl --user daemon-reload

       $ systemctl restart --user podman.socket

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

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

• 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 插件现在使用 func 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

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

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

       服务配置示例

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

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

       $ systemctl --user daemon-reload

       $ systemctl restart --user podman.socket

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

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

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

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

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

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

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

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

• 现在，您可以在 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"
  ...

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

  您可以在安装或升级 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

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

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

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

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

  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

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

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

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

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

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

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

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

• Node.js
• Quarkus
• TypeScript

• 函数入门。

• 创建代理

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

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

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

先决条件

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

先决条件

• 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
• 您的集群启用了 Marketplace 功能，或者手动配置 Red Hat Operator 目录源。
• 已登陆到 OpenShift Container Platform 集群。

• 安装 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

先决条件

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

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

  重要

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

  $ kn: No such file or directory

• 如果要使用验证步骤，您必须安装 OpenShift (oc) CLI。

验证

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

  $ oc get ConsoleCLIDownload

  输出示例

  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

  $ oc get route -n openshift-serverless

  输出示例

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

先决条件

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

先决条件

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

  重要

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

  $ kn: No such file or directory

先决条件

• 已安装 Knative (kn) CLI。

流程

• 构建事件：

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

  其中：

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

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

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

    构建简单的事件

    $ kn event build -o yaml

    结果为 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

    构建示例事务事件

    $ 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

    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="
      }
    }

先决条件

• 已安装 Knative (kn) CLI。

流程

• 发送事件：

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

  其中：

  • --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/

    以下示例显示了将事件发送到 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

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

先决条件

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

流程

• 创建功能项目：

  $ kn func create -r <repository> -l <runtime> -t <template> <path>

  • 可接受的运行时值包括 quarkus、node、typescript、go、python、springboot 和 rust。

  • 可接受的模板值包括 http 和 cloudevents。

    示例命令

    $ kn func create -l typescript -t cloudevents examplefunc

    输出示例

    Created typescript function in /home/user/demo/examplefunc

  • 或者，您可以指定包含自定义模板的存储库。

    示例命令

    $ kn func create -r https://github.com/boson-project/templates/ -l node -t hello-world examplefunc

    输出示例

    Created node function in /home/user/demo/examplefunc

先决条件

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

流程

• 部署功能：

  $ kn func deploy [-n <namespace> -p <path> -i <image>]

  输出示例

  Function deployed at: http://func.example.com

  • 如果没有指定 namespace，则该函数部署到当前命名空间中。
  • 此函数从当前目录中部署，除非指定了 path。
  • Knative 服务名称派生自项目名称，无法使用此命令进行更改。

流程

• 列出现有功能：

  $ kn func list [-n <namespace> -p <path>]

  输出示例

  NAME           NAMESPACE  RUNTIME  URL                                                                                      READY
  example-function  default    node     http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com  True

• 列出部署为 Knative 服务的功能：

  $ kn service list -n <namespace>

  输出示例

  NAME            URL                                                                                       LATEST                AGE   CONDITIONS   READY   REASON
  example-function   http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com   example-function-gzl4c   16m   3 OK / 3     True

流程

• 描述函数：

  $ kn func info [-f <format> -n <namespace> -p <path>]

  示例命令

  $ kn func info -p function/example-function

  输出示例

  Function name:
    example-function
  Function is built in image:
    docker.io/user/example-function:latest
  Function is deployed as Knative Service:
    example-function
  Function is deployed in namespace:
    default
  Routes:
    http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com

先决条件

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

流程

• 调用函数：

  $ kn func invoke

  • kn func invoke 命令仅在当前运行本地容器镜像时或在集群中部署功能时才有效。
  • kn func invoke 命令默认在本地目录上执行，并假定此目录是一个功能项目。

流程

• 删除函数：

  $ kn func delete [<function_name> -n <namespace> -p <path>]

  • 如果没有指定要删除的功能的名称或路径，则会搜索当前目录以查找用于决定要删除的功能的 func.yaml 文件。
  • 如果没有指定命名空间，则默认为 func.yaml 文件中的 namespace 值。

先决条件

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

流程

• 创建 Knative 服务：

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

  其中：

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

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

    示例命令

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

    输出示例

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

先决条件

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

先决条件

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

先决条件

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

先决条件

• 安装 OpenShift CLI (oc) 。

先决条件

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

先决条件

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

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 在将 init 容器用于 Knative 服务前，管理员必须在 KnativeServing 自定义资源 (CR) 中添加 kubernetes.podspec-init-containers 标志。如需更多信息，请参阅 OpenShift Serverless "Global configuration" 文档。

流程

• 将 initContainers spec 添加到 Knative Service 对象中：

  服务规格示例

  apiVersion: serving.knative.dev/v1
  kind: Service
  ...
  spec:
    template:
      spec:
        initContainers:
          - imagePullPolicy: IfNotPresent 1
            image: <image_uri> 2
            volumeMounts: 3
              - name: data
                mountPath: /data
  ...

  1

  镜像下载时的镜像拉取策略。

  2

  init 容器镜像的 URI。

  3

  卷在容器文件系统中挂载的位置。

• 软限制是目标请求限制，而不是严格实施的绑定。例如，如果流量突发，可以超过软限制目标。

• 硬限制是严格实施的上限请求限制。如果并发达到硬限制，则请求将被缓冲，必须等到有足够的可用容量来执行请求。

  重要

  只有在应用程序中明确用例时才建议使用硬限制配置。指定较少的硬限制可能会对应用程序的吞吐量和延迟造成负面影响，并可能导致冷启动。

先决条件

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

流程

• 使用带有标准 kn service update 命令的 --traffic 标签指定服务修订版本以及您要路由到它的流量百分比：

  示例命令

  $ kn service update <service_name> --traffic <revision>=<percentage>

  其中：

  • <service_name> 是您要为其配置流量路由的 Knative 服务的名称。
  • <revision> 是您要配置为接收流量百分比的修订版本。您可以使用 --tag 标志指定修订版本的名称，或指定分配给修订版本的标签。
  • <percentage> 是您要发送到指定修订版本的流量百分比。

• 可选： --traffic 标志可在一个命令中多次指定。例如，如果您有一个标记为 @latest 的修订版本以及名为 stable 的修订版本，您可以指定您要分割到每个修订版本的流量百分比：

  示例命令

  $ kn service update example-service --traffic @latest=20,stable=80

  如果您有多个修订版本，且没有指定应分割到最后一个修订版本的流量百分比，--traffic 标志可以自动计算此设置。例如，如果您有一个第三个版本名为 example，则使用以下命令：

  示例命令

  $ kn service update example-service --traffic @latest=10,stable=60

  剩余的 30% 的流量被分成 example 修订，即使未指定。

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 已登陆到 OpenShift Container Platform Web 控制台。

先决条件

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

先决条件

• 您必须已在 OpenShift Container Platform 集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
• 安装 OpenShift CLI (oc) 。

先决条件

• OpenShift Serverless Operator 和 Knative Serving 组件必须安装在 OpenShift Container Platform 集群中。
• 安装 OpenShift CLI (oc) 。

先决条件

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

流程

• 通过添加 networking.knative.dev/visibility=cluster-local 标签来设置服务的可见性：

  $ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local

验证

• 输入以下命令并查看输出结果，检查您的服务的 URL 是否现在格式为 http://<service_name>.<namespace>.svc.cluster.local：

  $ oc get ksvc

  输出示例

  NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
  hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True

先决条件

• OpenShift Serverless Operator、Knative Serving 和 Knative Eventing 已在 OpenShift Container Platform 集群中安装。
• 已登陆到 web 控制台，且处于 Developer 视角。
• 您已创建了一个项目，或者具有适当的角色和权限访问项目，以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
• 您已创建了 sink，如 Knative 服务、频道或代理。

先决条件

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

先决条件

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

先决条件

• 已登陆到 OpenShift Container Platform Web 控制台。
• OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
• 您已创建了一个项目，或者具有适当的角色和权限访问项目，以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

先决条件

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

先决条件

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

验证

• 创建 API 服务器源后，您会在 Topology 视图中看到它连接到接收器的服务。

  

先决条件

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

先决条件

• 在集群中安装了 OpenShift Serverless Operator 和 Knative Eventing。
• 您已创建了一个项目，或者具有适当的角色和权限访问项目，以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
• 您已在与 API 服务器源 YAML 文件中定义的相同的命名空间中创建 default 代理。
• 安装 OpenShift CLI (oc) 。

先决条件

• 已登陆到 OpenShift Container Platform Web 控制台。
• 在集群中安装了 OpenShift Serverless Operator、Knative Serving 和 Knative Eventing。
• 您已创建了一个项目，或者具有适当的角色和权限访问项目，以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

先决条件

• 在集群中安装了 OpenShift Serverless Operator、Knative Serving 和 Knative Eventing。
• 已安装 Knative (kn) CLI。
• 您已创建了一个项目，或者具有适当的角色和权限访问项目，以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
• 可选： 如果要使用此流程验证步骤，请安装 OpenShift CLI (oc) 。

删除 ping 源

• 删除 ping 源：

  $ kn delete pingsources.sources.knative.dev <ping_source_name>

先决条件

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

删除 ping 源

• 删除 ping 源：

  $ oc delete -f <filename>

  示例命令

  $ oc delete -f ping-source.yaml