ç Kubernetes Monitoring入門 Cloud Native Meetup Tokyo #9特別編 feat.Kaslin Fields@Oracle @yosshi_

● 吉村 翔太 ● NTTコミュニケーションズ所属 ● データサイエンスチーム ● インフラエンジニア/データエンジニアリング ● Kurbernetes 、Prometheus　 etc ● 趣味：ボードゲーム ● コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介

Kubernetesをはじめて困ること

• 最初に困ること – 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/ > 参考：Kubernetes初心者向けの資料

Cloud NativeなMonitoringとは

Cloud Nativeとは Observability(可観測性)を 持っていること 参考< https://github.com/cncf/toc/blob/master/DEFINITION.md >

Observabilityとは 参考< https://distributed-systems-observability-ebook.humio.com/ > • 「Distributed Systems Observability」によると 人によって認識が違います・・・知ってる

ObservabilityとMonitoringの違い (1/3) 参考< https://distributed-systems-observability-ebook.humio.com/ > MonitoringはObservabilityの一部 Observabilityには Testも含まれる

ObservabilityとMonitoringの違い (2/3) Monitoringの活躍の場は Release以降

ObservabilityとMonitoringの違い (3/3) • Monitoring – システムの状態を観測して、特定の条件に合致するものについてアラートを上げる営み – 既知の情報を元に、条件を設定してアラートを仕掛けるというニュアンスが強い • Observability – Monitoringの上位概念 – Monitoringだけでは分からない、潜在バグなどの未知の情報を明らかにする営み (だから、テストも含む) – 運用しているシステムには自分達がまだ理解していない状態が眠っていて それを明らかにしていく営みを継続していくことが大事みたいなメッセージ性を感じる (だから、カオスエンジニアリングみたいなのが大切なんだろう) どこかのドキュメントに書いあるわけではなく個人の感想です。

結局、Monitoringで収集する情報 参考< https://static.sched.com/hosted_files/kccnceu19/b7/Tom%20Wilkie%20and%20Frederic%20Branczyk%20-%20May%2023.pdf > 今日は主にこれ

参考：Metrics,logs & Trace + ServiceMeshな場合も (1/2) • “The Open Source Observability Toolkit on Oracle Cloud”の動画でも 参考< https://www.youtube.com/watch?v=w2Yx7OmsX4c >

参考：Metrics,logs & Trace + ServiceMeshな場合も (2/2) • “Service Mesh”って出てきますね。 参考< https://www.youtube.com/watch?v=w2Yx7OmsX4c >

Monitoringで目指すところ 参考< https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ >

Kubernetesにおける監視の難しさ

従来の監視でやってきたこと 監視項目 監視方法 アプリケーションの監視 リクエスト数、レスポンスタイム etc 対象のソフト毎の固有の情報 サービス監視 httpのリクエストの結果 ログ監視 該当ファイルへの”error”等の文字列の有無 プロセス監視 プロセスの有無、プロセスの数 リソース監視 CPU/メモリ使用率、ディスクI/O、 ディスク容量、ネットワークトラフィック 死活監視 Pingの応答結果 ハードウェア監視 電源、ファン、温度 etc

Kubernetesの難しくなったこと node Kube-proxy Pod node Kube-proxy Pod Port:31706 Port:31706 node Kube-proxy Pod Port:31706 • 特定のPodへの接続が保証されない – 従来の固定のIPアドレス:Portを指定した監視の仕組みが通用しない – Kubernetesの仕組みに合った監視の仕組みが必要 このPodにアクセスしたいと 思っても接続が保証されない NodePortの例

k8s Cluster Woker Master API Server etcd cluster Controller Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ Worker Kubelet Kube-proxy Container runtime コンテナ Kubectl Kubernetesの全体の振り返り API Server経由でetcdの操作を行い、etcdの状態に応じてアクションする

監視の観点は２つに別れる (1/2) • Application – 自分達がDeployしたアプリケーションの監視 • System Component – Kubernetesのクラスタ自体の監視 – Control Planeと呼ばれるようなクラスタを支えるコンポーネントたちの監視

k8s Cluster Woker Master API Server etcd cluster Controller Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ Worker Kubelet Kube-proxy Container runtime コンテナ Kubectl 監視の観点は２つに別れる (2/2) Applicationはこのコンテナ System Componentはコンテナ以外は全部

Metrics

Metricsの種類 参考< https://prometheus.io/docs/concepts/metric_types/> • Counter – 単調増加する数値情報 ex) エラー数 • Gauge – 上下する可能性のある単一の値の、その時点での数値情報 ex) CPUとかメモリの使用率 • Histogram – ある区間の平均、累積値 ex) レスポンスタイム • Summary – Histgramとだいたい一緒

