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というモックデータを生成するインスタンス
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128268/6f5e027b-210d-317e-b7e1-efdd5fe0f50d.png)

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

|アプリケーション|今回使用したバージョン|参考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の部分はご利用の環境に応じて読み替えて下さい。

クラスタが正しく作成されたことを確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128268/582b3d60-601d-b044-9058-e30bfdbb2c22.png)
##検証
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```
この例ではデフォルトの変数値を使用していて、以下のような結果が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128268/603bafa5-3cc7-787d-cfd3-6a2a19a3849e.png)
##CLIでConfluent Platformを確認する。
この例ではKubernetes Ingressなしでデプロイされます。つまり、Kubernetesクラスタ内のConfluent Platformリソースに外部クライアントからアクセスすることはできません。ここではConfluent Platformサービスへのネットワーク接続を備えたclient-consoleを使用できるPodをDeployします。
```kubectl -n operator exec -it client-console -- bash```
ここから標準のKafkaコマンドを実行してクラスタを検証できます。

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

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

```sh
kafka-console-consumer --bootstrap-server kafka:9071 --consumer.config /etc/kafka-client-properties/kafka-client.properties --topic clicks
```
出力例は以下のとおりとなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128268/c1211841-9f04-b63c-87b6-1385c51fe297.png)
##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に表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/128268/d419ba22-aa75-b1c5-4783-2e571c438cc2.png)
##構築した環境の破棄
クラスタ内のConfluent Platformコンポーネントを破棄するには以下を実行します。(環境に依存しますが、大体4～5分くらいかかります。)

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

```sh
kubectl -n operator get all
```




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