第 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
重要配置特定于命名空间的默认设置会覆盖任何集群范围的设置。
6.1.2. 配置默认代理支持频道
如果您使用基于频道的代理,您可以将代理的默认后备频道类型设置为 InMemoryChannel
或 KafkaChannel
。
先决条件
- 在 OpenShift Container Platform 上具有管理员权限。
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Eventing。
-
已安装 OpenShift (
oc
) CLI。 -
如果要使用 Kafka 频道作为默认后备频道类型,还必须在集群中安装
KnativeKafka
CR。
流程
修改
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
应用更新的
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/。
流程
要启用 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 是否使用写入访问权限。
-
要声明 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
注意要在 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。
流程
创建 secret:
示例命令
$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>
配置
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