无服务器应用程序

OpenShift Container Platform 4.2

OpenShift Serverless 的安装、使用与发行注记

Red Hat OpenShift Documentation Team

摘要

本文档提供有关如何在 OpenShift Container Platform 4.2 中使用 OpenShift Serverless 的信息

第 1 章 OpenShift Serverless 入门

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

重要

OpenShift Serverless 只是一个技术预览功能。红帽产品服务等级协议 (SLA) 不支持技术预览功能，并且这些功能可能并不完善。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情，请参阅 https://access.redhat.com/support/offerings/techpreview/。

OpenShift Serverless 可减少开发人员需要进行的基础架构设置或后端开发的操作，从而简化了代码从开发到在生产环境中应用的过程。

1.1. OpenShift Serverless 的工作原理

使用 OpenShift Serverless 的开发人员可使用所提供的 Kubernetes 原生 API，以及熟悉的语言和框架来部署应用程序和容器工作负载。有关安装 OpenShift Serverless 的详情请参考 Installing OpenShift Serverless。

在 OpenShift Container Platform 中使用 OpenShift Serverless，可通过自动化操作在单一多云容器平台中运行所有有状态、无状态以及无服务器的工作负载。开发人员能够使用单一平台托管其微服务、资产和无服务器的应用程序。

OpenShift Serverless 基于开源 Knative 项目，通过启用企业级无服务器平台在混合和多云环境之间实现可移植性和一致性。

1.2. OpenShift Serverless 上的应用程序

应用程序通过 CRD（Custom Resource Definitions）及关联的 Kubernetes 中的控制器创建，并被打包为 OCI 规格的 Linux 容器。这些容器可以在任何地方运行。

要在 OpenShift Serverless 中部署应用程序，必须创建 Knative Services。有关详情请参考 开始使用 Knative Services。

第 2 章 OpenShift Serverless 产品架构

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

2.1. Knative Serving

OpenShift Container Platform 上的 Knative Serving 基于 Kubernetes 和 Istio 构建，支持部署和提供无服务器应用程序。

它创建一组 Kubernetes 自定义资源定义 (CRD)，用于定义和控制 OpenShift Container Platform 集群上无服务器工作负载的行为。

这些 CRD 可用作构建块来解决复杂用例，例如快速部署无服务器容器、自动扩展 Pod、路由和网络编程 Istio 组件，或查看已部署代码和配置的时间点快照。

2.1.1. Knative Serving 组件

本节所述组件是正确配置和运行 Knative Serving 所需的资源。

Knative 服务资源
service.serving.knative.dev 资源自动管理集群上无服务器工作负载的整个生命周期。该资源可控制其他对象的创建，以确保每次更新服务时应用程序均有路由、配置和新修订版本。服务可被定义为始终将流量路由至最新修订版本或一个固定的修订版本。
Knative 路由资源
route.serving.knative.dev 资源可将网络端点映射到一个或多个 Knative 修订版本。您可通过多种方式管理流量，包括部分流量和指定路由。
Knative 配置资源
configuration.serving.knative.dev 资源可保持部署所需状态。修改配置则会创建一个新修订版本。
Knative 修订版本资源
revision.serving.knative.dev 资源是每次对工作负载进行修改所涉及代码和配置的时间点快照。所有修订版本均为不可变对象，可以根据需要保留。集群管理员可修改 revision.serving.knative.dev 资源，以便在 OpenShift Container Platform 集群中自动扩展 Pod。

2.2. Knative Client

Knative Client (kn) 会扩展 oc 或 kubectl 工具的功能，以支持在 OpenShift Container Platform 上与 Knative 组件交互。kn 允许开发人员在不直接编辑 YAML 文件的情况下部署和管理应用程序。

2.3. Knative Eventing

Knative Eventing 的开发人员预览版本可用于 OpenShift Serverless。但是，它没有包括在 OpenShift Serverless Operator 中，且作为该技术预览的一部分当前还不被支持。如需有关 Knative Eventing 的更多信息，包括安装说明和示例，请参阅 OpenShift Container Platform Knative Eventing 的文档 。

第 3 章 安装 OpenShift Serverless

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

重要

OpenShift Serverless 未经测试且不支持在受限网络环境中安装。

3.1. 集群大小要求

必须正确定义集群大小以确保 OpenShift Serverless 可正常运行。您可以使用 MachineSet API 手动将集群扩展至所需大小。

启动首个无服务器应用程序至少需要 OpenShift 集群具有 10 个 CPU 和 40GB 内存。这通常意味着您需要对一个默认 MachineSet 扩展两个额外的机器。

注意

对于此配置，具体要求取决于所部署的应用程序。默认情况下，每个 Pod 需要约 400m 的 CPU，推荐均基于此值。在给出的推荐中，应用程序最多可扩展至 10 个副本。降低应用程序的实际 CPU 请求会进一步推高边界。

注意

给出的数字仅与 OpenShift 集群的 worker 机器池有关。Master 节点不用于常规调度且会被忽略。

对于更高级的用例，如使用 OpenShift 来记录日志、监控、计量和跟踪，您必须部署更多资源。对这类用例的推荐要求为 24 个 vCPU 和 96GB 内存。

其它资源

有关使用 MachineSet API 的更多信息，请参阅创建 MachineSet。

3.1.1. 手动扩展 MachineSet

如果您必须在 MachineSet 中添加或移除机器实例，则可以手动扩展 MachineSet。

先决条件

  • 安装 OpenShift Container Platform 集群和 oc 命令行。
  • 以具有 cluster-admin 权限的用户身份登录 oc。

流程

  1. 查看集群中的 MachineSet： 

    $ oc get machinesets -n openshift-machine-api

    MachineSet 以 <clusterid>-worker-<aws-region-az> 的形式列出。

  2. 扩展 MachineSet： 

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

    或者： 

    $ oc edit machineset <machineset> -n openshift-machine-api

    您可以扩展或缩减 MachineSet 的规模。需要过几分钟以后新机器才可用。

    重要

    默认情况下，OpenShift Container Platform 路由器 Pod 部署在 worker 上。由于路由器需要访问某些集群资源（包括 Web 控制台），除非已事先把路由器 Pod 移到其他位置，否则请不要将 worker MachineSet 扩展为 0。

3.2. 安装 OpenShift Serverless Operator

OpenShift Serverless Operator 可参照 OpenShift Container Platform 的 Operator 安装说明来安装。

您可按照 OpenShift Container Platform 的 Operator 安装说明在主机集群中安装 OpenShift Serverless Operator。

