SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

AKS on Azure Stack HCI 検証方法 Tips

leave a comment

AKS on Azure Stack HCI を Windows Server 2019 の 1 ノード環境ではありますが、1 台起動したままにすることができそうなので、この機会に勉強を兼ねてメモを残しておきたいと思います。

AKS on Azure Stack HCI は、検証用途であれば 1 台の Windows Server 2019 上で動作させることができます。(Azure のサポート内で AKS on Azure Stack HCI のサポートを受ける場合は、OS に Azure Stack HCI OS を使用していたほうがスムーズになりますので、リソースに余裕がある場合は、HCI OS で環境を構築していたほうが良いかと)

image

64 GB / 4 Core (HT : 8 Core) の NUC が 1 台あれば、構築することができ、Windows Server 上で Kubernetes を展開することができます。

私のような今まで Windows をメインに触ってきたエンジニアでも Kubernetes の検証環境を容易に作ることができますので、k8s の勉強環境にも活用できるかと。

基本的には、Azure Stack HCI の Azure Kubernetes Service のドキュメント のドキュメントを確認しながら、勉強した内容を適宜更新していきたいと思います。

私の場合は、仕事の領域が「SQL Server のデータベースエンジン」となりますので、AKS on HCI を使用するのは、Azure Arc Enabled SQL Managed Instance を検証することが目的であり、Enabled SQL Managed Instance 観点の情報も記載しています。

検証環境

私は、手元で手軽に確認ができるように、NUC 上に構築をしています。

それ以外にも Azure VM 上に Azure Stack HCI を構築して検証を行うという方法をとることもでき、構築方法については次のドキュメントで公開されています。

上記の評価ガイドは、入れ子になった仮想化 (Nested Virtualization : Nested Hyper-V) を使用した環境になるため、Azure コンピューティング ユニット (ACU) で Nested Hyper-V に対応した ACU を選択する必要がありますが、手元に環境を用意できない場合は Azure を使用するのも一つの方法ではないでしょうか。

検証環境では CPU コア数 / メモリ数が少ないかと思いますので、Pod don’t run, insufficient resources に記載されている「kubectl describe node」を使用したリソースの割り当て状況の確認についても方法を覚えておくと便利かと。

1 台の NUC ですと、複数の Pod を起動するには、CPU がちょっと厳しいかもしれません。

image

 

サポートされている Kubernetes のバージョン

AKS on HCI でサポートされている Kubernetes のバージョンは「Get-AksHciKubernetesVersion」で取得することができ、2021/8/4 時点では、v1.18.14 / v1.18.17 / v1.19.7 / v1.19.9 / v1.20.2 / v1.20.5 を利用することができます。

本投稿を記載している時点では、Admin Center から展開を行った場合は、v1.20.5 がデフォルトで選択された状態になっています。

Azure Arc Enabled Data Controller がサポートする最小バージョンの Kubernetes は、Overview: Create the Azure Arc-enabled data controller に記載されているバージョン (投稿時点では v1.19) となりますので、1.8 系を使用する機会は少ないのではないでしょうか。

基本構成

基本的な構成については、次のドキュメントを見ながら確認することになるかと思います。

AKS on Azure Stack HCI では、Management Cluster と、Workload Cluster の 2 つの Kubernetes クラスターが構築されます。

image

Management Cluster は AKS on HCI を展開した際に最初に作成される k8s のクラスターであり、1 ノードの k8s として構成が行われます。
この環境はユーザーのワークロードを実行するためではなく、Admin Center や Azure との接続で利用されているものとなるかと。

ユーザーワークロードについては、Management Cluster 展開後に作成する Kubbernetes クラスターである、Workload Cluster を使用することになります。

image

Supported resource limits, VM sizes, and regions に記載されていますが、現在の構成の構成としては次の内容が上限となっているようです。

image

AKS on HCI 上に Kubernetes クラスターは 4 環境まで作成することができるようですので、用途に応じた複数のクラスターを準備するということも可能なようですね。

複数台の Workload クラスターの構築方法

