Standard クラスタでの IP マスカレード エージェントの構成

Standard

このページでは、Google Kubernetes Engine（GKE）標準モードで作成されたクラスタを、ip-masq-agent で IP マスカレードを実行するように構成する方法について説明します。GKE Autopilot モードでの IP マスカレードの詳細については、下り（外向き）NAT ポリシーを使用して Autopilot クラスタで IP マスカレードを構成するをご覧ください。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
  注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

• 既存の Standard クラスタがあることを確認する。必要な場合は、Standard クラスタを作成します。

ip-masq-agent ステータスのチェック

このセクションでは、次の方法について説明します。

• クラスタで ip-masq-agent DaemonSet が実行されているかどうか確認します。
• ip-masq-agent ConfigMap リソースを確認します。

ip-masq-agent DaemonSet を確認する

クラスタで ip-masq-agent DaemonSet が実行されているかどうかを確認するには、Google Cloud CLI または Google Cloud コンソールを使用します。

gcloud

1. クラスタの認証情報を取得します。

   gcloud container clusters get-credentials CLUSTER_NAME
   

   CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

2. kube-system Namespace で ip-masq-agent を検索します。

   kubectl get daemonsets/ip-masq-agent -n kube-system
   

   ip-masq-agent DaemonSet が存在する場合、出力は次のようになります。

   NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   ip-masq-agent   3         3         3       3            3           <none>          13d
   

   ip-masq-agent DaemonSet が存在しない場合、出力は次のようになります。

   Error from server (NotFound): daemonsets.apps "ip-masq-agent" not found
   

3. ip-masq-agent DaemonSet が最新バージョンを実行しているかどうかを確認します。

   kubectl get daemonsets/ip-masq-agent -n kube-system -o jsonpath='{.spec.template.spec.containers[].image}'
   

   このコマンドから、ip-masq-agent DaemonSet のデプロイで指定されているものと同じコンテナ イメージが返される必要があります。

コンソール

1. Google Cloud コンソールの [ワークロード] ページに移動します。

   [ワークロード] に移動

2. [ フィルタ] で、次の操作を行います。

   1. をクリックして、[システム オブジェクトである: False] フィルタをクリアします。
   2. 次のプロパティをフィルタリングします。
      • 名前: ip-masq-agent
      • クラスタ: クラスタの名前。

   ip-masq-agent DaemonSet が存在する場合、このテーブルに DaemonSet レコードが表示されます。ip-masq-agent DaemonSet が存在しない場合、行は表示されません。

ip-masq-agent ConfigMap を作成して ip-masq-agent DaemonSet をデプロイするには、ip-masq-agent の構成とデプロイをご覧ください。

ip-masq-agent ConfigMap を確認する

クラスタで ip-masq-agent ConfigMap が実行されているかどうかを確認するには、Google Cloud CLI または Google Cloud コンソールを使用します。

gcloud

1. クラスタの認証情報を取得します。

   gcloud container clusters get-credentials CLUSTER_NAME
   

   CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

2. kube-system Namespace の ip-masq-agent ConfigMap を記述します。

   kubectl describe configmaps/ip-masq-agent -n kube-system
   

   ip-masq-agent ConfigMap が存在する場合、出力は次のようになります。

   Name:         ip-masq-agent
   Namespace:    kube-system
   Labels:       <none>
   Annotations:  <none>
   
   Data
   ====
   config:
   ----
   nonMasqueradeCIDRs:
     - 198.15.5.92/24
     - 10.0.0.0/8
   masqLinkLocal: false
   resyncInterval: 60s
   
   BinaryData
   ====
   
   Events:  <none>
   

   ip-masq-agent ConfigMap が存在しない場合、出力は次のようになります。

   Error from server (NotFound): configmaps "ip-masq-agent" not found
   

コンソール

1. Google Cloud コンソールの [構成] ページに移動します。

   [構成] に移動

2. [ フィルタ] で、次の操作を行います。

   1. をクリックして、[システム オブジェクトである: False] フィルタをクリアします。
   2. 次のプロパティをフィルタリングします。
      • 名前: ip-masq-agent
      • クラスタ: クラスタの名前。

   ip-masq-agent ConfigMap が存在する場合、テーブルに ConfigMap レコードが表示されます。ip-masq-agent ConfigMap が存在しない場合、行は表示されません。

クラスタにすでに ip-masq-agent ConfigMap がある場合は、構成してデプロイできます。

ip-masq-agent の構成とデプロイ

このセクションでは、ip-masq-agent ConfigMap を作成または編集する方法と、ip-masq-agent DaemonSet をデプロイまたは削除する方法について説明します。必要なタスクを判断するには、まず、クラスタにすでに ip-masq-agent ConfigMap と ip-masq-agent DaemonSet が存在するかどうかを確認する必要があります。

