Trident保護インストールのカスタマイズ
Trident保護のデフォルト設定をカスタマイズして、環境の特定の要件を満たすことができます。
Trident保護コンテナのリソース制限を指定
Trident保護のインストール後に、構成ファイルを使用してTrident保護コンテナのリソース制限を指定できます。リソース制限を設定すると、Trident保護処理で消費されるクラスタのリソースの量を制御できます。
-
という名前のファイルを作成します
resourceLimits.yaml
。 -
環境のニーズに応じて、Trident保護コンテナのリソース制限オプションをファイルに入力します。
次の構成ファイルの例は、使用可能な設定を示しています。このファイルには、各リソース制限のデフォルト値が含まれています。
--- jobResources: defaults: limits: cpu: 8000m memory: 10000Mi ephemeralStorage: "" requests: cpu: 100m memory: 100Mi ephemeralStorage: "" resticVolumeBackup: limits: cpu: "" memory: "" ephemeralStorage: "" requests: cpu: "" memory: "" ephemeralStorage: "" resticVolumeRestore: limits: cpu: "" memory: "" ephemeralStorage: "" requests: cpu: "" memory: "" ephemeralStorage: "" kopiaVolumeBackup: limits: cpu: "" memory: "" ephemeralStorage: "" requests: cpu: "" memory: "" ephemeralStorage: "" kopiaVolumeRestore: limits: cpu: "" memory: "" ephemeralStorage: "" requests: cpu: "" memory: "" ephemeralStorage: ""
-
ファイルから値を適用し `resourceLimits.yaml`ます。
helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect -f resourceLimits.yaml --reuse-values
セキュリティコンテキスト制約のカスタマイズ
Tridentプロテクトのインストール後、構成ファイルを使用して、TridentプロテクトコンテナのOpenShift Security Context Constraint(SCC;セキュリティコンテキスト制約)を変更できます。これらの制約により、Red Hat OpenShiftクラスタ内のポッドのセキュリティ制限が定義されます。
-
という名前のファイルを作成します
sccconfig.yaml
。 -
SCCオプションをファイルに追加し、環境のニーズに応じてパラメータを変更します。
次に、SCCオプションのパラメータのデフォルト値の例を示します。
scc: create: true name: trident-protect-job priority: 1
次の表では、SCCオプションのパラメータについて説明します。
パラメータ 説明 デフォルト 作成
SCCリソースを作成できるかどうかを決定します。SCCリソースは、がに設定され
true
、HelmのインストールプロセスでOpenShift環境が指定されている場合にのみ作成されscc.create`ます。OpenShiftで動作していない場合、またはがに設定されている `false`場合 `scc.create
、SCCリソースは作成されません。正しいです
名前
SCCの名前を指定します。
Trident - protect-job
優先度
SCCのプライオリティを定義します。優先度の高いSCCSは、低い値のSCCSよりも先に評価されます。
1
-
ファイルから値を適用し `sccconfig.yaml`ます。
helm upgrade trident-protect netapp-trident-protect/trident-protect -f sccconfig.yaml --reuse-values
これにより、デフォルト値がファイルで指定された値に置き換えられ `sccconfig.yaml`ます。
追加のTrident Protect Helm チャート設定を構成する
特定の要件に合わせて、 AutoSupport設定と名前空間フィルタリングをカスタマイズできます。次の表は、使用可能な構成パラメータを示しています。
パラメータ | を入力します | 説明 |
---|---|---|
自動サポートプロキシ |
文字列 |
NetApp AutoSupport接続用のプロキシ URL を構成します。これを使用して、サポート バンドルのアップロードをプロキシ サーバー経由でルーティングします。例: |
autoSupport.insecure |
ブール値 |
設定すると、 AutoSupportプロキシ接続のTLS検証をスキップします。 |
自動サポートが有効 |
ブール値 |
毎日のTrident Protect AutoSupportバンドルのアップロードを有効または無効にします。に設定すると |
スキップ名前空間注釈の復元 |
文字列 |
バックアップおよび復元操作から除外する名前空間注釈のコンマ区切りリスト。注釈に基づいて名前空間をフィルタリングできます。 |
スキップ名前空間ラベルの復元 |
文字列 |
バックアップおよび復元操作から除外する名前空間ラベルのコンマ区切りリスト。ラベルに基づいて名前空間をフィルタリングできます。 |
これらのオプションは、YAML 構成ファイルまたはコマンドライン フラグを使用して構成できます。
-
設定ファイルを作成し、名前を付けます
values.yaml
。 -
作成したファイルに、カスタマイズする構成オプションを追加します。
autoSupport: enabled: false proxy: http://my.proxy.url insecure: true restoreSkipNamespaceAnnotations: "annotation1,annotation2" restoreSkipNamespaceLabels: "label1,label2"
-
入力したら `values.yaml`正しい値を持つファイルの場合は、構成ファイルを適用します。
helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect -f values.yaml --reuse-values
-
次のコマンドを `--set`個々のパラメータを指定するためのフラグ:
helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect \ --set autoSupport.enabled=false \ --set autoSupport.proxy=http://my.proxy.url \ --set restoreSkipNamespaceAnnotations="annotation1,annotation2" \ --set restoreSkipNamespaceLabels="label1,label2" \ --reuse-values
Trident保護ポッドを特定のノードに制限する
KubernetesのnodeSelectorノード選択制約を使用すると、ノードラベルに基づいて、Trident保護ポッドを実行できるノードを制御できます。デフォルトでは、Trident保護はLinuxを実行しているノードに制限されます。必要に応じて、これらの制約をさらにカスタマイズできます。
-
という名前のファイルを作成します
nodeSelectorConfig.yaml
。 -
nodeSelectorオプションをファイルに追加し、ファイルを変更してノードラベルを追加または変更して、環境のニーズに応じて制限します。たとえば、次のファイルにはデフォルトのOS制限が含まれていますが、特定の地域とアプリ名も対象としています。
nodeSelector: kubernetes.io/os: linux region: us-west app.kubernetes.io/name: mysql
-
ファイルから値を適用し `nodeSelectorConfig.yaml`ます。
helm upgrade trident-protect -n trident-protect netapp-trident-protect/trident-protect -f nodeSelectorConfig.yaml --reuse-values
これにより、デフォルトの制限がファイルで指定した制限に置き換えられます
nodeSelectorConfig.yaml
。