Azure Arc で有効になっている AKS の Kubernetes クラスターのアーキテクチャとワークロード
適用対象: AKS on Azure Stack HCI 22H2、Windows Server 上の AKS
Azure Local および Windows Server 上の Azure Kubernetes Service (AKS) は、Azure Local を利用したエンタープライズ レベルの Kubernetes コンテナー プラットフォームです。 Microsoft がサポートするコア Kubernetes、専用の Windows コンテナー ホスト、Microsoft がサポートする Linux コンテナー ホストが含まれており、シンプルなデプロイおよびライフサイクル管理エクスペリエンスを提供することを目標にしています。
この記事では、コントロール プレーン、ノード、ノード プールなど、Kubernetes インフラストラクチャのコア コンポーネントを紹介します。 また、プール、デプロイ、およびセットなどのワークロード リソースと、リソースを名前空間にグループ化する方法も紹介します。
Kubernetes クラスターのアーキテクチャ
Kubernetes は、Azure Arc で有効になっている AKS のコア コンポーネントです。AKS では、一連の定義済みの構成を使用して、スケーラビリティを念頭に置いて Kubernetes クラスターを効果的にデプロイします。
デプロイ操作では、複数の Linux または Windows 仮想マシンを作成し、それらを結合して Kubernetes クラスターを作成します。
Note
システムの信頼性を向上させるために、クラスター内で複数のクラスター共有ボリューム (CSV) を実行している場合、既定では、仮想マシン データはクラスター内の使用可能なすべての CSV に自動的に分散されます。 これにより、CSV の障害が発生した場合でも、アプリケーションは存続できます。 これは、(アップグレードではなく) 新規インストールにのみ適用されます。
デプロイされたシステムは、標準の Kubernetes ワークロードを受け取り、これらのワークロードをスケーリングしたり、必要に応じて仮想マシンの数やクラスターの数を上下にスケーリングする準備ができています。
Azure Kubernetes Service クラスターには、次のコンポーネントがあります。
- "管理クラスター" (AKS ホストとも呼ばれます) は、1 つ以上のワークロード クラスターをデプロイおよび管理するためのコア オーケストレーション メカニズムとインターフェイスを提供します。
- ワークロード クラスター (ターゲット クラスターとも呼ばれます) は、コンテナ化されたアプリケーションがデプロイされる場所です。
Arc で有効になっている AKS を管理する
AKS は、次の管理オプションを使用して管理できます。
- Windows Admin Center は、Kubernetes オペレーターがクラスターのライフサイクルを管理するための直感的な UI を提供します。
- PowerShell モジュールを使用すると、AKS のダウンロード、構成、デプロイが簡単になります。 PowerShell モジュールは、他のワークロード クラスターのデプロイと構成のほか、既存のクラスターの再構成もサポートしています。
管理クラスター
Kubernetes クラスターを作成すると、管理クラスターが自動的に作成および構成されます。 この管理クラスターは、ワークロードが実行されるワークロード クラスターのプロビジョニングと管理を担います。 管理クラスターには、以下の Kubernetes コア コンポーネントが含まれています。
- API サーバー: API サーバーは、基になる Kubernetes API を公開する方法です。 このコンポーネントにより、Windows Admin Center、PowerShell モジュール、
kubectlなど、管理ツールでの対話が実現します。 - ロード バランサー: ロード バランサーは、管理クラスターの API サーバーの負荷分散規則を持つ単一の専用 Linux VM です。
ワークロード クラスター
ワークロード クラスターは Kubernetes の高可用性デプロイであり、Kubernetes コントロール プレーン コンポーネントおよび Linux ワーカー ノードを実行するために Linux VM を使用しています。 Windows Server Core ベースの VM は、Windows ワーカー ノードを確立するために使用されます。 1 つの管理クラスターによって管理されるワークロード クラスターが 1 つ以上存在する場合があります。
ワークロード クラスターのコンポーネント
次のセクションでは、ワークロード クラスターに多数用意されているコンポーネントについて説明します。
コントロール プレーン
- API Server: API サーバーは Kubernetes API との対話を許可します。 このコンポーネントにより、Windows Admin Center、PowerShell モジュール、
kubectlなど、管理ツールでの対話が実現します。 - Etcd: Etcd は、クラスターのライフサイクル管理に必要なデータを格納する分散キー値ストアです。 これにはコントロール プレーンの状態が格納されます。
Load Balancer
ロード バランサーは、Linux と HAProxy + KeepAlive を実行する仮想マシンです。これは、管理クラスターによってデプロイされたワークロードト クラスターに、負荷分散されたサービスを提供します。 ワークロード クラスターごとに、AKS は少なくとも 1 つのロード バランサー仮想マシンを追加します。 ワークロード クラスター上に作成 LoadBalancer 種類の Kubernetes サービスは、最終的に VM に負荷分散規則を作成します。
[Worker nodes](ワーカー ノード)
アプリケーションとサポート対象のサービスを実行するには、Kubernetes のノードが必要です。 AKS ワークロード クラスターには "ワーカー ノード" が 1 つ以上あります。 ワーカー ノードは、Kubernetes ノード コンポーネントを実行する仮想マシン (VM) として機能し、アプリケーション ワークロードを構成するポッドとサービスをホストします。
ポッドやデプロイなど、AKS ワークロード クラスターにデプロイできるコア Kubernetes ワークロード コンポーネントがあります。
ポッド
Kubernetes はポッドを使用して、お使いのアプリケーションのインスタンスを実行します。 ポッドは、アプリケーションの単一のインスタンスを表します。 通常、ポッドにはコンテナーとの 1 対 1 のマッピングがありますが、ポッドに複数のコンテナーを含めることができる高度なシナリオがあります。 これらのマルチコンテナー ポッドは、同じノード上にまとめてスケジュールされ、コンテナーが関連するリソースを共有できるようにします。 詳細については、Kubernetes ポッドと Kubernetes ポッドのライフサイクルに関するページをご覧ください。
デプロイ
1 つのデプロイは 1 つ以上の同一ポッドに相当し、Kubernetes デプロイ コントローラーによって管理されます。 デプロイでは、作成する replicas (ポッド) の数が定義され、Kubernetes スケジューラにより、ポッドまたはノードで問題が発生した場合に、正常なノードで追加のポッドがスケジュールされます。 詳細については、Kubernetes のデプロイに関するページをご覧ください。
StatefulSet と DaemonSet
デプロイ コントローラーは、Kubernetes スケジューラを使用して、使用可能なリソースを持つ任意の使用可能なノードで特定の数のレプリカを実行します。 デプロイを使用するこの方法はステートレス アプリケーションには十分ですが、永続的な名前付け規則やストレージを必要とするアプリケーションでは十分ではありません。 1 つのクラスター内で、各ノード上 (または選択されたノード上) にレプリカが存在することが必要なアプリケーションの場合、デプロイ コントローラーは、ノード間でレプリカがどのように分散しているかを考慮しません。
- StatefulSets: StatefulSet は、1 つ以上の同じポッドが作成および管理されるという点でデプロイに似ています。 デプロイ、スケーリング、アップグレード、および強制終了において、StatefulSet 内の "レプリカ" は、適切な順序付けの手法に従います。 StatefulSet では (レプリカが再スケジュールされるときに)、名前規則、ネットワーク名、およびストレージが永続化されます。 StatefulSet 内のレプリカはスケジュールされ、Kubernetes クラスター内の使用可能なノード全体で実行されます。 セット内の少なくとも 1 つのポッドがノード上で実行されるようにする必要がある場合は、代わりに DaemonSet を使用できます。 詳細については、Kubernetes の StatefulSet に関するページを参照してください。
- DaemonSets: 特定のログ収集または監視のニーズに合わせて、すべてのノードまたは選択したノードで特定のポッドを実行することが必要になる場合があります。 DaemonSet は、1 つ以上の同一のポッドをデプロイするために再び使用されますが、DaemonSet コントローラーは、指定された各ノードがポッドのインスタンスを実行することを保証します。 詳細については、Kubernetes の DaemonSet に関するページを参照してください。
名前空間
ポッドやデプロイなどの Kubernetes リソースは、論理的に 1 つの "名前空間" にグループ化されます。 これらのグループ化により、ワークロード クラスターを論理的に分割し、リソースを作成、表示、または管理するためのアクセスを制限する方法が提供されます。 たとえば、名前空間を作成して業務グループを分けることができます。 ユーザーは、割り当てられている名前空間内のリソースのみを操作できます。 詳細については、Kubernetes の名前空間 に関するページを参照してください。
Arc によって有効になっている AKS 上に Azure Kubernetes Service クラスターを作成すると、次の名前空間を使用できます。
- default: 何も指定されていない場合、ポッドとデプロイが既定で作成される名前空間。 より小規模な環境では、追加の論理分割を作成せずに、既定の名前空間にアプリケーションを直接デプロイできます。
kubectl get podsなどの Kubernetes API を操作する場合、何も指定しないと、既定の名前空間が使用されます。 - kube-system: DNS やプロキシなどのネットワーク機能や Kubernetes ダッシュボードなど、コア リソースが存在する名前空間。 通常は、この名前空間に独自のアプリケーションをデプロイしません。
- kube-public: 名前空間は通常使用されませんが、リソースをクラスター全体に表示するために使用でき、任意のユーザーが表示できます。
シークレット
Kubernetes secrets を使用すると、パスワード、OAuth トークン、Secure Shell (SSH) キーなどの機密情報を格納および管理できます。 既定では、Kubernetes は暗号化されていない base64 でエンコードされた文字列としてシークレットを格納し、API アクセス権を持つすべてのユーザーがプレーン テキストとして取得できます。 詳細については、Kubernetes のシークレットに関するページをご覧ください。
永続ボリューム
"永続" ボリュームは Kubernetes クラスター内のストレージ リソースです。これは、管理者によってプロビジョニングされているか、ストレージ クラスを使用して動的にプロビジョニングされています。 永続ボリュームを使用するために、ポッドは PersistentVolumeClaim を使用してアクセスを要求します。 詳細については、永続ボリュームに関するページをご覧ください。
混合 OS デプロイ
あるワークロード クラスターが Linux と Windows の両方のワーカー ノードで構成されている場合、そのスケジュールは、ワークロードのプロビジョニングをサポートできる OS で行う必要があります。 Kubernetes には、ターゲット オペレーティング システムが稼働するノードにワークロードを確実に配置するため、2 つのメカニズムが用意されています。
- ノード セレクター は、ポッド スペックの単純なフィールドであり、オペレーティング システムに一致する正常なノードにのみポッドをスケジュールするように制限します。
- テイントと容認は、連携動作して、ポッドが意図せずノードにスケジュールされないようにします。 ノードは、ポッド 仕様の "容認" によってテイントを明示的に許容しないポッドを受け入れないように、"テイント" できます。
詳細については、ノード セレクターに関するページと、テイントおよび容認に関するページを参照してください。
次のステップ
この記事では、Azure Arc で有効になっている AKS のクラスター アーキテクチャとワークロード クラスター コンポーネントについて説明しました。 これらの概念の詳細については、次の記事を参照してください。