Google によるフルマネージドサービスである GKE では Kubernetes のマスタやノードのことは理解しなくとも Kubernetes の API を使って実現したいことに集中できる。
しかし、本番運用をはじめてから「なぜ動いているのかもなぜ動かないのかも分からない」というような状態ではいざという時に困る。
特に Service がどのようにクラスタの外から Pod へのアクセスを提供しているのかはブラックボックスになっていたため、今回は GKE での Service の L3(〜L4) の挙動について Kubernetes の内外を調査した。

~~(後で図や参照情報へのリンクを追加予定)~~ 図解が出てきたので追加しなかった。

追記(2018年10月5日)

Kubernetes Engine の Network Overview が良いのでこちらも読むと良いでしょう。この記事を書いた当時は存在しなかった Alias IP が GA となり、 GCE Route に成り代わっています。
https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview

追記(2017年3年22)

この記事が書かれた当時は GKE での LoadBalancer Service の動作についてドキュメントがなく、私を含めて動作を疑問に思っている人が多かった。よって、ドキュメントとソースコードを照らし合わせつつ挙動を確認する必要があった。
現在は Google Cloud Next 2017 にてこの記事の内容の概要をカバーする Kubernetes の Co-founder & Tech-lead の Googler である Tim Hockin と Michael Rubin
による下記の発表が公開されているので、これを観ることが正しくかつ近道である。この記事で触れていない localOnly 等も解説されている。

