ç Kubernetes Observability入門 Observability Conference 2022 @yosshi_

● 吉村 翔太 ● ゼットラボ株式会社 ソフトウェアエンジニア ● 経歴 SIer 6年、通信事業者のR&D 2年 etc ● Kurbernetes 、Prometheus　 etc ● 登壇 CNDT “Kubernetes Logging入門” etc ● コミュニティ活動“Cloud Native Developers JP” “Prometheus Meetup Tokyo” 　　　　　　　　　 @yosshi_ 自己紹介

本日のゴール • Observabilityが何かわかる – Observabilityがあるとはどういう状態なのかイメージが持てるようになる • 5つのSignalの収集方法と使い方がわかる – KubernetesでMetricsやLogsを収集して使えるようになる – Traces、Profiles、Dumpsについてどういうものかイメージを持てるようになる

What is Observability?（1/2） 参考 : glossary.cncf.io < https://glossary.cncf.io/observability/ > CNCFの用語集には上記のように記載されている

What is Observability?（2/2） 参考 : glossary.cncf.io < https://glossary.cncf.io/observability/ > 読みやすいようにGoogle翻訳にかけてみますが、このままでは抽象的で具体的に何をしていいか分からない

TAGとWhitepaper • CNCF Technical Advisory Groups (TAG) – 特定のテーマ毎に、実用的な情報や教育コンテンツを提供するグループ – 特定のベンダーやプラットフォームに依存しないアウトプットすることを定めている – Observabilityの他にも、Network、Security、Storage、Runtime などが存在する 参考 : < https://github.com/cncf >

Observability Whitepaper とは 参考 : Observability Whitepaper < https://github.com/cncf/tag-observability/blob/main/whitepaper.md > This paper aims to get you quickly started with different kinds of observability you might need to work within the cloud-native world. 既に取り組んでいる企業で得た知見をもとに、 各Signalsの収集方法と使い方がまとめられています • Observabilityに取り組めるようになるためのドキュメント

● HARTMANN, Richard. Talk given at Fosdem (Brussels), Feb 2019. < https://archive.fosdem.org/2019/schedule/event/on_observability_2019/ > ● SRIDHARAN, Cindy. Distributed Systems Observability. Chapter 04, The Three Pillars of Observability. 2018 < https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html. > ● BEYER, Betsy; JONES, Chris; MURPHY, Niall; PETOFF, Jennifer. Site Reliability Engineering. O'Reilly Media, 2016. < https://sre.google/sre-book/table-of-contents/ > ● BEYER, Betsy; MURPHY, Niall; RENSIN, David; KAWAHARA, Kent; THORNE, Stephen. The Site Reliability Workbook. O'Reilly Media, 2018 < https://sre.google/workbook/table-of-contents/ > ● SRIDHARAN, Cindy. Monitoring and Observability. Sep 5, 2017 < https://copyconstruct.medium.com/monitoring-and-observability-8417d1952e1c > ● MCCARTHY, Kate; FONG-JONES, Liz; FISHER, Danyel; MAHON, Deirdre; PERKINS, Rachel. Observability Maturity: Community Research Findings Q1, 2020. < https://www.honeycomb.io/wp-content/uploads/2020/04/observability-maturity-report-4-3-2020-1-1.pdf > ● Kalman R. E., On the General Theory of Control Systems, London 1961. < https://www.sciencedirect.com/science/article/pii/S1474667017700948?via%3Dihub > 60年前に書かれたこの論文に記載がある Observabilityとは 〜参考資料〜

1960年に執筆された制御工学の論文 Section 6 からObservability について記載されてます Observabilityはここ数年で できた考え方ではなく60年前からある

Controller Plant (制御対象) Command (目標値) Disturbance (外乱) in out Feedback Closed-loop diagram (閉ループ制御) 開ループ制御と閉ループ制御の２つのモデル Controller Plant (制御対象) Command (目標値) Disturbance (外乱) in out Open-loop diagram (開ループ制御) 20度の暖風を出してと命令したらエアコンが20度の暖風を出すモデル 室温を20度にしてと命令したらエアコンが自動で室温を保ってくれるモデル

Observabilityを満たすとは？ Controller Plant (制御対象) Command (目標値) Disturbance (外乱) in out Feedback Closed-loop diagram (閉ループ制御) • 閉ループ制御が実現できている Controllabilityがある(可制御) • 閉ループ制御を実施するのに必要な十分な in/out(測定対象) の情報を取得できている Observabilityがある(可観測) 説明をわかりやすくするために ここはぼかしてます

