BLOGAzureブログ

皆さまこんにちは、SB C&Sの八釼です。
Kubernetes(k8s)は、コンテナの運用管理やスケーリングを支援するオーケストレーション（複数あるコンテナを管理する）ツール（エンジン）として、もはやデファクトスタンダードです。しかし非常に複雑で難しいものなので、それなりに知見やスキルがないと環境を構築し運用していくことは容易ではありません。オンプレミス環境であれば尚更です。
そのためAzure基盤上に実装されたマネージドk8sサービスであるAzure Kubernetes Services(AKS)を利用する選択肢は有効です。しかし当然ながら単純にk8sを理解しているというだけでは扱うことはできず、Azure側の知見が必要不可欠です。

Kubernetes(k8s)は、コンテナの運用管理やスケーリングを支援するオーケストレーション（複数あるコンテナを管理する）ツール（エンジン）として、もはやデファクトスタンダードです。しかし非常に複雑で難しいものなので、それなりに知見やスキルがないと環境を構築し運用していくことは容易ではありません。オンプレミス環境であれば尚更です。
そのためAzure基盤上に実装されたマネージドk8sサービスであるAzure Kubernetes Services(AKS)を利用する選択肢は有効です。しかし当然ながら単純にk8sを理解しているというだけでは扱うことはできず、Azure側の知見が必要不可欠です。

そこで今回は、AKSのインフラ構成（Azureリソースの視点で見たアーキテクチャ）の概要をご紹介します。なお少々古いもので恐縮ですが、AKSがどういったサービスなのかについては本ブログにて掲載されている以下の記事をご参考ください。

• Azureブログ | Azureのコンテナサービスをより便利に使う管理ツール「AKS」

• 目次
• 1.Azureリソースの視点で見るAKS(k8s)環境
• 2.AKS環境におけるネットワークリソース
• 3.最後に

Azureリソースの視点で見るAKS(k8s)環境

一つのAKS環境に対して二つのリソースグループを用意し、それらに所属する形でk8sクラスターを構成するAzureリソースをデプロイし運用していくことになります。AKSの世界ではk8sクラスターは以下の図の通りコントロールプレーンと実行ノードという風に大きく二つに分割しますので、リソース（グループ）もk8sのコンポーネントもそのように分割されまとめられるというわけです。なお、コントロールプレーンはマネージドサービスとなっています。

出典：Kubernetes クラスターのアーキテクチャ

それぞれに含まれるk8sコンポーネントの詳細については、以下の公式ドキュメントをご確認ください。

• 公式ドキュメント | Azure Kubernetes Services (AKS) における Kubernetes の中心概念

コントロールプレーン

前述のとおりk8s環境を制御する上で重要なコンポーネントは一つのリソースグループにまとめられます。もう少し厳密に言うとこれらは抽象化された一つのAzureリソースとしてデプロイされ、指定した任意のリソースグループに所属させます。

例えば以下の画像の例では、「licensecounter-blog-aks-rg」という名前のリソースグループに「licensecounterAksCluster」という名前のリソースが所属しています。この種別「Kubernetes サービス」となっているリソースがコントロールプレーンです。

またこの画像を見ていただくとわかりますが、このリソースグループについてはコントロールプレーンリソース専用に使用しなければならないというわけではないので、他のリソースが所属していても問題ありません。

コントロールプレーンリソースはいくつかの機能（役割）を持っていますが、ざっくりとはkubectlが接続するAPIつまりこのリソース上で動作しているkube-apiserverが公開するk8s APIを提供してくれるものという理解で良いと思います。K8sの世界とのつなぎ役なわけでkubectlを使ってこのリソースに対してさまざまな命令を出しますので、身近でわかりやすいのではないでしょうか。

実行ノード（ノードプール）

こちらはユーザー側管理の領域です。K8sノードとして稼働するために必要なコンポーネント（機能）をAzure VMに搭載させているのです。つまりここでコンテナランタイムが実行され、Pod（コンテナ）つまりアプリケーションをデプロイすることになります。そしてこのリソースを中心にAKSによって管理されるリソース（周辺のさまざまなネットワークリソースなど）が一つのリソースグループとしてまとまります。

Azure portalで確認してみると、例えば以下の画像のようになっています。
なお、k8sは基本的に複数ノードを束ねてクラスターを構成します。これはAKS ( Azure ) の世界ではどうなるかというとVMSS ( Virtual Machine Scale Set ）リソースを使ったノードプールという形で実現します。

ちなみに、このリソースグループとそこに所属する各リソースはコントロールプレーンリソースデプロイ時に自動的に作成されます。リソースグループ名にもコントロールプレーンリソースが所属するリソースグループ名が含まれるので（MC_{リソースグループ名}_{AKSクラスター（コントロールプレーンリソース）名}_{リージョン名}）、どことなく関連性が見えますね。もちろんこのリソースグループ名は、任意のものを指定して作成することも可能です。

また、重要なこととしてこのリソースグループ内のリソースは、AKSが管理するリソースであるため原則としてAzureの世界から直接操作してはいけません。

AKS環境におけるネットワークリソース

ユーザー側管理の領域にはVMSSの他に周辺のさまざまなAzureのネットワークリソースが作成されることは前述しましたが、これらがk8s環境においてどのような存在となっているかを少しだけ補足します。

Azure Virtual Network ( VNet )

前述したとおりVMSS（ノードプール）を作成してAzure VM（ワーカーノード）を管理することになりますので、当然VMインスタンスが接続するVNetが必要になります。なお、ネットワーキングアーキテクチャの方式は以下のいずれかから選択することになります。

kubenet方式

AKSクラスターを作成するための既定の構成です。基本の方式と考えていただければと思います。Pod間の通信には仮想IPが利用され、Pod内→外の通信ではNAT変換が利用されます（物理ノードのIPアドレスに変換されて通信が行われます）。

端的に表すと、「 Pod 内部に独自の仮想ネットワーク空間を作る方式 」ということです。

Azure Container Networking Interface (CNI) 方式

応用の（高度な）方式です。Pod間通信、Pod内→外の通信に、VNet内のIPがそのまま利用されます。IPアドレスを多く消費することになりますが、Azureの様々なサービスとの連携や他リソースへのアクセスはしやすいです。

端的に表すと、「 PodがAzureのVNetをそのまま利用する方式 」ということです。

Azure Load Balancer

散らばっているPodにエンドポイントを割り与えIPアドレスを指定して通信したり、Podに対して負荷分散する役割があるServiceが該当します。つまりL4ロードバランサーであり、これがないとPodにアクセスすることができないので重要なリソースです。

Azure Application Gateway

クラスター外から内部サービスへのHTTPとHTTPSのルートを公開するIngressが該当します。また、仮想ホスティングやSSL終端等などの機能の提供を行う役割があります。つまりL7ロードバランサー(WAF)です。
なお、Ingressとして利用するサービスをPodとして導入しておきこれを使う方式（主に nginxを簡易WAFとして利用）と、k8s基盤の「外」にWAFを用意しこれを連携させるモジュールをIngressとして導入する方式があります。

この後者の場合においてAzureの世界ではApplication GatewayをデプロイしそのWAF機能を使用することになります。

最後に

AKSを活用することでk8sの運用をかなり楽にできますが、そもそも非常に複雑で難しいものなので正しく利用するにはそれなりに高いスキルが求められます。また現実的な運用を考える場合、AKS環境以外のAzureサービス（リソース）を使う可能性が大いにあり、AKSを含むシステムの最適な全体アーキテクチャを検討する必要があります。

このようになかなか一筋縄ではいかないAKSではありますが、弊社ではユーザー様の状況を踏まえて最適な形での導入のご支援を提供しておりますので、ぜひとも法人でのAzure 導入前の相談窓口であるAzure相談センターまでお気軽にお問い合わせください。Azure に精通したスタッフが丁寧にご回答いたします。