Metricsの用途 (The Four Golden Signals) 参考< https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/ > • Latency – 遅延 ex) リクエストのレスポンスタイム • Traffic – システムに対するリクエストの量 ex) HTTPのリクエスト数、セッション数 • Errors – 失敗したリクエスト – HTTPリクエストの結果が200であっても、規定したレスポンスタイムを守れていない件数とかも このErrorsに含まれる • Saturation(飽和) – どれだけサービスが飽和しているか – ex) CPU、メモリの使用率

Metricsの収集から可視化までの流れ データ蓄積 データ収集 アラート 可視化

Prometheusとは 参考< https://prometheus.io/docs/introduction/overview/ > Googleで使用していた監視ツール「Borgmon」を参考に作られた 今回はPrometheusをベースに話します

Prometheusのアーキテクチャ 参考< https://prometheus.io/docs/introduction/overview/ > データ収集 データ蓄積 アラート 可視化 データ収集

監視の観点は２つに別れる (1/2) • Application – 自分達がDeployしたアプリケーションの監視 • System Component – Kubernetesのクラスタ自体の監視 – Control Planeと呼ばれるようなクラスタを支えるコンポーネントたちの監視 まずはこっちの話をします

監視したいアプリケーションの例 OS Container runtime OS Container runtime Webサーバ DBサーバ OS Container runtime APサーバ nginx Javaのアプリ MySQL クライアント

KubernetesのProbe機能を使う 参考< https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ > • Liveness Probe – Podが正常に動作しているか確認する – チェック結果が異常の場合はPodを再起動する – 従来でいう所のプロセス監視、死活(ping)監視に近い • Readiness Probe – Podにリクエストを流していい状態か確認する – チェック結果が異常の場合はPodにリクエストを流さない – 従来だと、LBでWebサーバでリクエストを流すか制御していたのに近い ex) プロセスは起動したけど、メモリにまだ載っていないとか ヘルスチェック方法は3つ 　exec: コマンド実行し、終了コードが”0”かどうか 　httpGet: httpリクエストを実行し、結果が200〜399かどうか 　tcpSocket: TCPコネクションが確立できるかどうか livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 20 readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 60 periodSeconds: 10 設定例

参考：ConfigMapでシェルを書く • ConfigMapでシェルを書いてProbeで実行するとより 柔軟なヘルスチェックができる readinessProbe: exec: command: - - /bin/bash - /opt/health_check.sh initialDelaySeconds: 15 periodSeconds: 20 kind: ConfigMap data: health_check.sh: | #!/bin/bash curl --silent presto-discovery:8080/v1/node | tr \",\" \"\\n\" | grep --silent $(hostname -i) Probe ConfigMap

Exporterたちを使う (1/2) OS Container runtime OS Container runtime Webサーバ DBサーバ OS Container runtime APサーバ Apache Javaのアプリ MySQL クライアント Apache exporter JMX exporter MySQL server exporter Blackbox exporter 参考< https://prometheus.io/docs/instrumenting/exporters/ > cAdvisor • 監視したい観点に合わせてExporterを用意する

Exporterたちを使う (2/2) • アプリケーション固有の情報 – Apache exporter、JMX exporter、MySQL server exporter etc – アプリケーションに合わせて必要な情報を取得する • コンテナ毎のリソースの使用状況 – cAdvisor – コンテナ毎のCPU、メモリ等のリソースの使用状況を取得する • ブラックボックス監視 – Blackbox exporter – 外部からhttpのリクエストを送って、結果を取得する

参考：Whitebox and Blackbox Monitoring • Whitebox Monitoring – システム内部のメトリクスに基づく監視 – Prometheusの元となったBorgmonがそもそもWhitebox Monitoringを目指したツール – Black Box exporterを除けばPrometheusはWhitebox Monitoring • Blackbox Monitoring – ユーザから見たときのアプリケーションの振る舞いを監視 – Black Box exporterで実現する

参考：ProbeとBlackbox exporterの違い • Probe – kubeletからリクエストが発行される • Blackbox Exporter – Blackbox exporterの配置場所からリクエストを配置される – 配置場所に基づく通信経路も含めた監視ができる Blackbox exporter Kubelet Container runtime コンテナ probeの リクエスト Prometheus単体で使うときはよく使いますが k8sと組み合わせて使うときはそこまで使わないかな？ 監視ツールから監視対象までの 通信経路の把握も大事

監視の観点は２つに別れる (1/2) • Application – 自分達がDeployしたアプリケーションの監視 • System Component – Kubernetesのクラスタ自体の監視 – Control Planeと呼ばれるようなクラスタを支えるコンポーネントたちの監視 次はこっちの話をします

k8s Cluster Woker Master API Server etcd cluster Controller Manager Scheduler etcd Kubelet Kube-proxy Container runtime コンテナ Worker Kubelet Kube-proxy Container runtime コンテナ Kubectl 監視の観点は２つに別れる (2/2) Applicationはこのコンテナ System Componentはコンテナ以外は全部

