跳至内容

配置 Knative Serving 运算符自定义资源

您可以修改 KnativeServing CR 以配置 Knative Serving 的不同选项。

配置 Knative Serving 版本

集群管理员可以通过使用 spec.version 字段来安装特定版本的 Knative Serving。

例如，如果您要安装 Knative Serving v1.5，您可以应用以下 KnativeServing 自定义资源

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  version: "1.5"

您也可以运行以下命令以进行等效更改

kn operator install --component serving -v 1.5 -n knative-serving

如果未指定 spec.version，则 Knative 运算符将安装最新版本的 Knative Serving。

如果用户指定无效或不可用的版本，则 Knative 运算符将不执行任何操作。

Knative 运算符始终包含最新 3 个发布版本。例如，如果 Knative 运算符的当前版本为 v1.5，则通过运算符可用的 Knative Serving 的最早版本为 v1.2。

如果 Knative Serving 已经由运算符管理，则更新 KnativeServing 资源中的 spec.version 字段将使您能够升级或降级 Knative Serving 版本，而无需更改运算符。

重要

Knative 运算符一次只允许升级或降级一个次要版本。例如，如果当前 Knative Serving 部署的版本为 v1.3，则您必须升级到 v1.4 才能升级到 v1.5。

安装定制的 Knative Serving

您可以使用两种模式来安装定制的 Knative Serving 清单：覆盖模式和追加模式。

如果您使用的是覆盖模式，则在 .spec.manifests 下，您必须定义安装 Knative Serving 所需的所有清单，因为运算符不会安装任何默认清单。

如果您使用的是追加模式，则在 .spec.additionalManifests 下，您只需要定义您的定制清单。定制清单在应用默认清单后进行安装。

覆盖模式

当您想要自定义所有 Knative Serving 清单时，可以使用覆盖模式。

重要

您必须为您的自定义 Knative Serving 清单指定版本和有效 URL。

例如，如果您要安装 Knative Serving 和 Istio 入口的定制版本，您可以创建一个类似于以下示例的 KnativeServing CR

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  version: $spec_version
  manifests:
  - URL: https://my-serving/serving.yaml
  - URL: https://my-net-istio/net-istio.yaml

您可以通过一个或多个链接提供定制的 Knative Serving，因为 spec.manifests 支持链接列表。

重要

清单 URL 的排序至关重要。将您要首先应用的清单放在列表顶部。

此示例安装版本为 $spec_version 的定制 Knative Serving，它位于 https://my-serving/serving.yaml，以及位于 https://my-net-istio/net-istio.yaml 的定制入口插件 net-istio。

追加模式

您可以使用追加模式在默认清单之外添加您的定制 Knative Serving 清单。

例如，如果您只想自定义一些资源，但仍然想要安装默认的 Knative Serving，您可以创建一个类似于以下示例的 KnativeServing CR

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  version: $spec_version
  additionalManifests:
  - URL: https://my-serving/serving-custom.yaml

此示例安装默认的 Knative Serving 清单，然后安装位于 https://my-serving/serving-custom.yaml 的版本为 $spec_version 的定制资源。

私有仓库和私有密钥

您可以使用运算符 CR 的 spec.registry 部分更改镜像引用以指向私有仓库，或者指定 imagePullSecrets

  • default：此字段为所有 Knative 镜像定义镜像引用模板。格式为 example-registry.io/custom/path/${NAME}:{CUSTOM-TAG}。如果您对所有镜像使用相同的标签，则唯一的区别是镜像名称。${NAME} 是运算符中与容器名称相对应的预定义变量。如果您将私有仓库中的镜像命名为与容器名称一致（activator、autoscaler、controller、webhook、autoscaler-hpa、net-istio-controller 和 queue-proxy），则 default 参数应该足够了。

  • override：从容器名称到完整仓库位置的映射。此部分仅在仓库镜像与通用命名格式不匹配时需要。对于名称与键匹配的容器，将使用值而不是使用 default 计算的镜像名称。如果容器的名称与 override 中的键不匹配，则使用 default 中的模板。

  • imagePullSecrets：拉取 Knative 容器镜像时使用的一系列密钥名称。密钥必须在与 Knative Serving 部署相同的命名空间中创建。有关配置详细信息，请参阅从私有容器仓库部署镜像。

