Kubernetes_Logging入門.pdf

24606216ae4bbee28494552cb71cc220?s=47 yosshi_
July 23, 2019

 Kubernetes_Logging入門.pdf

24606216ae4bbee28494552cb71cc220?s=128

yosshi_

July 23, 2019
Tweet

Transcript

  1. 6.

    • 一晩でKubernetesを覚えて帰ろう。 ワンナイトBootCamp! -- cndjp#10 • OCHaCafe2 #1-これからはじめる! Kubernetes基礎 参考

    https://cnd.connpass.com/event/123046/ 参考 https://ochacafe.connpass.com/event/136115/ 参考: 初心者向けの資料
  2. 13.

    KubernetesにおけるLoggingとは (2/2) • 対象のログ – Application Logs • Kubernetes上にDeployしたコンテナのログ –

    System Component Logs • Control Planeと呼ばれるKuberntesのクラスタを支えるコンポーネントのログ • 目的 – プログラムのデバッグのため – クラスタの状態を把握するため 他にもAudit Logs(監査用)のログもあります。
  3. 14.

    今日話す割合 • Application Logs ( 80% ) • System Component

    Logs ( 20% ) • Audit Logs ( 0% ) みなさんがよく使うので割合は多め マネージドサービスを使うとそもそも考えな くていいので軽く触れる程度 上記のセッションで詳しく話してくれると信じてます。 [2H4] 16:40 - 17:20 「Kubernetesにauditログを求めるのは間違っているだろうか」 by 長谷川 誠 (サイバーエージェント)
  4. 19.

    物理&VMと比べた時のコンテナのログの難しさ • 物理&VMのログ – ログの出力先のファイルパスを理解しておく – ログを見たい時は対象のファイルパスを見ればよかった • コンテナのログ –

    コンテナが消えると、コンテナがDeployされる前の環境に戻る – ログに関するアーキテクチャを正しく理解した上で、 設計しておかないとログが追えない
  5. 22.

    kubectl logs コマンド (2/2) apiVersion: v1 kind: Pod metadata: name:

    counter spec: containers: - name: count image: busybox args: [/bin/sh, -c, 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'] の定義 を の 先の を気にすることなく ログが確認できる ここで思考を止めずに このログが何か考える
  6. 29.
  7. 31.

    アプリケーションからの直接出力 • 方法 – アプリケーションが直接、ログ収集基盤に出力する • 特徴 – Kubernetesに対する理解があまり要らない •

    懸念点 – 各チームが違う言語で作り始めた時に、ルールとかその他諸々作るのが大変? – アプリケーション側で設計されてないとログが収集されない コンテナを多数 する場合 ログにホスト名が入ってないと追跡できない ログの出力先が環境変数で 定義されてるといいな
  8. 32.

    Sidecar経由での出力 • 方法 – Fluentdなどを使って、アプリケーションのログをログ収集基盤に出力する • 特徴 – Kubernetesに対する理解はSidecarの仕組みが分かればなんとかなる –

    ログの加工やログ収集基盤の情報をアプリケーションから剥がしてSidecarに持たせられる • 懸念点 – Sidecarが死ぬとメインのコンテナも一緒に死ぬ – Sidecarを仕込み忘れるとログが収集されない
  9. 34.

    クラスタ単位での出力 その1 • 方法 – 各ノードにDeamonSetでFluentdなどをDeployしてログを収集する • 特徴 – Kubernetesのログの仕組みに対して理解が必要 –

    アプリケーション側で何もしなくてもログが収集できる • 懸念点 – コンテナが にログを出力しないと取れない
  10. 35.

    クラスタ単位での出力 その2 • 方法 – アプリケーションのログをFluentdなどのSidecarでつけて に出力する – 各ノードにDeamonSetでFluentdなどをDeployしてログを収集する • 特徴

    – Kubernetesのログの仕組みに対して理解が必要 – アプリケーション側で何もしなくてもログが収集できる – 既存のコンテナが に出力しなくても使える • 懸念点 – Sidecarが死ぬとメインのコンテナも一緒に死ぬ – Sidecarを仕込み忘れるとログが収集されない
  11. 36.

    方法 特徴 アプリケーションからの直 接出力 Kubernetesのことが分からなくても良い アプリケーション側で好きにできる kubectl logsがあまり使えない Sidecar経由での出力 Kubernetesについてそこまで分からなくても良い

    FluentdなどのLogging Agentの機能を使えば柔軟に対応できる kubectl logsがあまり使えない クラスタ単位での出力 Kuberntesについては理解が必要 クラスタ単位で設定するためKubernetes上の全てのコンテナのログを収集できる kubectl logsが存分に使用できる 個人的には「クラスタ単位での出力」がおすすめ Logging Architectureのおさらい
  12. 39.
  13. 40.

    Lokiとは • Lokiとは – Prometheusのようにログを操作できる • 用途 – Grafana経由でLokiに接続することで Logを可視化できる

    • GitHub – ★6,609 | https://github.com/grafana/loki • 開発主体 – Grafana Labs 初心者向けにβ版のプロダクトを説明するってなんなの?って話はありますが そもそも、Lokiの話がしたくて前段としてログの説明をしてるので許して欲しい (CFP応募の2019/2時点でLokiは無名)
  14. 41.

    KubeConでの発表の歴史と個人的な感想 • KubeCon 2018 NA で発表 – 反響:あまりない – 出来栄え:α版、商用で絶対に使わないで

    • そもそも当時のGrafanaで使えない – 所感:無理矢理出した感あるけど期待したい – 参考:https://sched.co/GrXC • KubeCon 2019 EU で発表 – 反響:Keynoteで騒がれる – 出来栄え:β版 • でも機能がまだ足りない – 所感:いい感じに進化してる – 参考:https://sched.co/MPbj が変わった!
  15. 42.

    What is “Grafa Loki” ? • 概要 – ログの収集と可視化ツール •

    開発の背景 – Metricsだけではインシデントの全容の半分しか分からない – MetricsとLogsの参照時の切替コストを最小限にしたい(Grafanaで完結したい) • アプローチ – Prometheusと同様にラベルがあって、時系列にデータを格納 – Cortexを参考に水平スケールを意識 • Non-Goal – みたいな統計情報 長期間のログに対しての統計情報の取得はターゲットにしてない プロダクト選定にあたり が自分たちのビジネスをスケールするにあたり だけじゃなくて をターゲットにする姿勢は信用できる
  16. 51.

    Lokiの今後について思うこと • 機能面に対する要望 – ダッシュボード • メトリクスと同じダッシュボードにログも載せたい – アラート •

    “error”って文字列を見つけたらSlackのチャネルに通知して欲しい • 公式のGitHubに期待すること – ドキュメントをもう少しなんとか・・ • “prometheus.io”みたいな公式サイトを作る話もある – Helmをもう少し整備して欲しい・・ • “ksonnet”のメンテはもういいから、Helmをもう少しメンテして欲しい • KubeCon 2019 North America(11/18–21)でGAになることを期待
  17. 63.
  18. 66.

    ▪ API Server ▪ Controller Manager ▪ Scheduler etcdへのwrite、readを行うAPIサーバ 複数台配置して冗長化構成をとることができる

    デプロイするコンテナの個数等を管理する 複数台配置できるがリーダは1つだけ コンテナをどのNodeにデプロイするか決める 複数台配置できるがリーダは1つだけ 参考:Control Plane Components (1/2)
  19. 67.

    ▪ Container runtime ▪ Kubelet ▪ Kube-proxy 文字通りコンテナのランタイム Docker以外を使用することもできる Node上に配置されるエージェント

    コンテナの起動停止等を行う コンテナとの接続を保証するためにNodeのNWを管理する 参考:Control Plane Components (2/2)