What is the best way to collect log on kubernates?

What is the best way to collect log on kubernates? on shinjuku-rb #64

Transcript

1. What is the best way to collect log on kubernates? @threetreeslight on shinjuku.rb #64 1 / 45
2. whoami @threetreeslight / VPoE at Repro 最近はイベントおじさん 2 / 45
3. 突然ですが 3 / 45
4. kubernates はいいぞ（⼩並感） 4 / 45
5. そんなRepro は ECS 5 / 45
6. ⾃⾝のblog をk8s で運⽤した経験からのお話です 6 / 45
7. 閑話休題 7 / 45
8. 悩ましいcontainer log container log は集約したいけど。。。 1. どこに集約(logging backend) する? 2. そのためのlog driver 何にする？ 3. log aggerate 先が落ちても⼤丈夫？ 4. node 単位で集約してから送る？ 5. どんなlog を集める？ etc... 8 / 45
9. k8s の⽅針を知る 9 / 45
10. logging architecutre 1. container 内のapplication はstdout, stderr にログを吐く 2. node の /var/log, /var/log/docker にlog が集約される 3. logrotate で世代管理 ref. kubernates - logging at the node level 10 / 45
11. Cluster-level logging cluster-level のlog を集約する⽅法は標準で⽤意されていない。 そのため、⾃前でlog aggregate する必要がある。 （よく考えられているなぁ ） 11 / 45
12. Approaches 1. 各node にlog aggregate するagent いれて集約先に送る 2. pod にlogging ⽤side car container つけて送る 3. application のsidecar contaienr から集約先に送る c.f. kubernates - Cluster-level logging architectures 12 / 45
13. Using a node logging agent node にlogging agent を置いて、集約先(logging backend) に送るとい う最も⼀般的な⽅法。 13 / 45
14. Pros/Cons Pros logging agent の⽣き死にapplication が影響を受けない logging agent のupdate が楽 Cons application はstdout, stderr でしかlog を転送できない node logging agent が詰ったら上⼿くスケールさせる必要がある 14 / 45
15. Using a sidecar container with the logging agent Streaming sidecar container をつけてログストリームを分割する 15 / 45
16. Pros/Cons Pros stderr, stdout への書き込みをサポートしていないミドルウェアを 使った時に使える lost してはいけないlog のbuffering やretry の制御を⾏いたい Cons pod 終了時の振る舞いに気をつける必要がある 他にもPros がありそう? 16 / 45
17. Using a sidecar container with the logging agent sidecar container から直接 logging backend にlog を送る 17 / 45
18. Pros/Cons Pros node logging agent の負荷を気にする必要がない node のscale out/in に影響を受けない Cons kubelet のlogs 機能を使ったlog の監視をすることが出来ない logging backend が落ちたときのhandle を考慮する必要がある 18 / 45
19. Exposing logs directly from the application application からlogging backend に直接送る男らしいやり⽅ 19 / 45
20. Pros/Cons Pros 構成としてシンプル node logging agent の負荷を気にする必要がない node のscale out/in に影響を受けない pod の終了に際し、コンテナ間の終了順序を意識する必要がない Cons kubelet のlogs 機能を使ったlog の監視をすることが出来ない logging backend が落ちたときのhandle を考慮する必要がある buffering, retry などを実装する必要がある 20 / 45
21. 落ちない超強いlogging backend があればシンプルな構成 にできるがそんなものはない！ 21 / 45
22. 12 Factors App c.f. アプリケーションはログファイルに書き込んだり管理しようとする べきではない。 代わりに、それぞれの実⾏中のプロセスはイベント ストリームをstdout （標準出⼒）にバッファリングせずに書きだ す。 The Twelve-Factors App - XI. log 22 / 45
23. Accepted Approach こんな感じ？ Using a node logging agent Approach を採⽤ GKE のdefault もコレ 必要に応じてsidecar agent を採⽤する Application の機能として、stdout, stderr への出⼒が貧弱なときに 中間約として利⽤する node logging agent の負荷に⼤きく影響を与えるログがあるとき に直接logging backend に送る 23 / 45
24. Logs 24 / 45
25. target logs 収集すべきログはこんな感じ？ 1. application log 1. container log 2. system component log 1. node(host) system log 2. docker daemon log 3. k8s(kubelet, api, etcd) log 25 / 45
26. いっぱいある 26 / 45
27. ⾒ていく 1. どんなログ 2. どこに置かれているのか 27 / 45
28. container log 28 / 45
29. k8s log location つまり、 /var/log をnode logging agent container で収集しておけば 良いので楽ちん！ c.f. On machines with systemd, the kubelet and container runtime write to journald. If systemd is not present, they write to .log files in the /var/log directory. kubernates - Logging Architecture 29 / 45
30. /var/log/containers container log が上記のpath にフラットに配置されている。 これは実態ではなくsymlink であり、kubelet がこの⼿のバイパス作業を 実施している。 01 # format 02 # pod_name + revision + namespace + container_name + container sha1 03 blog-84bd9f6d5b-9f6kt_default_blog-e3e2ad507585302aa3d77cc3670ffd3b86263bbff8 04 fluentd-gcp-v2.0.9-5kd4h_kube-system_fluentd-gcp-6330ce359fb5c54012b85c1d6d57 05 fluentd-gcp-v2.0.9-5kd4h_kube-system_fluentd-gcp-8b951e9978fae5781b55007de8f2 06 fluentd-gcp-v2.0.9-5kd4h_kube-system_prometheus-to-sd-exporter-2cd439bb6d2323 30 / 45
31. /var/log/pods container log のsymlink 先。pod 単位のlog が配置されている。 こうするメリットはなんだろう？ 01 # ls -la /var/log/pods/82a88873-9d18-11e8-b3c9-42010a8a0140 02 fluentd-gcp_10.log -> /var/lib/docker/containers/8b951e9978fae5781b55007de8f2 03 fluentd-gcp_11.log -> /var/lib/docker/containers/6330ce359fb5c54012b85c1d6d57 04 prometheus-to-sd-exporter_0.log -> /var/lib/docker/containers/2cd439bb6d23237 31 / 45
32. /var/lib/docker/containers/ docker 標準のlocal strage 配置場所。この中に各種設定情報も置かれて いる。 この中のlog だけをsymlink で引っ張っている。 c.f. docker - About storage drivers 01 # /var/lib/docker/containers 02 071b3c094a4332044997fb425aa95348d324ff6fc5f02d3311cd9a88ce999216 03 09af55d72e42330f1903cab2fb42f274bc2c5ee24149d72e69356e1faca64879 04 0aa68a6f97640043365d080b64c557379271f5ef1730763537772e3ecd695659 05 17834a541c748564ebb79772cafd8a6858f095fb46334778550d84e33ab51627 06 2cd439bb6d232379490dcb48f7a39e7c292bc6aba26a6249faf6d9a122697234 07 40730ac5da23aa22dcfc2baac15efd31dc82445c168d9230506930e5575e840d 08 556d1b7d52f70e4e0f17e4a0021a493048cb34aae1b52036799ca31f2def4b3a 09 10 # /var/lib/docker/containers/2cd439bb6d232379490dcb48f7a39e7c292bc6aba26a6249 11 2cd439bb6d232379490dcb48f7a39e7c292bc6aba26a6249faf6d9a122697234-json.log 12 checkpoints 13 config.v2.json 14 hostconfig.json 15 16 # tail 2cd439bb6d232379490dcb48f7a39e7c292bc6aba26a6249faf6d9a122697234-json. 17 {"log":"I0811 03:42:05.658378 1 main.go:83] GCE config: \u0026{Project: 18 {"log":"I0811 03:42:05.658464 1 main.go:115] Running prometheus-to-sd, 32 / 45
33. system component log 33 / 45
34. default GKE node logging agent collect 01 /var/log/salt/minion 02 /var/log/startupscript.log 03 /var/log/docker.log 04 /var/log/etcd.log 05 /var/log/kubelet.log 06 /var/log/kube-proxy.log 07 /var/log/kube-apiserver.log 08 /var/log/kube-controller-manager.log 09 /var/log/kube-scheduler.log 10 /var/log/rescheduler.log 11 /var/log/glbc.log 12 /var/log/cluster-autoscaler.log 34 / 45
35. /var/log/salt/minion もしや、GKE はnode のprovisioning にsaltstack を使うの? GEK のnode の中を⾒ても存在しなかった。 c.f. イベント駆動のオーケストレーションツール slatstack kubernates - Configuring Kubernetes with Salt 35 / 45
36. /var/log/startupscript.log cloud init みたいなやつのlog 。素のGKE では利⽤されない。 c.f. google cloud - 起動スクリプトの実⾏ 36 / 45
37. kubernates logs /var/log/kubelet.log node の制御やcontainer 起動などを⾏うcontainer. ecs agent みた いなやつ。 /var/log/kube-proxy.log dynamic port mapping を実現しているやつ。設定はkube api を利 ⽤して⾏われる /var/log/kube-apiserver.log 様々な操作はすべてkube apiserver を経由して処理される /var/log/kube-controller-manager.log node, replication, endoint, service account のcontroller log /var/log/kube-scheduler.log kubernates - kubernates components 37 / 45
38. /var/log/kube-proxy.log service におけるpod の起動・終了で以下のようなlog が流れます 01 I0603 15:38:32.507621 1 proxier.go:345] Removing service port "default/ 02 I0603 15:38:32.507679 1 proxier.go:345] Removing service port "default/ 03 I0603 15:40:53.472870 1 proxier.go:329] Adding new service port "defaul 04 I0603 15:40:53.472930 1 proxier.go:329] Adding new service port "defaul 05 I0603 15:40:53.493729 1 proxier.go:1769] Opened local port "nodePort fo 06 I0603 15:40:53.493840 1 proxier.go:1769] Opened local port "nodePort fo 38 / 45
39. /var/log/etcd.log kubernates の設定を伝搬するやつ coreos/etcd 39 / 45
40. /var/log/rescheduler.log これなに？ 40 / 45
41. /var/log/glbc.log GCE Load-Balancer Controller (GLBC) のlog. GKE でingress 使う場合はデフォルトでgoogle のloadbalancing 機能が使 われる。 kubernates - cluster-loadbalancing/glbc 41 / 45
42. /var/log/cluster- autoscaler.log k8s cluster のauto scaling に関わるログが出⼒される（はず） kubernates - Cluster Autoscaler 42 / 45
43. いっぱいある 43 / 45
44. まとめ application <-> logging agent とのやりとりは直接push せず、file を使 ってなるべく疎結合にする kubernates のlog 収集には Using a node logging agent Approach を やろう 監視対象は /var/log をみよう それだけで⼤丈夫! 44 / 45
45. 参考資料 Fluentd Blog - Unified Logging Layer: Turning Data into Action fluentd - Buffer Plugin Overview The Twelve-Factors App - XI. log kubernates - logging kubernates - Configuring Kubernetes with Salt slatstack infoQ - Lyft がPuppet からSaltStack にリプレース google cloud - Puppet 、Chef 、Salt 、Ansible での Compute Engine の管理 coreos/etcd kubernates - cluster-loadbalancing/glbc kubernates - Cluster Autoscaler 45 / 45