以预定义格式下载没有密钥的镜像

此示例展示了如何在 CR 中使用简化格式 docker.io/knative-images/${NAME}:{CUSTOM-TAG} 定义自定义镜像链接。

在以下示例中

  • 自定义标签 latest 用于所有镜像。
  • 所有镜像链接都可以在不使用密钥的情况下访问。
  • 镜像以 docker.io/knative-images/${NAME}:{CUSTOM-TAG} 的形式推送。

要定义镜像链接

  1. 将镜像推送到以下镜像标签

    容器 Docker 镜像
    activator docker.io/knative-images/activator:latest
    autoscaler docker.io/knative-images/autoscaler:latest
    controller docker.io/knative-images/controller:latest
    webhook docker.io/knative-images/webhook:latest
    autoscaler-hpa docker.io/knative-images/autoscaler-hpa:latest
    net-istio-controller docker.io/knative-images/net-istio-controller:latest
    queue-proxy docker.io/knative-images/queue-proxy:latest

  2. 使用以下内容定义您的运算符 CR

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  registry:
    default: docker.io/knative-images/${NAME}:latest

您也可以运行以下命令以进行等效更改

```bash
kn operator configure images --component serving --imageKey default --imageURL docker.io/knative-images/${NAME}:latest -n knative-serving
```

单独下载没有密钥的镜像

如果您的自定义镜像链接默认情况下未以统一格式定义，则需要单独将每个链接包含在 CR 中。

例如，给定以下镜像

容器 Docker 镜像
activator docker.io/knative-images-repo1/activator:latest
autoscaler docker.io/knative-images-repo2/autoscaler:latest
controller docker.io/knative-images-repo3/controller:latest
webhook docker.io/knative-images-repo4/webhook:latest
autoscaler-hpa docker.io/knative-images-repo5/autoscaler-hpa:latest
net-istio-controller docker.io/knative-images-repo6/prefix-net-istio-controller:latest
net-istio-webhook docker.io/knative-images-repo6/net-istio-webhooko:latest
queue-proxy docker.io/knative-images-repo7/queue-proxy-suffix:latest

您必须修改运算符 CR 以包含完整列表。例如

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  registry:
    override:
      activator: docker.io/knative-images-repo1/activator:latest
      autoscaler: docker.io/knative-images-repo2/autoscaler:latest
      controller: docker.io/knative-images-repo3/controller:latest
      webhook: docker.io/knative-images-repo4/webhook:latest
      autoscaler-hpa: docker.io/knative-images-repo5/autoscaler-hpa:latest
      net-istio-controller/controller: docker.io/knative-images-repo6/prefix-net-istio-controller:latest
      net-istio-webhook/webhook: docker.io/knative-images-repo6/net-istio-webhook:latest
      queue-proxy: docker.io/knative-images-repo7/queue-proxy-suffix:latest

您也可以运行以下命令以进行等效更改

