本記事について
本記事はAzure LocalでAKSを動かしてみた際のメモです。
AKS on Azure Localにはこれまで触れてこなかったのですが、少し前にAKS on Azure LocalでのEdge RAGがプレビューリリースされたのを見て俄然興味が湧いてきた次第です。
当のEdge RAGはそこそこに潤沢なリソースを必要とするため、私の手元の環境では動作させられなかったのですが、今後のために前提となるAKS on Azure Localをデプロイした際の手順をまとめておきます。
AKS on Azure Localのデプロイ
事前準備：論理ネットワークの作成
まずは仮想マシン同様に先に論理ネットワークを作成しておきます。
AKS用途も仮想マシン用途も変わりはありませんので、通常通りに論理ネットワークを作成します。
AKSクラスターである程度のIPを消費することを考えて、広めにアドレス空間を用意しておくとよいでしょう。
AKSクラスターの作成
次にAKSクラスターを作成していきます。今回はAzureポータルからGUIで作成しました。
Azure Local VMと同じくカスタムロケーションや論理ネットワークを指定しつつ、通常のAKSクラスターと同様なパラメータを指定していきます。
ポッドのネットワークはcalicoによるオーバーレイネットワークのみのようです。
一点引っかかったのはSSHキーをクラスターを作成しながら新規作成としたところ検証のタイミングでエラーが出ました。
そのため、先にSSHキーだけ作成して既存のものを選ぶ形にしています。
作成が成功するとコントロールプレーン用のノードVMとアプリケーション用のノードVM（今回はどちらも1台ずつ）がAzure Local上で実行されています。
controle-planeノードがkubernetesのAPIサーバ等を実行しており、nodepoolがアプリケーションのデプロイ先になります。
なお、nodepoolはAzure Arcのエージェントも実行しているとのことで、必ず1つはLinuxのnodepoolが必要になるとのことです。
AKS on Azure Localへの接続
アプリケーションをデプロイするためにAKSクラスターに接続していきます。
通常のAKSであればkubeconfigを取得して、それを使ってkubectlで接続しますが、ここが少し違います。
AKS on Azure Localでは以下のコマンドでkubeconfigを取得しつつ、Azure Arc経由でトンネルを開きます。
これはAzure Arc-enabled serversにAzure Arcの機能でSSH接続する方式と同様な仕組みのようです。
インバウンドの穴あけ不要でリモートからオンプレのAKSにアクセスできるので非常に便利です。
トンネルを開いたら、別のセッションでkubectlを実行します。
kubeconfigは先ほどのコマンドでダウンロードされているので、それを指定します。
早速podをデプロイしてみます。nginxのpodを1つデプロイしてみました。
nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-test
labels:
app: nginx-test
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
次はこのpodを外部に公開する方法を試していきます。
アプリケーションを公開する
NodePort経由で公開する
AKS on Azure LocalのドキュメントではMetalLB経由で公開する手順が掲載されていますが、とりあえず手っ取りば早くNodePortで公開してpodが動作していることを確認したいと思います。
こんな感じでノードの30007番ポートをpodの80番ポートに向けるNodePortのサービスをデプロイします。
nodeport-service.yaml
apiVersion: v1
kind: Service
metadata:
name: nodeport-test
spec:
type: NodePort
selector:
app: nginx-test
ports:
- port: 8080
targetPort: 80
nodePort: 30007
デプロイに成功すると、このようにノードのIPに30007番ポートでアクセスすることでnginxのpodにアクセスできるようになりました。
MetalLB経由で公開する
次に同じpodをLoadBalancerサービス経由で公開してみます。
AKS on Azure LocalではLoadBalancerサービスにMetalLBが利用できます。
MetalLBはノードで実行されますが、公開用IPアドレスの外部への公開方法はL2 (ARP)とL3 (BGP)の2通りがあります。
BGPでの公開の方が複数ノード間での負荷分散ができますが、ネットワーク機器側でBGPの設定が必要になるため今回はシンプルなARPの方式を試します。
MetalLBの構築手順はこちらに説明があります。
MS Learn | MetalLBロードバランサーを使用する
-
MetalLBの拡張機能を有効化
まずこちらの手順を参考にAzure CLIで拡張機能を有効化します。
MS Learn | MetalLBのArc拡張機能を有効化する
なお、AzureポータルからAKSリソースの[ネットワーク]画面でも有効化できるようなのですが、私の環境では失敗したためAzure CLIを利用しました。
-
MetalLBのデプロイ
MetalLBのデプロイも同じくAzure CLIから実行しました。
基本的には手順通りで、一点注意点を上げると"addresses"の引数に指定するMetalLBに割り当てるアドレス（アドレス空間）は、単体IPのみの場合でもCIDR表記にしないとエラーが出ます。
×：192.168.10.213
○：192.168.10.213/32
デプロイに成功するとAzureポータルでMetalLBを確認できます。
-
LoadBalancerサービスのデプロイ
最後にLoadBalancerサービスをデプロイして、LoadBalancerサービスにMetalLBのIPが割り当てられていることが確認できました。lb-service.yaml
lb-service.yamlapiVersion: v1 kind: Service metadata: name: metallb-test spec: type: LoadBalancer selector: app: nginx-test ports: - port: 8080 targetPort: 80
MetalLBのIPアドレス宛てにアクセスすると、ターゲットに設定したnginxのpodで実行されているアプリケーションが表示されました。
まとめ
機能自体は22H2以前からプレビューで存在していたものですが、今回初めてAKS on Azure Localを試してみました。
AKSとAzure Arcの知識があれば大きく戸惑うことはなくドキュメントの手順でとりあえず動かすことはできました。
今回は監視サービスは無効化してAKSをデプロイしていますが、通常のAKS同様に監視サービス、管理面でクラウドのAzureサービスが利用できるのはAzure Arcの良い点ですね。
Edge RAGや最近GAし始めている？data service系のAzure ArcのサービスはこのAKS on Azure Localがベースになって動作するようなので、慣れておきたいと思います。