作成するクラスタの数を決める

アプリを複数のワーカー・ノード、ゾーン、クラスターに分散させると、ユーザーがダウン時間を経験する可能性が低くなります。 ロード・バランシングや負荷の分離などの組み込み機能により、ホスト、ネットワーク、アプリで想定される障害に対する回復力を強化できます。

作成するクラスタの数は、ワークロード、会社のポリシーと規制、ビジネス要件、顧客とのサービス・レベル・アグリーメント、消費するリソース、およびコンピューティング・リソースで何をしたいかによって決まります。

• 複数のクラスター ：複数のクラスターの管理は一般的に複雑ですが、次のような重要な目標の達成に役立ちます。

  • ワークロードの分離を求めるセキュリティー・ポリシーに準拠する。
  • 異なるバージョンの Red Hat OpenShift や Calico などの他のクラスター・ソフトウェアで、アプリがどのように実行されるかをテストする。
  • 地理的に異なる地域のユーザーに対して、より高いパフォーマンスを実現。
  • ネームスペース・レベルで複数のRBACポリシーをカスタマイズして管理する代わりに、クラスタ・インスタンス・レベルでアクセスを構成することで、クラスタ内のアクセスを制御するユーザー・アクセスを簡素化します。
  • ワーカーノードの数を少なくする。 仮想マシンをスケーリングする際のネットワーク帯域幅は約1000Mbpsです。 クラスタ内に数百台のワーカーノードが必要な場合は、構成をノード数の少ない複数のクラスタに分割するか、ベアメタルノードを注文することができます。
  • 5,000以上のサービスなど、より多くの サービス統合 を許可します。
  • アプリに高い可用性を提供する。 マルチゾーンクラスターで 3 つのゾーンを使用する場合と同様に、ゾーンをまたいで 3 つのクラスターを構成することで、アプリケーションの可用性を高めることができます。
  • 作業量に見合った小型の機械を購入することで、コストを削減しましょう。

• より多くのワーカーノードを持つ1つのクラスタ：クラスタの数を少なくすることで、運用の手間と固定リソースのクラスタあたりのコストを削減できます。 クラスタを増やす代わりに、ワーカー・プールを1つのクラスタに追加して、アプリやサービス・コンポーネントで利用可能なさまざまな種類のコンピューティング・リソースを利用できます。 アプリを開発する際は、そのアプリで使用されるリソースは同じゾーン内にあるか、そうでない場合はマルチゾーン内で緊密に接続されているため、待ち時間、帯域幅、または相関関係のある複数の障害に関して推測できます。 ただし、クラスターが1つしかない場合は、ネームスペース、リソースクォータ、ラベルを使用してクラスターを整理することが、さらに重要になります。

必要なロケーション数を決定する

クラスタは、単一の場所にあるワーカーノードにレプリカを分散させることも、複数の場所に分散させることもできる。 この選択は、次のセクションで利用可能なクラスタ・タイプに影響を与える可能性があります。

ワークロードを 3 つのゾーン間に分散させることで、1 つまたは 2 つのゾーンが使用不可になっても対応できるアプリの高可用性を確保できます。 HA 構成のIBM Cloudサービス・レベル・アグリーメント (SLA) を満たすため、3 つのアベイラビリティー・ゾーンすべてに均等にワーカー・ノードを分散させる必要があります。

ゾーンの障害は、すべての物理コンピュート・ホストおよび NFS ストレージに影響します。 この障害には、電力、冷却、ネットワーキング、ストレージの故障と自然災害 (洪水、地震、ハリケーンなど) が含まれます。 ゾーンの障害から保護するためには、外部のロードバランサによって負荷分散された2つの異なるゾーンにクラスタを持つか、マスターをゾーンに分散させるマルチゾーンにクラスタを作成するか、別のゾーンに2つ目のクラスタを設定することを検討する必要があります。

クラスタタイプを選択する

使用可能なワーカー・ノード・フレーバーと分離レベルは、コンテナー・プラットフォーム、クラスター・タイプ、使用するインフラストラクチャー・プロバイダー、およびクラスターを作成する Red Hat OpenShift on IBM Cloud のロケーションによって異なります。 クラスターはClassic、VPC、Satelliteから選択できます。 必要なクラスタの種類は、クラスタの数や配置場所について下した決定によって決まります。

