telepresence というツールがあります。手元の端末が Kubernetes クラスタ内にいるかのような通信を可能にし、Kubernetes の Pod の Container への通信をインターセプトして手元の端末に流すことができます。これの仕組みを調べてみます。(以前は Python で書かれていたようですが、v2 は Go で書き直されたみたいです)
確認に使用した telepresence と mac の version
$ telepresence version
Client: v2.4.9 (api v3)
$ sw_vers
ProductName: macOS
ProductVersion: 12.1
BuildVersion: 21C52
Kubernetes クラスタは GKE の v1.21.5-gke.1302
クラスタへの terffic-manager のデプロイ
helm を使ってインストールすることができます。デフォルトではクラスタワイドな設定になりますが、特定の namespace にのみインストールしたり、namespace 毎に権限を分けてインストールすることも可能です。
$ helm repo add datawire https://app.getambassador.io
$ helm repo update
Namespace の作成。デフォルトでは ambassador という namespace を使うことになっているようです。
$ kubectl create namespace ambassador
$ helm install traffic-manager --namespace ambassador datawire/telepresence
次のようなリソースが作成されます。
| Kind | Namespace | Name |
|---|---|---|
| ServiceAccount | ambassador | traffic-manager |
| Secret | ambassador | mutator-webhook-tls |
| ClusterRole | - | traffic-manager-ambassador |
| ClusterRoleBinding | - | traffic-manager-ambassador |
| Role | ambassador | traffic-manager |
| RoleBinding | ambassador | traffic-manager |
| Service | ambassador | traffic-manager |
| Service | ambassador | agent-injector |
| Deployment | ambassador | traffic-manager |
| MutatingWebhookConfiguration | - | agent-injector-webhook-ambassador |
テスト用 Service / Deployment のデプロイ
default namespace に hello という Deployment をデプロイし、 expose コマンドで Service を作成します。
$ kubectl create deploy hello --image=k8s.gcr.io/echoserver:1.4
$ kubectl expose deploy hello --port 80 --target-port 8080
$ kubectl get ns,svc,deploy,po
NAME STATUS AGE
namespace/ambassador Active 104m
namespace/default Active 159m
namespace/kube-node-lease Active 159m
namespace/kube-public Active 159m
namespace/kube-system Active 159m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/hello ClusterIP 172.16.1.153 80/TCP 11s
service/kubernetes ClusterIP 172.16.0.1 443/TCP 159m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/hello 1/1 1 1 20s
NAME READY STATUS RESTARTS AGE
pod/hello-79dbd5fdfb-t59nr 1/1 Running 0 13s
telepresence connect
手元の端末で telepresence connect コマンドを実行することで手元の端末と Kubernetes クラスタ間の tunnel を掘る。root 権限で実行する必要のあるものがあるため、sudo のパスワード入力を求められます。
$ telepresence connect
Launching Telepresence Root Daemon
Need root privileges to run: /Users/teraoka/bin/telepresence daemon-foreground /Users/teraoka/Library/Logs/telepresence '/Users/teraoka/Library/Application Support/telepresence' ''
Password:
Launching Telepresence User Daemon
Connected to context gke_MY_PROJECT_ID_asia-northeast1-a_CLUSTER_NAME (https://203.0.113.123)
telepresence version コマンドで root で実行する daemon をユーザー権限で実行する daemon の 2 つが実行されているのがわかります。
$ telepresence version
Client: v2.4.9 (api v3)
Root Daemon: v2.4.9 (api v3)
User Daemon: v2.4.9 (api v3)
手元の curl からクラスタ内へのアクセス
たったこれだけで、あら不思議 curl hello.default とするとクラスタ内の Service に対してアクセスできています。
$ curl -sv hello.default
* Trying 172.16.1.153:80...
* Connected to hello.default (172.16.1.153) port 80 (#0)
> GET / HTTP/1.1
> Host: hello.default
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.10.0
< Date: Fri, 31 Dec 2021 08:27:43 GMT
< Content-Type: text/plain
< Transfer-Encoding: chunked
< Connection: keep-alive
<
CLIENT VALUES:
client_address=172.17.0.131
command=GET
real path=/
query=nil
request_version=1.1
request_uri=http://hello.default:8080/
SERVER VALUES:
server_version=nginx: 1.10.0 - lua: 10001
HEADERS RECEIVED:
accept=*/*
host=hello.default
user-agent=curl/7.79.1
BODY:
* Connection #0 to host hello.default left intact
-no body in request-
hello.default が 172.16.1.153 と名前解決されているのがどうしてなのか気になります。答えは下にありますが、これは mac の場合です、Linux や Windows ではまた別の仕組みが使われているのだろうと思われます。(他の環境も含めて DNS resolution に書かれていました)
サーバー側から見た client_address は 172.17.0.131 となっています、これは ambassador namespace にデプロイされている traffic-manager Deployment の Pod が持つ IP アドレスです。この Pod 経由でアクセスしていることがわかります。
$ kubectl get pod -n ambassador -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
traffic-manager-5cb99c9fd6-mv6v9 1/1 Running 0 124m 172.17.0.131 gke-teraoka-blue-teraoka-blue-pool1-48fb0873-m4cw <none> <none>
telepresence プロセスの役割
telepresence のぞれぞれのプロセスが何をやっているのかを確認してみます。
とりあえず ps コマンドで確認。
$ ps auxww | grep telepresence
teraoka 72020 0.0 0.0 34132084 872 s003 R+ 5:18PM 0:00.00 grep telepresence
teraoka 71885 0.0 0.3 34956040 46184 s000 S 5:14PM 0:00.65 /Users/teraoka/bin/telepresence connector-foreground
root 71881 0.0 0.2 34966080 35296 s000 S 5:14PM 0:00.27 /Users/teraoka/bin/telepresence daemon-foreground /Users/teraoka/Library/Logs/telepresence /Users/teraoka/Library/Application Support/telepresence
root 71880 0.0 0.0 34142464 4596 s000 S 5:14PM 0:00.01 sudo --non-interactive --preserve-env /Users/teraoka/bin/telepresence daemon-foreground /Users/teraoka/Library/Logs/telepresence /Users/teraoka/Library/Application Support/telepresence
$ pstree -w 71880
-+= 71880 root sudo --non-interactive --preserve-env /Users/teraoka/bin/telepresence daemon-foreground /Users/teraoka/Library/Logs/telepresence /Users/teraoka/Library/Application Support/telepresence
\--- 71881 root /Users/teraoka/bin/telepresence daemon-foreground /Users/teraoka/Library/Logs/telepresence /Users/teraoka/Library/Application Support/telepresence
lsof で確認
root daemon
$ sudo lsof -nPp 71881
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
teleprese 71881 root cwd DIR 1,9 512 47512210 /Users/teraoka/ghq/github.com/yteraoka/terraform-examples/gcp/gke
teleprese 71881 root txt REG 1,9 77231136 74147315 /Users/teraoka/bin/telepresence
teleprese 71881 root txt REG 1,9 46096 74099023 /Library/Preferences/Logging/.plist-cache.1VLWA6Q0
teleprese 71881 root txt REG 1,9 2160672 1152921500312811906 /usr/lib/dyld
teleprese 71881 root txt REG 1,9 32768 74099068 /private/var/db/mds/messages/se_SecurityMessages
teleprese 71881 root txt REG 1,9 114087 74099365 /private/var/db/analyticsd/events.whitelist
teleprese 71881 root txt REG 1,9 29638976 1152921500312823656 /usr/share/icu/icudt68l.dat
teleprese 71881 root 0r CHR 3,2 0t0 317 /dev/null
teleprese 71881 root 1w REG 1,9 2099 74169276 /Users/teraoka/Library/Logs/telepresence/daemon.log
teleprese 71881 root 2w REG 1,9 2099 74169276 /Users/teraoka/Library/Logs/telepresence/daemon.log
teleprese 71881 root 3u KQUEUE count=0, state=0xa
teleprese 71881 root 4 PIPE 0xd904b24160bf46ff 16384 ->0x1ac3420f1be0c501
teleprese 71881 root 5 PIPE 0x1ac3420f1be0c501 16384 ->0xd904b24160bf46ff
teleprese 71881 root 6w REG 1,9 2099 74169276 /Users/teraoka/Library/Logs/telepresence/daemon.log
teleprese 71881 root 7u systm 0x4715bfb02f5e8bd7 0t0 [ctl com.apple.net.utun_control id 4 unit 4]
teleprese 71881 root 8 PIPE 0x77446814497e3b77 16384 ->0x67dbd1c5970420d8
teleprese 71881 root 9u unix 0x4715bfb02f991c3f 0t0 /var/run/telepresence-daemon.socket
teleprese 71881 root 10 PIPE 0x67dbd1c5970420d8 16384 ->0x77446814497e3b77
teleprese 71881 root 11 NPOLICY
teleprese 71881 root 12u unix 0x4715bfb02f991f5f 0t0 /var/run/telepresence-daemon.socket
teleprese 71881 root 13u unix 0x4715bfb02f9944df 0t0 ->0x4715bfb02f9945a7
teleprese 71881 root 14u IPv4 0x4715bfb4fc950c67 0t0 UDP *:51812
teleprese 71881 root 15u unix 0x4715bfb02f993477 0t0 ->0x4715bfb02f99353f
root daemon は 51812/udp を listen しています。後でわかりますが、これは DNS サーバーです。クラスタのドメインはここに問い合わせが行われます。utun_control というのは tunnel の制御でしょうか。
utun3 といネットワークデバイスが作成されており
$ ifconfig utun3
utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 172.16.0.0 --> 172.16.0.1 netmask 0xfffff000
inet 172.17.0.0 --> 172.17.0.1 netmask 0xffffffc0
inet 172.17.0.64 --> 172.17.0.1 netmask 0xffffffc0
inet 172.17.0.128 --> 172.17.0.1 netmask 0xffffffc0
Pod や Service 用サブネットの route がその utun3 へ向けられています。
$ netstat -nr | grep utun3
172.16/20 172.16.0.1 UGCS utun3
172.16.0.1 172.16.0.0 UH utun3
172.16.15.255 172.16.0.1 UGHW3I utun3 22
172.17/26 172.17.0.1 UGCS utun3
172.17.0.1 172.17.0.0 UH utun3
172.17.0.63 172.17.0.1 UGHW3I utun3 22
172.17.0.64/26 172.17.0.1 UGCS utun3
172.17.0.127 172.17.0.1 UGHW3I utun3 22
172.17.0.128/26 172.17.0.1 UGCS utun3
172.17.0.191 172.17.0.1 UGHW3I utun3 22
user daemon
$ lsof -nPp 71885
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
teleprese 71885 teraoka cwd DIR 1,9 512 47512210 /Users/teraoka/ghq/github.com/yteraoka/terraform-examples/gcp/gke
teleprese 71885 teraoka txt REG 1,9 77231136 74147315 /Users/teraoka/bin/telepresence
teleprese 71885 teraoka txt REG 1,9 46096 74099023 /Library/Preferences/Logging/.plist-cache.1VLWA6Q0
teleprese 71885 teraoka txt REG 1,9 32768 74100907 /private/var/db/mds/messages/501/se_SecurityMessages
teleprese 71885 teraoka txt REG 1,9 2160672 1152921500312811906 /usr/lib/dyld
teleprese 71885 teraoka txt REG 1,9 114087 74099365 /private/var/db/analyticsd/events.whitelist
teleprese 71885 teraoka 0r CHR 3,2 0t0 317 /dev/null
teleprese 71885 teraoka 1w REG 1,9 1498 74169289 /Users/teraoka/Library/Logs/telepresence/connector.log
teleprese 71885 teraoka 2w REG 1,9 1498 74169289 /Users/teraoka/Library/Logs/telepresence/connector.log
teleprese 71885 teraoka 3u KQUEUE count=0, state=0xa
teleprese 71885 teraoka 4 PIPE 0xfc30aea6068d98ef 16384 ->0xd5d97fbdd54a6017
teleprese 71885 teraoka 5 PIPE 0xd5d97fbdd54a6017 16384 ->0xfc30aea6068d98ef
teleprese 71885 teraoka 6w REG 1,9 1498 74169289 /Users/teraoka/Library/Logs/telepresence/connector.log
teleprese 71885 teraoka 7u unix 0x4715bfb02f992347 0t0 /tmp/telepresence-connector.socket
teleprese 71885 teraoka 8 PIPE 0xa124ff493681e691 16384 ->0x40a1939f617879e5
teleprese 71885 teraoka 9 PIPE 0x40a1939f617879e5 16384 ->0xa124ff493681e691
teleprese 71885 teraoka 10u IPv6 0x4715bfb9c79fa6f7 0t0 TCP *:53443 (LISTEN)
teleprese 71885 teraoka 12u IPv4 0x4715bfbe96aaa46f 0t0 TCP 192.168.210.119:53444->203.0.113.123:443 (ESTABLISHED)
teleprese 71885 teraoka 13u unix 0x4715bfb02f9919e7 0t0 ->0x4715bfb02f991f5f
teleprese 71885 teraoka 14 NPOLICY
teleprese 71885 teraoka 15u unix 0x4715bfb02f992027 0t0 ->0x4715bfb02f99434f
teleprese 71885 teraoka 17u IPv4 0x4715bfbe9eb6546f 0t0 TCP 192.168.210.119:53446->203.0.113.123:443 (ESTABLISHED)
teleprese 71885 teraoka 18u unix 0x4715bfb02f9945a7 0t0 /tmp/telepresence-connector.socket
Kubernetes の API Server と通信しているのは user daemon のようです。
ログファイルを確認
lsof でログファイルらしきファイルが確認できたので中身を見てみます。
root daemon のログ
/Users/teraoka/Library/Logs/telepresence/daemon.log
2021-12-31 17:14:09.3150 info Logging at this level "info"
2021-12-31 17:14:09.3151 info ---
2021-12-31 17:14:09.3152 info Telepresence daemon v2.4.9 (api v3) starting...
2021-12-31 17:14:09.3152 info PID is 71881
2021-12-31 17:14:09.3152 info
2021-12-31 17:14:09.4008 info daemon/server-grpc : gRPC server started
2021-12-31 17:14:10.6945 info daemon/server-grpc/conn=2 : Adding never-proxy subnet 203.0.113.123/32
2021-12-31 17:14:10.7615 info daemon/watch-cluster-info : Adding service subnet 172.16.0.0/20
2021-12-31 17:14:10.7616 info daemon/watch-cluster-info : Adding pod subnet 172.17.0.0/26
2021-12-31 17:14:10.7616 info daemon/watch-cluster-info : Adding pod subnet 172.17.0.64/26
2021-12-31 17:14:10.7617 info daemon/watch-cluster-info : Adding pod subnet 172.17.0.128/26
2021-12-31 17:14:10.7621 info daemon/watch-cluster-info : Setting cluster DNS to 172.16.0.10
2021-12-31 17:14:10.7621 info daemon/watch-cluster-info : Setting cluster domain to "cluster.local."
2021-12-31 17:14:10.7778 info daemon/server-router/MGR stream : Connected to Manager 2.4.9
2021-12-31 17:14:10.7983 info daemon/server-dns : Generated new /etc/resolver/telepresence.local
2021-12-31 17:14:10.7985 info daemon/server-dns/SearchPaths : setting search paths ambassador default kube-node-lease kube-public kube-system
2021-12-31 17:14:10.7987 info daemon/server-dns/SearchPaths : Generated new /etc/resolver/telepresence.kube-system.local
2021-12-31 17:14:10.7991 info daemon/server-dns/SearchPaths : Generated new /etc/resolver/telepresence.tel2-search.local
2021-12-31 17:14:10.7994 info daemon/server-dns/SearchPaths : Generated new /etc/resolver/telepresence.ambassador.local
2021-12-31 17:14:10.7996 info daemon/server-dns/SearchPaths : Generated new /etc/resolver/telepresence.default.local
2021-12-31 17:14:10.7999 info daemon/server-dns/SearchPaths : Generated new /etc/resolver/telepresence.kube-node-lease.local
2021-12-31 17:14:10.8001 info daemon/server-dns/SearchPaths : Generated new /etc/resolver/telepresence.kube-public.local
root daemon は watch-cluster-info で Service の Subnet や Node 毎に作成される Pod の Subnet をクラスタに合わせて routing 設定しているようですし、DNS の forward 先の管理、そして /etc/resolver 配下に cluster 側に向けるドメイン用のファイルを管理しています。
例えば /etc/resolver/telepresence.kube-system.local の中身は次のようになっており、kube-system で終わるドメインの DNS の問い合わせは 127.0.0.1:51812 に送られるようになっています。51812/udp は root daemon が listen しており、tunnel 経由で Kubernetes 内の DNS Service に転送されてるようになっているみたいです。mac の /etc/resolver の仕組みを知らず、Linux の LD_PRELOAD 的なものが mac にもあってそれが使われているのだろうと調べてて、そんな設定が見つからずしばらく悩んでしまっていました…
$ cat /etc/resolver/telepresence.kube-system.local
# Generated by telepresence
port 51812
domain kube-system
nameserver 127.0.0.1
127.0.0.1:51812 に対して DNS の問い合わせを投げると結果が返ってきます。
mac のこの設定は scutil --dns でも確認できます。
$ dig +short @127.0.0.1 -p 51812 hello.default.svc.cluster.local a
172.16.1.153
user daemon のログ
/Users/teraoka/Library/Logs/telepresence/connector.log
2021-12-31 17:14:09.5593 info Logging at this level "info"
2021-12-31 17:14:09.5971 info ---
2021-12-31 17:14:09.5972 info Telepresence Connector v2.4.9 (api v3) starting...
2021-12-31 17:14:09.5972 info PID is 71885
2021-12-31 17:14:09.5972 info
2021-12-31 17:14:09.5974 info connector/server-grpc : gRPC server started
2021-12-31 17:14:09.7740 info connector/background-init : Connecting to daemon...
2021-12-31 17:14:09.7747 info connector/background-init : Connecting to k8s cluster...
2021-12-31 17:14:09.8611 info connector/background-init : Server version v1.21.5-gke.1302
2021-12-31 17:14:09.8612 info connector/background-init : Context: gke_MY_PROJECT_ID_asia-northeast1-a_CLUSTER_NAME
2021-12-31 17:14:09.8613 info connector/background-init : Server: https://203.0.113.123
2021-12-31 17:14:09.8613 info connector/background-init : Connected to context gke_MY_PROJECT_ID_asia-northeast1-a_CLUSTER_NAME (https://203.0.113.123)
2021-12-31 17:14:10.0374 info connector/background-init : Connecting to traffic manager...
2021-12-31 17:14:10.0375 info connector/background-init : Waiting for TrafficManager to connect
2021/12/31 17:14:10 Patching synced Namespace 6ed04e58-22c9-4b10-87a2-690867ae2371
2021-12-31 17:14:10.1281 info connector/background-manager : Existing Traffic Manager 2.4.9 not owned by cli or does not need upgrade, will not modify
2021/12/31 17:19:10 Patching synced Namespace 6ed04e58-22c9-4b10-87a2-690867ae2371
telepresence status
telepresence status コマンドで2つの daemon プロセスの状況を確認できます。DNS 周りの仕組みを見てて、誰かが com とか jp とか TLD と同じ namespace 作ってしまうと困るだろうなと思ってたのですが、いくつかはデフォルトで Exclude suffixes に入っているのですね。telepresence connect コマンドの --mapped-namespaces オプションで必要な namespace だけをコンマ区切りで並べることもできます。
$ telepresence status
Root Daemon: Running
Version : v2.4.9 (api 3)
DNS :
Remote IP : 172.16.0.10
Exclude suffixes: [.arpa .com .io .net .org .ru]
Include suffixes: []
Timeout : 4s
Also Proxy : (0 subnets)
Never Proxy: (1 subnets)
User Daemon: Running
Version : v2.4.9 (api 3)
Ambassador Cloud : Logged out
Status : Connected
Kubernetes server : https://203.0.113.123
Kubernetes context: gke_MY_PROJECT_ID_asia-northeast1-a_CLUSTER_NAME
Telepresence proxy: ON (networking to the cluster is enabled)
Intercepts : 0 total
part 1 はここまで。Kubernetes クラスタ側からのアクセスは次回。
telepresence connect で起動した 2 つの daemon プロセスは telepresence quit で終了できます。