SE の雑記

Azure Kubernetes Service (AKS) on Azure Stack HCI の一般提供が開始されたことで、Windows Server 上に Kubernetes (k8s) の環境をサポートを受けられる状態で構築することができました。

AKS on Azure Stack HCI を稼働させるホスト環境の要件については、Azure Kubernetes Service ホストの設定 に、次のように記載されています。

Kubernetes クラスターを作成する前に行う必要がある最後の手順が 1 つあります。 Kubernetes クラスターのデプロイ先となるシステム上に、Azure Kubernetes Service ホストを設定する必要があります。 このシステムには、Windows Server 2019 Datacenter クラスター、単一ノードの Windows Server 2019 Datacenter、または 2-4 ノード Azure Stack HCI クラスターを指定できます。

「単一ノードの Windows Server 2019 Datacenter」が利用可能なホストとして記載されており、Windows Server 2019 の環境が 1 台あれば、AKS on Azure Stack HCI を検証することが可能です。

シングルノードの検証環境については、コンピューティングの要件 にも記載されていますね。

• Azure Kubernetes Service は、技術的には単一ノードの Windows Server 2019 Datacenter で実行できますが、そうすることは推奨されません。 ただし、評価目的のために、単一ノードの Windows Server 2019 Datacenter 上で Azure Kubernetes Service を実行できます。

AKS on Azure Stack HCI は 60 日間、無償で試用することができますので、コストを抑えて検証することができます。

また、クイック スタート:Windows Admin Center を使用して、Azure Stack HCI 上に Azure Kubernetes Service を設定する に手順が記載されており、この手順で簡単に AKS on Azure Stack HCI の構築までは完了するので、本手順では、AKS on Azure Stack HCI の構築については省略していますが、Windows Admin Center に登録したサーバーについては、GUI から、AKS on Azure Stack HCI を簡単に構築することができます。

構築された k8s は、VHDX を使用したストレージや、ロードバランサーが組み込まれていますので、k8s の基本的な検証にも活用することができるのではないでしょうか。

本投稿では、1 ノードの Windows Server 2019 上に構築された AKS on Azure Stack HCI を使用して、App Service on Arcを動作させる際に必要な作業を見ていきたいと思います。

今回使用している NUC は NUC5I5MYHE で古めの NUC ですが、これに 32GB のメモリを搭載して検証環境としています。（CPU が 4 コア / メモリが 8 GB 以上無いと Azure Kubernetes サービスが追加できません。コントロールプレーンと Linux ノードを追加することを考えると、CPU 4 コア / メモリ 32GB は最低限必要です)

今回紹介していないドキュメントもいくつかありますが、App Service on Azure Arc (Azure application services on kubernetes) の検証時に確認をしておきたいドキュメント で関連するドキュメントをまとめてみましたので、深掘りしたい箇所はこれらのドキュメントから確認すると良いのではないでしょうか。

現状、Azure については、East US, West Europe でのみサポートされていますので、検証時に使用できるリージョンにも制限があります。(今回は East Us に作成しています)

オンプレミス環境の App Service on Arc で利用される機能

オンプレミスで App Service on Arc を実行する場合、Azure Arc enabled Kubernetes の次の機能を意識しておくと、検証をスムーズに進めることができるのではないでしょうか。

• Azure Arc 対応 Kubernetes のクラスター拡張機能
• Azure Arc 対応 Kubernetes でのカスタムの場所
• Azure Arc 対応 Kubernetes エージェントのアーキテクチャ

クラスター拡張機能

App Service on Arc は Arc enabled k8s の拡張機能 (Extension) として実装が行われていますので、Arc に接続された k8s (connectedk8s) に対して、拡張機能を追加する必要があります。

今回は App Service 用の拡張機能を追加していますが、そのほかにも 現在使用可能な拡張機能 に記載されているような機能があり、Azure Arc enabled Data Service についても拡張機能として追加することが可能です。

