OpenShift Container Platform

この VPA CR が管理するワークロードオブジェクトのタイプ。

この VPA CR が管理するワークロードオブジェクトの名前。

モードを Auto または Recreate に設定します。

Auto:VPA は、Pod の作成時にリソース要求を割り当て、要求されるリソースが新規の推奨事項と大きく異なる場合に、それらを終了して既存の Pod を更新します。
Recreate:VPA は、Pod の作成時にリソース要求を割り当て、要求されるリソースが新規の推奨事項と大きく異なる場合に、それらを終了して既存の Pod を更新します。このモードが使用されることはほとんどありません。リソース要求の変更に応じて Pod を必ず再起動させたい場合に限定して使用します。

注記

VPA によってリソースの推奨事項を決定し、推奨リソースを新しい Pod に適用するには、動作中の Pod がプロジェクト内に存在し、実行されている必要があります。

CPU やメモリーなどのワークロードのリソース使用量が安定している場合、VPA はリソースの推奨事項を数分で決定できます。ワークロードのリソース使用量が安定していない場合、VPA は正確な推奨を行うために、さまざまなリソース使用量の間隔でメトリクスを収集する必要があります。

2.5.4.3. Pod 作成時における VPA 推奨の自動適用
リンクのコピー

VPA を使用して、Pod が最初にデプロイされる場合にのみ推奨リソースを適用するには、updateMode が Initial に設定された特定のワークロードオブジェクトの VPA CR を作成します。

次に、VPA の推奨値を使用する必要のあるワークロードオブジェクトに関連付けられた Pod を手動で削除します。Initial モードで、VPA は新しいリソースの推奨内容を確認する際に Pod を削除したり、更新したりしません。

Initial モードの VPA CR の例

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend 
  updatePolicy:
    updateMode: "Initial"

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend


  updatePolicy:
    updateMode: "Initial"

Copy to Clipboard

Toggle word wrap

1: この VPA CR が管理するワークロードオブジェクトのタイプ。
2: この VPA CR が管理するワークロードオブジェクトの名前。
3: モードを Initial に設定します。VPA は、Pod の作成時にリソースを割り当て、Pod の有効期間中はリソースを変更しません。

注記

VPA によって推奨リソースを決定し、推奨事項を新しい Pod に適用するには、動作中の Pod がプロジェクト内に存在し、実行されている必要があります。

VPA から最も正確な推奨事項を取得するには、Pod が実行され、VPA が安定するまで少なくとも 8 日間待機してください。

2.5.4.4. VPA の推奨事項の手動適用
リンクのコピー

CPU およびメモリーの推奨値を判別するためだけに VPA を使用するには、updateMode を Off に設定した特定のワークロードオブジェクトの VPA CR を作成します。

Pod がワークロードオブジェクト用に作成されると、VPA はコンテナーの CPU およびメモリーのニーズを分析し、VPA CR の status フィールドにそれらの推奨事項を記録します。VPA は、新しい推奨リソースを判別する際に Pod を更新しません。

Off モードの VPA CR の例

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend 
  updatePolicy:
    updateMode: "Off"

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend


  updatePolicy:
    updateMode: "Off"

Copy to Clipboard

Toggle word wrap

1: この VPA CR が管理するワークロードオブジェクトのタイプ。
2: この VPA CR が管理するワークロードオブジェクトの名前。
3: モードを Off に設定します。

以下のコマンドを使用して、推奨事項を表示できます。

oc get vpa <vpa-name> --output yaml

$ oc get vpa <vpa-name> --output yaml

Copy to Clipboard

Toggle word wrap

この推奨事項により、ワークロードオブジェクトを編集して CPU およびメモリー要求を追加し、推奨リソースを使用して Pod を削除および再デプロイできます。

注記

VPA から最も正確な推奨事項を取得するには、Pod が実行され、VPA が安定するまで少なくとも 8 日間待機してください。

2.5.4.5. VPA の推奨事項をすべてのコンテナーに適用しないようにする
リンクのコピー

ワークロードオブジェクトに複数のコンテナーがあり、VPA がすべてのコンテナーを評価および実行対象としないようにするには、特定のワークロードオブジェクトの VPA CR を作成し、resourcePolicy を追加して特定のコンテナーをオプトアウトします。

VPA が推奨リソースで Pod を更新すると、resourcePolicy が設定されたコンテナーは更新されず、VPA は Pod 内のそれらのコンテナーの推奨事項を提示しません。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend 
  updatePolicy:
    updateMode: "Auto" 
  resourcePolicy: 
    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend


  updatePolicy:
    updateMode: "Auto"


  resourcePolicy:


    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"

Copy to Clipboard

Toggle word wrap

1: この VPA CR が管理するワークロードオブジェクトのタイプ。
2: この VPA CR が管理するワークロードオブジェクトの名前。
3: モードを Auto、Recreate、Initial、または Off に設定します。Recreate モードが使用されることはほとんどありません。リソース要求の変更に応じて Pod を必ず再起動させたい場合に限定して使用します。
4: VPA によって更新しないコンテナーを指定し、mode を Off に設定します。

たとえば、Pod には同じリソース要求および制限の 2 つのコンテナーがあります。

# ...
spec:
  containers:
  - name: frontend
    resources:
      limits:
        cpu: 1
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
  - name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
# ...

# ...
spec:
  containers:
  - name: frontend
    resources:
      limits:
        cpu: 1
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
  - name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
# ...

Copy to Clipboard

Toggle word wrap

backend コンテナーがオプトアウトに設定された VPA CR を起動した後、VPA は Pod を終了し、frontend コンテナーのみに適用される推奨リソースで Pod を再作成します。

...
spec:
  containers:
    name: frontend
    resources:
      limits:
        cpu: 50m
        memory: 1250Mi
      requests:
        cpu: 25m
        memory: 262144k
...
    name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
...

...
spec:
  containers:
    name: frontend
    resources:
      limits:
        cpu: 50m
        memory: 1250Mi
      requests:
        cpu: 25m
        memory: 262144k
...
    name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
...

Copy to Clipboard

Toggle word wrap

2.5.4.6. VPA Operator のパフォーマンスチューニング
リンクのコピー

クラスター管理者は、Vertical Pod Autoscaler Operator (VPA) のパフォーマンスを調整して、VPA が Kubernetes API サーバーにリクエストを行うレートを制限したり、VPA レコメンダー、アップデーター、アドミッションコントローラーコンポーネントの Pod の CPU とメモリーリソースを指定したりできます。

VPA カスタムリソース (CR) が管理するワークロードのみを監視するように VPA を設定することもできます。デフォルトでは、VPA はクラスター内のすべてのワークロードを監視します。その結果、VPA はすべてのワークロードの 8 日間の履歴データを蓄積して保存します。ワークロードに対して新しい VPA CR が作成された場合、VPA でこれを使用できます。ただし、これにより VPA は大量の CPU とメモリーを使用することになります。これにより、特に大規模なクラスターでは VPA が失敗する可能性があります。VPA CR を使用してワークロードのみを監視するように VPA を設定すると、CPU とメモリーのリソースを節約できます。トレードオフの 1 つは、実行中のワークロードがあり、そのワークロードを管理するために VPA CR を作成する場合です。VPA にはそのワークロードの履歴データがありません。そのため、最初の推奨値は、ワークロードがしばらく実行された後の推奨値ほど有用ではありません。

これらのチューニングを使用して、VPA が最高の効率で動作するために十分なリソースを確保し、スロットルや Pod の承認の遅延を防止します。

VerticalPodAutoscalerController カスタムリソース (CR) を編集することで、VPA コンポーネントに対して以下のチューニングを行えます。

スロットル調整と Pod アドミッションの遅延を防ぐには、kube-api-qps パラメーターと kube-api-burst パラメーターを使用して、Kubernetes API サーバーの VPA リクエストの 1 秒あたりのクエリー数 (QPS) とバーストレートを設定します。
十分な CPU とメモリーを確保するには、標準の cpu および memory リソース要求を使用して、VPA コンポーネント Pod の CPU 要求とメモリー要求を設定します。
VPA CR が管理するワークロードのみを監視するように VPA を設定するには、レコメンデーションコンポーネントの memory-saver パラメーターを true に設定します。

各 VPA コンポーネントに設定できるリソースおよびレート制限のガイドラインについて、次の表では、クラスターや他の要素のサイズに応じて、推奨のベースライン値を紹介しています。

重要

これらの推奨値は、Red Hat の内部テストに基づいて算出されたものであり、必ずしも実際のクラスターを代表するものではありません。実稼働クラスターを設定する前に、実稼働以外のクラスターでこれらの値をテストしてください。

Expand

表2.2 クラスター内のコンテナーによる要求
コンポーネント	1 - 500 個のコンテナー		500 - 1000 個のコンテナー		1000 - 2000 個のコンテナー		2000 - 4000 個のコンテナー		4000 個以上のコンテナー
	CPU	メモリー	CPU	メモリー	CPU	メモリー	CPU	メモリー	CPU	メモリー
アドミッション	25m	50 Mi	25m	75Mi	40m	150Mi	75m	260 Mi	(0.03c)/2 + 10 ^[1]	(0.1c)/2 + 50 ^[1]
レコメンダー	25m	100Mi	50m	160Mi	75m	275Mi	120M	420Mi	(0.05c)/2 + 50 ^[1]	(0.15c)/2 + 120 ^[1]
アップデーター	25m	100Mi	50m	220Mi	80 m	350Mi	150 m	500Mi	(0.07c)/2 + 20 ^[1]	(0.15c)/2 + 200 ^[1]

c は、クラスター内のコンテナーの数です。

注記

コンテナーのメモリー制限は、表中の推奨される要求量の少なくとも 2 倍に設定することを推奨します。ただし、CPU は圧縮可能なリソースであるため、コンテナーの CPU 制限を設定すると VPA をスロットリングできます。そのため、コンテナーに CPU 制限を設定しないことが推奨されます。

Expand

表2.3 クラスター内の VPAs によるレート制限
コンポーネント	1-150 VPAs		151-500 VPAs		501-2,000 VPAs		2,001-4,000 VPAs
	QPS 制限 ^[1]	Burst ^[2]	QPS 制限	Burst	QPS 制限	Burst	QPS 制限	Burst
レコメンダー	5	10	30	60	60	120	120	240
アップデーター	5	10	30	60	60	120	120	240

QPS は、Kubernetes API サーバーにリクエストを行う際の 1 秒あたりのクエリー数 (QPS) の制限を指定します。アップデーターおよびレコメンダー Pod のデフォルトは 5.0 です。
Burst は、Kubernetes API サーバーにリクエストを行う際のバースト制限を指定します。アップデーターおよびレコメンダー Pod のデフォルトは 10.0 です。

注記

クラスターに 4,000 を超える VPAs がある場合は、テーブルの値でパフォーマンスチューニングを開始し、必要なレコメンダー、更新レイテンシーおよびパフォーマンスを達成するまで値を徐々に増やすことを推奨します。QPS および Burst の増加により、VPA コンポーネントから API サーバーに送信される API 要求が多すぎると、クラスターの健全性に影響し、Kubernetes API サーバーの速度が遅くなる可能性があるため、これらの値は徐々に調整します。

以下の VPA コントローラー CR の例は、1,000 から 2,000 コンテナーを持つクラスター用であり、Pod の作成サージは 26 から 50 になります。CR は以下の値を設定します。

3 つの VPA コンポーネントすべてに対するコンテナーメモリーおよび CPU 要求
3 つの VPA コンポーネントすべてに対するコンテナーのメモリー制限
3 つの VPA コンポーネントすべてに対する QPS およびバーストレート
VPA レコメンダーコンポーネントの memory-saver パラメーターを true に設定

VerticalPodAutoscalerController CR の例

apiVersion: autoscaling.openshift.io/v1
kind: VerticalPodAutoscalerController
metadata:
  name: default
  namespace: openshift-vertical-pod-autoscaler
spec:
  deploymentOverrides:
    admission: 
      container:
        args: 
          - '--kube-api-qps=50.0'
          - '--kube-api-burst=100.0'
        resources:
          requests: 
            cpu: 40m
            memory: 150Mi
          limits:
            memory: 300Mi
    recommender: 
      container:
        args:
          - '--kube-api-qps=60.0'
          - '--kube-api-burst=120.0'
          - '--memory-saver=true' 
        resources:
          requests:
            cpu: 75m
            memory: 275Mi
          limits:
            memory: 550Mi
    updater: 
      container:
        args:
          - '--kube-api-qps=60.0'
          - '--kube-api-burst=120.0'
        resources:
          requests:
            cpu: 80m
            memory: 350M
          limits:
            memory: 700Mi
  minReplicas: 2
  podMinCPUMillicores: 25
  podMinMemoryMb: 250
  recommendationOnly: false
  safetyMarginFraction: 0.15

apiVersion: autoscaling.openshift.io/v1
kind: VerticalPodAutoscalerController
metadata:
  name: default
  namespace: openshift-vertical-pod-autoscaler
spec:
  deploymentOverrides:
    admission:


      container:
        args:


          - '--kube-api-qps=50.0'
          - '--kube-api-burst=100.0'
        resources:
          requests:


            cpu: 40m
            memory: 150Mi
          limits:
            memory: 300Mi
    recommender:


      container:
        args:
          - '--kube-api-qps=60.0'
          - '--kube-api-burst=120.0'
          - '--memory-saver=true'


        resources:
          requests:
            cpu: 75m
            memory: 275Mi
          limits:
            memory: 550Mi
    updater:


      container:
        args:
          - '--kube-api-qps=60.0'
          - '--kube-api-burst=120.0'
        resources:
          requests:
            cpu: 80m
            memory: 350M
          limits:
            memory: 700Mi
  minReplicas: 2
  podMinCPUMillicores: 25
  podMinMemoryMb: 250
  recommendationOnly: false
  safetyMarginFraction: 0.15

Copy to Clipboard

Toggle word wrap

VPA アドミッションコントローラーのチューニングパラメーターを指定します。

VPA アドミッションコントローラーの API QPS とバーストレートを指定します。

kube-api-qps: Kubernetes API サーバーにリクエストを行うときの 1 秒あたりのクエリー数 (QPS) 制限を指定します。デフォルトは 5.0 です。
kube-api-burst: Kubernetes API サーバーにリクエストを行うときのバースト制限を指定します。デフォルトは 10.0 です。

VPA アドミッションコントローラー Pod のリソース要求および制限を指定します。

VPA レコメンダーのチューニングパラメーターを指定します。

5

VPA Operator が VPA CR を持つワークロードのみを監視するように指定します。デフォルトは false です。

6

VPA アップデーターのチューニングパラメーターを指定します。

設定が各 VPA コンポーネント Pod に適用されたことを確認できます。

アップデーター Pod の例

apiVersion: v1
kind: Pod
metadata:
  name: vpa-updater-default-d65ffb9dc-hgw44
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
  containers:
  - args:
    - --logtostderr
    - --v=1
    - --min-replicas=2
    - --kube-api-qps=60.0
    - --kube-api-burst=120.0
# ...
    resources:
      requests:
        cpu: 80m
        memory: 350M
# ...

apiVersion: v1
kind: Pod
metadata:
  name: vpa-updater-default-d65ffb9dc-hgw44
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
  containers:
  - args:
    - --logtostderr
    - --v=1
    - --min-replicas=2
    - --kube-api-qps=60.0
    - --kube-api-burst=120.0
# ...
    resources:
      requests:
        cpu: 80m
        memory: 350M
# ...

Copy to Clipboard

Toggle word wrap

アドミッションコントローラー Pod の例

apiVersion: v1
kind: Pod
metadata:
  name: vpa-admission-plugin-default-756999448c-l7tsd
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
  containers:
  - args:
    - --logtostderr
    - --v=1
    - --tls-cert-file=/data/tls-certs/tls.crt
    - --tls-private-key=/data/tls-certs/tls.key
    - --client-ca-file=/data/tls-ca-certs/service-ca.crt
    - --webhook-timeout-seconds=10
    - --kube-api-qps=50.0
    - --kube-api-burst=100.0
# ...
    resources:
      requests:
        cpu: 40m
        memory: 150Mi
# ...

apiVersion: v1
kind: Pod
metadata:
  name: vpa-admission-plugin-default-756999448c-l7tsd
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
  containers:
  - args:
    - --logtostderr
    - --v=1
    - --tls-cert-file=/data/tls-certs/tls.crt
    - --tls-private-key=/data/tls-certs/tls.key
    - --client-ca-file=/data/tls-ca-certs/service-ca.crt
    - --webhook-timeout-seconds=10
    - --kube-api-qps=50.0
    - --kube-api-burst=100.0
# ...
    resources:
      requests:
        cpu: 40m
        memory: 150Mi
# ...

Copy to Clipboard

Toggle word wrap

レコメンダー Pod の例

apiVersion: v1
kind: Pod
metadata:
  name: vpa-recommender-default-74c979dbbc-znrd2
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
  containers:
  - args:
    - --logtostderr
    - --v=1
    - --recommendation-margin-fraction=0.15
    - --pod-recommendation-min-cpu-millicores=25
    - --pod-recommendation-min-memory-mb=250
    - --kube-api-qps=60.0
    - --kube-api-burst=120.0
    - --memory-saver=true
# ...
    resources:
      requests:
        cpu: 75m
        memory: 275Mi
# ...

apiVersion: v1
kind: Pod
metadata:
  name: vpa-recommender-default-74c979dbbc-znrd2
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
  containers:
  - args:
    - --logtostderr
    - --v=1
    - --recommendation-margin-fraction=0.15
    - --pod-recommendation-min-cpu-millicores=25
    - --pod-recommendation-min-memory-mb=250
    - --kube-api-qps=60.0
    - --kube-api-burst=120.0
    - --memory-saver=true
# ...
    resources:
      requests:
        cpu: 75m
        memory: 275Mi
# ...

Copy to Clipboard

Toggle word wrap

2.5.4.7. OOM イベント後のカスタムのメモリー増加量
リンクのコピー

クラスターで OOM (メモリー不足) イベントが発生した場合、Vertical Pod Autoscaler Operator (VPA) はメモリーの推奨値を増やします。この推奨値は、OOM イベントの発生時に観測されたメモリー消費量と、将来的なメモリー不足によるクラッシュを防ぐために指定された乗数に基づいています。

推奨値は、OOM イベント発生時に Pod によって使用されていたメモリー使用量に指定バイト数または指定パーセンテージを掛けて算出される値のうち、どちらか大きい方です。計算は次の式で表されます。

recommendation = max(memory-usage-in-oom-event + oom-min-bump-up-bytes, memory-usage-in-oom-event * oom-bump-up-ratio)

recommendation = max(memory-usage-in-oom-event + oom-min-bump-up-bytes, memory-usage-in-oom-event * oom-bump-up-ratio)

Copy to Clipboard

Toggle word wrap

メモリーの増加量は、レコメンダー Pod で次の値を指定して設定できます。

oom-min-bump-up-bytes。この値 (バイト単位) は、OOM イベントが発生した後のメモリーの具体的な増加量です。デフォルトは 100MiB です。
oom-bump-up-ratio。この値は、OOM イベント発生時のメモリーの増加率です。デフォルト値は 1.2 です。

たとえば、OOM イベント中の Pod メモリー使用量が 100 MB で、oom-min-bump-up-bytes が 150 MB に設定され、oom-min-bump-ratio が 1.2 に設定されている場合。OOM イベントの後、VPA では、その Pod のメモリー要求を 120 MB (100 MB * 1.2) よりも高い 150 MB に増やすことを推奨します。

レコメンダーの Deployment オブジェクトの例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vpa-recommender-default
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
# ...
  template:
# ...
    spec
      containers:
      - name: recommender
        args:
        - --oom-bump-up-ratio=2.0
        - --oom-min-bump-up-bytes=524288000
# ...

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vpa-recommender-default
  namespace: openshift-vertical-pod-autoscaler
# ...
spec:
# ...
  template:
# ...
    spec
      containers:
      - name: recommender
        args:
        - --oom-bump-up-ratio=2.0
        - --oom-min-bump-up-bytes=524288000
# ...

Copy to Clipboard

Toggle word wrap

関連情報

OOM の強制終了ポリシーについて

2.5.4.8. 代替のレコメンダーを使用する
リンクのコピー

独自のレコメンダーを使用して、独自のアルゴリズムに基づいて自動スケーリングできます。代替レコメンダーを指定しない場合、OpenShift Container Platform はデフォルトのレコメンダーを使用します。これは、過去の使用状況に基づいて CPU およびメモリー要求を提案します。すべてのタイプのワークロードに適用されるユニバーサルレコメンデーションポリシーはないため、特定のワークロードに対して異なるレコメンダーを作成してデプロイメントすることを推奨します。

たとえば、コンテナーが特定のリソース動作を示している場合、デフォルトのレコメンダーは将来のリソース使用量を正確に予測できない可能性があります。例としては、監視アプリケーションで使用される使用量の急増とアイドル状態が交互に繰り返される周期的なパターンや、ディープラーニングアプリケーションで使用される繰り返しパターンなどがあります。これらの使用動作でデフォルトのレコメンダーを使用すると、アプリケーションのプロビジョニングが大幅に過剰になり、Out of Memory (OOM) が強制終了される可能性があります。

注記

レコメンダーを作成する方法については、このドキュメントの範囲外です。

手順

Pod に代替のレコメンダーを使用するには:

代替レコメンダーのサービスアカウントを作成し、そのサービスアカウントを必要なクラスターロールにバインドします。

apiVersion: v1 
kind: ServiceAccount
metadata:
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding
metadata:
  name: system:example-metrics-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-actor
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-actor
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-target-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-target-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>

apiVersion: v1


kind: ServiceAccount
metadata:
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1


kind: ClusterRoleBinding
metadata:
  name: system:example-metrics-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1


kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-actor
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-actor
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>
---
apiVersion: rbac.authorization.k8s.io/v1


kind: ClusterRoleBinding
metadata:
  name: system:example-vpa-target-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:vpa-target-reader
subjects:
- kind: ServiceAccount
  name: alt-vpa-recommender-sa
  namespace: <namespace_name>

Copy to Clipboard

Toggle word wrap

1: レコメンダーを表示する namespace にレコメンダーのサービスアカウントを作成します。
2: レコメンダーサービスアカウントを metrics-reader ロールにバインドします。レコメンダーをデプロイする場所の namespace を指定します。
3: レコメンダーサービスアカウントを vpa-actor ロールにバインドします。レコメンダーをデプロイする場所の namespace を指定します。
4: レコメンダーサービスアカウントを vpa-target-reader ロールにバインドします。レコメンダーを表示する namespace を指定します。

代替レコメンダーをクラスターに追加するには、次のような Deployment オブジェクトを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alt-vpa-recommender
  namespace: <namespace_name>
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alt-vpa-recommender
  template:
    metadata:
      labels:
        app: alt-vpa-recommender
    spec:
      containers: 
      - name: recommender
        image: quay.io/example/alt-recommender:latest 
        imagePullPolicy: Always
        resources:
          limits:
            cpu: 200m
            memory: 1000Mi
          requests:
            cpu: 50m
            memory: 500Mi
        ports:
        - name: prometheus
          containerPort: 8942
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
              - ALL
          seccompProfile:
            type: RuntimeDefault
      serviceAccountName: alt-vpa-recommender-sa 
      securityContext:
        runAsNonRoot: true

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alt-vpa-recommender
  namespace: <namespace_name>
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alt-vpa-recommender
  template:
    metadata:
      labels:
        app: alt-vpa-recommender
    spec:
      containers:


      - name: recommender
        image: quay.io/example/alt-recommender:latest


        imagePullPolicy: Always
        resources:
          limits:
            cpu: 200m
            memory: 1000Mi
          requests:
            cpu: 50m
            memory: 500Mi
        ports:
        - name: prometheus
          containerPort: 8942
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
              - ALL
          seccompProfile:
            type: RuntimeDefault
      serviceAccountName: alt-vpa-recommender-sa


      securityContext:
        runAsNonRoot: true

Copy to Clipboard

Toggle word wrap

1: 代替レコメンダーのコンテナーを作成します。
2: 推奨イメージを指定します。
3: レコメンダー用に作成したサービスアカウントを関連付けます。

同じ namespace 内の代替レコメンダー用に新しい Pod が作成されます。

oc get pods

$ oc get pods

Copy to Clipboard

Toggle word wrap

出力例

NAME                                        READY   STATUS    RESTARTS   AGE
frontend-845d5478d-558zf                    1/1     Running   0          4m25s
frontend-845d5478d-7z9gx                    1/1     Running   0          4m25s
frontend-845d5478d-b7l4j                    1/1     Running   0          4m25s
vpa-alt-recommender-55878867f9-6tp5v        1/1     Running   0          9s

NAME                                        READY   STATUS    RESTARTS   AGE
frontend-845d5478d-558zf                    1/1     Running   0          4m25s
frontend-845d5478d-7z9gx                    1/1     Running   0          4m25s
frontend-845d5478d-b7l4j                    1/1     Running   0          4m25s
vpa-alt-recommender-55878867f9-6tp5v        1/1     Running   0          9s

Copy to Clipboard

Toggle word wrap

代替レコメンダー Deployment オブジェクトの名前を含む Vertical Pod Autoscaler Operator (VPA) カスタムリソース (CR) を設定します。

代替レコメンダーを含めるための VPA CR の例

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
  namespace: <namespace_name>
spec:
  recommenders:
    - name: alt-vpa-recommender 
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment 
    name:       frontend

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
  namespace: <namespace_name>
spec:
  recommenders:
    - name: alt-vpa-recommender


  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment


    name:       frontend

Copy to Clipboard

Toggle word wrap

1: 代替レコメンダーデプロイメントの名前を指定します。
2: この VPA で管理する既存のワークロードオブジェクトの名前を指定します。

2.5.5. Vertical Pod Autoscaler Operator の使用
リンクのコピー

VPA カスタムリソース (CR) を作成して、Vertical Pod Autoscaler Operator (VPA) を使用できます。CR は分析する Pod を示し、それらの Pod に対して VPA が実行するアクションを決定します。

VPA を使用して、デプロイメントまたはステートフルセットなどの組み込みリソースや Pod を管理するカスタムリソースをスケーリングできます。詳細は、「Vertical Pod Autoscaler Operator の使用について」を参照してください。

前提条件

自動スケーリングするワークロードオブジェクトが存在することを確認します。
代替レコメンダーを使用する場合は、そのレコメンダーを含むデプロイメントが存在することを確認してください。

手順

特定のワークロードオブジェクトの VPA CR を作成するには、以下を実行します。

スケーリングするワークロードオブジェクトのプロジェクトの場所に切り替えます。
1. VPA CR YAML ファイルを作成します。
  apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: vpa-recommender spec: targetRef: apiVersion: "apps/v1" kind: Deployment
  1
  name: frontend
  2
  updatePolicy: updateMode: "Auto"
  3
  resourcePolicy:
  4
  containerPolicies: - containerName: my-opt-sidecar mode: "Off" recommenders:
  5
  - name: my-recommender
  Copy to Clipboard Toggle word wrap
  1
  この VPA が管理するワークロードオブジェクトのタイプ (Deployment、StatefulSet、Job、DaemonSet、ReplicaSet、または ReplicationController) を指定します。
  2
  この VPA が管理する既存のワークロードオブジェクトの名前を指定します。
  3
  VPA モードを指定します。
  Auto は、コントローラーに関連付けられた Pod に推奨リソースを自動的に適用します。VPA は既存の Pod を終了し、推奨されるリソース制限および要求で新規 Pod を作成します。
  Recreate は、ワークロードオブジェクトに関連付けられた Pod に推奨リソースを自動的に適用します。VPA は既存の Pod を終了し、推奨されるリソース制限および要求で新規 Pod を作成します。Recreate モードが使用されることはほとんどありません。リソース要求の変更に応じて Pod を必ず再起動させたい場合に限定して使用します。
  Initial は、ワークロードオブジェクトに関連付けられた新しく作成された Pod に推奨リソースを自動的に適用します。VPA は、新しい推奨リソースを確認する際に Pod を更新しません。
  Off は、ワークロードオブジェクトに関連付けられた Pod の推奨リソースのみを生成します。VPA は、新しい推奨リソースを確認する際に Pod を更新しません。また、新規 Pod に推奨事項を適用しません。
  4
  オプション: オプトアウトするコンテナーを指定し、モードを Off に設定します。
  5
  オプション: レコメンダーの推奨者を指定します。
2. VPA CR を作成します。
  $ oc create -f <file-name>.yaml
  Copy to Clipboard Toggle word wrap
  しばらくすると、VPA はワークロードオブジェクトに関連付けられた Pod 内のコンテナーのリソース使用状況を確認します。
  次のコマンドを使用して、VPA の推奨値を表示できます。
  $ oc get vpa <vpa-name> --output yaml
  Copy to Clipboard Toggle word wrap
  出力には、以下のような CPU およびメモリー要求の推奨事項が表示されます。
  出力例
  ... status: ... recommendation: containerRecommendations: - containerName: frontend lowerBound:
  1
  cpu: 25m memory: 262144k target:
  2
  cpu: 25m memory: 262144k uncappedTarget:
  3
  cpu: 25m memory: 262144k upperBound:
  4
  cpu: 262m memory: "274357142" - containerName: backend lowerBound: cpu: 12m memory: 131072k target: cpu: 12m memory: 131072k uncappedTarget: cpu: 12m memory: 131072k upperBound: cpu: 476m memory: "498558823" ...
  
  Copy to Clipboard Toggle word wrap
  1
  lowerBound は、推奨リソースの最小レベルです。
  2
  target は、推奨リソースのレベルです。
  3
  upperBound は、推奨リソースの最大レベルです。
  4
  uncappedTarget は最新の推奨リソースです。

2.5.5.1. Vertical Pod Autoscaler のカスタムリソースの例
リンクのコピー

Vertical Pod Autoscaler (VPA) Operator は、デプロイメントまたはステートフルセットなどの組み込みリソースだけでなく、Pod を管理するカスタムリソースも更新できます。

カスタムリソースで VPA を使用するには、CustomResourceDefinition (CRD) オブジェクトを作成する際に、/scale サブリソースの labelSelectorPath フィールドを設定する必要があります。/scale サブリソースは Scale オブジェクトを作成します。labelSelectorPath フィールドは、Scale オブジェクトおよびカスタムリソースの status.selector に対応するカスタムリソース内の JSON パスを定義します。以下は、カスタムリソースをターゲットとする VerticalPodAutoscaler 定義と共に、これらの要件を満たす CustomResourceDefinition および CustomResource の例です。/scale サブリソースコントラクトの例を以下に示します。

注記

この例では、Pod を所有することを許可するカスタムリソースのコントローラーが存在しないため、VPA による Pod のスケーリングは行われません。そのため、カスタムリソースと Pod 間の調整と状態管理を管理するために、Kubernetes がサポートする言語でコントローラーを作成する必要があります。この例は、VPA がカスタムリソースをスケーラブルなものとして認識できるようにするための設定を示しています。

カスタム CRD、CR の例

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: scalablepods.testing.openshift.io
spec:
  group: testing.openshift.io
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              replicas:
                type: integer
                minimum: 0
              selector:
                type: string
          status:
            type: object
            properties:
              replicas:
                type: integer
    subresources:
      status: {}
      scale:
        specReplicasPath: .spec.replicas
        statusReplicasPath: .status.replicas
        labelSelectorPath: .spec.selector 
  scope: Namespaced
  names:
    plural: scalablepods
    singular: scalablepod
    kind: ScalablePod
    shortNames:
    - spod

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: scalablepods.testing.openshift.io
spec:
  group: testing.openshift.io
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              replicas:
                type: integer
                minimum: 0
              selector:
                type: string
          status:
            type: object
            properties:
              replicas:
                type: integer
    subresources:
      status: {}
      scale:
        specReplicasPath: .spec.replicas
        statusReplicasPath: .status.replicas
        labelSelectorPath: .spec.selector


  scope: Namespaced
  names:
    plural: scalablepods
    singular: scalablepod
    kind: ScalablePod
    shortNames:
    - spod

Copy to Clipboard

Toggle word wrap

1: カスタムリソースオブジェクトの status.selector フィールドに対応する JSON パスを指定します。

カスタム CR の例

apiVersion: testing.openshift.io/v1
kind: ScalablePod
metadata:
  name: scalable-cr
  namespace: default
spec:
  selector: "app=scalable-cr" 
  replicas: 1

apiVersion: testing.openshift.io/v1
kind: ScalablePod
metadata:
  name: scalable-cr
  namespace: default
spec:
  selector: "app=scalable-cr"


  replicas: 1

Copy to Clipboard

Toggle word wrap

1: 管理対象の Pod に適用するラベルのタイプを指定します。これは、カスタムリソース定義オブジェクト内で labelSelectorPath が参照するフィールドです。

VPA オブジェクトの例

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: scalable-cr
  namespace: default
spec:
  targetRef:
    apiVersion: testing.openshift.io/v1
    kind: ScalablePod
    name: scalable-cr
  updatePolicy:
    updateMode: "Auto"

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: scalable-cr
  namespace: default
spec:
  targetRef:
    apiVersion: testing.openshift.io/v1
    kind: ScalablePod
    name: scalable-cr
  updatePolicy:
    updateMode: "Auto"

Copy to Clipboard

Toggle word wrap

2.5.6. Vertical Pod Autoscaler Operator のアンインストール
リンクのコピー

Vertical Pod Autoscaler Operator (VPA) を OpenShift Container Platform クラスターから削除できます。アンインストール後、既存の VPA カスタムリソース (CR) によってすでに変更されている Pod のリソース要求は変更されません。VPA によって行われた以前の推奨事項ではなく、ワークロードオブジェクトで定義されたリソースが、新しい Pod に割り当てられます。

注記

oc delete vpa <vpa-name> コマンドを使用して、特定の VPA CR を削除できます。Vertical Pod Autoscaler のアンインストール時と同じアクションがリソース要求に対して適用されます。

VPA を削除した後、潜在的な問題を回避するために、Operator に関連する他のコンポーネントを削除することを推奨します。

前提条件

VPA をインストールしている。

手順

OpenShift Container Platform Web コンソールで、Ecosystem → Installed Operator をクリックします。
openshift-vertical-pod-autoscaler プロジェクトに切り替えます。
VerticalPodAutoscaler Operator の場合は、Options メニューをクリックし、Uninstall Operator を選択します。
オプション: Operator に関連付けられているすべてのオペランドを削除するには、ダイアログボックスで Delete all operand instances for this operator チェックボックスをオンにします。
Uninstall をクリックします。
オプション: OpenShift CLI を使用して VPA コンポーネントを削除します。
1. VPA namespace を削除します。
  $ oc delete namespace openshift-vertical-pod-autoscaler
  Copy to Clipboard Toggle word wrap
2. VPA カスタムリソース定義 (CRD) オブジェクトを削除します。
  $ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io
  Copy to Clipboard Toggle word wrap
  $ oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.io
  Copy to Clipboard Toggle word wrap
  $ oc delete crd verticalpodautoscalers.autoscaling.k8s.io
  Copy to Clipboard Toggle word wrap
  CRD を削除すると、関連付けられたロール、クラスターロール、およびロールバインディングが削除されます。
  注記
  この操作により、ユーザーが作成したすべての VPA CR がクラスターから削除されます。VPA を再インストールする場合は、これらのオブジェクトを再度作成する必要があります。
3. 次のコマンドを実行して MutatingWebhookConfiguration オブジェクトを削除します。
  $ oc delete MutatingWebhookConfiguration vpa-webhook-config
  Copy to Clipboard Toggle word wrap
4. VPA Operator を削除します。
  $ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
  Copy to Clipboard Toggle word wrap

2.6. Pod を中断せずに Pod のリソースレベルを調整する
リンクのコピー

Pod のインプレースサイズ変更 を使用すると、Pod を再作成または再起動せずに、コンテナーに割り当てられた CPU またはメモリーリソースの要求と制限を変更できます。

2.6.1. Pod のインプレースサイズ変更について
リンクのコピー

Pod のインプレースサイズ変更を使用すると、アプリケーションを中断することなく、実行中の Pod 内のコンテナーの CPU およびメモリーリソースを変更できます。Pod の CPU およびメモリーリソースを変更する標準的な方法では、Pod が再作成され、中断が発生する可能性があります。Pod のインプレースサイズ変更により、Pod の再起動に伴うダウンタイムや状態の損失を発生させることなく、Pod のリソースを増減できます。

Pod のインプレースサイズ変更を使用して CPU またはメモリーリソースを変更する場合、Pod 仕様でサイズ変更ポリシーを設定することで、Pod を再起動するかどうかを制御できます。次のサイズ変更ポリシーの例では、メモリーリソースの変更時には Pod の再起動が必要ですが、CPU リソースの変更時には再起動が防止されます。

リソースポリシーの例

apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: pause
# ...
    resizePolicy: 
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer

apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: pause
# ...
    resizePolicy:


    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer

Copy to Clipboard

Toggle word wrap

1: サイズ変更ポリシーを指定します。

注記

