クラスター管理

OpenShift Dedicated 4

OpenShift Dedicated クラスターの設定

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Dedicated クラスターの設定に関する情報を提供します。

第1章 プライベート接続の設定

1.1. AWS のプライベート接続の設定

1.1.1. AWS クラウドインフラストラクチャーのアクセスについて

注記

AWS クラウドインフラストラクチャーアクセスは、クラスターの作成時に選択した Customer Cloud Subscription (CCS) インフラストラクチャータイプには適用されません。これは、CCS クラスターがアカウントにデプロイされるためです。

Amazon Web Services (AWS) インフラストラクチャーへのアクセスにより、カスタマーポータルの組織管理者 およびクラスターの所有者は AWS の Identity and Access Management (IAM) ユーザーに OpenShift Dedicated クラスターの AWS 管理コンソールへの連携アクセスを割り当てることができます。AWS アクセスはカスタマー AWS ユーザーに付与でき、OpenShift Dedicated 環境のニーズに合わせてプライベートクラスターのアクセスを実装できます。

  1. OpenShift Dedicated クラスターの AWS インフラストラクチャーアクセスの設定を開始します。AWS ユーザーおよびアカウントを作成し、そのユーザーに OpenShift Dedicated AWS アカウントへのアクセスを提供します。
  2. OpenShift Dedicated AWS アカウントへのアクセスを取得した後に、以下の方法のいずれかを使用してクラスターへのプライベート接続を確立します。

    • AWS VPC ピアリングの設定: VPC ピアリングを有効にして、2 つのプライベート IP アドレス間のネットワークトラフィックをルーティングします。
    • AWS VPN の設定: プライベートネットワークを Amazon Virtual Private Cloud にセキュアに接続するために、仮想プライベートネットワークを確立します。
    • AWS Direct Connect の設定: プライベートネットワークと AWS Direct Connect の場所との間に専用のネットワーク接続を確立するように AWS Direct Connect を設定します。

クラウドインフラストラクチャーアクセスの設定後に、プライベートクラスターの設定について確認してください。

1.1.2. AWS インフラストラクチャーアクセスの設定

Amazon Web Services (AWS) インフラストラクチャーへのアクセスにより、カスタマーポータルの組織管理者 およびクラスターの所有者は AWS の Identity and Access Management (IAM) ユーザーに OpenShift Dedicated クラスターの AWS 管理コンソールへのフェデレーションアクセスを割り当てることができます。管理者は、Network Management または Read-only アクセスのオプションを選択できます。

前提条件

  • IAM パーミッションを持つ AWS アカウント。

手順

  1. AWS アカウントにログインします。必要な場合は、AWS ドキュメント に従って新規 AWS アカウントを作成できます。
  2. AWS アカウントで STS:AllowAssumeRole パーミッションを持つ IAM ユーザーを作成します。

    1. AWS 管理コンソールの IAM ダッシュボード を開きます。
    2. Policies セクションで、 Create Policy をクリックします。
    3. JSON タブを選択し、既存のテキストを以下に置き換えます。

      {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "sts:AssumeRole",
                "Resource": "*"
            }
        ]
      }
    4. Next:Tags をクリックします。
    5. オプション: タグを追加します。Next:Review をクリックします。
    6. 適切な名前および説明を指定してから Create Policy をクリックします。
    7. Users セクションで、Add plan をクリックします。
    8. 適切なユーザー名を指定します。
    9. AWS アクセスタイプとして AWS Management Console access を選択します。
    10. 組織に必要なパスワード要件を調整してから Next:Permissions をクリックします。
    11. Attach existing policies directly オプションをクリックします。直前の手順で作成したポリシーを検索し、確認します。

      注記

      パーミッションの境界を設定することは推奨されていません。

    12. Next: Tags をクリックしてから Next: Review をクリックします。設定が正しいことを確認します。
    13. Create user をクリックすると、成功ページが表示されます。
    14. IAM ユーザーの Amazon Resource Name (ARN) を収集します。ARN の形式は arn:aws:iam::000111222333:user/username のようになります。Close をクリックします。
  3. ブラウザーで OpenShift Cluster Manager を開き、AWS インフラストラクチャーアクセスを許可するクラスターを選択します。
  4. Access control タブを選択し、AWS Infrastructure Access セクションにスクロールします。
  5. AWS IAM ARN を貼り付け、Network Management または Read-only パーミッションを選択してから Grant role をクリックします。
  6. AWS OSD console URL をクリップボードにコピーします。
  7. アカウント ID またはエイリアス、IAM ユーザー名、およびパスワードを使用して AWS アカウントにサインインします。
  8. 新規のブラウザータブで、AWS Switch Role ページにルート指定するために使用される AWS OSD Console URL を貼り付けます。
  9. アカウント番号とロールはすでに入力されています。必要な場合は表示名を選択してから Switch Role をクリックします。

検証

  • これで、VPCRecently visited services の下に表示されます。

1.1.3. AWS VPC ピアリングの設定

Virtual Private Cloud (VPC) ピアリング接続は、2 つの VPC 間のネットワーク接続で、プライベート IPv4 アドレスまたは IPv6 アドレスを使用してこれらの間のトラフィックをルーティングできるようにします。OpenShift Dedicated クラスターを含む Amazon Web Services (AWS) VPC を別の AWS VPC ネットワークとピア接続するように設定できます。

警告

クラスターをアンインストールする前に、クラスターの VPC から VPC ピアリング接続を削除する必要があります。これを行わないと、クラスターがアンインストールプロセスを完了しない可能性があります。

AWS は、中国を除く すべての商業地域でのリージョン間の VPC ピアリングをサポートします。

前提条件

  • ピアリング要求を開始するために必要な Customer VPC に関する以下の情報を収集する。

    • Customer AWS アカウント番号
    • Customer VPC ID
    • Customer VPC リージョン
    • Customer VPC CIDR
  • OpenShift Dedicated Cluster VPC で使用される CIDR ブロックを確認する。Customer VPC の CIDR ブロックとの重複や一致がある場合、これらの 2 つの VPC 間のピアリングは実行できません。詳細は、Amazon VPC の サポートされていない VPC ピアリング設定 に関するドキュメントを参照してください。CIDR ブロックが重複しない場合は、以下の手順を実行できます。

関連情報

  • 詳細およびトラブルシューティングのヘルプは、AWS VPC ガイドを参照してください。

1.1.4. AWS VPN の設定

