Thanos マルチクラスタ監視の包括的なガイド

[[419900]]

この記事では、Prometheus 監視テクノロジースタックの制限と、Thanos ベースのテクノロジースタックに移行するとメトリックの保持が改善され、全体的なインフラストラクチャコストが削減される理由について説明します。

このデモに使用されたコンテンツは、以下のリンクから入手し、それぞれのライセンスに従って提出することができます。

https://github.com/particuleio/teks/tree/main/terragrunt/live/thanos
https://github.com/particuleio/terraform-kubernetes-addons/tree/main/modules/aws

Kubernetes Prometheus テクノロジースタック

お客様にKubernetesインフラストラクチャを導入する際、各クラスタに監視テクノロジースタックを導入するのが標準的な方法です。このスタックは通常、複数のコンポーネントで構成されます。

Prometheus: 収集メトリクス
アラートマネージャー: メトリッククエリに基づいてさまざまなプロバイダーにアラートを送信します。
Grafana: ラグジュアリーダッシュボードの可視化

簡略化されたアーキテクチャは次のとおりです。

予防

このアーキテクチャにはいくつか注意点があり、メトリックを取得するクラスターの数が増えると、スケーラビリティと拡張性はあまり良くありません。

複数のGrafana

このセットアップでは、各クラスターに独自の Grafana と独自のダッシュボードセットが存在するため、メンテナンスが面倒になります。

メトリックデータの保存にはコストがかかります。

Prometheusはメトリックデータをディスクに保存するため、ストレージ容量とメトリック保持期間のどちらかを選択する必要があります。データを長期間保存し、クラウドプロバイダーで実行する場合、ブロックストレージは非常に高価になる可能性があります。特にテラバイト単位のデータを保存する場合はその傾向が顕著です。同様に、本番環境では、Prometheusはレプリケーションやシャーディング、あるいはその両方を使用することが多く、ストレージ要件が2倍、あるいは4倍になることもあります。

解決

複数のGrafanaデータソース

Prometheusエンドポイントを外部ネットワークに公開し、単一のGrafanaインスタンスにデータソースとして追加することができます。セキュリティは、外部PrometheusエンドポイントでTLSまたはBasic認証付きのTLSを使用するだけで実現できます。このソリューションの欠点は、異なるデータソースに基づいて計算を実行できないことです。

プロメテウス連邦

Prometheus Federationは、Prometheus内からPrometheusをスクレイピングすることを可能にします。このソリューションは、大量のメトリクスをスクレイピングしない場合にはうまく機能します。しかし、大規模な場合、すべてのPrometheusターゲットのスクレイピング期間がスクレイピング間隔よりも長くなると、深刻な問題が発生する可能性があります。

プロメテウスのリモートライティング

リモート書き込みは一つの解決策（Thanosレシーバーでも実装されています）ですが、この記事では「プッシュメトリクス」のセクションについては説明しません。プッシュメトリクスの長所と短所については、こちら[1]をご覧ください。メトリクスは、複数のクラスターやテナントを信頼できない場合（Prometheusをサービスプロバイダーとして構築する場合など）の最終手段として使用することをお勧めします。いずれにせよ、これは後の記事で取り上げるトピックになるかもしれませんが、ここではスクレイピングに焦点を当てます。

サノス、来たぞ！

Thanosは「長期保存機能を備えたオープンソースで高可用性のPrometheusシステム」です。多くの有名企業がThanosを使用しており、CNCFインキュベーションプロジェクトにも参加しています。

Thanosの重要な特徴は、「無制限」のストレージ容量を利用できることです。ほぼすべてのクラウドプロバイダーがS3などのオブジェクトストレージを提供しています。既存の環境で実行する場合は、RookやMinioなどのソリューションを通じてオブジェクトストレージを提供できます。

どのように機能しますか?

サノスとプロメテウスは並んで戦い、プロメテウスから始めてサノスにアップグレードするのが一般的です。

Thanos は複数のコンポーネントに分かれており、各コンポーネントにはターゲットがあり (すべてのサービスでそうなるはずです :))、コンポーネントは gRPC を介して相互に通信します。

サノスサイドカー