memory のサイズ変更ポリシーを RestartContainer でない限り、メモリーの制限を引き下げることはできません。

既存の Pod にサイズ変更ポリシーを追加または変更することはできません。ただし、Pod にオーナーオブジェクトがある場合は、デプロイメントなどの Pod のオーナーオブジェクトでポリシーを追加または編集できます。

Pod のインプレースサイズ変更を使用するには、次の例に示すように、OpenShift CLI (oc) で Pod を編集するときに --subresource resize フラグを使用する必要があります。

コマンドの例

oc edit pod <pod_name>  --subresource resize

$ oc edit pod <pod_name>  --subresource resize

Copy to Clipboard

Toggle word wrap

oc apply -f <file_name>.yaml --subresource resize

$ oc apply -f <file_name>.yaml --subresource resize

Copy to Clipboard

Toggle word wrap

oc patch pod <pod_name> --subresource resize --patch \
  '{"spec":{"containers":[{"name":"pause", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

$ oc patch pod <pod_name> --subresource resize --patch \
  '{"spec":{"containers":[{"name":"pause", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

Copy to Clipboard

Toggle word wrap

サイズ変更ポリシーとともに --subresource resize フラグを使用する必要があるため、OpenShift Container Platform Web コンソールで Pod リソースを編集することはできません。

サイズ変更ポリシーが NotRequired の場合、要求または制限を変更しても、Pod は再起動されません。

oc get pods

$ oc get pods

Copy to Clipboard

Toggle word wrap

出力例

NAME                          READY   STATUS    RESTARTS     AGE
resize-pod                    1/1     Running   0            5s

NAME                          READY   STATUS    RESTARTS     AGE
resize-pod                    1/1     Running   0            5s

Copy to Clipboard

Toggle word wrap

サイズ変更ポリシーが RestartContainer の場合、要求または制限を変更すると、Pod が再起動されます。

oc get pods

$ oc get pods

Copy to Clipboard

Toggle word wrap

出力例

NAME                         READY   STATUS    RESTARTS    AGE
resize-pod                   1/1     Running   1 (5s ago)  5s

NAME                         READY   STATUS    RESTARTS    AGE
resize-pod                   1/1     Running   1 (5s ago)  5s

Copy to Clipboard

Toggle word wrap

リソースの変更後、Pod のステータス条件に、次のメッセージを使用してサイズ変更要求の状態が示されます。

PodResizeInProgress: 要求されたリソースの割り当てが可能であり、kubelet が変更を適用中です。
PodResizePending: 次のいずれかの理由により、kubelet がすぐに変更を加えることができません。
- Infeasible: 現在のノードでは要求されたサイズ変更を実行できません。たとえば、ノードが使用できるリソースよりも多くのリソースを要求すると、Infeasible 状態になります。
- Deferred: 要求されたサイズ変更は現在は不可能ですが、後で可能になる可能性があります。たとえば、別の Pod がノードから削除されると、要求されたリソースが使用可能になる可能性があります。ノードの状態に変化があった場合、kubelet がサイズ変更を再試行します。
Error: リソース割り当て中に kubelet でエラーが発生しました。メッセージフィールドにエラーの理由が報告されます。

実行不可能 (Infeasible) な変更のステータスの例

apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
# ...
status:
  conditions:
  - lastProbeTime: "2025-09-03T15:00:50Z"
    lastTransitionTime: "2025-09-03T15:00:50Z"
    message: 'Node didn''t have enough capacity: cpu, requested: 1000000, capacity:
      3500'
    reason: Infeasible
    status: "True"
    type: PodResizePending

apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
# ...
status:
  conditions:
  - lastProbeTime: "2025-09-03T15:00:50Z"
    lastTransitionTime: "2025-09-03T15:00:50Z"
    message: 'Node didn''t have enough capacity: cpu, requested: 1000000, capacity:
      3500'
    reason: Infeasible
    status: "True"
    type: PodResizePending

Copy to Clipboard

Toggle word wrap

以下の制限事項に注意してください。

再起動不可能な init コンテナーおよび一時コンテナーでは、Pod のインプレースサイズ変更はサポートされていません。
Pod のインプレースサイズ変更が、Pod QoS クラスなど、他の Pod の可変性に関する制約に違反する場合、その変更は許可されません。
静的な cpuManagerPolicy または memoryManagerPolicy パラメーターによって管理される Pod は、Pod のインプレースサイズ変更ではサイズ変更できません。
スワップメモリーを利用する Pod のメモリー要求を Pod のインプレースサイズ変更で変更するには、RestartContainer ポリシーを使用する必要があります。

2.6.2. Pod のインプレースサイズ変更の設定
リンクのコピー

Pod のインプレースサイズ変更を使用するには、Pod 仕様にサイズ変更ポリシーを追加する必要があります。

手順

サイズ変更ポリシーを使用して Pod 仕様を作成するか、既存の Pod のオーナーオブジェクトにサイズ変更ポリシーを追加します。
1. 次の例のような YAML ファイルを作成します。
  apiVersion: v1 kind: Pod metadata: name: resize-pod spec: # ... containers: - name: pause resizePolicy:
  1
  - resourceName: cpu restartPolicy: NotRequired - resourceName: memory restartPolicy: RestartContainer # ...
  Copy to Clipboard Toggle word wrap
  1
  サイズ変更ポリシーを指定します。CPU リソースやメモリーリソースについて、次のいずれかの値を指定します。
  NotRequired: Pod を再起動せずにリソースの変更を適用します。これは、サイズ変更ポリシーを使用する場合のデフォルト値です。
  RestartContainer: リソースの変更を適用し、Pod を再起動します。
2. 次のようなコマンドを実行してオブジェクトを作成します。
  $ oc create -f <file_name>.yaml
  Copy to Clipboard Toggle word wrap

検証

次のようなコマンドを実行して、CPU またはメモリーの要求または制限を変更し、サイズ変更ポリシーが適用されていることを確認します。--subresource resize フラグを含める必要があります。Pod にデプロイメントなどのオーナーオブジェクトがある場合は、オーナーオブジェクトを編集する必要があります。
```
oc edit pod <pod_name>  --subresource resize
```
```
$ oc edit pod <pod_name>  --subresource resize
```
Copy to Clipboard Toggle word wrap
ポリシーが適用されると、Pod は期待どおりに応答します。
```
oc get pods
```
```
$ oc get pods
```
Copy to Clipboard Toggle word wrap
サイズ変更ポリシーが NotRequired の場合、Pod は再起動されません。
出力例
```
NAME                          READY   STATUS    RESTARTS     AGE
resize-pod                    1/1     Running   0            5s
```
```
NAME                          READY   STATUS    RESTARTS     AGE
resize-pod                    1/1     Running   0            5s
```
Copy to Clipboard Toggle word wrap
サイズ変更ポリシーが RestartContainer の場合、Pod は再起動されます。
出力例
```
NAME                         READY   STATUS    RESTARTS    AGE
resize-pod                   1/1     Running   1 (5s ago)  5s
```
```
NAME                         READY   STATUS    RESTARTS    AGE
resize-pod                   1/1     Running   1 (5s ago)  5s
```
Copy to Clipboard Toggle word wrap

2.7. シークレットを使用した機密データの Pod への提供
リンクのコピー

アプリケーションによっては、パスワードやユーザー名など開発者に使用させない秘密情報が必要になります。

管理者は、Secret オブジェクトを使用して、機密情報をクリアテキストで公開せずに提供できます。

2.7.1. シークレットについて
リンクのコピー

Secret オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。シークレットはボリュームプラグインを使用してコンテナーにマウントすることも、システムが Pod の代わりにシークレットを使用して各種アクションを実行することもできます。

キーのプロパティーには以下が含まれます。

シークレットデータはその定義とは別に参照できます。
シークレットデータのボリュームは一時ファイルストレージ機能 (tmpfs) でサポートされ、ノードで保存されることはありません。
シークレットデータは namespace 内で共有できます。

YAML Secret オブジェクト定義

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 
data: 
  username: <username> 
  password: <password>
stringData: 
  hostname: myapp.mydomain.com

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque


data:


  username: <username>


  password: <password>
stringData:


  hostname: myapp.mydomain.com

Copy to Clipboard

Toggle word wrap

1: シークレットにキー名および値の構造を示しています。
2: data フィールドのキーに使用可能な形式は、Kubernetes identifiers glossary の DNS_SUBDOMAIN 値のガイドラインに従う必要があります。
3: data マップのキーに関連付けられる値は base64 でエンコーディングされている必要があります。
4: stringData マップのエントリーが base64 に変換され、このエントリーは自動的に data マップに移動します。このフィールドは書き込み専用です。この値は data フィールドでのみ返されます。
5: stringData マップのキーに関連付けられた値は単純なテキスト文字列で構成されます。

シークレットに依存する Pod を作成する前に、シークレットを作成する必要があります。

シークレットの作成時に以下を実行します。

シークレットデータでシークレットオブジェクトを作成します。
Pod のサービスアカウントをシークレットの参照を許可するように更新します。
シークレットを環境変数またはファイルとして使用する Pod を作成します (secret ボリュームを使用)。

2.7.1.1. シークレットの種類
リンクのコピー

type フィールドの値で、シークレットのキー名と値の構造を指定します。このタイプを使用して、シークレットオブジェクトにユーザー名とキーの配置を実行できます。検証の必要がない場合には、デフォルト設定の opaque タイプを使用してください。

以下のタイプから 1 つ指定して、サーバー側で最小限の検証をトリガーし、シークレットデータに固有のキー名が存在することを確認します。

kubernetes.io/basic-auth: Basic 認証で使用します。
kubernetes.io/dockercfg: イメージプルシークレットとして使用します。
kubernetes.io/dockerconfigjson: イメージプルシークレットとして使用します。
kubernetes.io/service-account-token: レガシーサービスアカウント API トークンの取得に使用します。
kubernetes.io/ssh-auth: SSH キー認証で使用します。
kubernetes.io/tls: TLS 認証局で使用します。

検証が必要ない場合には type: Opaque と指定します。これは、シークレットがキー名または値の規則に準拠しないという意味です。opaque シークレットでは、任意の値を含む、体系化されていない key:value ペアも利用できます。

注記

example.com/my-secret-type などの他の任意のタイプを指定できます。これらのタイプはサーバー側では実行されませんが、シークレットの作成者がその種類のキー/値の要件に従う意図があることを示します。

さまざまな種類のシークレットを作成する例は、シークレットの作成方法 を参照してください。

2.7.1.2. シークレットデータキー
リンクのコピー

シークレットキーは DNS サブドメインになければなりません。

2.7.1.3. 自動的に生成されたイメージプルシークレット
リンクのコピー

OpenShift Container Platform は、デフォルトで各サービスアカウントに対してイメージプルシークレットを作成します。

注記

OpenShift Container Platform 4.16 より前では、作成されたサービスアカウントごとに、長期間有効なサービスアカウント API トークンシークレットも生成されていました。OpenShift Container Platform 4.16 以降では、このサービスアカウント API トークンシークレットは作成されません。

4.20 にアップグレードした後も、既存の長期間有効なサービスアカウント API トークンシークレットは削除されず、引き続き機能します。クラスターで使用されている長期有効 API トークンを検出する方法、または不要な場合に削除する方法は、Red Hat ナレッジベースの記事 Long-lived service account API tokens in OpenShift Container Platform を参照してください。

このイメージプルシークレットは、OpenShift イメージレジストリーをクラスターのユーザー認証および認可システムに統合するために必要です。

ただし、ImageRegistry 機能を有効にしていない場合、または Cluster Image Registry Operator の設定で統合済みの OpenShift イメージレジストリーを無効にしている場合、イメージプルシークレットはサービスアカウントごとに生成されません。

統合済みの OpenShift イメージレジストリーを有効にしていたクラスターでそれを無効にすると、以前に生成されたイメージプルシークレットが自動的に削除されます。

2.7.2. シークレットの作成方法
リンクのコピー

管理者は、開発者がシークレットに依存する Pod を作成できるよう事前にシークレットを作成しておく必要があります。

シークレットの作成時に以下を実行します。

秘密にしておきたいデータを含む秘密オブジェクトを作成します。各シークレットタイプに必要な特定のデータは、以下のセクションで非表示になります。
不透明なシークレットを作成する YAML オブジェクトの例
```
apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque 
data: 
  username: <username>
  password: <password>
stringData: 
  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB
```
```
apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque 
```
1
```
data: 
```
2
```
  username: <username>
  password: <password>
stringData: 
```
3
```
  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB
```
Copy to Clipboard Toggle word wrap
1
シークレットのタイプを指定します。
2
エンコードされた文字列およびデータを指定します。
3
デコードされた文字列およびデータを指定します。
data フィールドまたは stringdata フィールドの両方ではなく、いずれかを使用してください。
Pod のサービスアカウントをシークレットを参照するように更新します。
シークレットを使用するサービスアカウントの YAML
```
apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret
```
```
apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret
```
Copy to Clipboard Toggle word wrap

シークレットを環境変数またはファイルとして使用する Pod を作成します (secret ボリュームを使用)。

シークレットデータと共にボリュームのファイルが設定された Pod の YAML

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts: 
          - name: secret-volume
            mountPath: /etc/secret-volume 
            readOnly: true 
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:


          - name: secret-volume
            mountPath: /etc/secret-volume


            readOnly: true


      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: シークレットが必要な各コンテナーに volumeMounts フィールドを追加します。
2: シークレットが表示される未使用のディレクトリー名を指定します。シークレットデータマップの各キーは mountPath の下にあるファイル名になります。
3: true に設定します。true の場合、ドライバーに読み取り専用ボリュームを提供するように指示します。
4: シークレットの名前を指定します。

シークレットデータと共に環境変数が設定された Pod の YAML

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef: 
              name: test-secret
              key: username
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:


              name: test-secret
              key: username
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: シークレットキーを使用する環境変数を指定します。

シークレットデータと環境変数が設定されたビルド設定の YAML

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef: 
            name: test-secret
            key: username
      from:
        kind: ImageStreamTag
        namespace: openshift
        name: 'cli:latest'

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef:


            name: test-secret
            key: username
      from:
        kind: ImageStreamTag
        namespace: openshift
        name: 'cli:latest'

Copy to Clipboard

Toggle word wrap

1: シークレットキーを使用する環境変数を指定します。

2.7.2.1. シークレットの作成に関する制限
リンクのコピー

シークレットを使用するには、Pod がシークレットを参照できる必要があります。シークレットは、以下の 3 つの方法で Pod で使用されます。

コンテナーの環境変数を事前に設定するために使用される。
1 つ以上のコンテナーにマウントされるボリュームのファイルとして使用される。
Pod のイメージをプルする際に kubelet によって使用される。

ボリュームタイプのシークレットは、ボリュームメカニズムを使用してデータをファイルとしてコンテナーに書き込みます。イメージプルシークレットは、シークレットを namespace のすべての Pod に自動的に注入するためにサービスアカウントを使用します。

テンプレートにシークレット定義が含まれる場合、テンプレートで指定のシークレットを使用できるようにするには、シークレットのボリュームソースを検証し、指定されるオブジェクト参照が Secret オブジェクトを実際に参照していることを確認できる必要があります。そのため、シークレットはこれに依存する Pod の作成前に作成されている必要があります。最も効果的な方法として、サービスアカウントを使用してシークレットを自動的に注入することができます。

シークレット API オブジェクトは namespace にあります。それらは同じ namespace の Pod によってのみ参照されます。

個々のシークレットは 1MB のサイズに制限されます。これにより、apiserver および kubelet メモリーを使い切るような大規模なシークレットの作成を防ぐことができます。ただし、小規模なシークレットであってもそれらを数多く作成するとメモリーの消費につながります。

2.7.2.2. 不透明なシークレットの作成
リンクのコピー

管理者は、不透明なシークレットを作成できます。これにより、任意の値を含むことができる非構造化 key:value のペアを格納できます。

手順

YAML ファイルに Secret オブジェクトを作成します。

以下に例を示します。

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque 
data:
  username: <username>
  password: <password>

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque


data:
  username: <username>
  password: <password>

Copy to Clipboard

Toggle word wrap

1: 不透明なシークレットを指定します。

以下のコマンドを使用して Secret オブジェクトを作成します。
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pod でシークレットを使用するには、以下を実行します。
1. 「シークレットの作成方法について」セクションで説明されているとおり、Pod のサービスアカウントを更新してシークレットを参照します。
2. 「シークレットの作成方法について」で説明されているとおり、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。

2.7.2.3. レガシーサービスアカウントトークンシークレットの作成
リンクのコピー

管理者は、レガシーサービスアカウントトークンシークレットを作成できます。これにより、API に対して認証する必要のあるアプリケーションにサービスアカウントトークンを配布できます。

警告

レガシーサービスアカウントトークンシークレットを使用する代わりに、TokenRequest API を使用してバインドされたサービスアカウントトークンを取得することを推奨します。TokenRequest API を使用できず、読み取り可能な API オブジェクトで有効期限が切れていないトークンのセキュリティーエクスポージャーが許容できる場合にのみ、サービスアカウントトークンシークレットを作成する必要があります。

バインドされたサービスアカウントトークンは、次の理由により、サービスアカウントトークンのシークレットよりもセキュアです。

バインドされたサービスアカウントトークンには有効期間が制限されています。
バインドされたサービスアカウントトークンには対象ユーザーが含まれます。
バインドされたサービスアカウントトークンは Pod またはシークレットにバインドでき、バインドされたオブジェクトが削除されるとバインドされたトークンは無効になります。

バインドされたサービスアカウントトークンを取得するために、ワークロードに projected ボリュームが自動的に注入されます。ワークロードに追加のサービスアカウントトークンが必要な場合は、ワークロードマニフェストに追加の projected ボリュームを追加してください。

詳細は、「ボリュームプロジェクションを使用したバインドされたサービスアカウントトークンの設定」を参照してください。

手順

YAML ファイルに Secret オブジェクトを作成します。
Secret オブジェクトの例
```
apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name" 
type: kubernetes.io/service-account-token 
```
```
apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name" 
```
1
```
type: kubernetes.io/service-account-token 
```
2
Copy to Clipboard Toggle word wrap
1
既存のサービスアカウント名を指定します。ServiceAccount と Secret オブジェクトの両方を作成する場合は、ServiceAccount オブジェクトを最初に作成します。
2
サービスアカウントトークンシークレットを指定します。
以下のコマンドを使用して Secret オブジェクトを作成します。
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pod でシークレットを使用するには、以下を実行します。
1. 「シークレットの作成方法について」セクションで説明されているとおり、Pod のサービスアカウントを更新してシークレットを参照します。
2. 「シークレットの作成方法について」で説明されているとおり、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。

2.7.2.4. Basic 認証シークレットの作成
リンクのコピー

管理者は Basic 認証シークレットを作成できます。これにより、Basic 認証に必要な認証情報を保存できます。このシークレットタイプを使用する場合は、Secret オブジェクトの data パラメーターには、base64 形式でエンコードされた以下のキーが含まれている必要があります。

username: 認証用のユーザー名
password: 認証のパスワードまたはトークン

注記

stringData パラメーターを使用して、クリアテキストコンテンツを使用できます。

手順

YAML ファイルに Secret オブジェクトを作成します。

secret オブジェクトの例

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth 
data:
stringData: 
  username: admin
  password: <password>

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth


data:
stringData:


  username: admin
  password: <password>

Copy to Clipboard

Toggle word wrap

1: Basic 認証のシークレットを指定します。
2: 使用する Basic 認証値を指定します。

以下のコマンドを使用して Secret オブジェクトを作成します。
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pod でシークレットを使用するには、以下を実行します。
1. 「シークレットの作成方法について」セクションで説明されているとおり、Pod のサービスアカウントを更新してシークレットを参照します。
2. 「シークレットの作成方法について」で説明されているとおり、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。

2.7.2.5. SSH 認証シークレットの作成
リンクのコピー

管理者は、SSH 認証シークレットを作成できます。これにより、SSH 認証に使用されるデータを保存できます。このシークレットタイプを使用する場合、Secret オブジェクトの data パラメーターには、使用する SSH 認証情報が含まれている必要があります。

手順

コントロールプレーンノードの YAML ファイルに Secret オブジェクトを作成します。

secret オブジェクトの例

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth 
data:
  ssh-privatekey: | 
          MIIEpQIBAAKCAQEAulqb/Y ...

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth


data:
  ssh-privatekey: |


          MIIEpQIBAAKCAQEAulqb/Y ...

Copy to Clipboard

Toggle word wrap

1: SSH 認証シークレットを指定します。
2: SSH のキー/値のペアを、使用する SSH 認証情報として指定します。

以下のコマンドを使用して Secret オブジェクトを作成します。
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pod でシークレットを使用するには、以下を実行します。
1. 「シークレットの作成方法について」セクションで説明されているとおり、Pod のサービスアカウントを更新してシークレットを参照します。
2. 「シークレットの作成方法について」で説明されているとおり、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。

2.7.2.6. Docker 設定シークレットの作成
リンクのコピー

管理者は Docker 設定シークレットを作成できます。これにより、コンテナーイメージレジストリーにアクセスするための認証情報を保存できます。

kubernetes.io/dockercfg: このシークレットタイプを使用してローカルの Docker 設定ファイルを保存します。secret オブジェクトの data パラメーターには、base64 形式でエンコードされた .dockercfg ファイルの内容が含まれている必要があります。
kubernetes.io/dockerconfigjson: このシークレットタイプを使用して、ローカルの Docker 設定 JSON ファイルを保存します。secret オブジェクトの data パラメーターには、base64 形式でエンコードされた .docker/config.json ファイルの内容が含まれている必要があります。

手順

YAML ファイルに Secret オブジェクトを作成します。

Docker 設定の secret オブジェクトの例

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-cfg
  namespace: my-project
type: kubernetes.io/dockerconfig 
data:
  .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-cfg
  namespace: my-project
type: kubernetes.io/dockerconfig


data:
  .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

Copy to Clipboard

Toggle word wrap

1: シークレットが Docker 設定ファイルを使用することを指定します。
2: base64 でエンコードされた Docker 設定ファイルの出力

Docker 設定の JSON secret オブジェクトの例

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-json
  namespace: my-project
type: kubernetes.io/dockerconfig 
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-json
  namespace: my-project
type: kubernetes.io/dockerconfig


data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

Copy to Clipboard

Toggle word wrap

1: シークレットが Docker 設定の JSON ファイルを使用することを指定します。
2: base64 でエンコードされた Docker 設定 JSON ファイルの出力

以下のコマンドを使用して Secret オブジェクトを作成します。
```
oc create -f <filename>.yaml
```
```
$ oc create -f <filename>.yaml
```
Copy to Clipboard Toggle word wrap
Pod でシークレットを使用するには、以下を実行します。
1. 「シークレットの作成方法について」セクションで説明されているとおり、Pod のサービスアカウントを更新してシークレットを参照します。
2. 「シークレットの作成方法について」で説明されているとおり、シークレットを環境変数またはファイル (secret ボリュームを使用) として使用する Pod を作成します。

2.7.2.7. Web コンソールを使用したシークレットの作成
リンクのコピー

Web コンソールを使用してシークレットを作成できます。

手順

Workloads → Secrets に移動します。
Create → From YAML をクリックします。
1. 仕様に合わせて YAML を手動で編集するか、ファイルを YAML エディターにドラッグアンドドロップします。以下に例を示します。
  apiVersion: v1 kind: Secret metadata: name: example namespace: <namespace> type: Opaque
  1
  data: username: <base64 encoded username> password: <base64 encoded password> stringData:
  2
  hostname: myapp.mydomain.com
  Copy to Clipboard Toggle word wrap
  1
  この例では、不透明なシークレットを指定します。ただし、サービスアカウントトークンシークレット、基本認証シークレット、SSH 認証シークレット、Docker 設定を使用するシークレットなど、他のシークレットタイプが表示される場合があります。
  2
  stringData マップのエントリーが base64 に変換され、このエントリーは自動的に data マップに移動します。このフィールドは書き込み専用です。この値は data フィールドでのみ返されます。
Create をクリックします。
Add Secret to workload をクリックします。
1. ドロップダウンメニューから、追加するワークロードを選択します。
2. Save をクリックします。

2.7.3. シークレットの更新方法
リンクのコピー

シークレットの値を変更する場合、値 (すでに実行されている Pod で使用される値) は動的に変更されません。シークレットを変更するには、元の Pod を削除してから新規の Pod を作成する必要があります (同じ PodSpec を使用する場合があります)。

シークレットの更新は、新規コンテナーイメージのデプロイメントと同じワークフローで実行されます。kubectl rolling-update コマンドを使用できます。

シークレットの resourceVersion 値は参照時に指定されません。したがって、シークレットが Pod の起動と同じタイミングで更新される場合、Pod に使用されるシークレットのバージョンは定義されません。

注記

現時点で、Pod の作成時に使用されるシークレットオブジェクトのリソースバージョンを確認することはできません。コントローラーが古い resourceVersion を使用して Pod を再起動できるように、Pod がこの情報を報告できるようにすることが予定されています。それまでは既存シークレットのデータを更新せずに別の名前で新規のシークレットを作成します。

2.7.4. シークレットの作成および使用
リンクのコピー

管理者は、サービスアカウントトークンシークレットを作成できます。これにより、サービスアカウントトークンを API に対して認証する必要のあるアプリケーションに配布できます。

手順

以下のコマンドを実行して namespace にサービスアカウントを作成します。
```
oc create sa <service_account_name> -n <your_namespace>
```
```
$ oc create sa <service_account_name> -n <your_namespace>
```
Copy to Clipboard Toggle word wrap
以下の YAML の例は service-account-token-secret.yaml という名前のファイルに保存します。この例には、サービスアカウントトークンの生成に使用可能な Secret オブジェクト設定が含まれています。
```
apiVersion: v1
kind: Secret
metadata:
  name: <secret_name> 
  annotations:
    kubernetes.io/service-account.name: "sa-name" 
type: kubernetes.io/service-account-token 
```
```
apiVersion: v1
kind: Secret
metadata:
  name: <secret_name> 
```
1
```
  annotations:
    kubernetes.io/service-account.name: "sa-name" 
```
2
```
type: kubernetes.io/service-account-token 
```
3
Copy to Clipboard Toggle word wrap
1
<secret_name> は、サービストークンシークレットの名前に置き換えます。
2
既存のサービスアカウント名を指定します。ServiceAccount と Secret オブジェクトの両方を作成する場合は、ServiceAccount オブジェクトを最初に作成します。
3
サービスアカウントトークンシークレットタイプを指定します。
ファイルを適用してサービスアカウントトークンを生成します。
```
oc apply -f service-account-token-secret.yaml
```
```
$ oc apply -f service-account-token-secret.yaml
```
Copy to Clipboard Toggle word wrap

以下のコマンドを実行して、シークレットからサービスアカウントトークンを取得します。

oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode

$ oc get secret <sa_token_secret> -o jsonpath='{.data.token}' | base64 --decode

Copy to Clipboard

Toggle word wrap

出力例

ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHA

ayJhbGciOiJSUzI1NiIsImtpZCI6IklOb2dtck1qZ3hCSWpoNnh5YnZhSE9QMkk3YnRZMVZoclFfQTZfRFp1YlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkZXItdG9rZW4tdHZrbnIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYnVpbGRlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjNmZGU2MGZmLTA1NGYtNDkyZi04YzhjLTNlZjE0NDk3MmFmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmJ1aWxkZXIifQ.OmqFTDuMHC_lYvvEUrjr1x453hlEEHYcxS9VKSzmRkP1SiVZWPNPkTWlfNRp6bIUZD3U6aN3N7dMSN0eI5hu36xPgpKTdvuckKLTCnelMx6cxOdAbrcw1mCmOClNscwjS1KO1kzMtYnnq8rXHiMJELsNlhnRyyIXRTtNBsy4t64T3283s3SLsancyx0gy0ujx-Ch3uKAKdZi5iT-I8jnnQ-ds5THDs2h65RJhgglQEmSxpHrLGZFmyHAQI-_SjvmHZPXEc482x3SkaQHNLqpmrpJorNqh1M8ZHKzlujhZgVooMvJmWPXTb2vnvi3DGn2XI-hZxl1yD2yGH1RBpYUHA

Copy to Clipboard

Toggle word wrap

1: <sa_token_secret> は、サービストークンシークレットの名前に置き換えます。

サービスアカウントトークンを使用して、クラスターの API で認証します。
```
curl -X GET <openshift_cluster_api> --header "Authorization: Bearer <token>"
```
```
$ curl -X GET <openshift_cluster_api> --header "Authorization: Bearer <token>" 
```
1
```
 
```
2
Copy to Clipboard Toggle word wrap
1
<openshift_cluster_api> は OpenShift クラスター API に置き換えます。
2
<token> は、直前のコマンドで出力されるサービスアカウントトークンに置き換えます。

2.7.5. シークレットで署名証明書を使用する方法
リンクのコピー

サービスの通信を保護するため、プロジェクト内のシークレットに追加可能な、署名されたサービス証明書/キーペアを生成するように OpenShift Container Platform を設定することができます。

サービス提供証明書のシークレット は、追加設定なしの証明書を必要とする複雑なミドルウェアアプリケーションをサポートするように設計されています。これにはノードおよびマスターの管理者ツールで生成されるサーバー証明書と同じ設定が含まれます。

サービス提供証明書のシークレット用に設定されるサービス Pod 仕様

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert
# ...

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert


# ...

Copy to Clipboard

Toggle word wrap

1: 証明書の名前を指定します。

他の Pod は Pod に自動的にマウントされる /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt ファイルの CA バンドルを使用して、クラスターで作成される証明書 (内部 DNS 名の場合にのみ署名される) を信頼できます。

この機能の署名アルゴリズムは x509.SHA256WithRSA です。ローテーションを手動で実行するには、生成されたシークレットを削除します。新規の証明書が作成されます。

2.7.5.1. シークレットで使用する署名証明書の生成
リンクのコピー

署名されたサービス証明書/キーペアを Pod で使用するには、サービスを作成または編集して service.beta.openshift.io/serving-cert-secret-name アノテーションを追加した後に、シークレットを Pod に追加します。

手順

サービス提供証明書のシークレット を作成するには、以下を実行します。

サービスの Pod 仕様を編集します。

シークレットに使用する名前に service.beta.openshift.io/serving-cert-secret-name アノテーションを追加します。

kind: Service
apiVersion: v1
metadata:
  name: my-service
  annotations:
      service.beta.openshift.io/serving-cert-secret-name: my-cert 
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

kind: Service
apiVersion: v1
metadata:
  name: my-service
  annotations:
      service.beta.openshift.io/serving-cert-secret-name: my-cert


spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

Copy to Clipboard

Toggle word wrap

1: 証明書およびキーは PEM 形式であり、それぞれ tls.crt および tls.key に保存されます。

サービスを作成します。
```
oc create -f <file-name>.yaml
```
```
$ oc create -f <file-name>.yaml
```
Copy to Clipboard Toggle word wrap

シークレットを表示して、作成されていることを確認します。

すべてのシークレットのリストを表示します。

oc get secrets

$ oc get secrets

Copy to Clipboard

Toggle word wrap

出力例

NAME                     TYPE                                  DATA      AGE
my-cert                  kubernetes.io/tls                     2         9m

NAME                     TYPE                                  DATA      AGE
my-cert                  kubernetes.io/tls                     2         9m

Copy to Clipboard

Toggle word wrap

シークレットの詳細を表示します。

oc describe secret my-cert

$ oc describe secret my-cert

Copy to Clipboard

Toggle word wrap

出力例

Name:         my-cert
Namespace:    openshift-console
Labels:       <none>
Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
              service.beta.openshift.io/originating-service-name: my-service
              service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
              service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z

Type:  kubernetes.io/tls

Data
====
tls.key:  1679 bytes
tls.crt:  2595 bytes

Name:         my-cert
Namespace:    openshift-console
Labels:       <none>
Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
              service.beta.openshift.io/originating-service-name: my-service
              service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
              service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z

Type:  kubernetes.io/tls

Data
====
tls.key:  1679 bytes
tls.crt:  2595 bytes

Copy to Clipboard

Toggle word wrap

このシークレットを使用して Pod 仕様を編集します。

apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: my-container
      mountPath: "/etc/my-path"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  volumes:
  - name: my-volume
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511

apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: my-container
      mountPath: "/etc/my-path"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  volumes:
  - name: my-volume
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511

Copy to Clipboard

Toggle word wrap

これが利用可能な場合、Pod が実行されます。この証明書は内部サービス DNS 名、<service.name>.<service.namespace>.svc に適しています。

証明書/キーのペアは有効期限に近づくと自動的に置換されます。シークレットの service.beta.openshift.io/expiry アノテーションで RFC3339 形式の有効期限の日付を確認します。

注記

ほとんどの場合、サービス DNS 名 <service.name>.<service.namespace>.svc は外部にルーティング可能ではありません。<service.name>.<service.namespace>.svc の主な使用方法として、クラスターまたはサービス間の通信用として、re-encrypt ルートで使用されます。

2.7.6. シークレットのトラブルシューティング
リンクのコピー

サービス証明書の生成は以下を出して失敗します (サービスの service.beta.openshift.io/serving-cert-generation-error アノテーションには以下が含まれます)。

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

Copy to Clipboard

Toggle word wrap

証明書を生成したサービスがすでに存在しないか、サービスに異なる serviceUID があります。古いシークレットを削除し、サービスのアノテーション (service.beta.openshift.io/serving-cert-generation-error、service.beta.openshift.io/serving-cert-generation-error-num) をクリアして証明書の再生成を強制的に実行する必要があります。

シークレットを削除します。
```
oc delete secret <secret_name>
```
```
$ oc delete secret <secret_name>
```
Copy to Clipboard Toggle word wrap

アノテーションをクリアします。

oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-

$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-

Copy to Clipboard

Toggle word wrap

oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-

$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-

Copy to Clipboard

Toggle word wrap

注記

アノテーションを削除するコマンドでは、削除するアノテーション名の後に - を付けます。

2.8. 外部シークレットストアを使用した機密データの Pod への提供
リンクのコピー

アプリケーションによっては、パスワードやユーザー名など開発者に使用させない秘密情報が必要になります。

Kubernetes Secret オブジェクトを使用して機密情報を提供する代わりに、外部シークレットストアを使用して機密情報を保存できます。Secrets Store CSI Driver Operator を使用して、外部シークレットストアと統合し、シークレットコンテンツを Pod ボリュームとしてマウントできます。

2.8.1. Secrets Store CSI Driver Operator について
リンクのコピー

Kubernetes シークレットは Base64 エンコーディングで保存されます。etcd は、これらのシークレットの保存時に暗号化しますが、シークレットの取得時に、シークレットが復号化されてユーザーに表示されます。クラスターでロールベースのアクセス制御が適切に設定されていない場合、API または etcd へのアクセス権を持つユーザーは誰でもシークレットを取得または変更できます。さらに、namespace で Pod を作成する権限を持つ人は誰でも、そのアクセス権を使用して、その namespace 内の任意のシークレットを読み取ることができます。

シークレットをセキュアに保存および管理するには、プロバイダープラグインを使用して、Azure Key Vault などの外部シークレット管理システムからシークレットをマウントするように OpenShift Container Platform Secrets Store Container Storage Interface (CSI) Driver Operator を設定できます。アプリケーションはシークレットを使用できますが、アプリケーション Pod が破棄されるとシークレットはシステム上に保持されません。

Secrets Store CSI Driver Operator (secrets-store.csi.k8s.io) を使用すると、OpenShift Container Platform で、エンタープライズグレードの外部シークレットストアに保存されている複数のシークレット、キー、証明書をボリュームとして Pod にマウントできます。Secrets Store CSI Driver Operator は、gRPC を使用してプロバイダーと通信し、指定された外部シークレットストアからマウントコンテンツを取得します。ボリュームがアタッチされると、その中のデータがコンテナーのファイルシステムにマウントされます。シークレットストアボリュームはインラインでマウントされます。

2.8.1.1. シークレットストアプロバイダー
リンクのコピー

Secrets Store CSI Driver Operator は、次のシークレットストアプロバイダーでテストされています。

AWS Secrets Manager
AWS Systems Manager Parameter Store
Azure Key Vault
Google Secret Manager
HashiCorp Vault

注記

Red Hat は、サードパーティーのシークレットストアプロバイダーの機能に関連するすべての要素をテストしているわけではありません。サードパーティーのサポートの詳細は、Red Hat サードパーティーサポートポリシーを参照してください。

2.8.1.2. 自動ローテーション
リンクのコピー

Secrets Store CSI ドライバーは、外部シークレットストアのコンテンツを使用して、マウントされたボリューム内のコンテンツを定期的にローテーションします。外部シークレットストアでシークレットが更新されると、マウントされたボリュームでもシークレットが更新されます。Secrets Store CSI Driver Operator は、2 分ごとに更新をポーリングします。

Kubernetes シークレットとしてマウントされたコンテンツの同期を有効にした場合は、Kubernetes シークレットもローテーションされます。

