More than 5 years have passed since last update.

Microsoft Azure TechAdvent Calendar 2018Day 22

Azure Kubernetes Service(AKS)を構成するAzureリソース

Last updated at 2019-05-04Posted at 2018-12-22

1. 目的

この記事は Microsoft Azure Tech Advent Calendar 2018 の22日目の記事です。

2018年はAzure Kubernetes Service(AKS)¹,Amazon Elastic Container Service for Kubernetes (Amazon EKS)²などが一般提供となったりIBMのRedHat買収にKubernetesが鍵となっているように見られた³り、様々な企業がKubernetesへの取り組みを強めた年だったと思います。この記事を読んでくださっている皆様の中にも、一度はkubectlコマンドを打ってみた方が多いのではないでしょうか。

この記事では、そんなKubernetesのプラットフォームの一つであるAzure Kubernetes Service(AKS)が、どのようなAzureリソースで構成されているのか、Azure視点で考えてみる記事です。
Azureインフラを現在運用されていて、「AKSを使ってみたいけど、Virtual NetworkとかVirtual Machineとかとどう絡んでいるんだろう」と考えている方や、
Kubernetesは利用されていて、「AKSを使う場合にどこに気を付けなくてはならないのだろう」と考えている方に、
特に役立てばいいなと思い書いています。

ゴールは、以下の図にある構成要素がどのようにAKSを構成しているか理解を深めてもらうことです。

2. 前提

Kubernetesの基礎知識(Podとは？Nodeとは？)にはこの記事では触れません。ただし、できる限り参考URLを載せるようにしているので、そこから基礎知識は参照できるようにしたいと思います。
AKSのネットワークはkubenetを用いた"基本"ネットワークとAzure CNIを用いた"高度"ネットワークがある⁴のですが、ここでは"高度"ネットワークを前提に紹介します。

3. AKSを操作する際のリソースの動き

以下の6つを紹介します。リソースごとの深掘りは次の章で書きます。

AKSクラスタを作成する
PodがStorage Firewallを有効にしたAzure Fileをマウントする
PodがAzure Container Registry(ACR)からimageをpullする
クライアント(PCなど)がPodにアクセスする
クライアント(PCなど)がKubernetesのAPIを呼ぶ
永続化ボリュームを作成する

AKSクラスタを作成する

まずはお使いのPCなどのクライアントからAzureポータルからGUIで作ったり、Azure CLIコマンドでaz aks create を実行したりして、Azure Resource Manager(ARM)のAPIが呼ばれます。これはAKSに限らず、Virutual MachineやVirtual NetworkなどAzureのリソースに対する操作では共通です。ここではARMはAzureリソースを操作するためにAzureが用意したAPIサーバだと思ってください。

サービスプリンシパルはこの後もたびたび出てきますがとても重要な構成要素です。次の章で深掘りしますが、ここではAzureのリソースを操作するための認証情報と思ってください。

'Master'というのはKubernetesの用語です。Kubernetesリソースを操作するためのAPIサーバ(kube-apiserver)など様々な役割があります。AzureではMasterはAzure側で管理されており、利用は無料です。そして、このMasterはサービスプリンシパルのID/Passwordを持ちます。

それぞれの構成要素の働きは後述しますが、これらのリソースが作成されることでKubernetesを利用できる準備が整いました。ここでも大事なのが、Agent NodeがサービスプリンシパルのID/Passwordを持つことです。

PodがStorage Firewallを有効にしたAzure Fileをマウントする

AzureにはAzure FilesというサービスがありSMB, CIFSでの接続が可能です。Storage Firewallは指定したVirtual Networkのサブネットからのみアクセスを受け付けるなど、接続元の制限が可能です。AKSの[高度]ネットワーク⁴においてPodはVirtual NetworkのIPアドレス帯に所属しています。
Virtual Machineも同じ方法で接続元を制限したAzure Filesへ接続できるように、上記方法でPodからの接続が可能になります。ここで伝えたかったのは、Virtual Machineと近い感覚でできることは多い、ということです。ただしそうでないこともあるので、Azure IaaS運用経験者がAKSを運用する場合は注意が必要です。
サービスエンドポイントについては特に解説しなかったのですが、詳細を学びたい方はこちらをご参照ください。

PodがAzure Container Registry(ACR)からimageをpullする

