Azure Kubernetes Service(ASK)上でConfluent Platformを構築してみる

はじめに

Kafkaのクラスターを構成してDeployすることは結構複雑でその分時間もかかります。
しかも、構成中にエラーが発生すればそれへの対処も必要となってさらに時間を費やすことになります。そこで、ConfluentがKubernetes環境へイベントストリーミングプラットフォームとして複数のコンポーネントを一度にデプロイする自動化ツールでオペレータというものを使用してAKS上にConfluent Platformを構築してみようと思います。

参照：https://docs.confluent.io/platform/current/tutorials/examples/kubernetes/aks-base/docs/index.html

このシナリオで構築されるコンポーネント

-AKSで実行されるKubernetesクラスタ
-シングルノードのZookeeper
-シングルノードのKafka
-シングルノードのスキーマレジストリ
-Confluent コントロールセンター(GUI)
-シングルノードのKafkaコネクタ
-Kafka-connect-datagenというモックデータを生成するインスタンス

前提条件

今回はシナリオ実行前に以下のアプリケーションとライブラリをインストールしています。

アプリケーション	今回使用したバージョン	参考URL
kubectl	1.18.0	https://kubernetes.io/docs/tasks/tools/
helm	3.1.2	https://github.com/helm/helm/releases/tag/v3.1.2
az	2.10.1	https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest

セットアップ

ここから順を追ってDeployしていきます。

ターミナルからAzureCLIを介してログインします。
az login

Azureサブスクリプションを一覧表示してこれから使用するサブスクリプションを特定します。
az account list -o table

AzureCLIを介してアクティブなAzureサブスクリプションを設定します。
az account set --subscription {{ azure subscription name }}
azure subscription nameの部分はご利用の環境に応じて読み替えて下さい。

Azureリソースグループを一覧で表示しこの例で使用するリソースグループを確認します。
az group list -o table

Confluentサンプルリポジトリのクローンを作成しディレクトリをaks-baseディレクトリに移動します。
git clone https://github.com/confluentinc/examples.git
cd examples/kubernetes/aks-base


次の手順はAKSでKubernetesクラスタを作成します。もし、既に使用するクラスタがある場合はこの手順をスキップして「検証」のセクションへ移動してください。

新しいクラスタが作成されるAzureリソースグループを選択します。
ここではAZ_RESOURCE_GROUPを変数として設定します。
以下を実行してクラスタを作成します。(環境に依存しますが、大体4~5分程度かかります。)
export AZ_RESOURCE_GROUP={{ azure resource group name }}
make aks-create-cluster
azure resource group nameの部分はご利用の環境に応じて読み替えて下さい。

クラスタが正しく作成されたことを確認します。

検証

Kubernetesクラスタを制御するためにkubectlを使用します。ローカルでkubectlが正しく構成されていることを確認するためには次のコマンドを実行します。
kubectl config current-context

実行

Confluent Platformのデモ環境を展開します。(環境に依存しますが、大体7~8分程度かかります。)
make demo
展開が終わると最後に以下のメッセージが出力されます。
✔ AKS Base Demo running

確認

KubernetesのDeployを確認します。
Deployされたコンポーネントは次の方法で表示できます。
kubectl -n operator get all
この例ではデフォルトの変数値を使用していて、以下のような結果が表示されます。

CLIでConfluent Platformを確認する。

この例ではKubernetes Ingressなしでデプロイされます。つまり、Kubernetesクラスタ内のConfluent Platformリソースに外部クライアントからアクセスすることはできません。ここではConfluent Platformサービスへのネットワーク接続を備えたclient-consoleを使用できるPodをDeployします。
kubectl -n operator exec -it client-console -- bash
ここから標準のKafkaコマンドを実行してクラスタを検証できます。

kafka-topics --bootstrap-server kafka:9071 --command-config /etc/kafka-client-properties/kafka-client.properties --list

以下console consumerでモックデータジェネレータの出力を表示できます。

kafka-console-consumer --bootstrap-server kafka:9071 --consumer.config /etc/kafka-client-properties/kafka-client.properties --topic clicks

出力例は以下のとおりとなります。

Confluent ControlCenterを確認する

Confluent Control Centerを実行(表示)するには、ローカルマシンとConfluent Control Centerサービスを実行しているKubernetesのPod間でネットワーク接続が利用可能である必要があります。このため、次のkubectlコマンドを使用してローカルホストとConfluent Control Center間のポート転送で接続します。
kubectl -n operator port-forward controlcenter-0 12345:9021
次にWebブラウザでhttp://localhost:12345 を開くと、操作可能なKafkaクラスタ、スキーマレジストリ、Kafka ConnectなどがConfluent Control Centerに表示されます。

構築した環境の破棄

クラスタ内のConfluent Platformコンポーネントを破棄するには以下を実行します。(環境に依存しますが、大体4～5分くらいかかります。)

make destroy-demo

次の方法で、すべてのリソースが削除されていることを確認できます。

kubectl -n operator get all

まとめ

KafkaをKubernetes環境へDeployすることをConfluentの機能であるオペレータを使って試してみました。多少の事前の準備を必要としますが、マルチステージング環境などでKafkaを運用する場合は本番環境へのDeployをスムーズに行えるなどメリットは大きいと思いました。
とりあえず概要はつかめたので、次はオンプレのKubernetes環境へのDeployをしたいと思います。