跳到内容

配置 Knative Serving Operator 自定义资源

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

配置 Knative Serving 版本

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

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

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

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

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

如果未指定 spec.version，Knative Operator 将安装最新可用版本的 Knative Serving。

如果用户指定了无效或不可用的版本，Knative Operator 不会执行任何操作。

Knative Operator 始终包含最新的 3 个发布版本。例如，如果 Knative Operator 的当前版本是 v1.20，则通过 Operator 可用的 Knative Serving 最早版本是 v1.17。

如果 Knative Serving 已经由 Operator 管理，更新 KnativeServing 资源中的 spec.version 字段可以升级或降级 Knative Serving 版本，而无需更改 Operator。

重要

Knative Operator 每次只允许一个次要版本升级或降级。例如，如果当前的 Knative Serving 部署是 v1.18 版本，您必须先升级到 v1.19，然后才能升级到 v1.20。

安装定制的 Knative Serving

有两种模式可用于安装定制的 Knative Serving manifest：覆盖模式 和 追加模式。

如果您使用覆盖模式，在 .spec.manifests 下，您必须定义所有必需的 manifest 来安装 Knative Serving，因为 Operator 不会安装任何默认 manifest。

如果您使用追加模式，在 .spec.additionalManifests 下，您只需定义您的定制 manifest。定制 manifest 在应用默认 manifest 后安装。

覆盖模式

当您想要定制所有 Knative Serving manifest 时，可以使用覆盖模式。

重要

您必须为您的自定义 Knative Serving manifest 指定版本和有效 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 支持链接列表。

重要

manifest URL 的顺序至关重要。将您想要首先应用的 manifest 放在列表的顶部。

此示例安装版本为 $spec_version 的定制 Knative Serving，该版本可在 https://my-serving/serving.yaml 处获得，以及定制的入口插件 net-istio，可在 https://my-net-istio/net-istio.yaml 处获得。

追加模式

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

例如，如果您只想定制一些资源，但仍然想安装默认的 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 manifest，然后安装版本 $spec_version 在 https://my-serving/serving-custom.yaml 处可用的定制资源。

私有仓库和私有秘钥

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

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

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

  • imagePullSecrets：拉取 Knative 容器镜像时使用的 Secret 名称列表。Secret 必须与 Knative Serving Deployment 位于同一命名空间中。有关配置详细信息，请参阅从私有容器仓库部署镜像。

在没有秘钥的情况下，以预定义格式下载镜像

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

在以下示例中

  • 所有镜像都使用自定义标签 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. 使用以下内容定义您的 Operator 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
