Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kuberntes_Monitoring_入門.pdf

yosshi_
August 07, 2019

 Kuberntes_Monitoring_入門.pdf

yosshi_

August 07, 2019
Tweet

More Decks by yosshi_

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. Kubernetesをはじめて困ること

    View Slide

  4. • 最初に困ること
    – DeploymentとServiceを使ってコンテナにアクセスする・・よく分からない
    – ConfigMapを使って、パラメータを設定する・・・ギリギリわかる
    – PVCとPVを使ってディスクをマウントする・・・全く分からない
    • 次に困ること
    – CI/CDのパイプラインを作る
    – Kubernetesの監視基盤を作る
    今日はこの監視の話
    K8sを触り始めた時の自分の感想
    Kubernetesをはじめて困ること

    View Slide

  5. • 一晩でKubernetesを覚えて帰ろう。
    ワンナイトBootCamp! -- cndjp#10
    • OCHaCafe2 #1-これからはじめる!
    Kubernetes基礎
    参考< https://cnd.connpass.com/event/123046/ > 参考< https://ochacafe.connpass.com/event/136115/ >
    参考:Kubernetes初心者向けの資料

    View Slide

  6. Cloud NativeなMonitoringとは

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. Kubernetesにおける監視の難しさ

    View Slide

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

    View Slide

  18. 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の例

    View Slide

  19. 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の状態に応じてアクションする

    View Slide

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

    View Slide

  21. 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/2)
    Applicationはこのコンテナ
    System Componentはコンテナ以外は全部

    View Slide

  22. Metrics

    View Slide

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

    View Slide

  24. 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、メモリの使用率

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  30. 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
    設定例

    View Slide

  31. 参考: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

    View Slide

  32. 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を用意する

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  37. 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/2)
    Applicationはこのコンテナ
    System Componentはコンテナ以外は全部

    View Slide

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

    View Slide

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

    View Slide

  40. 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 >

    View Slide

  41. 参考:Kube eagle

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  46. Alert

    View Slide

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

    View Slide

  48. 可視化

    View Slide

  49. 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 >

    View Slide

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

    View Slide

  51. 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

    View Slide

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

    View Slide

  53. 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  57. 参考: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

    View Slide

  58. Logging

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide