AKS on Azure Stack HCI を試した
azurestackhci
Published: 2021-06-05

はじめに

Build 2021で Azure Arc enabled application services が発表されました。本サービスを利用すると Arc enabled k8s 上で Azure のアプリケーションサービスを動かせます。本サービスの対象の一つが App Service です。Arc enabled App Service のチュートリアルでは Azure 上の AKS を利用します。

ですが、現実世界において Azure 上の AKS で Arc enabled App Service を使うことはほぼないと思います。Azure 上であれば普通の App Service をそのまま使えばいいので。「ありえないシナリオで評価しても学びが少ないなぁ・・」ということで、ありそうなシナリオであるオンプレ k8s を用意するために AKS on Azure Stack HCI(以降、AKS on HCI)を試しました。

環境

AKS on HCI の概要

次のドキュメントで AKS on HCI の大まかな構成を確認できます。

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

ドキュメント内の画像の通り、AKS on HCI は AKS 自体を管理する管理クラスタとアプリケーション用のコンテナを動作させるワークロードクラスタの2つで構成されています。

管理クラスタの構築

まずは管理クラスタを構築します。このクラスタを構築する際に、管理クラスタとワークロードクラスタが利用するアドレス帯を設定します。管理クラスタを構築した後にアドレス帯を変えられないので、設計は慎重に。

参考:Azure Stack HCI において Azure Kubernetes Service (AKS) ノードをデプロイするためのネットワークの概念

決めるべきアドレスと今回の設定値は次の通りです。

  • Cloudagent IP:192.168.0.50
  • Subnet prefix:192.168.0.0/24
  • Gateway:192.168.0.1
  • DNS servers:192.168.0.2
  • Load balancer IP pool start:192.168.0.100
  • Load balancer IP pool end:192.168.0.150
  • Kubernetes node IP pool start:192.168.0.10
  • Kubernetes node IP pool end:192.168.0.20

デプロイが成功すると、HCI 上に3つのクラスタリソースができあがります。Cloudagent IP で設定したアドレスが利用されているのが分かります。

管理クラスタ用のリソースその1

管理クラスタ用のリソースその2

また、起動した管理クラスタ用の仮想マシンが、先ほど設定した「Kubernetes node IP pool start」と「Load balancer IP pool start」の1つ目を利用していることが見えます。

管理クラスタ用の IP アドレス

なお、作成された管理クラスタは自動的に Azure Arc enabled kubernetes として Azure にも登録されます。

ワークロードクラスタの構築

管理クラスタ用ができあがると、Windows Admin Center 上からワークロードクラスタを構築できるようになります。主な設定項目は k8s のマスターノードのサイズと台数、ワーカノードのサイズと台数です。今回はマスターノード1台、ワーカノード3台の構成にします。

ワークロードクラスタ用のサイズと台数その1

ワークロードクラスタ用のサイズと台数その2

構築が完了すると、HCI 上に仮想マシンが出来上がります。各ノードが「Kubernetes node IP pool start」を順番に利用しているのが見て取れます。また、ワークロードクラスタ用のロードバランサ VM(my-workload-cluster-load-balancer-g0ei1-246c202a)が「Load balancer IP pool start」を順番に利用しているもの見て取れます。

PS C:\Users\labadmin> $cluster = Get-ClusterNode -Cluster azshciclus.azshci.local
PS C:\Users\labadmin> Get-vm -ComputerName $cluster | Select-Object -ExpandProperty NetworkAdapters | Select-Object VMName,IPAddresses | ft -auto