Amazon Web Services (AWS) OpenShift Dedicated クラスターを、お客様のオンサイトのハードウェア仮想プライベートネットワーク (VPN) デバイスを使用するように設定できます。デフォルトで、AWS Virtual Private Cloud (VPC) に起動するインスタンスは、独自の (リモート) ネットワークと通信できません。AWS Site-to-Site VPN 接続を作成し、ルーティングを設定して接続経由でトラフィックを渡すことで、VPC からリモートネットワークへのアクセスを有効にできます。

注記

AWS VPN は現在、NAT を VPN トラフィックに適用するための管理オプションを提供しません。詳細は、AWS Knowledge Center を参照してください。

プライベート接続を使用したすべてのトラフィックのルーティング (0.0.0.0/0 など) はサポートされていません。これには、SRE 管理トラフィックを無効にするインターネットゲートウェイを削除する必要があります。

前提条件

  • ハードウェア VPN ゲートウェイデバイスモデルおよびソフトウェアバージョン (例: バージョン 8.3 を実行している Cisco ASA)。AWS ドキュメント を参照して、お使いのゲートウェイデバイスが AWS でサポートされているかどうかを確認します。
  • VPN ゲートウェイデバイスのパブリックな静的 IP アドレス。
  • BGP または静的ルーティング: BGP の場合は、ASN が必要です。静的ルーティングの場合は、1 つ以上の静的ルートを設定する必要があります。
  • オプション: VPN 接続をテストするための到達可能なサービスの IP およびポート/プロトコル。

手順

  1. VPN 接続を設定するために カスタマーゲートウェイを作成 します。
  2. 仮想プライベートゲートウェイが目的の VPC に割り当てられていない場合は、仮想プライベートゲートウェイを 作成して割り当て ます。
  3. ルーティングを設定し、VPN ルート伝播を有効にします
  4. セキュリティーグループを更新します
  5. サイト間 VPN 接続を確立します

    注記

    VPC サブネット情報をメモします。これは、リモートネットワークとして設定に追加する必要があります。

関連情報

  • 詳細およびトラブルシューティングのヘルプは、AWS VPN ガイドを参照してください。

1.1.5. AWS Direct Connect の設定

Amazon Web Services (AWS) Direct Connect では、ホストされた Virtual Interface (VIF) が Direct Connect Gateway (DXGateway) に接続されている必要があります。これは、同じまたは別のアカウントでリモート Virtual Private Cloud (VPC) にアクセスするために Virtual Gateway (VGW) または Transit Gateway に関連付けられます。

既存の DXGateway がない場合、通常のプロセスではホストされた VIF を作成し、AWS アカウントに DXGateway および VGW が作成されます。

既存の DXGateway が 1 つ以上の既存の VGW に接続されている場合は、プロセスに AWS アカウントが Association Proposal を DXGateway の所有者に送信します。DXGateway の所有者は、提案された CIDR が関連付けられているその他の VGW と競合しないようにする必要があります。

前提条件

  • OpenShift Dedicated VPC の CIDR 範囲が、関連付けのあるその他の VGW と競合しないことを確認する。
  • 以下の情報を集めておく。

    • Direct Connect Gateway ID。
    • 仮想インターフェイスに関連付けられた AWS アカウント ID。
    • DXGateway に割り当てられた BGP ASN。必要に応じて、Amazon のデフォルト ASN も使用できます。

手順

  1. VIF を作成する か、既存の VIF を表示 して、作成する必要のあるダイレクト接続の種別を判断します。
  2. ゲートウェイを作成します。

    1. Direct Connect VIF タイプが Private の場合は、仮想プライベートゲートウェイを作成 します。
    2. Direct Connect VIF が Public の場合は、Direct Connect ゲートウェイを作成 します。
  3. 使用する既存のゲートウェイがある場合は、関連付けの提案を作成 し、承認のために提案を DXGateway の所有者に送信します。

    警告

    既存の DXGateway に接続する場合は、コスト がかかります。

関連情報

  • 詳細およびトラブルシューティングのヘルプは、AWS Direct Connect ガイドを参照してください。

1.2. プライベートクラスターの設定

OpenShift Dedicated クラスターをプライベートにし、内部アプリケーションを企業ネットワーク内でホストできるようにします。さらに、プライベートクラスターは、セキュリティーを強化するために内部 API エンドポイントのみを持つように設定できます。

OpenShift Dedicated 管理者は、OpenShift Cluster Manager 内からパブリックおよびプライベートのクラスター設定のいずれかを選択できます。プライバシー設定は、クラスターの作成時またはクラスターの設定後に設定できます。

1.2.1. クラスター作成時のプライベートクラスターの有効化

新規クラスターの作成時にプライベートクラスター設定を有効にできます。

前提条件

  • プライベートアクセスを許可するために以下のプライベート接続を設定しておく。

    • VPC ピアリング
    • Cloud VPN
    • DirectConnect (AWS のみ)
    • TransitGateway (AWS のみ)
    • Cloud Interconnect (GCP のみ)

手順

  1. OpenShift Cluster Manager にログインします。
  2. Create clusterOpenShift DedicatedCreate cluster をクリックします。
  3. クラスターの詳細を設定します。
  4. 希望するネットワーク設定を選択する場合は、Advanced を選択します。
  5. Private を選択します。

    警告

    Private に設定されている場合は、前提条件で説明されているように、クラウドプロバイダーにプライベート接続を設定しない限り、クラスターにアクセスできません。

  6. Create cluster をクリックします。クラスター作成プロセスが開始され、完了するまでに 30 - 40 分かかります。

検証

  • Overview タブの Installing cluster という見出しは、クラスターがインストール中であることを示し、この見出しからインストールログを確認できます。Details 見出しの Status インジケーターは、クラスターが使用できる Ready 状態であるかを示します。

1.2.2. 既存クラスターをプライベートにすることが可能

クラスターを作成したら、後でクラスターをプライベートにすることができます。

前提条件

  • プライベートアクセスを許可するために以下のプライベート接続を設定しておく。

    • VPC ピアリング
    • Cloud VPN
    • DirectConnect (AWS のみ)
    • TransitGateway (AWS のみ)
    • Cloud Interconnect (GCP のみ)