ip-masq-agent ConfigMap の作成

ip-masq-agent ConfigMap を作成する手順は以下のとおりです。クラスタにすでに ip-masq-agent ConfigMap がある場合は、既存の ip-masq-agent ConfigMap を編集します。

1. 次のテンプレートを使用して構成ファイルを作成し、ローカルに保存します。この構成ファイルのローカルコピーには、任意の名前を使用できます。

   nonMasqueradeCIDRs:
     - CIDR_1
     - CIDR_2
   masqLinkLocal: false
   resyncInterval: SYNC_INTERVALUNIT_OF_TIME
   

   次のように置き換えます。

   • CIDR_1、CIDR_2: CIDR 形式の IP アドレス範囲。これらの宛先にパケットが送信されると、クラスタで IP アドレスの送信元がマスカレードされず、送信元 Pod の IP アドレスが保持されます。3 つ以上の CIDR が必要な場合は、nonMasqueradeCIDRs リストに同じ形式でエントリを追加します。少なくとも、nonMasqueradeCIDRs プロパティには、クラスタのノードと Pod の IP アドレス範囲を含める必要があります。

   • SYNC_INTERVAL: 各 ip-masq-agent Pod が ip-masq-agent ConfigMap の内容をチェックし、ローカルの /etc/config/ip-masq-agent ファイルに変更を書き込むまでの時間。デフォルトは 60 です。

   • UNIT_OF_TIME: resyncInterval の時間単位。有効な値は、s（秒）または ms（ミリ秒）などです。デフォルトは s です。

   リンクのローカル IPv4 アドレスに送信されるパケットのマスカレードを有効にする必要がない限り、masqLinkLocal を false（デフォルト）に設定します。詳細については、リンクローカルの宛先へのマスカレードをご覧ください。

   注意: カスタム nonMasqueradeCIDRs には、少なくともクラスタのノードと Pod IP のアドレス範囲を含める必要があります。これは、ノード内の可視化を有効にする場合に特に重要です。nonMasqueradeCIDRs に Pod の IP アドレス範囲がなく、ノード内の可視化が有効になっている場合、Pod 間の通信が適切に行われません。

2. ConfigMap リソースを作成します。

   kubectl create configmap ip-masq-agent \
      --namespace=kube-system \
      --from-file=config=LOCAL_CONFIG_FILE_PATH
   

   LOCAL_CONFIG_FILE_PATH は、前の手順で作成した構成ファイルのパスで置き換えます。

   注: ボリュームとして解析するには、ip-masq-agent DaemonSet が ip-masq-agent ConfigMap の読み取り時に想定する名前付きキーに ConfigMap のコンテンツが関連付けられている必要があります。次の例で、標準の ip-masq-agent DaemonSet の場合、キーは config です。--from-file=config=LOCAL_CONFIG_FILE_PATH を指定すると、IP マスカレード構成情報が config キーに関連付けられます。

3. kube-system Namespace の ip-masq-agent ConfigMap を記述します。

   kubectl describe configmaps/ip-masq-agent -n kube-system
   

   出力は次のようになります。

   Name:         ip-masq-agent
   Namespace:    kube-system
   Labels:       <none>
   Annotations:  <none>
   
   Data
   ====
   config:
   ----
   nonMasqueradeCIDRs:
     - 198.15.5.92/24
     - 10.0.0.0/8
   masqLinkLocal: false
   resyncInterval: 60s
   
   BinaryData
   ====
   Events:  <none>
   
   

   この出力には、構成が変更された config パラメータが含まれます。これで ip-masq-agent DeamonSet をデプロイできるようになりました。

既存の ip-masq-agent ConfigMap を編集する

既存の ip-masq-agent ConfigMap は、次の手順で変更できます。

1. テキスト エディタで ConfigMap を開きます。

   kubectl edit configmap ip-masq-agent --namespace=kube-system
   

