KubernetesではRBACという、各種リソースへのアクセス権限を管理する仕組みが用意されてます。
たとえばPrometheusのようにKubernetesのAPIを叩く場合、各リソースへアクセスするための権限が必要になります。
今回はそれの基本的な仕組みや設定方法を説明します。
KubernetesにはUserAccountとServiceAccountがあります。大きな違いとしては以下です。
| UserAccount | ServiceAccount | |
|---|---|---|
| 対象 | 人 | プロセス |
| 権限範囲 | グローバル。 GCPのアカウントや AWSのIAMとリンクする。 |
namespace区切り。 Kubernetesの世界で完結する。 |
ref: Managing Service Accounts - Kubernetes
Pod起動時には必ずServiceAccountを１つ割り当てる必要があります。
指定しない場合はdefault ServiceAccountが割り当てられます。
PrometheusはPull型の監視ツールであるため、監視対象がどれかを教えてあげなければいけません。
これまでの記事は全てstatic_configsを用いた静的な値で、スケールした時やサービスが増減した時に柔軟性がありません。
PrometheusはServiceDiscoveryを指定することで動的にターゲットを検知できるのでそれを用います。
Configuration | Prometheus に対応しているSD一覧があります。
主に使いそうなのは以下でしょうか。
前回は既存のexporterを利用せず、自分でメトリクスを生成する方法を説明しました。
その方法を使って実際にAPIサーバ(HTTP)のメトリクスを生成し、可視化してみます。
分散システムで何をモニタリングすべきかについては、The Four Golden Signalsが有名です。
それを踏まえてマイクロサービスではREDメソッドという指標があります。
| 項目 | 説明 |
|---|---|
| Rate | リクエスト数/sec |
| Errors | エラー数 |
| Duration | リクエスト毎のduration |
今回はこのREDメソッドに基づいて可視化できるようにします。
続きを読むMetric types | Prometheus で定義されているようにPrometheusでは大きく４つのメトリクスタイプがあります。
今回はGoのPrometheusクライアントライブラリを用いて各メトリクスを独自で用意する方法を説明します。
まずはPrometheusが監視対象のメトリクスをPullできるよう/metricsのエンドポイントを用意します。
公式クライアントとしてpromhttpというライブラリが提供されているのでそれを使います。
package main import ( "log" "net/http" "github.com/prometheus/client_golang/prometheus/promhttp" ) func main() { http.Handle("/metrics", promhttp.Handler()) log.Fatal(http.ListenAndServe(":8080", nil)) }続きを読む
