お試し AKS

2021/11/25に公開

はじめに

今回は Azure で AKS を試していきます。今までは VirtualBox + Vagrant で色々と検証してきました。仕事でマネージドな Kubernetes を使う機会も増えてきたので、この辺りで本腰入れて使っていこうかと思います。検証環境を提供してもらえる会社に感謝です。

構成

今回の流れは

  1. 各種コマンド実行環境準備
  2. AKS 作成
  3. コンテナデプロイ

でいきます。

こちらを参考に AKS をお試ししていきます。
https://docs.microsoft.com/ja-jp/azure/aks/kubernetes-walkthrough

実行環境について(Azure Cloud Shell)

Azure のリソースを作成する方法としては以下が候補にあります。

  • Portal サイトからマウスでぽちぽち
  • Azure CLI で。
  • Terraform などのツールで。
  • etc.

今回は Azure CLI で作成します。


また、実行環境も以下の候補があります。

  • クライアント PC で実行
  • 共有環境として踏み台サーバを構築して実行
  • Azure Cloud Shell で実行
  • etc.

今回は Azure のサービスを出来る限り利用していこうと思うので、Azure Cloud Shell で実行していきます。Azure Cloud Shell はブラウザでアクセス出来るターミナルです。

Azure Shell の特徴として、

  • ホストとなるマシンは無料
  • ターミナルは Bash または PowerShell が選択できる。
  • ホームディレクトリは Azure Files が利用されているため、データ料金がかかる。
    • Bash の場合、5 GB のイメージを使用して $HOME を永続化しているため、最低 5GB 分(2021/11/22 時点で 約¥6.82 / GiB)課金される。
    • Azure Files 価格表
  • 無操作状態が20分経過するとタイムアウトする。
  • マシンはユーザ毎に分離される。
  • マシン内のユーザは一般アカウント権限
    • sudo は使えない(バイナリファイルは置けるが、パッケージマネージャーでのパッケージ導入等はできない)

Azure Portal にログインし右上のアイコンをクリックすると、下段にターミナルが表示されます。

今回は Bash のターミナルで作業を行います。次章からは Cloud Shell を使って、azkubectl などのコマンドを実行します。

Azure Cloud Shell の詳細は以下を参照ください。
https://docs.microsoft.com/ja-jp/azure/cloud-shell/overview

AKS 作成準備

AKS 作成前にリソースグループを作成します。
今回は ResourceGroup が会社から払いだされていたのでそちらを利用しました。必要に応じて ResourceGroup を作成してください。

AKS 作成

早速、Azure Cloud Shell で AKS を作成します。
コマンド1つで AKS と共に必要なリソースが作成されます。

# AKS 作成
# -n:AKS 名
# -g:リソースグループ名
# -c:--node-count、クラスタのノード数
# -a:--enable-addons、アドオンの有効化
# --generate-ssh-keys:SSH 鍵の作成

$ az aks create -n myAKSCluster -g xxxx -c 1 -a monitoring --generate-ssh-keys

VM の作成や LB 、ストレージなどの準備もいらないので、kubeadm で k8s クラスタを作るより大分楽ですね。クラウド / マネージドサービス様様です。

AKS にアクセス

作成された AKS のリソースを確認していきます。
まずは Kubernetes アクセス用の資格情報を取得します。

# 資格情報取得
# -g:リソースグループ名
# -n:AKS クラスタ名

$ az aks get-credentials -g xxxx -n myAKSCluster
Merged "myAKSCluster" as current context in /home/zzzz/.kube/config

# 接続コンテキスト確認
$ kubectl config get-contexts
CURRENT   NAME           CLUSTER        AUTHINFO                             NAMESPACE
*         myAKSCluster   myAKSCluster   clusterUser_xxxx_myAKSCluster

# ノード情報確認
$ kubectl get node -o wide
NAME                                STATUS   ROLES   AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION     CONTAINER-RUNTIME
aks-nodepool1-26228290-vmss000000   Ready    agent   29m   v1.20.9   10.240.0.4    <none>        Ubuntu 18.04.6 LTS   5.4.0-1062-azure   containerd://1.4.9+azure

kubectl でアクセスできるようになったので、現状の Kubernetes のリソースを確認していきます。

# Namespace
$ kubectl get ns
NAME              STATUS   AGE
default           Active   36m
kube-node-lease   Active   36m
kube-public       Active   36m
kube-system       Active   36m

# Containers
$ kubectl get pod,ds,deploy -A
NAMESPACE     NAME                                      READY   STATUS    RESTARTS   AGE
kube-system   pod/azure-ip-masq-agent-ht9vn             1/1     Running   0          39m
kube-system   pod/coredns-58567c6d46-4kw8n              1/1     Running   0          40m
kube-system   pod/coredns-58567c6d46-nw895              1/1     Running   0          39m
kube-system   pod/coredns-autoscaler-54d55c8b75-txmfx   1/1     Running   0          40m
kube-system   pod/kube-proxy-9g62m                      1/1     Running   0          39m
kube-system   pod/metrics-server-569f6547dd-btknn       1/1     Running   0          40m
kube-system   pod/omsagent-rs-58ff879f9d-4wz58          1/1     Running   0          40m
kube-system   pod/omsagent-vvrtx                        2/2     Running   0          39m
kube-system   pod/tunnelfront-5ccb7df95-9dbl7           1/1     Running   0          40m

