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
   

   View Slide

2. whoami
   @threetreeslight / VPoE at Repro
   最近はイベントおじさん
   2 / 45
   

   View Slide

3. 突然ですが
   3 / 45
   

   View Slide

4. kubernates
   はいいぞ（⼩並感）
   4 / 45
   

   View Slide

5. そんなRepro
   は
   ECS
   5 / 45
   

   View Slide

6. 
   ⾃⾝のblog
   をk8s
   で運⽤した経験からのお話です
   6 / 45
   

   View Slide

7. 閑話休題
   7 / 45
   

   View Slide

8. 悩ましいcontainer log
   container log
   は集約したいけど。。。
   1.
   どこに集約(logging backend)
   する?
   2.
   そのためのlog driver
   何にする？
   3. log aggerate
   先が落ちても⼤丈夫？
   4. node
   単位で集約してから送る？
   5.
   どんなlog
   を集める？
   etc...
   8 / 45
   

   View Slide

9. k8s
   の⽅針を知る
   9 / 45
   

   View Slide

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
    

    View Slide

11. Cluster-level logging
    cluster-level
    のlog
    を集約する⽅法は標準で⽤意されていない。
    そのため、⾃前でlog aggregate
    する必要がある。
    （よく考えられているなぁ ）
    11 / 45
    

    View Slide

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
    

    View Slide

13. Using a node logging agent
    node
    にlogging agent
    を置いて、集約先(logging backend)
    に送るとい
    う最も⼀般的な⽅法。
    13 / 45
    

    View Slide

14. Pros/Cons
    Pros
    logging agent
    の⽣き死にapplication
    が影響を受けない
    logging agent
    のupdate
    が楽
    Cons
    application
    はstdout, stderr
    でしかlog
    を転送できない
    node logging agent
    が詰ったら上⼿くスケールさせる必要がある
    14 / 45
    

    View Slide

15. Using a sidecar container with the
    logging agent
    Streaming sidecar container
    をつけてログストリームを分割する
    15 / 45
    

    View Slide

16. Pros/Cons
    Pros
    stderr, stdout
    への書き込みをサポートしていないミドルウェアを
    使った時に使える
    lost
    してはいけないlog
    のbuffering
    やretry
    の制御を⾏いたい
    Cons
    pod
    終了時の振る舞いに気をつける必要がある
    他にもPros
    がありそう?
    
    16 / 45
    

    View Slide

17. Using a sidecar container with the
    logging agent
    sidecar container
    から直接 logging backend
    にlog
    を送る
    17 / 45
    

    View Slide

18. Pros/Cons
    Pros
    node logging agent
    の負荷を気にする必要がない
    node
    のscale out/in
    に影響を受けない
    Cons
    kubelet
    のlogs
    機能を使ったlog
    の監視をすることが出来ない
    logging backend
    が落ちたときのhandle
    を考慮する必要がある
    18 / 45
    

    View Slide

19. Exposing logs directly from the
    application
    application
    からlogging backend
    に直接送る男らしいやり⽅
    19 / 45
    

    View Slide

20. Pros/Cons
    Pros
    構成としてシンプル
    node logging agent
    の負荷を気にする必要がない
    node
    のscale out/in
    に影響を受けない
    pod
    の終了に際し、コンテナ間の終了順序を意識する必要がない
    Cons
    kubelet
    のlogs
    機能を使ったlog
    の監視をすることが出来ない
    logging backend
    が落ちたときのhandle
    を考慮する必要がある
    buffering, retry
    などを実装する必要がある
    20 / 45
    

    View Slide

21. 落ちない超強いlogging
    backend
    があればシンプルな構成
    にできるがそんなものはない！
    21 / 45
    

    View Slide

22. 12 Factors App
    c.f.
    アプリケーションはログファイルに書き込んだり管理しようとする
    べきではない。 代わりに、それぞれの実⾏中のプロセスはイベント
    ストリームをstdout
    （標準出⼒）にバッファリングせずに書きだ
    す。
    The Twelve-Factors App - XI. log
    22 / 45
    

    View Slide

23. Accepted Approach
    こんな感じ？
    Using a node logging agent Approach
    を採⽤
    GKE
    のdefault
    もコレ
    必要に応じてsidecar agent
    を採⽤する
    Application
    の機能として、stdout, stderr
    への出⼒が貧弱なときに
    中間約として利⽤する
    node logging agent
    の負荷に⼤きく影響を与えるログがあるとき
    に直接logging backend
    に送る
    23 / 45
    

    View Slide

24. Logs
    24 / 45
    

    View Slide

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
    

    View Slide

26. いっぱいある
    26 / 45
    

    View Slide

27. ⾒ていく
    1.
    どんなログ
    2.
    どこに置かれているのか
    27 / 45
    

    View Slide

28. container log
    28 / 45
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

33. system
    component log
    33 / 45
    

    View Slide

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
    

    View Slide

35. /var/log/salt/minion
    もしや、GKE
    はnode
    のprovisioning
    にsaltstack
    を使うの?
    
    GEK
    のnode
    の中を⾒ても存在しなかった。
    c.f.
    イベント駆動のオーケストレーションツール
    slatstack
    kubernates - Configuring Kubernetes with Salt
    35 / 45
    

    View Slide

36. /var/log/startupscript.log
    cloud init
    みたいなやつのlog
    。素のGKE
    では利⽤されない。
    c.f. google cloud -
    起動スクリプトの実⾏
    36 / 45
    

    View Slide

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
    

    View Slide

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
    

    View Slide

39. /var/log/etcd.log
    kubernates
    の設定を伝搬するやつ
    coreos/etcd
    39 / 45
    

    View Slide

40. /var/log/rescheduler.log
    これなに？
    40 / 45
    

    View Slide

41. /var/log/glbc.log
    GCE Load-Balancer Controller (GLBC)
    のlog.
    GKE
    でingress
    使う場合はデフォルトでgoogle
    のloadbalancing
    機能が使
    われる。
    kubernates - cluster-loadbalancing/glbc
    41 / 45
    

    View Slide

42. /var/log/cluster-
    autoscaler.log
    k8s cluster
    のauto scaling
    に関わるログが出⼒される（はず）
    kubernates - Cluster Autoscaler
    42 / 45
    

    View Slide

43. いっぱいある
    43 / 45
    

    View Slide

44. まとめ
    application <-> logging agent
    とのやりとりは直接push
    せず、file
    を使
    ってなるべく疎結合にする
    kubernates
    のlog
    収集には Using a node logging agent Approach
    を
    やろう
    監視対象は /var/log
    をみよう
    それだけで⼤丈夫!
    44 / 45
    

    View Slide

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
    

    View Slide