Kuberntes_Monitoring_入門.pdf

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. 監視の観点は２つに別れる (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)
    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. 監視の観点は２つに別れる (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. 監視の観点は２つに別れる (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)
    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