kn operator configure images --component serving --imageKey activator --imageURL docker.io/knative-images-repo1/activator:latest -n knative-serving
kn operator configure images --component serving --imageKey autoscaler --imageURL docker.io/knative-images-repo2/autoscaler:latest -n knative-serving
kn operator configure images --component serving --imageKey controller --imageURL docker.io/knative-images-repo3/controller:latest -n knative-serving
kn operator configure images --component serving --imageKey webhook --imageURL docker.io/knative-images-repo4/webhook:latest -n knative-serving
kn operator configure images --component serving --imageKey autoscaler-hpa --imageURL docker.io/knative-images-repo5/autoscaler-hpa:latest -n knative-serving
kn operator configure images --component serving --deployName net-istio-controller --imageKey controller --imageURL docker.io/knative-images-repo6/prefix-net-istio-controller:latest -n knative-serving
kn operator configure images --component serving --deployName net-istio-webhook --imageKey webhook --imageURL docker.io/knative-images-repo6/net-istio-webhook:latest -n knative-serving
kn operator configure images --component serving --imageKey queue-proxy --imageURL docker.io/knative-images-repo7/queue-proxy-suffix:latest -n knative-serving

注意

如果容器名称在所有部署、守护程序集和作业中不唯一，则可以使用父容器名称和斜杠作为前缀。例如，istio-webhook/webhook。

使用密钥下载镜像

如果您的镜像仓库需要私有密钥才能访问，请包含 imagePullSecrets 属性。

此示例使用名为 regcred 的密钥。如果需要，您必须创建自己的私有密钥

创建此密钥后，通过追加以下内容来编辑运算符 CR

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  registry:
    ...
    imagePullSecrets:
      - name: regcred

imagePullSecrets 字段需要密钥列表。您可以添加多个密钥来访问镜像，如下所示

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  registry:
    ...
    imagePullSecrets:
      - name: regcred
      - name: regcred-2
      ...

用于控制器的 SSL 证书

要启用标记以进行摘要解析，Knative Serving 控制器需要访问容器注册表。 为了允许控制器信任自签名注册表证书，可以使用 Operator 使用 ConfigMap 或 Secret 指定证书。

在 spec.controller-custom-certs 中指定以下字段以选择自定义注册表证书

  • name: ConfigMap 或 Secret 的名称。
  • type: 字符串“ConfigMap”或“Secret”。

如果创建一个名为 testCert 的 ConfigMap，其中包含证书，请更改您的 CR

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  controller-custom-certs:
    name: testCert
    type: ConfigMap

替换默认 Istio 入口网关服务

  1. 创建一个网关服务和部署实例.

  2. 通过更新 ingress.istio.knative-ingress-gateway 规范以选择新入口网关的标签，来更新 Knative 网关

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    istio:
      enabled: true
      knative-ingress-gateway:
        selector:
          istio: ingressgateway

  3. 更新 Istio 入口网关 ConfigMap

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    istio:
      enabled: true
      knative-ingress-gateway:
        selector:
          istio: ingressgateway
  config:
    istio:
      external-gateways: |
        - name: knative-ingress-gateway
          namespace: knative-serving
          service: custom-ingressgateway.custom-ns.svc.cluster.local

    spec.config.istio 中的键格式为

    external-gateways: |
  - name: <gateway_name>
    namespace: <gateway_namespace>
    service: istio-ingressgateway.istio-system.svc.cluster.local

替换入口网关

  1. 创建一个网关.

  2. 更新 Istio 入口网关 ConfigMap

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    istio:
      external-gateways: |
        - name: knative-custom-gateway
          namespace: custom-ns
          service: istio-ingressgateway.istio-system.svc.cluster.local

    spec.config.istio 中的键格式为

    external-gateways: |
  - name: <gateway_name>
    namespace: <gateway_namespace>
    service: istio-ingressgateway.istio-system.svc.cluster.local

集群本地网关配置

更新 spec.ingress.istio.knative-local-gateway 以选择新的集群本地入口网关的标签

默认本地网关名称

如果使用名为 knative-local-gateway 的默认网关，请按照安装 Istio指南使用本地集群网关。

非默认本地网关名称

如果创建自定义本地网关，其名称不是 knative-local-gateway，请更新 config.istio 和 knative-local-gateway 选择器

