クラスター管理


OpenShift Dedicated 4

OpenShift Dedicated クラスターの設定

Red Hat OpenShift Documentation Team

概要

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

第1章 クラスターの通知

クラスター通知は、クラスターのステータス、健全性、またはパフォーマンスに関するメッセージです。

クラスター通知は、Red Hat Site Reliability Engineering (SRE) が管理対象クラスターの健全性をユーザーに通知する際に使用する主な方法です。SRE は、クラスター通知を使用して、クラスターの問題を解決または防止するためのアクションを実行するように促すこともあります。

クラスターの所有者と管理者は、クラスターの健全性とサポート対象の状態を維持するために、クラスター通知を定期的に確認して対処する必要があります。

クラスターの通知は、Red Hat Hybrid Cloud Console のクラスターの Cluster history タブで表示できます。デフォルトでは、クラスターの所有者のみがクラスター通知をメールで受信します。他のユーザーがクラスター通知メールを受信する必要がある場合は、各ユーザーをクラスターの通知連絡先として追加します。

1.1. 関連情報

1.2. クラスター通知に期待できること

クラスター管理者は、クラスターの健全性と管理上のニーズを効果的に把握するために、クラスター通知が送信されるタイミングと理由、および通知の種類と重大度レベルを認識しておく必要があります。

1.2.1. クラスター通知ポリシー

クラスター通知は、クラスターの健全性とクラスターに大きな影響を与えるイベントに関する情報を常に提供できるように設計されています。

ほとんどのクラスター通知は、クラスターの問題や状態の重要な変更をすぐに通知するために、自動的に生成されて送信されます。

状況によっては、Red Hat Site Reliability Engineering (SRE) がクラスター通知を作成して送信し、複雑な問題に関する追加のコンテキストとガイダンスを提供します。

影響の少ないイベント、リスクの低いセキュリティー更新、日常的な運用とメンテナンス、または SRE によってすぐに解決される軽微で一時的な問題は、クラスター通知は送信されません。

次の場合、Red Hat サービスが自動的に通知を送信します。

  • リモートヘルスモニタリングまたは環境検証チェックにより、ワーカーノードのディスク領域不足など、クラスター内の問題が検出された場合。
  • 重要なクラスターライフサイクルイベントが発生した場合。たとえば、スケジュールされたメンテナンスまたはアップグレードの開始時や、クラスター操作がイベントの影響を受けたが、お客様による介入は必要ない場合などです。
  • クラスター管理に大きな変更が発生した場合。たとえば、クラスターの所有権または管理制御が 1 人のユーザーから別のユーザーに移行された場合などです。
  • クラスターのサブスクリプションが変更または更新された場合。たとえば、Red Hat がサブスクリプションの条件やクラスターで利用可能な機能を更新した場合などです。

SRE は次の場合に通知を作成して送信します。

  • インシデントにより、クラスターの可用性やパフォーマンスに影響を与えるデグレードや停止が発生した場合。たとえば、クラウドプロバイダーで地域的な停止が発生した場合などです。SRE は、インシデント解決の進行状況とインシデントが解決した時期を知らせる後続の通知を送信します。
  • クラスターで、セキュリティー脆弱性、セキュリティー侵害、または異常なアクティビティーが検出された場合。
  • お客様が行った変更によってクラスターが不安定になっているか、不安定になる可能性があることを Red Hat が検出した場合。
  • ワークロードがクラスターのパフォーマンス低下や不安定化を引き起こしていることを Red Hat が検出した場合。

1.2.2. クラスター通知の重大度レベル

各クラスター通知には重大度レベルが関連付けられています。これはビジネスに最も大きな影響を与える通知を識別するのに役立ちます。Red Hat Hybrid Cloud Console のクラスターの Cluster history タブで、この重大度レベルに基づいてクラスター通知をフィルタリングできます。

Red Hat は、クラスター通知に次の重大度レベルを使用します (重大度が最も高いものから最も低いものの順)。

