このページでは、Google Kubernetes Engine(GKE)Pod に永続 IP アドレスを実装する方法について説明します。カスタム永続 IP アドレス マッピングを使用して、GKE Pod ネットワークを制御できます。永続 IP アドレス、そのユースケース、メリットの詳細については、GKE Pod の永続 IP アドレスについてをご覧ください。
要件
- GKE バージョン 1.31 以降。
- Google 提供の IP アドレスを予約するか(Google 提供の IP アドレス)、お客様所有の IP アドレスを使用するか(BYOIP)を選択します。
- 割り当てられた永続 IP アドレスを認識して使用するように、Pod 内で実行されているアプリケーションを構成します。
- GKE Pod に永続 IP アドレスを実装するには、 GKE Dataplane V2 と Gateway API 対応クラスタが必要です。
制限事項
- 割り振られた永続 IP アドレスを使用するようにアプリケーションを構成します。GKE は、Pod のネットワーク インターフェースに IP アドレス構成を自動的に追加しません。
- 永続 IP アドレスを一度に 1 つの Pod に関連付けることができます。利用可能な Pod が複数ある場合、通常、GKE は一致する最新の Pod にトラフィックを送信します。ただし、GKE は、最新の Pod が正常な状態である場合にのみ、この処理を行います。これは、Pod の
Ready
条件ステータスのデフォルトがTrue
であることを意味します。この動作は、GKEIPRoute
のreactionMode
設定を使用して構成および変更できます。 - GKE は、永続 IP アドレスとして IPv4 アドレスのみをサポートしています。
- GKE は、レイヤ 3 またはデバイスタイプのマルチネットワークのみをサポートします。
- DPDK 以外のユースケースでは、永続 IP アドレスを使用した高可用性(HA)サポートはサポートされていません。
始める前に
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components update
を実行して最新のバージョンを取得する。
IP アドレスの詳細をご覧ください。
料金
次の Network Function Optimizer(NFO)機能は、GKE Enterprise が有効になっているプロジェクトのクラスタでのみサポートされます。
Google Kubernetes Engine(GKE)Enterprise エディションの有効化に適用される料金については、GKE Enterprise の料金をご覧ください。
GKE Pod に永続 IP アドレスを実装する
GKE で永続 IP アドレスを使用すると、Pod 自体が更新または移動されても、Pod に安定したネットワーク ID を割り当てることができます。
このセクションでは、GKE Pod に永続 IP アドレスを実装するワークフローを簡単に説明します。
- クラスタを作成する: Gateway API、GKE Dataplane V2 を含むクラスタを作成します。
- IP アドレスを予約する: 外部(一般公開)IP アドレスと内部(Google Cloud のみ)IP アドレスのどちらが必要かを判断し、予約します。GKE クラスタと同じリージョンを選択します。
- Gateway を作成する: 予約済みの永続 IP アドレスを保存し、クラスタ内のどの Pod がこれらの永続 IP アドレスを使用できるかに関するルール(
GKEIPRoutes
)を作成できる Kubernetes Gateway オブジェクトを構成します。 - 永続 IP アドレスのワークロードを作成または識別する: 追加のネットワークで永続 IP アドレスを使用する場合は、複数のネットワーク インターフェースを有効にして、永続 IP アドレスが存在するネットワークを定義し、永続 IP アドレスを使用する Pod を準備します。
- 選択したワークロードに GKEIPRoute オブジェクトを作成する: 永続 IP アドレスを特定の Pod に割り当てるように
GKEIPRoute
を構成します。ラベルを使用して適切な Pod をターゲットに設定できます。また、必要に応じて、Pod の変更に対するルーティング動作を構成できます。 - アプリケーションの認識を構成する: 永続 IP アドレスを積極的に使用するように Pod 内のアプリケーションを構成します。
- モニタリング: Gateway と
GKEIPRoute
オブジェクトのステータスを記録し、すべてが想定どおりに機能していることを確認します。
GKE Pod に永続 IP アドレスを実装する手順は次のとおりです。
ステップ 1: Gateway API と GKE Dataplane V2 を有効にした GKE クラスタを作成する
GKE Pod に永続 IP アドレスを実装するために必要な高度なネットワーク ルーティングと IP アドレス管理機能を有効にするには、次のように GKE Dataplane V2 クラスタを作成する必要があります。
gcloud container clusters create CLUSTER_NAME \
--cluster-version=CLUSTER_VERSION \
--enable-dataplane-v2 \
--enable-ip-alias \
--gateway-api=standard
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。CLUSTER_VERSION
: クラスタのバージョン。
ステップ 2: 永続 IP アドレスを設定する
Pod の信頼できるネットワーク ID を確立し、永続 IP アドレスを設定するには、まず、永続 IP アドレスを取得する必要があります。Google 提供の IP アドレスを予約するか、独自の IP アドレスを使用する(BYOIP)かを選択できます。
ステップ 2a: Google 提供の IP アドレスを予約する
外部 IP アドレスを予約するには、次のコマンドを実行します。
gcloud compute addresses create ADDRESS_NAME \
--region=REGION
次のように置き換えます。
ADDRESS_NAME
: このアドレスに関連付ける名前。REGION
: このアドレスを予約するリージョン。これは、IP アドレスを割り振るリソースと同じリージョンにする必要があります。注: 永続 IP アドレスのトラフィック ルーティングを処理する転送ルールはリージョンであるため、IP アドレスを予約するときにリージョンを指定する必要があります。ルーティングが正しく機能するには、IP アドレスと GKE クラスタが同じリージョンに存在する必要があります。
内部 IP アドレスを予約するには、次のコマンドを実行します。
gcloud compute addresses create ADDRESS_NAME \
--region REGION
--subnet SUBNETWORK \
--addresses IP_ADDRESS
次のように置き換えます。
ADDRESS_NAME
: 予約する 1 つ以上のアドレスの名前。複数のアドレスの場合は、各アドレスをスペースで区切ったリストで指定します。例: example-address-1 example-address-2 example-address-3REGION
: このリクエストのリージョン。SUBNETWORK
: この内部 IPv4 アドレスのサブネット。
トラフィックがプライベート ネットワーク内で正しくルーティングされるようにするには、内部 IP アドレスがクラスタのデフォルト サブネットまたは追加のネットワーク サブネットに属している必要があります。
外部 IP アドレスと内部 IP アドレスの詳細、またはコンソールを使用してアドレスを予約する方法については、静的外部 IP アドレスを予約すると静的内部 IP アドレスを予約するをご覧ください。
ステップ 2b: お客様所有 IP アドレスを使用する(BYOIP)
Google 提供の IP アドレスに依存するのではなく、お客様所有の IP アドレス(BYOIP)を使用することもできます。BYOIP は、アプリケーションに特定の IP アドレスが必要な場合や、既存のシステムを Google Cloud に移行する場合に便利です。BYOIP を使用する場合は、Google は、お客様が IP アドレス範囲を所有していることを確認します。Google Cloud に IP アドレスがインポートされた後は、それらを GKE Pod の永続 IP アドレスとして割り振ることができます。詳細については、お客様所有 IP アドレスを使用するをご覧ください。
ステップ 3: Gateway オブジェクトを作成する
Gateway オブジェクトは IP アドレスを保持し、その使用資格のある Pod を定義します。永続 IP アドレスを GKE Pod に割り当てる方法を制御するには、Gateway オブジェクトを使用します。
- 適切なクラスの Kubernetes Gateway オブジェクトを作成します。
gke-persistent-regional-external-managed
: 外部(パブリック)IP アドレス。gke-persistent-regional-internal-managed
: 内部(Google Cloud のみ)IP アドレス。
- Gateway の addresses セクションで、この Gateway が管理する永続 IP アドレス(Google 提供または BYOIP)の一覧を記述します。
Listeners
セクションで、Gateway の IP アドレスを使用できる Pod とそれに関連するGKEIPRoute
オブジェクトを決定します。Listeners
は、GKEIPRoute
オブジェクトが存在する GKEIPRoute の Namespace に基づくフィルタとして機能します。Kubernetes Namespace の選択オプションは次のとおりです。
- すべての Namespace: クラスタ内のすべての
GKEIPRoute
。 - セレクタ: 特定のラベルに一致する GKEIPRoute の Namespace 内の
GKEIPRoute
。 - 同じ Namespace: Gateway と同じ GKEIPRoute の Namespace 内の
GKEIPRoutes
のみ。
- すべての Namespace: クラスタ内のすべての
次の例では、外部永続 IP アドレスに対するクラスタ全体のアクセス権を付与し、任意の Pod で使用できるようにしています。
次のサンプル マニフェストを allowed-pod-ips.yaml
として保存します。
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
namespace: default
name: allowed-pod-ips
spec:
gatewayClassName: gke-persistent-regional-external-managed
listeners:
- name: default
port: 443
protocol: none
allowedRoutes:
namespaces:
from: All
addresses:
- value: "34.123.10.1/32"
type: "gke.networking.io/cidr"
- value: "34.123.10.2/32"
type: "gke.networking.io/cidr"
ここで
- addresses: 特定のゲートウェイによって権限が管理されている IP アドレスのリストを記述します。
- listeners:
GKEIPRoute
オブジェクトがこの Gateway を参照できる Namespace を識別するために使用されます。
マニフェストをクラスタに適用します。
kubectl apply -f allowed-pod-ips.yaml
ステップ 4: (省略可)永続 IP アドレス用の追加ネットワークを使用して、ワークロードを作成または識別する
複数のネットワークへの接続を必要とする Pod で永続 IP アドレスを使用する場合は、マルチネットワーク Pod を設定し、永続 IP アドレスが属するネットワークを表すネットワーク オブジェクトを作成できます。
ステップ 5: 選択したワークロードに GKEIPRoute
オブジェクトを作成する
選択した Pod に永続 IP アドレスを割り当てるには、GKEIPRoute
オブジェクトを作成します。
次のサンプル マニフェストを my-ip-route.yaml
として保存します。
kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
namespace: default
name: my-ip-route
spec:
parentRefs:
- name: allowed-pod-ips
namespace: default
addresses:
- value: "34.123.10.1/32"
type: "gke.networking.io/cidr"
network: default
reactionMode: ReadyCondition
podSelector: # Only one pod is selected.
matchLabels:
component: proxy
ここで
- parentRefs: 永続 IP アドレスが使用される Gateway を参照します。このフィールドは変更できません。
- addresses:
podSelector
で識別される Pod にルーティングされる永続 IP アドレスのリストを記述します。このフィールドは変更可能です。IPv4 の場合、/32 アドレスのみがサポートされます。 - podSelector: 永続 IP アドレスがルーティングされる Pod を識別するラベルを指定します。このフィールドは変更可能で、
GKEIPRoute
が配置されている同じ Namespace に適用されます。複数の Pod を選択した場合、Pod の作成時間(GKE は最新のものを選択)とreactionMode
フィールドの設定という 2 つの要素が考慮されます。 - reactionMode: 特定の Pod(
podSelector
によって選択)が作成または削除されたときのこの機能の動作を指定します。このフィールドは省略可能で、デフォルト値はReadyCondition
です。ReadyCondition
フィールドは変更できません。reactionMode
を設定すると、Pod の作成、削除、更新時にこの機能がどのように動作するかを制御できます。 - ネットワーク: 永続 IP アドレスがルーティングされる Pod のネットワーク インターフェースを参照します。このフィールドは変更できません。
マニフェストをクラスタに適用します。
kubectl apply -f my-ip-route.yaml
StatefulSet Pod に永続 IP アドレスを割り当てる
StatefulSet 内の特定のマルチネットワーク Pod に永続 IP アドレスを割り当てるには、次の例のように、Pod の予測可能なホスト名と Kubernetes の自動ラベル付けを使用します。
次のサンプル マニフェストを my-pod-ips.yaml
として保存します。
kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
namespace: proxy-ss-ns
name: my-pod-ips
spec:
parentRefs:
- name: allowed-pod-ips
namespace: default
addresses:
- value: "34.123.10.1/32"
type: "gke.networking.io/cidr"
- value: "34.123.10.2/32"
type: "gke.networking.io/cidr"
network: blue-network
reactionMode: ReadyCondition
podSelector:
matchLabels:
statefulset.kubernetes.io/pod-name: proxy-ss-1
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
namespace: proxy-ss-ns
name: proxy-ss
spec:
selector:
matchLabels:
component: proxy
serviceName: "proxy"
replicas: 3
template:
metadata:
annotations:
networking.gke.io/default-interface: 'eth0'
networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
labels:
component: proxy
spec:
containers:
- name: hello-app
image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
マニフェストをクラスタに適用します(blue-network という名前のネットワークが存在している必要があります。)。
kubectl apply -f my-pod-ips.yaml
Deployment Pod に永続 IP アドレスを割り当てる
Deployment で最新の Pod に永続 IP アドレスを割り当てるには、次の構成で GKEIPRoute
を適用します。
次のサンプル マニフェストを my-pod-ips.yaml
として保存します。
kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
namespace: proxy-deploy-ns
name: my-pod-ips
spec:
parentRefs:
- name: allowed-pod-ips
namespace: default
addresses:
- value: "34.123.10.1/32"
type: "gke.networking.io/cidr"
- value: "34.123.10.2/32"
type: "gke.networking.io/cidr"
network: blue-network # point to the right network if you intend to use persistent-ip on additional networks
reactionMode: ReadyCondition
podSelector:
matchLabels:
component: proxy
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: proxy-deploy-ns
name: proxy-deploy
spec:
selector:
matchLabels:
component: proxy
replicas: 4 # Latest Pod is used
template:
metadata:
# annotations: <- Remove these lines if the pods are not multi-nic pods
# networking.gke.io/default-interface: 'eth0'
# networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
labels:
component: proxy
spec:
containers:
- name: hello-app
image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
マニフェストをクラスタに適用します。
kubectl apply -f my-ip-route.yaml
追加のネットワークを使用している場合は、blue-network という名前のネットワークが存在していることを確認します。
ステップ 6: Pod 内で永続 IP アドレスを使用する
GKEIPRoute を使用して GKE Pod に永続 IP アドレスを割り当てても、アプリケーションで IP アドレスを使用できるわけではありません。永続 IP アドレスはネットワーク ルーティング レベルで処理されますが、Pod のデフォルト構成では認識されません。Pod 内のアドレスを認識して使用するように、アプリケーションを構成する必要があります。この操作を行うには、Pod に特権権限が必要です。
アプリケーションを構成するには、次のオプションを検討してください。
- net.ipv4.ip_nonlocal_bind: システム設定を変更して、アプリケーションがインターフェースに直接割り当てられていない IP アドレスを使用できるようにします。
- ip address add: アプリケーションのロジック内でこのコマンドを使用して、永続 IP アドレスを手動でインターフェースに追加します。
- Raw ソケット: より細かい制御が必要な場合、アプリはネットワーク スタックと直接やり取りできます(上級者むけ)。
- ユーザー空間 IP アドレス スタック: 特殊なケースでは、Pod 内で別のアプリケーションが実行され、IP アドレスを管理する場合があります(非常に高度な方法)。
ステップ 7: 永続 IP アドレスの ARP を有効にする(デフォルト ネットワークのみ)
有効な Address Resolution Protocol(ARP)リクエストとレスポンスを生成し、デフォルト ネットワークの永続 IP アドレスを使用して Pod への新しい接続を確立するには、ARP_ANNOUNCE
変数を構成する必要があります。
ARP_ANNOUNCE
変数を設定するには、Pod で次のコマンドを実行します。
echo "2" > /proc/sys/net/ipv4/conf/eth0/ARP_ANNOUNCE
ここで、ARP_ANNOUNCE
変数は ARP 通知の処理方法を制御します。これを「2」に設定すると、永続 IP アドレスの ARP 通知が送信され、ネットワーク上の他のデバイスが新しいアソシエーションについて学習できるようになります。
Pod の変更中に永続 IP アドレスの動作をカスタマイズする
このセクションでは、ターゲット Pod が作成または削除されたときに、GKE Pod の永続 IP アドレスがどのように動作するかについて説明します。GKE コントローラが、Pod と GKEIPRoute
構成をモニタリングします。更新が実行されていることを検出すると、選択した reactionMode
に応じて、永続 IP アドレスが適切な Pod に自動的に再割り当てされます。
永続 IP アドレス機能が Pod の変更を自動的に処理する方法と、使用可能な構成オプションについて理解します。
GKEIPRoute
構成の reactionMode フィールドで、ReadyCondition または Exists を選択します。IP アドレスの割り振りの速さと厳密な準備要件のどちらがアプリケーションのニーズに合っているかを考慮します。ReadyCondition
を使用して準備状況を確認している場合は、Pod に Kubernetes readiness Probe が正しく実装されていることを確認します。そうしないと、永続 IP アドレスが意図したとおりに機能しない可能性があります。- システムが正しく動作していることを確認するには、Pod のステータスと
GKEIPRoute
オブジェクトのConditions
フィールドをモニタリングすることをおすすめします。Ready
条件のtrue
ステータスは、システムが正常に動作していることを示します。
Pod の永続 IP アドレスを使用した通信のトラブルシューティングを行う
このセクションでは、Pod の永続 IP アドレスに関連する問題を解決する方法について説明します。
NoPodsFound
(一致する Pod が見つからない)
症状
GKEIPRoute
オブジェクトは、永続 IP アドレスに関連付けられている Pod を識別する podSelector
(ラベルのセット)を指定します。NoPodsFound
ステータスは、ターゲット GKEIPRoute's
Namespace 内に一致するラベルを持つ Pod がないことを示します。
考えられる原因
- ラベルが正しくない: 永続 IP アドレスを使用する Pod のラベルが間違っているか、ラベルがない可能性があります。
- Pod が存在しない:
reactionMode == Exists
の場合は、pod.Spec.nodeName
フィールドを確認して Pod がノードに割り当てられているかどうかを確認します。GKEIPRoute's
Namespace で、セレクタに一致する Pod が実行されていない可能性があります。 - Pod の準備が完了していない:
reactionMode == ReadyCondition
の場合は、Pod のステータスがREADY
かどうかを確認します。一致する Pod が存在する場合でも、Ready
状態になっていないとトラフィックを処理できないため、選択されません。
解決策
- ラベルを確認する:
GKEIPRoute's
podSelector
のラベルが、対象の Pod に適用したラベルと一致していることを再確認します。 - Pod の存在を確認する: Gateway の
Listeners
で指定されたGKEIPRoute's
Namespace に、正しいラベルを持つ Pod が存在することを確認します。reactionMode == Exists
の場合は、pod.Spec.nodeName
フィールドを確認して、Pod がノードに割り当てられているかどうかを確認します。 Pod の準備状況を確認する:
reactionMode == ReadyCondition
の場合は、Pod のステータスがREADY
かどうかを確認します。次のコマンドを使用して、Pod がReady
状態であることを確認します。kubectl get pods -n <namespace>
他の状態(保留中、エラーなど)の Pod は選択されません。
割り当てられた永続 IP アドレスで応答するように Pod を構成します。
Mutated
(一致する Pod が見つかり、永続 IP アドレスのプログラミングが進行中)
症状
GKEIPRoute
ステータスに「Mutated」と表示されます。これは、一致する Pod の永続 IP アドレス構成が進行中であることを示します。
考えられる原因:
構成中は、永続 IP アドレスの GKE データパスと Google Cloud リソースが設定され、ステータスが「Mutated」になります。
解決策:
- 待機して再試行する: ほとんどの場合、構成プロセスは短時間で自動的に完了します。待機してステータスを確認します。成功すると
Ready
に変わります。 - さらに調査する(必要に応じて): 「Mutated」ステータスが長期間続く場合は、構成エラーが原因である可能性があります。
GKEIPRoute
の他のステータス条件を確認します。- Accepted:
GKEIPRoute
の設定が有効かどうかを示します。 - DPV2Ready: ノードのデータパスが正しくプログラムされているかどうかを示します。
- GCPReady: Google Cloud リソースが想定どおりに設定されているかどうかを示します。
- Accepted:
これらの条件でエラー メッセージを探して、問題のトラブルシューティングに役立ててください。