現状の Workload Cluster は、

  • 1 台のロードバランサー用の仮想マシン
  • 1,3,5 台のコントロールプレーン (Kubernetes Master ノード) 用の仮想マシン
  • Linux プール用仮想マシン (Kubernetes Worker ノード)
  • Windows プール用仮想マシン (Kubernetes Worker ノード)

で構成が行われます。

Linux プール / Windows プールの Worker ノードは混在させることが可能ですが、現時点では、Admin Center からデプロイした場合、各ノードは 1 台ずつしか作成ができないようでした。(Preview 時の制限がそのまま生きているようです….。)

複数の Worker ノードを構成したい場合は、New-AksHciCluster を使用する必要があるようです。

New-AksHciCluster -Name "my-workload-cluster" `
    -controlPlaneNodeCount 1 `
    -linuxNodeCount 2 `
    -controlplaneVmSize "Standard_A4_v2" `
    -loadBalancerVmSize "Standard_A2_v2" `
    -linuxNodeVmSize "Standard_D4s_v3"

 

コマンドレット経由で作成を行うことで、複数の Worker ノードで構築を行うことが可能です。

image

Azure Arc Enabled Kubernetes への登録

Admin Center で作成した場合は、Azure Arc Enabled Kubernetes への登録を同時にに行うことができます。

しかし、New-AksHciCluster で Workload クラスターを構築した場合、Arc への登録は自動的に行われないようです。

そのため、次のようなコマンドで登録を行う必要があります。

az connectedk8s connect --name my-workload-cluster `
--resource-group AKSonHCI `
--location eastus `
--distribution aks_workload `
--infrastructure azure_stack_hci `
--debug --verbose

 

検証で何回か Azure Arc Enabled Kubernetes への登録 / 削除を繰り返していて、kubeconfig の既定の名前空間を以前検証していたものに指定していたまま (今回は arc) ですと、

Error: create: failed to create: namespaces “arc” not found

というようなエラーが発生し、Azure への接続がうまくできないようなので、上記のようなエラーが出た場合は現在のコンテキストの既定の名前空間を存在するものに変えるか、ダミーで名前空間を作成しておけば回避できるかと。

connectedk8s を実行し、Azure Arc Enabled Kubernetes に正常に登録が行われている場合、Workload Cluster 上には、azure-arc の namespace で Pod が作成され、Portal でも接続が行われた状態となります。

この状態になっていない場合は、接続ができていないと考えたほうが良いかと思います。

image

管理用コマンド

AKS on Azure Stack HCI の管理は AksHci コマンドレット が提供されていますので、AKS on Azure Stack HCI を展開している Windows サーバー上にコマンドレットをインストールして管理を行うことになるかと思います。

(このコマンドレットをリモートから直接実行する方法がわからず)

トラブルシューティングのドキュメントツリー内に記載がされているのですが、Connect with SSH to Windows or Linux worker nodes for maintenance and troubleshooting によるアクセスも提供されており、SSH を使用して、構成されている各仮想マシンに SSH 経由でアクセスを行うことが可能です。

Management Cluster / Workload Cluster ともに、kubectl で接続を行うことができますので、k8s の一般的な操作も、もちろん可能です。

SSH については、AKS on Azure Stack ACI を構築したホスト OS 上の 「AksHCI\.ssh」の秘密鍵を使用することで各ノードに接続を行うことができます。

kubectl については「Get-AksHciCredential」をホスト OS 上で実行することで、kubectl で使用するコンフィグが取得できますので、こちらを使用することで各 k8s の情報を取得することが可能です。(SSH でノードにログインして kubectl を実行しても情報は取得可能です)

使用されている Linux

AKS on Azure Stack HCI は Linux の仮想マシンを Hyper-V 上に展開し、k8s が構成されます。

使用されている Linux のディストリビューションですが、次の内容となるようです。

image

AKS on Azure Stack HCI で展開される Linux は、基本的に、Microsoft の Linux ディストリビューションとなる CBL-Mariner (CBL : Common Base Linux) が使用されているようです。

Wikipedia の CBL-Mariner を確認したら、AKS on Azure Stack HCI でも使用されていることが記載されていますね。

Microsoft’s Internal Linux Distribution “CBL-Mariner” Continues Maturing も見るとよさそうですね。