Critical
直ちに対処する必要があります。サービスまたはクラスターの 1 つ以上の主要機能が動作していないか、まもなく動作しなくなります。Critical アラートは、待機中のスタッフに呼び出しをかけ、通常のワークフローを中断すべきほど重要なアラートです。
Major
直ちに対処することを強く推奨します。クラスターの 1 つ以上の主要機能がまもなく動作しなくなります。重大な問題は、速やかに対処しないと、重大な問題につながる可能性があります。
Warning
できるだけ早く対処する必要があります。クラスターの 1 つ以上の主要機能が最適に動作しておらず、さらにデグレードが発生する可能性があります。ただし、これはクラスターの機能に直ちに危険をもたらすものではありません。
Info
対処する必要はありません。この重大度は、対処する必要がある問題を示すものではありません。意味のある、または重要なライフサイクル、サービス、またはクラスターイベントに関する重要な情報のみを示します。
Debug
対処する必要はありません。Debug 通知は、予期しない動作のデバッグに役立つ、重要度の低いライフサイクル、サービス、またはクラスターイベントに関する低レベルの情報を提供します。

1.2.3. クラスター通知タイプ

各クラスター通知には通知タイプが関連付けられています。これは自分の役割や責任に関連する通知を識別できるように。Red Hat Hybrid Cloud Console のクラスターの Cluster history タブで、このタイプに基づいてクラスター通知をフィルタリングできます。

Red Hat は、通知の関連性を示すために次の通知タイプを使用します。

容量の管理
ノードプール、マシンプール、コンピュートレプリカ、またはクォータ (ロードバランサー、ストレージなど) の更新、作成、削除に関連するイベントの通知。
Cluster access
グループ、ロール、またはアイデンティティープロバイダーの追加または削除に関連するイベントの通知。たとえば、STS 認証情報の有効期限が切れているために SRE がクラスターにアクセスできない場合、AWS ロールの設定に問題がある場合、またはアイデンティティープロバイダーを追加または削除した場合などです。
Cluster add-ons
アドオンの管理またはアドオンのアップグレードメンテナンスに関連するイベントの通知。たとえば、アドオンがインストール、アップグレード、削除されたときや、要件が満たされていないためにアドオンをインストールできない場合などです。
Cluster configuration
クラスターチューニングイベント、ワークロード監視、およびインフライトチェックに関する通知。
Cluster lifecycle
クラスターまたはクラスターリソースの作成、削除、登録、またはクラスターまたはリソースのステータスの変更 (準備完了、休止状態など) に関する通知。
Cluster networking
HTTP/S プロキシー、ルーター、Ingress の状態など、クラスターネットワークに関連する通知。
Cluster ownership
クラスターの所有権がユーザー間で移動されることに関連する通知。
Cluster scaling
ノードプール、マシンプール、コンピュートレプリカ、またはクォータの更新、作成、または削除に関連する通知。
Cluster security
クラスターのセキュリティーに関連するイベント。たとえば、失敗したアクセス試行の増加、トラストバンドルの更新、セキュリティーに影響を与えるソフトウェアの更新などです。
Cluster subscription
クラスターの有効期限、試用版クラスターの通知、または無料から有料への切り替え。
Cluster updates
アップグレードのメンテナンスや有効化など、アップグレードに関連するすべてのもの。
Customer support
サポートケースのステータスの更新。
General notification
デフォルトの通知タイプ。これは、より具体的なカテゴリーがない通知にのみ使用されます。

1.3. Red Hat Hybrid Cloud Console を使用したクラスター通知の表示

クラスター通知は、クラスターの健全性に関する重要な情報を提供します。クラスターに送信された通知は、Red Hat Hybrid Cloud Console の Cluster history タブで表示できます。

前提条件

  • Hybrid Cloud Console にログインしている。

手順

  1. Hybrid Cloud Console の Clusters ページに移動します。
  2. クラスターの名前をクリックし、クラスターの詳細ページに移動します。
  3. Cluster history タブをクリックします。

    クラスター通知が Cluster history の見出しの下に表示されます。

  4. オプション: 関連するクラスター通知をフィルタリングします。

    専門分野や重要な問題の解決に集中できるように、フィルターコントロールを使用して、自分に関係のないクラスター通知を非表示にします。通知の説明のテキスト、重大度レベル、通知タイプ、通知の受信日時、通知をトリガーしたシステムまたはユーザーに基づいて通知をフィルタリングできます。

1.4. クラスター通知メール

デフォルトでは、クラスター通知がクラスターに送信されると、クラスター所有者にもメールとして送信されます。通知メールの受信者を追加設定することで、適切なユーザー全員にクラスターの状態に関する通知を届けることができます。

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