```

单独下载镜像，无需 secrets

如果您的自定义镜像链接默认未以统一格式定义，则需要将每个链接单独包含在 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

您必须修改 Operator 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

注意

如果容器名称在所有 Deployments、DaemonSets 和 Jobs 中不是唯一的，则可以用父容器名称和斜杠作为容器名称的前缀。例如，istio-webhook/webhook。

下载带秘钥的镜像

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

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

创建此 secret 后，通过追加以下内容来编辑 Operator CR

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

字段 imagePullSecrets 期望一个 secret 列表。您可以添加多个 secret 来访问镜像，如下所示

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

使用 Pod 身份连接到 AWS ECR

使用 AWS ECR 作为 Knative Serving 部署的镜像源需要访问镜像的摘要。这可以通过托管策略 AmazonEC2ContainerRegistryReadOnly 获得，该策略附加到 IAM 角色 knative-serving-controller。然后将此角色附加到 knative-serving 命名空间中的 controller ServiceAccount。这将允许控制器 Pod 从 ECR 检索容器的相关摘要。下面提供了 AWS-CLI 命令和 Terraform 模块的示例，用于执行设置。请根据您的团队使用的相关 IaC 工具进行调整。详细信息可在 AWS 文档中找到。

terraform 示例使用 AWS Provider Terraform 模块将所有部分组合在一起。

module "pod_identity_knative" {
  source  = "terraform-aws-modules/eks-pod-identity/aws"
  version = "~>"2.0.0"

  name = "knative-serving-controller"

  additional_policy_arns = {
    AmazonEC2ContainerRegistryReadOnly = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
  }

  # Pod Identity Associations
  associations = {
    knative-serving-controller = {
      cluster_name    = "some-cluster-name"
      namespace       = "knative-serving"
      service_account = "controller"
    }
  }
}

AWS CLI 示例使用 bash 脚本设置相关基础设施

# Set variables
REGION="<region>"
CLUSTER_NAME="<some-cluster-name>"
ROLE_NAME="knative-serving-controller"
NAMESPACE="knative-serving"
SERVICE_ACCOUNT="controller"

ACCOUNT_ID="$(aws sts get-caller-identity --query 'Account' --output text)"
PARTITION="$(aws sts get-caller-identity --query 'Arn' --output text | cut -d: -f2)"

# Create trust policy for EKS Pod Identity
cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EKSPodIdentityTrust",
      "Effect": "Allow",
      "Principal": { "Service": "pods.eks.amazonaws.com" },
      "Action": [ "sts:AssumeRole", "sts:TagSession" ],
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "${ACCOUNT_ID}" },
        "StringLike": {
          "aws:SourceArn": "arn:${PARTITION}:eks:${REGION}:${ACCOUNT_ID}:cluster/${CLUSTER_NAME}"
        }
      }
    }
  ]
}
EOF

# Create IAM role and attach ECR read-only policy
aws iam create-role \
  --role-name "${ROLE_NAME}" \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name "${ROLE_NAME}" \
  --policy-arn "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"

ROLE_ARN="$(aws iam get-role --role-name "${ROLE_NAME}" --query 'Role.Arn' --output text)"
echo "Created role: ${ROLE_ARN}"

# Ensure the EKS Pod Identity Agent add-on is installed
aws eks create-addon \
  --region "${REGION}" \
  --cluster-name "${CLUSTER_NAME}" \
  --addon-name eks-pod-identity-agent \
  --resolve-conflicts OVERWRITE || true

# Associate the role with the Knative Serving controller ServiceAccount
aws eks create-pod-identity-association \
  --region "${REGION}" \
  --cluster-name "${CLUSTER_NAME}" \
  --namespace "${NAMESPACE}" \
  --service-account "${SERVICE_ACCOUNT}" \
  --role-arn "${ROLE_ARN}"

# Optional: verify association
aws eks list-pod-identity-associations \
  --region "${REGION}" \
  --cluster-name "${CLUSTER_NAME}" \
  --query "associations[?namespace=='${NAMESPACE}' && serviceAccount=='${SERVICE_ACCOUNT}']"

# Cleanup local file
rm -f trust-policy.json

预期输出如下所示

{
    "associations": [
        {
            "clusterName": "<some-cluster-name>",
            "namespace": "knative-serving",
            "serviceAccount": "controller",
            "associationArn": "<ROLE-ARN>",
            "associationId": "<SOME-RANDOM-STRING>"
        },
        ...
}

控制器 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. 创建网关 Service 和 Deployment 实例.

  2. 通过更新 ingress.istio.knative-ingress-gateway spec 以选择新入口网关的标签来更新 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 网关的服务器节的主机和端口。例如，如果您想将 knative-local-gateway 的主机指定为 <test-ip> 并配置端口，使其 number: 443、name: https、protocol: HTTPS 和 target_port: 8443，则应用以下 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：

默认情况下，Kourier 在 ConfigMap kourier-bootstrap 中包含 Envoy 引导配置。spec.ingress.kourier.bootstrap-configmap 字段允许您指定自定义的引导 ConfigMap。

此示例显示 Kourier Gateway 使用 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 spec 来覆盖配置。目前支持 resources、replicas、labels、annotations 和 nodeSelector。

覆盖资源

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

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

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 设置覆盖 Deployment 和 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

覆盖 tolerations

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

覆盖 affinity

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

Pod Disruption Budget (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 共享以达到此目的。了解更多。

× 确定