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

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

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

• 複数のクラスター ：複数のクラスターは一般的に管理が複雑になるが、以下のような重要な目標を達成するのに役立つ。

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

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

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

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

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

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

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

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

VPC クラスター

ワーカーノードは、標準インフラストラクチャまたは専用ホスト上の仮想ワーカーノードを使用してプロビジョニングできます。 スピードを重視するなら、VPCクラスタが最適かもしれない。

Satellite クラスター

ワーカーノードは、AWS、Azure、GCP などのクラウドプロバイダーの仮想マシン上にプロビジョニングできます。 ワーカーノードは、オンプレミスのインフラを使用してプロビジョニングすることもできます。

クラシック・クラスター

ワーカーノードは、仮想ワーカーノードとベアメタルワーカーノードに作成できます。 追加のローカル・ディスクが必要な場合は、Portworx などのソフトウェア定義ストレージ・ソリューション用に設計されたベアメタル・フレーバーのいずれかを選択することもできます。

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

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

Ubuntu 24

詳しくは、 Ubuntu 24.04 リリースノートをご覧ください。 Ubuntu 24では、NTPは timesyncd 、関連コマンドが更新される可能性があることに注意。

新しいOSへの移行？ 新しいUbuntuバージョンへの移行 を参照してください。

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

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

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

クラスターにセットアップする可用性のレベルは、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 営業日以上かかる場合があります。

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

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

    通常、以下の場合に SDS マシンを使用します。

    • などのSDSアドオンを使用する場合は、SDSマシンを使用する。 Portworx SDSマシンを使用してください。
    • アプリケーションが StatefulSet アプリがローカルストレージを必要とする場合、SDS マシンを使用し、 Kubernetes ローカル永続ボリュームをプロビジョニングすることができる。
    • ローカルの追加のロー・ストレージを必要とするカスタム・アプリがある場合。

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

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

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

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

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

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

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

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

利用可能なフレーバーのリストについては、VPC Gen 2 flavors または Classic flavors を参照してください。

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

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

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

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

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

• サービスの選択：いくつのクラスタを作るかを考えたとき、いくつのサービス統合を含めることにしましたか？ これらの統合サービスとアドオンは、クラスタリソースを消費して影響を与えるポッドをスピンアップできます。

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

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

  予約済み容量と予約済みインスタンスはサポートされません。

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

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

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

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

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

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

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

アプリも高可用性に

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

次のステップ

クイズで知識を試してみましょう。

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