Kubernetesを使ったAzure上でのGridDBアプリのデプロイとスケーリング | GridDB: Open Source Time Series Database for IoT

この記事は、以前の取り組みの直接的な続きであり、ローカルのkubernetes（シングルノード）クラスタにGridDBアプリケーションをデプロイしました。このデプロイで得た知識を、同じクラスタをMicrosoftのクラウド・コンピューティング・サービスにデプロイする際に役立てたいと思います： Azureです。ほとんどの作業はすでに終わっているので、このプロジェクトをAzure上で稼働させるために必要なAzure固有の変更について簡単に説明します。

幸運なことに、AKSクラスタのセットアップは無料です。アカウントを取得したら、この記事に沿って進んでください。最後まで進めば、前回のブログで説明したシンプルなTodoアプリがAzure上でホストされ、インターネットにアクセスできる場所であればどこからでもアクセスできるようになります。

はじめに

始めるには、Microsoft Azureのアカウントを作成し、このプロジェクトに関する過去のエントリーを読んでください。また、GitHubからソースコードをクローンして、提供されている.yamlファイルを使えるようにしてください。また、自分のイメージを保存するためにDockerhubのアカウントを作成する必要があるかもしれませんが、今のところは私がDockerhubにプッシュしたイメージを使うことができます。

 $ git clone https://github.com/griddbnet/Blogs.git --branch azure_kubernetes

もう一つのオプションのステップは、Azure CLIをインストールすることで、Azureのコマンドを自分のマシンから実行できるようになり、クラウドシェルを使う必要がなくなりますが、これもオプションです。

ローカルクラスタからAzureへの変更

まず、このプロジェクトをローカルのK3sシングルノードではなく、AzureのマネージドAKSクラスタ上で実行するために必要な少量の変更について説明します。第一に、コンテナイメージをDockerhub（または他のコンテナイメージリポジトリ）で公開する必要があります。あとは特にありません。最後の違いは、永続ストレージの扱い方です。

AKSクラスタの作成

まず始めに、Microsoftチームから直接提供されているガイドに沿って説明します：これに従って、リソースグループを作成し、AKSクラスタを作成し、クラスタに接続します。そこから、自分のコンテナで踏み込むことができます。

AzureクラウドシェルかローカルのAzure CLIに接続し、Azureアカウントに接続します。

Azureリソースの作成

まず、リソースグループを作成しよう。

$ az group create --name myResourceGroup --location westus

そして実際のAKSクラスタを作成してみよう。

$ az aks create -g myResourceGroup -n myAKSCluster --enable-managed-identity --node-count 1 --enable-addons monitoring --enable-msi-auth-for-monitoring  --generate-ssh-keys

なお、シンプルかつ無料にするため、私自身はモニタリング用のアドオンを削除しましたが、残すかどうかはお好みでどうぞ。

それでは、kubectlをインストールしてクラスタに接続してみましょう（Cloud Shellを使う場合は不要です）。

$ az aks install-cli

そしてそれをつなぐ：

$ az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

そしてそれをテストする：

$ kubectl get nodes

NAME                       STATUS   ROLES   AGE     VERSION
aks-nodepool1-31718369-0   Ready    agent   6m44s   v1.12.8

これで、コマンドラインを使ってAzure AKSクラスタに直接リソースを追加する準備が整ったことになります。

Kubernetes リソースの作成

azureリソースにはgitがインストールされているので、このプロジェクトのソースコードがすべて入っているリポジトリをクローンしてください： https://github.com/griddbnet/Blogs/tree/kubernetes。3つの固有のディレクトリは、AKSクラスタに含まれるコンテナ/マイクロサービスとして実行する予定の異なるコンテナに対応しています。

K3sのローカルインスタンス上でこのプロジェクトを実行する私たちの以前の取り組みを読んでいれば、この大部分はなじみがあると思います。.yamlファイルをほとんど変更する必要はありませんでした。数少ない変更の一つは、イメージをどこからプルするかということです。

    spec:
      containers:
        - name: griddbcontainer
          image: imru/griddb-server:latest