此示例显示了 istio-system 命名空间中的服务和部署 knative-local-gateway，带有标签 custom: custom-local-gw

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    istio:
      enabled: true
      knative-local-gateway:
        selector:
          custom: custom-local-gateway
  config:
    istio:
      local-gateways: |
        - name: knative-local-gateway
          namespace: knative-serving
          service: custom-local-gateway.istio-system.svc.cluster.local

Istio 网关的服务器配置

可以利用 KnativeServing CR 来配置 knative-local-gateway 或 knative-ingress-gateway 网关的服务器节的 host 和端口。例如，希望将 host 指定为 <test-ip> 并且使用 number: 443、name: https、protocol: HTTPS 和 target_port: 8443 为 knative-local-gateway 配置端口，请应用以下 yaml 内容

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    istio:
      enabled: true
      knative-local-gateway:
        servers:
        - port:
            number: 443
            name: https
            protocol: HTTPS
            target_port: 8443
          hosts:
          - <test-ip>
  config:
    istio:
      local-gateways: |
        - name: knative-local-gateway
          namespace: knative-serving
          service: custom-local-gateway.istio-system.svc.cluster.local

为 Kourier 网关自定义 kourier-bootstrap

默认情况下，Kurier 在 ConfigMap kourier-bootstrap 中包含 envoy 启动配置。 spec.ingress.kourier.bootstrap-configmap 字段允许指定自定义启动 ConfigMap。

此示例显示 Kourier 网关使用 my-configmap 作为 envoy 启动配置。

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    network:
      ingress-class: kourier.ingress.networking.knative.dev
  ingress:
    kourier:
      bootstrap-configmap: my-configmap
      enabled: true

高可用性

默认情况下，Knative Serving 运行每个部署的单个实例。 spec.high-availability 字段允许配置 operator 管理的所有部署的副本数量。

以下配置为工作负载指定了 3 个副本数量

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  high-availability:
    replicas: 3

您也可以运行以下命令以进行等效更改

kn operator configure replicas --component serving --replicas 3 -n knative-serving

replicas 字段还会根据 spec.high-availability 配置 HorizontalPodAutoscaler 资源。假设 operator 包含以下 HorizontalPodAutoscaler

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  ...
spec:
  minReplicas: 3
  maxReplicas: 5

如果配置 replicas: 2，它小于 minReplicas，operator 会将 minReplicas 转换为 1。

如果配置 replicas: 6，它大于 maxReplicas，operator 会将 maxReplicas 转换为 maxReplicas + (replicas - minReplicas)，即 8。

覆盖系统部署

如果希望覆盖特定部署的一些配置，可以通过修改 KnativeServing CR 中的 deployments 规范来覆盖配置。目前支持 resources、replicas、labels、annotations 和 nodeSelector。

覆盖资源

KnativeServing CR 能够根据部署配置 Knative 系统容器的系统资源。可以为部署中的所有可用容器配置请求和限制。

例如，以下 KnativeServing CR 为 controller 部署中的容器 controller 配置了 0.3 个 CPU 和 100MB 内存的请求，并设置了 1 个 CPU 和 250MB 内存的硬限制

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  workloads:
  - name: controller
    resources:
    - container: controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi

您也可以运行以下命令以进行等效更改

kn operator configure resources --component serving --deployName controller --container controller --requestCPU 300m --requestMemory 100Mi --limitCPU 1000m --limitMemory 250Mi -n knative-serving

覆盖副本、标签和注释

以下 KnativeServing 资源覆盖 webhook 部署，使其具有 3 个副本、标签 mylabel: foo 和注释 myannotations: bar，而其他系统部署使用 spec.high-availability 具有 2 个副本。

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2
  workloads:
  - name: webhook
    replicas: 3
    labels:
      mylabel: foo
    annotations:
      myannotations: bar

您也可以运行以下命令以进行等效更改

kn operator configure replicas --component serving --replicas 2 -n knative-serving
kn operator configure replicas --component serving --deployName webhook --replicas 3 -n knative-serving
kn operator configure labels --component serving --deployName webhook --key mylabel --value foo -n knative-serving
kn operator configure annotations --component serving --deployName webhook --key myannotations --value bar -n knative-serving