パッケージ管理には、rpm が使用されており、yum を使って、https://packages.microsoft.com/cbl-mariner/1.0/prod/base/x86_64/rpms/ のパッケージをインストールできるようです。

CBL-Mariner のインストール用 ISO 等の作成方法は CBL-Mariner Linux 1.0 Released by Microsoft, Here’s How to Install it を確認するとよいかと。(wiki にも書かれています)

 

k8s のノード情報としては次のようになります。

こちらでも CBL-Mariner で各ノードが起動していることが確認できますね。

image

Container Runtime としては、現時点では docker となっているんですかね？

AKS クラスターの構成 では、AKS は 1.19 以降は containerd が使用されているようですので、AKS on Azure Stack HCI もコンテナーランタイムはそのうち変わるのかもしれませんね。

2021 August Update からコンテナーランタイムが containerd に変更されています。

docker cli ではなく ctr cli を使用して k8s.io の namespace に対してコマンドを実行することで情報が取得できます。

ctr -n k8s.io i ls

 

 

ロードバランサー

AKS on HCI には、デフォルトで Service として、 Loadbalancer を使用することができるようになっています。

以前、Big Data Cluster 用に Ubuntu 上に Kubernetes を構築していた際には、METALLB を Loadbalancer として使用していたので、AKS on HCI がどのように Loadbalancer を構築しているのか気になったので軽く確認してみたところ、HAProxy が使用されているようですね。

Loadbalancer の Serivce を作成すると、ロードバランサー用の仮想マシンに、Service で使用される IP アドレス (以下の画像であれば、10.5.x.x) が追加で設定されます。

image

haproxy.cfg も自動的に追加されて、ロードバランサーとして動作しているようです。

image

IP の追加や haproxy.cfg への設定追加をどのように実施しているのかについてはまだ、把握できていないのですが、IP のリダイレクトについては HA Proxy が活用されているようですね。

 

CNI

ネットワークについては、次のドキュメントで確認することになるかと。

CNI プラグインとしては、Flannel / Calico を使用することができます。

 

CSI

CSI ドライバーについては、Windows Server 2019 を 1 台で使用した場合は、disk.csi.akshci.com がプロビジョナーとして使用され、AKS を動作させている Windows サーバー上で起動している「wssdcloudagent.exe」を経由して、ローカルディスクが活用されているようです。

ディスクの CSI ドライバーについては、AKS on Azure Stack HCI ディスクの Container Storage Interface (CSI) ドライバーを使用する で解説がされており、Windows Server 2019 を 1 台使用して展開した場合は、これがデフォルトのストレージクラスとなります。

ほかには、AKS on Azure Stack HCI ファイルの Container Storage Interface (CSI) ドライバーを使用する の手順も公開されており、SMB / CIFS についても利用することができます。

AKS on HCI 使用されている CSI ドライバーそのものではないと思いますが、以下がベースになっているのではないでしょうか。

AKS on HCI 標準の CSI Driver (disk.csi.akhci.com) を使用する場合の注意点

AKS on HCI で非 root アカウントにより実行されるコンテナー(non root container) を実行する場合、Configure storage (Azure Stack HCI with AKS-HCI) に記載されていますが、パーミッションの設定については注意をする必要があるようです。

AKS on HCI は disk.csi.akshci.com の CSI Drivers を使用する Storage Class がデフォルトで使用されるように設定が行われています。

SR で教えていただいたのですが、AKS on HCI を Admin Center から構築した場合 Kubernetes のバージョンは v1.20.5 がデフォルトで選択された状態となっており、v1.19 から導入された、CSI Driver fsGroup Support の設定で動作が行われるようです。

現状の SQL Server on Linux や、Azure Arc Enabled Data Services のコンテナイメージはいくつかのコンテナーが非 root コンテナーとして動作が行われます。

このようなコンテナーで default のストレージクラスでマウントされた Persistent Volume (PV) に対して書き込みが行われると、Permission Denied となり、コンテナーの初期処理で書き込みが必要なものなどは、CrashLoopBackOff を繰り返し、Pod が正常に起動しないというような事象が発生します。

Azure Arc Enabled Data Service を例にすると、データコントローラーを起動する場合などがこれに該当します。