クラスター通知がクラスターに送信されると、通知連絡先にメールが送信されます。デフォルトでは、クラスターの所有者のみがクラスター通知をメールで受信します。クラスターサポート設定で、他のクラスターユーザーを追加の通知連絡先として設定できます。

前提条件

  • クラスターがデプロイされ、Red Hat Hybrid Cloud Console に登録されている。
  • クラスターの所有者または cluster editor ロールを持つユーザーとして、Hybrid Cloud Console にログインする。
  • 通知の対象となる受信者が、クラスター所有者と同じ組織に関連付けられた Red Hat カスタマーポータルアカウントを持っている。

手順

  1. Hybrid Cloud Console の Clusters ページに移動します。
  2. クラスターの名前をクリックし、クラスターの詳細ページに移動します。
  3. Support タブをクリックします。
  4. Support タブで、Notification contacts セクションを見つけます。
  5. Add notification contact をクリックします。
  6. Red Hat username or email フィールドに、新しい受信者のメールアドレスまたはユーザー名を入力します。
  7. Add contact をクリックします。

検証手順

  • "Notification contact added successfully" というメッセージが表示されます。

トラブルシューティング

Add notification contact ボタンが無効になっています
通知連絡先を追加する権限を持たないユーザーの場合、このボタンは無効になります。cluster owner、cluster editor、または cluster administrator のロールを持つアカウントにログインして、再試行してください。
エラー: Could not find any account identified by <username> または <email-address>
このエラーは、通知の受信者がクラスター所有者と同じ Red Hat アカウント組織に属していない場合に発生します。組織管理者に連絡して、対象の受信者を関連する組織に追加し、もう一度お試しください。

1.4.2. クラスターからの通知連絡先の削除

クラスター通知がクラスターに送信されると、通知連絡先にメールが送信されます。

クラスターサポート設定で通知連絡先を削除して、通知メールが届かないようにすることができます。

前提条件

  • クラスターがデプロイされ、Red Hat Hybrid Cloud Console に登録されている。
  • クラスターの所有者または cluster editor ロールを持つユーザーとして、Hybrid Cloud Console にログインする。

手順

  1. Hybrid Cloud Console の Clusters ページに移動します。
  2. クラスターの名前をクリックし、クラスターの詳細ページに移動します。
  3. Support タブをクリックします。
  4. Support タブで、Notification contacts セクションを見つけます。
  5. 削除する受信者の横にあるオプションメニュー () をクリックします。
  6. Delete をクリックします。

検証手順

  • "Notification contact deleted successfully" というメッセージが表示されます。

1.5. トラブルシューティング

クラスター通知メールが届かない場合

  • @redhat.com アドレスから送信されたメールがメールの受信トレイからフィルターで除外されていないことを確認します。
  • クラスターの通知連絡先として正しいメールアドレスがリストされていることを確認します。
  • クラスターの所有者または管理者に、お使いのメールアドレスを通知連絡先として追加するよう依頼します (Cluster notification emails を参照)。

クラスターに通知が届かない場合

  • クラスターが api.openshift.com のリソースにアクセスできることを確認します。
  • ファイアウォールが、ドキュメントの前提条件に従って設定されていることを確認します (AWS ファイアウォールの前提条件 を参照)。

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

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

2.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 を設定します。

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

2.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 user をクリックします。
    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 の下に表示されます。

2.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 ガイドを参照してください。

2.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 ガイドを参照してください。

2.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 ガイドを参照してください。

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

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

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

2.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 状態であるかを示します。

2.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 をクリックします。

    注記

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

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

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

手順

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

    注記

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

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

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

重要

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

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

3.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 を実行しないようにしてください。
注記

クラスターオートスケーラーは、スケジュール可能な Pod が作成される場合にのみ、自動スケーリングされたノードグループにノードを追加します。利用可能なノードタイプが Pod 要求の要件を満たすことができない場合、またはこれらの要件を満たすことができるノードグループが最大サイズに達している場合、クラスターオートスケーラーはスケールアップできません。

他のスケジュール機能との連携

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 を実行しているノードはリソースを解放するために削除される可能性があります。

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

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

手順

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

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

3.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 ボタンをクリックします。

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

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

3.4.1. 一般設定

表3.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

