|
[[442818]] 以前、私は「よりエレガントな Kubernetes クラスター イベント メトリック ソリューション」というタイトルの記事を書きました。この記事では、Jaeger とトレースを使用して Kubernetes クラスター内のイベントを収集して表示します。最終的な効果は次のようになります。 その記事を書いたとき、私は原則を詳しく紹介するためのフラグを立てました。長い間延期してきました。いよいよ年末となり、公開する時期になりました。 イベント概要Kubernetes クラスターでどのようなイベントが発生するかを確認するために、簡単な例を見てみましょう。 moelove という新しい名前空間を作成し、その中に redis というデプロイメントを作成します。次に、この名前空間内のすべてのイベントを表示します。 - (萌えラブ) ➜ kubectl create ns moelove
- namespace/moelove を作成しました
- (MoeLove) ➜ kubectl -n moeloveデプロイメント redisを作成
- デプロイメント.apps/redis が作成されました
- (MoeLove) ➜ kubectl -n moelove get デプロイ
- 名前準備完了最新利用可能年齢
- レディス 1/1 1 1 11秒
- (MoeLove) ➜ kubectl -n moelove イベントを取得
- 最終閲覧タイプ理由オブジェクトメッセージ
- 21 秒 通常スケジュール pod/redis-687967dbc5-27vmr moelove/redis-687967dbc5-27vmr をkind-worker3に正常に割り当てました
- 21 秒 通常 pod/redis-687967dbc5-27vmr をプルしています イメージ「ghcr.io/moelove/redis:alpine」をプルしています
- 15 秒 正常 pod/redis-687967dbc5-27vmr をプルしました イメージ「ghcr.io/moelove/redis:alpine」を正常にプルしました 6.814310968秒後
- 14 秒 正常 pod/redis-687967dbc5-27vmr を作成しました コンテナ redis を作成しました
- 14秒 正常 pod/redis-687967dbc5-27vmr を起動しました コンテナ redis を起動しました
- 22 秒 正常 成功 replicaset/redis-687967dbc5 を作成しました ポッド redis-687967dbc5-27vmr を作成しました
- 22秒 通常のスケーリングレプリカセットのデプロイメント/redis レプリカセットredis-687967dbc5を1にスケールアップしました
ただし、デフォルトでは kubectl get events はイベントを発生順に並べ替えないので、出力を時間順に並べ替えるには、--sort-by='{.metadata.creationTimestamp}' パラメータを追加する必要があることがよくあります。 このため、Kubernetes v1.23 では kubectl alpha events コマンドが追加されました。 時間で並べ替えると、次の結果が表示されます。 - (MoeLove) ➜ kubectl -n moelove イベントを取得
- 最終閲覧タイプ理由オブジェクトメッセージ
- 2分12秒 通常スケジュール pod/redis-687967dbc5-27vmr moelove/redis-687967dbc5-27vmr をkind-worker3に正常に割り当てました
- 2 分 13 秒 正常 成功 replicaset/redis-687967dbc5 を作成しました ポッド redis-687967dbc5-27vmr を作成しました
- 2分13秒 通常のスケーリングレプリカセットのデプロイメント/redis レプリカセットredis-687967dbc5を1にスケールアップしました
- 2 分 12 秒 通常 pod/redis-687967dbc5-27vmr をプルしています イメージ"ghcr.io/moelove/redis:alpine"をプルしています
- 2 分 6 秒 正常 pod/redis-687967dbc5-27vmr をプルしました イメージ「ghcr.io/moelove/redis:alpine」を正常にプルしました 6.814310968秒後
- 2分5秒 正常 pod/redis-687967dbc5-27vmr を作成しました コンテナ redis を作成しました
- 2分5秒 正常 pod/redis-687967dbc5-27vmr を起動しました コンテナ redis を起動しました
上記の操作により、イベントが実際には Kubernetes クラスター内のリソースであることがわかります。 Kubernetes クラスター内のリソースのステータスが変化すると、新しいイベントが生成されることがあります。 イベントに飛び込む単一イベントオブジェクトイベントは Kubernetes クラスター内のリソースであるため、通常、metadata.name には個々の操作の名前が含まれている必要があります。したがって、次のコマンドを使用してその名前を出力できます。 - (MoeLove) ➜ kubectl -n moelove get events
- レディス-687967dbc5-27vmr.16c4fb7bde8c69d2
- レディス-687967dbc5.16c4fb7bde6b54c4
- レディス.16c4fb7bde1bf769
- レディス-687967dbc5-27vmr.16c4fb7bf8a0ab35
- レディス-687967dbc5-27vmr.16c4fb7d8ecaeff8
- redis-687967dbc5-27vmr.16c4fb7d99709da9
- レディス-687967dbc5-27vmr.16c4fb7d9be30c06
任意のイベント レコードを選択し、YAML 形式でエクスポートして表示します。 - (MoeLove) ➜ kubectl -n moelove イベントを取得 redis-687967dbc5-27vmr.16c4fb7bde8c69d2 -o yaml
- アクション: バインディング
- APIバージョン: v1
- イベント時間: "2021-12-28T19:31:13.702987Z"
- 最初のタイムスタンプ: null
- 関与オブジェクト:
- APIバージョン: v1
- 種類: ポッド
- 名前: redis-687967dbc5-27vmr
- 名前空間: moelove
- リソースバージョン: "330230"
- uid: 71b97182-5593-47b2-88cc-b3f59618c7aa
- 種類: イベント
- 最終タイムスタンプ: null
- メッセージ: moelove/redis-687967dbc5-27vmr をkind-worker3に正常に割り当てました
- メタデータ:
- 作成タイムスタンプ: "2021-12-28T19:31:13Z"
- 名前: redis-687967dbc5-27vmr.16c4fb7bde8c69d2
- 名前空間: moelove
- リソースバージョン: "330235"
- ユーザID: e5c03126-33b9-4559-9585-5e82adcd96b0
- 理由: 予定
- reportingComponent:デフォルト-scheduler
- reportingInstance:デフォルト-scheduler-kind-control-plane
- ソース： {}
- タイプ: 通常
たくさんの情報が含まれていることがわかりますが、ここでは詳しく説明しません。別の例を見てみましょう。 kubectlのイベント記述Deployment オブジェクトと Pod オブジェクトに対してそれぞれ記述操作を実行すると、次の結果が得られます (中間出力は省略されています)。 - (MoeLove) ➜ kubectl -n moelove deploy/redis を記述します
- 名前: redis
- 名前空間: moelove
- ...
- イベント:
- タイプ 理由 年齢送信元 メッセージ
-
- 通常のScalingReplicaSet 15m デプロイメント コントローラ レプリカセットredis-687967dbc5を1にスケールアップしました
- (MoeLove) ➜ kubectl -n moelove ポッドを記述します redis-687967dbc5-27vmr
- 名前: redis-687967dbc5-27vmr
- 名前空間: moelove
- 優先度: 0
- イベント:
- タイプ 理由 年齢送信元 メッセージ
-
- 通常スケジュール 18 分デフォルト-scheduler moelove/redis-687967dbc5-27vmrをkind-worker3に正常に割り当てました
- 通常の引き込み 18m kubelet 引き込みイメージ"ghcr.io/moelove/redis:alpine"
- 正常にプルされました 17m kubelet イメージ「ghcr.io/moelove/redis:alpine」を正常にプルしました 6.814310968秒
- 通常 17m kubelet を作成しました コンテナ redis を作成しました
- 正常 17分 kubelet コンテナ redis を開始
さまざまなリソース オブジェクトを説明するときに、表示されるイベントはすべて自分自身に直接関連していることがわかります。デプロイメントを記述する場合、ポッド関連のイベントは表示されません。 これは、イベント オブジェクトに、それが記述するリソース オブジェクトに関する情報が含まれており、それらが直接関連していることを示しています。 先ほど見た単一の Event オブジェクトと組み合わせると、involvedObject フィールドの内容は、イベントに関連付けられたリソース オブジェクトの情報であることがわかります。 イベントの詳細存在しないイメージを使用してデプロイメントを作成する次の例を見てみましょう。 - (MoeLove) ➜ kubectl -n moeloveデプロイメントを作成non-exist
- デプロイメント.apps/non-exist が作成されました
- (MoeLove) ➜ kubectl -n moelove ポッドを取得する
- 名前準備完了 ステータス 再起動 年齢
- 存在しない-d9ddbdd84-tnrhd 0/1 ErrImagePull 0 11s
- redis-687967dbc5-27vmr 1/1 実行中 0 26分
現在の Pod が ErrImagePull 状態にあることがわかります。現在の名前空間のイベントを表示します（以前の deploy/redis レコードは省略しました） - (MoeLove) ➜ kubectl -n moelove イベントを取得
- 最終閲覧タイプ理由オブジェクトメッセージ
- 35 秒 正常 成功 レプリカセット/non-exist-d9ddbdd84 を作成しました ポッドを作成しました: non-exist-d9ddbdd84-tnrhd
- 35 秒 通常の ScalingReplicaSet の展開/非存在 レプリカセットnon-exist-d9ddbdd84を1にスケールアップしました
- 35 秒 通常スケジュール pod/non-exist-d9ddbdd84-tnrhd moelove/non-exist-d9ddbdd84-tnrhd をkind-worker3に正常に割り当てました
- 17 秒の警告失敗 pod/non-exist-d9ddbdd84-tnrhd エラー: ErrImagePull
- 17秒警告失敗pod/non-exist-d9ddbdd84-tnrhdイメージ「ghcr.io/moelove/non-exist」のプルに失敗しました: rpcエラー: code = Unknown desc =イメージ「ghcr.io/moelove/non-exist:latest」のプルと解凍に失敗しました: 参照「ghcr.io/moelove/non-exist:latest」の解決に失敗しました:承認に失敗しました: 匿名トークンを取得: 予期しないステータス: 403 禁止
- 18 秒 通常 pod/non-exist-d9ddbdd84-tnrhd をプルしています イメージ「ghcr.io/moelove/non-exist」をプルしています
- 4 秒の警告失敗 pod/non-exist-d9ddbdd84-tnrhd エラー: ImagePullBackOff
- 4 秒 通常のバックオフ pod/non-exist-d9ddbdd84-tnrhdイメージ「ghcr.io/moelove/non-exist」のバックオフ
この Pod に対して記述操作を実行します。 - (MoeLove) ➜ kubectl -n moelove ポッドを記述します non-exist-d9ddbdd84-tnrhd
- ...
- イベント:
- タイプ 理由 年齢送信元 メッセージ
-
- 通常スケジュール 4mデフォルト-scheduler moelove/non-exist-d9ddbdd84-tnrhd をkind-worker3に正常に割り当てました
- 通常のプル 2 分 22 秒 (3 分 59 秒かけて x4) kubelet イメージ「ghcr.io/moelove/non-exist」のプル
- 警告失敗 2分21秒 (3分59秒で4倍) kubeletイメージ「ghcr.io/moelove/non-exist」のプルに失敗しました: rpcエラー: code = 不明desc =イメージ「ghcr.io/moelove/non-exist:latest」のプルと解凍に失敗しました: 参照「ghcr.io/moelove/non-exist:latest」の解決に失敗しました:承認に失敗しました: 匿名トークンを取得: 予期しないステータス: 403 禁止
- 警告失敗 2分21秒 (3分59秒で4倍) kubelet エラー: ErrImagePull
- 警告失敗 2 分 9 秒 (3 分 58 秒で x6) kubelet エラー: ImagePullBackOff
- 通常のバックオフ 115 秒 (3 分 58 秒にわたって x7) kubelet バックオフイメージ「ghcr.io/moelove/non-exist」をプル
ここでの出力は、Pod の以前の正しい実行とは異なることがわかります。主な違いは年齢の列にあります。ここでは、115 秒 (3 分 58 秒にわたって x7) のような出力が表示されます。 つまり、このタイプのイベントは 3 分 58 秒以内に 7 回発生しており、最新のイベントは 115 秒前に発生しています。 しかし、kubectl get events を直接実行すると、7 つの重複イベントは表示されません。これは、Kubernetes が重複するイベントを自動的にマージすることを意味します。 最後のイベントを選択し（方法は上記で説明しました）、その内容を YAML 形式で出力します。 - (MoeLove) ➜ kubectl -n moelove イベントを取得 non-exist-d9ddbdd84-tnrhd.16c4fce570cfba46 -o yaml
- APIバージョン: v1
- 数: 43
- イベント時間: null
- 最初のタイムスタンプ: "2021-12-28T19:57:06Z"
- 関与オブジェクト:
- APIバージョン: v1
- フィールドパス: spec.containers{存在しない}
- 種類: ポッド
- 名前: 存在しない-d9ddbdd84-tnrhd
- 名前空間: moelove
- リソースバージョン: "333366"
- ユーザID: 33045163-146e-4282-b559-fec19a189a10
- 種類: イベント
- 最終タイムスタンプ: "2021-12-28T18:07:14Z"
- メッセージ: イメージ「ghcr.io/moelove/non-exist」のプルを中止してください
- メタデータ:
- 作成タイムスタンプ: "2021-12-28T19:57:06Z"
- 名前: 存在しない-d9ddbdd84-tnrhd.16c4fce570cfba46
- 名前空間: moelove
- リソースバージョン: "334638"
- ユーザID: 60708be0-23b9-481b-a290-dd208fed6d47
- 理由: バックオフ
- レポートコンポーネント: ""
- レポートインスタンス: ""
- ソース：
- コンポーネント: kubelet
- ホスト: kind-worker3
- タイプ: 通常
ここで、フィールドに同じイベントが何回発生したかを示す count フィールドが含まれていることがわかります。 firstTimestamp と lastTimestamp はそれぞれ、このイベントが最初に出現した時刻と最後に出現した時刻を示します。これは、前の出力におけるイベントの連続サイクルを説明しています。 イベントを徹底的に理解する以下はイベントからのランダムな選択です。含まれるフィールド情報の一部を確認できます。 - APIバージョン: v1
- カウント: 1
- イベント時間: null
- 最初のタイムスタンプ: "2021-12-28T19:31:13Z"
- 関与オブジェクト:
- APIバージョン: アプリ/v1
- 種類: レプリカセット
- 名前: redis-687967dbc5
- 名前空間: moelove
- リソースバージョン: "330227"
- ユーザID: 11e98a9d-9062-4ccb-92cb-f51cc74d4c1d
- 種類: イベント
- 最終タイムスタンプ: "2021-12-28T19:31:13Z"
- メッセージ: 'ポッドを作成しました: redis-687967dbc5-27vmr'
- メタデータ:
- 作成タイムスタンプ: "2021-12-28T19:31:13Z"
- 名前: redis-687967dbc5.16c4fb7bde6b54c4
- 名前空間: moelove
- リソースバージョン: "330231"
- ユーザID: 8e37ec1e-b3a1-420c-96d4-3b3b2995c300
- 理由: 成功しました作成
- レポートコンポーネント: ""
- レポートインスタンス: ""
- ソース：
- コンポーネント: レプリカセット コントローラ
- タイプ: 通常
主なフィールドの意味は次のとおりです。 - カウント: 同じ種類のイベントが何回発生したかを示します (前述)
- volvedObject: このイベントに直接関連付けられたリソース オブジェクト (前述)。構造は次のとおりです。
- ObjectReference構造体型{
- 種類の文字列
- 名前空間文字列
- 名前文字列
- UIDタイプ。UID
- APIバージョン文字列
- リソースバージョン文字列
- フィールドパス文字列
- }
- ソース: 直接関連するコンポーネント、構造は次のようになります。
- EventSource構造体型{
- コンポーネント文字列
- ホスト文字列
- }
- 理由: 単純な要約 (または固定コード)。主に機械で読み取り可能にするために、フィルター条件として使用するのに適しています。現在、このようなコードは 50 個以上あります。
- メッセージ: 人々が理解しやすいように詳細な説明をしてください
- タイプ: 現在は「通常」と「警告」の 2 つのタイプのみがあります。それらの意味はソースコードにも書かれています:
- // ステージング/src/k8s.io/api/core/v1/types.go
- 定数(
- // 情報のみ そして何の問題も起こさない
- EventTypeNormal 文字列 = "Normal"
- // これらのイベントは、何か問題が発生する可能性があることを警告するためのものです
- EventTypeWarning 文字列 = "警告"
- ）
したがって、これらすべてのイベントをトレース範囲として収集すると、ソースに従って分類し、関連するオブジェクトに従って関連付け、時間で並べ替えることができます。 要約するこの記事では、正しくデプロイされた Deploy と存在しないイメージを使用してデプロイされた Deploy の 2 つの例を通じて、主に Events オブジェクトの実際の役割とさまざまなフィールドの意味を紹介します。 Kubernetes の場合、イベントには多くの有用な情報が含まれていますが、この情報は Kubernetes に影響を与えず、実際の Kubernetes ログではありません。デフォルトでは、Kubernetes のログは etcd リソースを解放するために 1 時間後にクリーンアップされます。 したがって、クラスター管理者に何が起こったかをより適切に知らせるために、実稼働環境では通常、Kubernetes クラスターからイベントも収集します。私が個人的にお勧めするツールは、https://github.com/opsgenie/kubernetes-event-exporter です。 この記事はWeChatの公式アカウント「MoeLove」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合はMoeLove公式アカウントまでご連絡ください。 | 
