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