Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

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. • 吉村 翔太 • NTTコミュニケーションズ所属 • データサイエンスチーム • インフラエンジニア/データエンジニアリング •

    Kurbernetes 、Prometheus  etc • 趣味:ボードゲーム • コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介
  2. • 一晩でKubernetesを覚えて帰ろう。 ワンナイトBootCamp! -- cndjp#10 • OCHaCafe2 #1-これからはじめる! Kubernetes基礎 参考<

    https://cnd.connpass.com/event/123046/ > 参考< https://ochacafe.connpass.com/event/136115/ > 参考:Kubernetes初心者向けの資料
  3. ObservabilityとMonitoringの違い (3/3) • Monitoring – システムの状態を観測して、特定の条件に合致するものについてアラートを上げる営み – 既知の情報を元に、条件を設定してアラートを仕掛けるというニュアンスが強い • Observability

    – Monitoringの上位概念 – Monitoringだけでは分からない、潜在バグなどの未知の情報を明らかにする営み (だから、テストも含む) – 運用しているシステムには自分達がまだ理解していない状態が眠っていて それを明らかにしていく営みを継続していくことが大事みたいなメッセージ性を感じる (だから、カオスエンジニアリングみたいなのが大切なんだろう) どこかのドキュメントに書いあるわけではなく個人の感想です。
  4. 参考:Metrics,logs & Trace + ServiceMeshな場合も (1/2) • “The Open Source

    Observability Toolkit on Oracle Cloud”の動画でも 参考< https://www.youtube.com/watch?v=w2Yx7OmsX4c >
  5. 従来の監視でやってきたこと 監視項目 監視方法 アプリケーションの監視 リクエスト数、レスポンスタイム etc 対象のソフト毎の固有の情報 サービス監視 httpのリクエストの結果 ログ監視

    該当ファイルへの”error”等の文字列の有無 プロセス監視 プロセスの有無、プロセスの数 リソース監視 CPU/メモリ使用率、ディスクI/O、 ディスク容量、ネットワークトラフィック 死活監視 Pingの応答結果 ハードウェア監視 電源、ファン、温度 etc
  6. 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の例
  7. 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の状態に応じてアクションする
  8. 監視の観点は2つに別れる (1/2) • Application – 自分達がDeployしたアプリケーションの監視 • System Component –

    Kubernetesのクラスタ自体の監視 – Control Planeと呼ばれるようなクラスタを支えるコンポーネントたちの監視
  9. 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はコンテナ以外は全部
  10. Metricsの種類 参考< https://prometheus.io/docs/concepts/metric_types/> • Counter – 単調増加する数値情報 ex) エラー数 •

    Gauge – 上下する可能性のある単一の値の、その時点での数値情報 ex) CPUとかメモリの使用率 • Histogram – ある区間の平均、累積値 ex) レスポンスタイム • Summary – Histgramとだいたい一緒
  11. 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、メモリの使用率
  12. 監視の観点は2つに別れる (1/2) • Application – 自分達がDeployしたアプリケーションの監視 • System Component –

    Kubernetesのクラスタ自体の監視 – Control Planeと呼ばれるようなクラスタを支えるコンポーネントたちの監視 まずはこっちの話をします
  13. 監視したいアプリケーションの例 OS Container runtime OS Container runtime Webサーバ DBサーバ OS

    Container runtime APサーバ nginx Javaのアプリ MySQL クライアント
  14. 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 設定例
  15. 参考: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
  16. 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を用意する
  17. Exporterたちを使う (2/2) • アプリケーション固有の情報 – Apache exporter、JMX exporter、MySQL server exporter

    etc – アプリケーションに合わせて必要な情報を取得する • コンテナ毎のリソースの使用状況 – cAdvisor – コンテナ毎のCPU、メモリ等のリソースの使用状況を取得する • ブラックボックス監視 – Blackbox exporter – 外部からhttpのリクエストを送って、結果を取得する
  18. 参考:Whitebox and Blackbox Monitoring • Whitebox Monitoring – システム内部のメトリクスに基づく監視 –

    Prometheusの元となったBorgmonがそもそもWhitebox Monitoringを目指したツール – Black Box exporterを除けばPrometheusはWhitebox Monitoring • Blackbox Monitoring – ユーザから見たときのアプリケーションの振る舞いを監視 – Black Box exporterで実現する
  19. 参考:ProbeとBlackbox exporterの違い • Probe – kubeletからリクエストが発行される • Blackbox Exporter –

    Blackbox exporterの配置場所からリクエストを配置される – 配置場所に基づく通信経路も含めた監視ができる Blackbox exporter Kubelet Container runtime コンテナ probeの リクエスト Prometheus単体で使うときはよく使いますが k8sと組み合わせて使うときはそこまで使わないかな? 監視ツールから監視対象までの 通信経路の把握も大事
  20. 監視の観点は2つに別れる (1/2) • Application – 自分達がDeployしたアプリケーションの監視 • System Component –

    Kubernetesのクラスタ自体の監視 – Control Planeと呼ばれるようなクラスタを支えるコンポーネントたちの監視 次はこっちの話をします
  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はコンテナ以外は全部
  22. 監視の観点 • ノード自身のメトリクス – CPU/メモリ使用率、ディスクI/O、NW etc • System Componentのメトリクス –

    API Server 、Controller Manager、内部DNS等のメトリクス • ノード自身の不具合の検知 – コンテナランタイムの不具合など
  23. 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 >
  24. ノード自身の不具合の検知 • node-problem-detector – daemonの問題:ntp serviceのダウン – ハードウェアの問題:cpu、メモリ等の故障 – カーネルの問題:カーネルのデッドロック

    – コンテナランタイムの問題:ランタイムからの応答が返らない $ helm install stable/node-problem-detector 参考< https://github.com/kubernetes/node-problem-detector > ノード自身の異常を色々検知してくれる Helmで簡単にインストールできる
  25. 監視で集めてきた情報に対するアクションは3つ • Pages – すぐに対処する必要がある • Tickets – 数日以内に対処する必要がある •

    Logging – すぐに対処する必要はないけど、必要に応じてあとで分析した方が良いもの Alertが必要 Alertが必要
  26. Metricsに対するアラートのあげ方 • 従来:閾値監視がメイン – CPUが100%超えたら・・メモリ使用率が90%超えたら • 最近:統計学を使う – 移動平均、中央値、周期性、分位数、偏差とかを活用 –

    レスポンスタイムの95パーセントタイル値とか – ストレージの残量に対する増加の傾きとか 頑張って意味のないアラートを減らす
  27. 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 >
  28. Low No strategy (default state) - Everyone can modify -

    Duplicate used regularly - One-off dashboards - No version control - Lots of browsing Low 一回しか使わないものがある バージョン管理されてない 使わないダッシュボードがいっぱいいある
  29. 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
  30. 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
  31. 参考: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