手順

  1. OpenShift Cluster Manager にログインします。
  2. プライベートにするパブリッククラスターを選択します。
  3. Networking タブの Control Plane API endpoint の下で、Make API private を選択します。

    警告

    Private に設定されている場合は、前提条件で説明されているように、クラウドプロバイダーにプライベート接続を設定しない限り、クラスターにアクセスできません。

  4. Change settings をクリックします。

    注記

    クラスターをプライベートとパブリックの間で移行するには、完了までに数分の時間がかかる場合があります。

1.2.3. 既存のプライベートクラスターをパブリックにすることが可能

プライベートクラスターを作成したら、後でクラスターをパブリックにすることができます。

手順

  1. OpenShift Cluster Manager にログインします。
  2. パブリックにするプライベートクラスターを選択します。
  3. Networking タブの Control Plane API endpoint の下で、Make API private の選択を解除します。
  4. Change settings をクリックします。

    注記

    クラスターをプライベートとパブリックの間で移行するには、完了までに数分の時間がかかる場合があります。

第2章 クラスターの自動スケーリング

OpenShift Dedicated に自動スケーリングを適用するには、クラスターオートスケーラーを設定してから、クラスター内の少なくとも 1 つのマシンプールに対してマシンオートスケーラーを設定する必要があります。

重要

Cluster Autoscaler は、マシン API が機能しているクラスターでのみ設定できます。

クラスターオートスケーラーはクラスターごとに 1 つだけ作成できます。

2.1. Cluster Autoscaler について

Cluster Autoscaler は、現行のデプロイメントのニーズに合わせて OpenShift Dedicated クラスターのサイズを調整します。これは、Kubernetes 形式の宣言引数を使用して、特定のクラウドプロバイダーのオブジェクトに依存しないインフラストラクチャー管理を提供します。Cluster Autoscaler には cluster スコープがあり、特定の namespace には関連付けられていません。

Cluster Autoscaler は、リソース不足のために現在のワーカーノードのいずれにもスケジュールできない Pod がある場合や、デプロイメントのニーズを満たすために別のノードが必要な場合に、クラスターのサイズを拡大します。Cluster Autoscaler は、指定の制限を超えてクラスターリソースを拡大することはありません。

Cluster Autoscaler は、コントロールプレーンノードを管理しない場合でも、クラスター内のすべてのノードのメモリー、CPU の合計を計算します。これらの値は、単一マシン指向ではありません。これらは、クラスター全体での全リソースの集約です。たとえば、最大メモリーリソースの制限を設定する場合、Cluster Autoscaler は現在のメモリー使用量を計算する際にクラスター内のすべてのノードを含めます。この計算は、Cluster Autoscaler にワーカーリソースを追加する容量があるかどうかを判別するために使用されます。

重要

作成する ClusterAutoscaler リソース定義の maxNodesTotal 値が、クラスター内のマシンの想定される合計数に対応するのに十分な大きさの値であることを確認します。この値は、コントロールプレーンマシンの数とスケーリングする可能性のあるコンピュートマシンの数に対応できる値である必要があります。

Cluster Autoscaler は 10 秒ごとに、クラスターで不要なノードをチェックし、それらを削除します。Cluster Autoscaler は、以下の条件が適用される場合に、ノードを削除すべきと考えます。

  • ノードの使用率はクラスターの ノード使用率レベル のしきい値 よりも低い場合。ノード使用率レベルとは、要求されたリソースの合計をノードに割り当てられたリソースで除算したものです。ClusterAutoscaler カスタムリソースで値を指定しない場合、Cluster Autoscaler は 50% の使用率に対応するデフォルト値 0.5 を使用します。
  • Cluster Autoscaler がノードで実行されているすべての Pod を他のノードに移動できる。Kubernetes スケジューラーは、ノード上の Pod のスケジュールを担当します。
  • Cluster Autoscaler で、スケールダウンが無効にされたアノテーションがない。

以下のタイプの Pod がノードにある場合、Cluster Autoscaler はそのノードを削除しません。

  • 制限のある Pod の Disruption Budget (停止状態の予算、PDB) を持つ Pod。
  • デフォルトでノードで実行されない Kube システム Pod。
  • PDB を持たないか、制限が厳しい PDB を持つ Kuber システム Pod。
  • デプロイメント、レプリカセット、またはステートフルセットなどのコントローラーオブジェクトによってサポートされない Pod。
  • ローカルストレージを持つ Pod。
  • リソース不足、互換性のないノードセレクターまたはアフィニティー、一致する非アフィニティーなどにより他の場所に移動できない Pod。
  • それらに "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" アノテーションがない場合、"cluster-autoscaler.kubernetes.io/safe-to-evict": "false" アノテーションを持つ Pod。

たとえば、CPU の上限を 64 コアに設定し、それぞれ 8 コアを持つマシンのみを作成するように Cluster Autoscaler を設定したとします。クラスターが 30 コアで起動する場合、Cluster Autoscaler は最大で 4 つのノード (合計 32 コア) を追加できます。この場合、総計は 62 コアになります。

Cluster Autoscaler を設定する場合、使用に関する追加の制限が適用されます。

  • 自動スケーリングされたノードグループにあるノードを直接変更しないようにしてください。同じノードグループ内のすべてのノードには同じ容量およびラベルがあり、同じシステム Pod を実行します。
  • Pod の要求を指定します。
  • Pod がすぐに削除されるのを防ぐ必要がある場合、適切な PDB を設定します。
  • クラウドプロバイダーのクォータが、設定する最大のノードプールに対応できる十分な大きさであることを確認します。
  • クラウドプロバイダーで提供されるものなどの、追加のノードグループの Autoscaler を実行しないようにしてください。

Horizontal Pod Autoscaler (HPA) および Cluster Autoscaler は複数の異なる方法でクラスターリソースを変更します。HPA は、現在の CPU 負荷に基づいてデプロイメント、またはレプリカセットのレプリカ数を変更します。負荷が増大すると、HPA はクラスターで利用できるリソース量に関係なく、新規レプリカを作成します。十分なリソースがない場合、Cluster Autoscaler はリソースを追加し、HPA で作成された Pod が実行できるようにします。負荷が減少する場合、HPA は一部のレプリカを停止します。この動作によって一部のノードの使用率が低くなるか、完全に空になる場合、Cluster Autoscaler は不必要なノードを削除します。

