$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kubernetes_Logging入門.pdf
Search
yosshi_
July 23, 2019
Technology
18
7.5k
Kubernetes_Logging入門.pdf
yosshi_
July 23, 2019
Tweet
Share
More Decks by yosshi_
See All by yosshi_
Getting Started with Kubernetes Observability
yosshi_
8
2.4k
PromQL_Compatibility_Testing_Recap
yosshi_
0
1k
プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki
yosshi_
11
3.3k
これから学ぶKubernetesのReconciliation Loop
yosshi_
11
3.7k
伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf
yosshi_
12
5.7k
KubeCon2019_NA_Recap__NATS_.pdf
yosshi_
0
150
“Running Apache Samza on Kubernetes” Recap : KubeCon2019@NA
yosshi_
3
1.1k
Kuberntes_Monitoring_入門.pdf
yosshi_
17
3k
Vitessの基礎.pdf
yosshi_
7
1.4k
Other Decks in Technology
See All in Technology
Kubernetesを知る
logica0419
17
4.3k
乗っ取れKubernetes!!~リスクから学ぶKubernetesセキュリティの考え方~/k8s-risk-and-security
mochizuki875
3
420
突き破って学ぶコンテナセキュリティ/container-breakout-cncj-lt
mochizuki875
3
120
セキュリティベンダー/ユーザー双方の視点で語る、 Attack Surface Managementの実践 - Finatextパート / cloudnative-architecture-of-asm
stajima
0
2.6k
偶有的複雑性と戦うためのアーキテクチャとチームトポロジー
knih
7
6k
Hyperledger Fabric(再)入門
gakumura
3
6.7k
sre本読んだ感想
pisakun
0
160
レガシーシステムへのDatadog APM導入奮闘記
mtakeya4062
0
130
Postman Flowsで作るAPI連携LINE Bot
miura55
0
220
2024/11/29_失敗談から学ぶ! エンジニア向けre:Invent攻略アンチパターン集
hiashisan
0
250
PFN Company Deck
pfn
PRO
2
140
大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~
colopl
0
770
Featured
See All Featured
Being A Developer After 40
akosma
87
590k
The Language of Interfaces
destraynor
154
24k
Imperfection Machines: The Place of Print at Facebook
scottboms
266
13k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
760
Building an army of robots
kneath
302
43k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Agile that works and the tools we love
rasmusluckow
327
21k
Transcript
入門 CloudNative Days Tokyo 2019 虎ノ門ヒルズ
• 吉村 翔太 • コミュニケーションズ所属 • データサイエンスチーム • インフラエンジニア データエンジニアリング
• 、 • 趣味:ボードゲーム • コミュニティ活動 自己紹介
• Kubernetesをはじめて困ること • KubernetesにおけるLoggingとは • どうしてコンテナのログは難しい? • kubectl logsコマンド •
Kubernetes Logging Architecture • System Component Logs 本日の目次
をはじめて困ること
• 最初に困ること – DeploymentとServiceを使ってコンテナにアクセスする・・よく分からない – ConfigMapを使って、パラメータを設定する・・・ギリギリわかる – PVCとPVを使ってディスクをマウントする・・・全く分からない • 次に困ること
– CI/CDのパイプラインを作る – Kubernetesの監視基盤を作る 今日はこの中のログの話 K8sを触り始めた時の自分の感想 Kubernetesをはじめて困ること
• 一晩でKubernetesを覚えて帰ろう。 ワンナイトBootCamp! -- cndjp#10 • OCHaCafe2 #1-これからはじめる! Kubernetes基礎 参考
https://cnd.connpass.com/event/123046/ 参考 https://ochacafe.connpass.com/event/136115/ 参考: 初心者向けの資料
における とは
Cloud Nativeとは Observability(可観測性)を 持っていること 参考 https://github.com/cncf/toc/blob/master/DEFINITION.md
Observabilityとは 参考 https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf • Metrics, Logs & Tracesを集めて状態を観測出来るようにすること
参考:Metrics, Logs & Tracesのサンプル 参考 https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf
Observabilityで目指すところ 参考 https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/
KubernetesにおけるLoggingとは (1/2) 参考 https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-logging • 公式サイトの用語集によると
KubernetesにおけるLoggingとは (2/2) • 対象のログ – Application Logs • Kubernetes上にDeployしたコンテナのログ –
System Component Logs • Control Planeと呼ばれるKuberntesのクラスタを支えるコンポーネントのログ • 目的 – プログラムのデバッグのため – クラスタの状態を把握するため 他にもAudit Logs(監査用)のログもあります。
今日話す割合 • Application Logs ( 80% ) • System Component
Logs ( 20% ) • Audit Logs ( 0% ) みなさんがよく使うので割合は多め マネージドサービスを使うとそもそも考えな くていいので軽く触れる程度 上記のセッションで詳しく話してくれると信じてます。 [2H4] 16:40 - 17:20 「Kubernetesにauditログを求めるのは間違っているだろうか」 by 長谷川 誠 (サイバーエージェント)
どうしてコンテナのログは難しい?
コンテナの特徴 • コンテナが消えると元の環境に戻る コンテナ サーバ サーバ コンテナを する前と同じ
コンテナのログが見たい時 • 何らかのトラブルがあったからログが見たい コンテナ サーバ サーバ コンテナにトラブルが発生 ログが見たいのにコンテナごとない
コンテナオーケストレーション使用時の難しさ サーバ サーバ • コンテナがどこにDeployされるかはオーケストレーション任せ • トラブル時にどのサーバにコンテナがあったか分からない サーバ 正常に動いてた時はここにいたの?
物理&VMと比べた時のコンテナのログの難しさ • 物理&VMのログ – ログの出力先のファイルパスを理解しておく – ログを見たい時は対象のファイルパスを見ればよかった • コンテナのログ –
コンテナが消えると、コンテナがDeployされる前の環境に戻る – ログに関するアーキテクチャを正しく理解した上で、 設計しておかないとログが追えない
コマンド
kubectl logs コマンド (1/2) • “kubectl logs”はKubernetes上のコンテナのログを確認するコマンド ログファイル コンテナ コンテナが“
”に 出力したログを確認できる からのリクエストの受付 : 上のエージェント
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'] の定義 を の 先の を気にすることなく ログが確認できる ここで思考を止めずに このログが何か考える
Kubeletが見ているログファイル • “/var/logs/pods/コンテナ名”の配下のファイルを見てる ログファイル なぜかリンクになっている?
Dockerが書き出しているログファイル • “/var/lib/docker/containers/”の配下のファイルを見てる が見ていたログと同じ ログファイル コンテナ
kubectl logs コマンドの振り返り • “kubectl logs”はKubernetes上のコンテナのログを確認するコマンド ログファイル コンテナ “/var/logs/pods” からのリクエストの受付
: 上のエージェント “/var/lib/docker/containers/”
kubectl logsで困ること サーバ サーバ • コンテナをたくさんDeployした時にログを追いかけるのが大変 • サーバそのものが故障した場合にログが残らない可能性がある サーバ サーバがなくなると当然ログもない
コンテナ
ログの収集基盤 • コンテナをたくさんDeployした時にログを追いかけるのが大変 • ログが保管されている場所が欲しい ログの収集基盤 ログファイル の外にログが保管されててほしい
• “kubectl logs --help”かReferenceを見るともっと分かります 参考 hhttps://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs 参考:kubectl logsをもっと詳しく
None
KubernetesのLoggingのArchitectureについて • 大きく分けて3種類のアーキテクチャがある アプリケーションからの直接出力 参考 https://kubernetes.io/docs/concepts/cluster-administration/logging/ 経由での出力 クラスタ単位での出力
アプリケーションからの直接出力 • 方法 – アプリケーションが直接、ログ収集基盤に出力する • 特徴 – Kubernetesに対する理解があまり要らない •
懸念点 – 各チームが違う言語で作り始めた時に、ルールとかその他諸々作るのが大変? – アプリケーション側で設計されてないとログが収集されない コンテナを多数 する場合 ログにホスト名が入ってないと追跡できない ログの出力先が環境変数で 定義されてるといいな
Sidecar経由での出力 • 方法 – Fluentdなどを使って、アプリケーションのログをログ収集基盤に出力する • 特徴 – Kubernetesに対する理解はSidecarの仕組みが分かればなんとかなる –
ログの加工やログ収集基盤の情報をアプリケーションから剥がしてSidecarに持たせられる • 懸念点 – Sidecarが死ぬとメインのコンテナも一緒に死ぬ – Sidecarを仕込み忘れるとログが収集されない
コンテナ コンテナ の定義 の状態 の中にコンテナが 個あることが分かる 単位に が 個ある をデプロイすると
内のコンテナ間で ディスク領域を共有できる 参考:Sidecarとは
クラスタ単位での出力 その1 • 方法 – 各ノードにDeamonSetでFluentdなどをDeployしてログを収集する • 特徴 – Kubernetesのログの仕組みに対して理解が必要 –
アプリケーション側で何もしなくてもログが収集できる • 懸念点 – コンテナが にログを出力しないと取れない
クラスタ単位での出力 その2 • 方法 – アプリケーションのログをFluentdなどのSidecarでつけて に出力する – 各ノードにDeamonSetでFluentdなどをDeployしてログを収集する • 特徴
– Kubernetesのログの仕組みに対して理解が必要 – アプリケーション側で何もしなくてもログが収集できる – 既存のコンテナが に出力しなくても使える • 懸念点 – Sidecarが死ぬとメインのコンテナも一緒に死ぬ – Sidecarを仕込み忘れるとログが収集されない
方法 特徴 アプリケーションからの直 接出力 Kubernetesのことが分からなくても良い アプリケーション側で好きにできる kubectl logsがあまり使えない Sidecar経由での出力 Kubernetesについてそこまで分からなくても良い
FluentdなどのLogging Agentの機能を使えば柔軟に対応できる kubectl logsがあまり使えない クラスタ単位での出力 Kuberntesについては理解が必要 クラスタ単位で設定するためKubernetes上の全てのコンテナのログを収集できる kubectl logsが存分に使用できる 個人的には「クラスタ単位での出力」がおすすめ Logging Architectureのおさらい
• Elasticsearch and Kibana – https://kubernetes.io/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/ • Stackdriver – https://kubernetes.io/docs/tasks/debug-application-cluster/logging-stackdriver/
参考:公式にLoggingの方法が2つ載ってる
完全ガイド 実践ガイド 実践入門 参考:書籍
None
Lokiとは • Lokiとは – Prometheusのようにログを操作できる • 用途 – Grafana経由でLokiに接続することで Logを可視化できる
• GitHub – ★6,609 | https://github.com/grafana/loki • 開発主体 – Grafana Labs 初心者向けにβ版のプロダクトを説明するってなんなの?って話はありますが そもそも、Lokiの話がしたくて前段としてログの説明をしてるので許して欲しい (CFP応募の2019/2時点でLokiは無名)
KubeConでの発表の歴史と個人的な感想 • KubeCon 2018 NA で発表 – 反響:あまりない – 出来栄え:α版、商用で絶対に使わないで
• そもそも当時のGrafanaで使えない – 所感:無理矢理出した感あるけど期待したい – 参考:https://sched.co/GrXC • KubeCon 2019 EU で発表 – 反響:Keynoteで騒がれる – 出来栄え:β版 • でも機能がまだ足りない – 所感:いい感じに進化してる – 参考:https://sched.co/MPbj が変わった!
What is “Grafa Loki” ? • 概要 – ログの収集と可視化ツール •
開発の背景 – Metricsだけではインシデントの全容の半分しか分からない – MetricsとLogsの参照時の切替コストを最小限にしたい(Grafanaで完結したい) • アプローチ – Prometheusと同様にラベルがあって、時系列にデータを格納 – Cortexを参考に水平スケールを意識 • Non-Goal – みたいな統計情報 長期間のログに対しての統計情報の取得はターゲットにしてない プロダクト選定にあたり が自分たちのビジネスをスケールするにあたり だけじゃなくて をターゲットにする姿勢は信用できる
LokiとPrometheus、Cortexの関係性 のログ版 を 水平スケール 水平スケールの アーキテクチャを踏襲
Cortexのアーキテクチャ 参考 https://github.com/cortexproject/cortex/blob/master/docs/architecture.md
Lokiのアーキテクチャ 参考 https://grafana.com/blog/2019/04/15/how-we-designed-loki-to-work-easily-both-as-microservices-and-as-monoliths/ 入力が だいたい一緒ですね
Lokiのアーキテクチャ(簡易) • “Promtail”をdeamonsetで各ノードに配置してログを収集 を に置き換えることも可 参考 https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ 上のコンテナのメタデータも が集めて ログに付与してくれる
Lokiの操作 (1/4) 接続先を設定
Lokiの操作 (2/4) で操作
Lokiの操作 (3/4) 表示したい条件を入力 時系列で表示
Lokiの操作 (4/4) 割合も表示してくれる 現時点の印象:kubectl logsをGUIでできるツールっぽい
Lokiの今後について思うこと • 機能面に対する要望 – ダッシュボード • メトリクスと同じダッシュボードにログも載せたい – アラート •
“error”って文字列を見つけたらSlackのチャネルに通知して欲しい • 公式のGitHubに期待すること – ドキュメントをもう少しなんとか・・ • “prometheus.io”みたいな公式サイトを作る話もある – Helmをもう少し整備して欲しい・・ • “ksonnet”のメンテはもういいから、Helmをもう少しメンテして欲しい • KubeCon 2019 North America(11/18–21)でGAになることを期待
参考:LokiのGUIに興味が沸いたら 参考 https://grafana.com/blog/2019/01/02/closer-look-at-grafanas-user-interface-for-loki/ • Grafana Labsのこの記事がおすすめ
参考:Lokiのメトリクスがある 参考 https://grafana.com/blog/2019/07/18/lokis-path-to-ga-loki-canary-early-detection-for-missing-logs/ • Loki自身のメトリクスが取れる
参考:もっとLokiを知りたくなったら 参考 https://grafana.com/categories/loki/ • 公式のGitHubがGrafanaLabsのBlogがおすすめ(正直、他に情報がない)
• Helmの環境構築 1-1 helmのinit – 1-2 helm(tiller)へ権限を付与 実践 の詳しい話はこちら 参考:簡単!Lokiの環境構築
-Helm-
2-3 namespaceの作成 2-2 helmのレポジトリのアップデート 2-1 Lokiのレポジトリの登録 • Lokiの環境構築 参考 https://github.com/grafana/loki/tree/master/production/helm
2-4 Lokiのデプロイ 参考:簡単!Lokiの環境構築 -Loki-
3-4 ブラウザで「http://localhost:3000/」にアクセス • Grafanaの環境構築 3-3 port-forward 3-2 Grafanaのadminのパスワードの確認 3-1 Grafanaのインストール
参考:簡単!Lokiの環境構築 -Grafana-
先ほど確認した パスワードを入力 参考:簡単!Lokiの環境構築 GUI操作 (1/5)
クリック 参考:簡単!Lokiの環境構築 GUI操作 (2/5)
クリック 参考:簡単!Lokiの環境構築 GUI操作 (3/5)
クリック を入力 参考:簡単!Lokiの環境構築 GUI操作 (4/5)
クリック 参考:簡単!Lokiの環境構築 GUI操作 (5/5)
None
コンテナ コンテナ そもそもKubernetesの全体はこんな感じ 経由で の操作を行い、 の状態に応じてアクションする
コンテナ コンテナ System Component Logsの範囲 経由で の操作を行い、 の状態に応じてアクションする コンテナ以外全部
▪ API Server ▪ Controller Manager ▪ Scheduler etcdへのwrite、readを行うAPIサーバ 複数台配置して冗長化構成をとることができる
デプロイするコンテナの個数等を管理する 複数台配置できるがリーダは1つだけ コンテナをどのNodeにデプロイするか決める 複数台配置できるがリーダは1つだけ 参考:Control Plane Components (1/2)
▪ Container runtime ▪ Kubelet ▪ Kube-proxy 文字通りコンテナのランタイム Docker以外を使用することもできる Node上に配置されるエージェント
コンテナの起動停止等を行う コンテナとの接続を保証するためにNodeのNWを管理する 参考:Control Plane Components (2/2)
“kube-system”のnamespaceを確認する 以外が全部いる 補足 この クラスタは 製です
Master Nodeの中身 も実はコンテナ
systemctlで“kubelet”を確認する (1/4) └─ └─ 起動時にこの を読んでる
systemctlで“kubelet”を確認する (2/4) 参考 https://kubernetes.io/docs/tasks/administer-cluster/static-pod/ Static Pods機能を使うと 起動時に指定したmanifestに書かれたPodを 起動することができる
systemctlで“kubelet”を確認する (3/4) 起動時に で指定した の が立つことで として機能している 参考 https://kubernetes.io/docs/tasks/administer-cluster/static-pod/
systemctlで“kubelet”を確認する (4/4) 中身は普通の
Application Logsと同じように扱える 「クラスタ単位での出力」のログ収集基盤を構築しておくと も集まるのでおすすめ System Component Logsの見方
参考:kubectl logsで確認する System Component Logsが“kubectl logs”で確認できる
kubeletのログを確認する (1/2) 最後にkubeletのログを確認する
kubeletのログを確認する (2/2) コンテナの知識はいらず、 の知識で確認できる
• 結局、見るべきログは2種類 コンテナの ログファイル コンテナ “kubectl logs” kubeletの ログファイル “journalctl
-u kubelet” Kubernetes Loggingのまとめ
Special Thanks!! https://cnd.connpass.com/