発生している問題

2021/8/2 時点で、AKS on HCI をデフォルトの状態で展開をし、データコントローラーを任意の方法で展開 (ポータルから直接接続 / Azure Data Studio から間接接続 等) をしようとすると、次のようにコントローラー用の Pod が CrashLoopBackOff を繰り返し起動しない状態となります。

image

起動が完了していない Pod 内のコンテナーのログを確認してみると、「2021/08/02 05:20:43 Unable to initialize agent. Error: mkdir /var/log/agent: permission denied」というようなパーミッションのエラーが発生していることが確認できます。

image

ここでマウントをしているディレクトリは PV になるのですが、非 root コンテナーとしてプロセスを起動しており、PV に対して書き込みを行っているコンテナーについては同様の事象が発生するかと思います。

AKS on HCI の Disk Provisioner で作成されたボリュームは Linux Pool のノードの「/var/lib/kubelet/plugins/kubernetes.io/csi/pv」配下にマウントが行われます。

「pvc-」配下のディレクトリのパーミッションを確認してみると、「755」が設定されていることが確認できます。

image

今回、起動に失敗している「controldb-0」の Pod は非 root コンテナーとして起動されるのですが、SecurityContext としては、次のような設定が行われています。

image

設定されているユーザー / グループでは、マウントした pv に対して書き込みの権限がないため、Permission Denied が発生し、Pod の期の同を完了することができないという事象が発生します。

この解決方法ですが、Configure storage (Azure Stack HCI with AKS-HCI) に記載されています。

Kubernets 1.19 以降では、CSI Driver fsGroup Support が追加されており、この設定には次のように記載されています。

  • None: Indicates that volumes will be mounted with no modifications, as the CSI volume driver does not support these operations.
  • File: Indicates that the CSI volume driver supports volume ownership and permission change via fsGroup, and Kubernetes may use fsGroup to change permissions and ownership of the volume to match user requested fsGroup in the pod’s SecurityPolicy regardless of fstype or access mode.
  • ReadWriteOnceWithFSType: Indicates that volumes will be examined to determine if volume ownership and permissions should be modified to match the pod’s security policy. Changes will only occur if the fsType is defined and the persistent volume’s accessModes contains ReadWriteOnce. . 

次のいずれかの対応が実施すると、適切な権限でマウントされ、書き込みはエラーとならないはずです。

image

 

CSI Driver の Spec を変更 (v1.20 以降 で利用可能)

一つ目の解決方法が、CSI Driver の fsGroupPolicy を変更するものです。

デフォルトでは、「fsGroupPolicy: ReadWriteOnceWithFSType」が設定されています。

image

これを、「ReadWriteOnceWithFSType」から「File」に変更することで対応ができそうです。

Azure Arc Enabled Data Services で使用される Pod については、「fsGroup」が指定されていそうですので、CSI Driver の設定を変更することで、適切なパーミッションが設定されるかと。

File に変更した場合は、Storage Class の Spec は変更しなくても対応ができるかと思います。

CSI Driver の Spec は変更せずに、対応を行いたい場合には、Storage Class の Spec を変更します。

Storage Class の Spec を変更 (v1.19 以降で利用可能)

もう一つの方法が Storage Class に「fsType: ext4」を追加する方法です。デフォルトの状態では、fsType が指定されていないため、ext4 を設定しています。

こちらの方法では、CSI Driver の fsGroupPolicy が ReadWriteOnceWithFsType の状態でも対応を行うことができます。

image

略語

  • KVA : Kubernetes 仮想アプライアンス (Kubernetes Virtual Appliance)
  • MOC : Microsoft オンプレミス クラウド サービス (Microsoft On-premiss Cloud Service)

 

ドキュメント

AKS on Azure Stack HCI : 基本ドキュメント

GitHub で公開されているドキュメント

Azure Arc Enabled SQL Managed Instance

AKS を使用したシステム / アプリケーションの構築例

Kubernetes

Docker

Containerd

Share

Written by Masayuki.Ozawa

7月 15th, 2021 at 12:13 am

Posted in Azure Arc,Azure Stack HCI

Tagged with ,

«
»

Leave a Reply