きなこもち.net

.NET Framework × UiPath,Orchestrator × Azure × AWS × SIer

AKS × 入門 × 規定で作成されるリソースについて調べてみた

この記事の目的

この記事では、
Azure Kubernetes Servicesのリソースを作成したとき、何がどのように作られているのか調査すること
を目的としています。


本題

★マネージドKubernetes

数クリックでk8s環境を構築して満足していましたが、
Azureのサービスについてより理解を深めたいと思います。

第一歩として、数クリックで作られたk8s環境が
どのような構成で作られているのかを見ていきたいと思います。


★出来上がったもの確認

kubernetes-first-cluster」という名前のリソースグループに、
同じ名前のk8sクラスタAKS)を作成しました。
せっかくなので、nodeは3台構成になるように設定しました。
f:id:kinakomotitti:20190522203536p:plain

作成後、「kubernetes-first-cluster」リソースグループを見ると、
nodeなどの情報はなく、AKSのリソースだけが作成されていました。
f:id:kinakomotitti:20190522203543p:plain


nodeのリソースは、AKSサービスリソースとは別の場所に作成されていました。
自動生成されたリソースグループのようです。名前は、
「MC_kubernetes-first-cluster_kubernetes-first-cluster_westus」
でした。
「MC_<リソースグループ名>_<クラスター名>_<リソースのロケーション>」
というような命名規約の様です。
今回は、リソースグループ名=クラスター名としたので、
間抜けな感じの名前になっております。

こちらのリソースグループには、
k8sのnodeとして必要な仮想マシンのリソースがまとめられていました。
VM、ディスク、ネットワークインターフェース)×3、
仮想ネットワーク、ルートテーブル、可用性セット
f:id:kinakomotitti:20190522203605p:plain

これらのAzureのサービスを使ってAKSが構成されているようです。


仮想マシンの設定について

k8sのnodeとして利用される仮想マシンの設定についてみていきます。
まず、名前は、「aks-agentpool--」という規則でなっているようです。
numberのところは、Nodeをスケールアウトした際、インクリメントされていくようです。


仮想マシンとしては、以下のような特徴がみられました。
・パブリックIPが割り当てられていない
・「azureuser」というユーザーが規定で作成されている
・なかにログインするのが難しい(後述)
・「障害ドメイン:2」「更新ドメイン:3」の可用性セットに含まれている

仮想マシンへのログイン

せっかくVMがあるのだから、中にログインして設定などを見てみたいと思いましたが、うまくいきませんでした。以下、試したけどできなかったことをメモしておきます。
1)パブリックIPを割り当ててSSH
→「Permission denied (publickey).」エラー。

2)シリアルコンソールでログイン。
→「The serial console connection to the VM encountered an error: 'Not Found'」エラー

仮想マシンのスケールアップ

VMのスケールアップ(CPUとかメモリとか増やすやつ)については、
通常は以下の方法で可能のようですが、
今回の場合は、権限回りの影響でできないような気がします。

docs.microsoft.com

そもそも、1つのNodeで実行するコンテナのスペックに合うサイズを考慮しておけば、Nodeとして動いているVMのオートスケールはやる必要もないのだと思います。

ケチって最小サイズのVMを使っていた時、Istioと一緒に自作アプリを動かすとメモリが足りなくて動作確認ができなかった現象がありました。そんなことにならないように、あらかじめ計算するのが大事です。

★Nodeのオートスケール

k8sのクラスタとして、nodeとして動いていたVMが停止したとき、
自動で復旧して、常に同じnode数をキープしてくれたら安心だと思います。
上記の要求に直接対応できる機能は見つかりませんでしたが、プレビュー版の機能である「クラスターオートスケーラー」を利用することで対応ができそうです。

===
クラスター オートスケーラー コンポーネントは、リソース制約のためにスケジュールできないクラスター内のポッドを監視できます。 問題が検出されると、アプリケーションの需要を満たすためにノードの数が増やされます。 また、実行ポッドの不足について定期的にノードがチェックされ、必要に応じてノードの数が減らされます。
===

docs.microsoft.com


クラスターオートスケーラーでは、Nodeに配置(スケジュール)できないpodを検知して、必要に応じてNodeの数を自動的に増やすことができる「クラスターオートスケーラー」と、サービス提供の維持に必要なpodを自動的に増やしてくれる「ポッドの水平オートスケーラー」の二つの機能を提供してくれます。
Nodeが死んだとき・・・というのがトリガーになるわけではありませんが、Nodeが死んだとき、そのNodeに配置されていたPodを残りのNodeに再配置することができない場合では、クラスターオートスケーラーでNodeの数を維持するように動いてくれそうです。



まとめ

AKSを作成すると、VMをはじめいろいろなリソースが指定したリソースグループとは別のリソースグループに作成されます。この別のリソースグループは、AKS作成時に自動で作成されるので、AKS作成時に指定したリソースグループに何もリソースがなくても焦らなくて大丈夫です。