このオプションは、ノードグループの類似性を考慮するときにクラスターオートスケーラーが無視するラベルを指定します。このオプションにはスペースを使用できません。

array (string)

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

3.4.2. リソース制限

表3.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>" のコンマ区切りのリストである必要があります。

3.4.3. スケールダウン設定

表3.3 OpenShift Cluster Manager を使用する場合のクラスター自動スケーリングのスケールダウン設定を設定可能
設定説明型または範囲デフォルト

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

第4章 ノード

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

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

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

重要

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

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

4.1.1. マシン

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

4.1.2. マシンセット

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

4.1.3. マシンプール

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

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

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

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

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

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

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

4.1.4.1. マルチ AZ クラスター内の単一のアベイラビリティーゾーンにマシンプールをデプロイする

Google Cloud Platform (GCP) 上の OpenShift Dedicated ユーザーは、OpenShift Cluster Manager CLI (ocm) を使用して、マルチ AZ クラスターの一部である特定のアベイラビリティーゾーンに単一のマシンプールをデプロイできます。このオプションは、必要なインスタンスタイプが特定のリージョンのすべてのアベイラビリティーゾーンで使用できない場合や、クラスターに必要なインスタンスタイプが複数必要ない場合に特に役立ちます。

重要

マルチ AZ クラスターのプロビジョニング中に、デフォルトのマシンプールを単一のアベイラビリティーゾーンに割り当てることはできません。

重要

OpenShift Cluster Manager API コマンドラインインターフェイス (ocm) は、開発者プレビュー機能です。Red Hat 開発者プレビュー機能のサポート範囲の詳細は、開発者プレビューのサポート範囲 を参照してください。

手順

  • 次のコマンドを実行して、マシンプールを特定のアベイラビリティーゾーンにデプロイします。
ocm create machine-pool \
  --cluster <cluster_name|cluster_id> \ 1
  --instance-type <instance_type> \ 2
  --replicas <number_of_replicas> \ 3
  --availability-zone <availability_zone> \ 4
    [flags] \ 5
   <machine_pool_id> 6
1
<cluster_name|cluster_id> は、マシンプールを追加するクラスターの名前または ID に置き換えます。
2
<instance_type> は、単一のアベイラビリティーゾーンにデプロイするインスタンスタイプに置き換えます。
3
<replicas> は、マシンプールに含める選択したインスタンスタイプのレプリカの数に置き換えます。
4
<availability_zone> は、マシンプールを追加するアベイラビリティーゾーンに置き換えます。
5
オプション: [flags] は、マシンプールの作成に使用できる追加のフラグに置き換えます。
6
<machine_pool_id> は、マシンプールの ID に置き換えます。
注記

マシンプールの作成に使用できる追加のフラグを表示するには、ocm create machine-pool --help コマンドを実行します。

Google Cloud Platform (GCP) インスタンスタイプとアベイラビリティーゾーンの詳細は、関連情報 セクションを参照してください。

4.1.5. 関連情報

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

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

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

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

4.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 にそのグループを関連付けている必要があります。マシンプールの作成後は、セキュリティーグループを追加または編集することはできません。詳細は、「関連情報」セクションのセキュリティーグループの要件を参照してください。
  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 ページに表示され、設定が想定どおりに表示されていることを確認します。

4.2.2. マシンプールの削除

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

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

前提条件

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

手順

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

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

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

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

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

前提条件

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

手順

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

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

      注記

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

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

検証

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

4.2.4. ノードラベル

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

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

関連情報

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

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

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

前提条件

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

手順

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

検証

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

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

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

注記

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

前提条件

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

手順

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

検証

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

4.2.6. 関連情報

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

重要

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

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

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

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

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

注記

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

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

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

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

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

手順

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

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

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

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

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

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

手順

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

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

重要

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

4.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 を実行しないようにしてください。
注記

クラスターオートスケーラーは、スケジュール可能な Pod が作成される場合にのみ、自動スケーリングされたノードグループにノードを追加します。利用可能なノードタイプが Pod 要求の要件を満たすことができない場合、またはこれらの要件を満たすことができるノードグループが最大サイズに達している場合、クラスターオートスケーラーはスケールアップできません。

他のスケジュール機能との連携

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 を実行しているノードはリソースを解放するために削除される可能性があります。

4.3.4. 関連情報

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections 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.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.