ざっくりとKubernetesの通信を探る #GoogleCloud

はじめに

業務で必要になってくるので最近ようやくKubernetesについてキャッチアップしています。今回はKubernetesのワーカーノード周りの通信がどのように行われているかを探ってみたかったのでGKEを用いて確認していきます。ワーカーノードをじっくり触っていくため、クラスタモードはGKE Standardの一般公開クラスタを使います。クラスタは作成済み&ローカルで接続済みの状況を想定として話を進めていきたいと思います。

Google Kubernetes Engineの構成図

通信を確認するために作ったもの

GolangでAPI Serverを作成しました。HTTPリクエストするとIPアドレスを返してくれるものです。これでどのように通信が行われているかを確認していきたいと思います。

main.go

package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
)

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		interfaces, err := net.Interfaces()
		if err != nil {
			fmt.Println(err)
			return
		}
		for _, inter := range interfaces {
			addrs, err := inter.Addrs()
			if err != nil {
				fmt.Println(err)
				return
			}
			for _, a := range addrs {
				if ipnet, ok := a.(*net.IPNet); ok {
					if ipnet.IP.To4() != nil {
						fmt.Fprintf(w, ipnet.IP.String() + "\n")
					}
				}
			}
		}
	})
	log.Fatal(http.ListenAndServe(":8080", nil))
}

コンテナのデプロイ

deploymentを作成します。

kubectl create deployment go-app --image=asia-northeast1-docker.pkg.dev/${projectId}/go-repo/go-app:latest

Podを3つに増やします。

kubectl scale deployment --replicas 3 go-app

NodeとPodの関係

以下のコマンドを実行してnodeの詳細を確認します。

kubectl get node -o wide

nodeが３台起動していることを確認できます。

以下のコマンドを実行してpodの詳細を確認します。

kubectl get pod -o wide

podが３台起動していることを確認できます。しかし、3台のワーカーノードに１つずつPodが起動しているようではないみたいです。

図にすると以下のような関係になっています。ワーカーノードにPodが1つずつ配置されるというわけではないみたいです。

Serviceの作成(L4ロードバランサの設置)

Serviceの80番ポートにアクセスするとpodの8080番ポートに転送します

kubectl expose deployment go-app --type=LoadBalancer --port 80 --target-port 8080

以下のコマンドでServiceを確認することができます。

kubectl get svc -o wide

ワーカーノードの32192番ポートにアクセスすればCLUSTER-IPに転送するようになりました。

L7ロードバランサにHTTPリクエスト

curl http://35.200.9.207

こんな感じで各ノードにランダムで通信が行われていることがわかります。

ワーカーノードにHTTPリクエスト

今回はGKEを一般公開クラスタとしているので各ワーカーノードにPublicIPアドレスが割り当てられています。各ノードのファイヤーウォールのルールに32192番ポートの通信を許可し、各ノードに対してHTTPリクエストを行います。

curl 34.146.102.39:32192
curl 34.85.123.215:32192
curl 34.85.115.12:32192

結果は以下のようになりました。

図にまとめると以下のような感じです。　アクセスするワーカーノード上にPodがなかったとしても問題なく別のワーカーノードに対してパケットが振り分けられている。

クラスタ内から直接PodにHTTPリクエスト

クラスタ内にubuntuのPodを立て、そこからHTTPリクエストを行います。

kubectl run -it ubuntu --image=ubuntu bash

curlコマンドのインストール

apt-get update
apt-get install curl

試しにCLUSTER-IPにHTTPリクエストを行います。

curl http://10.56.11.169

結果は以下のようになりました。ちゃんと各Podに振り分けられていますね。

本命の各Podに直接HTTPリクエストを行います。

curl http://10.52.2.5:8080
curl http://10.52.2.6:8080
curl http://10.52.1.4:8080

結果は以下のようになりました。こちらもちゃんと各Podに振り分けられていますね。

どうやってPodに通信しているのか

各ワーカーノードに存在するkube-proxyがアクセスを振り分けているように見えるが、実際はapiserverの変更を検知してiptablesのDNATルールを追加、変更、削除を行うだけであり、アクセスの振り分けはiptablesというOS側の仕組みで実行する。CLUSTER-IPの実態はiptablesとなっている。

以下のようにiptables上のチェインを処理しています。

Ref: https://www.atmarkit.co.jp/ait/articles/1002/09/news119.html

ここからはiptablesどのようになっているかざっくり見ていきます。PREROUTINGチェインのKUBE-SERVICESを見ていきます

kubectl exec -it Pod名(kube-proxyなんとか) -n kube-system -- iptables -t nat -nL KUBE-SERVICES

CLUSTER-IPを発見した。

KUBE-SVC-7WFRCR3BAURI7IH5を見ていきます。

kubectl exec -it Pod名(kube-proxyなんとか) -n kube-system -- iptables -t nat -nL KUBE-SVC-7WFRCR3BAURI7IH5

iptablesでは、ルールは上から下に順番に一致します。１番目のルールがヒットする確率が33％、2番目のルールがヒットする確率が50%、３番目は必ずヒットするので3つのルールに当たる確率は同じであることがわかります。

KUBE-SEP-WWRWIUIMT3RFPW3Fを見ていきます。

kubectl exec -it Pod名(kube-proxyなんとか) -n kube-system -- iptables -t nat -nL KUBE-SEP-WWRWIUIMT3RFPW3F

10.52.1.4:8080(Pod)にDNATされることが確認できました。

ざっくりとiptablesについて探りました。ここから先の内容は以下の記事がとても参考になりますよ。

ざっくりとKubernetesの通信を探る