KubernetesのHPAで例えてみると • CPU使用率を元にサービスに必要なPod数を制御できている状態 (閉ループ制御が成立) – Controllabilityがある – Observabilityがある 「Observability」は「Controllability」を実現するための大事な概念という位置付け この説明を聞いても正直Observabilityで何をしていいかわからないし、Controllabilityのあるシステムを作 るなんて夢のまた夢という人が大半だと思います • CPU使用率だけでサービスに必要なPod数を制御できていない状態 (閉ループ制御が不成立) – Controllabilityがない – Observabilityは不明 – CPU使用率だけでは入力値が足りていない？ Controllerの処理が適切でない？

Observability Signals • Metrics • Logs • Traces – 分散トレーシングの話 • Profiles – 主にApplication profilesの話 • Dumps – core dumpの話 Whitepaperでは以下の5つのSignals(測定対象)とその使い方が記載されています Whitepaperの内容だけでは Kubernetesの時にどうすればいいか分からないので 以降のページで説明していきます 現在、5種類ですが今後増えていく可能性があります

Three pillars(三本の柱) Primary Signals We like to think of them as the "primary signals" instead of "three pillars" for two reasons • 今はPrimary Signalsと呼びます – Three pillars は 2019年頃に KubeConのKeynoteなどで使われていました • 理由1 – 柱だと3つ全て揃ってないとダメなイメージがあるが 用途によっては1つだけで大丈夫なケースもある • 理由2 – ProfilesやDumpsなどが対象から漏れることが多 い

Kubernetes Metrics 入門

Vertical Pod Autoscaler (Autoscaling) Horizontal Pod Autoscaler (Autoscaling) Receiver (Slack, PagerDuty etc) Kubernetes API Prometheus adapter (Metrics APIs) Alertmanager (Alert) Grafana (Dashboard) Prometheusを使用した際のMetricsの全体図 Prometheus (Collect,Store,Query) kube state metrics Control Plane Kubelet (cAdvisor) Node exporter Applications 収集対象 利用方法

OpenMetricsとは？ # HELP http_requests_total The total number of HTTP requests. # TYPE http_requests_total counter http_requests_total{method="post",code="200"} 1027 1395066363000 http_requests_total{method="post",code="400"} 3 1395066363000 metrics name value label • OpenMetrics – 右図のような形式のデータを収集する 参考 : Prometheus and OpenMetrics, with Richard Hartmann < https://kubernetespodcast.com/episode/037-prometheus-and-openmetrics/ > ADAM GLICK: Given all the work that you're doing with Prometheus, how did that lead you into creating the OpenMetrics Project? RICHARD HARTMANN: Politics. It's really hard for other projects, and especially for other companies, to support something with a different name on it. Even though Prometheus itself doesn't have a profit motive, so we don't have to have sales or anything, it was hard for others to accept stuff which is named after Prometheus in their own product. And this is basically why I decided to do that.

Kubernetesにおける収集対象のメトリクス一覧 • Application metrics – ユーザが作成するアプリケーションや、ユーザがデプロイするOSSのメトリクス • kube-state-metrics – Kubernetesのリソースオブジェクトの状態に関するメトリクス • Control Plane – API-Server、Scheduler、Controller-manager等に関するメトリクス • Kubelet – Kubernetesのノードと、コンテナに関するメトリクス(cAdvisor) • Node Exporter – ノードのCPU使用率やメモリ使用率等のメトリクス

メトリクスのユースケース • ダッシュボード – メトリクスを元にグラフを作って、状態を見やすくする • アラート – 異常の状態を定義して、通知するようにする • Horizontal / Vertical Pod Autoscaler – メトリクスの値を入力値としてPodの状態を制御する • SLI/SLO – メトリクスを用いてサービスの理想の状態を定義する考え方の一つ

Kubernetes Logging 入門

promtail (Log agent) Alertmanager (Alert) Grafana Loki (Log Backend) Receiver (Slack, PagerDuty etc) Grafana (Dashboard) Grafana Lokiを使用した際のLogsの全体図 Event (Container logs) Audit (Audit logs) Kubernetes Component (Container/Journal logs) Applications (Container logs) 収集対象 利用方法

Kubernetes のログ一覧 • Application Logs – ユーザが作成するアプリケーションや、ユーザがデプロイするOSSのログ • Event Logs – Kubernetesのイベント(オブジェクトの状態が遷移)に関するログ • Audit Logs – Kubernetesの監査ログ • Kubernetes Component Logs – API-Server、Scheduler、Controller-manager、Kubelet等に関するログ