NAMESPACE     NAME                                 DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
kube-system   daemonset.apps/azure-ip-masq-agent   1         1         1       1            1           beta.kubernetes.io/os=linux   40m
kube-system   daemonset.apps/kube-proxy            1         1         1       1            1           beta.kubernetes.io/os=linux   40m
kube-system   daemonset.apps/omsagent              1         1         1       1            1           <none>                        40m
kube-system   daemonset.apps/omsagent-win          0         0         0       0            0           <none>                        40m

NAMESPACE     NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/coredns              2/2     2            2           40m
kube-system   deployment.apps/coredns-autoscaler   1/1     1            1           40m
kube-system   deployment.apps/metrics-server       1/1     1            1           40m
kube-system   deployment.apps/omsagent-rs          1/1     1            1           40m
kube-system   deployment.apps/tunnelfront          1/1     1            1           40m

CoreDNS / metrics-server などがデプロイされているのがわかりました。
kubectl top でメトリクスが確認できます。

$ kubectl top node
NAME                                CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
aks-nodepool1-26228290-vmss000000   191m         10%    1421Mi          31%

また、以下の StorageClass が定義されていました。ファイル・ディスク、およびプレミアムの有無で定義が別れているように見えます。PV 作成時に指定することで、Azure 側でボリュームを自動で用意してくれます。

$ kubectl get sc
NAME                PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
azurefile           kubernetes.io/azure-file   Delete          Immediate              true                   72m
azurefile-premium   kubernetes.io/azure-file   Delete          Immediate              true                   72m
default (default)   kubernetes.io/azure-disk   Delete          WaitForFirstConsumer   true                   72m
managed-premium     kubernetes.io/azure-disk   Delete          WaitForFirstConsumer   true                   72m

Azure Portal 上で作成されたリソースを確認します。

AKS 作成時に指定したリソースグループ

新たに作成されたリソースグループ

上記の様に AKS は指定されたリソースグループに作成されますが、Kubernetes クラスタなどのリソースについては新たに作成されたリソースグループに作成されるようです。
このあたりは以下の FAQ にも記載があります。

AKS と一緒にリソース グループが 2 つ作成されるのはなぜでしょうか?

構成まとめてみました。デフォルトだと知らない所で課金される箇所がいくつかあるので、放っておくと注意が必要かと思います。

お試しコンテナデプロイ

最後は試しにコンテナをデプロイします。

$ vi azure-vote.yaml
※マニフェストファイルは以下を参考に
https://docs.microsoft.com/ja-jp/azure/aks/kubernetes-walkthrough#run-the-application

# コンテナデプロイ
$ kubectl apply -f azure-vote.yaml
deployment.apps/azure-vote-back created
service/azure-vote-back created
deployment.apps/azure-vote-front created
service/azure-vote-front created

# デプロイリソース確認
$ kubectl get pod,svc
NAME                                    READY   STATUS    RESTARTS   AGE
pod/azure-vote-back-6c4dd64bdf-6zdhk    1/1     Running   0          80s
pod/azure-vote-front-85b4df594d-krr7z   1/1     Running   0          79s

NAME                       TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
service/azure-vote-back    ClusterIP      10.0.54.105   <none>        6379/TCP       79s
service/azure-vote-front   LoadBalancer   10.0.99.142   20.89.xxx.x   80:30881/TCP   79s
service/kubernetes         ClusterIP      10.0.0.1      <none>        443/TCP        23h

Service のタイプを LoadBalancer にすることで Azure リソースで以下の構成変更が確認できました。

細かいところは次回以降で試しながら確認してみようと思います。

さて、作成したコンテナにアクセスします。
パブリック IP アドレスが付与されているので、そちらを確認してアクセスします。

$ kubectl get svc azure-vote-front -o jsonpath="{.status.loadBalancer.ingress[0].ip}"
20.89.xxx.x

まとめ

AKS を作成して、コンテナデプロイまでを試してみました。予想以上に簡単で流石クラウド!マネージド!でした。やはり、各リソースの準備と Kubernetes のインストールがない分大分楽ですね。気になる点として、課金対象や動作などは今後確認していこうと思います。

補足

個人アカウントではなく、会社から支給されたアカウントということもあり、AKS 作成時に権限関連で何度かエラーとなりました。権限周りは弊社のブログにも参考記事があるのでご一読いただければと思います。

https://techblog.ap-com.co.jp/entry/2021/06/09/181340?utm_source=feed

Discussion