Edge Volumes 用に Linux を準備する
この記事では、Azure Arc で有効な AKS、Edge Essentials、または Ubuntu を使用して Linux for Edge Volumes を準備する方法について説明します。
Note
サポートされている Linux カーネルの最小バージョンは 5.1 です。 現時点では、6.4 と 6.2 で既知の問題があります。
前提条件
Note
Azure Arc で有効な Azure コンテナー ストレージは、米国東部、米国東部 2、米国西部、米国西部 2、米国西部 3、北ヨーロッパ、西ヨーロッパのリージョンでのみ使用できます。
Azure Arc 拡張機能で有効な Azure コンテナー ストレージの以前のインスタンスをアンインストールする
2.1.0-preview より前のバージョンの Azure Arc で有効な Azure コンテナー ストレージを以前にインストールしていて、新しいバージョンをインストールするには、その以前のインスタンスをアンインストールする必要があります。 1.2.0-preview 以前のリリースをインストールした場合は、次の手順に沿ってください。 2.1.0-preview 以降のバージョンはアップグレード可能であり、このアンインストールは必要ありません。
拡張機能の古いバージョンを削除するには、拡張機能の古いバージョンへの参照を保持している Kubernetes リソースをクリーンアップする必要があります。 保留中のリソースにより、拡張機能のクリーンアップが遅れる場合があります。 これらのリソースをクリーンアップするには、少なくとも次の 2 つの方法があります。
kubectl delete <resource_type> <resource_name>を使用するか、リソースの作成に使用される YAML ファイルを "適用解除" します。 通常、削除する必要があるリソースは、ポッド、参照されている PVC、サブボリューム CRD (クラウド取り込みエッジ ボリュームが構成されている場合) です。 または、指定した順序で次のコマンドを使用して、以下の 4 つの YAML ファイルをkubectl delete -fに渡すことができます。 これらの変数は、実際の情報で更新する必要があります。YOUR_DEPLOYMENT_FILE_NAME_HERE: デプロイ ファイル名を追加します。 この記事の例では、使用されたファイル名はdeploymentExample.yamlでした。 複数のデプロイを作成した場合は、それぞれを個別の行で削除する必要があります。YOUR_PVC_FILE_NAME_HERE: 永続ボリューム要求ファイル名を追加します。 この記事の例では、クラウド取り込みエッジ ボリュームを使用した場合、使用されたファイル名はcloudIngestPVC.yamlでした。 ローカル共有エッジ ボリュームを使用した場合、使用されたファイル名はlocalSharedPVC.yamlでした。 複数の PVC を作成した場合は、それぞれを個別の行で削除する必要があります。YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE: Edge サブボリューム ファイル名を追加します。 この記事の例では、使用されたファイル名はedgeSubvolume.yamlでした。 複数のサブボリュームを作成した場合は、それぞれを個別の行で削除する必要があります。YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE: Edge ストレージ構成ファイル名をここに追加します。 この記事の例では、使用されたファイル名はedgeConfig.yamlでした。
kubectl delete -f "<YOUR_DEPLOYMENT_FILE_NAME_HERE.yaml>" kubectl delete -f "<YOUR_PVC_FILE_NAME_HERE.yaml>" kubectl delete -f "<YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE.yaml>" kubectl delete -f "<YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE.yaml>"前の手順でご自分のデプロイ、PVC、Edge サブボリューム、Edge ストレージ構成の各ファイルを削除した後、次のコマンドを使用して拡張機能をアンインストールできます。
YOUR_RESOURCE_GROUP_NAME_HERE、YOUR_CLUSTER_NAME_HERE、YOUR_EXTENSION_NAME_HEREは、それぞれ実際の情報に置き換えてください。az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
Arc 接続済み Kubernetes クラスター
この手順では、Arc 接続済み Kubernetes クラスターが既にあることを前提としています。 既存の Kubernetes クラスターを Azure Arc に接続するには、この手順を参照してください。
Azure Arc で有効な Azure コンテナー ストレージを使用する場合は、Azure IoT Operations 用にクラスターを作成する手順に従ってください。
単一ノードおよびマルチノード クラスター
単一ノード クラスターは、セットアップが簡単で、リソース要件が最小限であるため、通常は開発またはテストの目的で使用します。 このクラスターは、マルチノード セットアップの複雑さを伴うことなく開発者が 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 のストレージが必要です。