シークレットデータを使用するアプリケーションは、シークレットの更新を監視する必要があります。

2.8.2. Secrets Store CSI ドライバーのインストール
リンクのコピー

前提条件

OpenShift Container Platform Web コンソールにアクセスできる。
管理者としてクラスターにアクセスできる。

手順

Secrets Store CSI ドライバーをインストールするには、以下を実行します。

Secrets Store CSI Driver Operator をインストールします。
1. Web コンソールにログインします。
2. Ecosystem → Software Catalog をクリックします。
3. フィルターボックスに "Secrets Store CSI" と入力し、Secrets Store CSI Driver Operator を見つけます。
4. Secrets Store CSI Driver Operator ボタンをクリックします。
5. Secrets Store CSI Driver Operator ページで、Install をクリックします。
6. Install Operator のページで、以下のことを確認してください。
  - All namespaces on the cluster (default) が選択されている。
  - Installed Namespace が openshift-cluster-csi-drivers に設定されている。
7. Install をクリックします。
  インストールが終了すると、Web コンソールの Installed Operators セクションに Secrets Store CSI Driver Operator がリストされます。
ドライバーの ClusterCSIDriver インスタンス (secrets-store.csi.k8s.io) を作成します。
1. Administration → CustomResourceDefinitions → ClusterCSIDriver をクリックします。
2. Instances タブで Create ClusterCSIDriver をクリックします。
  以下の YAML ファイルを使用します。
  apiVersion: operator.openshift.io/v1 kind: ClusterCSIDriver metadata: name: secrets-store.csi.k8s.io spec: managementState: Managed
  Copy to Clipboard Toggle word wrap
3. Create をクリックします。

2.8.3. 外部シークレットストアから CSI ボリュームへのシークレットのマウント
リンクのコピー

Secrets Store CSI Driver Operator をインストールした後、次のいずれかの外部シークレットストアから CSI ボリュームにシークレットをマウントできます。

AWS Secrets Manager
AWS Systems Manager Parameter Store
Azure Key Vault
Google Secret Manager
HashiCorp Vault

2.8.3.1. AWS Secrets Manager からのシークレットのマウント
リンクのコピー

Secrets Store CSI Driver Operator を使用して、AWS Secrets Manager の外部シークレットストアから OpenShift Container Platform の Container Storage Interface (CSI) ボリュームにシークレットをマウントできます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
jq ツールをインストールした。
ccoctl ユーティリティーを抽出して準備した。
クラスターを Amazon Web Services (AWS) にインストールしており、そのクラスターは AWS Security Token Service (STS) を使用する。
Secrets Store CSI Driver Operator がインストールされている。詳細は、「Secrets Store CSI ドライバーのインストール」を参照してください。
必要なシークレットを格納するように AWS Secrets Manager を設定している。

手順

AWS Secrets Manager プロバイダーをインストールします。

次の設定例を使用して YAML ファイルを作成します。

重要

Secrets Store CSI ドライバーの AWS Secrets Manager プロバイダーは、アップストリームプロバイダーです。

この設定は、OpenShift Container Platform で適切に動作するように、アップストリームの AWS ドキュメントで提供されている設定から変更されています。この設定を変更すると、機能に影響が出る場合があります。

aws-provider.yaml ファイルの例

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-aws-cluster-role
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-aws-cluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-aws-cluster-role
subjects:
- kind: ServiceAccount
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: openshift-cluster-csi-drivers
  name: csi-secrets-store-provider-aws
  labels:
    app: csi-secrets-store-provider-aws
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-aws
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-aws
    spec:
      serviceAccountName: csi-secrets-store-provider-aws
      hostNetwork: false
      containers:
        - name: provider-aws-installer
          image: public.ecr.aws/aws-secrets-manager/secrets-store-csi-driver-provider-aws:1.0.r2-50-g5b4aca1-2023.06.09.21.19
          imagePullPolicy: Always
          args:
              - --provider-volume=/etc/kubernetes/secrets-store-csi-providers
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          securityContext:
            privileged: true
          volumeMounts:
            - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
              name: providervol
            - name: mountpoint-dir
              mountPath: /var/lib/kubelet/pods
              mountPropagation: HostToContainer
      tolerations:
      - operator: Exists
      volumes:
        - name: providervol
          hostPath:
            path: "/etc/kubernetes/secrets-store-csi-providers"
        - name: mountpoint-dir
          hostPath:
            path: /var/lib/kubelet/pods
            type: DirectoryOrCreate
      nodeSelector:
        kubernetes.io/os: linux

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-aws-cluster-role
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-aws-cluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-aws-cluster-role
subjects:
- kind: ServiceAccount
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: openshift-cluster-csi-drivers
  name: csi-secrets-store-provider-aws
  labels:
    app: csi-secrets-store-provider-aws
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-aws
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-aws
    spec:
      serviceAccountName: csi-secrets-store-provider-aws
      hostNetwork: false
      containers:
        - name: provider-aws-installer
          image: public.ecr.aws/aws-secrets-manager/secrets-store-csi-driver-provider-aws:1.0.r2-50-g5b4aca1-2023.06.09.21.19
          imagePullPolicy: Always
          args:
              - --provider-volume=/etc/kubernetes/secrets-store-csi-providers
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          securityContext:
            privileged: true
          volumeMounts:
            - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
              name: providervol
            - name: mountpoint-dir
              mountPath: /var/lib/kubelet/pods
              mountPropagation: HostToContainer
      tolerations:
      - operator: Exists
      volumes:
        - name: providervol
          hostPath:
            path: "/etc/kubernetes/secrets-store-csi-providers"
        - name: mountpoint-dir
          hostPath:
            path: /var/lib/kubelet/pods
            type: DirectoryOrCreate
      nodeSelector:
        kubernetes.io/os: linux

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、csi-secrets-store-provider-aws サービスアカウントへの特権アクセスを付与します。

oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-drivers

$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-drivers

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、プロバイダーリソースを作成します。
```
oc apply -f aws-provider.yaml
```
```
$ oc apply -f aws-provider.yaml
```
Copy to Clipboard Toggle word wrap

AWS シークレットオブジェクトの読み取り権限をサービスアカウントに付与します。

次のコマンドを実行して、認証情報リクエストを含むディレクトリーを作成します。
```
mkdir <aws_creds_directory_name>
```
```
$ mkdir <aws_creds_directory_name>
```
Copy to Clipboard Toggle word wrap

CredentialsRequest リソース設定を定義する YAML ファイルを作成します。次の設定例を参照してください。

apiVersion: cloudcredential.openshift.io/v1
kind: CredentialsRequest
metadata:
  name: aws-creds-request
  namespace: openshift-cloud-credential-operator
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
    - action:
      - "secretsmanager:GetSecretValue"
      - "secretsmanager:DescribeSecret"
      effect: Allow
      resource: "arn:*:secretsmanager:*:*:secret:testSecret-??????"
  secretRef:
    name: aws-creds
    namespace: my-namespace
  serviceAccountNames:
  - <service_account_name>

apiVersion: cloudcredential.openshift.io/v1
kind: CredentialsRequest
metadata:
  name: aws-creds-request
  namespace: openshift-cloud-credential-operator
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
    - action:
      - "secretsmanager:GetSecretValue"
      - "secretsmanager:DescribeSecret"
      effect: Allow
      resource: "arn:*:secretsmanager:*:*:secret:testSecret-??????"
  secretRef:
    name: aws-creds
    namespace: my-namespace
  serviceAccountNames:
  - <service_account_name>

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、OpenID Connect (OIDC) プロバイダーを取得します。
```
oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'
```
```
$ oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'
```
Copy to Clipboard Toggle word wrap
出力例
```
https://<oidc_provider_name>
```
```
https://<oidc_provider_name>
```
Copy to Clipboard Toggle word wrap
次のステップで使用するために、出力から OIDC プロバイダー名 <oidc_provider_name> をコピーします。

ccoctl ツールを使用して、次のコマンドを実行して認証情報リクエストを処理します。

ccoctl aws create-iam-roles \
    --name my-role --region=<aws_region> \
    --credentials-requests-dir=<aws_creds_dir_name> \
    --identity-provider-arn arn:aws:iam::<aws_account_id>:oidc-provider/<oidc_provider_name> --output-dir=<output_dir_name>

$ ccoctl aws create-iam-roles \
    --name my-role --region=<aws_region> \
    --credentials-requests-dir=<aws_creds_dir_name> \
    --identity-provider-arn arn:aws:iam::<aws_account_id>:oidc-provider/<oidc_provider_name> --output-dir=<output_dir_name>

Copy to Clipboard

Toggle word wrap

出力例

2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created
2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml
2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-creds

2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created
2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml
2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-creds

Copy to Clipboard

Toggle word wrap

次のステップで使用するために、出力から <aws_role_arn> をコピーします。たとえば、arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds です

次のコマンドを実行して、ロール ARN を持つサービスアカウントをバインドします。

oc annotate -n my-namespace sa/aws-provider eks.amazonaws.com/role-arn="<aws_role_arn>"

$ oc annotate -n my-namespace sa/aws-provider eks.amazonaws.com/role-arn="<aws_role_arn>"

Copy to Clipboard

Toggle word wrap

シークレットプロバイダークラスを作成して、シークレットストアプロバイダーを定義します。

SecretProviderClass オブジェクトを定義する YAML ファイルを作成します。

secret-provider-class-aws.yaml の例

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-aws-provider                   
  namespace: my-namespace                 
spec:
  provider: aws                           
  parameters:                             
    objects: |
      - objectName: "testSecret"
        objectType: "secretsmanager"

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-aws-provider


  namespace: my-namespace


spec:
  provider: aws


  parameters:


    objects: |
      - objectName: "testSecret"
        objectType: "secretsmanager"

Copy to Clipboard

Toggle word wrap

1: シークレットプロバイダークラスの名前を指定します。
2: シークレットプロバイダークラスの namespace を指定します。
3: プロバイダーを aws として指定します。
4: プロバイダー固有の設定パラメーターを指定します。

次のコマンドを実行して SecretProviderClass オブジェクトを作成します。
```
oc create -f secret-provider-class-aws.yaml
```
```
$ oc create -f secret-provider-class-aws.yaml
```
Copy to Clipboard Toggle word wrap

このシークレットプロバイダークラスを使用するデプロイメントを作成します。

Deployment オブジェクトを定義する YAML ファイルを作成します。

deployment.yaml の例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-aws-deployment                              
  namespace: my-namespace                              
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-storage
  template:
    metadata:
      labels:
        app: my-storage
    spec:
      serviceAccountName: aws-provider
      containers:
      - name: busybox
        image: k8s.gcr.io/e2e-test-images/busybox:1.29
        command:
          - "/bin/sleep"
          - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-aws-provider"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-aws-deployment


  namespace: my-namespace


spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-storage
  template:
    metadata:
      labels:
        app: my-storage
    spec:
      serviceAccountName: aws-provider
      containers:
      - name: busybox
        image: k8s.gcr.io/e2e-test-images/busybox:1.29
        command:
          - "/bin/sleep"
          - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-aws-provider"

Copy to Clipboard

Toggle word wrap

1: デプロイメントの名前を指定します。
2: デプロイメントの namespace を指定します。これは、シークレットプロバイダークラスと同じ namespace である必要があります。
3: シークレットプロバイダークラスの名前を指定します。

次のコマンドを実行して、Deployment オブジェクトを作成します。
```
oc create -f deployment.yaml
```
```
$ oc create -f deployment.yaml
```
Copy to Clipboard Toggle word wrap

検証

Pod ボリュームマウントの AWS Secrets Manager からシークレットにアクセスできることを確認します。
1. 次のコマンドを実行して、Pod マウント内のシークレットをリスト表示します。
  $ oc exec my-aws-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
  Copy to Clipboard Toggle word wrap
  出力例
  testSecret
  
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、Pod マウント内のシークレットを表示します。
  $ oc exec my-aws-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecret
  Copy to Clipboard Toggle word wrap
  出力例
  <secret_value>
  
  Copy to Clipboard Toggle word wrap

2.8.3.2. AWS Systems Manager Parameter Store からのシークレットのマウント
リンクのコピー

Secrets Store CSI Driver Operator を使用して、AWS Systems Manager Parameter Store の外部シークレットストアから OpenShift Container Platform の Container Storage Interface (CSI) ボリュームにシークレットをマウントできます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
jq ツールをインストールした。
ccoctl ユーティリティーを抽出して準備した。
クラスターを Amazon Web Services (AWS) にインストールしており、そのクラスターは AWS Security Token Service (STS) を使用する。
Secrets Store CSI Driver Operator がインストールされている。詳細は、「Secrets Store CSI ドライバーのインストール」を参照してください。
必要なシークレットを保存するように AWS Systems Manager パラメーターストアを設定している。

手順

AWS Systems Manager Parameter Store プロバイダーをインストールします。

次の設定例を使用して YAML ファイルを作成します。

重要

Secrets Store CSI ドライバーの AWS Systems Manager Parameter Store プロバイダーは、アップストリームのプロバイダーです。

aws-provider.yaml ファイルの例

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-aws-cluster-role
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-aws-cluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-aws-cluster-role
subjects:
- kind: ServiceAccount
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: openshift-cluster-csi-drivers
  name: csi-secrets-store-provider-aws
  labels:
    app: csi-secrets-store-provider-aws
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-aws
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-aws
    spec:
      serviceAccountName: csi-secrets-store-provider-aws
      hostNetwork: false
      containers:
        - name: provider-aws-installer
          image: public.ecr.aws/aws-secrets-manager/secrets-store-csi-driver-provider-aws:1.0.r2-50-g5b4aca1-2023.06.09.21.19
          imagePullPolicy: Always
          args:
              - --provider-volume=/etc/kubernetes/secrets-store-csi-providers
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          securityContext:
            privileged: true
          volumeMounts:
            - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
              name: providervol
            - name: mountpoint-dir
              mountPath: /var/lib/kubelet/pods
              mountPropagation: HostToContainer
      tolerations:
      - operator: Exists
      volumes:
        - name: providervol
          hostPath:
            path: "/etc/kubernetes/secrets-store-csi-providers"
        - name: mountpoint-dir
          hostPath:
            path: /var/lib/kubelet/pods
            type: DirectoryOrCreate
      nodeSelector:
        kubernetes.io/os: linux

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-aws-cluster-role
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-aws-cluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-aws-cluster-role
subjects:
- kind: ServiceAccount
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: openshift-cluster-csi-drivers
  name: csi-secrets-store-provider-aws
  labels:
    app: csi-secrets-store-provider-aws
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-aws
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-aws
    spec:
      serviceAccountName: csi-secrets-store-provider-aws
      hostNetwork: false
      containers:
        - name: provider-aws-installer
          image: public.ecr.aws/aws-secrets-manager/secrets-store-csi-driver-provider-aws:1.0.r2-50-g5b4aca1-2023.06.09.21.19
          imagePullPolicy: Always
          args:
              - --provider-volume=/etc/kubernetes/secrets-store-csi-providers
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          securityContext:
            privileged: true
          volumeMounts:
            - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
              name: providervol
            - name: mountpoint-dir
              mountPath: /var/lib/kubelet/pods
              mountPropagation: HostToContainer
      tolerations:
      - operator: Exists
      volumes:
        - name: providervol
          hostPath:
            path: "/etc/kubernetes/secrets-store-csi-providers"
        - name: mountpoint-dir
          hostPath:
            path: /var/lib/kubelet/pods
            type: DirectoryOrCreate
      nodeSelector:
        kubernetes.io/os: linux

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、csi-secrets-store-provider-aws サービスアカウントへの特権アクセスを付与します。

oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-drivers

$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-drivers

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、プロバイダーリソースを作成します。
```
oc apply -f aws-provider.yaml
```
```
$ oc apply -f aws-provider.yaml
```
Copy to Clipboard Toggle word wrap

AWS シークレットオブジェクトの読み取り権限をサービスアカウントに付与します。

次のコマンドを実行して、認証情報リクエストを含むディレクトリーを作成します。
```
mkdir <aws_creds_directory_name>
```
```
$ mkdir <aws_creds_directory_name>
```
Copy to Clipboard Toggle word wrap

CredentialsRequest リソース設定を定義する YAML ファイルを作成します。次の設定例を参照してください。

apiVersion: cloudcredential.openshift.io/v1
kind: CredentialsRequest
metadata:
  name: aws-creds-request
  namespace: openshift-cloud-credential-operator
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
    - action:
      - "ssm:GetParameter"
      - "ssm:GetParameters"
      effect: Allow
      resource: "arn:*:ssm:*:*:parameter/testParameter*"
  secretRef:
    name: aws-creds
    namespace: my-namespace
  serviceAccountNames:
  - <service_account_name>

apiVersion: cloudcredential.openshift.io/v1
kind: CredentialsRequest
metadata:
  name: aws-creds-request
  namespace: openshift-cloud-credential-operator
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
    - action:
      - "ssm:GetParameter"
      - "ssm:GetParameters"
      effect: Allow
      resource: "arn:*:ssm:*:*:parameter/testParameter*"
  secretRef:
    name: aws-creds
    namespace: my-namespace
  serviceAccountNames:
  - <service_account_name>

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、OpenID Connect (OIDC) プロバイダーを取得します。
```
oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'
```
```
$ oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'
```
Copy to Clipboard Toggle word wrap
出力例
```
https://<oidc_provider_name>
```
```
https://<oidc_provider_name>
```
Copy to Clipboard Toggle word wrap
次のステップで使用するために、出力から OIDC プロバイダー名 <oidc_provider_name> をコピーします。

ccoctl ツールを使用して、次のコマンドを実行して認証情報リクエストを処理します。

ccoctl aws create-iam-roles \
    --name my-role --region=<aws_region> \
    --credentials-requests-dir=<aws_creds_dir_name> \
    --identity-provider-arn arn:aws:iam::<aws_account_id>:oidc-provider/<oidc_provider_name> --output-dir=<output_dir_name>

$ ccoctl aws create-iam-roles \
    --name my-role --region=<aws_region> \
    --credentials-requests-dir=<aws_creds_dir_name> \
    --identity-provider-arn arn:aws:iam::<aws_account_id>:oidc-provider/<oidc_provider_name> --output-dir=<output_dir_name>

Copy to Clipboard

Toggle word wrap

出力例

2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created
2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml
2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-creds

2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created
2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml
2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-creds

Copy to Clipboard

Toggle word wrap

次のステップで使用するために、出力から <aws_role_arn> をコピーします。たとえば、arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds です

次のコマンドを実行して、ロール ARN を持つサービスアカウントをバインドします。

oc annotate -n my-namespace sa/aws-provider eks.amazonaws.com/role-arn="<aws_role_arn>"

$ oc annotate -n my-namespace sa/aws-provider eks.amazonaws.com/role-arn="<aws_role_arn>"

Copy to Clipboard

Toggle word wrap

シークレットプロバイダークラスを作成して、シークレットストアプロバイダーを定義します。

SecretProviderClass オブジェクトを定義する YAML ファイルを作成します。

secret-provider-class-aws.yaml の例

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-aws-provider                   
  namespace: my-namespace                 
spec:
  provider: aws                           
  parameters:                             
    objects: |
      - objectName: "testParameter"
        objectType: "ssmparameter"

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-aws-provider


  namespace: my-namespace


spec:
  provider: aws


  parameters:


    objects: |
      - objectName: "testParameter"
        objectType: "ssmparameter"

Copy to Clipboard

Toggle word wrap

1: シークレットプロバイダークラスの名前を指定します。
2: シークレットプロバイダークラスの namespace を指定します。
3: プロバイダーを aws として指定します。
4: プロバイダー固有の設定パラメーターを指定します。

次のコマンドを実行して SecretProviderClass オブジェクトを作成します。
```
oc create -f secret-provider-class-aws.yaml
```
```
$ oc create -f secret-provider-class-aws.yaml
```
Copy to Clipboard Toggle word wrap

このシークレットプロバイダークラスを使用するデプロイメントを作成します。

Deployment オブジェクトを定義する YAML ファイルを作成します。

deployment.yaml の例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-aws-deployment                              
  namespace: my-namespace                              
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-storage
  template:
    metadata:
      labels:
        app: my-storage
    spec:
      serviceAccountName: aws-provider
      containers:
      - name: busybox
        image: k8s.gcr.io/e2e-test-images/busybox:1.29
        command:
          - "/bin/sleep"
          - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-aws-provider"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-aws-deployment


  namespace: my-namespace


spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-storage
  template:
    metadata:
      labels:
        app: my-storage
    spec:
      serviceAccountName: aws-provider
      containers:
      - name: busybox
        image: k8s.gcr.io/e2e-test-images/busybox:1.29
        command:
          - "/bin/sleep"
          - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-aws-provider"

Copy to Clipboard

Toggle word wrap

1: デプロイメントの名前を指定します。
2: デプロイメントの namespace を指定します。これは、シークレットプロバイダークラスと同じ namespace である必要があります。
3: シークレットプロバイダークラスの名前を指定します。

次のコマンドを実行して、Deployment オブジェクトを作成します。
```
oc create -f deployment.yaml
```
```
$ oc create -f deployment.yaml
```
Copy to Clipboard Toggle word wrap

検証

Pod ボリュームマウント内の AWS Systems Manager Parameter Store からのシークレットにアクセスできることを確認します。
1. 次のコマンドを実行して、Pod マウント内のシークレットをリスト表示します。
  $ oc exec my-aws-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
  Copy to Clipboard Toggle word wrap
  出力例
  testParameter
  
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、Pod マウント内のシークレットを表示します。
  $ oc exec my-aws-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecret
  Copy to Clipboard Toggle word wrap
  出力例
  <secret_value>
  
  Copy to Clipboard Toggle word wrap

2.8.3.3. Azure Key Vault からのシークレットのマウント
リンクのコピー

Secrets Store CSI Driver Operator を使用して、Microsoft Azure Key Vault から OpenShift Container Platform の Container Storage Interface (CSI) ボリュームにシークレットをマウントできます。Azure Key Vault からシークレットをマウントするには、以下を実行します。

前提条件

Azure にクラスターをインストールした。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
Azure CLI (az) がインストールされている。
Secrets Store CSI Driver Operator がインストールされている。手順は、「Secrets Store CSI ドライバーのインストール」を参照してください。
必要なシークレットを保存するように Azure Key Vault を設定している。

手順

Azure Key Vault プロバイダーをインストールします。

ServiceAccount リソース設定を定義する、azure-provider.yaml という名前の YAML ファイルを作成します。次の設定例を参照してください。

重要

Secrets Store CSI ドライバーの Azure Key Vault プロバイダーは、アップストリームプロバイダーです。

この設定は、OpenShift Container Platform で適切に動作するように、アップストリームの Azure ドキュメントで提供されている設定から変更されています。この設定を変更すると、機能に影響が出る場合があります。

azure-provider.yaml ファイルの例

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-azure
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-azure-cluster-role
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-azure-cluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-azure-cluster-role
subjects:
- kind: ServiceAccount
  name: csi-secrets-store-provider-azure
  namespace: openshift-cluster-csi-drivers
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: openshift-cluster-csi-drivers
  name: csi-secrets-store-provider-azure
  labels:
    app: csi-secrets-store-provider-azure
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-azure
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-azure
    spec:
      serviceAccountName: csi-secrets-store-provider-azure
      hostNetwork: true
      containers:
        - name: provider-azure-installer
          image: mcr.microsoft.com/oss/azure/secrets-store/provider-azure:v1.4.1
          imagePullPolicy: IfNotPresent
          args:
            - --endpoint=unix:///provider/azure.sock
            - --construct-pem-chain=true
            - --healthz-port=8989
            - --healthz-path=/healthz
            - --healthz-timeout=5s
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8989
            failureThreshold: 3
            initialDelaySeconds: 5
            timeoutSeconds: 10
            periodSeconds: 30
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsUser: 0
            capabilities:
              drop:
              - ALL
          volumeMounts:
            - mountPath: "/provider"
              name: providervol
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
      volumes:
        - name: providervol
          hostPath:
            path: "/var/run/secrets-store-csi-providers"
      tolerations:
      - operator: Exists
      nodeSelector:
        kubernetes.io/os: linux

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-azure
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-azure-cluster-role
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-azure-cluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-azure-cluster-role
subjects:
- kind: ServiceAccount
  name: csi-secrets-store-provider-azure
  namespace: openshift-cluster-csi-drivers
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: openshift-cluster-csi-drivers
  name: csi-secrets-store-provider-azure
  labels:
    app: csi-secrets-store-provider-azure
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-azure
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-azure
    spec:
      serviceAccountName: csi-secrets-store-provider-azure
      hostNetwork: true
      containers:
        - name: provider-azure-installer
          image: mcr.microsoft.com/oss/azure/secrets-store/provider-azure:v1.4.1
          imagePullPolicy: IfNotPresent
          args:
            - --endpoint=unix:///provider/azure.sock
            - --construct-pem-chain=true
            - --healthz-port=8989
            - --healthz-path=/healthz
            - --healthz-timeout=5s
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8989
            failureThreshold: 3
            initialDelaySeconds: 5
            timeoutSeconds: 10
            periodSeconds: 30
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsUser: 0
            capabilities:
              drop:
              - ALL
          volumeMounts:
            - mountPath: "/provider"
              name: providervol
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
      volumes:
        - name: providervol
          hostPath:
            path: "/var/run/secrets-store-csi-providers"
      tolerations:
      - operator: Exists
      nodeSelector:
        kubernetes.io/os: linux

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、csi-secrets-store-provider-azure サービスアカウントへの特権アクセスを付与します。

oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-azure -n openshift-cluster-csi-drivers

$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-azure -n openshift-cluster-csi-drivers

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、プロバイダーリソースを作成します。
```
oc apply -f azure-provider.yaml
```
```
$ oc apply -f azure-provider.yaml
```
Copy to Clipboard Toggle word wrap

Key Vault にアクセスするためのサービスプリンシパルを作成します。

次のコマンドを実行して、サービスプリンシパルのクライアントシークレットを環境変数として設定します。

SERVICE_PRINCIPAL_CLIENT_SECRET="$(az ad sp create-for-rbac --name https://$KEYVAULT_NAME --query 'password' -otsv)"

$ SERVICE_PRINCIPAL_CLIENT_SECRET="$(az ad sp create-for-rbac --name https://$KEYVAULT_NAME --query 'password' -otsv)"

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、サービスプリンシパルのクライアント ID を環境変数として設定します。

SERVICE_PRINCIPAL_CLIENT_ID="$(az ad sp list --display-name https://$KEYVAULT_NAME --query '[0].appId' -otsv)"

$ SERVICE_PRINCIPAL_CLIENT_ID="$(az ad sp list --display-name https://$KEYVAULT_NAME --query '[0].appId' -otsv)"

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、サービスプリンシパルのクライアントシークレットと ID を使用して汎用シークレットを作成します。

oc create secret generic secrets-store-creds -n my-namespace --from-literal clientid=${SERVICE_PRINCIPAL_CLIENT_ID} --from-literal clientsecret=${SERVICE_PRINCIPAL_CLIENT_SECRET}

$ oc create secret generic secrets-store-creds -n my-namespace --from-literal clientid=${SERVICE_PRINCIPAL_CLIENT_ID} --from-literal clientsecret=${SERVICE_PRINCIPAL_CLIENT_SECRET}

Copy to Clipboard

Toggle word wrap

secrets-store.csi.k8s.io/used=true ラベルを適用して、プロバイダーがこの nodePublishSecretRef シークレットを検索できるようにします。
```
oc -n my-namespace label secret secrets-store-creds secrets-store.csi.k8s.io/used=true
```
```
$ oc -n my-namespace label secret secrets-store-creds secrets-store.csi.k8s.io/used=true
```
Copy to Clipboard Toggle word wrap

シークレットプロバイダークラスを作成して、シークレットストアプロバイダーを定義します。

SecretProviderClass オブジェクトを定義する YAML ファイルを作成します。

secret-provider-class-azure.yaml の例

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-azure-provider                 
  namespace: my-namespace                 
spec:
  provider: azure                         
  parameters:                             
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    userAssignedIdentityID: ""
    keyvaultName: "kvname"
    objects: |
      array:
        - |
          objectName: secret1
          objectType: secret
    tenantId: "tid"

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-azure-provider


  namespace: my-namespace


spec:
  provider: azure


  parameters:


    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    userAssignedIdentityID: ""
    keyvaultName: "kvname"
    objects: |
      array:
        - |
          objectName: secret1
          objectType: secret
    tenantId: "tid"

Copy to Clipboard

Toggle word wrap

1: シークレットプロバイダークラスの名前を指定します。
2: シークレットプロバイダークラスの namespace を指定します。
3: プロバイダーを azure として指定します。
4: プロバイダー固有の設定パラメーターを指定します。

次のコマンドを実行して SecretProviderClass オブジェクトを作成します。
```
oc create -f secret-provider-class-azure.yaml
```
```
$ oc create -f secret-provider-class-azure.yaml
```
Copy to Clipboard Toggle word wrap

このシークレットプロバイダークラスを使用するデプロイメントを作成します。

Deployment オブジェクトを定義する YAML ファイルを作成します。

deployment.yaml の例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-azure-deployment                            
  namespace: my-namespace                              
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-storage
  template:
    metadata:
      labels:
        app: my-storage
    spec:
      containers:
      - name: busybox
        image: k8s.gcr.io/e2e-test-images/busybox:1.29
        command:
          - "/bin/sleep"
          - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-azure-provider" 
            nodePublishSecretRef:
              name: secrets-store-creds

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-azure-deployment


  namespace: my-namespace


spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-storage
  template:
    metadata:
      labels:
        app: my-storage
    spec:
      containers:
      - name: busybox
        image: k8s.gcr.io/e2e-test-images/busybox:1.29
        command:
          - "/bin/sleep"
          - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-azure-provider"


            nodePublishSecretRef:
              name: secrets-store-creds

Copy to Clipboard

Toggle word wrap

1: デプロイメントの名前を指定します。
2: デプロイメントの namespace を指定します。これは、シークレットプロバイダークラスと同じ namespace である必要があります。
3: シークレットプロバイダークラスの名前を指定します。
4: Azure Key Vault にアクセスするためのサービスプリンシパル認証情報を含む Kubernetes シークレットの名前を指定します。

次のコマンドを実行して、Deployment オブジェクトを作成します。
```
oc create -f deployment.yaml
```
```
$ oc create -f deployment.yaml
```
Copy to Clipboard Toggle word wrap

検証

Pod ボリュームマウント内の Azure Key Vault からシークレットにアクセスできることを確認します。
1. 次のコマンドを実行して、Pod マウント内のシークレットをリスト表示します。
  $ oc exec my-azure-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
  Copy to Clipboard Toggle word wrap
  出力例
  secret1
  
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、Pod マウント内のシークレットを表示します。
  $ oc exec my-azure-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/secret1
  Copy to Clipboard Toggle word wrap
  出力例
  my-secret-value
  
  Copy to Clipboard Toggle word wrap

2.8.3.4. Google Secret Manager からのシークレットのマウント
リンクのコピー

Secrets Store CSI Driver Operator を使用して、Google Secret Manager から OpenShift Container Platform の Container Storage Interface (CSI) ボリュームにシークレットをマウントできます。Google Secret Manager からシークレットをマウントするには、クラスターが Google Cloud にインストールされている必要があります。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
Secrets Store CSI Driver Operator がインストールされている。手順は、「Secrets Store CSI ドライバーのインストール」を参照してください。
必要なシークレットを保存するように Google Secret Manager を設定した。
Google Cloud サービスアカウントから key.json という名前のサービスアカウントキーを作成した。

手順

Google Secret Manager プロバイダーをインストールします。

ServiceAccount リソース設定を定義する、gcp-provider.yaml という名前の YAML ファイルを作成します。次の設定例を参照してください。

gcp-provider.yaml ファイルの例

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-gcp
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-gcp-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-gcp-role
subjects:
  - kind: ServiceAccount
    name: csi-secrets-store-provider-gcp
    namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-gcp-role
rules:
  - apiGroups:
      - ""
    resources:
      - serviceaccounts/token
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - serviceaccounts
    verbs:
      - get
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: csi-secrets-store-provider-gcp
  namespace: openshift-cluster-csi-drivers
  labels:
    app: csi-secrets-store-provider-gcp
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-gcp
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-gcp
    spec:
      serviceAccountName: csi-secrets-store-provider-gcp
      initContainers:
      - name: chown-provider-mount
        image: busybox
        command:
        - chown
        - "1000:1000"
        - /etc/kubernetes/secrets-store-csi-providers
        volumeMounts:
        - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
          name: providervol
        securityContext:
          privileged: true
      hostNetwork: false
      hostPID: false
      hostIPC: false
      containers:
        - name: provider
          image: us-docker.pkg.dev/secretmanager-csi/secrets-store-csi-driver-provider-gcp/plugin@sha256:a493a78bbb4ebce5f5de15acdccc6f4d19486eae9aa4fa529bb60ac112dd6650
          securityContext:
            privileged: true
          imagePullPolicy: IfNotPresent
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          env:
            - name: TARGET_DIR
              value: "/etc/kubernetes/secrets-store-csi-providers"
          volumeMounts:
            - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
              name: providervol
              mountPropagation: None
              readOnly: false
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /live
              port: 8095
            initialDelaySeconds: 5
            timeoutSeconds: 10
            periodSeconds: 30
      volumes:
        - name: providervol
          hostPath:
            path: /etc/kubernetes/secrets-store-csi-providers
      tolerations:
        - key: kubernetes.io/arch
          operator: Equal
          value: amd64
          effect: NoSchedule
      nodeSelector:
        kubernetes.io/os: linux

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-gcp
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-gcp-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-gcp-role
subjects:
  - kind: ServiceAccount
    name: csi-secrets-store-provider-gcp
    namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-gcp-role
rules:
  - apiGroups:
      - ""
    resources:
      - serviceaccounts/token
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - serviceaccounts
    verbs:
      - get
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: csi-secrets-store-provider-gcp
  namespace: openshift-cluster-csi-drivers
  labels:
    app: csi-secrets-store-provider-gcp
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-gcp
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-gcp
    spec:
      serviceAccountName: csi-secrets-store-provider-gcp
      initContainers:
      - name: chown-provider-mount
        image: busybox
        command:
        - chown
        - "1000:1000"
        - /etc/kubernetes/secrets-store-csi-providers
        volumeMounts:
        - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
          name: providervol
        securityContext:
          privileged: true
      hostNetwork: false
      hostPID: false
      hostIPC: false
      containers:
        - name: provider
          image: us-docker.pkg.dev/secretmanager-csi/secrets-store-csi-driver-provider-gcp/plugin@sha256:a493a78bbb4ebce5f5de15acdccc6f4d19486eae9aa4fa529bb60ac112dd6650
          securityContext:
            privileged: true
          imagePullPolicy: IfNotPresent
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          env:
            - name: TARGET_DIR
              value: "/etc/kubernetes/secrets-store-csi-providers"
          volumeMounts:
            - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
              name: providervol
              mountPropagation: None
              readOnly: false
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /live
              port: 8095
            initialDelaySeconds: 5
            timeoutSeconds: 10
            periodSeconds: 30
      volumes:
        - name: providervol
          hostPath:
            path: /etc/kubernetes/secrets-store-csi-providers
      tolerations:
        - key: kubernetes.io/arch
          operator: Equal
          value: amd64
          effect: NoSchedule
      nodeSelector:
        kubernetes.io/os: linux

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、csi-secrets-store-provider-gcp サービスアカウントに特権アクセスを付与します。

oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-gcp -n openshift-cluster-csi-drivers

$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-gcp -n openshift-cluster-csi-drivers

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、プロバイダーリソースを作成します。
```
oc apply -f gcp-provider.yaml
```
```
$ oc apply -f gcp-provider.yaml
```
Copy to Clipboard Toggle word wrap

Google Secret Manager シークレットに読み取り権限を付与します。
1. 次のコマンドを実行して新しいプロジェクトを作成します。
  $ oc new-project my-namespace
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、Pod セキュリティーアドミッション用の my-namespace namespace にラベルを付けます。
  $ oc label ns my-namespace security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwrite
  Copy to Clipboard Toggle word wrap
3. Pod のデプロイメント用のサービスアカウントを作成します。
  $ oc create serviceaccount my-service-account --namespace=my-namespace
  Copy to Clipboard Toggle word wrap
4. 次のコマンドを実行して、key.json ファイルから汎用シークレットを作成します。
  $ oc create secret generic secrets-store-creds -n my-namespace --from-file=key.json
  1
  Copy to Clipboard Toggle word wrap
  1
  この key.json ファイルは Google Secret Manager から作成したものです。
5. secrets-store.csi.k8s.io/used=true ラベルを適用して、プロバイダーがこの nodePublishSecretRef シークレットを検索できるようにします。
  $ oc -n my-namespace label secret secrets-store-creds secrets-store.csi.k8s.io/used=true
  Copy to Clipboard Toggle word wrap

シークレットプロバイダークラスを作成して、シークレットストアプロバイダーを定義します。

