Kubernetesのイベントを徹底的に理解する

[[442818]]

以前、私は「よりエレガントな Kubernetes クラスターイベントメトリックソリューション」というタイトルの記事を書きました。この記事では、Jaeger とトレースを使用して Kubernetes クラスター内のイベントを収集して表示します。最終的な効果は次のようになります。

その記事を書いたとき、私は原則を詳しく紹介するためのフラグを立てました。長い間延期してきました。いよいよ年末となり、公開する時期になりました。

イベント概要

Kubernetes クラスターでどのようなイベントが発生するかを確認するために、簡単な例を見てみましょう。

moelove という新しい名前空間を作成し、その中に redis というデプロイメントを作成します。次に、この名前空間内のすべてのイベントを表示します。

 (萌えラブ) ➜ kubectl create ns moelove
 namespace/moelove を作成しました
(MoeLove) ➜ kubectl -n moeloveデプロイメント redisを作成--image=ghcr.io/moelove/redis:alpine  
デプロイメント.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 イベントを取得--sort-by='{.metadata.creationTimestamp}'  
最終閲覧タイプ理由オブジェクトメッセージ
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 --sort-by='{.metadata.creationTimestamp}' -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'  
レディス-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 --image=ghcr.io/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 イベントを取得--sort-by='{.metadata.creationTimestamp}'  
最終閲覧タイプ理由オブジェクトメッセージ
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 文字列 = "警告"  
 ）