Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
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.8k
伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.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
Wantedly での Datadog 活用事例
bgpat
1
490
10分で学ぶKubernetesコンテナセキュリティ/10min-k8s-container-sec
mochizuki875
3
350
podman_update_2024-12
orimanabu
1
270
なぜCodeceptJSを選んだか
goataka
0
160
KnowledgeBaseDocuments APIでベクトルインデックス管理を自動化する
iidaxs
1
260
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
3
2.4k
Opcodeを読んでいたら何故かphp-srcを読んでいた話
murashotaro
0
260
私なりのAIのご紹介 [2024年版]
qt_luigi
1
120
普通のエンジニアがLaravelコアチームメンバーになるまで
avosalmon
0
100
継続的にアウトカムを生み出し ビジネスにつなげる、 戦略と運営に対するタイミーのQUEST(探求)
zigorou
0
570
権威ドキュメントで振り返る2024 #年忘れセキュリティ2024
hirotomotaguchi
2
750
2024年にチャレンジしたことを振り返るぞ
mitchan
0
140
Featured
See All Featured
Designing Experiences People Love
moore
138
23k
Thoughts on Productivity
jonyablonski
67
4.4k
Being A Developer After 40
akosma
87
590k
How GitHub (no longer) Works
holman
311
140k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
5
450
Scaling GitHub
holman
458
140k
Producing Creativity
orderedlist
PRO
341
39k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
A Philosophy of Restraint
colly
203
16k
The Pragmatic Product Professional
lauravandoore
32
6.3k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
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/