JavaScriptを有効にしてください

GKEでnginxのremote_addrにクライアントIPが設定されなくなった

 ·   ·  ☕ 4 分で読めます  ·  🐈 もふもふ

GKEでnginxのremote_addrにクライアントIPが設定されなくなった

Ingressに新規Serviceのsvc-b-exampleを追加しましたがnginxのremote_addrにクライアントIPが設定されなくなりました。
svc-a-exampleとネットワークの構成は全く一緒なのですが、なぜかsvc-b-exampleだけremote_addrにNodeやpodのIPアドレスが設定されていました。

その時のnginxの設定ファイルは下記の通りです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
server {
    listen       80;
    server_name  b.example.com;
    root         /var/www/html;
    charset utf-8;

    error_page 404 /404.html;

    #remote_addrにクライアントのipアドレスを設定するための指定
    set_real_ip_from 130.211.0.0/22;
    set_real_ip_from 35.191.0.0/16;
    set_real_ip_from XXX.XXX.XXX.XXX; #LBのIPアドレス
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location / {
        index index.html;
    }
}

set_real_ip_fromの上二つのIPはターゲット プロキシ に記載のipアドレス

この設定でsvc-a-exampleremote_addrにクライアントのIPアドレスが設定されますが、svc-b-exampleには設定されなくなっていました。

svc-aとsvc-bの比較

svc-a-examplesvc-b-exampleの詳細をdescribeで確認してみます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
~/$ kubectl describe svc svc-a-example
Name:                     svc-a-example
Namespace:                hogehoge
Labels:                   app=svc-a-example
Annotations:              cloud.google.com/backend-config: {"default": "svc-a-backend-config"}
                          cloud.google.com/neg: {"ingress":true}
                          cloud.google.com/neg-status: {"network_endpoint_groups":{"80":"XXXX-XXXXXXXX-hogehoge--80-XXXXXXXX"},"zones":["asia-northeast1-b"]}
Selector:                 app=svc-a-example
Type:                     NodePort
IP Families:              <none>
IP:                       XXX.XXX.XXX.XXX
IPs:                      <none>
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  32491/TCP
Endpoints:                XXX.XXX.XXX.XXX:80,XXX.XXX.XXX.XXX:80,XXX.XXX.XXX.XXX:80 + 1 more...
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
~/$ kubectl describe svc svc-b-example
Name:                     svc-b-example
Namespace:                hogehoge
Labels:                   app=svc-b-example
Annotations:              cloud.google.com/backend-config: {"default": "svc-b-backend-config"}
Selector:                 app=svc-b-example
Type:                     NodePort
IP Families:              <none>
IP:                       XXX.XXX.XXX.XXX
IPs:                      <none>
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  32492/TCP
Endpoints:                XXX.XXX.XXX.XXX:80,XXX.XXX.XXX.XXX:80,XXX.XXX.XXX.XXX:80 + 1 more...
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

svc-b-examplenetwork_endpoint_groupsがありません。

network_endpoint_groupsについて調べてみますと、下記ページに記載がありました。
コンテナ ネイティブの負荷分散

早い話、Ingressから直接podを参照できるようにするシステムらしいです。

svc-b-exampleはIngress→Node→podになってしまっていたせいで、remote_addrにクライアントのIPが設定されていませんでした。

というわけでsvc-b-examplecloud.google.com/negアノテーションを追加しました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
apiVersion: v1
kind: Service
metadata:
  labels:
    app: svc-b-example
  name: svc-b-example
  annotations:
    cloud.google.com/backend-config: '{"default": "svc-b-backend-config"}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: svc-b-example

applyして確認するとneg-statusが追加されました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
~/$ kubectl describe svc svc-b-example
Name:                     svc-b-example
Namespace:                hogehoge
Labels:                   app=svc-b-example
Annotations:              cloud.google.com/backend-config: {"default": "svc-b-backend-config"}
                          cloud.google.com/neg: {"ingress":true}
                          cloud.google.com/neg-status: {"network_endpoint_groups":{"80":"XXXX-XXXXXXXX-hogehoge--80-XXXXXXXX"},"zones":["asia-northeast1-b"]}
Selector:                 app=svc-b-example
Type:                     NodePort
IP Families:              <none>
IP:                       XXX.XXX.XXX.XXX
IPs:                      <none>
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  32492/TCP
Endpoints:                XXX.XXX.XXX.XXX:80,XXX.XXX.XXX.XXX:80,XXX.XXX.XXX.XXX:80 + 1 more...
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

追加されましたがsvc-b-exampleアクセスできなくなりました。
Googleのガイドを読むとちゃんと記載がありました。

注意: このアノテーションを追加すると、既存の Service に新しい BackendService が作成されます。これにより、Service が一時的に停止する可能性があります。
コンテナ ネイティブの負荷分散 より一部抜粋

すぐ作成されるだろうと思っていましたが5分ぐらいアクセスできなくなりましたので、追加する際には注意しましょう。

negがデフォルトで有効になる条件

無事remote_addrにクライアントIPが設定されるようになりましたが、そもそもの話svc-b-examplenegが設定されなかった原因は何なのでしょうか。

Googleのガイドには以下の記載がありました。

コンテナ ネイティブの負荷分散は、次のすべての条件が満たされている場合、デフォルトで Services に対して有効になります。

GKE クラスタ 1.17.6-gke.7 以降で作成された Service の場合
VPC ネイティブ クラスタの使用
共有 VPC を使用しない
GKE ネットワーク ポリシーを使用しない
コンテナ ネイティブの負荷分散 より一部抜粋

この条件は満たしているはずなんですが…。
クラスタ単位の話で、同じクラスタ内で違いが出ることが不思議です。
svc-a-exampleは結構前に作ったserviceですから仕様が変わったのでしょうか。
この原因については分かっていません。

ただGoogleのガイドに、

NEG がデフォルトではないクラスタの場合でも、コンテナ ネイティブの負荷分散を使用することを強くおすすめしますが、Service ごとに明示的に有効にする必要があります。
コンテナ ネイティブの負荷分散 より一部抜粋

強くおすすめすると記載があるため、いずれの場合も使用するように設定した方がよさそうです。


スポンサーリンク

共有

もふもふ
著者
もふもふ
プログラマ。汎用系→ゲームエンジニア→Webエンジニア