SecretProviderClass オブジェクトを定義する YAML ファイルを作成します。

secret-provider-class-gcp.yaml の例

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-gcp-provider                        
  namespace: my-namespace                      
spec:
  provider: gcp                                
  parameters:                                  
    secrets: |
      - resourceName: "projects/my-project/secrets/testsecret1/versions/1"
        path: "testsecret1.txt"

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-gcp-provider


  namespace: my-namespace


spec:
  provider: gcp


  parameters:


    secrets: |
      - resourceName: "projects/my-project/secrets/testsecret1/versions/1"
        path: "testsecret1.txt"

Copy to Clipboard

Toggle word wrap

1: シークレットプロバイダークラスの名前を指定します。
2: シークレットプロバイダークラスの namespace を指定します。
3: プロバイダーを gcp として指定します。
4: プロバイダー固有の設定パラメーターを指定します。

次のコマンドを実行して SecretProviderClass オブジェクトを作成します。
```
oc create -f secret-provider-class-gcp.yaml
```
```
$ oc create -f secret-provider-class-gcp.yaml
```
Copy to Clipboard Toggle word wrap

このシークレットプロバイダークラスを使用するデプロイメントを作成します。

Deployment オブジェクトを定義する YAML ファイルを作成します。

deployment.yaml の例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-gcp-deployment                              
  namespace: my-namespace                              
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-storage
  template:
    metadata:
      labels:
        app: my-storage
    spec:
      serviceAccountName: my-service-account           
      containers:
      - name: busybox
        image: k8s.gcr.io/e2e-test-images/busybox:1.29
        command:
          - "/bin/sleep"
          - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-gcp-provider"   
            nodePublishSecretRef:
              name: secrets-store-creds

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-gcp-deployment


  namespace: my-namespace


spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-storage
  template:
    metadata:
      labels:
        app: my-storage
    spec:
      serviceAccountName: my-service-account


      containers:
      - name: busybox
        image: k8s.gcr.io/e2e-test-images/busybox:1.29
        command:
          - "/bin/sleep"
          - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-gcp-provider"


            nodePublishSecretRef:
              name: secrets-store-creds

Copy to Clipboard

Toggle word wrap

1: デプロイメントの名前を指定します。
2: デプロイメントの namespace を指定します。これは、シークレットプロバイダークラスと同じ namespace である必要があります。
3: 作成したサービスアカウントを指定します。
4: シークレットプロバイダークラスの名前を指定します。
5: Google Secret Manager にアクセスするためのサービスプリンシパル認証情報を含む Kubernetes シークレットの名前を指定します。

次のコマンドを実行して、Deployment オブジェクトを作成します。
```
oc create -f deployment.yaml
```
```
$ oc create -f deployment.yaml
```
Copy to Clipboard Toggle word wrap

検証

Pod ボリュームマウント内の Google Secret Manager からのシークレットにアクセスできることを確認します。
1. 次のコマンドを実行して、Pod マウント内のシークレットをリスト表示します。
  $ oc exec my-gcp-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
  Copy to Clipboard Toggle word wrap
  出力例
  testsecret1
  
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、Pod マウント内のシークレットを表示します。
  $ oc exec my-gcp-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testsecret1
  Copy to Clipboard Toggle word wrap
  出力例
  <secret_value>
  
  Copy to Clipboard Toggle word wrap

2.8.3.5. HashiCorp Vault からのシークレットのマウント
リンクのコピー

Secrets Store CSI Driver Operator を使用して、HashiCorp Vault から OpenShift Container Platform の Container Storage Interface (CSI) ボリュームにシークレットをマウントできます。

重要

Secrets Store CSI Driver Operator を使用して HashiCorp Vault からシークレットをマウントする機能は、次のクラウドプロバイダーでテストされています。

Amazon Web Services (AWS)
Microsoft Azure

他のクラウドプロバイダーも機能する可能性がありますが、まだテストされていません。今後、別のクラウドプロバイダーが追加でテストされる可能性があります。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
Secrets Store CSI Driver Operator がインストールされている。手順は、「Secrets Store CSI ドライバーのインストール」を参照してください。
Helm がインストールされている。

手順

次のコマンドを実行して、HashiCorp Helm リポジトリーを追加します。
```
helm repo add hashicorp https://helm.releases.hashicorp.com
```
```
$ helm repo add hashicorp https://helm.releases.hashicorp.com
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、すべてのリポジトリーを更新し、Helm が最新バージョンを認識するようにします。
```
helm repo update
```
```
$ helm repo update
```
Copy to Clipboard Toggle word wrap

HashiCorp Vault プロバイダーをインストールします。

次のコマンドを実行して、Vault の新しいプロジェクトを作成します。
```
oc new-project vault
```
```
$ oc new-project vault
```
Copy to Clipboard Toggle word wrap

次のコマンドを実行して、Pod セキュリティーアドミッション用の vault namespace にラベルを付けます。

oc label ns vault security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwrite

$ oc label ns vault security.openshift.io/scc.podSecurityLabelSync=false pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged --overwrite

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、vault サービスアカウントに特権アクセスを許可します。
```
oc adm policy add-scc-to-user privileged -z vault -n vault
```
```
$ oc adm policy add-scc-to-user privileged -z vault -n vault
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、vault-csi-provider サービスアカウントに特権アクセスを許可します。
```
oc adm policy add-scc-to-user privileged -z vault-csi-provider -n vault
```
```
$ oc adm policy add-scc-to-user privileged -z vault-csi-provider -n vault
```
Copy to Clipboard Toggle word wrap

以下のコマンドを実行して HashiCorp Vault をデプロイします。

helm install vault hashicorp/vault --namespace=vault \
  --set "server.dev.enabled=true" \
  --set "injector.enabled=false" \
  --set "csi.enabled=true" \
  --set "global.openshift=true" \
  --set "injector.agentImage.repository=docker.io/hashicorp/vault" \
  --set "server.image.repository=docker.io/hashicorp/vault" \
  --set "csi.image.repository=docker.io/hashicorp/vault-csi-provider" \
  --set "csi.agent.image.repository=docker.io/hashicorp/vault" \
  --set "csi.daemonSet.providersDir=/var/run/secrets-store-csi-providers"

$ helm install vault hashicorp/vault --namespace=vault \
  --set "server.dev.enabled=true" \
  --set "injector.enabled=false" \
  --set "csi.enabled=true" \
  --set "global.openshift=true" \
  --set "injector.agentImage.repository=docker.io/hashicorp/vault" \
  --set "server.image.repository=docker.io/hashicorp/vault" \
  --set "csi.image.repository=docker.io/hashicorp/vault-csi-provider" \
  --set "csi.agent.image.repository=docker.io/hashicorp/vault" \
  --set "csi.daemonSet.providersDir=/var/run/secrets-store-csi-providers"

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、vault-csi-driver デーモンセットにパッチを適用し、securityContext を privileged に設定します。

oc patch daemonset -n vault vault-csi-provider --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/securityContext", "value": {"privileged": true} }]'

$ oc patch daemonset -n vault vault-csi-provider --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/securityContext", "value": {"privileged": true} }]'

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、vault-csi-provider Pod が正常に起動したことを確認します。

oc get pods -n vault

$ oc get pods -n vault

Copy to Clipboard

Toggle word wrap

出力例

NAME                       READY   STATUS    RESTARTS   AGE
vault-0                    1/1     Running   0          24m
vault-csi-provider-87rgw   1/2     Running   0          5s
vault-csi-provider-bd6hp   1/2     Running   0          4s
vault-csi-provider-smlv7   1/2     Running   0          5s

NAME                       READY   STATUS    RESTARTS   AGE
vault-0                    1/1     Running   0          24m
vault-csi-provider-87rgw   1/2     Running   0          5s
vault-csi-provider-bd6hp   1/2     Running   0          4s
vault-csi-provider-smlv7   1/2     Running   0          5s

Copy to Clipboard

Toggle word wrap

必要なシークレットを保存するように HashiCorp Vault を設定します。

次のコマンドを実行してシークレットを作成します。

oc exec vault-0 --namespace=vault -- vault kv put secret/example1 testSecret1=my-secret-value

$ oc exec vault-0 --namespace=vault -- vault kv put secret/example1 testSecret1=my-secret-value

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、シークレットがパス secret/example1 で読み取り可能であることを確認します。

oc exec vault-0 --namespace=vault -- vault kv get secret/example1

$ oc exec vault-0 --namespace=vault -- vault kv get secret/example1

Copy to Clipboard

Toggle word wrap

出力例

= Secret Path =
secret/data/example1

======= Metadata =======
Key                Value
---                -----
created_time       2024-04-05T07:05:16.713911211Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

=== Data ===
Key            Value
---            -----
testSecret1    my-secret-value

= Secret Path =
secret/data/example1

======= Metadata =======
Key                Value
---                -----
created_time       2024-04-05T07:05:16.713911211Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

=== Data ===
Key            Value
---            -----
testSecret1    my-secret-value

Copy to Clipboard

Toggle word wrap

Kubernetes 認証を使用するように Vault を設定します。

次のコマンドを実行して、Kubernetes 認証方法を有効にします。

oc exec vault-0 --namespace=vault -- vault auth enable kubernetes

$ oc exec vault-0 --namespace=vault -- vault auth enable kubernetes

Copy to Clipboard

Toggle word wrap

出力例

Success! Enabled kubernetes auth method at: kubernetes/

Success! Enabled kubernetes auth method at: kubernetes/

Copy to Clipboard

Toggle word wrap

Kubernetes 認証メソッドを設定します。

次のコマンドを実行して、トークンレビューアーを環境変数として設定します。

TOKEN_REVIEWER_JWT="$(oc exec vault-0 --namespace=vault -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

$ TOKEN_REVIEWER_JWT="$(oc exec vault-0 --namespace=vault -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、Kubernetes サービスの IP アドレスを環境変数として設定します。

KUBERNETES_SERVICE_IP="$(oc get svc kubernetes --namespace=default -o go-template="{{ .spec.clusterIP }}")"

$ KUBERNETES_SERVICE_IP="$(oc get svc kubernetes --namespace=default -o go-template="{{ .spec.clusterIP }}")"

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、Kubernetes auth メソッドを更新します。

oc exec -i vault-0 --namespace=vault -- vault write auth/kubernetes/config \
  issuer="https://kubernetes.default.svc.cluster.local" \
  token_reviewer_jwt="${TOKEN_REVIEWER_JWT}" \
  kubernetes_host="https://${KUBERNETES_SERVICE_IP}:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

$ oc exec -i vault-0 --namespace=vault -- vault write auth/kubernetes/config \
  issuer="https://kubernetes.default.svc.cluster.local" \
  token_reviewer_jwt="${TOKEN_REVIEWER_JWT}" \
  kubernetes_host="https://${KUBERNETES_SERVICE_IP}:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Copy to Clipboard

Toggle word wrap

出力例

Success! Data written to: auth/kubernetes/config

Success! Data written to: auth/kubernetes/config

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、アプリケーションのポリシーを作成します。

oc exec -i vault-0 --namespace=vault -- vault policy write csi -<<EOF
  path "secret/data/*" {
  capabilities = ["read"]
  }
  EOF

$ oc exec -i vault-0 --namespace=vault -- vault policy write csi -<<EOF
  path "secret/data/*" {
  capabilities = ["read"]
  }
  EOF

Copy to Clipboard

Toggle word wrap

出力例

Success! Uploaded policy: csi

Success! Uploaded policy: csi

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、アプリケーションにアクセスするための認証ロールを作成します。

oc exec -i vault-0 --namespace=vault -- vault write auth/kubernetes/role/csi \
  bound_service_account_names=default \
  bound_service_account_namespaces=default,test-ns,negative-test-ns,my-namespace \
  policies=csi \
  ttl=20m

$ oc exec -i vault-0 --namespace=vault -- vault write auth/kubernetes/role/csi \
  bound_service_account_names=default \
  bound_service_account_namespaces=default,test-ns,negative-test-ns,my-namespace \
  policies=csi \
  ttl=20m

Copy to Clipboard

Toggle word wrap

出力例

Success! Data written to: auth/kubernetes/role/csi

Success! Data written to: auth/kubernetes/role/csi

Copy to Clipboard

Toggle word wrap

シークレットプロバイダークラスを作成して、シークレットストアプロバイダーを定義します。

SecretProviderClass オブジェクトを定義する YAML ファイルを作成します。

secret-provider-class-vault.yaml の例

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-vault-provider                   
  namespace: my-namespace                   
spec:
  provider: vault                           
  parameters:                               
    roleName: "csi"
    vaultAddress: "http://vault.vault:8200"
    objects:  |
      - secretPath: "secret/data/example1"
        objectName: "testSecret1"
        secretKey: "testSecret1"

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-vault-provider


  namespace: my-namespace


spec:
  provider: vault


  parameters:


    roleName: "csi"
    vaultAddress: "http://vault.vault:8200"
    objects:  |
      - secretPath: "secret/data/example1"
        objectName: "testSecret1"
        secretKey: "testSecret1"

Copy to Clipboard

Toggle word wrap

1: シークレットプロバイダークラスの名前を指定します。
2: シークレットプロバイダークラスの namespace を指定します。
3: プロバイダーは vault として指定します。
4: プロバイダー固有の設定パラメーターを指定します。

次のコマンドを実行して SecretProviderClass オブジェクトを作成します。
```
oc create -f secret-provider-class-vault.yaml
```
```
$ oc create -f secret-provider-class-vault.yaml
```
Copy to Clipboard Toggle word wrap

このシークレットプロバイダークラスを使用するデプロイメントを作成します。

Deployment オブジェクトを定義する YAML ファイルを作成します。

deployment.yaml の例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-deployment                                    
  namespace: my-namespace                                     
  labels:
    app: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - image: registry.k8s.io/e2e-test-images/busybox:1.29-4
        name: busybox
        imagePullPolicy: IfNotPresent
        command:
        - "/bin/sleep"
        - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-vault-provider"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-deployment


  namespace: my-namespace


  labels:
    app: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - image: registry.k8s.io/e2e-test-images/busybox:1.29-4
        name: busybox
        imagePullPolicy: IfNotPresent
        command:
        - "/bin/sleep"
        - "10000"
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "my-vault-provider"

Copy to Clipboard

Toggle word wrap

1: デプロイメントの名前を指定します。
2: デプロイメントの namespace を指定します。これは、シークレットプロバイダークラスと同じ namespace である必要があります。
3: シークレットプロバイダークラスの名前を指定します。

次のコマンドを実行して、Deployment オブジェクトを作成します。
```
oc create -f deployment.yaml
```
```
$ oc create -f deployment.yaml
```
Copy to Clipboard Toggle word wrap

検証

次のコマンドを実行して、すべての vault Pod が正常に実行されていることを確認します。

oc get pods -n vault

$ oc get pods -n vault

Copy to Clipboard

Toggle word wrap

出力例

NAME                       READY   STATUS    RESTARTS   AGE
vault-0                    1/1     Running   0          43m
vault-csi-provider-87rgw   2/2     Running   0          19m
vault-csi-provider-bd6hp   2/2     Running   0          19m
vault-csi-provider-smlv7   2/2     Running   0          19m

NAME                       READY   STATUS    RESTARTS   AGE
vault-0                    1/1     Running   0          43m
vault-csi-provider-87rgw   2/2     Running   0          19m
vault-csi-provider-bd6hp   2/2     Running   0          19m
vault-csi-provider-smlv7   2/2     Running   0          19m

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、すべての secrets-store-csi-driver Pod が実行されていることを確認します。

oc get pods -n openshift-cluster-csi-drivers | grep -E "secrets"

$ oc get pods -n openshift-cluster-csi-drivers | grep -E "secrets"

Copy to Clipboard

Toggle word wrap

出力例

secrets-store-csi-driver-node-46d2g                  3/3     Running   0             45m
secrets-store-csi-driver-node-d2jjn                  3/3     Running   0             45m
secrets-store-csi-driver-node-drmt4                  3/3     Running   0             45m
secrets-store-csi-driver-node-j2wlt                  3/3     Running   0             45m
secrets-store-csi-driver-node-v9xv4                  3/3     Running   0             45m
secrets-store-csi-driver-node-vlz28                  3/3     Running   0             45m
secrets-store-csi-driver-operator-84bd699478-fpxrw   1/1     Running   0             47m

secrets-store-csi-driver-node-46d2g                  3/3     Running   0             45m
secrets-store-csi-driver-node-d2jjn                  3/3     Running   0             45m
secrets-store-csi-driver-node-drmt4                  3/3     Running   0             45m
secrets-store-csi-driver-node-j2wlt                  3/3     Running   0             45m
secrets-store-csi-driver-node-v9xv4                  3/3     Running   0             45m
secrets-store-csi-driver-node-vlz28                  3/3     Running   0             45m
secrets-store-csi-driver-operator-84bd699478-fpxrw   1/1     Running   0             47m

Copy to Clipboard

Toggle word wrap

Pod ボリュームマウント内の HashiCorp Vault からシークレットにアクセスできることを確認します。

次のコマンドを実行して、Pod マウント内のシークレットをリスト表示します。
```
oc exec busybox-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
```
```
$ oc exec busybox-deployment-<hash> -n my-namespace -- ls /mnt/secrets-store/
```
Copy to Clipboard Toggle word wrap
出力例
```
testSecret1
```
```
testSecret1
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、Pod マウント内のシークレットを表示します。
```
oc exec busybox-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecret1
```
```
$ oc exec busybox-deployment-<hash> -n my-namespace -- cat /mnt/secrets-store/testSecret1
```
Copy to Clipboard Toggle word wrap
出力例
```
my-secret-value
```
```
my-secret-value
```
Copy to Clipboard Toggle word wrap

2.8.4. マウントされたコンテンツを Kubernetes シークレットとして同期できるようにする
リンクのコピー

同期を有効にして、マウントされたボリューム上のコンテンツから Kubernetes シークレットを作成できます。同期を有効にする例としては、デプロイメント内で環境変数を使用して Kubernetes シークレットを参照することが挙げられます。

警告

シークレットを OpenShift Container Platform クラスターおよび etcd に保存しない場合は、同期を有効にしないでください。この機能は、環境変数を使用してシークレットを参照する場合など、必要な場合にのみ有効にしてください。

同期を有効にすると、シークレットをマウントする Pod を開始した後、マウントされたボリュームのシークレットが Kubernetes シークレットとして同期されます。

コンテンツをマウントしたすべての Pod が削除されると、同期された Kubernetes シークレットも削除されます。

前提条件

Secrets Store CSI Driver Operator がインストールされている。
シークレットストアプロバイダーがインストールされている。
シークレットプロバイダークラスが作成されている。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

次のコマンドを実行して、SecretProviderClass リソースを編集します。
```
oc edit secretproviderclass my-azure-provider
```
```
$ oc edit secretproviderclass my-azure-provider 
```
1
Copy to Clipboard Toggle word wrap
1
my-azure-provider をシークレットプロバイダークラスの名前に置き換えます。

同期された Kubernetes シークレットの設定を含む secretsObjects セクションを追加します。

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-azure-provider
  namespace: my-namespace
spec:
  provider: azure
  secretObjects:                                   
    - secretName: tlssecret                        
      type: kubernetes.io/tls                      
      labels:
        environment: "test"
      data:
        - objectName: tlskey                       
          key: tls.key                             
        - objectName: tlscrt
          key: tls.crt
  parameters:
    usePodIdentity: "false"
    keyvaultName: "kvname"
    objects:  |
      array:
        - |
          objectName: tlskey
          objectType: secret
        - |
          objectName: tlscrt
          objectType: secret
    tenantId: "tid"

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-azure-provider
  namespace: my-namespace
spec:
  provider: azure
  secretObjects:


    - secretName: tlssecret


      type: kubernetes.io/tls


      labels:
        environment: "test"
      data:
        - objectName: tlskey


          key: tls.key


        - objectName: tlscrt
          key: tls.crt
  parameters:
    usePodIdentity: "false"
    keyvaultName: "kvname"
    objects:  |
      array:
        - |
          objectName: tlskey
          objectType: secret
        - |
          objectName: tlscrt
          objectType: secret
    tenantId: "tid"

Copy to Clipboard

Toggle word wrap

1: 同期された Kubernetes シークレットの設定を指定します。
2: 作成する Kubernetes Secret オブジェクトの名前を指定します。
3: 作成する Kubernetes Secret オブジェクトのタイプを指定します。たとえば、Opaque または kubernetes.io/tls です。
4: 同期するマウントされたコンテンツのオブジェクト名またはエイリアスを指定します。
5: Kubernetes シークレットに設定するデータフィールドを、指定した objectName から指定します。

変更を適用するためにファイルを保存します。

2.8.5. Pod ボリュームマウント内のシークレットのステータスの表示
リンクのコピー

Pod ボリュームマウント内のシークレットのバージョンなどの詳細情報を表示できます。

Secrets Store CSI Driver Operator は、Pod と同じ namespace に SecretProviderClassPodStatus リソースを作成します。このリソースを確認すると、Pod ボリュームマウントのシークレットに関するバージョンなどの詳細情報を確認できます。

前提条件

Secrets Store CSI Driver Operator がインストールされている。
シークレットストアプロバイダーがインストールされている。
シークレットプロバイダークラスが作成されている。
Secrets Store CSI Driver Operator からボリュームをマウントする Pod をデプロイしている。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

次のコマンドを実行して、Pod ボリュームマウントのシークレットに関する詳細情報を表示します。

oc get secretproviderclasspodstatus <secret_provider_class_pod_status_name> -o yaml

$ oc get secretproviderclasspodstatus <secret_provider_class_pod_status_name> -o yaml

Copy to Clipboard

Toggle word wrap

1: シークレットプロバイダークラスの Pod ステータスオブジェクトの名前は、<pod_name>-<namespace>-<secret_provider_class_name> の形式になります。

出力例

...
status:
  mounted: true
  objects:
  - id: secret/tlscrt
    version: f352293b97da4fa18d96a9528534cb33
  - id: secret/tlskey
    version: 02534bc3d5df481cb138f8b2a13951ef
  podName: busybox-<hash>
  secretProviderClassName: my-azure-provider
  targetPath: /var/lib/kubelet/pods/f0d49c1e-c87a-4beb-888f-37798456a3e7/volumes/kubernetes.io~csi/secrets-store-inline/mount

...
status:
  mounted: true
  objects:
  - id: secret/tlscrt
    version: f352293b97da4fa18d96a9528534cb33
  - id: secret/tlskey
    version: 02534bc3d5df481cb138f8b2a13951ef
  podName: busybox-<hash>
  secretProviderClassName: my-azure-provider
  targetPath: /var/lib/kubelet/pods/f0d49c1e-c87a-4beb-888f-37798456a3e7/volumes/kubernetes.io~csi/secrets-store-inline/mount

Copy to Clipboard

Toggle word wrap

2.8.6. Secrets Store CSI Driver Operator のアンインストール
リンクのコピー

前提条件

OpenShift Container Platform Web コンソールにアクセスできる。
管理者としてクラスターにアクセスできる。

手順

Secrets Store CSI Driver Operator をアンインストールするには、以下を実行します。

secrets-store.csi.k8s.io プロバイダーを使用するすべてのアプリケーション Pod を停止します。
選択したシークレットストアのサードパーティープロバイダープラグインをすべて削除します。
Container Storage Interface (CSI) ドライバーと関連するマニフェストを削除します。
1. Administration → CustomResourceDefinitions → ClusterCSIDriver をクリックします。
2. Instances タブの左端にある secrets-store.csi.k8s.io でドロップダウンメニューをクリックし、Delete ClusterCSIDriver をクリックします。
3. プロンプトが表示されたら、Delete をクリックします。
CSI ドライバー Pod が稼働していないことを確認します。
Secrets Store CSI Driver Operator をアンインストールします。
注記
Operator をアンインストールする前に、まず CSI ドライバーを削除する必要があります。
1. Ecosystem → Installed Operators をクリックします。
2. Installed Operators ページで、スクロールするか、Search by name ボックスに "Secrets Store CSI" と入力して Operator を見つけ、クリックします。
3. Installed Operators > Operator details ページの右上に表示される Actions → Uninstall Operator をクリックします。
4. Uninstall Operator ウィンドウでプロンプトが表示されたら、Uninstall ボタンをクリックして namespace から Operator を削除します。Operator によってクラスターにデプロイされたアプリケーションは手動でクリーンアップする必要があります。
  アンインストールすると、Secrets Store CSI Driver Operator は Web コンソールの Installed Operators セクションにリストされなくなります。

2.9. 短期認証情報で Pod を認証する
リンクのコピー

一部の OpenShift Container Platform クラスターでは、クラスター外で作成および管理されるコンポーネントごとの短期セキュリティー認証情報を使用します。該当するクラスター上のカスタマーワークロード内のアプリケーションは、クラスターが使用する短期認証方法を使用して認証できます。

2.9.1. ワークロードの短期認証の設定
リンクのコピー

アプリケーションでこの認証方法を使用するには、次の手順を完了する必要があります。

クラウドプロバイダーの Identity and Access Management (IAM) 設定で連携アイデンティティーサービスアカウントを作成します。
クラウドプロバイダーのサービスアカウントに成り代わることができる OpenShift Container Platform サービスアカウントを作成します。
アプリケーションに関連するワークロードを、OpenShift Container Platform サービスアカウントを使用するように設定します。

2.9.1.1. 環境とユーザーアクセスの要件
リンクのコピー

この認証方法を設定するには、次の要件を満たす必要があります。

クラスターで短期セキュリティー認証情報を使用する必要があります。
cluster-admin ロールを持つユーザーとして OpenShift CLI (oc) にアクセスできる必要があります。
クラウドプロバイダーコンソールでは、Identity and Access Management (IAM) および連携アイデンティティー設定の管理権限を持つユーザーとしてアクセスできる必要があります。

2.9.2. Google Cloud 上のアプリケーションに対する GCP Workload Identity 認証の設定
リンクのコピー

GCP Workload Identity 認証を使用する Google Cloud クラスター上のアプリケーションに短期認証を使用するには、次の手順を完了する必要があります。

Google Cloud でアクセスを設定します。
このアクセスを使用できる OpenShift Container Platform サービスアカウントを作成します。
GCP Workload Identity で認証するカスタマーワークロードをデプロイします。

2.9.2.1. フェデレーションされた Google Cloud サービスアカウントの作成
リンクのコピー

Google Cloud コンソールを使用して、ワークロードアイデンティティープールとプロバイダーを作成し、OpenShift Container Platform サービスアカウントによる Google Cloud サービスアカウントの成り代わりを許可できます。

前提条件

Google Cloud のクラスターで GCP Workload Identity を使用している。
Identity and Access Management (IAM) とワークロードアイデンティティー設定を管理する権限を持つユーザーとして、Google Cloud コンソールにアクセスできる。
アプリケーションで使用する Google Cloud プロジェクトが作成済みである。

手順

Google Cloud プロジェクトの IAM 設定で、クラスターが GCP Workload Identity 認証に使用するアイデンティティープールとプロバイダーを特定します。
外部のアイデンティティーが Google Cloud サービスアカウントに成り代わるための権限を付与します。これらの権限により、OpenShift Container Platform サービスアカウントは連携ワークロードアイデンティティーとして機能できます。
詳細は、外部ワークロードによる Google Cloud リソースへのアクセスを許可する方法に関する Google Cloud ドキュメントを参照してください。

2.9.2.2. Google Cloud 用の OpenShift Container Platform サービスアカウントを作成する
リンクのコピー

OpenShift Container Platform のサービスアカウントを作成し、Google Cloud のサービスアカウントに成り代われるように、そのサービスアカウントにアノテーションを付けます。

前提条件

Google Cloud のクラスターで GCP Workload Identity を使用している。
フェデレーションされた Google Cloud サービスアカウントを作成した。
cluster-admin ロールを持つユーザーとして OpenShift CLI (oc) にアクセスできる。
Identity and Access Management (IAM) とワークロードアイデンティティー設定を管理する権限を持つユーザーとして、Google Cloud CLI (gcloud) にアクセスできる。

手順

次のコマンドを実行して、GCP Workload Identity Pod 認証に使用する OpenShift Container Platform サービスアカウントを作成します。
```
oc create serviceaccount <service_account_name>
```
```
$ oc create serviceaccount <service_account_name>
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、サービスアカウントに成り代わるアイデンティティープロバイダーと Google Cloud サービスアカウントのアノテーションを付けます。
```
oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/workload-identity-provider": "projects/<project_number>/locations/global/workloadIdentityPools/<identity_pool>/providers/<identity_provider>"}}}'
```
```
$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/workload-identity-provider": "projects/<project_number>/locations/global/workloadIdentityPools/<identity_pool>/providers/<identity_provider>"}}}'
```
Copy to Clipboard Toggle word wrap
<project_number>、<identity_pool>、<identity_provider> を実際の設定の値に置き換えます。
注記
<project_number> には、プロジェクト ID ではなく、Google Cloud プロジェクト番号を指定します。
次のコマンドを実行して、Google Cloud サービスアカウントのメールアドレスをサービスアカウントにアノテーションとして追加します。
```
oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/service-account-email": "<service_account_email>"}}}'
```
```
$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/service-account-email": "<service_account_email>"}}}'
```
Copy to Clipboard Toggle word wrap
<service_account_email> は、Google Cloud サービスアカウントのメールアドレスに置き換えます。
ヒント
通常、Google Cloud サービスアカウントのメールアドレスは、<service_account_name>@<project_id>.iam.gserviceaccount.com という形式を使用します。
次のコマンドを実行して、direct 外部認証情報設定注入モードを使用するようにサービスアカウントにアノテーションを付けます。
```
oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/injection-mode": "direct"}}}'
```
```
$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/injection-mode": "direct"}}}'
```
Copy to Clipboard Toggle word wrap
このモードでは、Workload Identity Federation Webhook コントローラーが Google Cloud 外部認証情報の設定を直接生成し、Pod に注入します。
Google Cloud CLI (gcloud) を使用して次のコマンドを実行し、ワークロードの権限を指定します。
```
gcloud projects add-iam-policy-binding <project_id> --member "<service_account_email>" --role "projects/<project_id>/roles/<role_for_workload_permissions>"
```
```
$ gcloud projects add-iam-policy-binding <project_id> --member "<service_account_email>" --role "projects/<project_id>/roles/<role_for_workload_permissions>"
```
Copy to Clipboard Toggle word wrap
<role_for_workload_permissions> をワークロードのロールに置き換えます。ワークロードに必要な権限を付与するロールを指定します。

検証

サービスアカウントの設定を検証するには、次のコマンドを実行して ServiceAccount マニフェストを調べます。

oc get serviceaccount <service_account_name>

$ oc get serviceaccount <service_account_name>

Copy to Clipboard

Toggle word wrap

次の例では、service-a/app-x という OpenShift Container Platform サービスアカウントが、app-x という Google Cloud サービスアカウントに成り代わることができます。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-x
  namespace: service-a
  annotations:
    cloud.google.com/workload-identity-provider: "projects/<project_number>/locations/global/workloadIdentityPools/<identity_pool>/providers/<identity_provider>" 
    cloud.google.com/service-account-email: "app-x@project.iam.googleapis.com"
    cloud.google.com/audience: "sts.googleapis.com" 
    cloud.google.com/token-expiration: "86400" 
    cloud.google.com/gcloud-run-as-user: "1000"
    cloud.google.com/injection-mode: "direct"

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-x
  namespace: service-a
  annotations:
    cloud.google.com/workload-identity-provider: "projects/<project_number>/locations/global/workloadIdentityPools/<identity_pool>/providers/<identity_provider>"


    cloud.google.com/service-account-email: "app-x@project.iam.googleapis.com"
    cloud.google.com/audience: "sts.googleapis.com"


    cloud.google.com/token-expiration: "86400"


    cloud.google.com/gcloud-run-as-user: "1000"
    cloud.google.com/injection-mode: "direct"

Copy to Clipboard

Toggle word wrap

1: クラスターのサービスアカウントのワークロードアイデンティティープロバイダー。
2: ワークロードアイデンティティープロバイダーの許可されたオーディエンス。
3: トークンの有効期限 (秒単位)。
4: direct 外部認証情報設定注入モード。

2.9.2.3. GCP Workload Identity で認証するカスタマーワークロードのデプロイ
リンクのコピー

アプリケーションで短期認証を使用するには、関連する Pod が OpenShift Container Platform サービスアカウントを使用するように設定する必要があります。OpenShift Container Platform サービスアカウントを使用すると、Pod を変更する Webhook がトリガーされ、Google Cloud サービスアカウントへの成り代わりが可能になります。

次の例は、OpenShift Container Platform サービスアカウントを使用する Pod をデプロイし、設定を確認する方法を示しています。

前提条件

Google Cloud のクラスターで GCP Workload Identity を使用している。
フェデレーションされた Google Cloud サービスアカウントを作成した。
Google Cloud 用の OpenShift Container Platform サービスアカウントを作成した。

手順

GCP Workload Identity で認証する Pod を作成するには、次の例のようなデプロイメント YAML ファイルを作成します。

サンプルデプロイメント

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubi9
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ubi9
  template:
    metadata:
      labels:
        app: ubi9
    spec:
      serviceAccountName: "<service_account_name>" 
      containers:
        - name: ubi
          image: 'registry.access.redhat.com/ubi9/ubi-micro:latest'
          command:
            - /bin/sh
            - '-c'
            - |
              sleep infinity

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubi9
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ubi9
  template:
    metadata:
      labels:
        app: ubi9
    spec:
      serviceAccountName: "<service_account_name>"


      containers:
        - name: ubi
          image: 'registry.access.redhat.com/ubi9/ubi-micro:latest'
          command:
            - /bin/sh
            - '-c'
            - |
              sleep infinity

Copy to Clipboard

Toggle word wrap

1: OpenShift Container Platform サービスアカウントの名前を指定します。

次のコマンドを実行してデプロイメントファイルを適用します。
```
oc apply -f deployment.yaml
```
```
$ oc apply -f deployment.yaml
```
Copy to Clipboard Toggle word wrap

検証

Pod が短期認証を使用していることを確認するには、次のコマンドを実行します。

oc get pods -o json | jq -r '.items[0].spec.containers[0].env[] | select(.name=="GOOGLE_APPLICATION_CREDENTIALS")'

$ oc get pods -o json | jq -r '.items[0].spec.containers[0].env[] | select(.name=="GOOGLE_APPLICATION_CREDENTIALS")'

Copy to Clipboard

Toggle word wrap

出力例

{   "name": "GOOGLE_APPLICATION_CREDENTIALS",   "value": "/var/run/secrets/workload-identity/federation.json" }

{   "name": "GOOGLE_APPLICATION_CREDENTIALS",   "value": "/var/run/secrets/workload-identity/federation.json" }

Copy to Clipboard

Toggle word wrap

GOOGLE_APPLICATION_CREDENTIALS 環境変数が存在する場合、それは GCP Workload Identity で認証する Pod を示しています。

追加設定の詳細を確認するには、Pod 仕様を調べます。次の Pod 仕様の例は、Webhook によって変更される環境変数とボリュームフィールドを示しています。

direct 注入モードの Pod 仕様例:

apiVersion: v1
kind: Pod
metadata:
  name: app-x-pod
  namespace: service-a
annotations:
  cloud.google.com/skip-containers: "init-first,sidecar"
  cloud.google.com/external-credentials-json: |- 
    {
      "type": "external_account",
      "audience": "//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/on-prem-kubernetes/providers/<identity_provider>",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/app-x@project.iam.gserviceaccount.com:generateAccessToken",
      "credential_source": {
        "file": "/var/run/secrets/sts.googleapis.com/serviceaccount/token",
        "format": {
          "type": "text"
        }
      }
    }
spec:
  serviceAccountName: app-x
  initContainers:
  - name: init-first
    image: container-image:version
  containers:
  - name: sidecar
    image: container-image:version
  - name: container-name
    image: container-image:version
    env: 
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/gcloud/config/federation.json
    - name: CLOUDSDK_COMPUTE_REGION
      value: asia-northeast1
    volumeMounts:
    - name: gcp-iam-token
      readOnly: true
      mountPath: /var/run/secrets/sts.googleapis.com/serviceaccount
    - mountPath: /var/run/secrets/gcloud/config
      name: external-credential-config
      readOnly: true
  volumes:
  - name: gcp-iam-token
    projected:
      sources:
      - serviceAccountToken:
          audience: sts.googleapis.com
          expirationSeconds: 86400
          path: token
  - downwardAPI:
      defaultMode: 288
      items:
      - fieldRef:
          apiVersion: v1
          fieldPath: metadata.annotations['cloud.google.com/external-credentials-json']
        path: federation.json
    name: external-credential-config

apiVersion: v1
kind: Pod
metadata:
  name: app-x-pod
  namespace: service-a
annotations:
  cloud.google.com/skip-containers: "init-first,sidecar"
  cloud.google.com/external-credentials-json: |-


    {
      "type": "external_account",
      "audience": "//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/on-prem-kubernetes/providers/<identity_provider>",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/app-x@project.iam.gserviceaccount.com:generateAccessToken",
      "credential_source": {
        "file": "/var/run/secrets/sts.googleapis.com/serviceaccount/token",
        "format": {
          "type": "text"
        }
      }
    }
