Azure Kubernetes Service on Azure Stack HCI のクラスターとワークロード

適用対象:Azure Stack HCI 上の AKS、Windows Server 2019 Datacenter 上の AKS ランタイム

Azure Stack HCI 上の Azure Kubernetes Service は、Azure Stack HCI を利用するエンタープライズ グレードの Kubernetes コンテナー プラットフォームです。 これには、Microsoft がサポートするコア Kubernetes、専用 Windows コンテナー ホスト、および Microsoft がサポートする Linux コンテナー ホストが含まれており、 デプロイとライフ サイクル管理のシンプルなエクスペリエンス を用意することを目的としています。

この記事では、コントロール プレーン、ノード、ノード プールなど、Kubernetes インフラストラクチャのコア コンポーネントを紹介します。 また、プール、デプロイ、およびセットなどのワークロード リソースと、リソースを名前空間にグループ化する方法も紹介します。

クラスターのコンポーネント

Kubernetes は、Azure Stack HCI 上の Azure Kubernetes Service のコア コンポーネントです。 Azure Stack HCI 上の Azure Kubernetes Service では、事前に定義された構成のセットを使用し、スケーラビリティを念頭に置いて効果的に Kubernetes クラスターがデプロイされます。

デプロイ操作では、Linux または Windows の仮想マシンを複数作成し、それらを結合して Kubernetes クラスターを作成します。

注意

システムの信頼性を向上させるため、Azure Stack HCI クラスターで複数のクラスター共有ボリューム (CSV) を実行している場合、既定では、クラスター内のすべての使用可能な CSV に仮想マシン データが自動的に分散されます。 これにより、CSV の障害が発生した場合でも、アプリケーションは存続できます。 これは、(アップグレードではなく) 新規インストールにのみ適用されます。

デプロイされたシステムは、標準の Kubernetes ワークロードを受け取り、これらのワークロードをスケーリングしたり、必要に応じて仮想マシンの数やクラスターの数を上下にスケーリングする準備ができています。

Azure Stack HCI 上の Azure Kubernetes Service クラスターのコンポーネントは次のとおりです。

  • "管理クラスター" (AKS ホストとも呼ばれます) は、1 つ以上のワークロード クラスターをデプロイおよび管理するためのコア オーケストレーション メカニズムとインターフェイスを提供します。
  • ワークロード クラスター (ターゲット クラスターとも呼ばれます) は、コンテナ化されたアプリケーションがデプロイされる場所です。

Azure Stack HCI 上の Azure Kubernetes Service の技術的アーキテクチャを示す図です。

AKS on Azure Stack HCI を管理する

AKS on Azure Stack HCI は、次の管理オプションを使用して管理できます。

  • Windows Admin Center には、Azure Stack HCI 上で Azure Kubernetes Service クラスターのライフサイクルを管理するための、直感的な Kubernetes オペレーター向け UI が用意されています。
  • PowerShell モジュール を使用すると、Azure Kubernetes Service on Azure Stack HCI を簡単にダウンロード、構成、デプロイできます。 PowerShell モジュールは、追加のワークロード クラスターのデプロイと構成のほか、既存のクラスターの再構成もサポートしています。

管理クラスター

Azure Stack HCI 上に Azure Kubernetes Service クラスターを作成すると、管理クラスターが自動的に作成され、構成されます。 この管理クラスターは、ワークロードが実行されるワークロード クラスターのプロビジョニングと管理を担います。 管理クラスターには、以下の 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 を実行する仮想マシンです。これは、管理クラスターによってデプロイされたワークロードト クラスターに、負荷分散されたサービスを提供します。 Azure Kubernetes Service on Azure Stack HCI により、ワークロード クラスターごとに、少なくとも 1 つのロード バランサー仮想マシンが追加されます。 ワークロード クラスター上で作成された種類が LoadBalancer のすべての Kubernetes サービスによって、VM 内に負荷分散規則が作成されます。

ワーカー ノード