Application Logsと”kubectl logs”で見れるまで API Server kubectl logs Kubelet ログファイル コンテナ Container runtime Control plane Node Worker Node stdout/stderr “/var/logs/pods”配下に格納されている • Application Logs – stdout/stderrに出力したログがContainer runtimeから出力される(Container Logs) ノードがローリングアップデート等で消えた時に どうやってログファイルを参照するか考える必要があります

KubernetesのLoggingのArchitecture • 大きく分けて３種類のアーキテクチャがある Application forwarding 参考< https://kubernetes.io/docs/concepts/cluster-administration/logging/> Sidecar processing Node agent forwarding

Application forwarding • 方法 – アプリケーションが直接、ログバックエンドにログを送る • 特徴 – Kubernetesに対する知識等は必要なく、アプリケーション単体で実現可能 • 懸念点 – アプリケーション毎に対応が必要 コンテナを多数Deployする場合 ログにホスト名が入ってないと追跡できない

Sidecar processing • 方法 – Fluentdなどを使って、アプリケーションのログをログバックエンドに出力する • 特徴 – Pod単位で実現可能 – アプリケーションからログを送る部分の機能をSidecarに持たせられる • 懸念点 – Pod単位で対応が必要

Node agent forwarding • 方法 – 各ノードにDeamonSetでFluentdなどをDeployしてログを収集する • 特徴 – Container Logsの実体がどこにあるか理解する必要がある – アプリケーション側で何もしていなくてもログが収集できる • 懸念点 – コンテナがstdout/stderrにログを出力していないと 収集できない

Event Logs (1/2) $ kubectl alpha events : 110s Normal SuccessfulCreate ReplicaSet/kube-state-metrics-69fc8b7bb7 Created pod: kube-state-metrics-69fc8b7bb7-8n89q 109s Normal Scheduled Pod/kube-state-metrics-69fc8b7bb7-8n89q Successfully assigned kube-system/kube-state-metrics-69fc8b7bb7-8n89q to demo-yosshi-123-w-default-a5f36c1c-ldssp 109s Normal Started Pod/kube-state-metrics-69fc8b7bb7-8n89q Started container kube-state-metrics 109s Normal Created Pod/kube-state-metrics-69fc8b7bb7-8n89q Created container kube-state-metrics 109s Normal Pulled Pod/kube-state-metrics-69fc8b7bb7-8n89q Container image "k8s.gcr.io/kube-state-metrics-kube-state-metrics:v2.4.1" already present on machine • kubectl alpha events/ get events 等のコマンドで取得 – eventが発生してから1時間以内(デフォルト値)のイベントが取得できる – デバック等の時に必要なログなのでeventrouterでContainer Logsに出力しておくケースが多い

API Server Control plane Node Event Logs (2/2) ログファイル eventrouter Container runtime Worker Node stdout/stderr eventrouterがeventを取得する • Event Logsの永続化 – eventrouterがContainer Logsに出力してくれることで既存のログ収集の仕組みが活用できる 参考 : eventrouter < https://github.com/heptiolabs/eventrouter >

Audit Logs apiVersion: audit.k8s.io/v1 # This is required. kind: Policy # Don't generate audit events for all requests in RequestReceived stage. omitStages: - "RequestReceived" rules: # Log pod changes at RequestResponse level - level: RequestResponse resources: - group: "" # Resource "pods" doesn't match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: ["pods"] – 以下のようなaudit-policy.yamlを設定することで指定したKubernetesの操作ログを取得できる – LogはAPI-Serverのhostpath上に出力されるので、Logging agentで収集することで永続化可能

Kubernetes Component Logs – Control Planeが以下のような構成の場合 Controller Manager Kubelet Container runtime API Server Scheduler Controle Plane Node Systemdで立ち上げている場合は Journal Logsとして出力されている “jounalctl -u kubelet” Containerで立ち上げている場合は Container Logsとして出力されている “kubectl logs”

Kubernetes のログ一覧 • Application Logs – ユーザが作成するアプリケーションや、ユーザがデプロイするOSSのログ • Event Logs – Kubernetesのイベント(オブジェクトの状態が遷移)に関するログ • Audit Logs – Kubernetesの監査ログ • Kubernetes Component Logs – API-Server、Scheduler、Controller-manager、Kubelet等に関するログ