2. ConfigMap ファイルを編集します。

   apiVersion: v1
   data:
     config: |
       nonMasqueradeCIDRs:
         - CIDR_1
         - CIDR_2
       masqLinkLocal: false
       resyncInterval: SYNC_INTERVALUNIT_OF_TIME
   kind: ConfigMap
   metadata:
     name: ip-masq-agent
     namespace: kube-system
   

   次のように置き換えます。

   • CIDR_1、CIDR_2: CIDR 形式の IP アドレス範囲。これらの宛先にパケットが送信されると、クラスタで IP アドレスの送信元がマスカレードされず、送信元 Pod の IP アドレスが保持されます。3 つ以上の CIDR が必要な場合は、nonMasqueradeCIDRs リストに同じ形式でエントリを追加します。少なくとも、nonMasqueradeCIDRs プロパティには、クラスタのノードと Pod の IP アドレス範囲を含める必要があります。

   • SYNC_INTERVAL: 各 ip-masq-agent Pod が ip-masq-agent ConfigMap の内容をチェックし、ローカルの /etc/config/ip-masq-agent ファイルに変更を書き込むまでの時間。デフォルトは 60 です。

   • UNIT_OF_TIME: resyncInterval の時間単位。有効な値は、s（秒）または ms（ミリ秒）などです。デフォルトは s です。

   リンクのローカル IPv4 アドレスに送信されるパケットのマスカレードを有効にする必要がない限り、masqLinkLocal を false（デフォルト）に設定します。詳細については、リンクローカルの宛先へのマスカレードをご覧ください。

   注意: カスタム nonMasqueradeCIDRs には、少なくともクラスタのノードと Pod IP のアドレス範囲を含める必要があります。これは、ノード内の可視化を有効にする場合に特に重要です。nonMasqueradeCIDRs に Pod の IP アドレス範囲がなく、ノード内の可視化が有効になっている場合、Pod 間の通信が適切に行われません。

3. kube-system Namespace の ip-masq-agent ConfigMap を記述します。

   kubectl describe configmaps/ip-masq-agent -n kube-system
   

   出力は次のようになります。

   Name:         ip-masq-agent
   Namespace:    kube-system
   Labels:       <none>
   Annotations:  <none>
   
   Data
   ====
   config:
   ----
   nonMasqueradeCIDRs:
     - 198.15.5.92/24
     - 10.0.0.0/8
   masqLinkLocal: false
   resyncInterval: 60s
   
   BinaryData
   ====
   
   Events:  <none>
   

   この出力には、作成したファイルの構成値と一致する config パラメータが含まれます。

ip-masq-agent DaemonSet のデプロイ

ip-masq-agent ConfigMap を作成または編集したら、ip-masq-agent DaemonSet をデプロイします。

1. 次のマニフェストを YAML ファイルとして保存します。

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: ip-masq-agent
     namespace: kube-system
   spec:
     selector:
       matchLabels:
         k8s-app: ip-masq-agent
     template:
       metadata:
         labels:
           k8s-app: ip-masq-agent
       spec:
         hostNetwork: true
         containers:
         - name: ip-masq-agent
           image: gke.gcr.io/ip-masq-agent:v2.12.3-gke.4@sha256:b5db41ddaf863b660da330322714f668101482b528829c50c53229d901d11af5
           args:
           - --v=2
           - --logtostderr=false
           - --log_file=/dev/stdout
           - --log_file_max_size=0
           # The masq-chain must be IP-MASQ
           - --masq-chain=IP-MASQ
           # To non-masquerade reserved IP ranges by default,
           # uncomment the following line.
           # - --nomasq-all-reserved-ranges
           # Must be set to false when using Dataplane V2.
           - --random-fully=false
           securityContext:
             privileged: false
             capabilities:
               drop: ["ALL"]
               add: ["NET_ADMIN", "NET_RAW"]
             allowPrivilegeEscalation: false
             seccompProfile:
               type: RuntimeDefault
           volumeMounts:
           - name: config-volume
             mountPath: /etc/config
         volumes:
         - name: config-volume
           configMap:
             name: ip-masq-agent
             optional: true
             items:
             - key: config
               path: ip-masq-agent
         tolerations:
         - effect: NoSchedule
           operator: Exists
         - effect: NoExecute
           operator: Exists
         - key: "CriticalAddonsOnly"
           operator: "Exists"

   このマニフェストは、コンテナの volumeMount で指定されたようにマウントされるボリュームを config-volume という名前で作成します。

   このマニフェストを編集する必要がある場合は、次の条件を考慮してください。

   • ボリューム名は任意ですが、コンテナの volumeMount 名と一致している必要があります。

   • ConfigMap の名前は、Pod の config-volume Volume で参照されている configMap の名前と一致する必要があります。

   • チェーン（--masq-chain）の名前は IP-MASQ である必要があります。それ以外の場合、GKE はデフォルトのマスカレード ルールをオーバーライドしません。

   • DaemonSet Pod は ip-masq-agent ファイルから読み取ります。ip-masq-agent ファイルのコンテンツは、ConfigMap に含まれる config キーの値になります。

   • デフォルトでマスカレード以外の予約済み IP 範囲を使用する場合は、arg セクションの - --nomasq-all-reserved-ranges 行のコメント化を解除します。

2. DaemonSet をデプロイします。

   kubectl apply -f LOCAL_FILE_PATH
   

   LOCAL_FILE_PATH は、前の手順で作成したファイルのパスに置き換えます。

作成した ip-masq-agent DaemonSet は手動で更新できます。詳細については、DaemonSet の更新をご覧ください。