Kubernetesを利用するうえで、Podが用いるDocker Containerのイメージ管理は重要です。AzureではプライベートレジストリとしてAzure Container Registry(ACR)が用意されています。プライベートレジストリですので、アクセス認証は重要となります。ここで、サービスプリンシパルを用いてログインを行うことが可能です。imagePullSecretを使用する⁵ことも可能ですが、サービスプリンシパルにACRへのアクセス権限を与えておけば特に意識することなく認証が可能です。

クライアント(PCなど)がPodにアクセスする

PodはVirtual NetworkにプライベートIPアドレスを持っているので直接プライベートIPアドレスにsshなどもできますが、たとえばWebサーバなどを作ったらインターネットからアクセスすることが一般です。厳密にはPodにアクセスという表現は正しくなくKubernetesのネットワークは複雑なのですが、Azureから見た観点としては上記の画像のように、Virtual Machineとあまり変わらず、ロードバランサーやアプリケーションゲートウェイ経由でアクセスを受けていると考えて問題ないと考えています。

クライアント(PCなど)がKubernetesのAPIを呼ぶ

AKSごとにkube-apiserver用のエンドポイントが用意されており、そこへクライアントはアクセスが可能です。エンドポイントがどのように見えるかは後述します。

永続化ボリュームを作成する

永続化ボリューム(Persistent Volume)はKubernetesの用語です。ここではストレージのリソースと思ってください。Kubernetesで使用したいリソースはKubernetesのAPIで作成要求ができます。その裏側では、上記のようにサービスプリンシパルで認証してAzureのリソースが作成されています。このように、サービスプリンシパルはKubernetesをAzure上で動かすAKSとして非常に重要な構成要素であることがわかるかと思います。

ここまでのまとめ

KubernetesをAzure上で動かすAKSではサービスプリンシパルを使用してAzureのリソースを操作しています。これはKubernetesから見るとCloud Controller Managerというコンセプトにのっとっています。サービスプリンシパルはAKSを理解するうえで重要な要素です。
また、Azure FilesのマウントやクライアントからPodへのトラフィック経路などVirtual Machineと変わらない動きもあります。Azure IaaSエンジニアがAKSを利用する場合は何が同じで何が違うのか見極めていくと理解が容易になるかと思います。

AKSを構成するAzureリソース

改めて、上記の7カテゴリに分けて紹介していきます。
なお、実際にAKSを作成された際は以下のように2つのリソースグループに分かれて配置されます。'MC_'とついているリソースグループに、追加のAgent NodeであるVirtual MachineやパブリックIPアドレスが配置されます。

構成リソース1 サービスプリンシパル

サービスプリンシパルはAzureを操作するための認証情報です。Agent Nodeに格納されているサービスプリンシパルの情報は/etc/kubernetes/azure.jsonファイルに格納されています。下記のように、「実行コマンド」機能をAgent NodeのVirtual Machineに用いることで確認できます。

サービスプリンシパルを理解するには、上記で確認したサービスプリンシパルを用いてログインしてみるのが良いかもしれません。以下のコマンドでログインできます。

# az login --service-principal --username "サービスプリンシパルID" --password "サービスプリンシパルPassword" --tenant "テナント名"

これにより、サービスプリンシパルとして実際にAzureのリソースを操作することも可能です。「サービスプリンシパルはAzureを操作するための認証情報」をより理解できるのではないでしょうか。

サービスプリンシパルにどのような権限が割り当てられているか確認するには以下のコマンドで可能です。

# az role assignment list --assignee "サービスプリンシパルID" --all

構成リソース2 Master

AKSではMasterはAzureにて管理されており、かつ無料です。ユーザはkube-apiserverのエンドポイントや認証情報を取得しすぐにKubernetesの操作に着手できます。エンドポイントは以下のように"API server address"で確認できます。

認証情報の取得は以下のコマンドで可能です。

# az aks get-credentials -g "リソースグループ名" -n "AKS名"

構成リソース3 Network