Cluster Autoscaler は Pod の優先順位を考慮に入れます。Pod の優先順位とプリエンプション機能により、クラスターに十分なリソースがない場合に優先順位に基づいて Pod のスケジューリングを有効にできますが、Cluster Autoscaler はクラスターがすべての Pod を実行するのに必要なリソースを確保できます。これら両方の機能の意図を反映するべく、Cluster Autoscaler には優先順位のカットオフ機能が含まれています。このカットオフを使用して Best Effort の Pod をスケジュールできますが、これにより Cluster Autoscaler がリソースを増やすことはなく、余分なリソースがある場合にのみ実行されます。

カットオフ値よりも低い優先順位を持つ Pod は、クラスターをスケールアップせず、クラスターのスケールダウンを防ぐこともありません。これらの Pod を実行するために新規ノードは追加されず、これらの Pod を実行しているノードはリソースを解放するために削除される可能性があります。

クラスターの自動スケーリングは、マシン API が利用可能なプラットフォームでサポートされています。

2.2. OpenShift Cluster Manager を使用してクラスター作成中に自動スケーリングを有効にする

OpenShift Cluster Manager を使用して、クラスターの作成中に自動スケーリングできます。

手順

  1. クラスターの作成中に、Enable autoscaling ボックスをオンにします。Edit cluster autoscaling settings ボタンが選択可能になります。

    1. 自動スケールするノードの最小数または最大数を選択することもできます。
  2. Edit cluster autoscaling settings をクリックします。
  3. 必要な設定を編集し、Close をクリックします。

2.3. OpenShift Cluster Manager を使用してクラスター作成後に自動スケーリングを有効にする

OpenShift Cluster Manager を使用して、クラスターの作成後に自動スケーリングできます。

手順

  1. OpenShift Cluster Manager で、自動スケーリングするクラスターの名前をクリックします。クラスターの概要ページには、Autoscaling が有効か無効かを示す項目があります。
  2. Machine pools タブをクリックします。
  3. Edit cluster autoscaling ボタンをクリックします。Edit cluster autoscaling ウィンドウが表示されます。
  4. ウィンドウの上部にある Autoscale cluster トグルをクリックします。すべての設定が編集可能になりました。
  5. 必要な設定を編集し、Save をクリックします。
  6. 画面右上の × をクリックして設定画面を閉じます。

すべての自動スケーリング設定が変更されている場合にデフォルトに戻すには、Revert all to defaults ボタンをクリックします。

2.4. OpenShift Cluster Manager を使用したクラスターの自動スケーリング設定

次の表では、OpenShift Cluster Manager でクラスター自動スケーリングを使用する場合に設定可能なすべての UI 設定について説明します。

2.4.1. 一般設定

表2.1 OpenShift Cluster Manager を使用する場合のクラスター自動スケーリングの設定可能な全般設定

設定説明型または範囲デフォルト

log-verbosity

Autoscaler のログレベルを設定します。デフォルト値は 1 です。デバッグには、レベル 4 が推奨されます。レベル 6 はほぼすべてを有効にします。

integer

1

skip-nodes-with-local-storage

true の場合、クラスターオートスケーラーは、ローカルストレージ (EmptyDir や HostPath など) を持つ Pod を持つノードを削除しません。

boolean

true

max-pod-grace-period

スケールダウンする前に Pod に正常な終了時間を秒単位で与えます。

integer

600

max-node-provision-time

Cluster Autoscaler がノードのプロビジョニングを待機する最大時間。

string

15m

pod-priority-threshold

ユーザーは、クラスターオートスケーラーアクションをトリガーすることが期待されていないベストエフォート Pod をスケジュールできます。これらの Pod は、予備のリソースが利用可能な場合にのみ実行されます。

integer

-10

ignore-daemonsets-utilization

スケールダウンのためのリソース使用率を計算するときに、Cluster Autoscaler がデーモンセット Pod を無視するかどうかを決定します。

boolean

false

balance-similar-node-groups

true の場合、この設定は、同じインスタンスタイプと同じラベルセットを持つノードグループを自動的に識別し、それらのノードグループのそれぞれのサイズのバランスを維持しようとします。

boolean

false

balancing-ignored-labels

このオプションは、ノードグループの類似性を考慮するときにクラスターオートスケーラーが無視するラベルを指定します。たとえば、topology.ebs.csi.aws.com/zone ラベルが付いたノードがある場合、このラベルの名前を追加して、クラスターオートスケーラーがその値に基づいてノードを異なるノードグループに分割しないようにすることができます。このオプションにはスペースを使用できません。

array (string)

形式は、コンマで区切られたラベルのリストである必要があります。

2.4.2. リソース制限

表2.2 OpenShift Cluster Manager を使用する場合のクラスター自動スケーリングの設定可能なリソース制限設定

設定説明型または範囲デフォルト

cores-total-min

クラスター内のコアの最小数。Cluster Autoscaler は、この数値より小さいクラスターをスケーリングしません。

object

0

cores-total-max

クラスター内のコアの最大数。クラスターオートスケーラーは、この数値を超えるクラスターをスケーリングしません。

object

180 * 64 (11520)

memory-total-min

クラスター内のメモリーの最小ギガバイト数。Cluster Autoscaler は、この数値より小さいクラスターをスケーリングしません。

object

0

memory-total-max

クラスター内のメモリーの最大ギガバイト数。クラスターオートスケーラーは、この数値を超えるクラスターをスケーリングしません。

object

180 * 64 * 20 (230400)

max-nodes-total

すべてのノードグループのノードの最大数。自動的にスケールされたノードだけでなく、すべてのノードが含まれます。Cluster Autoscaler は、この数値を超えてクラスターを拡大しません。

integer

180

GPU

クラスター内の異なる GPU の最小数と最大数。Cluster Autoscaler は、これらの数値より小さくても大きくてもクラスターをスケーリングしません。

array

形式は、"<gpu_type>:<min>:<max>" のコンマ区切りのリストである必要があります。

2.4.3. スケールダウン設定

表2.3 OpenShift Cluster Manager を使用する場合の Cluster Autoscaler のスケールダウン設定を設定可能

設定説明型または範囲デフォルト

scale-down-enabled

Cluster Autoscaler はクラスターをスケールダウンする必要があります。

boolean

true

scale-down-utilization-threshold

ノード使用率レベル。要求されたリソースの合計を容量で割ったものとして定義され、このレベルを下回るとノードのスケールダウンが考慮されます。

float

0.5

scale-down-unneeded-time

スケールダウンの対象となる前にノードが不要になるまでの期間。

string

10m

scale-down-delay-after-add

スケールアップ後、スケールダウン評価が再開されるまでの期間。

