AKSのネットワーク構成は基本以下の2種類が存在します。
- kubenet(既定)
- Azure CNI
kubenet
kubenetはAKSのネットワーク構成の既定値となります。Kubernetesのネットワークデフォルト仕様でもあります。
仕組みイメージ図(公式資料引用)
kubenetの仕組みは、公式資料では、以下の構成となります。
kubenetの特徴
- ノードのみが仮想ネットワーク(サブネット)からIPを取得する
- PodはKubernetesの内部ネットワークからIPを取得する
- Kubernetes内部ネットワークから仮想ネットワークへの通信はNATで変換される(通信するため)
※Kubernetesの内部ネットワークはKubernetes機能によって作られる。仮想ネットワークと論理的に異なるIPレンジを使う
制限事項
- AKSクラスタの仮想ネットワークは、インターネット送信(Outbound)を許可する必要がある
- 同じサブネットに複数のAKSを構築してはいけない(kubenetのみ)
- AKSの仮想ネットワーク、Service、PodのIPレンジは以下のものを使用不可
- 169.254.0.0/16
- 172.30.0.0/16
- 172.31.0.0/16
- 192.0.2.0/24
- AKSに使用するサービス プリンシパル(GCPのサービスアカウントと類似)は、ネットワーク共同作成者以上の権限が必要。詳細権限は以下:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
- AKSクラスタごとに、最大400ノードまでサポート(UDRのルートが最大400まで)
- ノードごとに、Pod作成数範囲は10 ~ 110個(デフォルト110)
- ノードプール作成時のみ設定可能
メリットとデメリット
-
メリット:
- Podは仮想ネットワークのIPを使用しないため、ネットワークの設計に影響しない
-
デメリット:
- ノードをまたぐPod間の(IPでの)直接通信はできない(基本Pod間の通信はClusterIP経由が必要)
- 内部ネットワークに通信するに、追加のホップがあるため、通信ラグがわずかに増加する
- ルートテーブルとユーザー定義ルート(UDR)が必要なため、操作が複雑
- PodのIP指定は不可
- 複数のkubenet(AKS)を一つのサブネットに構成できない
- 以下の機能はサポートしない
- Azureネットワークポリシー(Calicoネットワークポリシーはサポートする)
- Windowsノードプール
- 仮想ノードアドオン
使用理由
以下の基準を考えて、使用するかを検討したほうがいいかと思います。
- ルートテーブルとユーザー定義ルート(UDR)の管理できる
- PodのIP枯渇に心配がある、または計画できない
- Azure ネットワークポリシー、Windowsノードプールを使う予定はない
Azure CNI(プラグイン)
Azure CNIはAzure特有のKubernetesプラグインで、Podが直接仮想ネットワークのIPを取得するネットワーク構成となります。
※ブリッジで実現できている
Azure CNIの特徴
- ノードとPodがサブネットからIPを取得する
- Podが仮想ネットワークのIPを持つため、直接外のサービスなどと通信可能(NAT変換なし)
- ノード単位でIP数を確保する
- ノードの最大Pod数の属性をベースにノード作成時のIP数を計算する。不足の場合は作成できない
制限事項
- AKSクラスタの仮想ネットワークは、インターネット送信(Outbound)を許可する必要がある
- AKSの仮想ネットワーク、Service、PodのIPレンジは以下のものを使用不可
- 169.254.0.0/16
- 172.30.0.0/16
- 172.31.0.0/16
- 192.0.2.0/24
- AKSに使用するサービス プリンシパル(GCPのサービスアカウントと類似)は、ネットワーク共同作成者以上の権限が必要。詳細権限は以下:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
- サービス プリンシパルの代わりに、システム割り当てのマネージド ID を使用可能(Azure CNIのみ)
- AKSのサブネットは委任されたサブネットにできない(Azure CNIのみ)
- 委任されたサブネット:PaaSサービスをサブネットと紐づく機能(専用サービスで使用するサブネットにする)
- ノードごとに、Pod作成数範囲は10 ~ 250個(デフォルト30)
- ノードプール作成時のみ設定可能
IPの計画
Azure CNIはPodもサブネットのIPを消費するため、サブネットのIP数を計画しないと、後々IPが足りないことになったら、クラスタを再作成する羽目になってしまいます。
ここでは、IP計画の計算方法をご紹介します。
Azure CNIでは、ノードをベースにIPを消費します。というのは、ノード属性に「最大Pod数」という設定値があります。
1ノードあたりのIP消費数は:
1ノードあたり消費するIP数 = 最大Pod数 + 1
※ "+ 1"はノード自身のIP
AKSはアップグレードを実施する必要があるため、1ノード分多くIPを用意する必要があります。
そのため、AKSの合計必要IP数は:
環境に必要なIP数 = 1ノードあたり消費するIP数 * (ノード数 + 1)
また、ノードが自動スケーリングの場合、最大ノード数で計算してください。
KubernetesのServiceが、もしLoadBalancerを同じサブネットにデプロイする想定でしたら、LoadBalancerのIPも足し算する必要があります。
※IP計画には影響ないですが、Podが削除され、IP開放するまでは数秒かかります。
AKSのサービスIP(ClusterIP)の計画
KubernetesのサービスIPのレンジはサブネットのIPを消費しませんが、IPレンジは仮想ネットワーク(及び接続するネットワーク)のIPレンジと重複してはいけません。
また、制限事項にも書いた通、169.254.0.0/16、172.30.0.0/16、172.31.0.0/16、または 192.0.2.0/24 を使ってはいけません。
また、以下の制限事項もあります。
- サービスのアドレスの CIDR は、/12 より小さくする必要があります。
- クラスターの DNS サービスの IP アドレスの指定
- サービスのアドレス範囲内の最初の IP アドレス (.1 など) は指定不可(サブネット範囲の最初のアドレスは、kubernetes.default.svc.cluster.local アドレスに使用される)
- Docker ブリッジのdocker0(既定値) ブリッジ、IP(既定値)は172.17.0.1/16
- docker build をAKSクラスタ上で実施するには、設定が必要
- 手動設定がお勧め(自動設定されますが、他のレンジと重複する可能性があるため)
- IPレンジはAKSのサービスIP、AKSのPodのIPとも衝突しないようにすべき
メリットとデメリット
-
メリット:
- 以下の機能をサポート
- Azureネットワークポリシー(Calicoネットワークポリシーはサポートする)
- Windowsノードプール
- 仮想ノードアドオン
- 仮想ネットワーク内部の送信元はPodのIPとなり、仮想ネットワーク外部への通信の送信元はノードのIPとなる
- ルートテーブルとユーザー定義ルート(UDR)の管理が不要
- 以下の機能をサポート
-
デメリット:
- IPの計画が必要(サブネット変更する場合、クラスタ再作成が発生する)
使用理由
以下の基準を考えて、使用するかを検討したほうがいいかと思います。
- Azureの多くの機能を使用したい(恐らく今後もCNIしか使えない機能が増えるだろう)
- PodのIP枯渇に心配がない、或いは計画可能
- Podを仮想ネットワークみたいな感じで(IPを持つ通信)通信したい
最後に
AKSのAzure CNIネットワークはGKE(GCP)の「VPCネイティブ」ネットワーク構成と似ています。
どちらも仮想ネットワークのIPをPodを使わせるためのKubernetesのプラグインです。
この機能はクラウドしか使えないといえるでしょう。
また、今回まとめた内容は以下のAzure公式ドキュメントに参考しています。
kubenet
Azure CNI
ここまで読んでいただいて、お疲れ様でした。
コメント