Virtual Network: アドレス空間内にPodがプライベートIPアドレスを持ちます。他のVirtual Networkと接続したりVPN Gatewayを配置してオンプレミスなどとVPN接続することも可能です⁶。
NSG(Network Security Group): Virtual Network外との通信においてアクセス制御を行います。なお、KubernetesのNetwork Policy(Podのマイクロセグメンテーション)はNSGでの制御でなくKubernetesでの設定として行います⁷。
Load Balancer: Kubernetesのリソースである'Service'が追加された際はAzureではLoad Balancerのルールが更新されます。Public IPアドレスが追加となった際もLoad BalancerのIP構成として追加されます。
Application Gateway: WAFなどをKubernetesが用いたい際に利用が可能です。また、Kubernetesのリソースである'Ingress Controller'としても利用できます⁸。
Azure DNS: AKSのアドオンである'HTTP アプリケーションルーティング'を利用することで活用できます。このアドオンを用いると、Kubernetesで作成したIngressに対し外部から解決できる名前をAzure DNSに登録できます⁹。

Load Balancerのルール更新などは、サービスプリンシパルを用いて行われます。

構成リソース4 Virtual Machine

KubernetesのAgent NodeはVirtual Machineそのものであり、Podは狭義ではVirtual Machine上のDockerコンテナといえます。たとえばAgent NodeであるVirtual Machineにssh接続することで実際にDockerコンテナが動いていることなどもみられるかと思います¹⁰。
AKSは管理されたKubernetesプラットフォームを目指しているため、Agent Nodeへの自動パッチあてなども行います。ただし、再起動はユーザにて必要となりますのでご注意ください¹¹。

構成リソース5 Container Registry

フローでも紹介しましたが、Container Registryを利用するにはサービスプリンシパルを用いての認証が必要です。しかしながら、AKSを作成する際にAzure Container Registry(ACR)が一緒に作成されるわけではないので、ユーザは自身でサービスプリンシパルへACRへの操作権限を与える必要があります。ここがAKSを使い始めた方がよく躓くポイントです。公式ドキュメントにも記載がありますので、ぜひ注意してみてください。
また、ACRはKubernetesの管理を行う上で重要なコンポーネントですので、多くの機能が日々開発され¹²、またフィードバックも多く受けてます¹³。

構成リソース6 Storage

AKSのStorageとして用いられるのはManaged DiskとAzure Filesが多いです。Managed Diskは単一のVirtual Machineとしか接続ができないため単一のAgent Nodeからの接続に用いられ、Azure Filesは複数の接続が必要な際に用いられます¹⁴。
バックアップが必要な際、現時点ではArkの利用が紹介されているようです¹⁵。

構成リソース7 その他

基本的な構成要素ではないと思うためこの記事では重点を置きませんが、その他のリソースがAKSの差別化要素だと考えています。是非注目してもらえればと思います。簡単に紹介します。

Azure Container Instance(ACI): 単体ではdockerコンテナを稼働するAzureリソースに過ぎないのですが、Virtual Kubeletと組み合わせることでAKSのVirtual Nodeとして利用できます¹⁶。構想としては、Agent Nodeをユーザが意識せず、欲しい時に必要なリソースのPodを秒課金で利用できる世界を目指しているようです¹⁷。
Azure DevOps: Visual Studio Team Service(VSTS)からリブランディングされました。これを用いることでAKSをCI/CDパイプラインへ容易に組み込めます¹⁸。
Azure Monitor for Container: Kubernetesを運用することを考えるとリソースや状態、ログの監視は不可欠です。AKSではAzureの監視サービスであるAzure Monitorとシームレスに統合しました¹⁹。2018年のアドベントカレンダーでも一般提供開始についての記事が投稿されています²⁰。

個人の意見ですが、Kubernetesはオープンソースプラットフォームであるため、基本的にはどのクラウドプラットフォームで使用してもKubernetesであることに変わりはないと考えています。極論ですが、Linux仮想マシンをどのクラウドプラットフォームで使用してもLinuxであることに変わりはないことに似ています。しかし、上記のような機能があることでクラウドプラットフォームごとの違いが出てきて面白いのではないかと思います。なお、ACIとAKSを連携するためのVirtual Kubeletはオープンソースとして開発されており、CNCFのSandBox Projectにもなっていることも面白いかと思います²¹。

まとめ

AKSが関連するAzureリソースたちが、どのようにAKSに関わっているのかを紹介してみました。クラウドプラットフォームでKubernetesを利用する際はKubernetesのことだけでなく、各クラウドプラットフォームの特性なども知る必要が出てくると思います。この記事で少しでもAKSに親しみを持っていただけたら幸いです。
気になることなどありましたら是非コメント欄に記載ください。

脚注

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up