Docker と containerd のログの違い (1/4) • Dockerからcontainerdに変更するときは以下の3点が変わります – ログの出力先 – ログフォーマット – ログローテーションの仕組み 参考 : kubernetes.io < https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/ >

Docker と containerd のログの違い (2/4) Kubelet ログファイル コンテナ Container runtime Worker Node stdout/stderr “/var/logs/pods” “/var/lib/docker/containers/” Kubelet ログファイル コンテナ Container runtime Worker Node stdout/stderr “/var/logs/pods” “/var/logs/pods” • ログの出力先の違い – Dockerは“/var/lib/docker/containers/”に出力したファイルをKubeletがシンボリックリンクで認識 – containerdの場合は“/var/logs/pods”に出力するのでKubeletは直接参照

Docker と containerd のログの違い (3/4) • ログのフォーマットの違い – Docker : Dockerで設定。Kubernetesで利用する場合はjsonのケースがほとんど – containerd : containerdで設定。text形式。jsonではないので注意が必要 $ tail 0.log {"log":"ts=2022-02-24T15:00:01.890Z caller=compact.go:518 level=info component=tsdb msg=\"write block\" mint=1645704000405 maxt=1645711200000 ulid=01FWP3XZTPATM0DNB79VN6TZW0 duration=1.419677358s\n","stream":"stderr","time":"2022-02-24T15:00:01.890727362Z"} {"log":"ts=2022-02-24T15:00:01.965Z caller=head.go:812 level=info component=tsdb msg=\"Head GC completed\" duration=72.466779ms\n","stream":"stderr","time":"2022-02-24T15:00:01.965877919Z"} $ tail 0.log 2022-02-24T15:00:03.979528555Z stderr F ts=2022-02-24T15:00:03.979Z caller=compact.go:518 level=info component=tsdb msg="write block" mint=1645704000028 maxt=1645711200000 ulid=01FWP3Y1RKQEAQXM2FMTEM1AP2 duration=1.528035987s 2022-02-24T15:00:04.057508629Z stderr F ts=2022-02-24T15:00:04.057Z caller=head.go:812 level=info component=tsdb msg="Head GC completed" duration=74.995023ms log-agentも合わせて変更しないとログが収集できなくなる