私はすでにこれらのイメージにタグを付け、Dockerhubにプッシュして使用していますが、もしあなたがそのプロセスについて興味があるのなら：

$ docker build -t griddb-server .
$ docker tag griddb-server imru/griddb-server:latest
$ docker push imru/griddb-server:latest

イメージに変更を加えてポッドを更新したい場合は、更新したイメージをdockerhubにプッシュしてデプロイメントを削除し、更新した新しいポッドを作成するように設定し直すだけです。

つまり、基本的には各ディレクトリに入り、kubectlでcreateコマンドを実行してサービスを作成します。

$ kubectl create -f griddb-server.yaml

Azureの永続ストレージ

冒頭で永続ストレージが変更されたことを述べました。ローカルのK3sクラスタと同じように、ホストマシンを永続ストレージとして使う方法を使おうとすると、AKSのデプロイは失敗します。まずazureディスクを作成し、それをGridDBストレージの永続ストレージとして使用する必要があります。

今回のアプリケーションは非常にシンプルで小規模なので、以下のようにAzure上のボリュームを静的にプロビジョニングする：ボリュームの静的プロビジョニング。

ここでは、ディスクを作成し、そのストレージをGridDBポッドに適用するために必要なコマンドを紹介します。

まず、ノードのリソースグループを取得します。

$ az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv

Output
MC_myResourceGroup_myAKSCluster_eastus

これができたら、コマンドを使ってディスクを作成しましょう：

$ az disk create 
  --resource-group MC_myResourceGroup_myAKSCluster_eastus 
  --name myAKSDisk 
  --size-gb 1 
  --query id --output tsv

ここでは1GBの小さなディスクを作成し、yamlファイルに必要なディスクリソースIDを出力します：

/subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk。

そして、永続ボリュームを作成し、永続ボリュームのクレームを作成し、最後にgriddbデプロイyamlファイルにアタッチする必要があります。

pv-azuredisk.yaml`を作成しましょう。

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: disk.csi.azure.com
  name: pv-azuredisk
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: managed-csi
  csi:
    driver: disk.csi.azure.com
    readOnly: false
    volumeHandle: /subscriptions/<subscriptionid>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk
    volumeAttributes:
      fsType: ext4</subscriptionid>

pvc: pvc-azuredisk.yaml です。

ここで、storageClassName が standard ではなく managed-csi になっていることに気づくだろう。これは我々が望むものです！

そして

$ kubectl apply -f pv-azuredisk.yaml
$ kubectl apply -f pvc-azuredisk.yaml

output

NAME            STATUS   VOLUME         CAPACITY    ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk   Bound    pv-azuredisk   1Gi        RWO                           5s

そして、GridDBのデプロイメントyamlを作成する：

      volumes:
        - name: azure
          persistentVolumeClaim:
            claimName: pvc-azuredisk

And in the container section of our yamlそして、yamlのコンテナ・セクションに

      containers:
        - name: griddbcontainer
          image: imru/griddb-server:latest
          ports:
            - containerPort: 10001
          securityContext:
            runAsUser: 0
            runAsGroup: 0
          volumeMounts:
            - name: azure
              mountPath: /mnt/azure

GridDBのデプロイを削除して再デプロイすると、Azure AKS上に永続的なストレージを持つようになります。

Azureポータルを見ると（コマンドラインだけでなく）、以下のリソースが表示されます。

最後に

最小限の労力で、アプリケーションのローカルインスタンスから、Azure上の堅牢で強力なクラウドベースのクラスタに移行できました。Azureを初めて使う人は、オンラインポータルで自分のクラスタをノードやサービスなどと一緒に見ることができます。

If you have any questions about the blog, please create a Stack Overflow post here https://stackoverflow.com/questions/ask?tags=griddb .
Make sure that you use the “griddb” tag so our engineers can quickly reply to your questions.