支持控制台（Console）开发人员开始试用联系人

第 6 章 管理

6.1. 全局配置

OpenShift Serverless Operator 管理 Knative 安装的全局配置，包括将 KnativeServing 和 KnativeEventing 自定义资源的值传播到系统配置映射。任何手动应用的配置映射更新都会被 Operator 覆盖。但是，通过修改 Knative 自定义资源，您可以为这些配置映射设置值。

Knative 具有多个配置映射，它们使用前缀 config- 命名。所有 Knative 配置映射都与它们应用到的自定义资源在同一命名空间中创建。例如，如果在 knative-serving 命名空间中创建 KnativeServing 自定义资源，则也会在此命名空间中创建所有 Knative Serving 配置映射。

Knative 自定义资源中的 spec.config 为每个配置映射有一个 <name> 条目，名为 config-<name>，其值为配置映射的 data。

6.1.1. 配置默认频道实施

您可以使用 default-ch-webhook 配置映射来指定 Knative Eventing 的默认频道实现。您可以为整个集群或一个或多个命名空间指定默认频道实现。目前支持 InMemoryChannel 和 KafkaChannel 频道类型。

先决条件

  • 在 OpenShift Container Platform 上具有管理员权限。
  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Eventing。
  • 如果要使用 Kafka 频道作为默认频道实现，还必须在集群中安装 KnativeKafka CR。

流程

  • 修改 KnativeEventing 自定义资源，以添加 default-ch-webhook 配置映射的配置详情： 

    apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  config: 1
    default-ch-webhook: 2
      default-ch-config: |
        clusterDefault: 3
          apiVersion: messaging.knative.dev/v1
          kind: InMemoryChannel
          spec:
            delivery:
              backoffDelay: PT0.5S
              backoffPolicy: exponential
              retry: 5
        namespaceDefaults: 4
          my-namespace:
            apiVersion: messaging.knative.dev/v1beta1
            kind: KafkaChannel
            spec:
              numPartitions: 1
              replicationFactor: 1
    1
    在 spec.config 中，您可以指定您要为修改的配置添加的配置映射。
    2
    default-ch-webhook 配置映射可以用来指定集群的默认频道实施，也可以用于一个或多个命名空间。
    3
    集群范围的默认频道类型配置。在本例中，集群的默认频道实现是 InMemoryChannel。
    4
    命名空间范围的默认频道类型配置。在本例中, my-namespace 命名空间的默认频道实现是 KafkaChannel。
    重要

    配置特定于命名空间的默认设置会覆盖任何集群范围的设置。

6.1.2. 配置默认代理支持频道

如果您使用基于频道的代理，您可以将代理的默认后备频道类型设置为 InMemoryChannel 或 KafkaChannel。

先决条件

  • 在 OpenShift Container Platform 上具有管理员权限。
  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Eventing。
  • 已安装 OpenShift (oc) CLI。
  • 如果要使用 Kafka 频道作为默认后备频道类型，还必须在集群中安装 KnativeKafka CR。

流程

  1. 修改 KnativeEventing 自定义资源(CR)以添加 config-br-default-channel 配置映射的配置详情： 

    apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  config: 1
    config-br-default-channel:
      channel-template-spec: |
        apiVersion: messaging.knative.dev/v1beta1
        kind: KafkaChannel 2
        spec:
          numPartitions: 6 3
          replicationFactor: 3 4
    1
    在 spec.config 中，您可以指定您要为修改的配置添加的配置映射。
    2
    默认后备频道类型配置。在本例中，集群的默认频道实现是 KafkaChannel。
    3
    支持代理的 Kafka 频道的分区数量。
    4
    支持代理的 Kafka 频道的复制因素。

  2. 应用更新的 KnativeEventing CR： 

    $ oc apply -f <filename>

6.1.3. 配置 default 代理类

您可以使用 config-br-defaults 配置映射来指定 Knative Eventing 的 default 代理类设置。您可以为整个集群或一个或多个命名空间指定 default 代理类。目前，支持 MTChannelBasedBroker 和 Kafka 代理类型。

先决条件

  • 在 OpenShift Container Platform 上具有管理员权限。
  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Eventing。
  • 如果要使用 Kafka 代理作为默认代理实现，还必须在集群中安装 KnativeKafka CR。

流程

  • 修改 KnativeEventing 自定义资源，以添加 config-br-defaults 配置映射的配置详情： 

    apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  defaultBrokerClass: Kafka 1
  config: 2
    config-br-defaults: 3
      default-br-config: |
        clusterDefault: 4
          brokerClass: Kafka
          apiVersion: v1
          kind: ConfigMap
          name: kafka-broker-config 5
          namespace: knative-eventing 6
        namespaceDefaults: 7
          my-namespace:
            brokerClass: MTChannelBasedBroker
            apiVersion: v1
            kind: ConfigMap
            name: config-br-default-channel 8
            namespace: knative-eventing 9