アプリケーションとサポート対象のサービスを実行するには、Kubernetes のノードが必要です。 Azure Stack HCI 上の Azure Kubernetes Service ワークロード クラスターには、ワーカー ノードが 1 つ以上あります。これは、Kubernetes ノード コンポーネントを実行する仮想マシン (VM) であり、アプリケーション ワークロードを構成するポッドやサービスをホストします。 ポッドやデプロイなど、Azure Kubernetes Service on Azure Stack HCI ワークロード クラスター上にデプロイできる Kubernetes ワークロード コア コンポーネントがあります。

ポッド

Kubernetes は ポッド を使用して、お使いのアプリケーションのインスタンスを実行します。 ポッドは、アプリケーションの単一のインスタンスを表します。 通常、ポッドにはコンテナーとの 1 対 1 のマッピングがありますが、1 つのポッドに複数のコンテナーが含まれる場合がある高度なシナリオが存在します。 これらのマルチコンテナー ポッドは、同じノード上にまとめてスケジュールされ、コンテナーが関連するリソースを共有できるようにします。 詳細については、Kubernetes ポッドKubernetes ポッドのライフサイクルに関するページをご覧ください。

デプロイメント

1 つの デプロイ は 1 つ以上の同一ポッドに相当し、Kubernetes デプロイ コントローラーによって管理されます。 デプロイでは、作成する レプリカ (ポッド) の数を定義し、Kubernetes スケジューラは、ポッドまたはノードで問題が発生した場合に、追加のポッドが正常なノード上にスケジュールされることを保証します。 詳細については、Kubernetes のデプロイに関するページをご覧ください。

StatefulSet と DaemonSet

デプロイ コントローラーでは、Kubernetes スケジューラを使って、使用できるリソースがある任意の利用可能なノード上で、指定された数のレプリカを実行します。 デプロイを使用するこの方法は、ステートレス アプリケーションでは十分なかもしれませんが、永続的な名前規則やストレージを必要とするアプリケーションでは、不十分です。 1 つのクラスター内で、各ノード上または選択されたノード上にレプリカが存在することが必要なアプリケーションの場合、デプロイ コントローラーでは、ノード間にレプリカが配信される方法を確認しません。

  • StatefulSets - StatefulSet は、1 つ以上のポッドが作成され管理されるデプロイとほぼ同じです。 デプロイ、スケーリング、アップグレード、および強制終了において、StatefulSet 内のレプリカは、適切な順序付けの手法に従います。 StatefulSet では (レプリカが再スケジュールされるときに)、名前規則、ネットワーク名、およびストレージが永続化されます。 StatefulSet 内の "レプリカ" は、Azure Kubernetes Service on Azure Stack HCI クラスター内のすべての利用可能なノード全体にスケジュールされ、実行されます。 セット内の 1 つ以上のポッドが、ノード上で実行されることを保証する必要がある場合は、代わりに、DaemonSet を使用できます。 詳細については、Kubernetes の StatefulSet に関するページを参照してください。

  • DaemonSets - 特定のログ コレクションや監視のニーズのために、すべてのノード上または選択されたノード上で、指定されたポッドを実行する必要が生じる場合があります。 この場合も、1 つ以上の同一ポッドをデプロイするために DaemonSet が使用されますが、DaemonSet コントローラーが、指定された各ノードでポッドのインスタンスが実行されることを保証します。 詳細については、Kubernetes の DaemonSet に関するページを参照してください。

名前空間

ポッドやデプロイなどの Kubernetes リソースは、論理的に 1 つの 名前空間 にグループ化されます。 このグループ化により、Azure Kubernetes Service on Azure Stack HCI ワークロード クラスターを論理的に分割し、リソースを作成、表示、または管理するためのアクセスを制限する方法が提供されます。 たとえば、名前空間を作成して業務グループを分けることができます。 ユーザーは、割り当てられている名前空間内のリソースのみを操作できます。 詳細については、Kubernetes の名前空間 に関するページを参照してください。

Azure Stack HCI 上に 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 on Azure Stack HCI のクラスター アーキテクチャとワークロード クラスター コンポーネントについて学習しました。 AKS on Azure Stack HCI の概念の詳細については、次の記事を参照してください。