より洗練されたKubernetesクラスタイベント測定ソリューション

[[442821]]

みなさんこんにちは。私は張錦濤です。

グループ内の友人が、ローリングアップグレードプロセスの時間を測定する方法について、上の写真のような質問を私にしました。

この問題は、さまざまなシナリオに適用できる一般的な要件に抽象化できます。

たとえば、Kubernetes クラスターの管理者であれば、最適化ポイントを見つけるためにこのプロセスにかかる時間を測定したいとします。
たとえば、CI/CD を実行している場合は、このプロセスの時間消費を測定することで、CI/CD プロセスの時間消費を示す必要があります。

既存のソリューション

Kubernetes は、この問題を解決するための非常に便利な方法を提供しています。これは、私が返信で説明した、イベントによる測定です。

たとえば、K8S でデプロイメントを作成し、そのプロセス内のイベント情報を確認します。

 ➜ ~ kubectl作成ns moelove
 namespace/moelove を作成しました
➜ ~ kubectl -n moeloveデプロイメント redisを作成します--image=ghcr.io/moelove/redis:alpine  
デプロイメント.apps/redis が作成されました
➜ ~ kubectl -n moelove をデプロイする
名前準備完了最新利用可能年齢
レディス 1/1 1 16秒
➜ ~ kubectl -n moelove イベントを取得する
最終閲覧タイプ理由オブジェクトメッセージ
27 秒 通常スケジュール pod/redis-687967dbc5-gsz5n moelove/redis-687967dbc5-gsz5n をkind-control-planeに正常に割り当てました
27 秒 正常 pod/redis-687967dbc5-gsz5n をプルしました コンテナ イメージ「ghcr.io/moelove/redis:alpine」は既にマシン上に存在します
27 秒 正常 pod/redis-687967dbc5-gsz5n を作成しました コンテナ redis を作成しました
27秒 正常 pod/redis-687967dbc5-gsz5n を起動しました コンテナ redis を起動しました
27 秒 正常 成功 replicaset/redis-687967dbc5 を作成しました ポッド redis-687967dbc5-gsz5n を作成しました
27 秒 通常の ScalingReplicaSet デプロイメント/redis レプリカセットredis-687967dbc5を1にスケールアップしました

私たちが主に関心を持っているイベントのいくつかが記録されていることがわかります。しかし、常に kubectl で確認できるとは限らず、時間の無駄になります。

私のこれまでの実践の 1 つは、K8S でプログラムを作成して K8S クラスター内のイベントを継続的に監視および収集し、それを保存および視覚化用に開発したシステムに書き込むことでした。ただし、このアプローチには追加の開発が必要であり、普遍的ではありません。ここで、別のより良い解決策を紹介します。

よりエレガントな解決策

K8S のこれらのイベントは、当社の操作の 1 つに対応しています。たとえば、上記ではデプロイメントが作成され、スケジュール済み、プル済み、作成済みなどのいくつかのイベントが生成されます。これを抽象化すると、リンクトレースと非常に似ているのではないでしょうか。

ここではCNCF卒業プロジェクトJaeger[1]を使用します。これまでのK8Sエコシステムウィークリーレポートでも何度も紹介してきました。 Jaeger は、オープンソースのエンドツーエンドの分散トレースシステムです。ただし、この記事の焦点はそれを紹介することではないため、ドキュメントを確認し、Jaeger をすぐに展開します。 CNCFのサンドボックスレベルのプロジェクトとしては、クラウドネイティブソフトウェアの可観測性フレームワークであるOpenTelemetry[2]があります。イェーガーと組み合わせて使うこともできます。ただし、この記事の焦点はこれら 2 つのプロジェクトを紹介することではないため、ここでは省略します。

次に、この記事で使用したメインプロジェクトである、Weaveworks のオープンソースプロジェクトである kspan を紹介します。その主なアプローチは、K8S 内のイベントをトレースシステムのスパンとして整理することです。

kspanをデプロイする

---  
 APIバージョン: v1
種類: サービスアカウント
メタデータ:
名前: kspan
 ---  
 apiバージョン: rbac。認証.k8s.io/v1
種類: ClusterRoleBinding
メタデータ:
  作成タイムスタンプ: null  
名前: kspan-admin
ロールリファレンス:
  apiGroup : rbac.authorization.k8s.io
  種類: ClusterRole
名前: クラスター管理者
科目:
 - 種類: サービスアカウント
名前: kspan
  名前空間:デフォルト 
 ---  
 APIバージョン: v1
種類: ポッド
メタデータ:
  ラベル:
    実行: kspan
名前: kspan
仕様:
  コンテナ:
  - イメージ: docker.io/weaveworks/kspan:v0.0
名前: kspan
    リソース： {}
  dnsポリシー: ClusterFirst
  再起動ポリシー: 常に
  サービスアカウント名: kspan

ここで提供する YAML をデプロイメントテストに直接使用できますが、上記の構成ファイルは実稼働環境では使用しないでください。また、RBAC 権限を変更する必要があることに注意してください。

デフォルトでは、スパンを渡すために otlp-collector.default:55680 が使用されるため、この svc が存在することを確認する必要があります。上記のコンテンツがすべてデプロイされると、おそらく次のようになります。

 ➜ ~ kubectlすべて取得 
名前準備完了 ステータス 再起動 年齢
pod/jaeger-76c84457fb-89s5v 1/1 実行中 0 64分
pod/kspan 1/1 ランニング 0 35m
 pod/otel-agent-sqlk6 1/1 実行中 0 59 メートル
pod/otel-collector-69985cc444-bjb92 1/1 実行中 0 56m 
 
名前タイプ クラスター IP 外部 IP ポート 年齢
service/jaeger-collector ClusterIP 10.96.47.12 <なし> 14250/TCP 60m
 service/kubernetes ClusterIP 10.96.0.1 <なし> 443/TCP 39h
 service/otel-collector ClusterIP 10.96.231.43 <なし> 4317/TCP、14250/TCP、14268/TCP、9411/TCP、8888/TCP 59m
 service/otlp-collector ClusterIP 10.96.79.181 <なし> 55680/TCP 52m 
 
名前希望現在の準備完了最新利用可能 ノード セレクタ 年齢
daemonset.apps/otel-agent 1 1 1 1 1 <なし> 59m 
 
名前準備完了最新利用可能年齢
デプロイメント.apps/jaeger 1/1 1 1 73分
デプロイメント.apps/otel-collector 1/1 1 1 59分
 
名前希望現在の年齢
レプリカセット.apps/jaeger-6f77c67c44 0 0 0 73分
レプリカセット.apps/jaeger-76c84457fb 1 1 1 64分
レプリカセット.apps/otel-collector-69985cc444 1 1 1 59分

始める

ここではまずテスト用の名前空間を作成します。

 ➜ ~ kubectl作成ns moelove
 namespace/moelove を作成しました

デプロイメントを作成する

➜ ~ kubectl -n moeloveデプロイメント redisを作成します--image=ghcr.io/moelove/redis:alpine  
デプロイメント.apps/redis が作成されました
➜ ~ kubectl -n moelove ポッドを取得する
名前準備完了 ステータス 再起動 年齢
redis-687967dbc5-xj2zs 1/1 実行中 0 10秒

Jaeger でチェックしてください:

詳細を見るにはクリックしてください

ご覧のとおり、デプロイの作成に関連するすべてのイベントがグループ化されており、消費時間などの詳細情報がタイムラインに表示されます。