注意

KnativeServing CR 的 label 和 annotation 设置会覆盖部署和 Pod 的 webhook 标签和注释。

覆盖 nodeSelector

以下 KnativeServing CR 覆盖 webhook 部署，使其使用 disktype: hdd nodeSelector

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  workloads:
  - name: webhook
    nodeSelector:
      disktype: hdd

您也可以运行以下命令以进行等效更改

kn operator configure nodeSelectors --component serving --deployName webhook --key disktype --value hdd -n knative-serving

覆盖容忍度

KnativeServing 资源能够覆盖 Knative Serving 部署资源的容忍度。例如，如果希望添加以下容忍度

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

到 activator 部署，需要将 KnativeServing CR 更改为如下所示

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  workloads:
  - name: activator
    tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"

您也可以运行以下命令以进行等效更改

kn operator configure tolerations --component serving --deployName activator --key key1 --operator Equal --value value1 --effect NoSchedule -n knative-serving

覆盖亲和性

KnativeServing 资源能够覆盖 Knative Serving 部署资源的亲和性，包括 nodeAffinity、podAffinity 和 podAntiAffinity。例如，如果希望添加以下 nodeAffinity

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        - key: disktype
          operator: In
          values:
          - ssd

到 activator 部署，需要将 KnativeServing CR 更改为如下所示

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  workloads:
  - name: activator
    affinity:
      nodeAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
            - key: disktype
              operator: In
              values:
              - ssd

覆盖环境变量

KnativeServing 资源能够覆盖或添加 Knative Serving 部署资源中容器的环境变量。例如，如果希望将 controller 部署中的容器 controller 中的环境变量 METRICS_DOMAIN 的值更改为 "knative.dev/my-repo"，需要将 KnativeServing CR 更改为如下所示

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  workloads:
  - name: controller
    env:
    - container: controller
      envVars:
      - name: METRICS_DOMAIN
        value: "knative.dev/my-repo"

您也可以运行以下命令以进行等效更改

kn operator configure envvars --component serving --deployName controller --container controller --name METRICS_DOMAIN --value "knative.dev/my-repo" -n knative-serving

覆盖系统服务

如果希望覆盖特定服务的某些配置，可以使用 CR 中的 spec.services 来覆盖配置。目前支持 labels、annotations 和 selector。

覆盖标签和注释以及选择器

以下 KnativeServing 资源覆盖 webhook 服务，使其具有标签 mylabel: foo、注释 myannotations: bar、选择器 myselector: bar。

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  services:
  - name: webhook
    labels:
      mylabel: foo
    annotations:
      myannotations: bar
    selector:
      myselector: bar

您也可以运行以下命令以进行等效更改

kn operator configure labels --component serving --serviceName webhook --key mylabel --value foo -n knative-serving
kn operator configure annotations --component serving --serviceName webhook --key myannotations --value bar -n knative-serving
kn operator configure selectors --component serving --serviceName webhook --key myselector --value bar -n knative-serving

覆盖系统 PodDisruptionBudgets

PodDisruptionBudget (PDB) 允许在需要重新安排 Pod 进行维护时，限制对应用程序的干扰。Knative Operator 允许您根据名称配置 Serving 中特定 podDisruptionBudget 资源的 minAvailable。要了解有关资源 podDisruptionBudget 配置的更多信息，请点击此处。例如，如果希望将名为 activator-pdb 的 podDisruptionBudget 的 minAvailable 更改为 70%，则需要将 KnativeServing CR 更改为如下所示

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  podDisruptionBudgets:
  - name: activator-pdb
    minAvailable: 70%

我们使用分析和 Cookie 来了解网站流量。有关您使用我们网站的信息将与 Google 共享，以用于该目的。 了解更多。

× 确定