The ins and outs of networking in Google Container Engine and Kubernetes (Google Cloud Next '17)
https://www.youtube.com/watch?v=y2bhV81MfKQ
https://speakerdeck.com/thockin/the-ins-and-outs-of-networking-in-google-container-engine

kube-proxy によって出力される iptables の中身を把握したい人には参考になるかもしれない。

追記2

この内容と上記の Google のセッションを元にスライドにして Kubernetes Meetup Tokyo #4 で発表しました。
https://speakerdeck.com/apstndb/kubernetes-false-service-hatoudong-iteirufalseka

環境

Kubernetes ver. 1.5.2(Master & Node)

GKE クラスタの初期設定

今回はネットワークを作ってその中で作業する。

$ gcloud compute networks create kube-sandbox
(省略)
$ gcloud compute firewall-rules create default-allow-ssh --network kube-sandbox --allow tcp:22
(省略)

上で作った kube-sandbox ネットワーク内に GKE クラスタを作成する。今回は単純化のためノードは1とする。

$ gcloud beta container clusters create --machine-type=g1-small --num-nodes=1 --network=kube-sandbox kube-sandbox
(省略)
NAME          ZONE          MASTER_VERSION  MASTER_IP       MACHINE_TYPE  NODE_VERSION  NUM_NODES  STATUS
kube-sandbox  asia-east1-a  1.5.2           104.199.251.51  g1-small      1.5.2         1          RUNNING

現時点で kube-sandbox ネットワークには下記のルートが自動的に設定されている。具体的なノード名等は環境ごとに違うので読み替えてほしい。

$ gcloud compute routes list --filter=network=kube-sandbox
NAME                                                            NETWORK       DEST_RANGE     NEXT_HOP                                                            PRIORITY
default-route-0febf5d565eb04b9                                  kube-sandbox  10.146.0.0/20                                                                      1000
default-route-61d48fa98847c47f                                  kube-sandbox  10.138.0.0/20                                                                      1000
default-route-73c1d7230a9f1444                                  kube-sandbox  10.128.0.0/20                                                                      1000
default-route-7cc26e9102aa6708                                  kube-sandbox  10.142.0.0/20                                                                      1000
default-route-7de16d017205e5de                                  kube-sandbox  10.132.0.0/20                                                                      1000
default-route-e3201908a50d2b01                                  kube-sandbox  0.0.0.0/0      default-internet-gateway                                            1000
default-route-fccedbefa32ce294                                  kube-sandbox  10.140.0.0/20                                                                      1000
gke-kube-sandbox-5bb78bc1-3ca8c4dd-edb8-11e6-90da-42010af00188  kube-sandbox  10.76.0.0/24   asia-east1-a/instances/gke-kube-sandbox-default-pool-88bb8656-26d1  1000

いかにも GKE な感じの gke-kube-sandbox-5bb78bc1-3ca8c4dd-edb8-11e6-90da-42010af00188 というルートができており NEXT_HOP に指定されている GCE インスタンスが作成した GKE クラスタのノードであることがわかる。
該当するインスタンスを確認する。
(表示内容の調整のため format 内でprojection を使っている。)

$ gcloud compute instances describe gke-kube-sandbox-default-pool-88bb8656-26d1 \          --format='table(name,networkInterfaces[0].networkIP, networkInterfaces[0].accessConfigs[0].natIP, tags.items.map(0).join(","):label=TAGS)'
NAME                                         NETWORK_IP  NAT_IP           TAGS
gke-kube-sandbox-default-pool-88bb8656-26d1  10.140.0.2  104.199.254.163  gke-kube-sandbox-5bb78bc1-node,goog-gke-node

対応する Kubernetes 側の Node 情報を確認する。
(デフォルトでは表示されないフィールドを抜き出すために custom-columns の中で JSONPath を使う。)

$ kubectl get node -o custom-columns='NAME:.metadata.name,EXTERNAL-IP:.status.addresses[?(@.type=="ExternalIP")].address,INTERNAL-IP:.status.addresses[?(@.type=="InternalIP")].address,POD-CIDR:.spec.podCIDR'
NAME                                          EXTERNAL-IP       INTERNAL-IP   POD-CIDR
gke-kube-sandbox-default-pool-88bb8656-26d1   104.199.254.163   10.140.0.2    10.76.0.0/24

GCE ルートの DEST_RANGE と Kubernetes Node の POD-CIDR, GCE ルートの NEXT_HOP と Kubernetes Node の NAME が対応していることが確認できた。
一応 Node の中の設定も見てみると、 POD-CIDR のアドレス範囲は cbr0 ブリッジに割り当てられていることがわかる。

$ gcloud compute ssh user@gke-kube-sandbox-default-pool-88bb8656-26d1 -- ip address show cbr0
4: cbr0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1460 qdisc htb state UP group default qlen 1000
    link/ether 0a:58:0a:4c:00:01 brd ff:ff:ff:ff:ff:ff
    inet 10.76.0.1/24 scope global cbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::a42a:16ff:fe06:38a5/64 scope link
       valid_lft forever preferred_lft forever

この記事では L2 レイヤのコンテナネットワークについては説明しないが、このブリッジにそれぞれの Pod の veth がアタッチされる。
(/24 ということは同時にIP アドレスが割り当てられる Pod は1 Node につき254個ということを意味する。 GKE に限って言えば nodeIpv4CidrSize フィールドは変更不可能なようだから、他のリソースに余裕があっても Pod の数に応じて Node をスケールする必要があるように見える。)

ここまでで Pod の IP アドレスから対象の GCE インスタンスへのルーティングが行われていることが分かる。

これらの設定は何を意味するのだろうか。
Networking によると Kubernetes のコンテナ間ネットワークの基本要件は下記の3つがある。

全てのコンテナは別の全てのコンテナと NAT なしで通信できる
全てのノードは全てのコンテナと NAT なしで通信できる
- 逆も同様(全てのコンテナは全てのノードと NAT なしで通信できる)
コンテナは自分自身の IP アドレスを他のコンテナから見えるのと同じ IP アドレスとして見ることができる

flannel 等のオーバレイネットワークでこれらの要件に対応している環境もあるが、 GCE ではオーバレイネットワークが不要としているのは、この GCE ルートの設定によるものであるようだ。

Kubernetes の世界

ここからは Kubernetes の Service がどのように動いているかについて「Debugging Services - Is the kube-proxy working?」を参考に確認していく。

kube-proxy

Service は kube-proxy による仮想 IP アドレスと kube-dns による名前解決によって実現されているが、この記事では L3(〜L4) にフォーカスするため kube-dns については特に説明しない。
kube-proxy は Kubernetes 1.2 以降は動的に iptables のルールを操作 (Proxy-mode: iptables) することで、 Linux カーネルの netfilter を使って動き、仮想 IP アドレスへのアクセスを適切に Pod に転送する。
なお、過去は名前通りユーザスペースのプロキシ (Proxy-mode: userspace) として動いていたらしい。

SSH 経由で GKE ノードの iptables のルール全体を取得するには下記のようにする。

$ gcloud compute ssh user@gke-kube-sandbox-default-pool-88bb8656-26d1 -- sudo iptables-save

操作ごとに差分のみ示す。なお著者は iptables に詳しくないので、 iptables 自体の解釈については他の記事も参考にしてほしい。

(注: Kubernetes の外に転送する ExternalName Service と複数 IP アドレスを A レコードで返す Headless Service は DNS ベースで仮想 IP アドレスを持たないのでこの記事では触れない。)

Service なし

まずは kubectl run で作った Deployment から Pod を起動する。

$ kubectl run hostnames --image=gcr.io/google_containers/serve_hostname \
                        --labels=app=hostnames \
                        --port=9376 \
                        --replicas=1
deployment "hostnames" created

下記のような IP アドレスを持った Pod が作られた。この時点だと特に iptables には変化がない。

$ kubectl get pod -o wide -l app=hostnames
NAME                         READY     STATUS    RESTARTS   AGE       IP          NODE
hostnames-3799501552-jpmdq   1/1       Running   0          6m        10.76.0.9   gke-kube-sandbox-default-pool-88bb8656-26d1

ClusterIP Service

先程の Pod に対応するの ClusterIP Service を作ってみよう。

$ kubectl expose deployment hostnames --port=80 --target-port=9376
service "hostnames" exposed

作られたものを確認してみる。 Service だけでなく Endpoints ができていることが分かる。

$ kubectl get pod,endpoints,service -o wide -l app=hostnames
NAME                            READY     STATUS    RESTARTS   AGE       IP          NODE
po/hostnames-3799501552-jpmdq   1/1       Running   0          42m       10.76.0.9   gke-kube-sandbox-default-pool-88bb8656-26d1

NAME           ENDPOINTS        AGE
ep/hostnames   10.76.0.9:9376   33m

NAME            CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE       SELECTOR
svc/hostnames   10.79.255.4   <none>        80/TCP    33m       app=hostnames

この時点で iptables には次のルールが追加されていた。

-A KUBE-SERVICES ! -s 10.76.0.0/14 -d 10.79.255.4/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.79.255.4/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-EV2NQKURMPKCP5UI
-A KUBE-SEP-EV2NQKURMPKCP5UI -s 10.76.0.9/32 -m comment --comment "default/hostnames:" -j KUBE-MARK-MASQ
-A KUBE-SEP-EV2NQKURMPKCP5UI -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.76.0.9:9376

部分ごとに見ていこう。

-A KUBE-SERVICES ! -s 10.76.0.0/14 -d 10.79.255.4/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ

10.76.0.0/14 の中以外から ClusterIP への通信は KUBE-MARK-MASQ に回されるようだ。上で確認した cbr0 のアドレス空間は 10.76.0.0/24 だが、等しくないのは何のためで、どこで設定されているのか？
設定箇所は kube-proxy の起動オプションが答えだった。ノードごとの Pod のアドレス空間の上にクラスタの Pod のアドレス空間があることが分かる。

$ gcloud compute ssh user@gke-kube-sandbox-default-pool-88bb8656-26d1 -- ps ax | grep kube-proxy
 1625 ?        Sl     1:48 kube-proxy --master=https://104.199.251.51 --kubeconfig=/var/lib/kube-proxy/kubeconfig --cluster-cidr=10.76.0.0/14 --resource-container= --v=2

KUBE-MARK-MASQ は次のように定義されている一連のルールを読むと POSTROUTING を経由して KUBE-POSTROUTING からマスカレード(NAT)するかどうかの判断のためのフラグをつける設定だとわかる。
よって、クラスタ境界を跨ぐ通信は NAT されることがわかった。

-A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING

次のルールを見てみよう。Cluster IP への通信は KUBE-SVC-* チェインに飛ぶことが分かる。

-A KUBE-SERVICES -d 10.79.255.4/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3

KUBE-SVC-* チェインは Endpoints に対応する KUBE-SEP-* に飛ぶ。

-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-EV2NQKURMPKCP5UI

KUBE-SEP-* は対象の Pod の ContainerPort に宛先の IP アドレスとポート番号を転送する。

-A KUBE-SEP-EV2NQKURMPKCP5UI -s 10.76.0.9/32 -m comment --comment "default/hostnames:" -j KUBE-MARK-MASQ
-A KUBE-SEP-EV2NQKURMPKCP5UI -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.76.0.9:9376

ここまでで、 Cluster IP へのアクセスが Service を構成する Pod へと転送されることがわかった。

Pod をスケールする

Pod をスケールした場合の変化を確認する。

$ kubectl scale deployment hostnames --replicas 2
deployment "hostnames" scaled

複数の Pod に対応する Endpoints が出来ていることがわかる。

$ kubectl get pod,endpoints,service -o wide -l app=hostnames
NAME                            READY     STATUS    RESTARTS   AGE       IP           NODE
po/hostnames-3799501552-jpmdq   1/1       Running   0          39m       10.76.0.9    gke-kube-sandbox-default-pool-88bb8656-26d1
po/hostnames-3799501552-nw2gz   1/1       Running   0          21m       10.76.0.10   gke-kube-sandbox-default-pool-88bb8656-26d1

NAME           ENDPOINTS                        AGE
ep/hostnames   10.76.0.10:9376,10.76.0.9:9376   30m

NAME            CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE       SELECTOR
svc/hostnames   10.79.255.4   <none>        80/TCP    30m       app=hostnames

この時点でできた差分は下記のようになる。

-A KUBE-SEP-BWZ646KDVNVKXICT -s 10.76.0.10/32 -m comment --comment "default/hostnames:" -j KUBE-MARK-MASQ
-A KUBE-SEP-BWZ646KDVNVKXICT -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.76.0.10:9376
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-BWZ646KDVNVKXICT

KUBE-SEP については、新しく追加された Pod に対しても同様にチェインを追加している。

-A KUBE-SEP-BWZ646KDVNVKXICT -s 10.76.0.10/32 -m comment --comment "default/hostnames:" -j KUBE-MARK-MASQ
-A KUBE-SEP-BWZ646KDVNVKXICT -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.76.0.10:9376

注目すべきは statistic module の random モードを使って 50% ずつ振り分けを行っているところだ。これにより ClusterIP はロードバランサとして働く。

-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-BWZ646KDVNVKXICT
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-EV2NQKURMPKCP5UI

単純化のためにレプリカ数は1に戻しておこう。

$ kubectl scale deployment hostnames --replicas 1
deployment "hostnames" scaled

NodePort Service

これから外に公開する Service を作ってみる。まずは Node であるインスタンスのポートを通して Service にアクセスできるようにする NodePort Service だ。
前回作った ClusterIP Service を消してから作成する。

$ kubectl delete service hostnames
service "hostnames" deleted
$ kubectl expose deployment hostnames --port=80 --target-port=9376 --type=NodePort
service "hostnames" exposed

作られたリソースを見てみる。 Service のポート 80 がノードのポート 31358 に割り当てられていることが分かる。

$ kubectl get pod,endpoints,service -o wide -l app=hostnames
NAME                            READY     STATUS    RESTARTS   AGE       IP          NODE
po/hostnames-3799501552-jpmdq   1/1       Running   0          50m       10.76.0.9   gke-kube-sandbox-default-pool-88bb8656-26d1

NAME           ENDPOINTS        AGE
ep/hostnames   10.76.0.9:9376   1m

NAME            CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE       SELECTOR
svc/hostnames   10.79.245.174   <nodes>       80:31358/TCP   1m        app=hostnames

CLUSTER-IP が設定されていることからも、 ClusterIP Service の拡張であることがわかる。
iptables には下記のようなルールが追加された。
KUBE-NODEPORTS に来たもので NodePort に割り当てられたポートあてのパケットを対応する KUBE-SVC-* で処理するルールだとわかる。

-A KUBE-NODEPORTS -p tcp -m comment --comment "default/hostnames:" -m tcp --dport 31358 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/hostnames:" -m tcp --dport 31358 -j KUBE-SVC-NWV5X2332I4OT4T3

KUBE-NODEPORTS チェインとは何かというと、 KUBE-SERVICES に来たものでノードのローカルアドレス宛てのパケットだ。

-A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS

これにより、ノードの NodePort に来たものが Service の Endpoints を構成する Pod の適切なポートに転送されることが分かる。

LoadBalancer Service (GKE 依存)

最後に LoadBalancer Service がどのように動くのかを見る。

$ kubectl delete service hostnames
service "hostnames" deleted
$ kubectl
kubectl expose deployment hostnames --port=80 --target-port=9376 --type=LoadBalancer

作られたリソースを確認する。 EXTERNAL-IP が設定された。

% kubectl get pod,endpoints,service -o wide -l app=hostnames
NAME                            READY     STATUS    RESTARTS   AGE       IP          NODE
po/hostnames-3799501552-jpmdq   1/1       Running   0          55m       10.76.0.9   gke-kube-sandbox-default-pool-88bb8656-26d1

NAME           ENDPOINTS        AGE
ep/hostnames   10.76.0.9:9376   1m

NAME            CLUSTER-IP      EXTERNAL-IP       PORT(S)        AGE       SELECTOR
svc/hostnames   10.79.250.127   104.199.232.159   80:30675/TCP   1m        app=hostnames

PORT を見ると、 NodePort Service の上に実装されていることが分かる。
iptables には次のようなルールが追加された。

-A KUBE-SERVICES -d 104.199.232.159/32 -p tcp -m comment --comment "default/hostnames: loadbalancer IP" -m tcp --dport 80 -j KUBE-FW-NWV5X2332I4OT4T3
-A KUBE-FW-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames: loadbalancer IP" -j KUBE-MARK-MASQ
-A KUBE-FW-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames: loadbalancer IP" -j KUBE-SVC-NWV5X2332I4OT4T3
-A KUBE-FW-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames: loadbalancer IP" -j KUBE-MARK-DROP

まず、下記のルールから、EXTERNAL-IP の対象宛ての Service のポート宛てのパケットは全て KUBE-FW-* で処理されることが分かる。

-A KUBE-SERVICES -d 104.199.232.159/32 -p tcp -m comment --comment "default/hostnames: loadbalancer IP" -m tcp --dport 80 -j KUBE-FW-NWV5X2332I4OT4T3

次のルールから KUBE-FW-* に来たパケットはは対応する KUBE-SVC-* で処理されることが分かる。 KUBE-MARK-DROP は何らかの理由で KUBE-SVC-* がない場合にパケットを捨てるためのものだろう。

-A KUBE-FW-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames: loadbalancer IP" -j KUBE-MARK-MASQ
-A KUBE-FW-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames: loadbalancer IP" -j KUBE-SVC-NWV5X2332I4OT4T3
-A KUBE-FW-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames: loadbalancer IP" -j KUBE-MARK-DROP

KUBE-SVC-* に来たら今までに見てきた Service と同様なので、 EXTERNAL-IP に来たパケットは結果的には Pod に転送されることが分かる。

LoadBalancer Service の GCE 側

GCE 側も確認する。最初に確認した通り現在存在する GKE ノードの GCE インスタンスには下記のようなタグが設定されている。

$ gcloud compute instances list --format='table(name,tags.items.map(0).join(","):label=tags)'
NAME                                         tags
gke-kube-sandbox-default-pool-88bb8656-26d1  gke-kube-sandbox-5bb78bc1-node,goog-gke-node

GCE ファイアウォールを確認してみるとノードのタグに対して Service が export しているポートへの通信が許可されている。

$ gcloud compute firewall-rules list --filter=network=kube-sandbox
NAME                                     NETWORK       SRC_RANGES         RULES                         SRC_TAGS  TARGET_TAGS
k8s-fw-a0d5edc74edc111e690da42010af0018  kube-sandbox  0.0.0.0/0          tcp:80                                  gke-kube-sandbox-5bb78bc1-node

更に Service の EXTERNAL-IP の IP アドレスに対応する転送ルールが作られている。

$ gcloud compute forwarding-rules list --filter IPAddress=104.199.232.159
NAME                              REGION      IP_ADDRESS       IP_PROTOCOL  TARGET
a0d5edc74edc111e690da42010af0018  asia-east1  104.199.232.159  TCP          asia-east1/targetPools/a0d5edc74edc111e690da42010af0018

転送ルールの転送先は上で確認したインスタンスを含むターゲットプールに向いていることが確認できる。

$ gcloud compute target-pools list a0d5edc74edc111e690da42010af0018 --format='table(name,region,instances.map().basename().join(","))'
NAME                              REGION      INSTANCES
a0d5edc74edc111e690da42010af0018  asia-east1  gke-kube-sandbox-default-pool-88bb8656-26d1

なおこれらの転送ルール及びターゲットプールの生成は GCE Cloud Provider Addon が行っている。

ターゲットプールを指す転送ルールは GCE の L4 ロードバランサである Network LoadBalancing として機能するので、転送ルールに設定された外部 IP アドレスへのパケットが Node に転送されることが分かる。

なお、GCE の Network LoadBalancing は Maglev として知られる DSR 型のロードバランサなので、クライアントが送信した際の送信先 IP アドレスがそのまま iptables で処理される。(参考)

まとめ

GKE/GCE/Kubernetes を通して、下記のように Service から作られたロードバランサからどのように Pod までパケットが届くかを確認した。

GKE のノード間のネットワークは GCE のルートでルーティングするためオーバレイネットワークは不要
Kubernetes のコア機能である Service の IP レイヤは kube-proxy が動的に生成した iptables のルールを使って Linux カーネルで処理される
GCE Network Load Balancing 等との連携部分については Cloud Provider Addon が処理する

なお、 HTTP ロードバランサに対応する Ingress の実装は今回説明した LoadBalancer Service のものとは別になっている。
(具体的には現在 NodePort Service で公開されるポートを使って実現されている。GCE Ingress Controllerの実装を参照してほしい。)

参考

Service: https://kubernetes.io/docs/user-guide/services/
ネットワークモデル全般: https://kubernetes.io/docs/admin/networking/
kube-proxy の iptables 処理部分の実装: https://github.com/kubernetes/kubernetes/blob/v1.5.2/pkg/proxy/iptables/proxier.go
GKE に頼らずに GCE 及び AWS でクラスタを構成するチュートリアル: https://github.com/kelseyhightower/kubernetes-the-hard-way
etcd と照らし合わせて確認している: http://containerops.org/2017/01/30/kubernetes-services-and-ingress-under-x-ray/