spec:
  serviceAccountName: app-x
  initContainers:
  - name: init-first
    image: container-image:version
  containers:
  - name: sidecar
    image: container-image:version
  - name: container-name
    image: container-image:version
    env:


    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/gcloud/config/federation.json
    - name: CLOUDSDK_COMPUTE_REGION
      value: asia-northeast1
    volumeMounts:
    - name: gcp-iam-token
      readOnly: true
      mountPath: /var/run/secrets/sts.googleapis.com/serviceaccount
    - mountPath: /var/run/secrets/gcloud/config
      name: external-credential-config
      readOnly: true
  volumes:
  - name: gcp-iam-token
    projected:
      sources:
      - serviceAccountToken:
          audience: sts.googleapis.com
          expirationSeconds: 86400
          path: token
  - downwardAPI:
      defaultMode: 288
      items:
      - fieldRef:
          apiVersion: v1
          fieldPath: metadata.annotations['cloud.google.com/external-credentials-json']
        path: federation.json
    name: external-credential-config

Copy to Clipboard

Toggle word wrap

1: Webhook コントローラーによって生成された外部認証情報の設定。Kubernetes の downwardAPI ボリュームは、設定をコンテナーのファイルシステムにマウントします。
2: Webhook により注入される、トークンベースの認証用の環境変数。

2.10. 設定マップの作成および使用
リンクのコピー

以下のセクションでは、設定マップおよびそれらを作成し、使用する方法を定義します。

2.10.1. 設定マップについて
リンクのコピー

多くのアプリケーションには、設定ファイル、コマンドライン引数、および環境変数の組み合わせを使用した設定が必要です。OpenShift Container Platform では、これらの設定アーティファクトは、コンテナー化されたアプリケーションを移植可能な状態に保つためにイメージコンテンツから切り離されます。

ConfigMap オブジェクトは、コンテナーを OpenShift Container Platform に依存させないようにする一方で、コンテナーに設定データを注入するメカニズムを提供します。設定マップは、個々のプロパティーなどの粒度の細かい情報や、設定ファイル全体または JSON Blob などの粒度の荒い情報を保存するために使用できます。

ConfigMap オブジェクトは、Pod で使用したり、コントローラーなどのシステムコンポーネントの設定データを保存するために使用できる設定データのキーと値のペアを保持します。以下に例を示します。

ConfigMap オブジェクト定義

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: my-namespace
data: 
  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3
binaryData:
  bar: L3Jvb3QvMTAw

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: my-namespace
data:


  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3
binaryData:
  bar: L3Jvb3QvMTAw

Copy to Clipboard

Toggle word wrap

1: 設定データが含まれます。
2: バイナリー Java キーストアファイルなどの UTF8 以外のデータを含むファイルを参照します。Base 64 のファイルデータを入力します。

注記

イメージなどのバイナリーファイルから設定マップを作成する場合に、binaryData フィールドを使用できます。

設定データはさまざまな方法で Pod 内で使用できます。設定マップは以下を実行するために使用できます。

コンテナーへの環境変数値の設定
コンテナーのコマンドライン引数の設定
ボリュームの設定ファイルの設定

ユーザーとシステムコンポーネントの両方が設定データを設定マップに保存できます。

設定マップはシークレットに似ていますが、機密情報を含まない文字列の使用をより効果的にサポートするように設計されています。

2.10.1.1. 設定マップの制限
リンクのコピー

設定マップは、コンテンツを Pod で使用される前に作成する必要があります。

コントローラーは、設定データが不足していても、その状況を許容して作成できます。ケースごとに設定マップを使用して設定される個々のコンポーネントを参照してください。

ConfigMap オブジェクトはプロジェクト内にあります。

それらは同じプロジェクトの Pod によってのみ参照されます。

Kubelet は、API サーバーから取得する Pod の設定マップの使用のみをサポートします。

これには、CLI を使用して作成された Pod、またはレプリケーションコントローラーから間接的に作成された Pod が含まれます。これには、OpenShift Container Platform ノードの --manifest-url フラグ、その --config フラグ、またはその REST API を使用して作成された Pod は含まれません (これらは Pod を作成する一般的な方法ではありません)。

2.10.2. OpenShift Container Platform Web コンソールでの設定マップの作成
リンクのコピー

OpenShift Container Platform Web コンソールで設定マップを作成できます。

手順

クラスター管理者として設定マップを作成するには、以下を実行します。
1. Administrator パースペクティブで Workloads → Config Maps を選択します。
2. ページの右上にある Create Config Map を選択します。
3. 設定マップの内容を入力します。
4. Create を選択します。
開発者として設定マップを作成するには、以下を実行します。
1. 開発者パースペクティブで、Config Maps を選択します。
2. ページの右上にある Create Config Map を選択します。
3. 設定マップの内容を入力します。
4. Create を選択します。

2.10.3. CLI を使用して設定マップを作成する
リンクのコピー

以下のコマンドを使用して、ディレクトリー、特定のファイルまたはリテラル値から設定マップを作成できます。

手順

設定マップの作成

oc create configmap <configmap_name> [options]

$ oc create configmap <configmap_name> [options]

Copy to Clipboard

Toggle word wrap

2.10.3.1. ディレクトリーからの設定マップの作成
リンクのコピー

--from-file フラグを使用すると、ディレクトリーから config map を作成できます。この方法では、ディレクトリー内の複数のファイルを使用して設定マップを作成できます。

ディレクトリー内の各ファイルは、config map にキーを設定するために使用されます。キーの名前はファイル名で、キーの値はファイルの内容です。

たとえば、次のコマンドは、example-files ディレクトリーの内容を使用して config map を作成します。

oc create configmap game-config --from-file=example-files/

$ oc create configmap game-config --from-file=example-files/

Copy to Clipboard

Toggle word wrap

config map 内のキーを表示します。

oc describe configmaps game-config

$ oc describe configmaps game-config

Copy to Clipboard

Toggle word wrap

出力例

Name:           game-config
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data

game.properties:        158 bytes
ui.properties:          83 bytes

Name:           game-config
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data

game.properties:        158 bytes
ui.properties:          83 bytes

Copy to Clipboard

Toggle word wrap

マップにある 2 つのキーが、コマンドで指定されたディレクトリーのファイル名に基づいて作成されていることに気づかれることでしょう。これらのキーの内容は大きい可能性があるため、oc describe の出力にはキーの名前とそのサイズのみが表示されます。

前提条件

config map に追加するデータを含むファイルを含むディレクトリーが必要です。

次の手順では、サンプルファイル game.properties および ui.properties を使用します。

cat example-files/game.properties

$ cat example-files/game.properties

Copy to Clipboard

Toggle word wrap

出力例

enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

Copy to Clipboard

Toggle word wrap

cat example-files/ui.properties

$ cat example-files/ui.properties

Copy to Clipboard

Toggle word wrap

出力例

color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Copy to Clipboard

Toggle word wrap

手順

次のコマンドを入力して、このディレクトリー内の各ファイルの内容を保持する設定マップを作成します。
```
oc create configmap game-config \
    --from-file=example-files/
```
```
$ oc create configmap game-config \
    --from-file=example-files/
```
Copy to Clipboard Toggle word wrap

検証

-o オプションを使用してオブジェクトの oc get コマンドを入力し、キーの値を表示します。

oc get configmaps game-config -o yaml

$ oc get configmaps game-config -o yaml

Copy to Clipboard

Toggle word wrap

出力例

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:34:05Z
  name: game-config
  namespace: default
  resourceVersion: "407"
  selflink: /api/v1/namespaces/default/configmaps/game-config
  uid: 30944725-d66e-11e5-8cd0-68f728db1985

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:34:05Z
  name: game-config
  namespace: default
  resourceVersion: "407"
  selflink: /api/v1/namespaces/default/configmaps/game-config
  uid: 30944725-d66e-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

2.10.3.2. ファイルから設定マップを作成する
リンクのコピー

--from-file フラグを使用すると、ファイルから config map を作成できます。--from-file オプションを CLI に複数回渡すことができます。

key=value 式を --from-file オプションに渡すことで、ファイルからインポートされたコンテンツの config map に設定するキーを指定することもできます。以下に例を示します。

oc create configmap game-config-3 --from-file=game-special-key=example-files/game.properties

$ oc create configmap game-config-3 --from-file=game-special-key=example-files/game.properties

Copy to Clipboard

Toggle word wrap

注記

ファイルから設定マップを作成する場合、UTF8 以外のデータを破損することなく、UTF8 以外のデータを含むファイルをこの新規フィールドに配置できます。OpenShift Container Platform はバイナリーファイルを検出し、ファイルを MIME として透過的にエンコーディングします。サーバーでは、データを破損することなく MIME ペイロードがデコーディングされ、保存されます。

前提条件

config map に追加するデータを含むファイルを含むディレクトリーが必要です。

次の手順では、サンプルファイル game.properties および ui.properties を使用します。

cat example-files/game.properties

$ cat example-files/game.properties

Copy to Clipboard

Toggle word wrap

出力例

enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

Copy to Clipboard

Toggle word wrap

cat example-files/ui.properties

$ cat example-files/ui.properties

Copy to Clipboard

Toggle word wrap

出力例

color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Copy to Clipboard

Toggle word wrap

手順

特定のファイルを指定して設定マップを作成します。

oc create configmap game-config-2 \
    --from-file=example-files/game.properties \
    --from-file=example-files/ui.properties

$ oc create configmap game-config-2 \
    --from-file=example-files/game.properties \
    --from-file=example-files/ui.properties

Copy to Clipboard

Toggle word wrap

キーと値のペアを指定して、設定マップを作成します。

oc create configmap game-config-3 \
    --from-file=game-special-key=example-files/game.properties

$ oc create configmap game-config-3 \
    --from-file=game-special-key=example-files/game.properties

Copy to Clipboard

Toggle word wrap

検証

-o オプションを使用してオブジェクトの oc get コマンドを入力し、ファイルからキーの値を表示します。

oc get configmaps game-config-2 -o yaml

$ oc get configmaps game-config-2 -o yaml

Copy to Clipboard

Toggle word wrap

出力例

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:52:05Z
  name: game-config-2
  namespace: default
  resourceVersion: "516"
  selflink: /api/v1/namespaces/default/configmaps/game-config-2
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:52:05Z
  name: game-config-2
  namespace: default
  resourceVersion: "516"
  selflink: /api/v1/namespaces/default/configmaps/game-config-2
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

-o オプションを使用してオブジェクトの oc get コマンドを入力し、key-value (キー/値) ペアからキーの値を表示します。

oc get configmaps game-config-3 -o yaml

$ oc get configmaps game-config-3 -o yaml

Copy to Clipboard

Toggle word wrap

出力例

apiVersion: v1
data:
  game-special-key: |- 
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  selflink: /api/v1/namespaces/default/configmaps/game-config-3
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985

apiVersion: v1
data:
  game-special-key: |-


    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  selflink: /api/v1/namespaces/default/configmaps/game-config-3
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

1: これは、先の手順で設定したキーです。

2.10.3.3. リテラル値からの設定マップの作成
リンクのコピー

設定マップにリテラル値を指定することができます。

--from-literal オプションは、リテラル値をコマンドラインに直接指定できる key=value 構文を取ります。

手順

リテラル値を指定して設定マップを作成します。

oc create configmap special-config \
    --from-literal=special.how=very \
    --from-literal=special.type=charm

$ oc create configmap special-config \
    --from-literal=special.how=very \
    --from-literal=special.type=charm

Copy to Clipboard

Toggle word wrap

検証

-o オプションを使用してオブジェクトの oc get コマンドを入力し、キーの値を表示します。

oc get configmaps special-config -o yaml

$ oc get configmaps special-config -o yaml

Copy to Clipboard

Toggle word wrap

出力例

apiVersion: v1
data:
  special.how: very
  special.type: charm
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  selflink: /api/v1/namespaces/default/configmaps/special-config
  uid: dadce046-d673-11e5-8cd0-68f728db1985

apiVersion: v1
data:
  special.how: very
  special.type: charm
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  selflink: /api/v1/namespaces/default/configmaps/special-config
  uid: dadce046-d673-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

2.10.4. ユースケース: Pod で設定マップを使用する
リンクのコピー

以下のセクションでは、Pod で ConfigMap オブジェクトを使用する際のいくつかのユースケースを説明します。

2.10.4.1. 設定マップの使用によるコンテナーでの環境変数の設定
リンクのコピー

config map を使用して、コンテナーで個別の環境変数を設定するために使用したり、有効な環境変数名を生成するすべてのキーを使用してコンテナーで環境変数を設定するために使用したりすることができます。

例として、以下の設定マップを見てみましょう。

2 つの環境変数を含む ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config 
  namespace: default 
data:
  special.how: very 
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config


  namespace: default


data:
  special.how: very


  special.type: charm

Copy to Clipboard

Toggle word wrap

1: 設定マップの名前。
2: 設定マップが存在するプロジェクト。設定マップは同じプロジェクトの Pod によってのみ参照されます。
3 4: 注入する環境変数。

1 つの環境変数を含む ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config 
  namespace: default
data:
  log_level: INFO

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config


  namespace: default
data:
  log_level: INFO

Copy to Clipboard

Toggle word wrap

1: 設定マップの名前。
2: 注入する環境変数。

手順

configMapKeyRef セクションを使用して、Pod のこの ConfigMap のキーを使用できます。

特定の環境変数を注入するように設定されている Pod 仕様のサンプル

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env: 
        - name: SPECIAL_LEVEL_KEY 
          valueFrom:
            configMapKeyRef:
              name: special-config 
              key: special.how 
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config 
              key: special.type 
              optional: true 
      envFrom: 
        - configMapRef:
            name: env-config 
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:


        - name: SPECIAL_LEVEL_KEY


          valueFrom:
            configMapKeyRef:
              name: special-config


              key: special.how


        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config


              key: special.type


              optional: true


      envFrom:


        - configMapRef:
            name: env-config


      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: ConfigMap から指定された環境変数をプルするためのスタンザです。
2: キーの値を注入する Pod 環境変数の名前です。
3 5: 特定の環境変数のプルに使用する ConfigMap の名前です。
4 6: ConfigMap からプルする環境変数です。
7: 環境変数をオプションにします。オプションとして、Pod は指定された ConfigMap およびキーが存在しない場合でも起動します。
8: ConfigMap からすべての環境変数をプルするためのスタンザです。
9: すべての環境変数のプルに使用する ConfigMap の名前です。

この Pod が実行されると、Pod のログには以下の出力が含まれます。

SPECIAL_LEVEL_KEY=very
log_level=INFO

SPECIAL_LEVEL_KEY=very
log_level=INFO

Copy to Clipboard

Toggle word wrap

注記

SPECIAL_TYPE_KEY=charm は出力例にリスト表示されません。optional: true が設定されているためです。

2.10.4.2. 設定マップを使用したコンテナーコマンドのコマンドライン引数の設定
リンクのコピー

config map を使用すると、Kubernetes 置換構文 $(VAR_NAME) を使用してコンテナー内のコマンドまたは引数の値を設定できます。

例として、以下の設定マップを見てみましょう。

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

Copy to Clipboard

Toggle word wrap

手順

コンテナー内のコマンドに値を注入するには、環境変数として使用するキーを使用する必要があります。次に、$(VAR_NAME) 構文を使用してコンテナーのコマンドでそれらを参照することができます。

特定の環境変数を注入するように設定されている Pod 仕様のサンプル

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] 
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]


      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: 環境変数として使用するキーを使用して、コンテナーのコマンドに値を注入します。

この Pod が実行されると、test-container コンテナーで実行される echo コマンドの出力は以下のようになります。

very charm

very charm

Copy to Clipboard

Toggle word wrap

2.10.4.3. config map の使用によるボリュームへのコンテンツの注入
リンクのコピー

config map を使用して、コンテンツをボリュームに注入することができます。

ConfigMap カスタムリソース (CR) の例

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

Copy to Clipboard

Toggle word wrap

手順

config map を使用してコンテンツをボリュームに注入するには、2 つの異なるオプションを使用できます。

config map を使用してコンテンツをボリュームに注入するための最も基本的な方法は、キーがファイル名であり、ファイルの内容がキーの値になっているファイルでボリュームを設定する方法です。

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "cat", "/etc/config/special.how" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  volumes:
    - name: config-volume
      configMap:
        name: special-config 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "cat", "/etc/config/special.how" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  volumes:
    - name: config-volume
      configMap:
        name: special-config


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: キーを含むファイル。

この Pod が実行されると、cat コマンドの出力は以下のようになります。

very

very

Copy to Clipboard

Toggle word wrap

設定マップキーが投影されるボリューム内のパスを制御することもできます。

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "cat", "/etc/config/path/to/special-key" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: special.how
          path: path/to/special-key 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "cat", "/etc/config/path/to/special-key" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: special.how
          path: path/to/special-key


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: 設定マップキーへのパス。

この Pod が実行されると、cat コマンドの出力は以下のようになります。

very

very

Copy to Clipboard

Toggle word wrap

2.11. Pod への OCI イメージのマウント
リンクのコピー

Open Container Initiative (OCI) 準拠のコンテナーイメージを Pod に直接マウントできます。これにより、イメージ内のファイルにコンテナーがアクセスできるようになり、ファイルをベースイメージに含める必要がなくなります。その結果、OCI 準拠のレジストリーでデータをホストすることが可能になります。

2.11.1. イメージボリューム
リンクのコピー

イメージボリューム を使用すると、Open Container Initiative (OCI) 準拠のコンテナーイメージを Pod に直接マウントできます。これにより、イメージ内のファイルにコンテナーがアクセスできるようになり、ファイルをベースイメージに含める必要がなくなります。そのため、OCI 準拠のレジストリーでデータをホストすることが可能になります。

Pod でイメージボリュームを使用すると、OCI イメージおよびディストリビューション仕様標準を活用して、次のユースケースを含むいくつかのタスクを実行できます。

Pod 内の複数のコンテナー間で設定ファイルを共有でき、ベースイメージにファイルを含める必要がなくなるため、セキュリティーリスクとイメージサイズが最小限に抑えられます。
人工知能環境では、イメージボリュームを使用して、モデルサーバーと一緒に、大規模言語モデルの重みまたは機械学習モデルの重みを Pod にマウントできます。この方法により、モデルサーバーのコンテナーイメージにモデルの重みを含めなくても、モデルの重みを効率的に提供できます。したがって、モデルの仕様とコンテンツを、それらを処理する実行可能ファイルから分離することができます。
マルウェアスキャナー用のパブリックイメージを使用し、それをプライベートなマルウェアシグネチャーを含むボリュームにマウントできます。これにより、パブリックイメージの著作権によって許可されていない可能性があるベースイメージへのイメージの組み込みを行うことなく、それらのシグネチャーをロードできます。

イメージボリュームをマウントするには、Pod へのイメージボリュームの追加 で説明されているように、イメージへのパスを、オプションのプルポリシーとともに Pod 仕様に含めます。

2.11.2. Pod へのイメージボリュームの追加
リンクのコピー

Open Container Initiative (OCI) 準拠のコンテナーイメージをマウントするには、volume パラメーターを使用して、オプションのプルポリシーとともに Pod 仕様にイメージへのパスを含めます。Pod を直接作成することも、デプロイメントやレプリカセットなどの制御オブジェクトを使用することもできます。

手順

以下のような YAML ファイルを作成します。
```
apiVersion: v1
kind: Pod
metadata:
  name: image-volume
spec:
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian
    volumeMounts:
    - name: volume
      mountPath: /volume
  volumes:
  - name: volume
    image: 
      reference: quay.io/crio/image:v2 
      pullPolicy: Always 
```
```
apiVersion: v1
kind: Pod
metadata:
  name: image-volume
spec:
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian
    volumeMounts:
    - name: volume
      mountPath: /volume
  volumes:
  - name: volume
    image: 
```
1
```
      reference: quay.io/crio/image:v2 
```
2
```
      pullPolicy: Always 
```
3
Copy to Clipboard Toggle word wrap
1
ホストマシンで使用可能な OCI コンテナーイメージを指定します。
2
イメージへのパスを指定します。
3
プルポリシーを指定します。次のいずれかのオプションを使用します。
Always の場合、kubelet は常にイメージのプルを試行します。プルが失敗すると、kubelet は Pod を Failed に設定します。
Never の場合、kubelet はイメージをプルせず、ローカルイメージのみを使用します。イメージのいずれかのレイヤーがローカルに存在しない場合、またはそのイメージのマニフェストがまだキャッシュされていない場合、Pod が Failed 状態になります。
IfNotPresent の場合、kubelet はイメージが存在しない場合にイメージをプルします。イメージが存在せずプルが失敗すると、Pod が Failed になります。これがデフォルトです。
以下のコマンドを実行して Pod を作成します。
```
oc create -f <file_name>.yaml
```
```
$ oc create -f <file_name>.yaml
```
Copy to Clipboard Toggle word wrap

検証

次のようなコマンドを使用して Pod を調べ、イメージのプルとマウントに関する詳細情報を確認します。

oc describe pod <pod_name>

$ oc describe pod <pod_name>

Copy to Clipboard

Toggle word wrap

出力例

Name:             image-volume
Namespace:        default
# ...
Volumes:
  volume: 
    Type:        Image
    Reference:   quay.io/crio/image:v2
    PullPolicy:  IfNotPresent
# ...
Events:
  Type    Reason          Age                From               Message
  ----    ------          ----               ----               -------
# ...
  Normal  Pulling         46s                kubelet            Pulling image "quay.io/crio/image:v2"
  Normal  Pulled          44s                kubelet            Successfully pulled image "quay.io/crio/image:v2" in 2.261s (2.261s including waiting). Image size: 6707 bytes. 
# ...

Name:             image-volume
Namespace:        default
# ...
Volumes:
  volume:


    Type:        Image
    Reference:   quay.io/crio/image:v2
    PullPolicy:  IfNotPresent
# ...
Events:
  Type    Reason          Age                From               Message
  ----    ------          ----               ----               -------
# ...
  Normal  Pulling         46s                kubelet            Pulling image "quay.io/crio/image:v2"
  Normal  Pulled          44s                kubelet            Successfully pulled image "quay.io/crio/image:v2" in 2.261s (2.261s including waiting). Image size: 6707 bytes.


# ...

Copy to Clipboard

Toggle word wrap

1: イメージが Pod にマウントされたことを示します。
2: イメージが正常にプルされたことを示します。

2.12. Pod で外部リソースにアクセスするためのデバイスプラグインの使用
リンクのコピー

デバイスプラグインを使用すると、カスタムコードを作成せずに特定のデバイスタイプ (GPU、InfiniBand、またはベンダー固有の初期化およびセットアップを必要とする他の同様のコンピューティングリソース) を OpenShift Container Platform Pod で使用できます。

2.12.1. デバイスプラグインについて
リンクのコピー

デバイスプラグインは、クラスター間でハードウェアデバイスを使用する際の一貫した移植可能なソリューションを提供します。デバイスプラグインは、拡張メカニズムを通じてこれらのデバイスをサポートし (これにより、コンテナーがこれらのデバイスを利用できるようになります)、デバイスのヘルスチェックを実施し、それらをセキュアに共有します。

重要

OpenShift Container Platform はデバイスのプラグイン API をサポートしますが、デバイスプラグインコンテナーは個別のベンダーによりサポートされます。

デバイスプラグインは、特定のハードウェアリソースの管理を行う、ノード上で実行される gRPC サービスです (kubelet の外部にあります)。デバイスプラグインは以下のリモートプロシージャーコール (RPC) をサポートしている必要があります。

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as resetting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as resetting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}

Copy to Clipboard

Toggle word wrap

2.12.1.1. デバイスプラグインの例
リンクのコピー

注記

デバイスプラグイン参照の実装を容易にするために、vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go という Device Manager コードのスタブデバイスプラグインを使用できます。

2.12.1.2. デバイスプラグインのデプロイ方法
リンクのコピー

デーモンセットは、デバイスプラグインのデプロイメントに推奨される方法です。
起動時にデバイスプラグインは、Device Manager から RPC を送信するためにノードの /var/lib/kubelet/device-plugin/ での UNIX ドメインソケットの作成を試行します。
デバイスプラグインは、ソケットの作成のほかにもハードウェアリソース、ホストファイルシステムへのアクセスを管理する必要があるため、特権付きセキュリティーコンテキストで実行される必要があります。
デプロイメント手順の詳細は、それぞれのデバイスプラグインの実装で確認できます。

2.12.2. Device Manager について
リンクのコピー

Device Manager は、特殊なノードのハードウェアリソースを、デバイスプラグインとして知られるプラグインを使用して公開するメカニズムを提供します。

特殊なハードウェアは、アップストリームのコード変更なしに公開できます。

重要

OpenShift Container Platform はデバイスのプラグイン API をサポートしますが、デバイスプラグインコンテナーは個別のベンダーによりサポートされます。

Device Manager はデバイスを 拡張リソース として公開します。ユーザー Pod は、他の 拡張リソース を要求するために使用されるのと同じ 制限/要求 メカニズムを使用して Device Manager で公開されるデバイスを消費できます。

使用開始時に、デバイスプラグインは /var/lib/kubelet/device-plugins/kubelet.sock の Register を起動して Device Manager に自己登録し、Device Manager の要求を提供するために /var/lib/kubelet/device-plugins/<plugin>.sock で gRPC サービスを起動します。

Device Manager は、新規登録要求の処理時にデバイスプラグインサービスで ListAndWatch リモートプロシージャーコール (RPC) を起動します。応答として Device Manager は gRPC ストリームでプラグインから デバイス オブジェクトの一覧を取得します。Device Manager はプラグインからの新規の更新の有無についてストリームを監視します。プラグイン側では、プラグインはストリームを開いた状態にし、デバイスの状態に変更があった場合には常に新規デバイスの一覧が同じストリーム接続で Device Manager に送信されます。

新しい Pod の受付リクエストの処理中に、Kubelet が要求された Extended Resources をデバイス割り当てのためにデバイスマネージャーに渡します。Device Manager はそのデータベースにチェックインして対応するプラグインが存在するかどうかを確認します。プラグインが存在し、ローカルキャッシュと共に割り当て可能な空きデバイスがある場合、Allocate RPC がその特定デバイスのプラグインで起動します。

さらにデバイスプラグインは、ドライバーのインストール、デバイスの初期化、およびデバイスのリセットなどの他のいくつかのデバイス固有の操作も実行できます。これらの機能は実装ごとに異なります。

2.12.3. Device Manager の有効化
リンクのコピー

Device Manager を有効にし、デバイスプラグインを実装してアップストリームのコード変更なしに特殊なハードウェアを公開できるようにします。

次のコマンドを入力して、設定するノードタイプの静的な MachineConfigPool CRD に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。
1. マシン設定を表示します。
  # oc describe machineconfig <name>
  Copy to Clipboard Toggle word wrap
  以下に例を示します。
  # oc describe machineconfig 00-worker
  Copy to Clipboard Toggle word wrap
  出力例
  Name: 00-worker Namespace: Labels: machineconfiguration.openshift.io/role=worker
  1
  
  Copy to Clipboard Toggle word wrap
  1
  Device Manager に必要なラベル。

手順

設定変更のためのカスタムリソース (CR) を作成します。

Device Manager CR の設定例

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: devicemgr 
spec:
  machineConfigPoolSelector:
    matchLabels:
       machineconfiguration.openshift.io: devicemgr 
  kubeletConfig:
    feature-gates:
      - DevicePlugins=true

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: devicemgr


spec:
  machineConfigPoolSelector:
    matchLabels:
       machineconfiguration.openshift.io: devicemgr


  kubeletConfig:
    feature-gates:
      - DevicePlugins=true

Copy to Clipboard

Toggle word wrap

1: CR に名前を割り当てます。
2: Machine Config Pool からラベルを入力します。
3: DevicePlugins を 'true` に設定します。

Device Manager を作成します。

oc create -f devicemgr.yaml

$ oc create -f devicemgr.yaml

Copy to Clipboard

Toggle word wrap

出力例

kubeletconfig.machineconfiguration.openshift.io/devicemgr created

kubeletconfig.machineconfiguration.openshift.io/devicemgr created

Copy to Clipboard

Toggle word wrap

Device Manager が実際に有効にされるように、/var/lib/kubelet/device-plugins/kubelet.sock がノードで作成されていることを確認します。これは、Device Manager の gRPC サーバーが新規プラグインの登録がないかどうかリッスンする UNIX ドメインソケットです。このソケットファイルは、Device Manager が有効にされている場合にのみ Kubelet の起動時に作成されます。

2.13. Pod スケジューリングの決定に Pod の優先順位を含める
リンクのコピー

クラスターで Pod の優先順位およびプリエンプションを有効にできます。Pod の優先度は、他の Pod との比較した Pod の重要度を示し、その優先度に基づいて Pod をキューに入れます。Pod のプリエンプションは、クラスターが優先順位の低い Pod の退避またはプリエンプションを実行することを可能にするため、適切なノードに利用可能な領域がない場合に優先順位のより高い Pod をスケジュールできます。Pod の優先順位は Pod のスケジューリングの順序にも影響を与え、リソース不足の場合のノード上での退避の順序に影響を与えます。

優先順位およびプリエンプションを使用するには、Pod の相対的な重みを定義する優先順位クラスを作成します。次に Pod 仕様で優先順位クラスを参照し、スケジューリングの重みを適用します。

2.13.1. Pod の優先順位について
リンクのコピー

Pod の優先順位およびプリエンプション機能を使用する場合、スケジューラーは優先順位に基づいて保留中の Pod を順序付け、保留中の Pod はスケジューリングのキューで優先順位のより低い他の保留中の Pod よりも前に置かれます。その結果、より優先順位の高い Pod は、スケジューリングの要件を満たす場合に優先順位の低い Pod よりも早くスケジュールされる可能性があります。Pod をスケジュールできない場合、スケジューラーは引き続き他の優先順位の低い Pod をスケジュールします。

2.13.1.1. Pod の優先順位クラス
リンクのコピー

Pod には優先順位クラスを割り当てることができます。これは、名前から優先順位の整数値へのマッピングを定義する namespace を使用していないオブジェクトです。値が高いと優先順位が高くなります。

優先順位およびプリエンプションは、1000000000 (10 億) 以下の 32 ビットの整数値を取ることができます。プリエンプションや退避を実行すべきでない Critical Pod 用に 10 億以上の数値を予約する必要があります。デフォルトで、OpenShift Container Platform には 2 つの予約された優先順位クラスがあり、これらは重要なシステム Pod で保証されたスケジューリングが適用されるために使用されます。

oc get priorityclasses

$ oc get priorityclasses

Copy to Clipboard

Toggle word wrap

出力例

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-node-critical      2000001000   false            72m
system-cluster-critical   2000000000   false            72m
openshift-user-critical   1000000000   false            3d13h
cluster-logging           1000000      false            29s

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-node-critical      2000001000   false            72m
system-cluster-critical   2000000000   false            72m
openshift-user-critical   1000000000   false            3d13h
cluster-logging           1000000      false            29s

Copy to Clipboard

Toggle word wrap

system-node-critical: この優先順位クラスには 2000001000 の値があり、ノードから退避すべきでないすべての Pod に使用されます。この優先順位クラスを持つ Pod の例としては、ovnkube-node などがあります。数多くの重要なコンポーネントには、デフォルトで system-node-critical の優先順位クラスが含まれます。以下は例になります。
- master-api
- master-controller
- master-etcd
- ovn-kubernetes
- sync
system-cluster-critical: この優先順位クラスには 2000000000 (20 億) の値があり、クラスターに重要な Pod に使用されます。この優先順位クラスの Pod は特定の状況でノードから退避される可能性があります。たとえば、system-node-critical 優先順位クラスで設定される Pod が優先される可能性があります。この場合でも、この優先順位クラスではスケジューリングが保証されます。この優先順位クラスを持つ可能性のある Pod の例として、fluentd、descheduler などのアドオンコンポーネントなどがあります。数多くの重要なコンポーネントには、デフォルトで system-cluster-critical 優先順位クラスが含まれます。以下はその一例です。
- fluentd
- metrics-server
- descheduler
openshift-user-critical: priorityClassName フィールドを、リソース消費をバインドできず、予測可能なリソース消費動作がない重要な Pod で使用できます。openshift-monitoring および openshift-user-workload-monitoring namespace 下にある Prometheus Pod は、openshift-user-critical priorityClassName を使用します。モニタリングのワークロードは system-critical を最初の priorityClass として使用しますが、これにより、モニタリング時にメモリーが過剰に使用され、ノードが退避できない問題が発生します。その結果、モニタリングの優先順位が下がり、スケジューラーに柔軟性が与えられ、重要なノードの動作を維持するために重いワークロード発生します。
cluster-logging: この優先順位は、Fluentd Pod が他のアプリケーションより優先してノードにスケジュールされるようにするために Fluentd で使用されます。

2.13.1.2. Pod の優先順位名
リンクのコピー

1 つ以上の優先順位クラスを準備した後に、Pod 仕様に優先順位クラス名を指定する Pod を作成できます。優先順位のアドミッションコントローラーは、優先順位クラス名フィールドを使用して優先順位の整数値を設定します。名前付きの優先順位クラスが見つからない場合、Pod は拒否されます。

2.13.2. Pod のプリエンプションについて
リンクのコピー

開発者が Pod を作成する場合、Pod はキューに入れられます。開発者が Pod の優先順位またはプリエンプションを設定している場合、スケジューラーはキューから Pod を選択し、Pod をノードにスケジュールしようとします。スケジューラーが Pod に指定されたすべての要件を満たす適切なノードに領域を見つけられない場合、プリエンプションロジックが保留中の Pod にトリガーされます。

スケジューラーがノードで 1 つ以上の Pod のプリエンプションを実行する場合、優先順位の高い Pod 仕様の nominatedNodeName フィールドは、nodename フィールドと共にノードの名前に設定されます。スケジューラーは nominatedNodeName フィールドを使用して Pod の予約されたリソースを追跡し、またクラスターのプリエンプションに関する情報をユーザーに提供します。

スケジューラーが優先順位の低い Pod のプリエンプションを実行した後に、スケジューラーは Pod のグレースフルな終了期間を許可します。スケジューラーが優先順位の低い Pod の終了を待機する間に別のノードが利用可能になると、スケジューラーはそのノードに優先順位の高い Pod をスケジュールできます。その結果、Pod 仕様の nominatedNodeName フィールドおよび nodeName フィールドが異なる可能性があります。

さらに、スケジューラーがノード上で Pod のプリエンプションを実行し、終了を待機している場合で、保留中の Pod よりも優先順位の高い Pod をスケジュールする必要がある場合、スケジューラーは代わりに優先順位の高い Pod をスケジュールできます。その場合、スケジューラーは保留中の Pod の nominatedNodeName をクリアし、その Pod を他のノードの対象とすることができます。

プリエンプションは、ノードから優先順位の低いすべての Pod を削除する訳ではありません。スケジューラーは、優先順位の低い Pod の一部を削除して保留中の Pod をスケジュールできます。

スケジューラーは、保留中の Pod をノードにスケジュールできる場合にのみ、Pod のプリエンプションを実行するノードを考慮します。

2.13.2.1. プリエンプションを実行しない優先順位クラス
リンクのコピー

プリエンプションポリシーが Never に設定された Pod は優先順位の低い Pod よりも前のスケジューリングキューに置かれますが、他の Pod のプリエンプションを実行することはできません。スケジュールを待機しているプリエンプションを実行しない Pod は、十分なリソースが解放され、これがスケジュールされるまでスケジュールキュー内に留まります。他の Pod などのプリエンプションを実行しない Pod はスケジューラーのバックオフの対象になります。つまり、スケジューラーがこれらの Pod のスケジュールの試行に成功しない場合、低頻度で再試行されるため、優先順位の低い他の Pod をそれらの Pod よりも前にスケジュールできます。

プリエンプションを実行しない Pod には、他の優先順位の高い Pod が依然としてプリエンプションを実行できます。

2.13.2.2. Pod プリエンプションおよび他のスケジューラーの設定
リンクのコピー

Pod の優先順位およびプリエンプションを有効にする場合、他のスケジューラー設定を考慮します。

Pod の優先順位および Pod の Disruption Budget (停止状態の予算): Pod の Disruption Budget (停止状態の予算) は一度に稼働している必要のあるレプリカの最小数またはパーセンテージを指定します。Pod の Disruption Budget (停止状態の予算) を指定する場合、OpenShift Container Platform は、Best Effort レベルで Pod のプリエンプションを実行する際にそれらを適用します。スケジューラーは、Pod の Disruption Budget (停止状態の予算) に違反しない範囲で Pod のプリエンプションを試行します。該当する Pod が見つからない場合には、Pod の Disruption Budget (停止状態の予算) の要件を無視して優先順位の低い Pod のプリエンプションが実行される可能性があります。
Pod の優先順位およびアフィニティー: Pod のアフィニティーは、新規 Pod が同じラベルを持つ他の Pod と同じノードにスケジュールされることを要求します。