VMName                                                       IPAddresses
------                                                       -----------
my-workload-cluster-default-linux-nodepool-md-fvzc9-a2bb3111 {192.168.0.13, fe80::ec:ff:fe05:3}
my-workload-cluster-default-linux-nodepool-md-fxjl5-3a5e17bd {192.168.0.14, fe80::ec:ff:fe05:4}
my-workload-cluster-default-linux-nodepool-md-nbdvb-060b25a8 {192.168.0.15, fe80::ec:ff:fe05:5}
my-workload-cluster-load-balancer-g0ei1-246c202a             {192.168.0.11, 192.168.0.101, fe80::ec:ff:fe05:1}
aks-management-cluster-1-control-plane-0-3d6cfe76            {192.168.0.10, 192.168.0.100, fe80::ec:ff:fe05:0}
my-workload-cluster-control-plane-t8gl5-9a3a4780             {192.168.0.12, fe80::ec:ff:fe05:2}

なお、作成されたワークロードクラスタも自動的に Azure Arc enabled kubernetes として Azure に登録されます。

ワークロードクラスタへの接続

ワークロードクラスタの構築が完了すると、Windows Admin Center から kubeconfig をダウンロードできるようになります。拡張子が XML にも関わらず中身は YAML というおもしろ kubeconfig です。

kubeconfig のダウンロード

ダウンロードした kubeconfig を見ると、ワークロードクラスタ用ロードバランサの IP アドレスが API になっています。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: 
    server: https://192.168.0.101:6443
  name: my-workload-cluster

ダウンロードした kubeconfig をワークロードクラスタ用ロードバランサにアクセスできる端末に配置して kubectl で読み込むと、 kubectl でワークロードクラスタを操作できるようになります。試しにノードの状態を確認してみると、Windows Admin Center で指定した通りマスターノード1台、ワーカノード3台のクラスタになっています。

PS C:\Users\labadmin> .\kubectl.exe get node
NAME              STATUS   ROLES                  AGE   VERSION
moc-lk0rlxypusb   Ready    <none>                 19h   v1.20.5
moc-lnsgg7oli7a   Ready    <none>                 19h   v1.20.5
moc-lnwss4jfizu   Ready    control-plane,master   19h   v1.20.5
moc-lv01ixhjvl9   Ready    <none>                 19h   v1.20.5
PS C:\Users\labadmin>

アプリの実行

最後に AKS on HCI 上でお馴染みの投票アプリ(Azure-Samples/azure-voting-app-redis)を実行してみます。

ワークロードクラスタ用ロードバランサに新しい IP アドレス(192.168.0.103)が割り当てられて、k8s のサービスの外部 IP として利用されていることが分かります。

PS C:\Users\labadmin\Downloads\azure-voting-app-redis-master\azure-voting-app-redis-master> Get-vm -ComputerName $cluster | Select-Object -ExpandProperty NetworkAdapters | Select-Object VMName,IPAddresses | ft -auto

VMName                                                       IPAddresses
------                                                       -----------
my-workload-cluster-default-linux-nodepool-md-fvzc9-a2bb3111 {192.168.0.13, fe80::ec:ff:fe05:3}
my-workload-cluster-default-linux-nodepool-md-fxjl5-3a5e17bd {192.168.0.14, fe80::ec:ff:fe05:4}
my-workload-cluster-default-linux-nodepool-md-nbdvb-060b25a8 {192.168.0.15, fe80::ec:ff:fe05:5}
my-workload-cluster-load-balancer-g0ei1-246c202a             {192.168.0.11, 192.168.0.101, 192.168.0.102, 192.168.0.103...}
aks-management-cluster-1-control-plane-0-3d6cfe76            {192.168.0.10, 192.168.0.100, fe80::ec:ff:fe05:0}
my-workload-cluster-control-plane-t8gl5-9a3a4780             {192.168.0.12, fe80::ec:ff:fe05:2}

投票アプリの状況

おわりに

AKS on HCI を試しました。Windows Admin Center からポチポチするだけで Hyper-V や Failover cluster と連携して k8s クラスタができあがり 、さらに k8s クラスタが Azure Arc に登録されるという良くできた仕組みでした。もしオンプレミスに Hyper-V な仮想基盤があるならば、リプレースの時点で Azure Stack HCI OS ベースの仮想基盤にしておくとオンプレでの k8s への挑戦が容易になりますね。