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


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

始める前に

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

  • Google Kubernetes Engine API を有効にする。
  • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

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
    

コンソール

  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_1CIDR_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(デフォルト)に設定します。詳細については、リンクローカルの宛先へのマスカレードをご覧ください。

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

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

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

  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_1CIDR_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(デフォルト)に設定します。詳細については、リンクローカルの宛先へのマスカレードをご覧ください。

  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.11.0-gke.23@sha256:f50757332ee45c0fb9f5856552a3ed16548c1de3c33c4e520a02d22e30af96ae
            args:
            # 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 ConfigMap を削除する

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

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

トラブルシューティング

次の手順では、トラブルシューティング情報を示します。

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

次のステップ