カスタムの場所

App Service on Arc は「Azure ポータルから任意の Kubernetes に対して、App Service を展開することができる」機能となります。
ポータルから展開する際にリージョンとして Arc enabled k8s を指定することができるようになります。

この指定する際に使用されるのが「カスタムの場所 (Custom Location)」となり、展開先として Arc enabled k8s を指定するためには、Arc enabled k8s をカスタムの場所として追加する必要があります。

Arc enabled k8s エージェント

オンプレミスの最後のポイントとなるのが、Arc enabled k8s エージェントです。

Azure Arc にクラスターを接続する に記載されているのですが、Azure Arc enabled k8s を展開すると、エージェントとしていくつかの Pod が展開されます。

オンプレミスの環境で、App Service on AKS を展開する際にポイントとなるのが、「clusterconnect-agent」です。

このエージェントはオプションコンポーネントであるため、明示的に追加しないと導入が行われません。

App Service on Arc では、「Azure Servie Bus から k8s の apiserver に対してアクセス」が行われているようなのですが、「clusterconnect-agent」が導入されていない環境では、k8s に対して直接アクセスを行おうとするようです。

App Service on Arc を構築する際に上記の通信が発生するのは、「カスタムの場所」を作成するタイミングで発生しているようです。

そのため、Public IP が付与されていない k8s (Public IP 経由でアクセスできない k8s) については、apiserver に対してのアクセス経路が存在しないため、カスタムの場所を作成しようとするとエラーとなります。

「clusterconnect-agent」が展開されている環境では、このエージェントがプロキシとなり Service Bus とのアクセスが行われるような通信経路となるようで、k8s がインターネットにアクセスできる環境があれば、App Service on Arc を展開することができるようになります。

App Service on Arc を展開する

拡張機能導入のためのスクリプトの生成

App Service on Arc の展開方法については、Azure Arc 対応の Kubernetes クラスターを設定して、App Service、Functions、Logic Apps を実行します (プレビュー) で公開されていますが、Azure ポータルから展開用のスクリプトを生成することができます。

Arc Enabled k8s の「拡張機能」から「Application services extension」を追加することができます。

ここで必要な情報を入力すると展開用のスクリプトを生成することができ、サブスクリプションの管理者がスクリプトを実行することで、展開が完了します。

オンプレミス環境で実行する際のポイント

展開をする際には、Azure Arc 対応の Kubernetes クラスターを設定して、App Service、Functions、Logic Apps を実行します (プレビュー) や、上記の生成されたスクリプトをベースにすると思いますが、オンプレミス環境で実行する場合には、クラスターでカスタムの場所を有効にする を実行しておく必要があります。

$subscriptionId = "<Subscripton Id>"
$resourceGroup = "Resource Group"
$clusterName = "Arc on k8s Cluster Namer"


az login
az account set -s $subscriptionId
az connectedk8s enable-features -n $clusterName -g $resourceGroup --features cluster-connect custom-locations

「az connectedk8s enable-features」を実行することで、指定した Arc enabled k8s に対して、「cluster-connect」「custom-locations」の機能が Helm を使用して追加されています。(custom-locations だけを追加しようとしても、依存関係で cluster-connect も追加されていそうですが)

これにより、次のエージェントが pod として追加されます。

• clusterconnect-agent
• kube-aad-proxy
• config-agent
• extension-manager

これらのエージェントが追加されることで、Service Bus からの通信が、clusterconnect-agent 経由になり、k8s が Public IP を持っていなくても、Azure との通信ができるようになります。

enable-features では、そのほかにも、Cluster Role Binding として、AzureArc-Microsoft.ExtendedLocation-RP-RoleBinding に「6a19b556-1bb3-4d46-8e7e-956a51b1cabc」(Custom Locations RP) の設定なども行われているようですね。

あとは、ステップバイステップや、ポータルで生成されたスクリプトを実行することで、環境を構築することができると思います。