...
    1
    Knative Eventing 的 default 代理类。
    2
    在 spec.config 中，您可以指定您要为修改的配置添加的配置映射。
    3
    config-br-defaults 配置映射指定任何没有指定 spec.config 设置或代理类的代理的默认设置。
    4
    集群范围的 default 代理类配置。在本例中，集群的 default 代理类实现是 Kafka。
    5
    kafka-broker-config 配置映射指定 Kafka 代理的默认设置。请参阅 "Additional resources" 部分的"配置 Kafka 代理设置"。
    6
    存在 kafka-broker-config 配置映射的命名空间。
    7
    命名空间范围的 default 代理类配置。在本例中，my-namespace 命名空间的 default 代理类实现是 MTChannelbasedBroker。您可以为多个命名空间指定 default 代理类实现。
    8
    config-br-default-channel 配置映射指定代理的默认后备频道。请参阅"Additional resources"部分的"配置默认代理支持频道"部分。
    9
    config-br-default-channel 配置映射所在的命名空间。
    重要

    配置特定于命名空间的默认设置会覆盖任何集群范围的设置。

其他资源

6.1.4. 启用 scale-to-zero

Knative Serving 为应用程序提供自动扩展功能（或 autoscaling），以满足传入的需求。您可以使用 enable-scale-to-zero spec，为集群中的应用程序全局启用或禁用 scale-to-zero。

先决条件

  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
  • 有集群管理员权限。
  • 使用默认的 Knative Pod Autoscaler。如果使用 Kubernetes Horizontal Pod Autoscaler，则缩减为零功能将不可用。

流程

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

    KnativeServing CR 示例

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

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

6.1.5. 配置 scale-to-zero 宽限期

Knative Serving 为应用程序提供自动缩放为零个 pod。您可以使用 scale-to-zero-grace-period spec 定义上限，Knative 在删除应用程序的最后一个副本前等待 scale-to-zero machinery 原位。

先决条件

  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
  • 有集群管理员权限。
  • 使用默认的 Knative Pod Autoscaler。如果使用 Kubernetes Horizontal Pod Autoscaler，则缩减为零功能将不可用。

流程

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

    KnativeServing CR 示例

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

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

6.1.6. 覆盖系统部署配置

您可以通过修改 KnativeServing 和 KnativeEventing 自定义资源(CR)中的 deployment spec 来覆盖某些特定 部署 的默认配置。

6.1.6.1. 覆盖 Knative Serving 系统部署配置

您可以通过修改 KnativeServing 自定义资源(CR)中的 deployments spec 来覆盖某些特定部署的默认配置。目前，支持覆盖默认配置的字段包括 resources, replicas, labels, annotations, 和 nodeSelector 。

在以下示例中，KnativeServing CR 会覆盖 Webhook 部署，以便：

  • 部署指定了 CPU 和内存资源限制。
  • 部署有 3 个副本。
  • 添加 example-label: label 标签。
  • 添加 example-annotation: 注解。
  • nodeSelector 字段被设置为选择带有 disktype: hdd 标签的节点。
注意

KnativeServing CR 标签和注解设置覆盖部署本身和生成的 Pod 的部署标签和注解。

KnativeServing CR 示例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: ks
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2
  deployments:
  - name: webhook
    resources:
    - container: webhook
      requests:
        cpu: 300m
        memory: 60Mi
      limits:
        cpu: 1000m
        memory: 1000Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

6.1.6.2. 覆盖 Knative Eventing 系统部署配置

您可以通过修改 KnativeEventing 自定义资源(CR)中的 deployments spec 来覆盖某些特定部署的默认配置。目前，对于 eventing-controller、eventing-webhook 和 imc-controller 字段支持覆盖默认配置设置。

重要

replicas spec 无法覆盖使用 Horizontal Pod Autoscaler(HPA)的部署副本数，且不适用于 eventing-webhook 部署。

在以下示例中，KnativeEventing CR 覆盖 eventing-controller 部署，以便：

  • 部署指定了 CPU 和内存资源限制。
  • 部署有 3 个副本。
  • 添加 example-label: label 标签。
  • 添加 example-annotation: 注解。
  • nodeSelector 字段被设置为选择带有 disktype: hdd 标签的节点。

KnativeEventing CR 示例

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  deployments:
  - name: eventing-controller
    resources:
    - container: eventing-controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

注意

KnativeEventing CR 标签和注解设置会覆盖部署本身和生成的 pod 的标签和注解。

6.1.7. 配置 EmptyDir 扩展

emptyDir 卷是创建 pod 时创建的空卷，用来提供临时工作磁盘空间。当为其创建 pod 被删除时，emptyDir 卷会被删除。

kubernetes.podspec-volumes-emptydir 扩展控制 emptyDir 卷是否与 Knative Serving 搭配使用。要使用 emptyDir 卷启用，您必须修改 KnativeServing 自定义资源(CR)使其包含以下 YAML：

KnativeServing CR 示例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    features:
      kubernetes.podspec-volumes-emptydir: enabled
...

6.1.8. HTTPS 重定向全局设置

HTTPS 重定向为传入的 HTTP 请求提供重定向。这些重定向的 HTTP 请求会被加密。您可以通过为 KnativeServing 自定义资源(CR)配置 httpProtocol spec，为集群中的所有服务启用 HTTPS 重定向。

