Linux を準備する
この記事では、Azure Arc によって有効にされる AKS、Edge Essentials、または Ubuntu を使用して Linux を準備する方法について説明します。
Note
サポートされている Linux カーネルの最小バージョンは 5.1 です。 現時点では、6.4 と 6.2 で既知の問題があります。
前提条件
Note
Azure Arc によって有効化された Azure コンテナー ストレージは、米国東部、米国東部 2、米国西部、米国西部 2、米国西部 3、北ヨーロッパ、西ヨーロッパのリージョンでのみ使用できます。
Arc 接続済み Kubernetes クラスター
この手順では、Arc 接続済み Kubernetes クラスターが既にあることを前提としています。 既存の Kubernetes クラスターを Azure Arc に接続するには、この手順を参照してください。
Azure Arc によって有効化された Azure コンテナー ストレージを使用する場合は、Azure IoT Operations 用にクラスターを作成する手順に従ってください。
追加のストレージ用に 3 つの SSD が接続されている Standard D8s v3 マシンでは、Ubuntu 22.04 を使用します。
単一ノードおよびマルチノード クラスター
単一ノード クラスターは、セットアップが簡単で、リソース要件が最小限であるため、通常は開発またはテストの目的で使用します。 このクラスターは、マルチノード セットアップの複雑さを伴うことなく開発者が Kubernetes で試行するための、軽量で簡単な環境を提供します。 さらに、CPU、メモリ、ストレージなどのリソースが限られている状況では、単一ノード クラスターの方が実用的です。 セットアップが簡単で、リソース要件も最小限であるため、リソースに制約がある環境では適切な選択となります。
ただし、単一ノード クラスターには制限があり、その大部分は機能の不足に関するものです。例えば、高可用性、フォールト トレランス、スケーラビリティ、パフォーマンスが欠けています。
マルチノード Kubernetes 構成は、高可用性、フォールト トレランス、スケーラビリティ、パフォーマンスなどの機能があるため、通常、運用、ステージング、または大規模なシナリオで使用されます。 マルチノード クラスターには、複雑さ、オーバーヘッド、コスト、効率に関する考慮事項など、課題やトレードオフも伴います。 たとえば、マルチノード クラスターを設定して維持するには、追加の知識、スキル、ツール、リソース (ネットワーク、ストレージ、コンピューティング) が必要です。 クラスターはノード間の調整と通信を処理する必要があるため、待ち時間やエラーが発生する可能性があります。 さらに、マルチノード クラスターの実行では、単一ノード クラスターの場合よりも多くのリソースを消費し、コストが高くなります。 クラスターとアプリケーションの効率とパフォーマンスを維持するためには、ノード間でリソース使用量の最適化を図ることが不可欠です。
要約すると、単一ノード Kubernetes クラスターは、開発、テスト、リソースに制約のある環境に適している可能性があります。 マルチノード クラスターは、運用環境のデプロイ、高可用性、スケーラビリティ、分散型アプリケーションが要件となるシナリオに適しています。 この選択は、最終的に、デプロイの特定のニーズと目標に応じて決まります。
最小ハードウェア要件
単一ノードまたは 2 ノード クラスター
- Standard_D8ds_v5 VM を推奨
- ノードあたり、次と同等の仕様:
- 4 個の CPU
- 16 GB RAM
マルチノード クラスター
- Standard_D8as_v5 VM を推奨
- ノードあたり、次と同等の仕様:
- 8 個の CPU
- 32 GB RAM
32 GB の RAM はバッファーとして機能します。ただし、16 GB の RAM で十分です。 Edge Essentials の構成では、ノードあたり 8 個の CPU と 10 GB の RAM が必要であり、最小要件は 16 GB の RAM となります。
最小ストレージ要件
エッジ ボリュームの要件
フォールト トレラント ストレージ オプションを使用すると、エッジ ボリュームは、クラスター内の各ノードによってエクスポートされたストレージで構成されるフォールト トレラント ストレージ プールからディスク領域を割り当てます。
ストレージ プールは、フォールト トレランスを確保するために 3 方向レプリケーションを使用するように構成されています。 エッジ ボリュームがプロビジョニングされると、ストレージ プールからディスク領域が割り当てられ、レプリカの 3 にストレージが割り当てられます。
たとえば、ノードあたり 20 GB のディスク領域がある 3 ノード クラスターの場合、クラスターには 60 GB のストレージ プールがあります。 ただし、レプリケーションがあるため、有効なストレージ サイズは 20 GB です。
エッジ ボリュームが要求された 10 GB のサイズでプロビジョニングされると、予約済みシステム ボリューム (静的に 1 GB というサイズ設定) とデータ ボリューム (要求されたボリューム サイズ、たとえば 10 GB というサイズ設定) が割り当てられます。 予約済みシステム ボリュームはストレージ プール内の 3 GB (3 x 1 GB) のディスク領域を消費し、データ ボリュームはストレージ プール内の 30 GB (3 x 10 GB) のディスク領域を消費するため、合計 33 GB になります。
キャッシュ ボリュームの要件
キャッシュ ボリュームには、ノードごとに少なくとも 4 GB のストレージが必要です。 たとえば、3 ノード クラスターがある場合は、少なくとも 12 GB のストレージが必要です。
次のステップ
Linux の準備を続けるには、単一ノードまたはマルチノード クラスター用の次の手順を参照してください。