string

10m

scale-down-delay-after-delete

ノードの削除後、スケールダウン評価が再開されるまでの時間。

string

0s

scale-down-delay-after-failure

スケールダウンの失敗後、スケールダウン評価が再開されるまでの期間。

string

3m

第3章 ノード

3.1. マシンプールについて

OpenShift Dedicated は、クラウドインフラストラクチャーで柔軟性があり動的なプロビジョニング方法としてマシンプールを使用します。

プライマリーリソースは、マシン、マシンセット、およびマシンプールです。

重要

OpenShift Dedicated 4.11 以降、デフォルトの Pod ごとの PID 制限は 4096 です。この PID 制限を有効にする場合は、OpenShift Dedicated クラスターを 4.11 以降にアップグレードする必要があります。以前のバージョンで実行されている OpenShift Dedicated クラスターは、デフォルトの PID 制限である 1024 を使用します。

OpenShift Dedicated クラスターでは、Pod ごとの PID 制限を設定することはできません。

3.1.1. マシン

マシンは、ワーカーノードのホストを記述する基本的な単位です。

3.1.2. マシンセット

MachineSet リソースは、計算マシンのグループです。より多くのマシンが必要な場合、またはマシンをスケールダウンする必要がある場合は、コンピュートマシンセットが属するマシンプール内のレプリカの数を変更します。

3.1.3. マシンプール

マシンプールは、マシンセットを計算するための上位レベルの構造です。

コンピュートマシンプールは、アベイラビリティーゾーン全体で同じ設定のクローンがすべて含まれるマシンセットを作成します。マシンプールは、ワーカーノードですべてのホストノードのプロビジョニング管理アクションを実行します。より多くのマシンが必要な場合、またはマシンをスケールダウンする必要がある場合は、コンピュートのニーズに合わせてマシンプール内のレプリカの数を変更してください。スケーリングは手動または自動の設定ができます。

デフォルトで、クラスターは 1 つのマシンプールを使用して作成されます。追加のマシンプールを既存クラスターに追加し、デフォルトのマシンプールを変更して、マシンプールを削除できます。

1 つのクラスターに複数のマシンプールが存在する可能性があり、それぞれが異なるタイプまたは異なるサイズのノードを持つことができます。

3.1.4. 複数のゾーンクラスターのマシンプール

複数のアベイラビリティーゾーン (Multi-AZ) クラスターにマシンプールを作成する場合は、1 つのマシンプールに 3 つのゾーンがあります。次に、マシンプールは、合計 3 つのコンピュートマシンセット (クラスター内のゾーンごとに 1 つ) を作成します。これらの各コンピュートマシンセットは、それぞれのアベイラビリティーゾーンで 1 つ以上のマシンを管理します。

新しい Multi-AZ クラスターを作成すると、マシンプールはそれらのゾーンに自動的に複製されます。マシンプールを既存の Multi-AZ に追加すると、そのゾーンに新しいプールが自動的に作成されます。同様に、マシンプールを削除するとすべてのゾーンから削除されます。この相乗効果により、Multi-AZ クラスターでマシンプールを使用すると、マシンプールを作成するときに、特定のリージョンに対するプロジェクトのクォータをより多く消費する可能性があります。

3.1.5. 関連情報

3.2. コンピュートノードの管理

このドキュメントでは、OpenShift Dedicated を使用してコンピュート (ワーカーとも呼ばれます) ノードを管理する方法について説明します。

コンピュートノードの変更の大半は、マシンプールで設定されます。マシンプール は、管理を容易にするために、同じ設定を持つクラスター内のコンピュートノードのグループです。

スケーリング、ノードラベルの追加、テイントの追加などのマシンプール設定オプションを編集できます。

3.2.1. マシンセットの作成

OpenShift Dedicated クラスターをインストールすると、マシンプールが作成されます。インストール後、OpenShift Cluster Manager を使用して、クラスターの追加のマシンプールを作成できます。

重要

使用可能なコンピュート (ワーカーとも呼ばれる) ノードインスタンスタイプ、自動スケーリングオプション、およびノード数は、OpenShift Dedicated サブスクリプション、リソースクォータ、およびデプロイメントシナリオによって異なります。詳細は、営業担当者または Red Hat サポートにお問い合わせください。

前提条件

  • OpenShift Dedicated クラスターを作成している。

