コンテンツへスキップ

Knative Serving Operatorカスタムリソースの設定

Knative Serving 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 Operatorは利用可能な最新バージョンのKnative Servingをインストールします。

無効または利用できないバージョンをユーザーが指定した場合、Knative Operatorは何もしません。

Knative Operatorには常に最新の3つのリリースバージョンが含まれています。例えば、Knative Operatorの現在のバージョンがv1.5の場合、Operatorを通じて利用可能なKnative Servingの最も古いバージョンはv1.2です。

Knative Servingが既にOperatorによって管理されている場合、`KnativeServing`リソースの`spec.version`フィールドを更新することで、Operatorを変更する必要なく、Knative Servingのバージョンのアップグレードまたはダウングレードが可能になります。

重要

Knative Operatorは、一度に1つのマイナーリリースバージョンのみのアップグレードまたはダウングレードを許可します。例えば、現在のKnative Servingのデプロイメントバージョンがv1.3の場合、v1.5にアップグレードする前にv1.4にアップグレードする必要があります。

カスタマイズされたKnative Servingのインストール

カスタマイズされたKnative Servingマニフェストをインストールするために使用できる2つのモードがあります。「上書きモード」と「追加モード」です。

上書きモードを使用する場合は、`.spec.manifests`の下に、Knative Servingをインストールするために必要なすべてマニフェストを定義する必要があります。Operatorはデフォルトのマニフェストをインストールしません。

追加モードを使用する場合は、`.spec.additionalManifests`の下に、カスタマイズされたマニフェストのみを定義する必要があります。カスタマイズされたマニフェストは、デフォルトのマニフェストが適用された後にインストールされます。

上書きモード

すべてのKnative Servingマニフェストをカスタマイズする場合、上書きモードを使用できます。

重要

バージョンと、カスタムKnative Servingマニフェストの有効なURLの両方を指定する必要があります。

例えば、Knative ServingとIstio Ingressの両方のカスタマイズされたバージョンをインストールしたい場合は、次の例のような`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

`spec.manifests`はリンクのリストをサポートしているため、カスタマイズされたKnative Servingを1つまたは複数のリンクで利用できるようにできます。

重要

マニフェストURLの順序は重要です。最初に適用したいマニフェストをリストの一番上に配置します。

この例では、`https://my-serving/serving.yaml`で利用可能なバージョン`$spec_version`のカスタマイズされたKnative Servingと、`https://my-net-istio/net-istio.yaml`で利用可能なカスタマイズされたIngressプラグイン`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マニフェストをインストールした後、バージョン`$spec_version`の`https://my-serving/serving-custom.yaml`で利用可能なカスタマイズされたリソースをインストールします。

プライベートリポジトリとプライベートシークレット

Operator 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デプロイメントと同じ名前空間に作成する必要があります。設定の詳細については、プライベートコンテナレジストリからのイメージのデプロイを参照してください。

シークレットなしで、定義済みのフォーマットでイメージをダウンロードする

この例では、簡略化されたフォーマット`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. 次の内容でオペレータ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

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

注記

コンテナ名がすべてのDeployment、DaemonSet、およびJobで一意でない場合は、親コンテナ名とスラッシュをコンテナ名のプレフィックスとして付けることができます。例：istio-webhook/webhook。

シークレットを使用したイメージのダウンロード

イメージリポジトリがアクセスにプライベートシークレットを必要とする場合は、imagePullSecrets属性を含めます。

この例では、regcredという名前のシークレットを使用しています。これらのシークレットが必要な場合は、独自のプライベートシークレットを作成する必要があります。

このシークレットを作成した後、次のコンテンツを追加してOperator 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 Ingress Gatewayサービスの置換

  1. Gateway ServiceとDeploymentインスタンスを作成します。.

  2. 新しいIngress Gatewayのラベルを選択するようにingress.istio.knative-ingress-gateway仕様を更新して、Knative Gatewayを更新します。

    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 Ingress Gateway 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

Ingress Gatewayの置換

  1. Gatewayを作成します。.

  2. Istio Ingress Gateway 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

クラスタローカルゲートウェイの構成

新しいクラスタローカルIngress Gatewayのラベルを選択するように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ゲートウェイのserversスタンザのホストとポートを構成できます。たとえば、ホストを<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ブートストラップのカスタマイズ

デフォルトでは、KourierにはConfigMap kourier-bootstrapにEnvoyブートストラップ構成が含まれています。spec.ingress.kourier.bootstrap-configmapフィールドを使用すると、カスタマイズされたブートストラップConfigMapを指定できます。

この例は、Kourier GatewayがEnvoyブートストラップ構成にmy-configmapを使用することを示しています。

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フィールドを使用すると、オペレーターによって管理されるすべてのデプロイメントのレプリカ数を構成できます。

次の構成は、ワークロードのレプリカ数を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リソースも構成します。オペレーターに次のHorizontalPodAutoscalerが含まれているとします。

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

replicas: 2（minReplicasより少ない）を構成すると、オペレーターはminReplicasを1に変換します。

replicas: 6（maxReplicasより多い）を構成すると、オペレーターはmaxReplicasをmaxReplicas + (replicas - minReplicas)つまり8に変換します。

システムデプロイメントの上書き

特定のデプロイメントの一部の構成を上書きする場合は、KnativeServing CRのdeployments仕様を変更して構成を上書きできます。現在、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

許容値の上書き

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

システムPodDisruptionBudgetの上書き

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と共有されます。詳細はこちら。

× OK