保留中の Pod にノード上の 1 つ以上の優先順位の低い Pod との Pod 間のアフィニティーがある場合、スケジューラーはアフィニティーの要件を違反せずに優先順位の低い Pod のプリエンプションを実行することはできません。この場合、スケジューラーは保留中の Pod をスケジュールするための別のノードを探します。ただし、スケジューラーが適切なノードを見つけることは保証できず、保留中の Pod がスケジュールされない可能性があります。

この状態を防ぐには、優先順位が等しい Pod との Pod のアフィニティーの設定を慎重に行ってください。

2.13.2.3. プリエンプションが実行された Pod のグレースフルな終了
リンクのコピー

Pod のプリエンプションの実行中、スケジューラーは Pod のグレースフルな終了期間が期限切れになるのを待機します。その後、Pod は機能を完了し、終了します。Pod がこの期間後も終了しない場合、スケジューラーは Pod を強制終了します。このようにグレースフルな終了期間が原因で、スケジューラーによる Pod のプリエンプションの実行時と保留中の Pod のノードへのスケジュール時に時間差が出ます。

このギャップを最小限に抑えるには、優先度の低い Pod に対してグレースフルな終了期間を短く設定します。

2.13.3. 優先順位およびプリエンプションの設定
リンクのコピー

Pod 仕様で priorityClassName を使用して優先順位クラスオブジェクトを作成し、Pod を優先順位に関連付けることで、Pod の優先度およびプリエンプションを適用できます。

注記

優先クラスを既存のスケジュール済み Pod に直接追加することはできません。

手順

優先順位およびプリエンプションを使用するようにクラスターを設定するには、以下を実行します。

1 つ以上の優先順位クラスを作成します。
1. 以下のような YAML ファイルを作成します。
  apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority
  1
  value: 1000000
  2
  preemptionPolicy: PreemptLowerPriority
  3
  globalDefault: false
  4
  description: "This priority class should be used for XYZ service pods only."
  5
  Copy to Clipboard Toggle word wrap
  1
  優先順位クラスオブジェクトの名前です。
  2
  オブジェクトの優先順位の値です。
  3
  オプション: この優先クラスがプリエンプティングであるか非プリエンプティングであるかを指定します。プリエンプションポリシーは、デフォルトで PreemptLowerPriority に設定されます。これにより、その優先順位クラスの Pod はそれよりも優先順位の低い Pod のプリエンプションを実行できます。プリエンプションポリシーが Never に設定される場合、その優先順位クラスの Pod はプリエンプションを実行しません。
  4
  オプション: 優先クラス名が指定されていない Pod にこの優先クラスを使用するかどうかを指定します。このフィールドはデフォルトで false です。globalDefault が true に設定される 1 つの優先順位クラスのみがクラスター内に存在できます。globalDefault:true が設定された優先順位クラスがない場合、優先順位クラス名が設定されていない Pod の優先順位はゼロになります。globalDefault:true が設定された優先順位クラスを追加すると、優先順位クラスが追加された後に作成された Pod のみがその影響を受け、これによって既存 Pod の優先順位は変更されません。
  5
  オプション: 開発者がこの優先クラスで使用する必要がある Pod を説明します。任意の文字列を入力します。
2. 優先クラスを作成します。
  $ oc create -f <file-name>.yaml
  Copy to Clipboard Toggle word wrap

優先クラスの名前を含む Pod 仕様を作成します。

以下のような YAML ファイルを作成します。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  priorityClassName: high-priority

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  priorityClassName: high-priority

Copy to Clipboard

Toggle word wrap

1: この Pod で使用する優先順位クラスを指定します。

Pod を作成します。
```
oc create -f <file-name>.yaml
```
```
$ oc create -f <file-name>.yaml
```
Copy to Clipboard Toggle word wrap

優先順位の名前は Pod 設定または Pod テンプレートに直接追加できます。

2.14. ノードセレクターの使用による特定ノードへの Pod の配置
リンクのコピー

ノードセレクター は、キーと値のペアのマップを指定します。ルールは、ノード上のカスタムラベルと Pod で指定されたセレクターを使用して定義されます。

Pod がノードで実行する要件を満たすには、Pod はノードのラベルとして示されるキーと値のペアを持っている必要があります。

同じ Pod 設定でノードのアフィニティーとノードセレクターを使用している場合、以下の重要な考慮事項を参照してください。

2.14.1. ノードセレクターの使用による Pod 配置の制御
リンクのコピー

Pod でノードセレクターを使用し、ノードでラベルを使用して、Pod がスケジュールされる場所を制御できます。ノードセレクターにより、OpenShift Container Platform は一致するラベルが含まれるノード上に Pod をスケジュールします。

ラベルをノード、コンピュートマシンセット、またはマシン設定に追加します。コンピュートマシンセットにラベルを追加すると、ノードまたはマシンが停止した場合に、新規ノードにそのラベルが追加されます。ノードまたはマシン設定に追加されるラベルは、ノードまたはマシンが停止すると維持されません。

ノードセレクターを既存 Pod に追加するには、ノードセレクターを ReplicaSet オブジェクト、DaemonSet オブジェクト、StatefulSet オブジェクト、Deployment オブジェクト、または DeploymentConfig オブジェクトなどの Pod の制御オブジェクトに追加します。制御オブジェクト下の既存 Pod は、一致するラベルを持つノードで再作成されます。新規 Pod を作成する場合、ノードセレクターを Pod 仕様に直接追加できます。Pod に制御オブジェクトがない場合は、Pod を削除し、Pod 仕様を編集して、Pod を再作成する必要があります。

注記

ノードセレクターを既存のスケジュールされている Pod に直接追加することはできません。

前提条件

ノードセレクターを既存 Pod に追加するには、Pod の制御オブジェクトを判別します。たとえば、router-default-66d5cf9464-m2g75 Pod は router-default-66d5cf9464 レプリカセットによって制御されます。

oc describe pod router-default-66d5cf9464-7pwkc

$ oc describe pod router-default-66d5cf9464-7pwkc

Copy to Clipboard

Toggle word wrap

出力例

kind: Pod
apiVersion: v1
metadata:
# ...
Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress
# ...
Controlled By:      ReplicaSet/router-default-66d5cf9464
# ...

kind: Pod
apiVersion: v1
metadata:
# ...
Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress
# ...
Controlled By:      ReplicaSet/router-default-66d5cf9464
# ...

Copy to Clipboard

Toggle word wrap

Web コンソールでは、Pod YAML の ownerReferences に制御オブジェクトをリスト表示します。

apiVersion: v1
kind: Pod
metadata:
  name: router-default-66d5cf9464-7pwkc
# ...
  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true
# ...

apiVersion: v1
kind: Pod
metadata:
  name: router-default-66d5cf9464-7pwkc
# ...
  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true
# ...

Copy to Clipboard

Toggle word wrap

手順

コンピュートマシンセットを使用するか、ノードを直接編集してラベルをノードに追加します。

MachineSet オブジェクトを使用して、ノードの作成時にコンピュートマシンセットによって管理されるノードにラベルを追加します。

以下のコマンドを実行してラベルを MachineSet オブジェクトに追加します。

oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

$ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

以下に例を示します。

oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

$ oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

ヒント

あるいは、以下の YAML を適用してコンピュートマシンセットにラベルを追加することもできます。

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: xf2bd-infra-us-east-2a
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"
# ...

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: xf2bd-infra-us-east-2a
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"
# ...

Copy to Clipboard

Toggle word wrap

oc edit コマンドを使用して、ラベルが MachineSet オブジェクトに追加されていることを確認します。

以下に例を示します。

oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

$ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

MachineSet オブジェクトの例

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet

# ...

spec:
# ...
  template:
    metadata:
# ...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
# ...

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet

# ...

spec:
# ...
  template:
    metadata:
# ...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
# ...

Copy to Clipboard

Toggle word wrap

ラベルをノードに直接追加します。

ノードの Node オブジェクトを編集します。

oc label nodes <name> <key>=<value>

$ oc label nodes <name> <key>=<value>

Copy to Clipboard

Toggle word wrap

たとえば、ノードにラベルを付けるには、以下を実行します。

oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

$ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

Copy to Clipboard

Toggle word wrap

ヒント

あるいは、以下の YAML を適用してノードにラベルを追加することもできます。

kind: Node
apiVersion: v1
metadata:
  name: hello-node-6fbccf8d9
  labels:
    type: "user-node"
    region: "east"
# ...

kind: Node
apiVersion: v1
metadata:
  name: hello-node-6fbccf8d9
  labels:
    type: "user-node"
    region: "east"
# ...

Copy to Clipboard

Toggle word wrap

ラベルがノードに追加されていることを確認します。

oc get nodes -l type=user-node,region=east

$ oc get nodes -l type=user-node,region=east

Copy to Clipboard

Toggle word wrap

出力例

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.33.4

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.33.4

Copy to Clipboard

Toggle word wrap

一致するノードセレクターを Pod に追加します。

ノードセレクターを既存 Pod および新規 Pod に追加するには、ノードセレクターを Pod の制御オブジェクトに追加します。

ラベルを含む ReplicaSet オブジェクトのサンプル

kind: ReplicaSet
apiVersion: apps/v1
metadata:
  name: hello-node-6fbccf8d9
# ...
spec:
# ...
  template:
    metadata:
      creationTimestamp: null
      labels:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        pod-template-hash: 66d5cf9464
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ''
        type: user-node 
# ...

kind: ReplicaSet
apiVersion: apps/v1
metadata:
  name: hello-node-6fbccf8d9
# ...
spec:
# ...
  template:
    metadata:
      creationTimestamp: null
      labels:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        pod-template-hash: 66d5cf9464
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ''
        type: user-node


# ...

Copy to Clipboard

Toggle word wrap

1: ノードセレクターを追加します。

ノードセレクターを特定の新規 Pod に追加するには、セレクターを Pod オブジェクトに直接追加します。
ノードセレクターを持つ Pod オブジェクトの例
```
apiVersion: v1
kind: Pod
metadata:
  name: hello-node-6fbccf8d9
# ...
spec:
  nodeSelector:
    region: east
    type: user-node
# ...
```
```
apiVersion: v1
kind: Pod
metadata:
  name: hello-node-6fbccf8d9
# ...
spec:
  nodeSelector:
    region: east
    type: user-node
# ...
```
Copy to Clipboard Toggle word wrap
注記
ノードセレクターを既存のスケジュールされている Pod に直接追加することはできません。

2.15. Pod への GPU の割り当て
リンクのコピー

属性ベースの GPU 割り当てを使用すると、OpenShift Container Platform でのグラフィックスプロセッシングユニット (GPU) リソース割り当てを細かく制御できるようになります。これにより、製品名、GPU メモリー容量、計算能力、ベンダー名、ドライバーバージョンなどの特定のデバイス属性に基づいて Pod が GPU を要求できるようになります。これらの属性は、サードパーティーの Dynamic Resource Allocation (DRA) ドライバーによって公開されます。

重要

属性ベースの GPU 割り当ては、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat テクノロジープレビュー機能のサポート範囲の詳細は、次のリンクを参照してください。

テクノロジープレビュー機能のサポート範囲

2.15.1. ワークロードへの GPU の割り当てについて
リンクのコピー

属性ベースの GPU 割り当てを使用すると、Pod が特定のデバイス属性に基づいてグラフィックスプロセッシングユニット (GPU) を要求できるようになります。これにより、Pod が必要とする指定どおりの GPU が各 Pod に割り当てられます。

属性ベースのリソース割り当てを使用するには、Dynamic Resource Allocation (DRA) ドライバーをインストールする必要があります。DRA ドライバーは、クラスター内の各ノードで動作し、そのノードのハードウェアとの橋渡しをするサードパーティーアプリケーションです。

DRA ドライバーは、以下の属性を含むいくつかの GPU デバイス属性をアドバタイズします。これらは OpenShift Container Platform が GPU の正確な選択に使用できる属性です。

製品名: Pod は、パフォーマンス要件やアプリケーションとの互換性に基づいて、正確な GPU モデルを要求できます。これにより、ワークロードがタスクに最適なハードウェアを活用できるようになります。
GPU メモリー容量: Pod は、8 GB、16 GB、40 GB など、最小または最大メモリー容量を持つ GPU を要求できます。これは、大規模な AI モデルのトレーニングやデータ処理など、メモリーを大量に消費するワークロードに役立ちます。この属性を使用すると、リソースの過剰な割り当てや不十分な使用を防ぎながら、アプリケーションがメモリーの要件に合わせて GPU を確保できるようになります。
計算能力: Pod は、サポートされている CUDA バージョンなど、GPU の計算能力に基づいて GPU を要求できます。Pod は、アプリケーションのフレームワークと互換性のある GPU をターゲットにして、最適化された処理能力を活用できます。
電力と熱のプロファイル: Pod は、電力使用量や熱特性に基づいて GPU を要求できます。これにより、電力や温度の影響を受けやすいアプリケーションを効率的に動作させることができます。これは、電力や冷却に制約がある高密度環境で特に役立ちます。
デバイス ID とベンダー ID: Pod は、GPU のハードウェアの詳細に基づいて GPU を要求できます。これにより、特定のベンダーまたはデバイスタイプを必要とするアプリケーションが、ターゲットを絞った要求を行えるようになります。
ドライバーバージョン: Pod は、特定のドライバーバージョンを実行する GPU を要求できます。これにより、アプリケーションの依存関係との互換性が確保され、GPU 機能へのアクセスが最大化されます。

2.15.2. GPU 割り当てオブジェクトについて
リンクのコピー

属性ベースの GPU 割り当ては、次のオブジェクトを使用して、グラフィックスプロセッシングユニット (GPU) の主要な割り当て機能を提供します。これらの API の種類は、すべて resource.k8s.io/v1beta2 API グループに含まれています。

デバイスクラス

デバイスクラスは、Pod が要求できるデバイスのカテゴリーと、要求時に特定のデバイス属性を選択する方法です。一部のデバイスドライバーには独自のデバイスクラスが含まれています。管理者がデバイスクラスを作成することもできます。デバイスクラスにはデバイスセレクターが含まれています。デバイスセレクターは、デバイスが要求を満たす場合に true と評価される Common Expression Language (CEL) 式です。

次の例の DeviceClass オブジェクトは、driver.example.com デバイスドライバーによって管理されるすべてのデバイスを選択します。

デバイスクラスオブジェクトの例

apiVersion: resource.k8s.io/v1beta1
kind: DeviceClass
metadata:
  name: example-device-class
spec:
  selectors:
  - cel:
      expression: |-
        device.driver == "driver.example.com"

apiVersion: resource.k8s.io/v1beta1
kind: DeviceClass
metadata:
  name: example-device-class
spec:
  selectors:
  - cel:
      expression: |-
        device.driver == "driver.example.com"

Copy to Clipboard

Toggle word wrap

リソーススライス

各ノードの Dynamic Resource Allocation (DRA) ドライバーは、クラスター内の リソーススライス を作成および管理します。リソーススライスは、ノードに割り当てられている 1 つ以上の GPU リソースを表します。リソースクレームが作成され、Pod で使用されると、OpenShift Container Platform はリソーススライスを使用して、要求されたリソースにアクセスできるノードを探します。リソースクレームに適したリソーススライスが見つかると、OpenShift Container Platform のスケジューラーが、割り当ての詳細を使用してリソースクレームを更新し、リソースクレームにリソースを割り当て、リソースにアクセスできるノードに Pod をスケジュールします。

リソースクレームテンプレート

クラスターの管理者と運用担当者は、特定のデバイスクラスから GPU を要求するための リソースクレームテンプレート を作成できます。リソースクレームテンプレートは、それぞれ分離された類似のリソースへのアクセスを Pod に提供します。OpenShift Container Platform は、リソースクレームテンプレートを使用して、Pod のリソースクレームを生成します。OpenShift Container Platform がテンプレートから生成する各リソースクレームは、特定の Pod にバインドされます。Pod が終了すると、OpenShift Container Platform は対応するリソースクレームを削除します。

次のリソースクレームテンプレートの例では、example-device-class デバイスクラス内のデバイスを要求します。

リソースクレームテンプレートオブジェクトの例

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
  namespace: gpu-test1
  name: gpu-claim-template
spec:
# ...
  spec:
    devices:
      requests:
      - name: gpu
        deviceClassName: example-device-class

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
  namespace: gpu-test1
  name: gpu-claim-template
spec:
# ...
  spec:
    devices:
      requests:
      - name: gpu
        deviceClassName: example-device-class

Copy to Clipboard

Toggle word wrap

リソースクレーム

管理者と運用担当者は、特定のデバイスクラスから GPU を要求する リソースクレーム を作成できます。リソースクレームは、GPU を複数の Pod で共有できる点で、リソースクレームテンプレートとは異なります。また、要求元の Pod が終了しても、リソースクレームは削除されません。

次のリソースクレームテンプレートの例では、CEL 式を使用して、example-device-class デバイスクラス内の特定のサイズを持つ特定のデバイスを要求します。

リソースクレームオブジェクトの例

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  namespace: gpu-claim
  name: gpu-devices
spec:
  devices:
    requests:
    - name: 1g-5gb
      deviceClassName: example-device-class
      selectors:
      - cel:
          expression: "device.attributes['driver.example.com'].profile == '1g.5gb'"
    - name: 1g-5gb-2
      deviceClassName: example-device-class
      selectors:
      - cel:
          expression: "device.attributes['driver.example.com'].profile == '1g.5gb'"
    - name: 2g-10gb
      deviceClassName: example-device-class
      selectors:
      - cel:
          expression: "device.attributes['driver.example.com'].profile == '2g.10gb'"
    - name: 3g-20gb
      deviceClassName: example-device-class
      selectors:
      - cel:
          expression: "device.attributes['driver.example.com'].profile == '3g.20gb'"

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  namespace: gpu-claim
  name: gpu-devices
spec:
  devices:
    requests:
    - name: 1g-5gb
      deviceClassName: example-device-class
      selectors:
      - cel:
          expression: "device.attributes['driver.example.com'].profile == '1g.5gb'"
    - name: 1g-5gb-2
      deviceClassName: example-device-class
      selectors:
      - cel:
          expression: "device.attributes['driver.example.com'].profile == '1g.5gb'"
    - name: 2g-10gb
      deviceClassName: example-device-class
      selectors:
      - cel:
          expression: "device.attributes['driver.example.com'].profile == '2g.10gb'"
    - name: 3g-20gb
      deviceClassName: example-device-class
      selectors:
      - cel:
          expression: "device.attributes['driver.example.com'].profile == '3g.20gb'"

Copy to Clipboard

Toggle word wrap

リソースクレーム、リソースクレームテンプレートの設定の詳細は、Dynamic Resource Allocation (Kubernetes ドキュメント) を参照してください。

Pod にリソースクレームを追加する方法は、「Pod へのリソースクレームの追加」を参照してください。

次のステップ

Pod へのリソースクレームの追加

2.15.3. Pod へのリソースクレームの追加
リンクのコピー

属性ベースの GPU 割り当てでは、Pod 内のコンテナーに対して特定のグラフィックスプロセッシングユニット (GPU) を要求できるようにするために、リソースクレームとリソースクレームテンプレートを使用します。リソースクレームは複数のコンテナーで使用できますが、リソースクレームテンプレートは 1 つのコンテナーでのみ使用できます。詳細は、関連情報 セクションの「デバイス属性を使用したデバイス割り当ての設定について」を参照してください。

次の手順の例では、特定の GPU を container0 に割り当てるリソースクレームテンプレートと、container1 と container2 間で GPU を共有するリソースクレームを作成します。

前提条件

Dynamic Resource Allocation (DRA) ドライバーがインストールされている。DRA の詳細は、Dynamic Resource Allocation (Kubernetes ドキュメント) を参照してください。
リソーススライスが作成されている。
リソースクレームやリソースクレームテンプレートが作成されている。
cluster という名前の FeatureGate CR を編集して、クラスターに必要なテクノロジープレビュー機能を有効にした。
FeatureGate CR の例
```
apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade 
```
```
apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade 
```
1
Copy to Clipboard Toggle word wrap
1
必要な機能を有効にします。
警告
クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、元に戻すことができず、マイナーバージョンの更新が妨げられます。この機能セットを使用すると、該当するテクノロジープレビュー機能をテストクラスターで有効にして、完全にテストすることができます。実稼働クラスターではこの機能セットを有効にしないでください。

手順

次のような YAML ファイルを作成して Pod を作成します。

リソースを要求する Pod の例

apiVersion: v1
kind: Pod
metadata:
  namespace: gpu-allocate
  name: pod1
  labels:
    app: pod
spec:
  restartPolicy: Never
  containers:
  - name: container0
    image: ubuntu:24.04
    command: ["sleep", "9999"]
    resources:
      claims: 
      - name: gpu-claim-template
  - name: container1
    image: ubuntu:24.04
    command: ["sleep", "9999"]
    resources:
      claims:
      - name: gpu-claim
  - name: container2
    image: ubuntu:24.04
    command: ["sleep", "9999"]
    resources:
      claims:
      - name: gpu-claim
  resourceClaims: 
  - name: gpu-claim-template
    resourceClaimTemplateName: example-resource-claim-template
  - name: gpu-claim
    resourceClaimName: example-resource-claim

apiVersion: v1
kind: Pod
metadata:
  namespace: gpu-allocate
  name: pod1
  labels:
    app: pod
spec:
  restartPolicy: Never
  containers:
  - name: container0
    image: ubuntu:24.04
    command: ["sleep", "9999"]
    resources:
      claims:


      - name: gpu-claim-template
  - name: container1
    image: ubuntu:24.04
    command: ["sleep", "9999"]
    resources:
      claims:
      - name: gpu-claim
  - name: container2
    image: ubuntu:24.04
    command: ["sleep", "9999"]
    resources:
      claims:
      - name: gpu-claim
  resourceClaims:


  - name: gpu-claim-template
    resourceClaimTemplateName: example-resource-claim-template
  - name: gpu-claim
    resourceClaimName: example-resource-claim

Copy to Clipboard

Toggle word wrap

1: このコンテナーで使用する 1 つ以上のリソースクレームを指定します。
2: コンテナーの起動に必要なリソースクレームを指定します。リソースクレームリクエストと、リソースクレームやリソースクレームテンプレートの任意の名前を含めます。

CRD オブジェクトを作成します。
```
oc create -f <file_name>.yaml
```
```
$ oc create -f <file_name>.yaml
```
Copy to Clipboard Toggle word wrap

Pod のリソースクレームを設定する方法の詳細は、Dynamic Resource Allocation (Kubernetes ドキュメント) を参照してください。

2.16. Run Once Duration Override Operator
リンクのコピー

2.16.1. Run Once Duration Override Operator の概要
リンクのコピー

Run Once Duration Override Operator を使用して、1 回実行 Pod をアクティブにできる最大時間制限を指定できます。

2.16.1.1. Run Once Duration Override Operator について
リンクのコピー

OpenShift Container Platform は 1 回実行 (run-once) Pod を使用して Pod のデプロイやビルドの実行などのタスクを実行します。1 回実行 (run-once) Pod は、RestartPolicy が Never または OnFailure の Pod です。

クラスター管理者は Run Once Duration Override Operator を使用して、1 回実行 Pod がアクティブになる時間を強制的に制限できます。期限が切れると、クラスターはそれらの Pod をアクティブに終了しようとします。このような制限を設ける主な理由は、ビルドなどのタスクが長い時間にわたって実行されることを防ぐことにあります。

Run Once Duration Override Operator から run-once duration override を 1 回実行 (run-once) Pod に適用するには、該当する各 namespace でそれを有効にする必要があります。

1 回実行 Pod と Run Once Duration Override Operator の両方に activeDeadlineSeconds 値が設定されている場合、2 つの値のうち小さい方が使用されます。

注記

Run Once Duration Override Operator は、HyperShift Operator によって管理されるクラスターにインストールすることはできません。

2.16.2. Run Once Duration Override Operator のリリースノート
リンクのコピー

クラスター管理者は Run Once Duration Override Operator を使用して、1 回実行 Pod がアクティブになる時間を強制的に制限できます。制限時間が経過すると、クラスターは 1 回実行 Pod を終了しようとします。このような制限を設ける主な理由は、ビルドなどのタスクが長い時間にわたって実行されることを防ぐことにあります。

これらのリリースノートでは、OpenShift Container Platform の Run Once Duration Override Operator の開発を追跡します。

Run Once Duration Override Operator の概要は、Run Once Duration Override Operator についてを参照してください。

2.16.2.1. Run Once Duration Override Operator 1.3.1
リンクのコピー

発行日: 2025 年 10 月 29 日

Run Once Duration Override Operator 1.3.1 に関しては、アドバイザリー RHBA-2025:19272 が利用可能です。

2.16.2.1.1. 新機能および機能拡張
リンクのコピー

この Run Once Duration Override Operator リリースでは、Kubernetes のバージョンが 1.33 に更新されます。

2.16.2.1.2. バグ修正
リンクのコピー

Run Once Duration Override Operator のこのリリースでは、いくつかの Common Vulnerabilities and Exposures (CVE) に対処しています。

2.16.2.2. Run Once Duration Override Operator 1.3.0
リンクのコピー

発行日: 2025 年 7 月 9 日

Run Once Duration Override Operator 1.3.0 に関しては、アドバイザリー RHBA-2025-10725 が利用可能です。

2.16.2.2.1. バグ修正
リンクのコピー

Run Once Duration Override Operator のこのリリースでは、いくつかの Common Vulnerabilities and Exposures (CVE) に対処しています。

2.16.3. 1 回実行 Pod のアクティブな期限をオーバーライドする
リンクのコピー

Run Once Duration Override Operator を使用して、1 回実行 Pod をアクティブにできる最大時間制限を指定できます。namespace で Run Once Duration Override Operator を有効にすると、その namespace で今後作成または更新されるすべての 1 回実行 (run-once) Pod の activeDeadlineSeconds フィールドが、Run Once Duration Override Operator で指定された値に設定されます。

注記

1 回実行 Pod と Run Once Duration Override Operator の両方に activeDeadlineSeconds 値が設定されている場合、2 つの値のうち小さい方が使用されます。

2.16.3.1. Run Once Duration Override Operator のインストール
リンクのコピー

Web コンソールを使用して、Run Once Duration Override Operator をインストールできます。

前提条件

cluster-admin 権限でクラスターにアクセスできる。
OpenShift Container Platform Web コンソールにアクセスできる。

手順

OpenShift Container Platform Web コンソールにログインします。
Run Once Duration Override Operator に必要な namespace を作成します。
1. Administration → Namespaces に移動し、Create Namespace をクリックします。
2. Name フィールドに openshift-run-once-duration-override-operator と入力し、Create をクリックします。
Run Once Duration Override Operator をインストールします。
1. Ecosystem → Software Catalog に移動します。
2. フィルターボックスに Run Once Duration Override Operator と入力します。
3. Run Once Duration Override Operator を選択し、Install をクリックします。
4. Install Operator ページで以下を行います。
  1. Update channel は stable に設定されており、これにより、Run Once Duration Override Operator の最新の安定リリースがインストールされます。
  2. A specific namespace on the cluster を選択します。
  3. openshift-run-once-duration-override-operator の下のドロップダウンメニューから openshift-run-once-duration-override-operator を選択します。
  4. Update approval strategy を選択します。
    Automatic ストラテジーを使用すると、新しいバージョンが利用可能になったときに、Operator Lifecycle Manager (OLM) によって Operator を自動的に更新できます。
    Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
  5. Install をクリックします。
RunOnceDurationOverride インスタンスを作成します。
1. Ecosystem → Installed Operators ページから、Run Once Duration Override Operator をクリックします。
2. Run Once Duration Override タブを選択し、Create RunOnceDurationOverride をクリックします。
3. 必要に応じて設定を編集します。
  runOnceDurationOverride セクションで、必要に応じて spec.activeDeadlineSeconds 値を更新できます。事前定義された値は 3600 秒、つまり 1 時間です。
4. Create をクリックします。

検証

OpenShift CLI にログインします。

すべての Pod が作成され、適切に実行されていることを確認します。

oc get pods -n openshift-run-once-duration-override-operator

$ oc get pods -n openshift-run-once-duration-override-operator

Copy to Clipboard

Toggle word wrap

出力例

NAME                                                   READY   STATUS    RESTARTS   AGE
run-once-duration-override-operator-7b88c676f6-lcxgc   1/1     Running   0          7m46s
runoncedurationoverride-62blp                          1/1     Running   0          41s
runoncedurationoverride-h8h8b                          1/1     Running   0          41s
runoncedurationoverride-tdsqk                          1/1     Running   0          41s

NAME                                                   READY   STATUS    RESTARTS   AGE
run-once-duration-override-operator-7b88c676f6-lcxgc   1/1     Running   0          7m46s
runoncedurationoverride-62blp                          1/1     Running   0          41s
runoncedurationoverride-h8h8b                          1/1     Running   0          41s
runoncedurationoverride-tdsqk                          1/1     Running   0          41s

Copy to Clipboard

Toggle word wrap

2.16.3.2. namespace での run-once duration override の有効化
リンクのコピー

前提条件

Run Once Duration Override Operator がインストールされます。

手順

OpenShift CLI にログインします。

ラベルを追加して、run-once duration override を有効にします。

oc label namespace <namespace> \
    runoncedurationoverrides.admission.runoncedurationoverride.openshift.io/enabled=true

$ oc label namespace <namespace> \


    runoncedurationoverrides.admission.runoncedurationoverride.openshift.io/enabled=true

Copy to Clipboard

Toggle word wrap

1: run-once duration override を有効にする namespace を指定します。

この namespace で run-once duration override を有効にすると、今後この namespace で作成される 1 回実行 Pod の activeDeadlineSeconds フィールドが、Run Once Duration Override Operator からのオーバーライド値に設定されます。この namespace の既存 Pod には、次の更新時に activeDeadlineSeconds 値も設定されます。

検証

run-once duration override を有効にした namespace に、1 回実行 Pod を作成します。

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: <namespace>                 
spec:
  restartPolicy: Never                   
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: busybox
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
      image: busybox:1.25
      command:
        - /bin/sh
        - -ec
        - |
          while sleep 5; do date; done

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: <namespace>


spec:
  restartPolicy: Never


  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: busybox
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
      image: busybox:1.25
      command:
        - /bin/sh
        - -ec
        - |
          while sleep 5; do date; done

Copy to Clipboard

Toggle word wrap

1: <namespace> を namespace の名前に置き換えます。
2: 1 回実行 (run-once) Pod には、restartPolicy が Never または OnFailure である必要があります。

Pod に activeDeadlineSeconds フィールドが設定されていることを確認します。
```
oc get pods -n <namespace> -o yaml | grep activeDeadlineSeconds
```
```
$ oc get pods -n <namespace> -o yaml | grep activeDeadlineSeconds
```
Copy to Clipboard Toggle word wrap
出力例
```
    activeDeadlineSeconds: 3600
```
```
    activeDeadlineSeconds: 3600
```
Copy to Clipboard Toggle word wrap

2.16.3.3. run-once active deadline override 値の更新
リンクのコピー

Run Once Duration Override Operator が 1 回実行 Pod (run-once Pod) に適用されるオーバーライド値をカスタマイズできます。事前定義された値は 3600 秒、つまり 1 時間です。

前提条件

cluster-admin 権限でクラスターにアクセスできる。
Run Once Duration Override Operator をインストールしました。

手順

OpenShift CLI にログインします。
RunOnceDurationOverride リソースを編集します。
```
oc edit runoncedurationoverride cluster
```
```
$ oc edit runoncedurationoverride cluster
```
Copy to Clipboard Toggle word wrap

activeDeadlineSeconds フィールドを更新します。

apiVersion: operator.openshift.io/v1
kind: RunOnceDurationOverride
metadata:
# ...
spec:
  runOnceDurationOverride:
    spec:
      activeDeadlineSeconds: 1800 
# ...

apiVersion: operator.openshift.io/v1
kind: RunOnceDurationOverride
metadata:
# ...
spec:
  runOnceDurationOverride:
    spec:
      activeDeadlineSeconds: 1800


# ...

Copy to Clipboard

Toggle word wrap

1: activeDeadlineSeconds フィールドを必要な値に設定します (秒単位)。

変更を適用するためにファイルを保存します。

run-once duration override が有効になっている namespace で今後作成される 1 回実行 Pod では、activeDeadlineSeconds フィールドがこの新しい値に設定されます。これらの namespace 内の既存の 1 回実行 Pod は、更新時にこの新しい値を受け取ります。

2.16.4. Run Once Duration Override Operator のアンインストール
リンクのコピー

Operator をアンインストールし、その関連リソースを削除することで、OpenShift Container Platform から Run Once Duration Override Operator を削除できます。

2.16.4.1. Run Once Duration Override Operator のアンインストール
リンクのコピー

Web コンソールを使用して、Run Once Duration Override Operator をアンインストールできます。Run Once Duration Override Operator をアンインストールしても、1 回実行 (run-once) Pod の activeDeadlineSeconds フィールドの設定が解除されませんが、オーバーライド値は今後の 1 回実行 (run-once) Pod に適用されなくなります。

前提条件

cluster-admin 権限でクラスターにアクセスできる。
OpenShift Container Platform Web コンソールにアクセスできる。
Run Once Duration Override Operator をインストールしました。

手順

OpenShift Container Platform Web コンソールにログインします。
Ecosystem → Installed Operators に移動します。
Project ドロップダウンリストから openshift-run-once-duration-override-operator を選択します。
RunOnceDurationOverride インスタンスを削除します。
1. Run Once Duration Override Operator をクリックし、Run Once Duration Override タブを選択します。
2. クラスター エントリーの横にある Options メニューをクリックし、Delete RunOnceDurationOverride を選択します。
3. 確認ダイアログで Delete をクリックします。
Run Once Duration Override Operator をアンインストールします。
1. Ecosystem → Installed Operators に移動します。
2. Run Once Duration Override Operator エントリーの横にある Options メニューをクリックし、Uninstall Operator をクリックします。
3. 確認ダイアログで、Uninstall をクリックします。

2.16.4.2. Run Once Duration Override Operator リソースのアンインストール
リンクのコピー

必要に応じて、Run Once Duration Override Operator をアンインストールした後、その関連リソースをクラスターから削除できます。

前提条件

cluster-admin 権限でクラスターにアクセスできる。
OpenShift Container Platform Web コンソールにアクセスできる。
Run Once Duration Override Operator をアンインストールしている。

手順

OpenShift Container Platform Web コンソールにログインします。
Run Once Duration Override Operator のインストール時に作成された CRD を削除します。
1. Administration → CustomResourceDefinitions に移動します。
2. Name フィールドに RunOnceDurationOverride を入力し、CRD をフィルタリングします。
3. RunOnceDurationOverride CRD の横にある Options メニューをクリックし、Delete CustomResourceDefinition を選択します。
4. 確認ダイアログで Delete をクリックします。
openshift-run-once-duration-override-operator namespace を削除します。
1. Administration → Namespaces に移動します。
2. openshift-run-once-duration-override-operator をフィルターボックスに入力します。
3. openshift-run-once-duration-override-operator エントリーの横にある Options メニューをクリックし、Delete Namespace を選択します。
4. 確認ダイアログで、openshift-run-once-duration-override-operator を入力し、Delete をクリックします。
有効にされた namespace から run-once duration override ラベルを削除します。
1. Administration → Namespaces に移動します。
2. namespace を選択します。
3. Labels フィールドの横にある Edit をクリックします。
4. runoncedurationoverrides.admission.runoncedurationoverride.openshift.io/enabled=true ラベルを削除し、Save をクリックします。

2.17. Linux ユーザー名前空間での Pod の実行
リンクのコピー

Linux ユーザー名前空間を使用すると、管理者はコンテナーのユーザーおよびグループ識別子 (UID および GID) を分離できるため、実行されているホストシステムとは異なる権限セットを、ユーザー名前空間でコンテナーに付与できます。これにより、ユーザー名前空間内で完全な権限を使用してプロセスを実行することをコンテナーに許可する一方で、ホストマシンに対する操作の権限をプロセスに与えないことが可能になります。

デフォルトでは、コンテナーはホストユーザー名前空間で実行されます。コンテナーをホストのユーザー名前空間で実行することは、そのユーザー名前空間でのみ使用可能な機能がコンテナーに必要な場合に便利です。しかし、ホストの名前空間で Pod を実行すると、コンテナーブレイクアウトの可能性など、セキュリティー上の懸念が生じます。コンテナーブレイクアウトが発生すると、別のコンテナー内のプロセスがホスト上に脱出し、そのプロセスがホスト上またはコンテナー内のファイルにアクセスしたり、ファイルを変更したりできるようになります。

個々のユーザー名前空間でコンテナーを実行すると、コンテナーブレイクアウトや、侵害されたコンテナーから他の Pod やノード自体に及ぶ可能性のあるその他のいくつかの脆弱性を軽減できます。