ポータルで生成されたスクリプトでは、Azure CLI に Extension に追加や、Azure にリソースプロバイダーの登録を行っていますが、それ以外の処理としては次のような内容が行われています。

• az k8s-extension create
• az customlocation create
• az appservice kube create

az k8s-extension create

「az k8s-extension create」が実行されることで、Arc enabled k8s に拡張機能が追加されます。

拡張機能の登録時に指定した namespace に Pod と Service が作成されます。

ポータルで生成したスクリプトでは、「loadBalancerIp」の指定がありますが、今回検証した環境では、この構成を省略してもロードバランサーでサービスが作成され、自動的に IP も割り当てられていました。

IP を指定しても該当の IP が設定されていなかったので、AKS で Public IP を設定する際に指定するものなのでしょうかね？？

拡張機能の追加が完了すると、次のようなサービスと Pod が作成されます。

az customlocation create

「カスタムの場所」のリソースを Azure 上に追加します。

「オンプレミス環境で実行する際のポイント」に記載しましたが、「az connectedk8s enable-features」で「cluster-connect」「custom-locations」を追加しておかないと、Service Bus から k8s の apiserver に通信ができず、次のようなエラーが発生します。

Message: The operation to Create a Namespace: "appservice-hci", failed with the following error: "an error on the server (\"404 There are no listeners connected for the endpoint. Tracking

Id:xxxxxxxxx, SystemTracker:sb://azgnrelay-eastus-l1.servicebus.windows.net/microsoft.kubernetes/connectedclusters/xxxxxxxxx

xxxxxx/xxxxxxxxxx, Timestamp:2021-06-06T11:20:00. websocket: bad handshake\") has prevented the request from succee

これを回避するためには「public ip 経由で apiserver にアクセスを可能とする」「clusterconnect-agent」経由で apiserver にアクセスを可能とする」の 2 つの方法となるかと思いますが、オンプレミスの環境であれば、「enable-features」で後者を有効にすることになるのではないでしょうか。

「clusterconnect-agent」が起動している環境であれば、次のように clusterconnect-agent が Service Bus からの通信を受けていることが確認できます。

「カスタムの場所」の追加が終わり、次の「az appservice kube create」が完了すると、App Service の追加時に、カスタムの場所が選択できるようになります。

az appservice kube create

このコマンドを実行することで、Azure に「App Service Kubernetes 環境」が追加されます。

「az appservice kube create」を実行する際には、「–static-ip」を指定しますが、この時に指定する IP は、「az k8s-extension create」で作成された Load Balancer の Service の IP になるかと思います。(Web アプリを作成すると、「az appservie kube create」の「–static-ip」で指定した IP で名前解決されるようになります)

k8s 上には、次のような Pod が展開されます。

• appservice-hci-k8se-app-controller
• appservice-hci-k8se-activator
• appservice-hci-k8se-log-processor

Web アプリの作成

ここまでの作業が完了すると、Web Apps 等の App Service のリソースを作成する際に、「カスタムの場所」として、作成した場所を選択できるようになり、この場所に作成した場合には、App Service on Arc 上の k8s にサイトが作成されます。

付与されれる URL も「xxxxx.eastus.k4apps.io」という形式になっていますね。

作成されたアプリケーションで名前解決をすると、「az appservice kube create」で指定した「–static-ip」で登録が行わていることが確認できますね。

アプリケーションにアクセスすることもできていますね。

まとめ

docs で公開されているチュートリアルは、Azure 上の AKS に環境を構築するものとなっていますが、それ以外の k8s を Arc enabled k8s として接続して、App Service on Azure Arc の検証を行うことが可能です。

「カスタムの場所」を作成する際の Service Bus から k8s の apiserver への通信ではまっていて、いろいろな方にアドバイスをいただいたのですが、最終的に、オンプレミスの環境に対して構築できることが分かりました。