Docker と containerd のログの違い (4/4) Kubelet ログファイル コンテナ Container runtime Worker Node stdout/stderr { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3", } Kubelet ログファイル コンテナ Container runtime Worker Node stdout/stderr • ログのローテーションの違い – Docker : dockerで実施 – containerd : Kubeletで実施 apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration : containerLogMaxSize: "10Mi" containerLogMaxFiles: "5" デフォルト値も異なるので切り替えの時は注意が必要

Kubernetes Tracing 入門

Applications OpenTelemetry Collector Jaeger (Trace Backend) Grafana Tempo (Trace Backend) Grafana (Dashboard) 収集対象 Applications Tracing Agent Library Grafana Tempoを使用した際のTracesの全体図 利用方法 ここからKubernetesのクラスタコンポーネント固有の情報がなくなってきます Grana Tempoだけだとわかりにくい人も 多いと思うので、Jaegerも併記しています

分散トレーシング 参考 : jaegertracing.io < https://www.jaegertracing.io/docs/1.31/architecture/ > • Whitepaperの中のトレーシングは分散トレーシングのことになります – Kubernetesでは一つのリクエストが複数のpodを経由して完結するケース多くなります – そのため、ユニークなIDを付与してリクエストをトレースする技術になります

OpenTelemetryはトレーシングの技術？ 参考 : opentelemetry.io < https://opentelemetry.io/docs/reference/specification/logs/overview/#trace-context-in-legacy-formats > • TelemetryはTracesだけでなく、MetricsやLogsも含みます OpenTelemetryが目指す姿

Primary Signals の使い方

Primary Signals の利用イメージ 参考 : < https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ > 各Signals間は時刻を元に関連性を推測

各Signals間を関連づける 参考 < https://github.com/cncf/tag-observability/blob/main/whitepaper.md > • ユニークなIDを付与することで関連づける機能についても議論されてます logとtraceに同じIDを付与する

Grafana Loki と Grafana Tempo での例 参考 < https://grafana.com/blog/2020/11/09/trace-discovery-in-grafana-tempo-using-prometheus-exemplars-loki-2.0-queries-and-more/ > 2020-11-06T15:02:10.261121224Z stdout F level=info msg="HTTP client success" status=200 url=http://db duration=1.03636ms traceID=fb0fbe73200e474 2020-11-06T15:02:10.014657751Z stdout F level=info msg="HTTP client success" status=200 url=http://db duration=2.116557ms traceID=2c963a78f1ee0c78 2020-11-06T15:02:09.98055353Z stdout F level=info msg="HTTP client success" status=200 url=http://db duration=2.24091ms traceID=7efd169fbc41ff4a • ログにtraceIDを付与することでトレースと関連づける Grafana上でtraceIDを元に関連づけ

Kubernetes Profiles 入門

さまざまなProfiles • CPU Profilers • Heap Profilers • GPU Profilers • Mutex Profilers • IO Profilers • Language-specific Profilers ここから先はKubernetes特有の機能の紹介ではなく 今まで使っていた技術をKubernetesの時にどう使えばいいかの話になります メモリリークの原因究明など、今までのやり方だけで分からない事象が起こります

Kubernetesにおけるコンテナの操作方法 • コンテナを直接操作する – “kubectl exec”でコンテナを操作する – “kubectl debug”でエフェメラルコンテナを用意して操作する • コンテナに疎通できるようにして操作する – “kubectl port-forward”で接続する – “Service type Nodeport”等でコンテナに疎通できるようにする • ノードにsshして操作する – “kubectl get node -o wide”でノートを確認してsshする Kubernetes固有の部分はこの操作パターンを覚えること あとは今まで使ってきた技術をそのまま使っていきます

Kubernetes Dump 入門

Dump について • プログラムがクラッシュ時の原因を特定するためのCoredumpの話になります – “/proc/sys/kernerl/core_pattern”に書かれたpathにコアファイルを出力する – Kubernetes固有の操作方法等はない – コアファイルのpathをマウントしたlog-agentで収集することはできるが Kubernetesの情報と組合せて権限管理を行ったりすることが難しい Coredumpがノード単位での設定なので コンテナ単位で制御できず、ContainerIDが付与されてません ContainerでCoredumpを使いやすくするための機能提案はされて いますが、今のところ進展はありません 参考 : github.com/moby < https://github.com/moby/moby/issues/19289 >

まとめ (振り返り)

Observability Signals • Metrics • Logs • Traces – 分散トレーシングの話 • Profiles – 主にApplication profilesの話 • Dumps – core dumpの話 Whitepaperでは以下の5つのSignals(測定対象)とその使い方が記載されています Whitepaperの内容だけでは Kubernetesの時にどうすればいいか分からないので 以降のページで説明していきます 現在、5種類ですが今後増えていく可能性があります

Vertical Pod Autoscaler (Autoscaling) Horizontal Pod Autoscaler (Autoscaling) Receiver (Slack, PagerDuty etc) Kubernetes API Prometheus adapter (Metrics APIs) Alertmanager (Alert) Grafana (Dashboard) Prometheusを使用した際のMetricsの全体図 Prometheus (Collect,Store,Query) kube state metrics Control Plane Kubelet (cAdvisor) Node exporter Applications 収集対象 利用方法

promtail (Log agent) Alertmanager (Alert) Grafana Loki (Log Backend) Receiver (Slack, PagerDuty etc) Grafana (Dashboard) Grafana Lokiを使用した際のLogsの全体図 Event (Container logs) Audit (Audit logs) Kubernetes Component (Container/Journal logs) Applications (Container logs) 収集対象 利用方法

Applications OpenTelemetry Collector Jaeger (Trace Backend) Grafana Tempo (Trace Backend) Grafana (Dashboard) 収集対象 Applications Tracing Agent Library Grafana Tempoを使用した際のTracesの全体図 利用方法 ここからKubernetesのクラスタコンポーネント固有の情報がなくなってきます Grana Tempoだけだとわかりにくい人も 多いと思うので、Jaegerも併記しています

Primary Signals の利用イメージ 参考 : < https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ >

Kubernetesにおけるコンテナの操作方法 • コンテナを直接操作する – “kubectl exec”でコンテナを操作する – “kubectl debug”でエフェメラルコンテナを用意して操作する • コンテナに疎通できるようにして操作する – “kubectl port-forward”で接続する – “Service type Nodeport”等でコンテナに疎通できるようにする • ノードにsshして操作する – “kubectl get node -o wide”でノートを確認してsshする Kubernetes固有の部分はこの操作パターンを覚えること あとは今まで使って生きた技術をそのまま使っていきます