注意

OpenShift Serverless Operator 仅适用于 4.1.13 及更新版本的 OpenShift Container Platform。

详情请参阅 OpenShift Container Platform 文档中有关向集群中添加 Operator 的内容。

重要

OpenShift Serverless Operator 会自动安装 Service Mesh Operator。如果您已经安装了一个社区版本，这将导致与 OpenShift Serverless Operator Service Mesh auto-install 的冲突。在这种情况下，已存在的 Maistra 社区版本会被使用。

3.3. 安装 Knative Serving

您必须创建一个 KnativeServing 对象以使用 OpenShift Serverless Operator 来安装 Knative Serving。

重要

您需要在 knative-serving 命名空间内创建 KnativeServing 项（如示例 YAML 所示），或它会被忽略。

service.yaml 示例

apiVersion: v1
kind: Namespace
metadata:
 name: knative-serving
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
 name: knative-serving
 namespace: knative-serving

先决条件

  • 具有集群管理员访问权限的帐户。
  • 已安装 OpenShift Serverless Operator。

流程

  1. 将 YAML 文件示例复制到 smmr.yaml 中，并运行以下命令： 

    $ oc apply -f serving.yaml

  2. 使用以下命令验证安装是否完成： 

    $ oc get knativeserving.operator.knative.dev/knative-serving -n knative-serving --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

    结果应类似于： 

    DeploymentsAvailable=True
InstallSucceeded=True
Ready=True

3.4. 卸载 Knative Serving

要卸载 Knative Serving，必须移除其自定义资源并移除 knative-serving 命名空间。

先决条件

  • 已安装 Knative Serving

流程

  1. 要移除 Knative Serving，请使用以下命令： 

    $ oc delete knativeserving.operator.knative.dev knative-serving -n knative-serving

  2. 在该命令运行完成且已从 knative-serving 命名空间中移除所有 Pod 后，使用以下命令移除命名空间： 

    $ oc delete namespace knative-serving

3.5. 删除 OpenShift Serverless Operator

您可按照 OpenShift Container Platform 的 Operator 删除说明从主机集群中移除 OpenShift Serverless Operator。

详情请参阅 OpenShift Container Platform 文档中有关从集群中删除 Operator 的内容。

3.6. 从 Operator 中删除 Knative Serving CRD

卸载 OpenShift Serverless Operator 后，Operator CRD 和 API 服务仍保留在集群上。使用此流程完全卸载剩余组件。

先决条件

  • 已使用以上流程卸载了 Knative Serving 并移除了 OpenShift Serverless Operator。

流程

  1. 运行以下命令删除剩余的 Knative Serving CRD： 

    $ oc delete crd knativeservings.operator.knative.dev

第 4 章 开始使用 Knative 服务

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

Knative 服务是用户为部署无服务器应用程序而创建的 Kubernetes 服务。每个 Knative 服务均由 .yaml 文件中包含的路由和配置定义。

4.1. 创建 Knative 服务

要创建服务，则必须要创建 service.yaml 文件。

您可以复制以下示例。该示例将创建一个名为 helloworld-go 的 golang 应用程序，您可以为该应用程序指定镜像。 

apiVersion: serving.knative.dev/v1alpha1 1
kind: Service
metadata:
  name: helloworld-go 2
  namespace: default 3
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go 4
          env:
            - name: TARGET 5
              value: "Go Sample v1"
1
当前 Knative 版本
2
应用程序的名称
3
应用程序要使用的命名空间
4
应用程序镜像的 URL
5
示例应用程序输出的环境变量

4.2. 部署无服务器应用程序

要部署无服务器应用程序，则必须应用 service.yaml 文件。

流程

  1. 导航到包含 service.yaml 文件的目录。

  2. 通过应用 service.yaml 文件来部署应用程序。 

    $ oc apply --filename service.yaml

现已创建了服务并部署了应用程序，Knative 将为该版应用程序创建新的不可变修订版本。

Knative 还将执行网络操作，为您的应用程序创建路由、入口、服务和负载平衡器，并将根据流量（包括不活跃 Pod）自动扩展或缩减 Pod。

注意

首次在命名空间中创建 Knative 服务时，该命名空间会自动接收新的网络配置。服务第一次就绪的时间可以会比一般需要的时间更长。

如果命名空间没有现有的 NetworkPolicy 配置，则会自动应用“允许所有”类型策略。如果从那个命名空间中删除了所有 Knative 服务，且没有应用任何其它 NetworkPolicy 配置，这个策略将被自动删除。

4.3. 将 Knative Services 连接到现有的 Kubernetes 部署

只要不存在额外的网络限制，Knative Services 就可在任何命名空间中调用 Kubernetes 部署。

Kubernetes 部署可在以下情况下调用 Knative Service：

  • Kubernetes 部署与目标 Knative Service 位于同一命名空间。
  • Kubernetes 部署位于一个命名空间中，该命名空间被手工添加到 knative-serving-ingress 的 ServiceMeshMemberRoll 中。

  • Kubernetes 部署使用目标 Knative Service 的公共 URL。

    注意

    默认情况下，Knative Services 通过一个公共 URL 访问。如果要使用一个公共 URL 将目标 Knative Service 连接到您的已存在的 Kubernetes 部署，则此目标 Knative Service 一定不能被配置为私有的、cluster-local 可见的服务。

第 5 章 监控 OpenShift Serverless 组件

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

作为集群管理员，您可以部署 OpenShift Container Platform 监控堆栈并监控 OpenShift Serverless 组件的指标。

使用 OpenShift Serverless Operator 时，可自动创建所需 ServiceMonitor 对象来监控所部署的组件。

OpenShift Serverless 组件（如 Knative Serving）可公开指标数据。管理员可通过 OpenShift Container Platform Web 控制台来监控此数据。

5.1. 为应用程序监控配置集群

在应用开发人员可监控其应用程序前，集群的操作人员需要进行相应的集群配置。本流程将介绍配置方法。

先决条件

  • 必须使用属于具有集群管理特权的角色的用户登录。

流程

  1. 在 OpenShift Container Platform Web 控制台，导航到 Operators → OperatorHub 页面，并在您的应用程序所在命名空间安装 Prometheus Operator。
  2. 导航到 Operators → Installed Operators 页面，并在同一个命名空间中安装 Prometheus、Alertmanager、Prometheus Rule 和 Service Monitor。

5.2. 验证 OpenShift Container Platform 监控安装以用于 Knative Serving