VPC クラスター（推奨）

ワーカーノードは、VPCインフラストラクチャ上で仮想サーバーインスタンスとしてプロビジョニングされます。 VPCは、新しいクラスターに推奨されるインフラストラクチャの種類です。 デフォルトでネットワークの分離機能を提供し、専用ホストや「デフォルトでのセキュリティ確保」など、 Red Hat OpenShift on IBM Cloud の最新機能をサポートしています。

Satellite クラスター

ワーカーノードは、オンプレミスのハードウェアや、 AWS、 Azure、 GCP などの他のクラウドプロバイダー上の仮想マシンなど、お客様自身のインフラストラクチャ上にプロビジョニングされます。 IBM Cloud のデータセンター外で、 IBM Cloud が管理するクラスターを実行する必要がある場合は、 Satellite をご利用ください。

クラシック・クラスター

ワーカーノードは、 IBM Cloud クラシック・インフラストラクチャー上の仮想マシンまたはベアメタルマシンにプロビジョニングされます。 ベアメタルのワーカーノード、ソフトウェア定義ストレージ（SDS）のフレーバー、または既存のクラシック・インフラストラクチャーへの接続が必要な場合は、「Classic」をご利用ください。

クラスタ用のオペレーティング・システムを選択する

利用可能なオペレーティング・システムは、選択したクラスタ・タイプによって異なります。

Red Hat Enterprise Linux CoreOS (RHCOS)

VPC Satellite

