Kubernetesの利点の一つとしてOSSのコミュニティで開発された独自のシステム系コンポーネントを導入することで、自分たちのニーズに合わせた運用性の向上が望めるという点があります。
転職会議でもALB Ingress ControllerやSealedSecrets等のシステム系コンポーネントを導入しています。
このようなコンポーネントは多くの場合ドキュメントに従って手を動かすだけで(場合によってはYAMLをクラスタに適用するだけで)導入が完了するほど容易に導入できるのですが、ここで見落としがちなのが導入後の運用です。運用を滞りなくおこなうためには導入されたコンポーネントは当然監視されている必要があります。
転職会議ではDatadogのAutodiscovery機能を使用してPrometheusのエンドポイントからDatadogにメトリクスを取得して監視を行っているのでその設定例等を紹介します。
何を監視したいか
転職会議ではEKS上に以下のようなコンポーネントを導入しています。
このとき例えば以下のような問題が起きたらすぐにSlack等に通知させたいです。
- YAMLが誤っているのでFluxがGitHubリポジトリのYAMLをクラスタに反映できない
- Ingressの設定内容が誤っているためALB Ingress ControllerがALBを作成・設定変更できない
- SealedSecrets ControllerがSealedSecretsを復号できない
転職会議ではSREだけではなくアプリケーションエンジニアも自分が担当するサービスのKubernetesのYAMLを日々編集しています。そのためSREとしては、上のような問題が起きた場合には本番だけでなくステージングや開発環境でもなるべく早く開発者に知らせてあげることで、安心してKubernetesのYAMLを修正しやすい環境を作りたいと考えています。
そのため、独自システムコンポーネントの監視によって問題発生時にはすぐに通知されることは重要です。
どうやって監視するか
実は多くの場合独自のシステム系コンポーネントにはPrometheusのエンドポイントが生えているため、Prometheus形式のメトリクスに対応したツールを使うことでこれらのメトリクスを監視に用いることができます。
例えばALB Ingress Controllerであれば 10254
番ポートの /metrics
というパスにアクセスすることで以下のようなPrometheus形式のメトリクスが返ってきます。
...略.... aws_alb_ingress_controller_aws_api_errors{operation="DescribeListenerCertificates",service="elasticloadbalancing"} 2 aws_alb_ingress_controller_aws_api_errors{operation="DescribeLoadBalancers",service="elasticloadbalancing"} 9 aws_alb_ingress_controller_aws_api_errors{operation="DescribeTargetGroups",service="elasticloadbalancing"} 15 aws_alb_ingress_controller_aws_api_errors{operation="GetToken",service="ec2metadata"} 1 aws_alb_ingress_controller_aws_api_errors{operation="ModifyRule",service="elasticloadbalancing"} 38 aws_alb_ingress_controller_aws_api_errors{operation="RegisterTargets",service="elasticloadbalancing"} 7 ...略....
このようなPrometheusのエンドポイントから取得したアプリケーションの動作を表すメトリクスを用いて問題発生時にアラートを飛ばすことができます。監視ツールとしてPrometheusを使用している場合はAlertmanager等を使ってアラートを飛ばすことができます。
転職会議では監視にDatadogを使用しているため一旦Datadogにメトリクスを集めて、Datadogからアラートを飛ばすようにしています。
その際に使用しているのがDatadogのAutodiscovery機能です。監視対象のPodに以下のようにアノテーションを設定するだけで、Datadog AgentがPodのアノテーションを解釈し自動的にメトリクスをDatadogに送るようになります。
# 以下はCluster AutoScalerでの設定例 # Podのアノテーション annotations: # datadogでPrometheusエンドポイントからメトリクスを取得する # ad.datadoghq.com/<コンテナ名>から始まるアノテーションを設定 # コンテナ名はPodのcontainers[].nameで指定している名前 ad.datadoghq.com/cluster-autoscaler.check_names: '["openmetrics"]' ad.datadoghq.com/cluster-autoscaler.init_configs: '[{}]' ad.datadoghq.com/cluster-autoscaler.instances: '[ { # Prometheusエンドポイント # "prometheus_url": "http://%%host%%:<ポート番号>/metrics", "prometheus_url": "http://%%host%%:8085/metrics", # Datadogのメトリクスのnamespace。 # これによりDatadog上でのメトリクスが"<ここで設定したnamespace名>.<メトリクス名>"というような名前になる "namespace": "prometheus", # 取得するメトリクス名のフィルタ # "metrics": ["<metrics名のフィルタ>"] # Goのランタイムのメトリクス等も取りたいなら以下 # "metrics": ["*"] "metrics": ["cluster_autoscaler_*"] } ]'
あとはDatadogの機能で普通にアラートを設定するだけです。Slackに通知すると以下のような感じです。
まとめ
運用を楽にするような独自コンポーネントを導入しやすいのはKubernetesの大きな利点です。この大きな利点を最大限に利用するためにも、新しいコンポーネントを入れる際には監視やアップデートを含めたプロダクトのライフサイクルで起こりそうな問題を考えておくようにしましょう。