ThanosはPrometheusと並行して（サイドカーを介して）動作し、2時間ごとにPrometheusのメトリクスをオブジェクトリポジトリに出力します。これにより、Prometheusは実質的にステートレスになります。Prometheusは2時間分のメトリクスをメモリに保持しているため、クラッシュが発生した場合、2時間分のメトリクスが失われる可能性があります（この問題は、Thanosではなく、HA/シャーディングを使用したPrometheusのセットアップで対処する必要があります）。

Thanosサイドカーは、PrometheusオペレーターとKube Prometheusスタックとともに簡単にデプロイできます。このコンポーネントは、Thanosクエリのストアとして機能します。

サノスストレージ

Thanosストレージはゲートウェイとして機能し、クエリをリモートオブジェクトストレージに変換します。また、一部の情報をローカルストレージにキャッシュすることもできます。基本的に、このコンポーネントはオブジェクトストレージに対してメトリクスのクエリを実行できます。このコンポーネントは、Thanosクエリのストレージとして機能します。

サノス・コンパクター

Thanos Compactorはシングルトン（スケーラブルではありません）で、オブジェクトストレージに保存されているメトリクスの圧縮とダウンサンプリングを行います。ダウンサンプリングとは、時間の経過とともにメトリクスの粒度を緩めることです。例えば、メトリクスを2～3年保持したいものの、昨日のメトリクスほど多くのデータポイントは必要ない場合などです。そこでコンプレッサーが登場します。コンプレッサーはオブジェクトストレージのバイト数を節約し、コストを削減します。

サノスクエリ

ThanosクエリはThanosの主要コンポーネントであり、PromQLクエリの送信先として機能します。ThanosクエリはPrometheus互換のエンドポイントを公開します。そして、クエリをすべての「ストア」にディスパッチします。ストアは、メトリクスを提供する他のThanosコンポーネントであれば何でも構いません。Thanosクエリは他のThanosクエリにクエリを送信できます（クエリはスタック可能です）。

サノスストア
サノスサイドカー
サノスクエリ

また、異なるストアまたはPrometheusインスタンスからの同一メトリクスの重複排除も処理します。例えば、Prometheusとオブジェクトストレージの両方にメトリクスがある場合、Thanos Queryはそのメトリクス値を重複排除できます。Prometheus HA構成では、重複排除はPrometheusのレプリカとシャードに基づいて行われます。

Thanos クエリフロントエンド

名前が示すように、Thanos クエリフロントエンドは Thanos クエリのフロントエンドであり、その目的は、大きなクエリを複数の小さなクエリに分割し、クエリ結果をキャッシュ (メモリまたは memcached に) することです。

リモート書き込みの場合にサノスを受信するなど、他のコンポーネントもありますが、それはまだこの記事の主題ではありません。

マルチクラスタアーキテクチャ

これらのコンポーネントを複数のKubernetesクラスターにデプロイする方法は複数あります。ユースケースによっては、どの方法がより適しているかが異なりますが、ここでは詳細な説明はできません。

この例はAWS上で実行され、tEKS[2]を使用して2つのクラスターをデプロイします。当社のオールインワンソリューションは、AWS上に本番環境対応のEKSクラスターをデプロイします。

オブザーバークラスター[3]
観測されたクラスター[4]

私たちのデプロイメントでは、公式の kube-prometheus-stack と bitnami thanos ダイアグラムを使用します。

すべては terraform-kubernetes-addons リポジトリ内で計画されました。

Thanos デモフォルダーのディレクトリ構造は次のとおりです。

 ├──  env_tags.yaml  
 ├──  eu-west-1  
 │ ├──  クラスター 
 │ │ └──  オブザーバー 
 │ │ ├──  eks  
 │ │ │ ├──  kubeconfig  
 │ │ │ └──  terragrunt.hcl  
 │ │ §──  eks-addons  
 │ │ │ └──  terragrunt.hcl  
 │ │ └──  vpc  
 │ │ └──  terragrunt.hcl  
 │ └──  region_values.yaml  
 └──  eu-west-3  
 ├──  クラスター 
 │ └──  観察者 
 │ ├──  cluster_values.yaml  
 │ ├──  eks  
 │ │ ├──  kubeconfig  
 │ │ └──  terragrunt.hcl  
   │ §──  eks-addons  
 │ │ └──  terragrunt.hcl  
 │ └──  vpc  
 │ └──  terragrunt.hcl  
 └──  region_values.yaml