監視の観点 • ノード自身のメトリクス – CPU/メモリ使用率、ディスクI/O、NW etc • System Componentのメトリクス – API Server 、Controller Manager、内部DNS等のメトリクス • ノード自身の不具合の検知 – コンテナランタイムの不具合など

ノード自身のメトリクス • Node exporterで取得する

System Componentのメトリクス • kube-state-metrics – Kubernetesクラスタ固有のメトリクスを取得 • Kube eagleのメトリクス – Kubernetesクラスタ固有のメトリクスを取得 • Prometheus operatorの設定を模倣する – helmで簡単に入るので設定をみて勉強するのおすすめ URL< https://github.com/kubernetes/kube-state-metrics#kube-state-metrics-self-metrics > URL< https://github.com/cloudworkz/kube-eagle > URL< https://github.com/helm/charts/tree/master/stable/prometheus-operator >

参考：Kube eagle

参考：Kubernetes job monitor 参考< https://github.com/pietervogelaar/kubernetes-job-monitor >

Controller Manager Kubelet Container runtime API Server Scheduler Master 参考：System Componentもコンテナ

ノード自身の不具合の検知 • node-problem-detector – daemonの問題：ntp serviceのダウン – ハードウェアの問題：cpu、メモリ等の故障 – カーネルの問題：カーネルのデッドロック – コンテナランタイムの問題：ランタイムからの応答が返らない $ helm install stable/node-problem-detector 参考< https://github.com/kubernetes/node-problem-detector > ノード自身の異常を色々検知してくれる Helmで簡単にインストールできる

監視で集めてきた情報に対するアクションは3つ • Pages – すぐに対処する必要がある • Tickets – 数日以内に対処する必要がある • Logging – すぐに対処する必要はないけど、必要に応じてあとで分析した方が良いもの Alertが必要 Alertが必要

Alert

Metricsに対するアラートのあげ方 • 従来：閾値監視がメイン – CPUが100%超えたら・・メモリ使用率が90％超えたら • 最近：統計学を使う – 移動平均、中央値、周期性、分位数、偏差とかを活用 – レスポンスタイムの95パーセントタイル値とか – ストレージの残量に対する増加の傾きとか 頑張って意味のないアラートを減らす

可視化

Dashboardの運用の成熟度 • Grafanaの利用の仕方に成熟度があります No strategy (default state) - Everyone can modify - Duplicate used regularly - One-off dashboards - No version control - Lots of browsing Managing use of methodical dashboards - prevention of sprawl - use of template variables - methodical dashboards - hierarchical dashboards - expressive charts - version control - directed browsing Optimizing use, consistency by design - active sprawl reduction - use of scripting libraries - use of mixins - no editing in the browser - browsing is the exception Low Medium High 参考< https://static.sched.com/hosted_files/kccnceu19/27/Kubecon%202019_%20Kubernetes%20dashboards%20final.pdf >

Low No strategy (default state) - Everyone can modify - Duplicate used regularly - One-off dashboards - No version control - Lots of browsing Low 一回しか使わないものがある バージョン管理されてない 使わないダッシュボードがいっぱいいある

Medium ダッシュボードのテンプレートをjson形式でバージョン管理してる ダッシュボードがドリルダウンできる様に作ってある Medium Managing use of methodical dashboards - prevention of sprawl - use of template variables - methodical dashboards - hierarchical dashboards - expressive charts - version control - directed browsing

参考：階層化されたダッシュボード 大きな情報から順に絞り込んでいける ダッシュボードにする

High Dashboard as codeを目指す コードベースでダッシュボードを作成して管理する High Optimizing use, consistency by design - active sprawl reduction - use of scripting libraries - use of mixins - no editing in the browser - browsing is the exception

参考：コードでダッシュボードを作成する

参考：Grafana Labsで共有されているのを使う 参考< https://grafana.com/grafana/dashboards >

参考：Publicのダッシュボードを参考にする (1/2) 参考< https://weather.hiveeyes.org/grafana/d/9_Uu9Qaiz/no2-aktueller-1h-wert?orgId=1 > • Hiveeyes Projec

参考：Publicのダッシュボードを参考にする (2/2) • GItLab – https://dashboards.gitlab.com/ • Cloud Native Computing Foundation – https://devstats.cncf.io/ • CERN – http://monit-grafana-open.cern.ch/d/000000523/home?orgId=16 • Grafana – https://play.grafana.org/d/000000012/grafana-play-home?orgId=1

Logging

参考：CNDTで話したのでよろしければそちらを参考に 参考< https://speakerdeck.com/yosshi_/kubernetes-loggingru-men >

SRE Distributed Systems Observability 入門 監視 Mnaging Kubernetes 参考：書籍 英語版ならだいたい無料で配布されてる

Special Thanks!! URL< https://cnd.connpass.com/ >