IP マスカレードと eBPF が GKE Autopilot で利用可能に

※この投稿は米国時間 2022 年 6 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes をデプロイし、コンテナ化されたアプリケーションでの準備が整っていると考えてください。そこで直面するひとつの問題は、多様な環境間で IP が枯渇してしまうことです。クラスタはオンプレミス クラスタまたはホストと通信する必要があります。あるいは、規則やコンプライアンスの理由から、ワークロードが RFC 1918 アドレスのみを許可するサービスと通信するかもしれません。

一般提供となった最新のネットワーキング機能を使うことで、GKE Autopilot クラスタで Pod IP をノード IP に変換することができるようになりました。

• Pod IP からノード IP に変換する IP マスカレードを実装した Egress NAT ポリシーが、GKE Autopilot 用に一般提供されています。

• eBPF に基づいた高度にプログラム可能なデータパスである Dataplane V2（DPv2）は、ネットワーク ポリシーとネットワーク ロギングをサポートしており、この度、GKE Autopilot を対象に一般提供が開始されました。

GKE Autopilot 用の Egress NAT ポリシー

Egress NAT ポリシーによって、Pod IP をノード IP アドレスにマスカレードすることが可能になります。それによって、ノードの IP アドレスをソース IP として使うことで、（通常は離れたネットワークのアイランドにある）Pod がクラスタ外で通信できます。ユーザーの中には、Pod の範囲に特別な IP（RFC 1918 以外のアドレス）を使うことで、予約済みまたはクラス E の IP 空間を活用し、IP の使用を拡大している方々がいます。Pod IP をノード IP にマスカレードする必要があるユースケースには、セキュリティやコンプライアンスの理由で、または単に互換性の理由で、オンプレミス ワークロードに戻る通信をするためのものもあります。以前は、GKE Autopilot でのマネージド Namespace の制限により、ユーザーは IP マスカレードを構成できませんでした。Egress NAT ポリシーのカスタム リソース定義（CRD）によって、ユーザー向け API を使い、GKE Autopilot クラスタでの IP マスカレードを行うことが可能になりました。

「運用オーバーヘッドを削減し、コストを削減できる可能性があるため、GKE Autopilot を使っています。Egress NAT ポリシーを通じた IP マスカレードの追加により、オンプレミスのデータとシステムへのアクセスが可能になり、Autopilot の使用を拡大できました。」 - American Family Insurance、エンジニアリング マネージャー Joey Brown 氏

Google の長期目標は、GKE と Anthos のプラットフォーム間で同じ API と機能セットを持つことです。Anthos で Egress NAT ポリシーを拡張することで、Namespace やラベルといった K8s のリソースに基づいた NAT の機能を提供しています。GKE Autopilot クラスタにおけるこの新しい Egress NAT ポリシーにより、ソース NAT の管理を始めることができます。今回のリリースで、Google はロードマップの最初のマイルストーンを達成するための第一歩を踏み出しました。

Cloud Composer 2 は、Apache Airflow をベースに構築されたマネージド ワークフロー オーケストレーション サービスで、ユーザーから見えないところで GKE Autopilot を使用します。Cloud Composer 2 のユーザーも、Egress NAT ポリシーの導入により多様な環境と通信できるというメリットを享受できます。

「GCP の一部として Cloud Composer を大いに活用しています。GKE クラスタに RFC 1918 以外のアドレス空間を使うことで、IP の枯渇に対処しています。Egress NAT ポリシーによって、Cloud Composer 2 で IP マスカレードを使用できるようになりました。Cloud Composer 2 の RFC 1918 以外のアドレスを使うワークロードで、より幅広い Equifax アプリケーションに API 呼び出しを行うことができるようになりました。Cloud Composer 2 で Egress NAT ポリシーを使うことで、より多くのアプリケーションを GCP で利用可能にしたいと考えています。」– Equifax 社サイト信頼性エンジニア - スペシャリスト Siddharth Shekhar 氏

DPv2 のバージョンが 1.22.7-gke.1500 以降または 1.23.4-gke.1600 以降の GKE Autopilot クラスタにおいて、Egress NAT ポリシーの一般提供が開始されました。Egress NAT ポリシーの構成例については、GKE ドキュメントにある入門ガイドをご覧ください。

Dataplane V2（DPv2）を備えた GKE Autopilot

クラスタ ワークロードを分離し、いつネットワーク ポリシーが適用されるのか理解したいと考えたことはありますか？GKE Autopilot では、コンテナ ネットワーキングに Dataplane V2（DPv2）を使っています。これは、eBPF に基づいて Google のインフラストラクチャに統合されたデータパスです。この高度なデータプレーンを使うことで、GKE Autopilot のユーザーは、ネットワーク ポリシーとネットワーク ポリシー ロギングといった機能を利用できます。

DPv2 がサポートされるようになることで、GKE Autopilot クラスタでも、GKE Standard クラスタが現在 DPv2 から得ている次のメリットを得ることができるようになります。

• Kubernetes ネットワーク ポリシーを通じたセキュリティ

• iptables と kube-proxy の実装を削除することによるスケーラビリティ

• ネットワーク ポリシー ロギングによる運用上のメリット

• Anthos と GKE 環境での整合性

ネットワーク ポリシー ロギングによって、セキュリティ チームがログを監査し、既存のネットワーク ポリシーに基づいて許可または拒否されたトラフィック フローを理解できます。ネットワーク ポリシー ロギングは、GKE クラスタ上のオブジェクトとして構成され、さまざまなパラメータごとにフィルタされます。以下は、拒否されたアクセスから取得したログエントリの例です。

ネットワーク ポリシー ログは、Cloud Logging に自動的にアップロードされ、Cloud コンソールのログ エクスプローラを通じて取得できます。ネットワーク ポリシーの指標も Dataplane v2 で利用可能なため、ネットワーク ポリシー ロギングが使えない場合でも、ポリシーのイベント指標をモニタリングできます。

GKE Autopilot では、GKE バージョン 1.22.7-gke.1500 以降または 1.23.4-gke.1600 以降で新しく作成されたクラスタすべてに DPv2 を使います。Dataplane V2 の詳細については、GKE Dataplane V2 ドキュメントをご覧ください。

DPv2 が有効な GKE Autopilot を使い始めるには、次の gcloud コマンドを入力するだけです。

GKE Autopilot について詳しくは、概要ページをご確認ください。