手順

  1. OpenShift Cluster Manager に移動し、クラスターを選択します。
  2. Machine pools タブで、Add machine pool をクリックします。
  3. マシンプール名 を追加します。
  4. ドロップダウンメニューから Compute node instance type を選択します。インスタンスタイプは、マシンプール内の各コンピュートノードの仮想 CPU およびメモリー割り当てを定義します。

    注記

    プールを作成した後に、マシンプールのインスタンスタイプを変更することはできません。

  5. オプション: マシンプールの自動スケーリングを設定します。

    1. Enable autoscaling を選択し、デプロイメントのニーズを満たすためにマシンプール内のマシン数を自動的にスケーリングします。

      注記

      Enable autoscaling オプションは、capability.cluster.autoscale_clusters サブスクリプションがある場合にのみ OpenShift Dedicated で使用できます。詳細は、営業担当者または Red Hat サポートにお問い合わせください。

    2. 自動スケーリングの最小および最大のノード数制限を設定します。Cluster Autoscaler は、指定する制限を超えてマシンプールノード数を減らしたり、増やしたりできません。

      • 単一アベイラビリティーゾーンを使用してクラスターをデプロイした場合は、最小および最大のノード数 を設定します。これは、アベイラビリティーゾーンのコンピュートノードの最小および最大の制限を定義します。
      • 複数のアベイラビリティーゾーンを使用してクラスターをデプロイした場合は、Minimum nodes per zone および Maximum nodes per zone を設定します。これは、ゾーンごとの最小および最大のコンピュート制限を定義します。

        注記

        または、マシンプールの作成後にマシンプールの自動スケーリングを設定できます。

  6. 自動スケーリングを有効にしていない場合は、コンピュートノードの数を選択します。

    • 単一アベイラビリティーゾーンを使用してクラスターをデプロイした場合は、ドロップダウンメニューから コンピュートノード数 を選択します。これは、ゾーンのマシンプールにプロビジョニングするコンピュートノードの数を定義します。
    • 複数のアベイラビリティーゾーンを使用してクラスターをデプロイした場合は、ドロップダウンメニューから コンピュートノードの数 (ゾーンごと) を選択します。これは、ゾーンごとにマシンプールにプロビジョニングするコンピュートノードの数を定義します。
  7. オプション: マシンプールのノードラベルおよびテイントを追加します。

    1. Edit node labels and taints メニューをデプロイメントします。
    2. Node labels で、ノードラベルの Key および Value のエントリーを追加します。
    3. Taints で、テイントの Key および Value エントリーを追加します。

      注記

      テイントを含むマシンプールの作成は、クラスターにテイントのないマシンプールが少なくとも 1 つすでに存在する場合にのみ可能です。

    4. テイントごとに、ドロップダウンメニューから Effect を選択します。使用できるオプションには、NoSchedulePreferNoSchedule、および NoExecute が含まれます。

      注記

      または、マシンプールの作成後にノードラベルおよびテイントを追加できます。

  8. オプション: このマシンプール内のノードに使用する追加のカスタムセキュリティーグループを選択します。すでにセキュリティーグループを作成し、このクラスター用に選択した VPC にそのグループを関連付けている必要があります。マシンプールの作成後は、セキュリティーグループを追加または編集することはできません。詳細は、関連情報セクションのセキュリティーグループの要件を参照してください。

    重要

    ROSA with HCP クラスターのマシンプールには、最大 10 個の追加セキュリティーグループを使用できます。

  9. オプション: Customer Cloud Subscription (CCS) モデルを使用して AWS に OpenShift Dedicated をデプロイした際に、保証されていない AWS スポットインスタンスとしてマシンをデプロイするようにマシンプールを設定する場合は、Amazon EC2 スポットインスタンスを使用します。

    1. Use Amazon EC2 Spot Instances を選択します。
    2. オンデマンドのインスタンス価格を使用するには、Use On-Demand instance price を選択したままにします。または、Set maximum price を選択して、Spot インスタンスの 1 時間ごとの最大価格を定義します。

      Amazon EC2 Spot インスタンスの詳細は、AWS のドキュメント を参照してください。

      重要

      Amazon EC2 Spot インスタンスはいつでも中断する可能性があります。Amazon EC2 Spot インスタンスは、中断に対応できるワークロードにのみ使用します。

      注記

      マシンプールに Use Amazon EC2 Spot Instances を選択すると、マシンプールの作成後にオプションを無効にすることはできません。

  10. Add machine pool をクリックしてマシンプールを作成します。

検証

  • マシンプールが Machine pools ページに表示され、設定が想定どおりに表示されていることを確認します。

3.2.2. マシンプールの削除

ワークロード要件が変更され、現在のマシンプールがニーズを満たさなくなった場合は、マシンプールを削除できます。

OpenShift Cluster Manager を使用してマシンプールを削除できます。

前提条件

  • OpenShift Dedicated クラスターを作成している。
  • クラスターが準備状態にある。
  • テイントのない既存のマシンプールがあり、シングル AZ クラスターの場合は少なくとも 2 つのレプリカ、マルチ AZ クラスターの場合は少なくとも 3 つのレプリカがある。

手順

  1. OpenShift Cluster Manager から、Clusters ページに移動し、削除するマシンプールを含むクラスターを選択します。
  2. 選択したクラスターで、Machine pools タブを選択します。
  3. Machine pools タブで、削除するマシンプールのオプションメニュー kebab をクリックします。
  4. Delete をクリックします。

選択したマシンプールが削除されます。

3.2.3. コンピュートノードの手動によるスケーリング

マシンプールの自動スケーリングを有効にしていない場合は、デプロイメントのニーズに合わせてプール内のコンピュート (ワーカーとも呼ばれる) ノードの数を手動でスケーリングできます。

各マシンプールを個別にスケーリングする必要があります。

前提条件

  • OpenShift Dedicated クラスターを作成している。
  • 既存のマシンプールがある。

手順

  1. OpenShift Cluster Manager に移動し、クラスターを選択します。
  2. Machine pools タブで、スケーリングするマシンプールのオプションメニュー kebab をクリックします。
  3. Scale を選択します。
  4. ノード数を指定します。

    • 単一のアベイラビリティーゾーンを使用してクラスターをデプロイした場合は、ドロップダウンメニューでNode count を指定します。
    • 複数のアベイラビリティーゾーンを使用してクラスターをデプロイした場合は、ドロップダウンメニューでNode count per zone を指定します。

      注記

      サブスクリプションにより、選択可能なノードの数が決まります。

  5. Apply をクリックして、マシンプールをスケーリングします。

検証

  • Machine pools タブで、マシンプールの Node count が期待どおりであることを確認します。

3.2.4. ノードラベル

ラベルは、Node オブジェクトに適用されるキーと値のペアです。ラベルを使用して一連のオブジェクトを整理し、Pod のスケジューリングを制御できます。

クラスターの作成中または後にラベルを追加できます。ラベルはいつでも変更または更新できます。

関連情報

3.2.4.1. ノードラベルのマシンプールへの追加

いつでもコンピュート (ワーカーとも呼ばれる) ノードのラベルを追加または編集して、適切な方法でノードを管理します。たとえば、ワークロードのタイプを特定のノードに割り当てることができます。

ラベルは key-value ペアとして割り当てられます。各キーは、割り当てられたオブジェクトに固有のものである必要があります。

前提条件

  • OpenShift Dedicated クラスターを作成している。
  • 既存のマシンプールがある。

手順

  1. OpenShift Cluster Manager に移動し、クラスターを選択します。
  2. Machine pools タブで、ラベルを追加するマシンプールのオプションメニュー kebab をクリックします。
  3. Edit labels を選択します。
  4. 削除するマシンプールに既存のラベルがある場合は、ラベルの横にある x を選択して削除します。
  5. <key>=<value> の形式を使用してラベルを追加し、Enter を押します。たとえば、app=db を追加して、Enter を押します。形式が正しい場合は、キーと値のペアが強調表示されます。
  6. ラベルを追加する場合は、前の手順を繰り返します。
  7. Save をクリックして、ラベルをマシンプールに適用します。

検証

  1. Machine pools タブで、マシンプールの横にある > を選択して、ビューをデプロイメントします。
  2. デプロイメントされたビューの Labels の下にラベルが表示されていることを確認します。

3.2.5. マシンプールへのテイントの追加