管理员并不需要手动配置监控，但可执行以下步骤来验证是否已正确安装了监控功能。

流程

  1. 验证是否已部署 ServiceMonitor 对象。 

    $ oc get servicemonitor -n knative-serving
NAME         AGE
activator    11m
autoscaler   11m
controller   11m

  2. 验证是否已向 Knative Serving 命名空间添加 openshift.io/cluster-monitoring=true 标签： 

    $ oc get namespace knative-serving --show-labels
NAME              STATUS   AGE   LABELS
knative-serving   Active   4d    istio-injection=enabled,openshift.io/cluster-monitoring=true,serving.knative.dev/release=v0.7.0

5.3. 使用 OpenShift Container Platform 监控堆栈来监控 Knative Serving

本部分提供使用 OpenShift Container Platform 监控工具来可视化 Knative Serving Pod 自动扩展指标的示例说明。

先决条件

  • 必须已安装 OpenShift Container Platform 监控堆栈。

流程

  1. 导航到 OpenShift Container Platform Web 控制台并进行身份验证。
  2. 导航到 Monitoring → Metrics。

  3. 输入 Expression 并选择 Run queries。要监控 Knative Serving 自动扩展程序 Pod，请使用示例表达式。 

    autoscaler_actual_pods

    您现在可在控制台中看到 Knative Serving 自动扩展程序 Pod 的监控信息。

第 6 章 使用 OpenShift Serverless 的 metering

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

作为集群管理员，您可使用 Metering 来分析 OpenShift Serverless 集群中的情况。

如需有关 OpenShift Container Platform 的 metering 的更多信息，请参阅 关于 metering。

6.1. 安装 metering

有关在 OpenShift Container Platform 上安装 metering 的详情请参考 Installing Metering。

6.2. Knative making metering 的数据源

以下 ReportDataSources 是 OpenShift Container Platform metering 如何使用 Knative instructioning 的示例。

6.2.1. Knativelatesting 中 CPU 用量的数据源

这个数据源提供在报告的时间段内每个 Knative 服务使用的总 CPU 秒数。

yaml 文件

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: knative-service-cpu-usage
spec:
  prometheusMetricsImporter:
    query: >
      sum
          by(namespace,
             label_serving_knative_dev_service,
             label_serving_knative_dev_revision)
          (
            label_replace(rate(container_cpu_usage_seconds_total{container_name!="POD",container_name!="",pod_name!=""}[1m]), "pod", "$1", "pod_name", "(.*)")
            *
            on(pod, namespace)
            group_left(label_serving_knative_dev_service, label_serving_knative_dev_revision)
            kube_pod_labels{label_serving_knative_dev_service!=""}
          )

6.2.2. 用于 Knative making 中的内存使用的数据源

这个数据源为每个 Knative 服务在报告期间提供平均内存消耗。

yaml 文件

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: knative-service-memory-usage
spec:
  prometheusMetricsImporter:
    query: >
      sum
          by(namespace,
             label_serving_knative_dev_service,
             label_serving_knative_dev_revision)
          (
            label_replace(container_memory_usage_bytes{container_name!="POD", container_name!="",pod_name!=""}, "pod", "$1", "pod_name", "(.*)")
            *
            on(pod, namespace)
            group_left(label_serving_knative_dev_service, label_serving_knative_dev_revision)
            kube_pod_labels{label_serving_knative_dev_service!=""}
          )

6.2.3. 为 KnativeUping metering 应用数据源

您可以使用以下命令应用 ReportDataSources： 

$ oc apply -f <datasource-name>.yaml

示例

$ oc apply -f knative-service-memory-usage.yaml

6.3. 对 Knative Serving metering 的查询

以下 ReportQuery 资源引用提供的 DataSources 示例。

6.3.1. 在 Knativelatesting 中查询 CPU 用量

yaml 文件

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: knative-service-cpu-usage
spec:
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - default: knative-service-cpu-usage
    name: KnativeServiceCpuUsageDataSource
    type: ReportDataSource
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: service
    type: varchar
  - name: data_start
    type: timestamp
    unit: date
  - name: data_end
    type: timestamp
    unit: date
  - name: service_cpu_seconds
    type: double
    unit: cpu_core_seconds
  query: |
    SELECT
      timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart| prestoTimestamp |}' AS period_start,
      timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}' AS period_end,
      labels['namespace'] as project,
      labels['label_serving_knative_dev_service'] as service,
      min("timestamp") as data_start,
      max("timestamp") as data_end,
      sum(amount * "timeprecision") AS service_cpu_seconds
    FROM {| dataSourceTableName .Report.Inputs.KnativeServiceCpuUsageDataSource |}
    WHERE "timestamp" >= timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart | prestoTimestamp |}'
    AND "timestamp" < timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}'
    GROUP BY labels['namespace'],labels['label_serving_knative_dev_service']

6.3.2. 在 Knative Serving 中查询内存用量

yaml 文件

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: knative-service-memory-usage
spec:
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - default: knative-service-memory-usage
    name: KnativeServiceMemoryUsageDataSource
    type: ReportDataSource
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: service
    type: varchar
  - name: data_start
    type: timestamp
    unit: date
  - name: data_end
    type: timestamp
    unit: date
  - name: service_usage_memory_byte_seconds
    type: double
    unit: byte_seconds
  query: |
    SELECT
      timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart| prestoTimestamp |}' AS period_start,
      timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}' AS period_end,
      labels['namespace'] as project,
      labels['label_serving_knative_dev_service'] as service,
      min("timestamp") as data_start,
      max("timestamp") as data_end,
      sum(amount * "timeprecision") AS service_usage_memory_byte_seconds
    FROM {| dataSourceTableName .Report.Inputs.KnativeServiceMemoryUsageDataSource |}
    WHERE "timestamp" >= timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart | prestoTimestamp |}'
    AND "timestamp" < timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}'
    GROUP BY labels['namespace'],labels['label_serving_knative_dev_service']

6.3.3. 为 Knative Serving metering 应用查询

您可以使用以下命令查询 ReportQuery： 

$ oc apply -f <query-name>.yaml

示例

$ oc apply -f knative-service-memory-usage.yaml

6.4. Knative Serving 的 metering 报告

您可以通过创建 Report 资源来针对 Knative Serving 运行 metering 报告。在您运行报告前，您必须修改 Report 资源中的输入参数，以指定报告周期的开始和结束日期。

yaml 文件

apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: knative-service-cpu-usage
spec:
  reportingStart: '2019-06-01T00:00:00Z' 1
  reportingEnd: '2019-06-30T23:59:59Z' 2
  query: knative-service-cpu-usage 3
runImmediately: true

1
报告的开始日期，格式为 ISO 8601 。
2
报告的结束日期，格式为 ISO 8601。
3
用于 CPU 用量报告的 knative-service-cpu-usage，或用于内存用量报告的 knative-service-memory-usage 。

6.4.1. 运行 metering 报告

提供输入参数后，您可以使用以下命令运行报告： 

$ oc apply -f <report-name>.yml

然后可以查看以下示例中显示的报告： 

$ kubectl get report

NAME                        QUERY                       SCHEDULE   RUNNING    FAILED   LAST REPORT TIME       AGE
knative-service-cpu-usage   knative-service-cpu-usage              Finished            2019-06-30T23:59:59Z   10h

第 7 章 使用 OpenShift Serverless 的集群日志记录

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

7.1. 关于集群日志记录

OpenShift Container Platform 集群管理员可以使用一些 CLI 命令和 OpenShift Container Platform Web 控制台安装 Elasticsearch Operator 和 Cluster Logging Operator，以此部署集群日志记录。安装 Operator 后，可创建集群日志记录自定义资源 (CR) 以调度集群日志记录 pod 和支持集群日志记录所需的其他资源。Operator 负责部署、升级和维护集群日志记录。

您可以通过修改集群日志记录自定义资源 (CR)（名为 instance）来配置集群日志记录。CR 定义包括日志记录堆栈的所有组件在内的完整集群日志记录部署，以收集、存储和视觉化日志。Cluster Logging Operator 监控 ClusterLogging 自定义资源并相应地调整日志记录部署。

管理员和应用程序开发人员可以查看他们具有查看访问权限的项目的日志。

7.2. 关于部署和配置集群日志记录

OpenShift Container Platform 集群日志记录已设计为可搭配默认配置使用，该配置针对中小型 OpenShift Container Platform 集群进行了调优。

以下安装说明包括一个示例集群日志记录自定义资源 (CR)，您可以用它来创建集群日志记录实例并配置集群日志记录部署。

如果要使用默认集群日志记录安装，可直接使用示例 CR。

如果要自定义部署，请根据需要对示例 CR 进行更改。下文介绍了在安装集群日志记录实例或安装后修改时可以进行的配置。请参阅“配置”部分来了解有关使用各个组件的更多信息，包括可以在集群日志记录自定义资源之外进行的修改。

7.2.1. 配置和调优集群日志记录

您可以通过修改 openshift-logging 项目中部署的集群日志记录自定义资源来配置集群日志记录环境。

您可以在安装时或安装后修改以下任何组件：

内存和 CPU
您可以使用有效的内存和 CPU 值修改 resources 块，以此调整各个组件的 CPU 和内存限值： 
spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu: 1
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
     type: kibana
  curation:
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      type: "curator"
Elasticsearch 存储
您可以使用 storageClass name 和 size 参数，为 Elasticsearch 集群配置持久性存储类和大小。Cluster Logging Operator 基于这些参数为 Elasticsearch 集群中的每个数据节点创建 PersistentVolumeClaim。 
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

本例中指定，集群中的每个数据节点将绑定到请求 200G 的 gp2 存储的 PersistentVolumeClaim。每个主分片将由单个副本支持。

注意

省略 storage 块会导致部署中仅包含临时存储。 

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
Elasticsearch 复制策略

您可以通过设置策略来定义如何在集群中的数据节点之间复制 Elasticsearch 分片：

  • FullRedundancy。各个索引的分片完整复制到每个数据节点上。
  • MultipleRedundancy。各个索引的分片分布到一半数据节点上。
  • SingleRedundancy。各个分片具有单个副本。只要存在至少两个数据节点，日志就能始终可用且可恢复。
  • ZeroRedundancy。所有分片均无副本。如果节点关闭或发生故障， 则可能无法获得日志数据。
Curator 调度
以 cron 格式指定 Curator 的调度。 
  spec:
    curation:
    type: "curator"
    resources:
    curator:
      schedule: "30 3 * * *"

7.2.2. 修改后集群日志记录自定义资源示例

以下是使用前述选项修改的集群日志记录自定义资源的示例。

修改后集群日志记录自定义资源示例

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 2
      resources:
        limits:
          memory: 2Gi
        requests:
          cpu: 200m
          memory: 2Gi
      storage: {}
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/5 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

7.3. 使用集群日志来查找 Knative Serving 组件的日志

流程

  1. 要访问 Kibana UI（Elasticsearch 的可视化工具），请使用以下命令获取 Kibana 路由： 

    $ oc -n openshift-logging get route kibana
  2. 使用路由的 URL 导航到 Kibana 仪表板并登录。
  3. 确保将索引设置为 .all。如果索引未设置为 .all，则只会列出 OpenShift 系统日志。

  4. 您可使用 knative-serving 命名空间来过滤日志。在搜索框中输入 kubernetes.namespace_name:knative-serving 以过滤结果。

    注意

    Knative Serving 默认使用结构化日志记录。您可以通过自定义集群日志记录 Fluentd 设置来启用这些日志的解析。这可使日志更易搜索，并且能够在日志级别进行过滤以快速识别问题。

7.4. 使用集群日志来查找通过 Knative Serving 部署的服务的日志

使用 OpenShift Cluster Logging，应用程序写入控制台的日志将在 Elasticsearch 中收集。以下流程概述了如何使用 Knative Serving 将这些功能应用到所部署的应用程序中。