隔離されたユーザー名前空間で Pod を実行すると、Pod コンテナー内の UID/GID がホスト上の UID/GID と一致しなくなります。ファイルシステムの所有権が正しく機能するように、Linux カーネルは ID-mapped マウントを使用します。ID マップマウントは、仮想ファイルシステム (VFS) レイヤーにおいて、コンテナーとホスト間でユーザー ID を変換するものです。

重要

現時点では、ネットワークファイルシステム (NFS) やその他のネットワーク/分散ファイルシステムなど、すべてのファイルシステムが ID-mapped マウントをサポートしているわけではありません。ID-mapped マウントをサポートしていないベンダーが提供する、NFS を基盤とした永続ボリュームを使用している Pod は、ユーザー名前空間で実行される際に、アクセスや権限の問題が発生する可能性があります。この動作は OpenShift Container Platform に固有のものではありません。これは、Kubernetes v1.33 以降のすべての Kubernetes ディストリビューションに適用されます。

2.17.1. Linux ユーザー名前空間のサポートの設定
リンクのコピー

Linux ユーザー名前空間を設定するには、次の手順に示すように、Pod 仕様で hostUsers パラメーターを false に設定し、その他のいくつかの設定を行います。

ユーザー名前空間でワークロードを実行すると、fsGroup、runAsGroup、runAsUser、supplementalGroups などの Security Context Constraints (SCC) フィールドに、RunAsAny を安全に設定できるようになります。これは、コンテナー外部の UID や GID が、これらのフィールドが表すコンテナー内部の UID や GID と異なるためです。

セキュリティーを強化するために、restricted-v3 または nested-container SCC を使用できます。これらは、Linux ユーザー名前空間内のワークロード向けに特別に設計されたものです。SCC に userNamespaceLevel: RequirePodLevel フィールドを設定すると、ワークロードが必ずユーザー名前空間で実行されます。SCC の詳細は、「Security Context Constraints の管理」を参照してください。

ワークロードに対して特定の SCC を必須とするには、oc adm policy add-scc-to-user コマンドまたは oc adm policy add-scc-to-group コマンドを使用して、特定のユーザーまたはグループに SCC を追加できます。詳細は、「OpenShift CLI 管理者コマンドリファレンス」を参照してください。

また、必要に応じて、Pod 仕様の procMount パラメーターを使用して、Pod 内の /proc ファイルシステムを unmasked に設定することもできます。一般的に安全であると考えられている /proc を unmasked に設定すると、コンテナーランタイムのデフォルトのマスキング動作がバイパスされるため、userNamespaceLevel を RequirePodLevel に設定する SCC でのみ使用する必要があります。

前提条件

restricted-v3 または nested-container SCC で設定されたユーザーとして、またはいずれかの SCC で設定されたユーザーグループのユーザーとして、OpenShift Container Platform クラスターにログインします。または、ワークロードオブジェクトで、restricted-v3 または nested-container SCC を直接設定することもできます。

手順

次のコマンドを実行して、Pod がデプロイされている OpenShift Container Platform の namespace のデフォルトユーザー ID (UID) およびグループ ID (GID) の範囲を編集します。
```
oc edit ns/<namespace_name>
```
```
$ oc edit ns/<namespace_name>
```
Copy to Clipboard Toggle word wrap
namespace の例
```
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/description: ""
    openshift.io/display-name: ""
    openshift.io/requester: system:admin
    openshift.io/sa.scc.mcs: s0:c27,c24
    openshift.io/sa.scc.supplemental-groups: 1000/10000
    openshift.io/sa.scc.uid-range: 1000/10000
# ...
  name: userns
# ...
```
```
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/description: ""
    openshift.io/display-name: ""
    openshift.io/requester: system:admin
    openshift.io/sa.scc.mcs: s0:c27,c24
    openshift.io/sa.scc.supplemental-groups: 1000/10000
    openshift.io/sa.scc.uid-range: 1000/10000
# ...
  name: userns
# ...
```
Copy to Clipboard Toggle word wrap
各項目の説明:
metadata.annotations.openshift.io/sa.scc.supplemental-groups
Pod 仕様で必要なデフォルトの GID を指定します。Linux ユーザー名前空間の範囲は 65535 以下である必要があります。デフォルトは 1000000000/10000 です。
metadata.annotations.openshift.io/sa.scc.uid-range
Pod 仕様で必要なデフォルトの UID を指定します。Linux ユーザー名前空間の範囲は 65535 以下である必要があります。デフォルトは 1000000000/10000 です。
注記
範囲 1000/10000 は、ID 1000 から始まる 10,000 個の値を意味するため、1000 から 10,999 までの範囲の ID を指定します。
適切な SCC を使用して動作するように設定したワークロードを作成し、hostUsers パラメーターを false に設定して、Linux ユーザー名前空間の使用を有効にします。
1. 以下のような YAML ファイルを作成します。
  Pod 仕様の例
  apiVersion: v1 kind: Pod metadata: name: userns-pod spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault hostUsers: false containers: name: userns-container image: registry.access.redhat.com/ubi9 command: ["sleep", "1000"] securityContext: runAsUser: 1000 runAsGroup: 1000 runAsNonRoot: true procMount: Unmasked capabilities: add: - "SETGID" - "SETUID" # ...
  
  Copy to Clipboard Toggle word wrap
  各項目の説明:
  spec.hostUsers
  Pod をユーザー名前空間で実行するかどうかを指定します。false の場合、Pod は Pod 用に作成した新しいユーザー名前空間で実行されます。true の場合、Pod はホストのユーザー名前空間で実行されます。デフォルトは true です。
  spec.containers.securityContext.runAsUser
  コンテナー内で実行されるプロセスのユーザー ID を指定します。これは、namespace オブジェクトで設定した範囲内に収まっている必要があります。
  spec.containers.securityContext.runAsGroup
  コンテナー内で実行されるプロセスのグループ ID を指定します。これは、namespace オブジェクトで設定した範囲内に収まっている必要があります。
  spec.containers.securityContext.runAsNonRoot
  コンテナー内のプロセスを 0 以外の UID を持つユーザーで実行することを指定します。
  spec.containers.securityContext.procMount
  コンテナーに使用する proc マウントのタイプを指定します。unmasked 値を設定すると、コンテナーの /proc ファイルシステムが、コンテナーのプロセスによって読み取り/書き込み可能な状態でマウントされます。デフォルトは Default です。この値はオプションです。
  spec.containers.securityContext.capabilities.add
  ユーザー名前空間に設定する Linux 機能を指定します。これにより、完全なルートアクセスを与えることなく特権アクションが許可されます。技術的に言えば、ユーザー名前空間の中でケイパビリティーを設定する方が、ユーザー名前空間の外で設定するよりも安全です。ケイパビリティーのスコープがユーザー名前空間の内部にあることで制限され、一般的に安全であると考えられるためです。しかし、信頼できないワークロードに CAP_SYS_ADMIN などの Pod ケイパビリティーを付与すると、コンテナー化されたプロセスがアクセスできる潜在的なカーネルの攻撃対象領域が広がり、悪用可能な脆弱性が発見されるおそれがあります。したがって、ユーザー名前空間内のケイパビリティーは、Pod セキュリティーアドミッションでは baseline レベルで許可されます。この値はオプションです。
2. 以下のコマンドを実行してオブジェクトを作成します。
  $ oc create -f <file_name>.yaml
  Copy to Clipboard Toggle word wrap

検証

作成した Pod 内のコンテナーで使用されているユーザー ID とグループ ID を確認します。Pod は Linux ユーザー名前空間内にあります。
1. Pod 内のコンテナーでシェルセッションを開始します。
  $ oc rsh -c <container_name> pod/<pod_name>
  Copy to Clipboard Toggle word wrap
  コマンドの例
  $ oc rsh -c userns-container pod/userns-pod
  
  Copy to Clipboard Toggle word wrap
2. コンテナー内で使用されているユーザー ID とグループ ID を表示します。
  sh-5.1$ id
  Copy to Clipboard Toggle word wrap
  出力例
  uid=1000(1000) gid=1000(1000) groups=1000(1000)
  1
  
  Copy to Clipboard Toggle word wrap
  1
  コンテナーの UID とグループは、Pod 仕様で設定したものと同じである必要があります。
3. コンテナーのユーザー名前空間で使用されているユーザー ID を表示します。
  sh-5.1$ lsns -t user
  Copy to Clipboard Toggle word wrap
  出力例
  NS TYPE NPROCS PID USER COMMAND 4026532447 user 3 1 1000 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000
  1
  
  Copy to Clipboard Toggle word wrap
  1
  プロセスの UID は、Pod 仕様で設定したものと同じである必要があります。
4. 次のコマンドを使用して、コンテナーシェルセッションを終了します。
  sh-5.1$ exit
  Copy to Clipboard Toggle word wrap
ノードによって使用されている UID を確認します。ノードは Linux ユーザー名前空間の外部にあります。このユーザー ID がコンテナーで使用されている UID と異なっている必要があります。
1. そのノードのデバッグセッションを開始します。
  $ oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9
  Copy to Clipboard Toggle word wrap
  コマンドの例
  $ oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9
  
  Copy to Clipboard Toggle word wrap
2. /host をデバッグシェル内のルートディレクトリーとして設定します。
  sh-5.1# chroot /host
  Copy to Clipboard Toggle word wrap
3. ノードによって使用されている UID を表示します。
  sh-5.1# lsns -t user
  Copy to Clipboard Toggle word wrap
  コマンドの例
  NS TYPE NPROCS PID USER COMMAND 4026531837 user 233 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 28 4026532447 user 1 4767 2908816384 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000
  1
  
  Copy to Clipboard Toggle word wrap
  1
  UID は、Pod 仕様で設定したものと異なる必要があります。
4. 次のコマンドを使用してデバッグセッションを終了します。
  sh-5.1# exit
  Copy to Clipboard Toggle word wrap
  sh-5.1# exit
  Copy to Clipboard Toggle word wrap
/proc ファイルシステムがコンテナーに unmasked の状態でマウントされていることを確認します。これは、次のコマンドの出力に、読み取り/書き込み権限 (rw) が含まれていることからわかります。
```
oc exec <pod_name> -- mount | grep /proc
```
```
$ oc exec <pod_name> -- mount | grep /proc
```
Copy to Clipboard Toggle word wrap
出力例
```
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
```
```
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
```
Copy to Clipboard Toggle word wrap

第3章 Custom Metrics Autoscaler Operator を使用した Pod の自動スケーリング
リンクのコピー

3.1. リリースノート
リンクのコピー

3.1.1. Custom Metrics Autoscaler Operator リリースノート
リンクのコピー

Red Hat OpenShift の Custom Metrics Autoscaler Operator のリリースノートでは、新機能および拡張機能、非推奨となった機能、および既知の問題を説明しています。

Custom Metrics Autoscaler Operator は、Kubernetes ベースの Event Driven Autoscaler (KEDA) を使用し、OpenShift Container Platform の Horizontal Pod Autoscaler (HPA) の上に構築されます。

注記

Red Hat OpenShift の Custom Metrics Autoscaler Operator のロギングサブシステムは、インストール可能なコンポーネントとして提供され、コアの OpenShift Container Platform とは異なるリリースサイクルを備えています。Red Hat OpenShift Container Platform ライフサイクルポリシーはリリースの互換性を概説しています。

3.1.1.1. サポート対象バージョン
リンクのコピー

以下の表は、各 OpenShift Container Platform バージョンの Custom Metrics Autoscaler Operator バージョンを定義しています。

Expand

バージョン	OpenShift Container Platform バージョン	一般提供
2.17.2-2	4.20	一般提供
2.17.2-2	4.19	一般提供
2.17.2-2	4.18	一般提供
2.17.2-2	4.17	一般提供
2.17.2-2	4.16	一般提供
2.17.2-2	4.15	一般提供
2.17.2-2	4.14	一般提供
2.17.2-2	4.13	一般提供
2.17.2-2	4.12	一般提供

3.1.1.2. Custom Metrics Autoscaler Operator 2.17.2-2 リリースノート
リンクのコピー

発行日: 2025 年 10 月 21 日

この Custom Metrics Autoscaler Operator 2.17.2-2 リリースは、新しいベースイメージと Go コンパイラーを使用して、Custom Metrics Autoscaler Operator のバージョン 2.17.2 を再構築したものです。Custom Metrics Autoscaler Operator のコード変更はありません。Custom Metrics Autoscaler Operator に関しては、次のアドバイザリーが利用可能です。

RHBA-2025:18914

重要

このバージョンの Custom Metrics Autoscaler Operator をインストールする前に、以前にインストールされたテクノロジープレビューバージョンまたはコミュニティーがサポートするバージョンの Kubernetes ベースの Event Driven Autoscaler (KEDA) を削除します。

3.1.2. Custom Metrics Autoscaler Operator の過去リリースに関するリリースノート
リンクのコピー

次のリリースノートは、以前の Custom Metrics Autoscaler Operator バージョンを対象としています。

現在のバージョンは、Custom Metrics Autoscaler Operator リリースノートを参照してください。

3.1.2.1. Custom Metrics Autoscaler Operator 2.17.2 リリースノート
リンクのコピー

発行日: 2025 年 9 月 25 日

Custom Metrics Autoscaler Operator 2.17.2 のこのリリースでは、Common Vulnerabilities and Exposures (CVE) に対処しています。Custom Metrics Autoscaler Operator に関しては、次のアドバイザリーが利用可能です。

RHSA-2025:16124

重要

3.1.2.1.1. 新機能および機能拡張
リンクのコピー

3.1.2.1.1.1. KEDA コントローラーはインストール中に自動的に作成される
リンクのコピー

Custom Metrics Autoscaler Operator をインストールすると、KEDA コントローラーが自動的に作成されるようになりました。以前は、KEDA コントローラーを手動で作成する必要がありました。必要に応じて、自動作成された KEDA コントローラーを編集できます。

3.1.2.1.1.2. Kubernetes ワークロードトリガーのサポート
リンクのコピー

Cluster Metrics Autoscaler Operator は、Kubernetes ワークロードトリガーを使用して、特定のラベルセレクターに一致する Pod の数に基づいて Pod をスケーリングできるようになりました。

3.1.2.1.1.3. バインドされたサービスアカウントトークンのサポート
リンクのコピー

Cluster Metrics Autoscaler Operator は、バインドされたサービスアカウントトークンをサポートするようになりました。これまで、Operator はレガシーサービスアカウントトークンのみをサポートしていましたが、セキュリティー上の理由から、バインドされたサービスアカウントトークンに段階的に移行しています。

3.1.2.1.2. バグ修正
リンクのコピー

以前は、KEDA コントローラーはボリュームマウントをサポートしていませんでした。その結果、Kafka スケーラーで Kerberos を使用できませんでした。この修正により、KEDA コントローラーはボリュームマウントをサポートするようになりました。(OCPBUGS-42559)
以前は、keda-operator デプロイメントオブジェクトログの KEDA バージョンで、Custom Metrics Autoscaler Operator が誤った KEDA バージョンに基づいていることが報告されていました。この修正により、正しい KEDA バージョンがログに報告されるようになりました。(OCPBUGS-58129)

3.1.2.2. Custom Metrics Autoscaler Operator 2.15.1-4 リリースノート
リンクのコピー

発行日: 2025 年 3 月 31 日

Custom Metrics Autoscaler Operator 2.15.1-4 のこのリリースでは、Common Vulnerabilities and Exposures (CVE) に対処しています。Custom Metrics Autoscaler Operator に関しては、次のアドバイザリーが利用可能です。

RHSA-2025:3501

重要

3.1.2.2.1. 新機能および機能拡張
リンクのコピー

3.1.2.2.1.1. CMA マルチアーキテクチャービルド
リンクのコピー

このバージョンの Custom Metrics Autoscaler Operator では、ARM64 OpenShift Container Platform クラスターに Operator をインストールして実行できるようになりました。

3.1.2.3. Custom Metrics Autoscaler Operator 2.14.1-467 リリースノート
リンクのコピー

Custom Metrics Autoscaler Operator 2.14.1-467 のこのリリースでは、OpenShift Container Platform クラスターで Operator を実行するための CVE とバグ修正が提供されています。RHSA-2024:7348 に関する次のアドバイザリーが利用可能です。

重要

3.1.2.3.1. バグ修正
リンクのコピー

以前は、Custom Metrics Autoscaler Operator Pod のルートファイルシステムが書き込み可能でした。これは不要であり、セキュリティー上の問題を引き起こす可能性がありました。この更新により、Pod のルートファイルシステムが読み取り専用になり、潜在的なセキュリティー問題が解決されました。(OCPBUGS-37989)

3.1.2.4. Custom Metrics Autoscaler Operator 2.14.1-454 リリースノート
リンクのコピー

この Custom Metrics Autoscaler Operator 2.14.1-454 リリースでは、OpenShift Container Platform クラスターで Operator を実行するための CVE、新機能、およびバグ修正を使用できます。RHBA-2024:5865 に関する次のアドバイザリーが利用可能です。

重要

3.1.2.4.1. 新機能および機能拡張
リンクのコピー

3.1.2.4.1.1. Custom Metrics Autoscaler Operator による Cron トリガーのサポート
リンクのコピー

Custom Metrics Autoscaler Operator が、Cron トリガーを使用して、時間単位のスケジュールに基づいて Pod をスケーリングできるようになりました。指定した時間枠が開始すると、Custom Metrics Autoscaler Operator が Pod を必要な数にスケーリングします。時間枠が終了すると、Operator は以前のレベルまでスケールダウンします。

詳細は、Cron トリガーについてを参照してください。

3.1.2.4.2. バグ修正
リンクのコピー

以前は、KedaController カスタムリソースの監査設定パラメーターに変更を加えても、keda-metrics-server-audit-policy config map が更新されませんでした。その結果、Custom Metrics Autoscaler の初期デプロイ後に監査設定パラメーターを変更することができませんでした。この修正により、監査設定への変更が config map に適切に反映されるようになり、インストール後いつでも監査設定を変更できるようになりました。(OCPBUGS-32521)

3.1.2.5. Custom Metrics Autoscaler Operator 2.13.1 リリースノート
リンクのコピー

Custom Metrics Autoscaler Operator 2.13.1-421 のこのリリースでは、OpenShift Container Platform クラスターで Operator を実行するための新機能およびバグ修正が提供されています。RHBA-2024:4837 に関する次のアドバイザリーが利用可能です。

重要

3.1.2.5.1. 新機能および機能拡張
リンクのコピー

3.1.2.5.1.1. Custom Metrics Autoscaler Operator によるカスタム証明書のサポート
リンクのコピー

Custom Metrics Autoscaler Operator は、カスタムサービス CA 証明書を使用して、外部 Kafka クラスターや外部 Prometheus サービスなどの TLS 対応メトリクスソースにセキュアに接続できるようになりました。デフォルトでは、Operator は自動生成されたサービス証明書を使用して、クラスター上のサービスにのみ接続します。KedaController オブジェクトには、config map を使用して外部サービスに接続するためのカスタムサーバー CA 証明書を読み込むことができる新しいフィールドがあります。

詳細は、Custom Metrics Autoscaler のカスタム CA 証明書を参照してください。

3.1.2.5.2. バグ修正
リンクのコピー

以前は、custom-metrics-autoscaler および custom-metrics-autoscaler-adapter イメージにタイムゾーン情報がありませんでした。その結果、コントローラーがタイムゾーン情報を見つけられなかったため、cron トリガーを使用した scaled object は機能しなくなりました。この修正により、イメージビルドが更新され、タイムゾーン情報が含まれるようになりました。その結果、cron トリガーを含む scaled object が正常に機能するようになりました。cron トリガーを含む scaled object は、現在、カスタムメトリクスオートスケーラーではサポートされていません。(OCPBUGS-34018)

3.1.2.6. Custom Metrics Autoscaler Operator 2.12.1-394 リリースノート
リンクのコピー

Custom Metrics Autoscaler Operator 2.12.1-394 のこのリリースでは、OpenShift Container Platform クラスターで Operator を実行するためのバグ修正が提供されています。RHSA-2024:2901 に関する次のアドバイザリーが利用可能です。

重要

3.1.2.6.1. バグ修正
リンクのコピー

以前は、protojson.Unmarshal 関数は、特定の形式の無効な JSON をアンマーシャリングするときに無限ループに入りました。この状態は、google.protobuf.Any 値を含むメッセージにアンマーシャリングするとき、または UnmarshalOptions.DiscardUnknown オプションが設定されているときに発生する可能性があります。このリリースではこの問題が修正されています。(OCPBUGS-30305)
以前は、Request.ParseMultipartForm メソッドを使用して明示的に、または Request.FormValue、Request.PostFormValue、Request.FormFile メソッドを使用して暗黙的にマルチパートフォームを解析する場合、解析されたフォームの合計サイズの制限は、消費されるメモリーには適用されませんでした。これによりメモリー不足が発生する可能性があります。この修正により、解析プロセスでは、単一のフォーム行を読み取る際に、フォーム行の最大サイズが正しく制限されるようになりました。(OCPBUGS-30360)
以前は、一致するサブドメイン上または最初のドメインと完全に一致しないドメインへの HTTP リダイレクトに従う場合、HTTP クライアントは Authorization や Cookie などの機密ヘッダーを転送しませんでした。たとえば、example.com から www.example.com へのリダイレクトでは Authorization ヘッダーが転送されますが、www.example.org へのリダイレクトではヘッダーは転送されません。このリリースではこの問題が修正されています。(OCPBUGS-30365)
以前は、不明な公開鍵アルゴリズムを持つ証明書を含む証明書チェーンを検証すると、証明書検証プロセスがパニックに陥っていました。この状況は、Config.ClientAuth パラメーターを VerifyClientCertIfGiven または RequireAndVerifyClientCert 値に設定するすべての暗号化および Transport Layer Security (TLS) クライアントとサーバーに影響しました。デフォルトの動作では、TLS サーバーはクライアント証明書を検証しません。このリリースではこの問題が修正されています。(OCPBUGS-30370)
以前は、MarshalJSON メソッドから返されるエラーにユーザーが制御するデータが含まれている場合、攻撃者はそのデータを使用して HTML テンプレートパッケージのコンテキスト自動エスケープ動作を破ることができた可能性があります。この条件により、後続のアクションによってテンプレートに予期しないコンテンツが注入される可能性があります。このリリースではこの問題が修正されています。(OCPBUGS-30397)
以前は、Go パッケージ net/http および golang.org/x/net/http2 では、HTTP/2 リクエストの CONTINUATION フレームの数に制限がありませんでした。この状態により、CPU が過剰に消費される可能性があります。このリリースではこの問題が修正されています。(OCPBUGS-30894)

3.1.2.7. Custom Metrics Autoscaler Operator 2.12.1-384 リリースノート
リンクのコピー

Custom Metrics Autoscaler Operator 2.12.1-384 のこのリリースでは、OpenShift Container Platform クラスターで Operator を実行するためのバグ修正が提供されています。RHBA-2024:2043 に関する次のアドバイザリーが利用可能です。

重要

このバージョンの Custom Metrics Autoscaler Operator をインストールする前に、以前にインストールされたテクノロジープレビューバージョンまたはコミュニティーがサポートするバージョンの KEDA を削除します。

3.1.2.7.1. バグ修正
リンクのコピー

以前は、custom-metrics-autoscaler および custom-metrics-autoscaler-adapter イメージにタイムゾーン情報がありませんでした。その結果、コントローラーがタイムゾーン情報を見つけられなかったため、cron トリガーを使用した scaled object は機能しなくなりました。この修正により、イメージビルドが更新され、タイムゾーン情報が含まれるようになりました。その結果、cron トリガーを含む scaled object が正常に機能するようになりました。(OCPBUGS-32395)

3.1.2.8. Custom Metrics Autoscaler Operator 2.12.1-376 リリースノート
リンクのコピー

Custom Metrics Autoscaler Operator 2.12.1-376 のこのリリースでは、OpenShift Container Platform クラスターで Operator を実行するためのセキュリティー更新とバグ修正が提供されます。RHSA-2024:1812 に関する次のアドバイザリーが利用可能です。

重要

3.1.2.8.1. バグ修正
リンクのコピー

以前は、存在しない namespace などの無効な値が scaled object メタデータに指定されている場合、基盤となるスケーラークライアントはクライアント記述子を解放または終了できず、低速のメモリーリークが発生していました。この修正により、エラーが発生した場合に基礎となるクライアント記述子が適切に終了され、メモリーのリークが防止されます。(OCPBUGS-30145)
以前は、keda-metrics-apiserver Pod の ServiceMonitor カスタムリソース (CR) が機能していませんでした。これは、CR が http という誤ったメトリクスポート名を参照していたためです。この修正により、ServiceMonitor CR が修正され、metrics の適切なポート名が参照されるようになります。その結果、Service Monitor が正常に機能します。(OCPBUGS-25806)

3.1.2.9. Custom Metrics Autoscaler Operator 2.11.2-322 リリースノート
リンクのコピー

Custom Metrics Autoscaler Operator 2.11.2-322 のこのリリースでは、OpenShift Container Platform クラスターで Operator を実行するためのセキュリティー更新とバグ修正が提供されます。RHSA-2023:6144 に関する次のアドバイザリーが利用可能です。

重要

3.1.2.9.1. バグ修正
リンクのコピー

Custom Metrics Autoscaler Operator バージョン 3.11.2-311 は、Operator デプロイメントで必要なボリュームマウントなしにリリースされたため、Custom Metrics Autoscaler Operator Pod は 15 分ごとに再起動しました。この修正により、必要なボリュームマウントが Operator デプロイメントに追加されました。その結果、Operator は 15 分ごとに再起動しなくなりました。(OCPBUGS-22361)

3.1.2.10. Custom Metrics Autoscaler Operator 2.11.2-311 リリースノート
リンクのコピー

この Custom Metrics Autoscaler Operator 2.11.2-311 リリースでは、OpenShift Container Platform クラスターで Operator を実行するための新機能とバグ修正を使用できます。Custom Metrics Autoscaler Operator 2.11.2-311 のコンポーネントは RHBA-2023:5981 でリリースされました。

重要

3.1.2.10.1. 新機能および機能拡張
リンクのコピー

3.1.2.10.1.1. Red Hat OpenShift Service on AWS と OpenShift Dedicated がサポートされるようになる
リンクのコピー

Custom Metrics Autoscaler Operator 2.11.2-311 は、Red Hat OpenShift Service on AWS および OpenShift Dedicated マネージドクラスターにインストールできます。Custom Metrics Autoscaler Operator の以前のバージョンは、openshift-keda namespace にのみインストールできました。これにより、Operator を Red Hat OpenShift Service on AWS および OpenShift Dedicated クラスターにインストールできませんでした。このバージョンの Custom Metrics Autoscaler では、openshift-operators または keda などの他の namespace へのインストールが可能になり、Red Hat OpenShift Service on AWS および OpenShift Dedicated クラスターへのインストールが可能になります。

3.1.2.10.2. バグ修正
リンクのコピー

以前は、Custom Metrics Autoscaler Operator がインストールおよび設定されているが使用されていない場合、OpenShift CLI では、oc コマンドを入力すると、couldn’t get resource list for external.metrics.k8s.io/v1beta1: Got empty response for: external.metrics.k8s.io/v1beta1 エラーが報告されていました。このメッセージは無害ではありますが、混乱を引き起こす可能性がありました。この修正により、Got empty response for: external.metrics… エラーが不適切に表示されなくなりました。(OCPBUGS-15779)
以前は、設定変更後など、Keda Controller が変更されるたびに、Custom Metrics Autoscaler Operator によって管理されるオブジェクトに対するアノテーションやラベルの変更は、Custom Metrics Autoscaler Operator によって元に戻されました。これにより、オブジェクト内のラベルが継続的に変更されてしまいました。Custom Metrics Autoscaler は、独自のアノテーションを使用してラベルとアノテーションを管理するようになり、アノテーションやラベルが不適切に元に戻されることがなくなりました。(OCPBUGS-15590)

3.1.2.11. Custom Metrics Autoscaler Operator 2.10.1-267 リリースノート
リンクのコピー

この Custom Metrics Autoscaler Operator 2.10.1-267 リリースでは、OpenShift Container Platform クラスターで Operator を実行するための新機能とバグ修正を使用できます。Custom Metrics Autoscaler Operator 2.10.1-267 のコンポーネントは RHBA-2023:4089 でリリースされました。

重要

3.1.2.11.1. バグ修正
リンクのコピー

以前は、custom-metrics-autoscaler イメージと custom-metrics-autoscaler-adapter イメージにはタイムゾーン情報が含まれていませんでした。そのため、コントローラーがタイムゾーン情報を検出できないことが原因で、cron トリガーを使用した scaled object が機能していませんでした。今回の修正により、イメージビルドにタイムゾーン情報が含まれるようになりました。その結果、cron トリガーを含む scaled object が正常に機能するようになりました。(OCPBUGS-15264)
以前のバージョンでは、Custom Metrics Autoscaler Operator は、他の namespace 内のオブジェクトやクラスタースコープのオブジェクトを含む、すべてのマネージドオブジェクトの所有権を取得しようとしていました。このため、Custom Metrics Autoscaler Operator は API サーバーに必要な認証情報を読み取るためのロールバインディングを作成できませんでした。これにより、kube-system namespace でエラーが発生しました。今回の修正により、Custom Metrics Autoscaler Operator は、別の namespace 内のオブジェクトまたはクラスタースコープのオブジェクトへの ownerReference フィールドの追加をスキップします。その結果、ロールバインディングがエラーなしで作成されるようになりました。(OCPBUGS-15038)
以前は、Custom Metrics Autoscaler Operator によって、ownerReferences フィールドが openshift-keda namespace に追加されていました。これによって機能上の問題が発生することはありませんでしたが、このフィールドの存在によりクラスター管理者が混乱する可能性がありました。今回の修正により、Custom Metrics Autoscaler Operator は ownerReference フィールドを openshift-keda namespace に追加しなくなりました。その結果、openshift-keda namespace には余分な ownerReference フィールドが含まれなくなりました。(OCPBUGS-15293)
以前のバージョンでは、Pod ID 以外の認証方法で設定された Prometheus トリガーを使用し、podIdentity パラメーターが none に設定されている場合、トリガーはスケーリングに失敗しました。今回の修正により、OpenShift の Custom Metrics Autoscaler は、Pod ID プロバイダータイプ none を適切に処理できるようになりました。その結果、Pod ID 以外の認証方法で設定され、podIdentity パラメーターが none に設定された Prometheus トリガーが適切にスケーリングされるようになりました。(OCPBUGS-15274)

3.1.2.12. Custom Metrics Autoscaler Operator 2.10.1 リリースノート
リンクのコピー

この Custom Metrics Autoscaler Operator 2.10.1 リリースでは、OpenShift Container Platform クラスターで Operator を実行するための新機能とバグ修正を使用できます。Custom Metrics Autoscaler Operator 2.10.1 のコンポーネントは RHEA-2023:3199 でリリースされました。

重要

3.1.2.12.1. 新機能および機能拡張
リンクのコピー

3.1.2.12.1.1. Custom Metrics Autoscaler Operator の一般提供
リンクのコピー

Custom Metrics Autoscaler Operator バージョン 2.10.1 以降で、Custom Metrics Autoscaler Operator の一般提供が開始されました。

重要

スケーリングされたジョブを使用したスケーリングはテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat テクノロジープレビュー機能のサポート範囲の詳細は、次のリンクを参照してください。

テクノロジープレビュー機能のサポート範囲

3.1.2.12.1.2. パフォーマンスメトリクス
リンクのコピー

Prometheus Query Language (PromQL) を使用して、Custom Metrics Autoscaler Operator でメトリクスのクエリーを行えるようになりました。

3.1.2.12.1.3. スケーリングされたオブジェクトのカスタムメトリクス自動スケーリングの一時停止
リンクのコピー

必要に応じてスケーリングされたオブジェクトの自動スケーリングを一時停止し、準備ができたら再開できるようになりました。

3.1.2.12.1.4. スケーリングされたオブジェクトのレプリカフォールバック
リンクのコピー

スケーリングされたオブジェクトがソースからメトリクスを取得できなかった場合に、フォールバックするレプリカの数を指定できるようになりました。

3.1.2.12.1.5. スケーリングされたオブジェクトのカスタマイズ可能な HPA 命名
リンクのコピー

スケーリングされたオブジェクトで、Horizontal Pod Autoscaler のカスタム名を指定できるようになりました。

3.1.2.12.1.6. アクティブ化およびスケーリングのしきい値
リンクのコピー

Horizontal Pod Autoscaler (HPA) は 0 レプリカへの、または 0 レプリカからのスケーリングができないため、Custom Metrics Autoscaler Operator がそのスケーリングを実行し、その後 HPA がスケーリングを実行します。レプリカの数に基づき HPA が自動スケーリングを引き継ぐタイミングを指定できるようになりました。これにより、スケーリングポリシーの柔軟性が向上します。

3.1.2.13. Custom Metrics Autoscaler Operator 2.8.2-174 リリースノート
リンクのコピー

この Custom Metrics Autoscaler Operator 2.8.2-174 リリースでは、OpenShift Container Platform クラスターで Operator を実行するための新機能とバグ修正を使用できます。Custom Metrics Autoscaler Operator 2.8.2-174 のコンポーネントは RHEA-2023:1683 でリリースされました。

重要

Custom Metrics Autoscaler Operator バージョン 2.8.2-174 は、テクノロジープレビュー機能です。

3.1.2.13.1. 新機能および機能拡張
リンクのコピー

3.1.2.13.1.1. Operator のアップグレードサポート
リンクのコピー

以前の Custom Metrics Autoscaler Operator バージョンからアップグレードできるようになりました。Operator のアップグレードの詳細は、「関連情報」の「Operator の更新チャネルの変更」を参照してください。

3.1.2.13.1.2. must-gather サポート
リンクのコピー

OpenShift Container Platform must-gather ツールを使用して、Custom Metrics Autoscaler Operator およびそのコンポーネントに関するデータを収集できるようになりました。現時点で、Custom Metrics Autoscaler で must-gather ツールを使用するプロセスは、他の Operator とは異なります。詳細は、関連情報の「デバッグデータの収集」を参照してください。

3.1.2.14. Custom Metrics Autoscaler Operator 2.8.2 リリースノート
リンクのコピー

Custom Metrics Autoscaler Operator 2.8.2 のこのリリースは、OpenShift Container Platform クラスターで Operator を実行するための新機能とバグ修正を提供します。Custom Metrics Autoscaler Operator 2.8.2 のコンポーネントは RHSA-2023:1042 でリリースされました。

重要

Custom Metrics Autoscaler Operator バージョン 2.8.2 はテクノロジープレビュー機能です。

3.1.2.14.1. 新機能および機能拡張
リンクのコピー

3.1.2.14.1.1. 監査ロギング
リンクのコピー

Custom Metrics Autoscaler Operator とその関連コンポーネントの監査ログを収集して表示できるようになりました。監査ログは、システムに影響を与えた一連のアクティビティーを個別のユーザー、管理者その他システムのコンポーネント別に記述したセキュリティー関連の時系列のレコードです。

3.1.2.14.1.2. Apache Kafka メトリクスに基づくアプリケーションのスケーリング
リンクのコピー

KEDA Apache kafka トリガー/スケーラーを使用して、Apache Kafka トピックに基づいてデプロイメントをスケーリングできるようになりました。

3.1.2.14.1.3. CPU メトリクスに基づくアプリケーションのスケーリング
リンクのコピー

KEDA CPU トリガー/スケーラーを使用して、CPU メトリクスに基づいてデプロイメントをスケーリングできるようになりました。

3.1.2.14.1.4. メモリーメトリクスに基づくアプリケーションのスケーリング
リンクのコピー

KEDA メモリートリガー/スケーラーを使用して、メモリーメトリクスに基づいてデプロイメントをスケーリングできるようになりました。

3.2. Custom Metrics Autoscaler Operator の概要
リンクのコピー

開発者は、Red Hat OpenShift の Custom Metrics Autoscaler Operator を使用して、OpenShift Container Platform が CPU またはメモリーのみに基づくものではないカスタメトリクスに基づきデプロイメント、ステートフルセット、カスタムリソース、またはジョブの Pod 数を自動的に増減する方法を指定できます。

Custom Metrics Autoscaler Operator は、Kubernetes Event Driven Autoscaler (KEDA) に基づくオプションの Operator であり、Pod メトリクス以外の追加のメトリクスソースを使用してワークロードをスケーリングできます。

カスタムメトリクスオートスケーラーは現在、Prometheus、CPU、メモリー、および Apache Kafka メトリクスのみをサポートしています。

Custom Metrics Autoscaler Operator は、特定のアプリケーションからのカスタムの外部メトリクスに基づいて、Pod をスケールアップおよびスケールダウンします。他のアプリケーションは引き続き他のスケーリング方法を使用します。スケーラーとも呼ばれる トリガー を設定します。これは、カスタムメトリクスオートスケーラーがスケーリング方法を決定するために使用するイベントとメトリクスのソースです。カスタムメトリクスオートスケーラーはメトリクス API を使用して、外部メトリクスを OpenShift Container Platform が使用できる形式に変換します。カスタムメトリクスオートスケーラーは、実際のスケーリングを実行する Horizontal Pod Autoscaler (HPA) を作成します。

