Kubernetes勉強会第4回 〜cAdvisor、Heapster、podとnodeのauto scaling、taintsとtolerations〜

Kubernetes

Kubernetes in Action

Kubernetes in Action

「Kubernetes in Action」を読んで学んだ結果を社内で共有しました。 その第4回の内容です。

cAdvisor

kubeletには内部にcAdvisorというものを持っている。 cAdvisorはnode自体のリソース使用量及びnode上で実行されているコンテナのリソース消費量のデータを収集する役割を担っている。 それらのデータをクラスタ全体で集約するためのHeapsterとよばれるコンポーネントがある。 Heapsterは全nodeのうち1つのnode上でpodとして動作する。 Heapsterはserviceを通して公開される。

minikubeの場合は以下のコマンドでheapsterを有効にできる。 minikube addons enable heapster

heapsterが実行されていれば、 kubectl top node でその集約データ結果からnodeのリソース使用量がみれる。 (minikube addons enable heapsterを実行した直後であれば少し待つ必要がある)

$ kubectl top node
NAME       CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%
minikube   170m         8%        556Mi           27%

# またpodごとのリソース消費量もみれる
$ kubectl top pod
NAME           CPU(cores)    MEMORY(bytes)
requests-pod   21m           19Mi

$ kubectl top pod --all-namespaces
NAMESPACE     NAME                                    CPU(cores)   MEMORY(bytes)
default       requests-pod-2                          21m          19Mi
kube-system   kube-scheduler-minikube                 11m          13Mi
kube-system   kube-controller-manager-minikube        40m          34Mi
kube-system   heapster-bmk4j                          0m           16Mi
kube-system   kubernetes-dashboard-5498ccf677-5gjhz   0m           14Mi
kube-system   kube-addon-manager-minikube             10m          19Mi
kube-system   kube-apiserver-minikube                 33m          232Mi
kube-system   etcd-minikube                           18m          32Mi
kube-system   kube-dns-86f4d74b45-hkn2d               1m           25Mi
kube-system   kube-proxy-xnfjc                        2m           15Mi
kube-system   influxdb-grafana-tnbzw                  1m           24Mi
kube-system   storage-provisioner                     0m           33Mi

グラフィカルにリソースをモニタリングしたい場合、GKEならGoogle Cloud Monitoringが使える。 minikubeやオンプレの場合は、データの保存にInfluxDB, ビジュアリングにGrafanaが使える。

Heapster, InfluxDB, Grafanaを試したい方は以下をご参考下さい。 KubernetesをHeapster + InfluxDB + Grafanaでモニタリングする

podのリソースを管理するためのまとめ

  • Resource Requestsを指定することはpodをscheduleするときに役に立つ
  • Resource Limitsを指定することはpodが他のpodのリソースを使い過ぎることを防ぐ
  • 使われていないCPU時間はコンテナのRequestsに基づいて割り当てられる
  • コンテナはCPUを使い過ぎても決してkillされないが、メモリを使い過ぎようとしたらkillされる
  • QoSと実際のメモリ使用量に基づいて、より重要なpodのために他のpodが消されることもある
  • LimitRangeリソースを定義することによって、それぞれのpodに対して、Resource RequestsとResource Limitsの最小値,最大値, デフォルト値を設定することができる
  • ResourceQuotaリソースを定義することによって、namespace内のpodのResource Requests, Resource Limitsの総量に対して最小, 最大を設定することができる
  • podに適切なResource Requests, Resource Limitsを指定するためには、長い間モニタリングをする必要がある

podとnodeのauto scaling

Kubernetesのauto scalingについて

taintsとtolerations

Kubernetesのtaintsとtolerationsについて