启用 HTTPS 重定向的 KnativeServing CR 示例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    network:
      httpProtocol: "redirected"
...

6.1.9. 为外部路由设置 URL 方案

用于增强安全性，外部路由的 URL 方案默认为 HTTPS。这个方案由 KnativeServing 自定义资源(CR)spec 中的 default-external-scheme 键决定。

默认规格

...
spec:
  config:
    network:
      default-external-scheme: "https"
...

您可以通过修改 default-external-scheme 键来覆盖默认的 spec 以使用 HTTP：

HTTP 覆盖规格

...
spec:
  config:
    network:
      default-external-scheme: "http"
...

6.1.10. 设置 Kourier 网关服务类型

Kourier 网关默认作为 ClusterIP 服务类型公开。此服务类型由 KnativeServing 自定义资源(CR)中的 service-type ingress spec 决定。

默认规格

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

您可以通过修改 service-type spec 来覆盖默认服务类型来使用负载均衡器服务类型：

LoadBalancer 覆盖规格

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

6.1.11. 启用 PVC 支持

有些无服务器应用程序需要持久性数据存储。要做到这一点，您可以为 Knative 服务配置持久性卷声明(PVC)。

重要

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

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

流程

  1. 要启用 Knative Serving 使用 PVC 并写入它们，请修改 KnativeServing 自定义资源(CR)使其包含以下 YAML：

    启用具有写入访问的 PVC

    ...
spec:
  config:
    features:
      "kubernetes.podspec-persistent-volume-claim": enabled
      "kubernetes.podspec-persistent-volume-write": enabled
...

    • kubernetes.podspec-persistent-volume-claim 扩展控制持久性卷(PV)是否可以用于 Knative Serving。
    • kubernetes.podspec-persistent-volume-write 扩展控制 Knative Serving 是否使用写入访问权限。

  2. 要声明 PV，请修改您的服务使其包含 PV 配置。例如，您可能具有以下配置的持久性卷声明：

    注意

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

    PersistentVolumeClaim 配置

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pv-claim
  namespace: my-ns
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ocs-storagecluster-cephfs
  resources:
    requests:
      storage: 1Gi

    在这种情况下，若要声明具有写访问权限的 PV，请修改服务，如下所示：

    Knative 服务 PVC 配置

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  namespace: my-ns
...
spec:
 template:
   spec:
     containers:
         ...
         volumeMounts: 1
           - mountPath: /data
             name: mydata
             readOnly: false
     volumes:
       - name: mydata
         persistentVolumeClaim: 2
           claimName: example-pv-claim
           readOnly: false 3

    1
    卷挂载规格。
    2
    持久性卷声明规格。
    3
    启用只读访问的标记。
    注意

    要在 Knative 服务中成功使用持久性存储，您需要额外的配置，如 Knative 容器用户的用户权限。

6.1.12. 启用 init 容器

Init 容器是 pod 中应用程序容器之前运行的专用容器。它们通常用于为应用程序实施初始化逻辑，其中可能包括运行设置脚本或下载所需的配置。您可以通过修改 KnativeServing 自定义资源(CR)来启用 init 容器用于 Knative 服务。

重要

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

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

注意

Init 容器可能会导致应用程序的启动时间较长，应该谨慎地用于无服务器应用程序，这应该经常被扩展或缩减。

先决条件

  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
  • 有集群管理员权限。

流程

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

    KnativeServing CR 示例

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

6.1.13. tag-to-digest 解析

如果 Knative Serving 控制器可以访问容器 registry，Knative Serving 会在创建服务的修订时将镜像标签解析为摘要。这被称为 tag-to-digest 解析，有助于为部署提供一致性。

要让控制器访问 OpenShift Container Platform 上的容器 registry，您必须创建一个 secret，然后配置控制器自定义证书。您可以通过修改 KnativeServing 自定义资源(CR)中的 controller-custom-certs spec 来配置控制器自定义证书。secret 必须位于与 KnativeServing CR 相同的命名空间中。

如果 KnativeServing CR 中不包含 secret，此设置默认为使用公钥基础架构(PKI)。在使用 PKI 时，集群范围的证书会使用 config-service-sa 配置映射自动注入到 Knative Serving 控制器。OpenShift Serverless Operator 使用集群范围证书填充 config-service-sa 配置映射，并将配置映射作为卷挂载到控制器。

6.1.13.1. 使用 secret 配置 tag-to-digest 解析

如果 controller-custom-certs spec 使用 Secret 类型，secret 将被挂载为 secret 卷。Knative 组件直接使用 secret，假设 secret 具有所需的证书。

先决条件

  • 在 OpenShift Container Platform 上具有集群管理员权限。
  • 您已在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。

流程

  1. 创建 secret：

    示例命令

    $ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>

  2. 配置 KnativeServing 自定义资源(CR)中的 controller-custom-certs 规格以使用 Secret 类型：

    KnativeServing CR 示例

    apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  controller-custom-certs:
    name: custom-secret
    type: Secret

6.1.14. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.