マシンプールにコンピュート (ワーカーとも呼ばれる) ノードにテイントを追加して、そのノードにスケジュールされる Pod を制御できます。テイントをマシンプールに適用すると、Pod 仕様にテイントの容認が含まれない限り、スケジューラーは Pod をプールに配置できません。

注記

クラスターにはテイントを含まないマシンプールが少なくとも 1 つ必要です。

前提条件

  • OpenShift Dedicated クラスターを作成している。
  • テイントを含まず、少なくとも 2 つのインスタンスを含む既存のマシンプールがある。

手順

  1. OpenShift Cluster Manager に移動し、クラスターを選択します。
  2. Machine pools タブで、テイントを追加するマシンプールのオプションメニュー kebab をクリックします。
  3. Edit taints を選択します。
  4. テイントのKeyValue のエントリーを追加します。
  5. ドロップダウンメニューからテイントの Effect を選択します。使用できるオプションには、NoSchedulePreferNoSchedule、および NoExecute が含まれます。
  6. マシンプールにテイントを追加する場合は、Add taint を選択します。
  7. Save をクリックして、テイントをマシンプールに適用します。

検証

  1. Machine pools タブで、マシンプールの横にある > を選択して、ビューをデプロイメントします。
  2. デプロイメントされたビューの Taints の下にテイントがリストされていることを確認します。

3.2.6. 関連情報

3.3. クラスターでのノードの自動スケーリングについて

重要

自動スケーリングは、Google Cloud Marketplace および Red Hat Marketplace を通じて購入したクラスターでのみ利用できます。

自動スケーリングオプションは、クラスター内のマシンの数を自動的にスケーリングするように設定できます。

Cluster Autoscaler は、リソース不足のために現在のノードのいずれにも Pod をスケジュールできない場合、またはデプロイメントのニーズを満たすために別のノードが必要な場合に、クラスターのサイズを拡大します。Cluster Autoscaler は、指定の制限を超えてクラスターリソースを拡大することはありません。

さらに、Cluster Autoscaler は、リソースの使用量が少なく、重要な Pod すべてが他のノードに適合する場合など、一部のノードが長い期間にわたって不要な状態が続く場合にクラスターのサイズを縮小します。

自動スケーリングを有効にする場合は、ワーカーノードの最小数および最大数も設定する必要があります。

注記

クラスターの所有者と組織管理者のみがクラスターのスケーリングまたは削除が可能です。

3.3.1. クラスターでの自動スケーリングノードの有効化

ワーカーノードで自動スケーリングを有効にし、既存クラスターのマシンプール定義を編集して利用可能なノード数を増減できます。

Red Hat OpenShift Cluster Manager を使用した既存のクラスターでの自動スケーリングノードの有効化

OpenShift Cluster Manager コンソールからマシンプール定義でワーカーノードの自動スケーリングを有効にします。

手順

  1. OpenShift Cluster Manager で、Clusters ページに移動し、自動スケーリングを有効にするクラスターを選択します。
  2. 選択したクラスターで、Machine pools タブを選択します。
  3. 自動スケーリングを有効にするマシンプールの最後にある Options メニュー kebab をクリックし、Scale を選択します。
  4. Edit node count ダイアログで、Enable autoscaling チェックボックスを選択します。
  5. Apply を選択してこれらの変更を保存し、クラスターの自動スケーリングを有効にします。

3.3.2. クラスターでの自動スケーリングノードの無効化

ワーカーノードで自動スケーリングを無効にし、既存クラスターのマシンプール定義を編集して利用可能なノード数を増減できます。

OpenShift Cluster Manager コンソールを使用して、クラスターでの自動スケーリングを無効にできます。

Red Hat OpenShift Cluster Manager を使用した既存のクラスターでの自動スケーリングノードの無効化

OpenShift Cluster Manager コンソールからマシンプール定義でワーカーノードの自動スケーリングを無効にします。

手順

  1. OpenShift Cluster Manager で、Clusters ページに移動し、無効にする必要のある自動スケーリングでクラスターを選択します。
  2. 選択したクラスターで、Machine pools タブを選択します。
  3. 自動スケーリングのあるマシンプールの最後にある Options メニュー kebab をクリックし、Scale を選択します。
  4. ノード数の編集ダイアログで、Enable autoscaling チェックボックスの選択を解除します。
  5. Apply を選択してこれらの変更を保存し、クラスターから自動スケーリングを無効にします。

自動スケーリングの OpenShift Dedicated クラスターへの適用には、クラスターへの Cluster Autoscaler のデプロイと各マシンタイプの Machine Autoscaler のデプロイが必要です。

重要

Cluster Autoscaler は、マシン API が機能しているクラスターでのみ設定できます。

3.3.3. Cluster Autoscaler について

Cluster Autoscaler は、現行のデプロイメントのニーズに合わせて OpenShift Dedicated クラスターのサイズを調整します。これは、Kubernetes 形式の宣言引数を使用して、特定のクラウドプロバイダーのオブジェクトに依存しないインフラストラクチャー管理を提供します。Cluster Autoscaler には cluster スコープがあり、特定の namespace には関連付けられていません。

Cluster Autoscaler は、リソース不足のために現在のワーカーノードのいずれにもスケジュールできない Pod がある場合や、デプロイメントのニーズを満たすために別のノードが必要な場合に、クラスターのサイズを拡大します。Cluster Autoscaler は、指定の制限を超えてクラスターリソースを拡大することはありません。

Cluster Autoscaler は、コントロールプレーンノードを管理しない場合でも、クラスター内のすべてのノードのメモリー、CPU の合計を計算します。これらの値は、単一マシン指向ではありません。これらは、クラスター全体での全リソースの集約です。たとえば、最大メモリーリソースの制限を設定する場合、Cluster Autoscaler は現在のメモリー使用量を計算する際にクラスター内のすべてのノードを含めます。この計算は、Cluster Autoscaler にワーカーリソースを追加する容量があるかどうかを判別するために使用されます。

重要

作成する ClusterAutoscaler リソース定義の maxNodesTotal 値が、クラスター内のマシンの想定される合計数に対応するのに十分な大きさの値であることを確認します。この値は、コントロールプレーンマシンの数とスケーリングする可能性のあるコンピュートマシンの数に対応できる値である必要があります。

