How to cluster-level logging aggregate on kubernates?

How to cluster-level logging aggregate on kubernates? / shinjuku-mokumoku vol.6
at 2018-07-14

Transcript

1. How to cluster-level logging aggregate on kubernates? shinjuku mokumoku programming #6 @threetreeslight on 2018-07-14 1 / 31
2. 今⽇やりたいこと ⾃分の運⽤するblog がGEK で動いている。このログ を分析に活かせるようなpipeline を作りたい 1. k8s( 主にGKE) でのlog driver まわりやlog 集約の調査 2. ⽤意したほうが⾃由度⾼そうであれば⾃前のlog shipper を動作させるか考える 2 / 31
3. 図にすると nginx prometheus grafana | | | ------------------- ||| ココらへんどうしよう？ | ------------------- | | | bigquery gcs papertrail/stackdriver | spark(data proc) 3 / 31
4. logging architecutre on kubernates stdout, stderr に吐はれてnode にそのログがたま る。/var/log, /var/log/docker 配下にlog が蓄積 し、logrotate して管理している感じ。 4 / 31
5. Cluster-level logging default でcluster-level のlog を集約したりする⽅法は ⽤意されていない。そのため、⾃前でlog aggregate する必要がある。 5 / 31
6. Approaches kubernates には、log 集約のapproach が綺麗にまとま っていたので良いですね！ 1. 各node にagent いれて⾛らせる 2. pod にlogging ⽤side car container をつけて集約 3. application からlog service に直接送る docker logdriver で直接送るようにすると接続先が down したときにどうにもならなくなるから推奨して いないのだろう :thinking_face: 6 / 31
7. Using a node logging agent 最も⼀般的な⽅法。稼働しているapplication に⼀切 変更することなく、log aggregate することができ る。 そのかわり、stdout, stderr でしかエラーを出⼒ できない。 7 / 31
8. Using a sidecar container with the logging agent Streaming sidecar container sidecar container を使うことで、ログストリームを 分けることができる。 8 / 31
9. 考えられる使い所 application でデータを直接送るのではなく、fluentd なりをsidecar container として⽴ててbuffering や retry を制御したいとき良い。 9 / 31
10. Using a sidecar container with the logging agent: Sidecar container with a logging agent 10 / 31
11. 考えられる使い所 ロストしてはいけない重要なデータストリームを分け る。 こうすることで、負荷とかそこらへんがhandle しやすく て良い。 node のscalein/out が激しいのでnode 上のログを⾒てお くのが⾟い 11 / 31
12. Exposing logs directly from the application application とstickey になるのであまりおすすめしな いアプローチ。 12 / 31
13. とはいえ、いくつかメリットもあ る？ 1. node level のscalein/out に対して気遣いが不要となる 2. pod のscale out/in に対して sidecar container の終了に係 る気遣いが不要となる リアルタイムにすべてのデータを受け付けられ、落 ちないlogging backend があるのであれば、この⽅法 もありだと思います。 13 / 31
14. 12factor's app に従うと 1. Using a node logging agent アプローチを採⽤する 2. application からログのparse, buffering, retry 処理を切り 離したいのであれば、Streaming sidecar container を⼀ 緒に採⽤する 14 / 31
15. How to GKE -> stackdriver? GKE のデフォルトでは、log がstackdriver に送られて いる。 こんな感じ I GET 200 10.31 KB null Go-http-client/1.1 https://grafana.threetreeslig I GET 200 26.02 KB null Go-http-client/1.1 https://threetreeslight.com/ I GET 200 10.31 KB null Go-http-client/1.1 https://grafana.threetreeslig I GET 200 26.02 KB null Go-http-client/1.1 https://threetreeslight.com/ 15 / 31
16. 構成を確認する % kubectl get deployment,ds,pod --namespace=kube-system NAME DESIRED CURRENT UP-TO-D deployment.extensions/event-exporter-v0.1.8 1 1 1 deployment.extensions/heapster-v1.4.3 1 1 1 deployment.extensions/kube-dns 1 1 1 deployment.extensions/kube-dns-autoscaler 1 1 1 deployment.extensions/kubernetes-dashboard 1 1 1 deployment.extensions/l7-default-backend 1 1 1 NAME DESIRED CURRENT READY U daemonset.extensions/fluentd-gcp-v2.0.9 1 1 1 1 NAME READY STATUS pod/event-exporter-v0.1.8-599c8775b7-qthr8 2/2 Running pod/fluentd-gcp-v2.0.9-8mm85 2/2 Running pod/heapster-v1.4.3-f9f9ddd55-n8cnf 3/3 Running pod/kube-dns-778977457c-68gsl 3/3 Running 16 / 31
17. uetnd が daemonset 17 / 31
18. GEK logging with uentd どのような設定かも確認するしていく 18 / 31
19. daemonset https://github.com/kubernetes/kubernetes/blob/master/clus gcp/fluentd-gcp-ds.yaml containers: - name: fluentd-gcp image: gcr.io/stackdriver-agents/stackdriver-logging-agent:{{ flu volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true 19 / 31
20. uentd conf container input https://github.com/kubernetes/kubernetes/blob/master/clus gcp/fluentd-gcp-configmap.yaml containers.input.conf: |- ... @type tail path /var/log/containers/*.log 20 / 31
21. sysmte input system.input.conf: |- ... # logfile path /var/log/startupscript.log path /var/log/docker.log path /var/log/etcd.log path /var/log/kubelet.log path /var/log/kube-proxy.log path /var/log/kube-apiserver.log path /var/log/kube-controller-manager.log path /var/log/kube-scheduler.log path /var/log/rescheduler.log path /var/log/glbc.log path /var/log/cluster-autoscaler.log # systemd filters [{ " SYSTEMD UNIT": "docker.service" }] 21 / 31
22. output output.conf: |- ... <match {stderr,stdout}> @type google_cloud 22 / 31
23. カスタマイズは？ 設定変更やカスタマイズは、daemonset やconfig を いじれば良い GCP - Customizing Stackdriver Logs for Kubernetes Engine with Fluentd kubernates - Logging Using Stackdriver 23 / 31
24. stackdriver -> gcs, bq すればよい のでは？ nginx prometheus grafana | | | ------------------- ||| node logging agent(fluentd) ||| stack driver | cloud pubsub | ------------------- | | | bigquery gcs papertrail/stackdriver 24 / 31
25. こういうのもありかも？ nginx prometheus grafana | | | ------------------- ||| node logging agent(fluentd) ||| logging aggregater(fluentd cluster) | ------------------- | | | bigquery gcs papertrail/stackdriver 25 / 31
26. そもそも node ごとにあるfleutnd 設定いじるのって正しいの？ node にあるfluentd を触ると、配置されるpod によっ てnode ごとのfluentd 負荷が変わっちゃうだろうけ ど、致し⽅ないのだろうか？ papertrail やdatadog logging あたりにつなぎこむん であればnode logging agent をカスタマイズするのあ りな認識。 26 / 31
27. とりあえずカスタマイズしてみる logging service を停⽌する必要がある。 dynamic に変えられるようになったのすごい. beta だ けど。 Prerequisites. If you’re using GKE and Stackdriver Logging is enabled in your cluster, you cannot change its configuration, because it’s managed and supported by GKE. gcloud beta container clusters update --logging-service=none blog-cluster 27 / 31
28. 設定 は以下のrepo の内容を使うことも可能 すでにfluentd daemonset が動いているので、設定を 吐き出すことにする GoogleCloudPlatform/k8s-stackdriver GoogleCloudPlatform/container-engine-customize- fluentd kubernetes/kubernetes - fluentd-gcp 28 / 31
29. 既存設定を書き出す # daemonset % kubectl get ds --namespace kube-system | grep fluentd | awk '{ print $1 fluentd-gcp-v2.0.9 % kubectl get ds fluentd-gcp-v2.0.9 --namespace kube-system -o yaml > flu fluentd-gcp-v2.0.9 # fluentd conf % kubectl get cm --namespace kube-system | grep fluentd | awk '{ print $ fluentd-gcp-config-v1.2.2 kubectl get cm fluentd-gcp-config-v1.2.2 --namespace kube-system -o yaml 29 / 31
30. ここからがん ばること :innocent: 1. papertrail につなぎこむ設定を書いていく 2. GCS, BQ にはcloud pubsub を使って吐き出していく 30 / 31
31. まとめ 1. Using a node logging agent アプローチを採⽤する 2. application からログのparse, buffering, retry 処理を切り 離したいのであれば、Streaming sidecar container も採 ⽤する 3. gcp のstack に乗るんであればstackdriver export を使って データ加⼯することが望ましい 4. node logging agent の設定カスタマイズは趣味や papertrail やdatadog logging など別基盤に流すときぐら いにしかつかわない 31 / 31