ルートベースとVPCネイティブ
一般的なkubernetesのPodのネットワークはクラスタ内部の仮想ネットワークで、外のNodeのネットワークと基本分離するような形です。
GCPのGKEクラスタを作成時、PodのネットワークをVPCを使用するように設定が可能です。
GKE作成時、Podネットワークの種類は以下のオプションを付けることで、選べます（後変更は不可）
--no-enable-ip-alias(ルートベース)：kubernetesのデフォルト仕様、kubernetesが作った内部ネットワークにPodを配置する--enable-ip-alias(VPCネイティブ)：VPCネットワークにPodを配置する- メリット：
- k8s内部のロードバランシングが省けれる(通信が速くなる)
- Podからは直接プライベートIP(VPC)を持つリソースと通信可能
- GCPのNEGがサポート可能
- Podは直接cloudSQL(プライベートIP)などと通信が可能
- メリット：
VPCネイティブのGKEはルートベースより新しく追加された機能で、VPCネイティブでないと使えない機能もあります。
そのため、今後GKE作成にあたり、VPCネイティブで作成することをお勧めします。
ちなみに、この設定はGKE作成のみ指定可能なので、変えたい場合は再作成(作り直し)が必要となります。
--enable-ip-aliasの場合のネットワーク構成
VPCネイティブの場合、ネットワーク構成は以下のようになります。
https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips
- すべてのノードの IP アドレスに、サブネットのプライマリ IP 範囲を使用します。
- すべての Pod IP アドレスに、1 つのセカンダリ IP 範囲を使用します。
- すべての Service（クラスタ IP）アドレスに、別のセカンダリ IP 範囲を使用します。
各種IP範囲の説明参考
GKE作成例
下記の例はGKEとサブネット同時作成するためのものとなります。
既存サブネットにGKEを作成したい場合、上記参考のリンクにてご確認いただければと思います。
GKE作成コマンド例：
# GKE作成
gcloud container clusters create <cluster-name> \
--region=<region> \
--enable-ip-alias \
--create-subnetwork name=<subnet-name>,range=<node-ip-range> \
--cluster-ipv4-cidr=<pod-ip-range> \
--services-ipv4-cidr=<services-ip-range>サブネット関係のオプションの説明：
node-ip-range：CIDR 表記の IP アドレス範囲（10.5.0.0/20 など）、または CIDR ブロックのサブネット マスクのサイズ（/20 など）です。- これは、ノードのサブネット プライマリ IP アドレス範囲を作成するために使用されます。
- 省略した場合、GKE は /20 のサイズで VPC 内で使用可能な IP 範囲を選択します。
pod-ip-range：CIDR 表記の IP アドレス範囲（10.0.0.0/14 など）、または CIDR ブロックのサブネット マスクのサイズ（/14 など）です。- これは、Pod のサブネット セカンダリ IP アドレス範囲を作成するために使用されます。
- 省略した場合、GKE はデフォルトの Pod IP 範囲のサイズである /14 を使用します。
services-ip-range：CIDR 表記の IP アドレス範囲（10.4.0.0/19 など）、または CIDR ブロックのサブネット マスクのサイズ（/19 など）です。- これは、Service のサブネット セカンダリ IP アドレス範囲を作成するために使用されます。
- 省略した場合、GKE はデフォルトの Service IP 範囲のサイズである /20 を使用します。
PodからVPCへの通信状況
Podはそれぞれのオプションにおいて、以下のようなアクセス結果が出ます。
※cloudSQL(プライベート)は外部IPを持たないcloudSQLインスタンスのことを指す。
| アクセス元↓・先→ | GCE(プライベートIP) | cloudSQL(プライベート)IP | cloudSQL(プライベート)接続名 |
|---|---|---|---|
--enable-ip-aliasのPod |
○ | ○ | × |
--no-enable-ip-aliasのPod |
○ | × | × |
※ GCEへアクセスできない場合、ファイアウォールを一応確認してみた方がいいと思います。
サイドカー方式でcloudSQLへのアクセスは以下のデメリットがあるので、どうしてもの時以外はお勧めしません。
- 外部経由でcloudSQLへアクセスするので、通信セキュリティが落ちる
- 外部通信なので、通信料がかかる
- 外部経由のため、パフォーマンスが落ちる(通信が遅い)
最後に
今回はVPCネイティブについて、簡単にご紹介しました。
上記の内容で、まだ使い方がいまいちよくわからない方は、以前書いたシナリオの記事にVPCネイティブを使っていたので、もしよければそちらもご一読いていただければと思います。
ここまで読んでいただいて、お疲れ様でした。
コメント