第 6 章 管理

6.1. 全局配置

OpenShift Serverless Operator 管理 Knative 安装的全局配置,包括将 KnativeServingKnativeEventing 自定义资源的值传播到系统配置映射。任何手动应用的配置映射更新都会被 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 的默认频道实现。您可以为整个集群或一个或多个命名空间指定默认频道实现。目前支持 InMemoryChannelKafkaChannel 频道类型。

先决条件

  • 在 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. 配置默认代理支持频道

如果您使用基于频道的代理,您可以将代理的默认后备频道类型设置为 InMemoryChannelKafkaChannel

先决条件

  • 在 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 代理类。目前,支持 MTChannelBasedBrokerKafka 代理类型。

先决条件

  • 在 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. 覆盖系统部署配置

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

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

您可以通过修改 KnativeServing 自定义资源 (CR) 中的 deployments spec 来覆盖某些特定部署的默认配置。目前,支持覆盖默认配置设置,资源副本标签注解、和 nodeSelector 字段,以及探测 的就绪度存活度 字段。

在以下示例中,KnativeServing CR 会覆盖 Webhook 部署,以便:

  • net-kourier-controller就绪度探测 超时设置为 10 秒。
  • 部署指定了 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: net-kourier-controller
    readinessProbes: 1
      - container: controller
        timeoutSeconds: 10
  - 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

1
您可以使用 就绪度和存活度探测 覆盖,覆盖部署容器中探测的所有字段,如 Kubernetes API 中指定的,但与探测处理程序相关的字段除外: execgrpchttpGettcpSocket

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

您可以通过修改 KnativeEventing 自定义资源 (CR) 中的 deployments spec 来覆盖某些特定部署的默认配置。目前,对于 eventing-controllereventing-webhookimc-controller 字段以及探测 的就绪度存活度 字段支持覆盖默认配置设置。

重要

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

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

  • 就绪度探测 超时 eventing-controller 设置为 10 秒。
  • 部署指定了 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
    readinessProbes: 1
      - container: controller
        timeoutSeconds: 10
    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

1
您可以使用 就绪度和存活度探测 覆盖,覆盖部署容器中探测的所有字段,如 Kubernetes API 中指定的,但与探测处理程序相关的字段除外: execgrpchttpGettcpSocket
注意

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) 。

流程

  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 配置。例如,您可能具有以下配置的持久性卷声明:

    注意

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

    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 服务。

注意

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. 其他资源