この記事はKubernetes Advent Calendar 2016の20日目の記事です。

Kubernetesを安定的に運用する上で、どのように監視を行うかということを考える必要があると思います。

しかし、Kubernetesにデフォルトで使用されているcAdvisor, Heapsterやaddonとして提供されているkube-state-metricsの他、DataDogなど選択肢も様々で、その中からどれを選べば良いのか難しい状況です。

今回は、それらの監視ツールの中からKubernetesにデフォルトで使用されているcAdvisor, Heapsterと、addonとして提供されているkube-state-metricsについて調べてみました。

cAdvisor

cAdvisorはGoogle社が開発しているオープンソースのコンテナの監視ツールです。 Kubernetesの各ホスト上で１つづつ起動しており、デフォルトで１秒毎に同じホストにあるコンテナのメトリクス情報を収集してくれます。

f:id:i03yari2:20161220173424p:plain

cAdvisorの概要図

cAdvisorで取得できるメトリクスとしては

CPU
Memory
Network
FileSystem

などがあり、メモリ上に（デフォルトで）60秒分のメトリクスを保持し、APIとして提供してくれます。

また、cAdvisorはGUIも持っているため60秒分のメトリクスであれば簡単に確認することができます。

f:id:i03yari2:20161220110401p:plain

cAdvisorのダッシュボード

Heapster

alt

[5]より引用

Heapsterは、クラスタ単位のメトリクスの監視ツールであり、ホストを自動的に監視に追加しkubeletを通してcAdvisorからメトリクス情報を収集します。メトリクス情報は、ラベルでPodをまとめてしエクスポートされます。また、Kubernetes 1.2以降であれば、コンテナ内のアプリケーションからカスタムメトリクスを取得することができます。

Heapsterを使うには、メトリクスのフォワード先のストレージバックエンドが必要になります。ストレージバックエンドにはInfluxDBが使われることが多いようです。

今回はInfluxDBとGrafanaを使ってメトリクスを可視化してみました。（本当はこちらのガイドからKubernetes上のクラスタを監視したかったのですが、うまく動作せず今回はこちらを参考にコンテナを直に立ち上げて確認しています）

はじめに監視対象のホストでcAdvisorを起動しておきます。

$ docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --publish=8080:8080 --detach=true --name=cadvisor google/cadvisor:latest

次にInfluxDBとGrafanaを起動します。Heapsterが、格納先のInfluxDBへリンクするため先に起動する必要があります。

$ docker run -d -p 8083:8083 -p 8086:8086 --name influxdb kubernetes/heapster_influxdb
$ docker run -d -p 80:8080 -e INFLUXDB_HOST=<influxdb_host_ip> kubernetes/heapster_grafana:v0.7

次にHeapsterですが、監視対象のホスト設定を書いたJSONファイルをコンテナにマウントする必要があります。実際にはHeapsterとKubernetesが連携し自動でホストを監視対象に追加する形になります。今回は監視対象のホストを２つ用意し、それぞれcAdvisorを動かしています。

$ vim /export/heapster/hosts
{
  "items": [
    {
      "ip": "192.168.33.10",
      "name": "host1"
    },
    {
      "ip": "192.168.33.20",
      "name": "host2"
    }
  ]
}
$ docker run --name heapster --link influxdb:influxdb -v /export/heapster/hosts:/var/run/heapster/hosts -d kubernetes/heapster:v0.14.2 --sink="influxdb:http://influxdb:8086" --source="cadvisor:external?cadvisorPort=8080"

以上でGrafanaからメトリクスの確認ができるようになります。

f:id:i03yari2:20161220115846p:plain

Heapsterのメトリクス

左側がCPU使用量、右側がメモリ使用量、上段がコンテナ単位のメトリクス、下段がホスト単位のメトリクスのグラフです。上段のグラフでは、動作しているホストに関係なくすべてのコンテナのメトリクスが表示されています。複数のホスト上のcAdvisorがコンテナ単位で収集したメトリクスがHeapsterを通してInfluxDBにエクスポートされていることが確認できます。

kube-state-metrics

Heapsterが、CPU・メモリ・ネットワークといったリソース単位でメトリクスを管理しているのに対し、kube-stae-metricsはPod, Deployment, DeamonSetといったKubernetesで抽象化された単位でメトリクスを管理します。

また、kube-state-metricsは、デフォルトでKubernetesに組み込まれていないためkube-state-metricsコンテナを自分でデプロイする必要があります。

@helix_kazさんの記事を参考に構築してみました。

構築に成功するとhttp://<node_ip>:30090/graphでPrometheusにアクセスすることができます。

今回はメトリクスとしてkubelet_running_pod_countを表示し、nginxのPodを手動で起動と削除を繰り返してみました。

f:id:i03yari2:20161220171353p:plain

kube-state-metricsのメトリクス

グラフからPod数が変動していることが分かると思います。

このようにkube-state-metricsを使えば、Kubernetesの抽象化単位をメトリクスとしてみることができます。

Heapsterとkube-state-metricsの比較

ストレージとの連携

Heapsterは、cAdvisorのメトリクスを取得しInfluxDBなどのバックエンドストレージにフォワードします。一方、kube-state-metricsは、メトリクスをメモリに保持しますがフォワードに責任を持ちません。そのため、kube-state-metricsの場合は、Prometheusなどのpull型の監視ツールと連携する必要があります。

メトリクスの違い

Kubernetesは、状況に応じてオートスケーリングしてくれるため、ホスト単位よりもラベル単位での管理が必要になってくると思います。監視という点でも、Kubernetesで抽象化されている単位で管理できる方がわかりやすく、問題の原因が特定しやすくなるのではないかと思います。その点、kube-state-metricsは、メトリクスの形式がPodやDeploymentといったKubernetesの抽象化単位でメトリクスが見れるため、利点があると感じました。

まとめ

Kubernetesのモニタリングについては、こちらの記事がよくまとまっていると思います。一部を要約すると、「Kubernetesを使う上ではどこでアプリケーションが動いているかを正確に知ることができないので、これまでの監視の考え方を再考する必要があるよ。タグとラベルで管理しトラッキングすることが重要になるよ。」ということを言っています。　今回の調査でkube-state-metricsがこの考え方に近く、実際にKubernetesを扱う上で直感的にメトリクスを見れると感じました。今後も監視系ツールは開発が進んでいくと思いますが、kube-state-metricsに注目しつつ見守っていきたいと思います。