Cluster Autoscaler は 10 秒ごとに、クラスターで不要なノードをチェックし、それらを削除します。Cluster Autoscaler は、以下の条件が適用される場合に、ノードを削除すべきと考えます。

  • ノードの使用率はクラスターの ノード使用率レベル のしきい値 よりも低い場合。ノード使用率レベルとは、要求されたリソースの合計をノードに割り当てられたリソースで除算したものです。ClusterAutoscaler カスタムリソースで値を指定しない場合、Cluster Autoscaler は 50% の使用率に対応するデフォルト値 0.5 を使用します。
  • Cluster Autoscaler がノードで実行されているすべての Pod を他のノードに移動できる。Kubernetes スケジューラーは、ノード上の Pod のスケジュールを担当します。
  • Cluster Autoscaler で、スケールダウンが無効にされたアノテーションがない。

以下のタイプの Pod がノードにある場合、Cluster Autoscaler はそのノードを削除しません。

  • 制限のある Pod の Disruption Budget (停止状態の予算、PDB) を持つ Pod。
  • デフォルトでノードで実行されない Kube システム Pod。
  • PDB を持たないか、制限が厳しい PDB を持つ Kuber システム Pod。
  • デプロイメント、レプリカセット、またはステートフルセットなどのコントローラーオブジェクトによってサポートされない Pod。
  • ローカルストレージを持つ Pod。
  • リソース不足、互換性のないノードセレクターまたはアフィニティー、一致する非アフィニティーなどにより他の場所に移動できない Pod。
  • それらに "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" アノテーションがない場合、"cluster-autoscaler.kubernetes.io/safe-to-evict": "false" アノテーションを持つ Pod。

たとえば、CPU の上限を 64 コアに設定し、それぞれ 8 コアを持つマシンのみを作成するように Cluster Autoscaler を設定したとします。クラスターが 30 コアで起動する場合、Cluster Autoscaler は最大で 4 つのノード (合計 32 コア) を追加できます。この場合、総計は 62 コアになります。

Cluster Autoscaler を設定する場合、使用に関する追加の制限が適用されます。

  • 自動スケーリングされたノードグループにあるノードを直接変更しないようにしてください。同じノードグループ内のすべてのノードには同じ容量およびラベルがあり、同じシステム Pod を実行します。
  • Pod の要求を指定します。
  • Pod がすぐに削除されるのを防ぐ必要がある場合、適切な PDB を設定します。
  • クラウドプロバイダーのクォータが、設定する最大のノードプールに対応できる十分な大きさであることを確認します。
  • クラウドプロバイダーで提供されるものなどの、追加のノードグループの Autoscaler を実行しないようにしてください。

Horizontal Pod Autoscaler (HPA) および Cluster Autoscaler は複数の異なる方法でクラスターリソースを変更します。HPA は、現在の CPU 負荷に基づいてデプロイメント、またはレプリカセットのレプリカ数を変更します。負荷が増大すると、HPA はクラスターで利用できるリソース量に関係なく、新規レプリカを作成します。十分なリソースがない場合、Cluster Autoscaler はリソースを追加し、HPA で作成された Pod が実行できるようにします。負荷が減少する場合、HPA は一部のレプリカを停止します。この動作によって一部のノードの使用率が低くなるか、完全に空になる場合、Cluster Autoscaler は不必要なノードを削除します。

Cluster Autoscaler は Pod の優先順位を考慮に入れます。Pod の優先順位とプリエンプション機能により、クラスターに十分なリソースがない場合に優先順位に基づいて Pod のスケジューリングを有効にできますが、Cluster Autoscaler はクラスターがすべての Pod を実行するのに必要なリソースを確保できます。これら両方の機能の意図を反映するべく、Cluster Autoscaler には優先順位のカットオフ機能が含まれています。このカットオフを使用して Best Effort の Pod をスケジュールできますが、これにより Cluster Autoscaler がリソースを増やすことはなく、余分なリソースがある場合にのみ実行されます。

カットオフ値よりも低い優先順位を持つ Pod は、クラスターをスケールアップせず、クラスターのスケールダウンを防ぐこともありません。これらの Pod を実行するために新規ノードは追加されず、これらの Pod を実行しているノードはリソースを解放するために削除される可能性があります。

クラスターの自動スケーリングは、マシン API が利用可能なプラットフォームでサポートされています。

3.3.4. 関連情報

第4章 ロギング

4.1. OpenShift Dedicated クラスターのサービスログへのアクセス

Red Hat OpenShift Cluster Manager を使用して、OpenShift Dedicated クラスターのサービスログを表示できます。サービスログには、ロードバランサークォータの更新やスケジュールされたメンテナンスアップグレードなどの詳細なクラスターイベントが記録されます。ログには、ユーザー、グループ、および ID プロバイダーの追加または削除などのクラスターリソースの変更も表示されます。

さらに、OpenShift Dedicated クラスターの通知連絡先を追加できます。サブスクライブしたユーザーは、顧客の対応が必要なクラスターイベント、既知のクラスターインシデント、アップグレードのメンテナンス、およびその他のトピックに関するメールを受け取ります。

4.1.1. OpenShift Cluster Manager を使用したサービスログの表示

Red Hat OpenShift Cluster Manager を使用して、OpenShift Dedicated クラスターのサービスログを表示できます。

前提条件

  • OpenShift Dedicated クラスターをインストールしている。

手順

  1. OpenShift Cluster Manager に移動し、クラスターを選択します。
  2. クラスターの Overview ページで、Cluster history セクションのサービスログを表示します。
  3. オプション: ドロップダウンメニューから、Description または Severity でクラスターサービスのログをフィルタリングします。検索バーに特定の項目を入力して、さらにフィルタリングできます。
  4. オプション: Download history をクリックして、クラスターのサービスログを JSON または CSV 形式でダウンロードします。

4.1.2. クラスター通知連絡先の追加

OpenShift Dedicated クラスターに関する通知の連絡先を追加できます。クラスター通知メールをトリガーするイベントが発生すると、サブスクライブしているユーザーに通知が送信されます。

手順

  1. OpenShift Cluster Manager に移動し、クラスターを選択します。
  2. Notification contacts 見出しの Support タブで、Add notification contact をクリックします。
  3. 追加する連絡先の Red Hat ユーザー名またはメールアドレスを入力します。

    注記

    ユーザー名または電子メールアドレスは、クラスターがデプロイされている Red Hat 組織のユーザーアカウントに関連付けられている必要があります。

  4. Add contact をクリックします。

検証

  • 連絡先が正常に追加されると、確認メッセージが表示されます。ユーザーは、Support タブの Notification contacts 見出しの下に表示されます。

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.