流程

  1. 使用以下命令查找 Kibana 的 URL： 

    $ oc -n cluster-logging get route kibana`
  2. 在浏览器中输入 URL 以打开 Kibana UI。
  3. 确保将索引设置为 .all。如果索引未设置为 .all，则只会列出 OpenShift 系统日志。

  4. 通过使用服务部署到的 Kubernetes 命名空间来过滤日志。添加过滤条件以识别服务本身：kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{SERVICE_NAME}。

    注意

    除此之外还可使用 /configuration 或 /revision 来过滤。

  5. 您可使用 kubernetes.container_name:<user-container> 来缩小搜索范围，只显示由您的应用程序生成的日志。否则，会显示来自 queue-proxy 的日志。

    注意

    在应用程序中使用基于 JSON 的结构化日志记录，以便在生产环境中快速过滤这些日志。

第 8 章 配置 Knative Serving 自动扩展

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

OpenShift Serverless 通过在 OpenShift Container Platform 集群中启用 Knative Serving 自动扩展系统来提供 Pod 自动扩展功能，包括将不活跃 Pod 缩减为零。

要针对 Knative Serving 启用自动扩展，您必须在修订模板中配置并发和扩展范围。

注意

修订模板中设置的任何限值或目标均是针对应用程序的单个实例测得。例如：将 target 注解设置为 50 将对扩展应用程序的自动扩展器进行配置，使每个实例每次将可处理 50 个请求。

8.1. 为 Knative Serving 自动扩展配置并发请求

通过在修订模板中添加 target 注解或 containerConcurrency 字段，可指定应用程序（修订容器）的每个实例应处理的并发请求数。

以下是修订模板中使用的 target 示例： 

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: 50
    spec:
      containers:
      - image: myimage

以下是修订模板中使用的 containerConcurrency 示例： 

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
    spec:
      containerConcurrency: 100
      containers:
      - image: myimage

为 target 和 containerConcurrency 添加值将以并发请求的 target 数为目标，但对请求的 containerConcurrency 数施加一个硬性限制。

例如，如果将 target 值设定为 50，将 containerConcurrency 值设定为 100，则目标请求数将为 50，硬性限制数为 100。

如果 containerConcurrency 值小于 target 值，则 target 值将会降级，因为不需要将目标设定为超过实际处理量的请求数。

注意

只有在明确需要限制给定时间到达应用程序的请求数时才应使用 containerConcurrency。只有在应用程序需要强制限制并发时才建议使用 containerConcurrency。

8.1.1. 使用目标注解配置并发请求

并发请求数的默认目标值为 100，但您可通过在修订模板中添加或修改 autoscaling.knative.dev/target 注解值来覆盖该值。

下面是如何在修订模板中使用该注解将目标设置为 50 的示例。 

autoscaling.knative.dev/target: 50

8.1.2. 使用 containerConcurrency 字段配置并发请求

containerConcurrency 字段可对处理的并发请求数设置硬性限制。 

containerConcurrency: 0 | 1 | 2-N
0
并发请求数不限。
1
保证修订容器的给定实例一次只处理一个请求。
2 或以上
将并发请求数限制为该值。
注意

如果无 target 注解，则自动扩展会被配置为 target 值与 containerConcurrency 值相等。

8.2. 配置扩展范围 Knative Serving 自动扩展

minScale 和 maxScale 注解可用于配置可服务于应用程序的最小和最大 Pod 数。这些注解可用于防止冷启动或辅助控制计算成本。

minScale
如果未设置 minScale 注解，Pod 会缩减至 0（如果对 ConfigMap 启用缩减至 0 失败，则为 1）。
maxScale
如果未设置 maxScale 注解，则创建的 Pod 数将无上限。

minScale 和 maxScale 可在修订模板中配置如下： 

spec:
  template:
    metadata:
      autoscaling.knative.dev/minScale: "2"
      autoscaling.knative.dev/maxScale: "10"

在修订模板中使用这些注解会将此配置传播至 PodAutoscaler 对象。

注意

这些注解适用于修订版本的整个生命周期。即使修订版本未被任何路由引用，仍将提供由 minScale 指定的最小 Pod 计数。请记住，不可路由的修订版本可能会收集到回收箱，以便 Knative 回收资源。

第 9 章 开始使用 Knative Client

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

Knative Client (kn) 是 Knative 命令行界面 (CLI)。CLI 会提供管理应用程序的命令，以及较低级别的工具与 OpenShift Container Platform 组件交互。借助 kn，您可以从终端创建应用程序并管理 OpenShift Container Platform 项目。

9.1. 开始前

Knative Client 本身没有登录机制。要登录至集群，必须安装 oc CLI 并使用 oc 进行登录。

oc CLI 的安装选项会因您的操作系统而异。有关为您的操作系统安装 oc CLI 并使用 oc 登录的更多信息，请参阅 CLI 启动文档 。

9.2. 安装 Knative Client

9.2.1. 使用 OpenShift Container Platform web 控制台安装 kn CLI

安装 OpenShift Serverless Operator 后，您会在 OpenShift Container Platform web 控制台的 Command Line Tools 页中看到下载用于 Linux 、macOS 和 Windows 的 kn CLI 的链接。

您也可以使用以下方法进入 Command Line Tools 页： 点 question circle 图标 （web 控制台右上角）并在下拉菜单中选择 Command Line Tools。

流程

  1. 从 Command Line Tools 页下载 kn CLI。

  2. 解包存档： 

    $ tar -xf <file>
  3. 将 kn 二进制文件迁移至 PATH 上的目录中。

  4. 要查看路径，请运行： 

    $ echo $PATH
    注意

    如果不使用 RHEL 或 Fedora，请确保将 libc 安装在库路径的目录中。如果 libc 不可用，您在运行 CLI 命令时可能会看到以下错误： 

    $ kn: No such file or directory

9.2.2. 使用 RPM 为 Linux 安装 kn CLI

对于 Red Hat Enterprise Linux (RHEL)，如果您的红帽帐户上已有活跃的 OpenShift Container Platform 订阅，则可将 kn 安装为 RPM。

流程

  • 使用以下命令来安装 kn： 
# subscription-manager register
# subscription-manager refresh
# subscription-manager attach --pool=<pool_id> 1
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
# yum install openshift-serverless-clients
1
活跃的 OpenShift Container Platform 订阅的池 ID

9.2.3. 为 Linux 安装 kn CLI

对于 Linux 系统，您可以直接将 CLI 下载为 tar.gz 存档。

流程

  1. 下载 CLI。

  2. 解包存档： 

    $ tar -xf <file>
  3. 将 kn 二进制文件迁移至 PATH 上的目录中。

  4. 要查看路径，请运行： 

    $ echo $PATH
    注意

    如果不使用 RHEL 或 Fedora，请确保将 libc 安装在库路径的目录中。如果 libc 不可用，您在运行 CLI 命令时可能会看到以下错误： 

    $ kn: No such file or directory

9.2.4. 为 macOS 安装 kn CLI

用于 macOS 的 kn 以 tar.gz 存档形式提供。

流程

  1. 下载 CLI。
  2. 解包和解压存档。
  3. 将 kn 二进制文件迁移至 PATH 上的目录中。

  4. 要查看 PATH，请打开终端窗口并运行： 

    $ echo $PATH

9.2.5. 为 Windows 安装 kn CLI

用于 Windows 的 CLI 以 zip 存档形式提供。

流程

  1. 下载 CLI。
  2. 使用 ZIP 程序解压存档。
  3. 将 kn 二进制文件迁移至 PATH 上的目录中。

  4. 要查看您的 PATH，请打开命令提示并运行以下命令： 

    C:\> path

9.3. 使用 Knative Client 的基本工作流

使用该基本工作流在服务上创建、读取、更新、删除 (CRUD) 操作。以下示例部署一个简单的 Hello World 服务，该服务可读取环境变量 TARGET 并打印其输出。

流程

  1. 通过一个镜像，在 default 命名空间内创建一个服务。 

    $ kn service create hello --image gcr.io/knative-samples/helloworld-go --env TARGET=Knative
Creating service 'hello' in namespace 'default':

  0.085s The Route is still working to reflect the latest desired specification.
  0.101s Configuration "hello" is waiting for a Revision to become ready.
 11.590s ...
 11.650s Ingress has not yet been reconciled.
 11.726s Ready to serve.

Service 'hello' created with latest revision 'hello-gsdks-1' and URL:
http://hello.default.apps-crc.testing

  2. 列出该服务。 

    $ kn service list
NAME    URL                                     LATEST          AGE     CONDITIONS   READY   REASON
hello   http://hello.default.apps-crc.testing   hello-gsdks-1   8m35s   3 OK / 3     True

  3. 使用 curl 服务端点命令检查该服务是否正在工作： 

    $ curl http://hello.default.apps-crc.testing

Hello Knative!

  4. 更新该服务。 

    $ kn service update hello --env TARGET=Kn
Updating Service 'hello' in namespace 'default':

 10.136s Traffic is not yet migrated to the latest revision.
 10.175s Ingress has not yet been reconciled.
 10.348s Ready to serve.

Service 'hello' updated with latest revision 'hello-dghll-2' and URL:
http://hello.default.apps-crc.testing

    现在，该服务的环境变量 TARGET 设置为 Kn。

  5. 描述该服务。 

    $ kn service describe hello
Name:       hello
Namespace:  default
Age:        13m
URL:        http://hello.default.apps-crc.testing
Address:    http://hello.default.svc.cluster.local

Revisions:
  100%  @latest (hello-dghll-2) [2] (1m)
        Image:  gcr.io/knative-samples/helloworld-go (pinned to 5ea96b)

Conditions:
  OK TYPE                   AGE REASON
  ++ Ready                   1m
  ++ ConfigurationsReady     1m
  ++ RoutesReady             1m

  6. 删除该服务。 

    $ kn service delete hello
Service 'hello' successfully deleted in namespace 'default'.

    然后您可使用 list 命令来验证 hello 服务是否已被删除。 

    $ kn service list hello
No services found.

9.4. 使用 Knative Client 自动扩展工作流

您可使用 kn 修改 Knative 服务来访问自动扩展功能，而无需直接编辑 YAML 文件。

使用带有适当标志的 service create 和 service update 命令来配置自动扩展行为。

标志描述

--concurrency-limit int

单个副本处理的并发请求的硬性限制。

--concurrency-target int

根据传入请求的并发数量建议扩展时间。默认为 --concurrency-limit。

--max-scale int

最大副本数。

--min-scale int

最小副本数。

9.5. 使用 Knative Client 进行流量分割

kn 可帮助您控制哪些修订版本可获取您的 Knative 服务上的路由流量。

Knative 服务支持流量映射，可将服务的修订版本映射到流量的分配部分。它提供了为特定修订版本创建唯一 URL 的选项，且能够为最新修订版本分配流量。

每次更新服务配置时，都会创建一个新修订版本，服务路由默认会将所有流量指向最新可用的修订版本。

您可通过定义哪个修订版本可获得部分流量来更改此行为。

流程

  • 使用带有 --traffic 标志的 kn service update 命令来更新流量。
注意

--traffic RevisionName=Percent 使用以下语法：

  • --traffic 标志需要用等号 (=) 分隔的两个值。
  • RevisionName 字符串表示修订版本的名称。
  • Percent 整数表示分配给修订版本的流量部分。
  • 将标识符 @latest 用于 RevisionName，以表示服务的最新的可用修订版本。此标识符仅可与 --traffic 标志一起使用一次。
  • 如果 service update 命令更新该服务的配置值和流量标志，则 @latest 引用将指向更新应用到的所创建修订版本。
  • --traffic 标志可多次指定，且仅在所有标志的 Percent 值总和达到 100 时才有效。
注意

例如，要在放置所有流量前将 10％ 的流量路由至您的新修订版本，请使用以下命令： 

$ kn service update svc --traffic @latest=10 --traffic svc-vwxyz=90

9.5.1. 分配标签修订

服务流量块中的标签会创建自定义 URL，指向引用的修订版本。用户可为服务的可用修订版本定义唯一标签，该标签通过使用 http(s)://TAG-SERVICE.DOMAIN 格式创建自定义 URL。

给定标签对于该服务的流量块来说必须唯一。kn 作为 kn service update 命令的一部分，支持为服务修订版本分配和取消分配自定义标签。

注意

如果您为特定修订版本分配了标签，用户便可通过 --traffic 标志中作为 --traffic Tag=Percent 的标签来引用修订版本。

流程

  • 使用以下命令： 

    $ kn service update svc --tag @latest=candidate --tag svc-vwxyz=current
注意

--tag RevisionName=Tag 使用以下语法：

  • --tag 标志需要两个以 = 分隔的值。
  • RevisionName 字符串表示 Revision 的名称。
  • Tag 字符串表示要为此修订版本提供的自定义标签。
  • 将标识符 @latest 用于 RevisionName，以表示服务的最新的可用修订版本。此标识符仅可与 --tag 标志一起使用一次。
  • 如果 service update 命令更新该服务的配置值（以及标签标志），则 @latest 引用将在应用更新后指向所创建修订版本。
  • --tag 标志可多次指定。
  • --tag 标志可为同一修订版本分配不同标签。

9.5.2. 取消分配标签修订版本

已分配至流量块中修订版本的标签可取消分配。取消分配标签将会移除自定义 URL。

注意

如果修订版本未标记，也没有为其分配流量，则会从流量块中完全移除该修订版本。

流程

  • 用户可以使用 kn service update 命令为修订版本取消分配标签。 

    $ kn service update svc --untag candidate
注意

--untag Tag 使用以下语法：

  • --untag 标志需要一个值。
  • tag 字符串表示服务流量块中的唯一标签需要取消分配。这也会移除对应的自定义 URL。
  • --untag 标志可多次指定。

9.5.3. 流量标志操作优先级

所有流量相关标志均可使用一条 kn service update 命令指定。kn 定义这些标志的优先级。不考虑使用命令时指定的标志顺序。

通过 kn 评估标志时，标志的优先级如下：

  1. --untag：带有此标志的所有引用修订版本均将从流量块中移除。
  2. --tag：修订版本将按照流量块中的指定进行标记。
  3. --traffic：为引用的修订版本分配一部分流量分割。

9.5.4. 流量分割标志

kn 作为 kn service update 命令的一部分，支持在服务的流量块上进行流量操作。

下表显示流量分割标志、值格式和标志执行的操作汇总。“重复”列表示在 kn service update 命令中可否重复标志特定值。

标志值操作重复

--traffic

RevisionName=Percent

为 RevisionName 提供 Percent 的流量

是

--traffic

Tag=Percent

为具有 Tag 的修订版本提供 Percent 的流量

是

--traffic

@latest=Percent

为最新可用的修订版本提供 Percent 的流量

否

--tag

RevisionName=Tag

为 RevisionName 提供 Tag

是

--tag

@latest=Tag

为最新可用的修订版本提供 Tag

否

--untag

Tag

从修订版本中移除 Tag

是

第 10 章 OpenShift Serverless 发行注记

重要

您正在查看已不再被支持的 Red Hat OpenShift Serverless 发行版本的文档。目前，OpenShift Container Platform 4.3 及更新的版本支持 Red Hat OpenShift Serverless。

如需了解 OpenShift Serverless 功能概述，请参阅了解 OpenShift Serverless。

10.1. 获取支持

如果您在执行本文档所述的某个流程时遇到问题，请访问客户门户网站以获得技术预览功能的相关支持信息。

10.2. Red Hat OpenShift Serverless 技术预览 1.4.0 发行注记

重要

OpenShift Serverless 1.4.0 包含一个错误的所有有者引用，可导致 Kubernetes 模板收集器错误地删除整个 Knative control plane，包括所有服务。您必须安装 OpenShift Serverless 1.4.1 来解决这个问题。

10.2.1. 新功能

  • OpenShift Serverless 1.4.0 包括在 OpenShift Container Platform 4.2 及更新的版本中。
  • OpenShift Serverless 已更新为使用 Knative Serving 0.11.1。
  • OpenShift Serverless 已更新为使用 Knative Client（kn CLI）0.11.0。
  • OpenShift Serverless 已更新为使用 Knative Serving 0.11.1。
  • kn CLI 现在可以通过 OpenShift Container Platform web 控制台中的 Command Line Tools 页面下载。

  • 本发行版本中的 KnativeServing 对象的 API 组已从 service.knative.dev 改为 operator.knative.dev。您需要调整所有依赖旧 API 组的脚本或应用程序，以使用新的 API 组。OpenShift Serverless 安装说明已更新为使用新的 API 组。

    当从 OpenShift Serverless 1.3.0 升级到 1.4.0 时，OpenShift Serverless Operator 会在新 API 组中创建一个 KnativeServing 自定义资源 (CR) 。此 CR 是在 OpenShift Serverless 1.3.0 中使用的旧组中的 KnativeServing CR 的一个镜像（mirror）。

    如果需要临时使用旧的组，您可以像以前一样使用旧的 CR。但是，这个 CR 已被弃用，最终会被删除。

    在更新了对新 API 组的引用后，您可以删除任何旧的 CR 版本，并使用新部署的 KnativeServing CR。为了安全地这样做而无需停机，请使用以下方法从新部署的 KnativeServing CR 中删除所有者引用 ： 

     $ oc edit knativeserving.operator.knative.dev knative-serving -n knative-serving

    删除所有者引用后，您可以安全地删除任何旧的 CR 版本，然后开始使用新的 CR。

    重要

    如果之前的 CR 版本存在，OpenShift Serverless Operator 将覆盖对新 CR 的更改。在旧的 CR 仍处于活跃状态时，需要对该 CR 进行所有更改。

10.2.2. 修复的问题

  • 从一个不是 knative-serving-ingress Service Mesh 一部分的命名空间连接到私有的、集群本地的 Knative Service 会导致 i/o timeout 错误。这个问题现已解决。
  • OpenShift Container Platform 4.3 中删除了 container_name 和 pod_name 指标标签。文档已更新，以使用新的容器和 pod 指标标签。如果在 OpenShift Container Platform 4.3 或更高版本中使用 Serverless metering ，您必须根据 Serverless metering 当前版本的文档内容更新 Prometheus 查询。

10.2.3. 已知问题

  • 因为迁移到一个新的 API 组，通过非限定格式使用 oc 命令中的 KnativeServing 将无法工作。例如，这个命令将无法正常工作： 

    $ oc get knativeserving -n knative-serving

    改为使用显式完全限定格式。例如： 

    $ oc get knativeserving.operator.knative.dev -n knative-serving
  • OpenShift Container Platform 从零延迟扩展，会在创建 pod 时有大约 10 秒的延迟。这是当前 OpenShift Container Platform 的一个限制。

10.3. Red Hat OpenShift Serverless 技术预览 1.3.0 发行注记

10.3.1. 新功能

  • OpenShift Serverless 已更新为使用 Knative Serving 0.10.1。
  • OpenShift Serverless 已更新为使用 Knative Client（kn CLI）0.10.0。
  • OpenShift Serverless 1.3.0 包括在 OpenShift Container Platform 4.2 及更新的版本中。

10.3.2. 修复的问题

  • 修复了导致 Routes 带有错误的跨命名空间的 OwnerReferences 的程序错误。

10.3.3. 已知问题

  • 从一个不是 knative-serving-ingress Service Mesh 一部分的命名空间连接到私有的集群本地 Knative Service 会导致 i/o timeout 错误。

10.4. Red Hat OpenShift Serverless 技术预览 1.2.0 发行注记

10.4.1. 新功能

  • OpenShift Serverless 已更新为使用 Knative­ing 0.9.0。
  • OpenShift Serverless 已更新为使用 Knative Client（kn CLI）0.9.0。
  • OpenShift Container Platform 4.2 上的 OpenShift Serverless 现在使用 Operator Lifecycle Manager (OLM) 依赖性解析机制来自动安装 ServiceMesh Operator。还为用户安装和管理了所需的 ServiceMeshControlPlane 和 ServiceMeshMemberRoll。
  • 对 KnativeServing 资源的访问现在仅限于 cluster-admin 角色，以防止其他用户阻塞资源。只有 cluster-admin 角色可以创建 KnativeServing CR。
  • OpenShift Serverless Operator 现在可以通过在 OperatorHub 中搜索 "Knative" 找到。
  • OpenShift Container Platform Web 控制台现在显示 KnativeServing 资源的状态条件。

  • 在 1.2.0 版本中，OpenShift Serverless Operator 检查命名空间的网络策略。

    如果不存在网络策略，Operator 会自动创建一个广泛开放的策略，以确保命名空间和 OpenShift 路由可以接收网络流量。

    如果存在网络策略，OpenShift Serverless 将不会创建新策略。Operator 期望用户根据自己的应用程序需要，继续管理自己的网络策略。例如，用户必须设置策略，允许命名空间可以接收网络数据，并在将命名空间添加到 ServiceMeshMemberRoll 后仍允许使用 OpenShift 路由。

10.4.2. 修复的问题

  • 在以前的版本中，在不同命名空间中使用相同的服务或路由可导致服务无法正常工作，并导致 OpenShift Container Platform 路由被覆盖。这个问题已被解决。
  • 在以前的版本中，不同的流量分割目标都需要一个强制标签（tag）。现在，一个流量分隔可以使用 untagged 的流量目标定义。
  • 在 OpenShift Serverless Operator 版本 1.1.0 中创建的，已存在的公共可见的 Knative 服务和路由 无法更新为只在集群范围内可见。这个问题现已解决。
  • Unknown Uninitialized : Waiting for VirtualService 错误已被修复。
  • 当集群长时间运行时，Knative 服务不再会返回 503 状态代码。

10.4.3. 已知问题

  • 使用 OLM 在比 4.2.4 更老的 OpenShift Container Platform 版本上安装 OpenShift Serverless Operator 可能会错误地使用依赖软件包的社区版本。作为临时解决方案，在 4.2.4 之前的 OpenShift Container Platform 版本中，在安装 OpenShift Serverless Operator 前，明确安装红帽提供的 Elastic Search 、Jaeger 、Kiali 和 ServiceMesh Operators 版本。

  • 如果您要将 OpenShift Server 从1.1.0 升级到1.2.0，并且已设置了一个 ServiceMeshControlPlane 和 ServiceMeshMemberRoll 与 Knative 实例一同工作，则必须从 istio-system 的 ServiceMeshMemberRoll 中删除 knative-serving 命名空间以及包含 Knative Services 的其他所有命名空间。

    如果其他应用程序不需要，您还可以从命名空间中完全删除 ServiceMeshControlPlane。

    升级开始后，现有服务会象以前一样继续工作，但新服务将永远无法就绪。一旦通过从 ServiceMeshMemberRoll 中删除 knative-serving 以及任何其他相关的命名来取消阻塞发行后，所有活跃的服务都会有一个短暂的中断。这会自行修复。请确定从原始 ServiceMeshMemberRoll 中删除所有包含 Knative Services 的命名空间。

  • gRPC 和 HTTP2 不适用于路由。这是 OpenShift 路由的一个已知的局限性。

10.5. Red Hat OpenShift Serverless 技术预览 1.1.0 发行注记

10.5.1. 新功能

  • OpenShift Serverless 已更新为使用 Knative Serving 0.8.1。
  • 现在，增强的 Operator 元数据包括了有关支持状态和到官方安装文档的链接的更多信息。
  • 现在，一个开发者预览版本的 Knative Eventing 可以与 OpenShift Serverless 一起使用，但这不包括在 OpenShift Serverless Operator 中，且目前还不支持它作为这个技术预览的一部分。如需更多信息，请参阅 OpenShift Container Platform 上的 Knative Eventing 。

10.5.2. 修复的问题

  • 非项目管理员的用户在使用 OpenShift Serverless 时会看到以下出错信息： 

    revisions.serving.knative.dev: User "sounds" cannot list resource "revisions

    现在，增加了新的 RBAC 规则，从而解决了这个问题。

  • 一个竞争条件使得 Istio sidecar 注入无法正常工作。Istio 没有考虑到在创建 Pod 时 knative-serving 命名空间需要存在于 ServiceMeshMemberRoll 中。Istio 现在会等待来自 ServiceMeshMemberRoll 的状态信息，从而解决了这个问题。

10.5.3. 已知问题

  • 用户在等待新创建的命名空间中的服务就绪时可能会看到 Unknown Uninitialized : Waiting for VirtualService to be ready 错误。这可能会持续几分钟。如果用户允许在创建命名空间和在命名空间中创建服务间有足够的时间（大约一分钟），则可能会避免这个错误。
  • 已存在的公共可见的 Knative 服务和路由无法更新为只在集群范围内可见。如果需要 Knative 服务和路由只在集群范围内可见，则需要在创建这些资源时配置。
  • 当集群长时间运行时，Knative 服务会返回 503 状态代码。Knative Serving Pod 不显示任何错误。重启 istio-pilot Pod 可临时解决这一问题。
  • gRPC 和 HTTP2 不适用于路由。这是 OpenShift 路由的一个已知的局限性。

10.6. Red Hat OpenShift Serverless 技术预览 1.0.0 发行注记

10.6.1. 新功能

该版本 OpenShift Serverless 引入了 OpenShift Serverless Operator，它支持 Knative Serving 0.7.1，并针对 OpenShift Service Mesh 1.0 进行了测试。

10.6.2. 已知问题

OpenShift Serverless 当前存在以下局限性：

  • Knative Serving Operator 需等待在 ServiceMeshMemberRoll 中包含了 knative-serving 命名空间。建议在安装过程中先创建 knative-serving 命名空间，再安装该 Operator。在创建 Knative Serving Pod 时，Istio 认为 knative-serving 命名空间不在 ServiceMeshMemberRoll 中。因此，不会注入 sidecar。
  • 当集群长时间运行时，Knative 服务会返回 503 状态代码。Knative Serving Pod 不显示任何错误。重启 istio-pilot Pod 可临时解决这一问题。
  • gRPC 和 HTTP2 不适用于路由。这是 OpenShift 路由的一个已知的局限性。

10.7. 其它资源

OpenShift Serverless 基于开源的 Knative 项目。

注意

在 OpenShift Container Platform 中，Knative Eventing 当前还是一个开发者预览功能。请参阅上游的 Knative Eventing on OpenShift Container Platform 文档。

法律通告

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.