カスタムメトリクスオートスケーラーを使用するには、ワークロード用の ScaledObject または ScaledJob オブジェクトを作成します。これらは、スケーリングメタデータを定義するカスタムリソース (CR) です。スケーリングするデプロイメントまたはジョブ、スケーリングするメトリクスのソース (トリガー)、許可される最小および最大レプリカ数などのその他のパラメーターを指定します。

注記

スケーリングするワークロードごとに、スケーリングされたオブジェクトまたはスケーリングされたジョブを 1 つだけ作成できます。また、スケーリングされたオブジェクトまたはスケーリングされたジョブと Horizontal Pod Autoscaler (HPA) を同じワークロードで使用することはできません。

カスタムメトリクスオートスケーラーは、HPA とは異なり、ゼロにスケーリングできます。カスタムメトリクスオートスケーラー CR の minReplicaCount 値を 0 に設定すると、カスタムメトリクスオートスケーラーはワークロードを 1 レプリカから 0 レプリカにスケールダウンするか、0 レプリカから 1 にスケールアップします。これは、アクティベーションフェーズ として知られています。1 つのレプリカにスケールアップした後、HPA はスケーリングを制御します。これは スケーリングフェーズ として知られています。

一部のトリガーにより、クラスターメトリクスオートスケーラーによってスケーリングされるレプリカの数を変更できます。いずれの場合も、アクティベーションフェーズを設定するパラメーターは、activation で始まる同じフレーズを常に使用します。たとえば、threshold パラメーターがスケーリングを設定する場合、activationThreshold はアクティベーションを設定します。アクティベーションフェーズとスケーリングフェーズを設定すると、スケーリングポリシーの柔軟性が向上します。たとえば、アクティベーションフェーズをより高く設定することで、メトリクスが特に低い場合にスケールアップまたはスケールダウンを防ぐことができます。

それぞれ異なる決定を行う場合は、スケーリングの値よりもアクティベーションの値が優先されます。たとえば、threshold が 10 に設定されていて、activationThreshold が 50 である場合にメトリクスが 40 を報告した場合、スケーラーはアクティブにならず、HPA が 4 つのインスタンスを必要とする場合でも Pod はゼロにスケーリングされます。

図3.1 カスタムメトリクスオートスケーラーのワークフロー

クラスター上のワークロード用のスケーリングされたオブジェクトのカスタムリソースを作成または変更します。オブジェクトには、そのワークロードのスケーリング設定を含めます。OpenShift API サーバーは、新しいオブジェクトを受け入れる前に、そのオブジェクトをカスタムメトリクスオートスケーラーのアドミッション Webhook プロセスに送信して、オブジェクトが有効であることを確認します。検証が成功すると、API サーバーはオブジェクトを永続化します。
カスタムメトリクスオートスケーラーコントローラーが、スケーリングされたオブジェクトの更新または変更を監視します。OpenShift API サーバーがコントローラーに変更を通知すると、コントローラーは、オブジェクト内で指定されている外部トリガーソース (データソースとも呼ばれる) を監視して、メトリクスデータの変更を確認します。1 つ以上のスケーラーが外部トリガーソースからのスケーリングデータを要求します。たとえば、Kafka トリガータイプの場合、コントローラーは Kafka スケーラーを使用して Kafka インスタンスと通信し、トリガーによって要求されたデータを取得します。
コントローラーが、スケーリングされたオブジェクトの Horizontal Pod Autoscaler オブジェクトを作成します。その結果、Horizontal Pod Autoscaler (HPA) Operator が、トリガーに関連付けられたスケーリングデータの監視を開始します。HPA は、クラスターの OpenShift API サーバーエンドポイントからスケーリングデータを要求します。
OpenShift API サーバーエンドポイントが、カスタムメトリクスオートスケーラーのメトリクスアダプターによって提供されます。メトリクスアダプターは、カスタムメトリクスの要求を受信すると、コントローラーへの GRPC 接続を使用して、スケーラーから受信した最新のトリガーデータを要求します。
HPA がメトリクスアダプターから受信したデータに基づいてスケーリングを決定し、レプリカを増減することでワークロードをスケールアップまたはスケールダウンします。
運用中に、ワークロードがスケーリングメトリクスに影響を与えることがあります。たとえば、Kafka キュー内の作業を処理するためにワークロードがスケールアップされた場合、ワークロードがすべての作業を処理した後、キューのサイズが減少します。その結果、ワークロードがスケールダウンされます。
メトリクスが minReplicaCount 値で指定された範囲内にある場合、カスタムメトリクスオートスケーラーコントローラーがすべてのスケーリングを無効にして、レプリカ数を一定に維持します。メトリクスがその範囲を超える場合、カスタムメトリクスオートスケーラーコントローラーはスケーリングを有効にして、HPA がワークロードをスケーリングできるようにします。スケーリングが無効になっている間、HPA は何もアクションを実行しません。

3.2.1. Custom Metrics Autoscaler 用のカスタム CA 証明書
リンクのコピー

デフォルトでは、Custom Metrics Autoscaler Operator は、自動的に生成されたサービス CA 証明書を使用して、クラスター上のサービスに接続します。

カスタム CA 証明書を必要とするクラスター外のサービスを使用する場合は、必要な証明書を config map に追加できます。次に、カスタムメトリクスオートスケーラーのインストールの説明に従って、KedaController カスタムリソースに config map を追加します。Operator は起動時にこれらの証明書を読み込み、Operator によって信頼されたものとして登録します。

config map には、1 つ以上の PEM エンコードされた CA 証明書を含む 1 つ以上の証明書ファイルを含めることができます。または、証明書ファイルごとに個別の config map を使用することもできます。

注記

後で config map を更新して追加の証明書を追加する場合は、変更を有効にするために keda-operator-* Pod を再起動する必要があります。

3.3. カスタムメトリクスオートスケーラーのインストール
リンクのコピー

OpenShift Container Platform Web コンソールを使用して Custom Metrics Autoscaler Operator をインストールすることができます。

インストールにより、以下の 5 つの CRD が作成されます。

ClusterTriggerAuthentication
KedaController
ScaledJob
ScaledObject
TriggerAuthentication

インストールプロセスでは、KedaController カスタムリソース (CR) も作成されます。必要に応じて、デフォルトの KedaController CR を変更できます。詳細は、「Keda Controller CR の編集」を参照してください。

注記

2.17.2 より前のバージョンの Custom Metrics Autoscaler Operator をインストールする場合は、Keda Controller CR を手動で作成する必要があります。CR を作成するには、「Keda Controller CR の編集」で説明されている手順を使用できます。

3.3.1. カスタムメトリクスオートスケーラーのインストール
リンクのコピー

次の手順を使用して、Custom Metrics Autoscaler Operator をインストールできます。

前提条件

これまでにインストールしたテクノロジープレビューバージョンの Cluster Metrics Autoscaler Operator を削除する。
コミュニティーベースの KEDA バージョンをすべて削除する。
次のコマンドを実行して、KEDA 1.x カスタムリソース定義を削除する。
```
oc delete crd scaledobjects.keda.k8s.io
```
```
$ oc delete crd scaledobjects.keda.k8s.io
```
Copy to Clipboard Toggle word wrap
```
oc delete crd triggerauthentications.keda.k8s.io
```
```
$ oc delete crd triggerauthentications.keda.k8s.io
```
Copy to Clipboard Toggle word wrap
オプション: Custom Metrics Autoscaler Operator を外部 Kafka クラスターや外部 Prometheus サービスなどのクラスター外のサービスに接続する必要がある場合は、必要なサービス CA 証明書を config map に配置します。config map は、Operator がインストールされているのと同じ namespace に存在する必要があります。以下に例を示します。
```
oc create configmap -n openshift-keda thanos-cert  --from-file=ca-cert.pem
```
```
$ oc create configmap -n openshift-keda thanos-cert  --from-file=ca-cert.pem
```
Copy to Clipboard Toggle word wrap

手順

OpenShift Container Platform Web コンソールで、Ecosystem → Software Catalog をクリックします。
使用可能な Operator のリストから Custom Metrics Autoscaler を選択し、Install をクリックします。
Install Operator ページで、Installation Mode に All namespaces on the cluster (default) オプションが選択されていることを確認します。これにより、Operator がすべての namespace にインストールされます。
Installed Namespace に openshift-keda namespace が選択されていることを確認します。クラスターに存在しない場合、OpenShift Container Platform は namespace を作成します。
Install をクリックします。
Custom Metrics Autoscaler Operator コンポーネントをリスト表示して、インストールを確認します。
1. Workloads → Pods に移動します。
2. ドロップダウンメニューから openshift-keda プロジェクトを選択し、custom-metrics-autoscaler-operator-* Pod が実行されていることを確認します。
3. Workloads → Deployments に移動して、custom-metrics-autoscaler-operator デプロイメントが実行されていることを確認します。

オプション: 次のコマンドを使用して、OpenShift CLI でインストールを確認します。

oc get all -n openshift-keda

$ oc get all -n openshift-keda

Copy to Clipboard

Toggle word wrap

以下のような出力が表示されます。

出力例

NAME                                                      READY   STATUS    RESTARTS   AGE
pod/custom-metrics-autoscaler-operator-5fd8d9ffd8-xt4xp   1/1     Running   0          18m

NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/custom-metrics-autoscaler-operator   1/1     1            1           18m

NAME                                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/custom-metrics-autoscaler-operator-5fd8d9ffd8   1         1         1       18m

NAME                                                      READY   STATUS    RESTARTS   AGE
pod/custom-metrics-autoscaler-operator-5fd8d9ffd8-xt4xp   1/1     Running   0          18m

NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/custom-metrics-autoscaler-operator   1/1     1            1           18m

NAME                                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/custom-metrics-autoscaler-operator-5fd8d9ffd8   1         1         1       18m

Copy to Clipboard

Toggle word wrap

3.3.2. Keda Controller CR の編集
リンクのコピー

Custom Metrics Autoscaler Operator のインストール中に自動的にインストールされる KedaController カスタムリソース (CR) を変更するには、次の手順に従います。

手順

OpenShift Container Platform Web コンソールで、Ecosystem → Installed Operator をクリックします。
Custom Metrics Autoscaler をクリックします。
Operator Details ページで、KedaController タブをクリックします。

KedaController タブで、Create KedaController をクリックしてファイルを編集します。

kind: KedaController
apiVersion: keda.sh/v1alpha1
metadata:
  name: keda
  namespace: openshift-keda
spec:
  watchNamespace: '' 
  operator:
    logLevel: info 
    logEncoder: console 
    caConfigMaps: 
    - thanos-cert
    - kafka-cert
    volumeMounts: 
    - mountPath: /<path_to_directory>
      name: <name>
    volumes: 
    - name: <volume_name>
      emptyDir:
        medium: Memory
  metricsServer:
    logLevel: '0' 
    auditConfig: 
      logFormat: "json"
      logOutputVolumeClaim: "persistentVolumeClaimName"
      policy:
        rules:
        - level: Metadata
        omitStages: ["RequestReceived"]
        omitManagedFields: false
      lifetime:
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
  serviceAccount: {}

kind: KedaController
apiVersion: keda.sh/v1alpha1
metadata:
  name: keda
  namespace: openshift-keda
spec:
  watchNamespace: ''


  operator:
    logLevel: info


    logEncoder: console


    caConfigMaps:


    - thanos-cert
    - kafka-cert
    volumeMounts:


    - mountPath: /<path_to_directory>
      name: <name>
    volumes:


    - name: <volume_name>
      emptyDir:
        medium: Memory
  metricsServer:
    logLevel: '0'


    auditConfig:


      logFormat: "json"
      logOutputVolumeClaim: "persistentVolumeClaimName"
      policy:
        rules:
        - level: Metadata
        omitStages: ["RequestReceived"]
        omitManagedFields: false
      lifetime:
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
  serviceAccount: {}

Copy to Clipboard

Toggle word wrap

1: Custom Metrics Autoscaler Operator がアプリケーションをスケーリングする単一の namespace を指定します。空白のままにするか、または空にして、すべての namespace でアプリケーションをスケーリングします。このフィールドは、namespace があるか、空である必要があります。デフォルト値は空です。
2: Custom Metrics Autoscaler Operator ログメッセージの詳細レベルを指定します。許可される値は debug、info、error です。デフォルトは info です。
3: Custom Metrics Autoscaler Operator ログメッセージのログ形式を指定します。許可される値は console または json です。デフォルトは console です。
4: オプション: CA 証明書を持つ 1 つ以上の config map を指定します。Custom Metrics Autoscaler Operator はこれを使用して、TLS 対応のメトリクスソースにセキュアに接続できます。
5: オプション: コンテナーのマウントパスを追加します。
6: オプション: volumes ブロックを追加し、各 projected ボリュームのソースをリストします。
7: Custom Metrics Autoscaler Metrics Server のログレベルを指定します。使用可能な値は、info の場合は 0、debug の場合は 4 です。デフォルトは 0 です。
8: Custom Metrics Autoscaler Operator の監査ログをアクティブにして、使用する監査ポリシーを指定します (「監査ログの設定」セクションを参照)。

Save をクリックして、変更を保存します。

3.4. カスタムメトリクスオートスケーラートリガーについて
リンクのコピー

スケーラーとも呼ばれるトリガーは、Custom Metrics Autoscaler Operator が Pod をスケーリングするために使用するメトリクスを提供します。

カスタムメトリクスオートスケーラーは現在、Prometheus、CPU、メモリー、Apache Kafka、cron トリガーをサポートしています。

以下のセクションで説明するように、ScaledObject または ScaledJob カスタムリソースを使用して、特定のオブジェクトのトリガーを設定します。

scaled object で使用する認証局、またはクラスター内のすべてのスケーラー用の認証局を設定できます。

3.4.1. Prometheus トリガーについて
リンクのコピー

Prometheus メトリクスに基づいて Pod をスケーリングできます。このメトリクスは、インストール済みの OpenShift Container Platform モニタリングまたは外部 Prometheus サーバーをメトリクスソースとして使用できます。OpenShift Container Platform モニタリングをメトリクスのソースとして使用するために必要な設定は、「OpenShift Container Platform モニタリングを使用するためのカスタムメトリクスオートスケーラーの設定」を参照してください。

注記

カスタムメトリクスオートスケーラーがスケーリングしているアプリケーションから Prometheus がメトリクスを収集している場合は、カスタムリソースで最小レプリカ数を 0 に設定しないでください。アプリケーション Pod がないと、カスタムメトリクスオートスケーラーにスケーリングの基準となるメトリクスが提供されません。

Prometheus ターゲットを使用した scaled object の例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prom-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: prometheus 
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 
      namespace: kedatest 
      metricName: http_requests_total 
      threshold: '5' 
      query: sum(rate(http_requests_total{job="test-app"}[1m])) 
      authModes: basic 
      cortexOrgID: my-org 
      ignoreNullValues: "false" 
      unsafeSsl: "false" 
      timeout: 1000

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prom-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: prometheus


    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092


      namespace: kedatest


      metricName: http_requests_total


      threshold: '5'


      query: sum(rate(http_requests_total{job="test-app"}[1m]))


      authModes: basic


      cortexOrgID: my-org


      ignoreNullValues: "false"


      unsafeSsl: "false"


      timeout: 1000

Copy to Clipboard

Toggle word wrap

Prometheus をトリガータイプとして指定します。

Prometheus サーバーのアドレスを指定します。この例では、OpenShift Container Platform モニタリングを使用します。

オプション: スケーリングするオブジェクトの namespace を指定します。メトリクスのソースとして OpenShift Container Platform モニタリングを使用する場合、このパラメーターは必須です。

external.metrics.k8s.io API でメトリクスを識別する名前を指定します。複数のトリガーを使用している場合、すべてのメトリクス名が一意である必要があります。

5

スケーリングをトリガーする値を指定します。引用符で囲まれた文字列値として指定する必要があります。

6

使用する Prometheus クエリーを指定します。

7

使用する認証方法を指定します。Prometheus スケーラーは、ベアラー認証 (bearer)、Basic 認証 (basic)、または TLS 認証 (tls) をサポートしています。以下のセクションで説明するように、トリガー認証で特定の認証パラメーターを設定します。必要に応じて、シークレットを使用することもできます。

8

オプション: X-Scope-OrgID ヘッダーを Prometheus のマルチテナント Cortex または Mimir ストレージに渡します。このパラメーターは、Prometheus が返す必要のあるデータを示すために、マルチテナント Prometheus ストレージでのみ必要です。

9

オプション: Prometheus ターゲットが失われた場合のトリガーの処理方法を指定します。

true の場合、Prometheus ターゲットが失われても、トリガーは動作し続けます。これがデフォルトの動作です。
false の場合、Prometheus ターゲットが失われると、トリガーはエラーを返します。

10

オプション: 証明書チェックをスキップするかどうかを指定します。たとえば、テスト環境で実行しており、Prometheus エンドポイントで自己署名証明書を使用している場合は、チェックをスキップできます。

false の場合、証明書のチェックが実行されます。これがデフォルトの動作です。
true の場合、証明書のチェックは実行されません。
重要
チェックのスキップは推奨されません。

11

オプション: この Prometheus トリガーで使用される HTTP クライアントの HTTP 要求タイムアウトをミリ秒単位で指定します。この値は、グローバルタイムアウト設定をオーバーライドします。

3.4.1.1. Prometheus と DCGM メトリクスを使用した GPU ベースの自動スケーリングの設定
リンクのコピー

カスタムメトリクスオートスケーラーを NVIDIA データセンター GPU マネージャー (DCGM) メトリクスとともに使用すると、GPU 使用率に基づいてワークロードをスケーリングできます。これは、GPU リソースを必要とする AI および機械学習のワークロードに特に役立ちます。

GPU ベースの自動スケーリングのために Prometheus ターゲットを使用する scaled object の例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: gpu-scaledobject
  namespace: my-namespace
spec:
  scaleTargetRef:
    kind: Deployment
    name: gpu-deployment
  minReplicaCount: 1 
  maxReplicaCount: 5 
  triggers:
  - type: prometheus
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: my-namespace
      metricName: gpu_utilization
      threshold: '90' 
      query: SUM(DCGM_FI_DEV_GPU_UTIL{instance=~".+", gpu=~".+"}) 
      authModes: bearer
    authenticationRef:
      name: keda-trigger-auth-prometheus

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: gpu-scaledobject
  namespace: my-namespace
spec:
  scaleTargetRef:
    kind: Deployment
    name: gpu-deployment
  minReplicaCount: 1


  maxReplicaCount: 5


  triggers:
  - type: prometheus
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: my-namespace
      metricName: gpu_utilization
      threshold: '90'


      query: SUM(DCGM_FI_DEV_GPU_UTIL{instance=~".+", gpu=~".+"})


      authModes: bearer
    authenticationRef:
      name: keda-trigger-auth-prometheus

Copy to Clipboard

Toggle word wrap

1: 維持するレプリカの最小数を指定します。GPU ワークロードの場合は、メトリクスが継続的に収集されるように、これを 0 に設定しないください。
2: スケールアップ操作中に許可するレプリカの最大数を指定します。
3: スケーリングをトリガーする GPU 使用率のしきい値をパーセンテージで指定します。GPU の平均使用率が 90% を超えると、オートスケーラーがデプロイメントをスケールアップします。
4: すべての GPU デバイスの GPU 使用率を監視するために、NVIDIA DCGM メトリクスを使用して Prometheus クエリーを指定します。DCGM_FI_DEV_GPU_UTIL メトリクスは、GPU 使用率を提供します。

3.4.1.2. OpenShift Container Platform モニタリングを使用するためのカスタムメトリクスオートスケーラーの設定
リンクのコピー

カスタムメトリクスオートスケーラーが使用するメトリクスのソースとして、インストール済みの OpenShift Container Platform Prometheus モニタリングを使用できます。ただし、実行する必要がある追加の設定がいくつかあります。

scaled object が OpenShift Container Platform Prometheus メトリクスを読み取れるように、トリガー認証またはクラスタートリガー認証を使用して、必要な認証情報を提供する必要があります。以下の手順は、使用するトリガー認証方式によって異なります。トリガー認証の詳細は、「カスタムメトリクスオートスケーラーのトリガー認証について」を参照してください。

注記

これらの手順は、外部 Prometheus ソースには必要ありません。

このセクションで説明するように、次のタスクを実行する必要があります。

サービスアカウントを作成します。
トリガー認証を作成します。
ロールを作成します。
そのロールをサービスアカウントに追加します。
Prometheus が使用するトリガー認証オブジェクトでトークンを参照します。

前提条件

OpenShift Container Platform モニタリングをインストールしている必要がある。
ユーザー定義のワークロードのモニタリングを、OpenShift Container Platform モニタリングで有効にする必要がある (ユーザー定義のワークロードモニタリング設定マップの作成 セクションで説明)。
Custom Metrics Autoscaler Operator をインストールしている。

手順

適切なプロジェクトに切り替えます。
```
oc project <project_name>
```
```
$ oc project <project_name> 
```
1
Copy to Clipboard Toggle word wrap
1
次のプロジェクトのいずれかを指定します。
トリガー認証を使用している場合は、スケーリングするオブジェクトを含むプロジェクトを指定します。
クラスタートリガー認証を使用している場合は、openshift-keda プロジェクトを指定します。
クラスターにサービスアカウントがない場合は作成します。
1. 次のコマンドを使用して、service account オブジェクトを作成します。
  $ oc create serviceaccount thanos
  1
  Copy to Clipboard Toggle word wrap
  1
  サービスアカウントの名前を指定します。
サービスアカウントトークンを使用してトリガー認証を作成します。
1. 以下のような YAML ファイルを作成します。
  apiVersion: keda.sh/v1alpha1 kind: <authentication_method>
  1
  metadata: name: keda-trigger-auth-prometheus spec: boundServiceAccountToken:
  2
  - parameter: bearerToken
  3
  serviceAccountName: thanos
  4
  Copy to Clipboard Toggle word wrap
  1
  次のいずれかのトリガー認証方法を指定します。
  トリガー認証を使用している場合は、TriggerAuthentication を指定します。この例では、トリガー認証を設定します。
  クラスタートリガー認証を使用している場合は、ClusterTriggerAuthentication を指定します。
  2
  このトリガー認証では、メトリクスエンドポイントに接続するときに、バインドされたサービスアカウントトークンを使用して認可を行うことを指定します。
  3
  トークンを使用して提供する認証パラメーターを指定します。この例では、ベアラー認証を使用します。
  4
  使用するサービスアカウントの名前を指定します。
2. CR オブジェクトを作成します。
  $ oc create -f <file-name>.yaml
  Copy to Clipboard Toggle word wrap

Thanos メトリクスを読み取るためのロールを作成します。

次のパラメーターを使用して YAML ファイルを作成します。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: thanos-metrics-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: thanos-metrics-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch

Copy to Clipboard

Toggle word wrap

CR オブジェクトを作成します。
```
oc create -f <file-name>.yaml
```
```
$ oc create -f <file-name>.yaml
```
Copy to Clipboard Toggle word wrap

Thanos メトリクスを読み取るためのロールバインディングを作成します。
1. 以下のような YAML ファイルを作成します。
  apiVersion: rbac.authorization.k8s.io/v1 kind: <binding_type>
  1
  metadata: name: thanos-metrics-reader
  2
  namespace: my-project
  3
  roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: thanos-metrics-reader subjects: - kind: ServiceAccount name: thanos
  4
  namespace: <namespace_name>
  5
  Copy to Clipboard Toggle word wrap
  1
  次のオブジェクト型のいずれかを指定します。
  トリガー認証を使用している場合は、RoleBinding を指定します。
  クラスタートリガー認証を使用している場合は、ClusterRoleBinding を指定します。
  2
  作成したロールの名前を指定します。
  3
  次のプロジェクトのいずれかを指定します。
  トリガー認証を使用している場合は、スケーリングするオブジェクトを含むプロジェクトを指定します。
  クラスタートリガー認証を使用している場合は、openshift-keda プロジェクトを指定します。
  4
  ロールにバインドするサービスアカウントの名前を指定します。
  5
  サービスアカウントを先に作成したプロジェクトを指定します。
2. CR オブジェクトを作成します。
  $ oc create -f <file-name>.yaml
  Copy to Clipboard Toggle word wrap

「カスタムメトリクスオートスケーラーの追加方法について」で説明されているとおり、スケーリングされたオブジェクトまたはスケーリングされたジョブをデプロイして、アプリケーションの自動スケーリングを有効化できます。OpenShift Container Platform モニタリングをソースとして使用するには、トリガーまたはスケーラーに以下のパラメーターを含める必要があります。

triggers.type は prometheus にしてください。
triggers.metadata.serverAddress は https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 にしてください。
triggers.metadata.authModes は bearer にしてください。
triggers.metadata.namespace は、スケーリングするオブジェクトの namespace に設定してください。
triggers.authenticationRef は、直前の手順で指定されたトリガー認証リソースを指す必要があります。

3.4.2. CPU トリガーについて
リンクのコピー

CPU メトリクスに基づいて Pod をスケーリングできます。このトリガーは、クラスターメトリクスをメトリクスのソースとして使用します。

カスタムメトリクスオートスケーラーは、オブジェクトに関連付けられた Pod をスケーリングして、指定された CPU 使用率を維持します。オートスケーラーは、すべての Pod で指定された CPU 使用率を維持するために、最小数と最大数の間でレプリカ数を増減します。メモリートリガーは、Pod 全体のメモリー使用率を考慮します。Pod に複数のコンテナーがある場合、メモリートリガーは Pod 内にあるすべてのコンテナーの合計メモリー使用率を考慮します。

注記

このトリガーは、ScaledJob カスタムリソースでは使用できません。
メモリートリガーを使用してオブジェクトをスケーリングすると、複数のトリガーを使用している場合でも、オブジェクトは 0 にスケーリングされません。

CPU ターゲットを使用した scaled object の例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: cpu 
    metricType: Utilization 
    metadata:
      value: '60' 
  minReplicaCount: 1

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: cpu


    metricType: Utilization


    metadata:
      value: '60'


  minReplicaCount: 1

Copy to Clipboard

Toggle word wrap

トリガータイプとして CPU を指定します。

使用するメトリクスのタイプ (Utilization または AverageValue のいずれか) を指定します。

スケーリングをトリガーする値を指定します。引用符で囲まれた文字列値として指定する必要があります。

Utilization を使用する場合、ターゲット値は、関連する全 Pod のリソースメトリクスの平均値であり、Pod のリソースの要求値に占めるパーセンテージとして表されます。
AverageValue を使用する場合、ターゲット値は、関連する全 Pod のメトリクスの平均値です。

スケールダウン時のレプリカの最小数を指定します。CPU トリガーの場合は、1 以上の値を入力します。CPU メトリクスのみを使用している場合、HPA はゼロにスケールできないためです。

3.4.3. メモリートリガーについて
リンクのコピー

メモリーメトリクスに基づいて Pod をスケーリングできます。このトリガーは、クラスターメトリクスをメトリクスのソースとして使用します。

カスタムメトリクスオートスケーラーは、オブジェクトに関連付けられた Pod をスケーリングして、指定されたメモリー使用率を維持します。オートスケーラーは、すべての Pod で指定のメモリー使用率を維持するために、最小数と最大数の間でレプリカ数を増減します。メモリートリガーは、Pod 全体のメモリー使用率を考慮します。Pod に複数のコンテナーがある場合、メモリー使用率はすべてのコンテナーの合計になります。

注記

このトリガーは、ScaledJob カスタムリソースでは使用できません。
メモリートリガーを使用してオブジェクトをスケーリングすると、複数のトリガーを使用している場合でも、オブジェクトは 0 にスケーリングされません。

メモリーターゲットを使用した scaled object の例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: memory-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: memory 
    metricType: Utilization 
    metadata:
      value: '60' 
      containerName: api

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: memory-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: memory


    metricType: Utilization


    metadata:
      value: '60'


      containerName: api

Copy to Clipboard

Toggle word wrap

トリガータイプとしてメモリーを指定します。

使用するメトリクスのタイプ (Utilization または AverageValue のいずれか) を指定します。

スケーリングをトリガーする値を指定します。引用符で囲まれた文字列値として指定する必要があります。

Utilization を使用する場合、ターゲット値は、関連する全 Pod のリソースメトリクスの平均値であり、Pod のリソースの要求値に占めるパーセンテージとして表されます。
AverageValue を使用する場合、ターゲット値は、関連する全 Pod のメトリクスの平均値です。

オプション: Pod 全体ではなく、そのコンテナーのみのメモリー使用率に基づいて、スケーリングする個々のコンテナーを指定します。この例では、api という名前のコンテナーのみがスケーリングされます。

3.4.4. Kafka トリガーについて
リンクのコピー

Apache Kafka トピックまたは Kafka プロトコルをサポートするその他のサービスに基づいて Pod をスケーリングできます。カスタムメトリクスオートスケーラーは、スケーリングされるオブジェクトまたはスケーリングされるジョブで allowIdleConsumers パラメーターを true に設定しない限り、Kafka パーティションの数を超えてスケーリングしません。

注記

コンシューマーグループの数がトピック内のパーティションの数を超えると、余分なコンシューマーグループはそのままアイドル状態になります。これを回避するために、デフォルトではレプリカの数は次の値を超えません。

トピックのパーティションの数 (トピックが指定されている場合)。
コンシューマーグループ内の全トピックのパーティション数 (トピックが指定されていない場合)。
スケーリングされるオブジェクトまたはスケーリングされるジョブの CR で指定された maxReplicaCount。

これらのデフォルトの動作は、allowIdleConsumers パラメーターを使用して無効にすることができます。

Kafka ターゲットを使用した scaled object の例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: kafka 
    metadata:
      topic: my-topic 
      bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092 
      consumerGroup: my-group 
      lagThreshold: '10' 
      activationLagThreshold: '5' 
      offsetResetPolicy: latest 
      allowIdleConsumers: true 
      scaleToZeroOnInvalidOffset: false 
      excludePersistentLag: false 
      version: '1.0.0' 
      partitionLimitation: '1,2,10-20,31' 
      tls: enable

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: kafka


    metadata:
      topic: my-topic


      bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092


      consumerGroup: my-group


      lagThreshold: '10'


      activationLagThreshold: '5'


      offsetResetPolicy: latest


      allowIdleConsumers: true


      scaleToZeroOnInvalidOffset: false


      excludePersistentLag: false


      version: '1.0.0'


      partitionLimitation: '1,2,10-20,31'


      tls: enable

Copy to Clipboard

Toggle word wrap

トリガータイプとして Kafka を指定します。

Kafka がオフセットラグを処理している Kafka トピックの名前を指定します。

接続する Kafka ブローカーのコンマ区切りリストを指定します。

トピックのオフセットの確認と、関連するラグの処理に使用される Kafka コンシューマーグループの名前を指定します。

5

オプション: スケーリングをトリガーする平均ターゲット値を指定します。引用符で囲まれた文字列値として指定する必要があります。デフォルトは 5 です。

6

オプション: アクティベーションフェーズのターゲット値を指定します。引用符で囲まれた文字列値として指定する必要があります。

7

オプション: Kafka コンシューマーの Kafka オフセットリセットポリシーを指定します。使用可能な値は latest および earliest です。デフォルトは latest です。

8

オプション: Kafka レプリカの数がトピックのパーティションの数を超えることを許可するかどうかを指定します。

true の場合、Kafka レプリカの数はトピックのパーティションの数を超えることができます。これにより、Kafka コンシューマーがアイドル状態になることが許容されます。
false の場合、Kafka レプリカの数はトピックのパーティションの数を超えることはできません。これがデフォルトです。

9

Kafka パーティションに有効なオフセットがない場合のトリガーの動作を指定します。

true の場合、そのパーティションのコンシューマーはゼロにスケーリングされます。
false の場合、スケーラーはそのパーティションのために 1 つのコンシューマーを保持します。これがデフォルトです。

10

オプション: 現在のオフセットが前のポーリングサイクルの現在のオフセットと同じであるパーティションのパーティションラグをトリガーに含めるか除外するかを指定します。

true の場合、スケーラーはこれらのパーティションのパーティションラグを除外します。
false の場合、すべてのパーティションのコンシューマーラグがすべてトリガーに含まれます。これがデフォルトです。

11

オプション: Kafka ブローカーのバージョンを指定します。引用符で囲まれた文字列値として指定する必要があります。デフォルトは 1.0.0 です。

12

オプション: スケーリングのスコープを適用するパーティション ID のコンマ区切りリストを指定します。指定されている場合、ラグの計算時にリスト内の ID のみが考慮されます。引用符で囲まれた文字列値として指定する必要があります。デフォルトでは、すべてのパーティションが考慮されます。

13

オプション: Kafka に TSL クライアント認証を使用するかどうかを指定します。デフォルトは disable です。TLS の設定の詳細は、「カスタムメトリクスオートスケーラートリガー認証について」を参照してください。

3.4.5. Cron トリガーについて
リンクのコピー

Pod は時間範囲に基づいてスケーリングできます。

時間範囲の開始時に、カスタムメトリクスオートスケーラーが、オブジェクトに関連する Pod を、設定された最小 Pod 数から指定された必要な Pod 数にスケーリングします。時間範囲の終了時に、Pod は設定された最小値にスケールダウンされます。期間は cron 形式で設定する必要があります。

次の例では、この scaled object に関連する Pod を、インド標準時の午前 6 時から午後 6 時 30 分まで 0 から 100 にスケーリングします。

Cron トリガーを使用した scaled object の例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: my-deployment
  minReplicaCount: 0 
  maxReplicaCount: 100 
  cooldownPeriod: 300
  triggers:
  - type: cron 
    metadata:
      timezone: Asia/Kolkata 
      start: "0 6 * * *" 
      end: "30 18 * * *" 
      desiredReplicas: "100"

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: my-deployment
  minReplicaCount: 0


  maxReplicaCount: 100


  cooldownPeriod: 300
  triggers:
  - type: cron


    metadata:
      timezone: Asia/Kolkata


      start: "0 6 * * *"


      end: "30 18 * * *"


      desiredReplicas: "100"

Copy to Clipboard

Toggle word wrap

1: 時間枠の終了時にスケールダウンする Pod の最小数を指定します。
2: スケールアップ時のレプリカの最大数を指定します。この値は desiredReplicas と同じである必要があります。デフォルトは 100 です。
3: Cron トリガーを指定します。
4: 時間枠のタイムゾーンを指定します。この値は、IANA Time Zone Database から取得する必要があります。
5: 時間枠の始点を指定します。
6: 時間枠の終点を指定します。
7: 時間枠の始点から終点までの間にスケーリングする Pod の数を指定します。この値は maxReplicaCount と同じである必要があります。

3.4.6. Kubernetes ワークロードトリガーを理解する
リンクのコピー

特定のラベルセレクターに一致する Pod の数に基づいて Pod をスケーリングできます。

Custom Metrics Autoscaler Operator は、同じ namespace にある特定のラベルが付いた Pod の数を追跡し、ラベル付き Pod の数に基づいて scaled object の Pod との関係を計算します。この関係を使用して、Custom Metrics Autoscaler Operator は、ScaledObject または ScaledJob 仕様のスケーリングポリシーに従ってオブジェクトをスケーリングします。

Pod 数には、Succeeded フェーズまたは Failed フェーズの Pod が含まれます。

たとえば、frontend デプロイメントと backend デプロイメントがあるとします。kubernetes-workload トリガーを使用すると、frontend Pod の数に基づいて backend デプロイメントをスケーリングできます。frontend Pod の数が増えると、Operator は指定された比率を維持するために backend Pod をスケーリングします。この例では、app=frontend Pod セレクターを持つ Pod が 10 個ある場合、Operator は、scaled object で設定された 0.5 の比率を維持するために、バックエンド Pod を 5 にスケーリングします。

Kubernetes ワークロードトリガーを使用した scaled object の例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: workload-scaledobject
  namespace: my-namespace
spec:
  triggers:
  - type: kubernetes-workload 
    metadata:
      podSelector: 'app=frontend' 
      value: '0.5' 
      activationValue: '3.1'

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: workload-scaledobject
  namespace: my-namespace
spec:
  triggers:
  - type: kubernetes-workload


    metadata:
      podSelector: 'app=frontend'


      value: '0.5'


      activationValue: '3.1'

Copy to Clipboard

Toggle word wrap

Kubernetes ワークロードトリガーを指定します。

Pod 数を取得するために使用する 1 つ以上の Pod セレクターやセットベースセレクターをコンマで区切って指定します。

スケーリングされたワークロードとセレクターに一致する Pod の数との間のターゲット関係を指定します。この関係は次の式に従って計算されます。

relation = (pods that match the selector) / (scaled workload pods)

relation = (pods that match the selector) / (scaled workload pods)

Copy to Clipboard

Toggle word wrap