Azure Kubernetes Service クラスターを作成する
あなたの会社では、クラウドネイティブの開発プラットフォームとして Azure Kubernetes Service (AKS) を使用して、クラウドベースのビデオ レンダリング サービスをデプロイする予定です。 アプリケーションをデプロイする前に、AKS クラスターを作成する必要があります。
新しい AKS クラスターを問題なくデプロイできるように、いくつかの概念を確認しましょう。
Kubernetes クラスター
Kubernetes はクラスターに基づいています。 単一の仮想マシン (VM) が使用されるのではなく、1 つのものとして動作する複数のマシンが使用されます。 これらの VM はノードと呼ばれます。 Kubernetes はクラスターベースのオーケストレーターです。 可用性、監視、スケーリング、ローリング更新など、アプリケーションにいくつかの利点が提供されます。
クラスター ノード
クラスターはノードが基になります。 Kubernetes クラスターには、特定の機能を提供する 2 種類のノードがあります。
コントロール プレーン ノード: これらのノードは、クラスターのコントロール プレーンの側面をホストするために使用され、クラスターを制御するサービス用に予約されています。 これらには、ユーザーや他のすべてのノードが通信に使用する API を提供する役割があります。 これらのノードにワークロードがデプロイまたはスケジュールされることはありません。
ノード: これらのノードには、クラウドベースのビデオ レンダリング サービスからのコンポーネントなど、カスタムのワークロードとアプリケーションを実行する役割があります。
クラスターのアーキテクチャ
クラスター アーキテクチャを使用して、Kubernetes クラスターにデプロイするコントロール プレーンとノードの数を概念化します。
たとえば、クラスター内のノードの数は、常に 2 つより多くする必要があります。 あるノードが使用できなくなると、Kubernetes スケジューラにより、クラスター内の残りのノードに対して、このノードで実行されていたすべてのワークロードの再スケジュールが試行されます。
Kubernetes ベースのデプロイには、2 つの一般的なクラスター アーキテクチャがあります。
単一のコントロール プレーンと複数のノード
クラスターごとの "単一のコントロール プレーンから複数ノード" へのアーキテクチャは最も一般的なアーキテクチャ パターンであり、デプロイが最も簡単ですが、クラスターのコア管理サービスに高可用性は提供されません。
何らかの理由でコントロール プレーン ノードが使用できなくなった場合、クラスターで他の操作を行うことはできません。 この問題は、少なくとも API サーバーがオンラインに戻るまでは、オペレーターであっても、通信に Kubernetes の API を使用するワークロードによる場合であっても、発生します。
他より可用性は低くなりますが、ほとんどの状況にはこのアーキテクチャで十分なはずです。 コア管理サービスが使用できなくなる可能性は、ノードがオフラインになる可能性ほど高くありません。 コントロール プレーン ノードは、ノードより変更されることが少なく、高い回復性を備えています。
運用シナリオに対応している場合は、このアーキテクチャは最適なソリューションではない可能性があります。
単一のコントロール プレーンと単一のノード
"単一のコントロール プレーンから単一のノード" へのアーキテクチャは、前のアーキテクチャのバリエーションであり、開発環境で使用されます。 このアーキテクチャによって、コントロール プレーンとワーカー ノードの両方をホストするノードが 1 つだけ提供されます。 これは、Kubernetes のさまざまな概念をテストまたは実験するときに便利です。 単一コントロール プレーンと単一ノードのアーキテクチャによってクラスターのスケーリングが制限されるため、このアーキテクチャは運用環境やステージング環境での使用には適していません。
AKS クラスターを構成する
新しい AKS クラスターを作成するときに、構成する項目が複数あります。 各項目は、コンピューティング リソース割り当てのクラスターの最終的な構成に影響します。
次のような項目があります。
- ノード プール
- ノード数
- ノード VM のサイズ
ノード プール
AKS クラスター内のノードをグループ化するには、"ノード プール" を作成します。 ノード プールを作成するときは、アプリケーションの要件に基づいて、ノード プールの各ノードの VM サイズと OS の種類 (Linux または Windows) を指定します。 ユーザー アプリケーション ポッドをホストするには、ノード プールの [モード] が [ユーザー] または [システム] である必要があります。
既定で、AKS クラスターには、作成する際に使用したのが Azure portal か CLIかに関わらず、Linux ノード プール (システム モード) があります。 ただし、ポータルの作成ウィザード、CLI のパラメーター、または ARM テンプレートを使用して、Windows ノード プールを既定の Linux ノード プールと共に追加するように構成できます。
ノード プールでは、基盤となるインフラストラクチャとして Virtual Machine Scale Sets を使用することにより、クラスターでノード プール内のノード数をスケーリングできるようにします。 ノード プールで作成される新しいノードは、常に、ノード プールの作成時に指定したサイズと同じサイズになります。
ノード数
ノード数は、クラスターのノード プール内に存在するノードの数です。 ノードは Azure VM です。 使用パターンに合わせてサイズと数を変更することができます。
ノード数は、クラスターの構成パネルを使用して後から変更できます。 また、不要なコストや未使用のコンピューティング能力を避けるため、この数をできるだけ少なくすることがベスト プラクティスです。
ノード VM のサイズ
さまざまな VM 仕様から選択することができます。 開発目的では、コストを節約するために B シリーズを選択できます。 演習では、標準サイズであるシリーズ B2 を使用します。 ニーズに基づいて VM を選択するための詳細なガイダンスについては、Azure VM セレクター ツールを参照してください