世界のやまさ

SEKAI NO YAMASA

Azure Container Service における設計上の注意点

Azure Container Service(ACS) にて kubernetes を作成した場合、2017/5/29現在はストレージアカウントの制限を受けるため注意して下さい。

何故かというと Azure Container Service の Agent(Node) はストレージアカウントごとに10個VMを作ります。

f:id:nnasaki:20170527103838p:plain

ストレージアカウントには下図の通り、最大IOPSとスループットの制限があります。

f:id:nnasaki:20170527104220p:plain

下図のように片方のストレージアカウントのコンテナに負荷がかかると、上限に引っかかる場合があり、もう片方のストレージアカウントに余裕があっても負荷分散が出来ません。

f:id:nnasaki:20170527104236p:plain

これを解決するための手段はストレージアカウントを意識して自分でコンテナを再配置することが必要ですが、具体的にどのようにするかはちょっと分かっていないです。

ですが、悲観的になる必要は無くて、ストレージアカウントの制限については Managed Disk(管理ディスク)が使用できるようになれば解決すると思われます。

f:id:nnasaki:20170527110329p:plain

管理ディスクを使用する場合、今すぐできる解決策と将来に期待する2つの選択肢があると思いますので、ご紹介します。

今すぐできる解決策

ACS Engine という OSS プロジェクトを利用することで、Azure Manged Disk(管理ディスク)を使用して、KubernetesやMesosとDocker Swarmをデプロイすることが出来ます。

ACS Engine については Container Service についてよく寄せられる質問 を引用します。

Azure Container Service と ACS Engine の違いは何ですか。

Azure Container Service は SLA による保証が付いた Azure サービスで、Azure Portal の各種機能、Azure コマンドライン ツール、Azure API が付属しています。 Azure Container Service を使用すると、比較的少ない選択肢を選んで構成するだけで、標準のコンテナー オーケストレーション ツールを実行するクラスターを簡単に実装して管理できます。
ACS Engine はオープンソース プロジェクトで、パワー ユーザーがクラスター構成を各レベルでカスタマイズするのに適しています。 インフラとソフトウェアの両方の構成に変更を加えることができるため、ACS Engine には SLA が用意されていません。 サポートは、Microsoft の公式チャネルではなく、GitHub のオープンソース プロジェクトを通じて提供されます。

ただし、Kubernetes の場合 PersistentVolumeClaims(PVC, 永続ボリューム) には管理ディスクは現在非対応で、1.7でサポートされる予定だそうです。

github.com

将来に期待する

Virtual Machine Scale Sets(VMSS) が管理ディスク対応になってますので、Azure Container Service も VMSS 上で構築されているため(Kubernetesは現在そうなってないけど)将来的にはサポートされると考えています。

まとめ

Azure Container Service で管理ディスクが早くサポートされると良いなぁと思います。