ip-masq-agent の削除

このセクションでは、ip-masq-agent DaemonSet と ip-masq-agent ConfigMap を削除する方法を説明します。ip-masq-agent を削除しても、ノードの既存の IP マスカレード設定は元に戻りません。

ip-masq-agent DaemonSet の削除

ip-masq-agent DaemonSet を手動で作成した場合は、次のコマンドを実行して削除できます。

kubectl delete daemonsets ip-masq-agent -n kube-system

注: ip-masq-agent DaemonSet が自動的にデプロイされた場合は、GKE により自動的に再作成されます。

ip-masq-agent ConfigMap を削除する

ip-masq-agent ConfigMap を完全に削除するには、次のコマンドを実行します。

kubectl delete configmap ip-masq-agent -n kube-system

トラブルシューティング

以降のセクションでは、トラブルシューティングのアドバイスを紹介します。

一般的なトラブルシューティング

次の手順は、IP アドレス マスカレーディングに関する問題の診断に役立ちます。

• ip-masq-agent のステータスを確認します。ConfigMap が定義されていない場合、デフォルトの宛先へのトラフィックはすべてマスカレードされず、その Pod の IP アドレスを維持します。他の宛先へのトラフィックはそのノードの IP アドレスを維持します。
• DaemonSet で指定されている ip-masq-agent イメージのバージョンを確認します。ip-masq-agent DaemonSet のバージョンが最新でない場合は、デプロイ手順に沿って DaemonSet を更新します。
• 影響を受けたノードで sudo iptables -t nat -L IP-MASQ コマンドを実行し、NAT IP テーブルに IP-MASQ チェーンが正しく設定されているかどうかを確認します。ConfigMap で定義された nonMasqueradeCIDRs が NAT IP テーブルに表示されない場合は、ConfigMap の作成に使用された構成ファイルに入力ミスがないことを確認します。
• 宛先でノードと Pod の両方の IP アドレス範囲が許可されていることを確認します。
• ノードまたは Pod からトラフィックにアクセスできない場合は、接続テストを実施します。

問題: Pod の IP アドレスがノードの IP アドレスに変更される

IP マスカレード エージェントを使用すると、Pod が外部の宛先と通信するときに、Pod の送信元 IP アドレスがノードの IP アドレスを予期せず使用することがあります。

この問題は、カスタム SNAT（送信元ネットワーク アドレス変換）リストが存在しないか、または不完全な場合に発生します。IP マスカレード エージェントを使用するときに、ConfigMap が存在しない場合や nonMasqueradeCIDRs リストが含まれていない場合は、クラスタのデフォルトの SNAT が使用されます。パケットが Pod から送信されると、デフォルトの SNAT は送信元 IP アドレスを Pod の IP アドレスからノードの内部 IP アドレスに変更します。SNAT の詳細については、IP マスカレード エージェントをご覧ください。

この問題を解決するには、ip-masq-agent ConfigMap で nonMasqueradeCIDRs リストを定義して、カスタム SNAT リストを構成します。

1. ip-masq-agent ConfigMap を開きます。

   kubectl edit configmap ip-masq-agent --namespace=kube-system
   

2. ConfigMap 内の nonMasqueradeCIDRs リストを確認します。nonMasqueradeCIDRs リストが存在し、完全である必要があります。例:

   ...
   nonMasqueradeCIDRs:
     - 35.100.0.0/16
   ...
   

3. リストが存在しない場合や不完全な場合は、nonMasqueradeCIDRs リストを追加または変更して、送信元 Pod の IP アドレスを保持する宛先 IP 範囲を含めます。このリストには、Cloud NAT を使用するアドレスも含める必要があります。

   外部トラフィックに SNAT を使用しない場合は、nonMasqueradeCIDRs フィールドを 0.0.0.0/0 に設定します。例:

   ...
   nonMasqueradeCIDRs:
     - 0.0.0.0/0
   ...
   

   トラフィックが SNAT を使用しない場合、Pod から送信されるすべてのパケットは、宛先に関係なく、送信元 IP アドレスとして Pod の IP アドレスを保持します。

4. Pod からのアウトバウンド パケットの送信元 IP アドレスを確認します。このアドレスを確認するには、パケット キャプチャを取得します。取得できない場合は、次のコマンドを使用してノードの IP アドレスを確認します。これは、SNAT の対象となるアウトバウンド パケットの送信元 IP アドレスになります。

   kubectl get nodes -o wide
   

次のステップ

• Egress NAT ポリシーを使用して Autopilot クラスタに IP マスカレードを構成する方法を学習する。
• VPC ネイティブ クラスタを作成する方法を学習する。
• GKE ネットワークの概要を読む。
• 承認済みネットワークの構成について学習する。