バージョン4.15以降で作成されたクラスタで利用可能です。 Red Hat Enterprise Linux CoreOS (RHCOS）は、 Red Hat OpenShift Container Platform （OCP）のために特別に設計されている。 Red Hat Enterprise Linux (RHEL)の安定性とセキュリティを活用しつつ、RHCOSは軽量かつ最小限の構成で、コンテナ化されたワークロードを効率的かつ大規模に実行することに重点を置いている。 RHELのコンポーネントで構成されているため、RHELと同レベルのセキュリティに加え、より最小限のコンテナ中心のフットプリント、読み取り専用ファイルシステム、イメージベースのデプロイメントなどが追加されている。 RHCOSの概要については、 Red Hat Enterprise Linux CoreOS （RHCOS ）を参照。 VPCクラスタ用のRHCOSワーカーノードは、RHCOSをサポートするバージョンで作成されたクラスタでのみ利用可能です。 RHCOSをサポートしていないバージョンからサポートしているバージョンにアップグレードされたクラスタは、RHCOSワーカーを使用できません。

バージョン 4.18 以降、RHEL ワーカーノードは VPC クラスタでは非推奨です。 バージョン 4.22 は、VPC上のRHELワーカーノードをサポートする最後のバージョンです。 今後のバージョンでは、RHCOS ワーカーノードが必要となります。 詳細については、 VPCクラスタのRHEL非推奨を 参照してください。

Red Hat Enterprise Linux (RHEL) バージョン 9

クラシック VPC

バージョン 4.16 以降で作成されたクラスタで利用可能です。 Red Hat Enterprise Linux on IBM Cloud は、セキュリティを念頭に構築され、クリティカルなワークロード向けに調整された、堅牢でスケーラブルな環境を企業に提供します。 組織は、 Red Hat Enterprise Linux プラットフォームと IBM Cloud のインフラを結合することで、高可用性、ディザスタリカバリ、合理化された管理機能を利用できるようになる。 RHEL 9の概要については、 なぜ IBM Cloud で Linux を実行するのか？ を参照。

Red Hat Enterprise Linux (RHEL) バージョン 8

クラシック VPC

4.15 以前のバージョンで作成されたクラスタで使用できます。 RHEL 8は2024年5月31日に寿命を迎えた。 詳しくは、 Red Hat Enterprise Linux 8 ライフサイクルを参照。

クラスタの命名戦略を定義する

名前の競合を回避するために、アカウント内のリソース・グループおよびリージョン全体で固有の名前をクラスターに付けることを検討してください。 クラスタ作成後にクラスタの名前を変更することはできません。

各クラスタのワーカーノード数を決める

クラスターにセットアップする可用性のレベルは、IBM Cloud HA サービス・レベル・アグリーメントのご利用条件の実現可能なレベルに影響を与えます。 例えば、SLA の条件に基づいて HA の範囲を完全にカバーするには、合計 6 つ以上のワーカー・ノードを持つ複数ゾーン・クラスターをセットアップする必要があります。各ゾーンに 2 つのワーカー・ノードがあり、それらは 3 つのゾーンに均等に分散されます。

クラスター内のワーカー・ノードの総数によって、クラスター内のアプリで使用可能なコンピュート容量が決まります。 クラスタ内に複数のワーカーノードを設定することで、ワーカーノードに障害が発生した場合でも、環境を保護することができます。 ワーカーノードの障害には、電源、冷却、ネットワークなどのハードウェアの障害や、 VM 自体に起因する問題などが含まれます。

• マルチゾーンクラスタ Classic VPC ：ゾーンごとに少なくとも2つのワーカーノードを確保するように計画してください。つまり、3つのゾーンにまたがって合計6つのノードとなります。 さらに、クラスターの合計容量が、必要な合計ワークロード容量の 150% 以上になるように計画します。そうすることで、1 つのゾーンがダウンした場合でも、ワークロードを維持するためのリソースが使用可能になります。

• シングルゾーンクラスタ ：クラスタには、少なくとも3つのワーカーノードを配置するように計画してください。 さらに、余分の 1 ノード分の CPU とメモリーの容量をクラスター内に確保することをお勧めします。 アプリに必要なリソースが、ワーカーノードで利用可能なリソースよりも少ない場合は、1つのワーカーノードにデプロイするポッドの数を制限できる可能性があります。

以下の点に注意してください。

• cluster autoscaler を試してみて、ワークロードをカバーするのに十分なワーカーノードが常にあることを確認してください。
• Kubernetes では、1 つのクラスター内に作成できるワーカー・ノードの最大数に制限があります。 詳細については、「 ワーカーノードおよびポッドのクォータ 」を参照してください。

ワーカーノードのフレーバーを選択

ワーカーノードとは、物理ハードウェア上で動作する VM のことです。 ワーカー・ノード・フレーバーとは、ワーカー・ノードをプロビジョンした場合に得られるコンピュート・リソース (CPU、メモリー、ディスク容量など) を表すものです。 同じフレーバーのワーカー・ノードは、ワーカー・ノード・プールを分けてグループ化します。

クラスタタイプを選択する際に、ワーカーノードのフレーバーの場所とマシンのタイプが決定にどのような影響を与えるかをすでに考えていたはずです。 ワーカーノードのフレーバーを選択する際には、以下を考慮してください。

• テナント：必要なハードウェア分離のレベルに応じて、仮想ワーカー ノードを複数のIBM カスタマーが共有するノード (マルチ テナンシー) またはユーザー専用のノード (シングル テナンシー) として設定できます。 ベアメタルマシンは常に専用機としてセットアップされる。 共有ノードと専用ノードのどちらを採用するかを決める際には、アプリ環境に求められるインフラの分離レベルやコンプライアンス要件について、法務部門に相談することをお勧めします。

  • 共有 ：CPU やメモリなどの物理リソースは、同じ物理ハードウェアに展開されたすべての仮想マシン間で共有されます。 各仮想マシンが独立して実行できるようにするため、仮想マシン・モニター (ハイパーバイザーとも呼ばれる) が物理リソースを個別のエンティティーにセグメント化し、それらを専用リソースとして仮想マシンに割り振ります (ハイパーバイザー分離)。 共有ノードは通常、専用ノードよりも安価です。基盤となるハードウェアのコストを複数のお客様が共同で分担するからです。
  • 専用：すべての物理リソースはお客様専用です。 同じ物理ホスト上に複数のワーカー・ノードを仮想マシンとしてデプロイできます。 マルチテナント・セットアップと同様、各ワーカー・ノードには、使用可能な物理リソースがハイパーバイザーによって割り振られます。

• マシンの種類：マシンの種類はいくつかあり、その中から選ぶことができます。

  • 仮想マシン：より高い柔軟性、より迅速なプロビジョニング時間、より自動的なスケーラビリティ機能、およびより費用対効果の高い価格を実現するには、VM を使用します。 テスト環境と開発環境、ステージング環境と実稼働環境、マイクロサービス、ビジネス・アプリなど、ほとんどの汎用ユース・ケースに VM を使用できます。 ただし、パフォーマンス面でのトレードオフがあります。

  • ベアメタル（物理）マシン ：データやRAMを大量に消費するワークロード向けに高性能なコンピューティングが必要な場合は、ベアメタルのワーカーノードを使用してクラスタを構築することを検討してください。 ワークロードの分離とリソース使用量を完全に制御できるため、ベアメタル・マシンを使用して、ご使用の環境に対する HIPAA および PCI のコンプライアンスを実現できます。 ベア・メタルを使用すると、メモリーや CPU など、マシン上の物理リソースに直接アクセスできます。 このセットアップには、ホスト上で稼働する仮想マシンに物理リソースを割り振る仮想マシン・ハイパーバイザーは含まれません。 代わりに、ベア・メタル・マシンのすべてのリソースはワーカー専用であるため、リソースを共有したりパフォーマンスを低下させたりする「うるさい隣人」について心配する必要はありません。 物理フレーバーは、ローカル・ストレージが仮想マシン・タイプより大きく、一部のタイプはデータの可用性を向上させるための RAID を備えています。 ワーカーノード上のローカルストレージは短期的な処理専用であり、ワーカーノードを更新または再読み込みすると、プライマリディスクと補助ディスクのデータは消去されます。 ベアメタルワーカーは、従来のクラスターおよびVPCベアメタル構成で利用可能です。

    ベアメタルワーカーノードの課金方法は、インフラストラクチャの種類によって異なります。 従来のベアメタルサーバーは、毎月請求されます。 クラシック・ベアメタル・サーバーを月末より前に解約した場合、その月の月末まで料金が請求されます。 クラシック・ベアメタル・サーバーのご注文またはキャンセル後、 IBM Cloud アカウントにて手動で処理が行われるため、完了までに1営業日以上かかる場合があります。 VPCのベアメタルサーバーは、最低利用期間の制限なく、時間単位で課金されます。

  • SDS マシン: ソフトウェア定義ストレージ (SDS) フレーバーには、物理ローカル ストレージ用に追加の raw ディスクがあります。 プライマリおよび補助ローカルディスクとは異なり、これらの生ディスクは、ワーカーノードの更新や再読み込みの際にも消去されません。 データはコンピュート・ノードと同じ場所に配置されるため、SDS マシンはハイパフォーマンス・ワークロードに適しています。 ソフトウェア定義のストレージ・フレーバーはクラシック・クラスターでのみ使用可能であり、VPC クラスターではサポートされません。

    ワークロードの分離とリソース使用量を完全に制御できるため、SDS マシンを使用して、ご使用の環境に対する HIPAA および PCI のコンプライアンスを実現できます。

    通常、以下の場合に SDS マシンを使用します。 * 次のようなSDSアドオンを使用する場合は Portworx SDSアドオンを使用する場合は、SDSマシンをご利用ください。 * アプリが StatefulSet ローカルストレージを必要とするアプリである場合、SDSマシンを使用し、 Kubernetes のローカル永続ボリュームをプロビジョニングできます。 * ローカルの追加のロー・ストレージを必要とするカスタム・アプリがある場合。

• コスト ：一般的に、負荷の高いワークロードはベアメタルの物理マシンで実行するのが適していますが、コスト効率の高いテストや開発作業には、共有または専用ハードウェア上の仮想マシンを選択するとよいでしょう。

• 場所：クラスターを設置する場所を決めます。 必要なクラスター数やクラスターの種類は、どこに置くかによって決まる。 例えば、モントリオールにあることが必要だとわかっていれば、選択肢を絞るのに役立ちます。 利用可能な ロケーション をチェックしてください。

• 規模 ：特に、高性能マシンで処理することで効率が向上するように設計されたワークロードの場合、大規模なノードの方が小規模なノードよりもコスト効率に優れることがあります。 ただし、大規模なワーカーノードがダウンした場合、クラスター内に十分な処理能力があり、すべてのワークロードポッドをクラスター内の他のワーカーノードに安全に再スケジューリングできることを確認しておく必要があります。 小規模なワーカーノードは、安全なスケーリングに役立ちます。 容量について詳しくはこちら。

• GPU：AI、機械学習、推論など、計算集約型のワークロードに必要な処理時間を高速化するためにGPUマシンを使用できます。

• ストレージ ：すべての VM には、OSファイルシステム、コンテナランタイム、 kubelet など、 VM の稼働に必要な情報を保存するためのディスクが付属しています。 ワーカー・ノード上のローカル・ストレージは短期処理専用であり、ワーカー・ノードを削除、再ロード、置換、または更新すると、ストレージ・ディスクはワイプされます。 また、クラシック・インフラストラクチャーと VPC インフラストラクチャーでは、ディスクのセットアップ構造が異なります。

  • クラシック VM: クラシック VM には 2 つのディスクが接続されています。 プライマリストレージディスクにはOSのファイルシステム用に25 GBが割り当てられており、補助ストレージディスクにはコンテナランタイムや kubelet などのデータ用に100 GBが割り当てられています。 信頼性を確保するため、プライマリおよび補助ストレージボリュームには、ストレージエリアネットワーク（SAN）ではなくローカルディスクが使用されています。 信頼性が高いと、ローカル・ディスクへのバイトのシリアライズ時のスループットが向上し、ネットワーク障害が原因のファイル・システムのパフォーマンス低下が軽減されます。 補助ディスクはデフォルトで暗号化されています。
  • VPC コンピュート VM: VPC VM には、ネットワーク経由で接続されるブロック・ストレージ・ボリュームである 1 次ディスクが 1 つあります。 ストレージ層は他のネットワーク層から分離されず、ネットワークとストレージの両方のトラフィックが同じネットワーク上でルーティングされます。 1 次ストレージ・ディスクは、OS ファイル・システム、コンテナー・ランタイム、kubelet などのデータを保管するために使用され、 デフォルトで暗号化されます。 VPCクラスタでは、ワーカーノードにセカンダリディスクをプロビジョニングすることもできます。 このオプションディスクはお客様のアカウントにプロビジョニングされており、VPCコンソールで確認できます。 これらのディスクの料金は、各作業員の費用とは別であり、請求書には別の項目として表示されます。 これらの二次ボリュームも、 アカウントのクォータ使用量に算入されます。 デフォルトでのポッドの強制終了を防ぐため、 Kubernetes のデータディスク（Classic環境では補助ディスク、VPC環境ではプライマリブートディスク）の10%が、システムコンポーネント用に確保されています。

  ステートフルなアプリでは、データが、アプリを稼働状態に保つために重要な役割を果たします。 潜在的な障害からリカバリーできるように、データの可用性は必ず高くなるようにしてください。 Red Hat OpenShift on IBM Cloud では、データを保持する方法を複数の選択肢から選択できます。 例えば、Kubernetes ネイティブ永続ボリュームを使用して NFS ストレージをプロビジョンしたり、IBM Cloud データベース・サービスを使用してデータを保管したりできます。 詳細については、「 高可用性データの計画 」を参照してください。

  ワークロードに対応できる適切なストレージ構成を備えたフレーバー、またはマシンタイプを選択してください。 一部のフレーバーは、以下のようなディスクとストレージ構成の混合になっています。 例えば、一部のフレーバーにはロー SSD 2 次ディスクを持つ SATA 1 次ディスクがあるなどです。

利用可能なフレーバーのリストについては、 VPCフレーバー または クラシック・フレーバーを 参照のこと。

リソースのワーカーノード容量を決定する

ワーカーノードの性能を最大限に引き出すには、リソースをセットアップする際に以下を考慮してください：

• Consider what your app is doing: 利用可能なワーカー ノード フレーバーの 1 つの容量にアプリのサイズを合わせることから始めます。 また、アプリが大容量の画像や多数の画像を取得するかどうかといった点も考慮してください。これらはワーカーノードのローカルストレージを占有する可能性があるためです。

• コアの強度を維持する: 各マシンは特定数のコアを備えています。 アプリのワークロードに応じて、コアあたりのポッド数の上限 (10 など) を設定します。

• ノードの過負荷を避ける ：スケジューリングが必要になる可能性のある他のポッドのための余裕を確保するため、ワーカーノードの使用率を75%程度に抑えてください。 アプリで必要なリソースが、ワーカー・ノード上で使用可能なリソースより多い場合は、これらの要件を満たすことができる異なるワーカー・ノード・フレーバーを使用してください。 アプリのワークロードに応じて、ノードあたりのポッド数の上限 (40 など) を設定します。

• サービスの選択：いくつのクラスタを作るかを考えたとき、いくつのサービス統合を含めることにしましたか？ これらの統合サービスやアドオンは、クラスターのリソースを消費し、そのリソースに影響を与えるポッドを起動する可能性があります。

• アプリのレプリカ: 必要となるワーカー・ノードの数を決定するために、実行するアプリ・レプリカの数を検討することもできます。 例えば、ワークロードで 32 基の CPU コアが必要となることがわかっており、16 個のアプリ・レプリカを実行することを計画している場合は、各レプリカ・ポッドに 2 基の CPU コアが必要となります。 ワーカー・ノードあたり 1 つのアプリ・ポッドのみを実行する場合は、使用するクラスター・タイプでこの構成をサポートするための適切な数のワーカー・ノードを注文できます。

• ランタイム要件に余裕を持たせる：ワーカー ノードは、オペレーティング システムやコンテナー ランタイムなどの必要なコンポーネントを実行するために、一定量の CPU およびメモリ リソース を確保する必要があります。

  予約容量および予約インスタンスは サポートされていません。

クラスタ内に作成するネームスペースの数を選択する

クラスターを共有している複数のチームとプロジェクトがある場合は、複数の名前空間をセットアップする 名前空間は、リソース割り当てと デフォルト制限を使用してクラスタリソースを分割する方法です。 新しい名前空間を作成するときには、アクセスを制御するために、必ず、適切な RBAC ポリシーをセットアップしてください。 詳細については、『 Kubernetes 』のドキュメントにある「 ネームスペースを使用したクラスタの共有」を参照してください。

クラスターが小規模で、ユーザーが数十人、かつリソースが類似している (同じソフトウェアのバージョン違いなど) 場合は、複数の名前空間は必要ない可能性があります。 代わりに、ラベルを使用することで対応できます。

この決定に関するセキュリティ情報を コンテナの分離とセキュリティ で確認してください。

ネームスペースのリソース要求と制限を確立する

すべてのチームが、クラスター内でサービスをデプロイし、アプリケーションを実行するために必要なリソースを確保できるようにするには、すべてのネームスペース に対してリソースクォータを設定する必要があります。 リソースのクォータによって、デプロイ可能な Kubernetes リソースの数や、それらのリソースが消費できるCPUおよびメモリの量など、デプロイに関する制約が決定されます。 割り当て量を設定すると、ユーザーは、そのデプロイメントにリソース要求と制限を含める必要があります。

デプロイメントを作成する際は、アプリ用のPodが、リソースの組み合わせが最適なマシンにのみデプロイされるように制限してください。 例えば、md1c.28x512.4x4tb のように大容量のローカル・ディスク・ストレージを備えたベアメタル・マシンにのみ、データベース・アプリケーションがデプロイされるように制限することをお勧めします。

アプリも高可用性に

設計上、コンテナーやポッドの存続期間は短く、予期せぬ障害が起こることがあります。 例えば、アプリでエラーが発生した場合、コンテナーやポッドが異常終了する可能性があります。 アプリの高可用性を確保するには、ワークロードを処理するのに十分なインスタンスに加え、障害発生時に備えて予備のインスタンスも用意しておく必要があります。 十分なインスタンスを確保するには、自動スケーリング を設定します。

現在実施されているベストプラクティス

クラスターが稼働し始めたら、セキュリティと正常な稼働状態を維持するために、以下のベストプラクティスに従ってください。

次のステップ

計画プロセスを続行するには、VPCクラスタ ネットワーキング と クラシック クラスタ ネットワーキング のいずれかを選択します。 クラスタの作成を始める準備ができたら、まず クラスタを作成するためのアカウントを準備する ことから始めます。