これにより、DRY (Don't Repeat Yourself) インフラストラクチャが可能になり、AWS アカウント、リージョン、クラスターの数を簡単に拡張できるようになります。

オブザーバークラスター

オブザーバークラスターはメインクラスターであり、そこから他のクラスターをクエリします。

Prometheus が実行中です:

Grafana 対応
Thanosサイドカーは特定のバケットにアップロードします

kube-prometheus-スタック= {  
有効= true    
 allowed_cidrs =依存関係.vpc.outputs.private_subnets_cidr_blocks  
 thanos_sidecar_enabled = true    
 thanos_bucket_force_destroy = true    
 extra_values = < < -EXTRA_VALUES    
グラファナ:  
展開戦略:  
タイプ: 再作成 
入口:  
有効: true  
注釈:  
 kubernetes.io/ingress.class: nginx  
          cert-manager.io/cluster-issuer: "letsencrypt"  
ホスト:  
          - grafana.${local.default_domain_suffix}  
 TLS:  
 - シークレット名: grafana.${local.default_domain_suffix}  
ホスト: 
               - grafana.${local.default_domain_suffix}  
持続性:  
有効: true  
ストレージクラス名: ebs-sc  
アクセスモード:  
 - 一度だけ読み書き可能 
サイズ: 1Gi  
プロメテウス：  
プロメテウス仕様:  
レプリカ: 1  
保持: 2日 
保持サイズ: "10GB"  
ルールセレクタNilUsesHelmValues: false  
サービスモニターセレクタNilUsesHelmValues: false  
 podMonitorSelectorNilUsesHelmValues: false  
ストレージ仕様:  
ボリュームクレームテンプレート:  
仕様:  
ストレージクラス名: ebs-sc  
アクセスモード: ["ReadWriteOnce"]  
リソース：  
リクエスト:  
ストレージ: 10Gi  
追加値

オブザーバークラスターの CA 証明書を生成します。

この CA は、サイドカーに入る監視対象クラスターによって信頼されます。
監視対象クラスターをクエリする Thanos クエリコンポーネントの TLS 証明書を生成します。

Thanos コンポーネントの展開:

すべての Thanos コンポーネントが展開されました。
クエリフロントエンドは、Grafana のデータソースエンドポイントとして機能します。
ストレージゲートウェイは、オブザーバーバケットをクエリするために使用されます。
クエリは、ストレージゲートウェイおよびその他のクエリ実行者に対してクエリを実行します。

追加の Thanos コンポーネントが展開されました:

TLS で構成された Thanos クエリーは、監視対象の各クラスターをクエリします。

 thanos-tls-querier = {  
 「観察対象」 = {  
有効= true    
 default_global_requests = true    
 default_global_limits = false    
店舗= [  
 "thanos-sidecar.${local.default_domain_suffix}:443"  
 ]  
 }  
 }  
サノスストアゲートウェイ= {  
 「観察対象」 = {  
有効= true    
 default_global_requests = true    
 default_global_limits = false  
バケット= "thanos-store-pio-thanos-observee"    
リージョン= "eu-west-3"    
 }

観測されたクラスター

観察対象のクラスターは、最小限の Prometheus/Thanos がインストールされた Kubernetes クラスターであり、観察対象のクラスターに対してクエリが実行されます。

Prometheus オペレーターが実行中です:

Thanos 側では、特定のバケットをオブザーバーにアップロードします。
Thanos サイドカーは、TLS クライアント認証と信頼できるオブザーバークラスター CA のエントリオブジェクトとともに公開されます。

 kube-prometheus-スタック= {  
有効= true    
 allowed_cidrs =依存関係.vpc.outputs.private_subnets_cidr_blocks  
 thanos_sidecar_enabled = true    
 thanos_bucket_force_destroy = true    
 extra_values = < < -EXTRA_VALUES    
グラファナ:  
有効: false  
プロメテウス：  
サノスイングレス:  
有効: true  
イングレスクラス名: nginx  
注釈:  
          cert-manager.io/cluster-issuer: "letsencrypt"  
 nginx.ingress.kubernetes.io/ssl-redirect: "true"  
 nginx.ingress.kubernetes.io/バックエンドプロトコル: "GRPC"  
 nginx.ingress.kubernetes.io/auth-tls-verify-client: 「オン」  
 nginx.ingress.kubernetes.io/auth-tls-secret: "monitoring/thanos-ca"  
ホスト:  
 - thanos-sidecar.${local.default_domain_suffix}  
パス:  
 - /  
 TLS:  
 - シークレット名: thanos-sidecar.${local.default_domain_suffix}  
ホスト:  
 - thanos-sidecar.${local.default_domain_suffix}  
プロメテウス仕様:  
レプリカ: 1  
保持: 2日 
保持サイズ: "6GB"  
ルールセレクタNilUsesHelmValues: false  
サービスモニターセレクタNilUsesHelmValues: false  
 podMonitorSelectorNilUsesHelmValues: false  
ストレージ仕様:  
ボリュームクレームテンプレート:  
仕様:  
ストレージクラス名: ebs-sc  
アクセスモード: ["ReadWriteOnce"]  
リソース：  
リクエスト:  
ストレージ: 10Gi  
追加値

Thanos コンポーネントの展開:

Thanos コンプレッサーは、この特定のクラスターのダウンサンプリングを管理するために使用されます。

サノス= {  
有効= true    
バケット強制破棄= true    
 trusted_ca_content =依存関係.thanos-ca.outputs.thanos_ca  
 extra_values = < < -EXTRA_VALUES    
圧縮機:  
保持期間解像度5か月: 90日 
クエリ:  
有効: false  
クエリフロントエンド:  
有効: false  
ストアゲートウェイ:  
有効: false  
追加値 
 }

さらに深く

クラスターで何が実行されているか確認してみましょう。オブザーバーに関しては、以下のものがあります。

 kubectl -n モニタリング ポッドを取得する 
名前 準備完了 ステータス 再起動 年齢 
 alertmanager-kube-prometheus-stack-alertmanager-0 2/2 実行中 0 120 分 
 kube-prometheus-stack-grafana-c8768466b-rd8wm 2/2 実行中 0 120分 
 kube-prometheus-stack-kube-state-metrics-5cf575d8f8-x59rd 1/1 実行中 0 120分 
 kube-prometheus-stack-operator-6856b9bb58-hdrb2 1/1 実行中 0 119分 
 kube-prometheus-stack-prometheus-node-exporter-8hvmv 1/1 実行中 0 117分 
 kube-prometheus-stack-prometheus-node-exporter-cwlfd 1/1 実行中 0 120 分 
 kube-prometheus-stack-prometheus-node-exporter-rsss5 1/1 実行中 0 120分 
 kube-prometheus-stack-prometheus-node-exporter-rzgr9 1/1 実行中 0 120分 
 prometheus-kube-prometheus-stack-prometheus-0 3/3 実行中 1 120 分 
 thanos-compactor-74784bd59d-vmvps 1/1 実行中 0 119m  
 thanos-query-7c74db546c-d7bp8 1/1 実行中 0 12分 
 thanos-query-7c74db546c-ndnx2 1/1 実行中 0 12分 
 thanos-query-frontend-5cbcb65b57-5sx8z 1/1 実行中 0 119分 
 thanos-query-frontend-5cbcb65b57-qjhxg 1/1 実行中 0 119分 
 thanos-storegateway-0 1/1 実行中 0 119分 
 thanos-storegateway-1 1/1 実行中 0 118分 
 thanos-storegateway-observee-storegateway-0 1/1 実行中 0 12 メートル 
 thanos-storegateway-observee-storegateway-1 1/1 実行中 0 11 メートル 
 thanos-tls-querier-observee-query-dfb9f79f9-4str8 1/1 実行中 0 29分 
 thanos-tls-querier-observee-query-dfb9f79f9-xsq24 1/1 実行中 0 29分 
 kubectl -n モニタリング イングレスを取得 
名前 クラス ホスト アドレス ポート 年齢
kube-prometheus-stack-grafana <なし> grafana.thanos.teks-tg.clusterfrak-dynamics.io k8s-ingressn-ingressn-afa0a48374-f507283b6cd101c5.elb.eu-west-1.amazonaws.com 80, 443 123m

観察:

 kubectl -n モニタリング ポッドを取得する 
名前 準備完了 ステータス 再起動 年齢 
 alertmanager-kube-prometheus-stack-alertmanager-0 2/2 実行中 0 39 分 
 kube-prometheus-stack-kube-state-metrics-5cf575d8f8-ct292 1/1 実行中 0 39分 
 kube-prometheus-stack-operator-6856b9bb58-4cngc 1/1 実行中 0 39分 
 kube-prometheus-stack-prometheus-node-exporter-bs4wp 1/1 実行中 0 39 分 
 kube-prometheus-stack-prometheus-node-exporter-c57ss 1/1 実行中 0 39 分 
 kube-prometheus-stack-prometheus-node-exporter-cp5ch 1/1 実行中 0 39 分 
 kube-prometheus-stack-prometheus-node-exporter-tnqvq 1/1 実行中 0 39 分 
 kube-prometheus-stack-prometheus-node-exporter-z2p49 1/1 実行中 0 39分 
 kube-prometheus-stack-prometheus-node-exporter-zzqp7 1/1 実行中 0 39分 
 prometheus-kube-prometheus-stack-prometheus-0 3/3 実行中 1 39 分 
 thanos-compactor-7576dcbcfc-6pd4v 1/1 実行中 0 38分 
 kubectl -n モニタリング イングレスを取得 
名前 クラス ホスト アドレス ポート 年齢
kube-prometheus-stack-thanos-gateway nginx thanos-sidecar.thanos.teks-tg.clusterfrak-dynamics.io k8s-ingressn-ingressn-95903f6102-d2ce9013ac068b9e.elb.eu-west-3.amazonaws.com 80, 443 40分

TLSクエリは、監視対象クラスタのメトリクスをクエリできるはずです。その動作を見てみましょう。

 k -n 監視ログ -f thanos-tls-querier-observee-query-687dd88ff5-nzpdh  
レベル=情報  ts = 2021 -02-23T15:37:35.692346206Z呼び出し元= storeset .go:387コンポーネント= storeset   msg = "ストアセットを照会するための新しいストアAPIを追加しています"  アドレス= thanos -sidecar.thanos.teks-tg.clusterfrak-dynamics.io:443 extLset ="{cluster=\" pio -thanos-observee\", prometheus =\"monitoring/kube-prometheus-stack-prometheus\", prometheus_replica =\"prometheus-kube-prometheus-stack-prometheus-0\"}"

したがって、このクエリポッドは他のクラスターをクエリすることができ、Web をチェックするとストレージを確認できます。

 kubectl -n モニタリング ポート転送 thanos-tls-querier-observee-query-687dd88ff5-nzpdh 10902

それは素晴らしいですね。でも、ストレージは1つしかありません。クエリーはスタックできると言ったのを覚えていますか？オブザーバークラスターには、アーキテクチャグラフ内の他のコンポーネントにクエリを実行できる標準的なHTTPクエリーがあります。

 kubectl -n モニタリング ポート転送 thanos-query-7c74db546c-d7bp8 10902

ここで、すべてのストレージが中央クエリーに追加されたことがわかります。

オブザーバーは地元のサノスを集めます。
ストレージゲートウェイ（リモートオブザーバークラスター用とローカルオブザーバークラスター用に1つずつ）
観測されたサイドカーを照会できるローカルTLSクエリ

Grafanaでの可視化

最後に、Grafana に移動して、デフォルトの Kubernetes ダッシュボードが複数のクラスターとどのように互換性があるかを確認します。

要約

Thanos は多くの可動部分を持つ非常に複雑なシステムであり、時間がかかりすぎるため、特定のカスタム構成については詳しく検討しませんでした。

tEKSリポジトリでは、非常に包括的なAWS実装を提供しており、複雑さの大部分（主にmTLS部分）を抽象化し、幅広いカスタマイズを可能にします。terraform-kubernetes-addonsモジュールをスタンドアロンコンポーネントとして使用することも可能です。将来的には他のクラウドプロバイダーにも対応する予定です。ご質問等ございましたら、GitHub上のプロジェクトからお気軽にお問い合わせください。

インフラストラクチャとニーズに応じて、ニーズに適した Thanos 実装が多数あります。

Thanosについてさらに詳しく知りたい場合は、公式のkube-thanosリポジトリとクラスター間通信に関するアドバイスを確認してください[5]。

もちろん、クラウドネイティブな監視スタックの構築をお手伝いさせていただきます。お気軽に[email protected]までお問い合わせください。

CNCF/Kubernetes Slack チャネルを通じて毎日ご連絡いただくこともできます。

DUICUO