Azure Kubernetes Service を使用するタイミング

完了

ここでは、Azure Kubernetes Service (AKS) が最適な選択であるかどうかを判断できます。

"未開発" または "リフトアンドシフト" のプロジェクトの観点から決定に取り組みます。 未開発プロジェクトでは、既定の機能に基づいて AKS を評価できます。 リフトアンドシフト プロジェクトでは、移行をサポートするために最適な機能の確認が強制されます。

先ほど、Azure を介した DevOps 機能に対する AKS のサポートについて説明しました。 ここでは、AKS Kubernetes オファリングを強化するために検討すべき Azure リソースを示します。 これらの機能はそれぞれ、お客様が AKS を選ぶ理由に対する説得力のある要因を表しています。

サービス 考慮事項
ID とセキュリティ管理 既に既存の Azure リソースを使用しており、Microsoft Entra ID を利用していますか。 Microsoft Entra ID と統合し、既存の ID とグループ メンバーシップを再利用するように AKS クラスターを構成できます。
ログ記録と監視の統合 AKS には、クラスターのパフォーマンスの可視性を提供するためのコンテナーの Azure Monitor が含まれています。 カスタム Kubernetes インストールでは、インストールと構成を必要とする監視ソリューションを決定します。
自動クラスター ノードおよびポッドのスケーリング 大規模なコンテナー化環境でスケールアップまたはスケールダウンするタイミングを決めるのは大変です。 AKS では、2 つの自動クラスター スケーリング オプションがサポートされています。 ポッドの水平オートスケーラーまたはクラスター オートスケーラーを使用して、クラスターをスケーリングすることができます。 水平ポッド オートスケーラーは、ポッドのリソース需要を監視し、需要に合うようにポッドのリソースを増やします。 ''クラスター オートスケーラー'' コンポーネントでは、ノードの制約のためにスケジュールできないポッドを監視します。 スケジュールされたポッドをデプロイするために、クラスター ノードが自動的にスケーリングされます。
クラスター ノードのアップグレード クラスター管理タスクの数を減らす必要がありますか。 AKS では、Kubernetes ソフトウェアのアップグレードと、ノードを切断およびドレインして実行中のアプリケーションの中断を最小限に抑えるプロセスを管理します。 完了すると、これらのノードは一度に 1 つずつアップグレードされます。
GPU 対応ノード 多くのコンピューティング処理を要するワークロードやグラフィックを集中的に使用するワークロードはありますか。 AKS では GPU 対応ノード プールがサポートされます。
ストレージ ボリュームのサポート アプリケーションはステートフルですか。また、アプリケーションで永続化されたストレージが必要ですか。 AKS では、静的と動的の両方のストレージ ボリュームがサポートされます。 ポッドは、異なるノードで作成または再スケジュールされたときに、これらのストレージ ボリュームにアタッチして再アタッチすることができます。
仮想ネットワークのサポート ''ポッド間でネットワーク通信を行ったり、AKS クラスターからオンプレミス ネットワークにアクセスしたりする必要がありますか?'' AKS クラスターは、既存の仮想ネットワークに簡単にデプロイできます。
HTTP アプリケーション ルーティング サポートを使用するイングレス デプロイしたアプリケーションを公開する必要がありますか。 HTTP アプリケーション ルーティング アドオンを使用すると、AKS クラスターでデプロイされたアプリケーションに簡単にアクセスできます。
Docker イメージのサポート コンテナーに Docker イメージを既に使用していますか。 既定では、AKS で Docker ファイル イメージ形式がサポートされます。
プライベート コンテナー レジストリ プライベート コンテナー レジストリが必要ですか。 AKS は Azure Container Registry (ACR) と統合されています。 ACR に限定されるわけではありません。パブリックかプライベートかにかかわらず、他のコンテナー リポジトリを使用できます。

これらのすべての機能は、クラスターを作成するとき、またはデプロイ後に構成できます。