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

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

[[442818]]

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

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

イベント概要

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

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

  1.  (萌えラブ) ➜ kubectl create ns moelove
  2.  namespace/moelove を作成しました
  3. (MoeLove) ➜ kubectl -n moeloveデプロイメント redisを作成--image=ghcr.io/moelove/redis:alpine  
  4. デプロイメント.apps/redis が作成されました
  5. (MoeLove) ➜ kubectl -n moelove get デプロイ
  6. 名前準備完了最新利用可能年齢
  7. レディス 1/1 1 1 11秒
  8. (MoeLove) ➜ kubectl -n moelove イベントを取得
  9. 最終閲覧タイプ理由オブジェクトメッセージ
  10. 21 秒 通常スケジュール pod/redis-687967dbc5-27vmr moelove/redis-687967dbc5-27vmr をkind-worker3に正常に割り当てました
  11. 21 秒 通常 pod/redis-687967dbc5-27vmr をプルしています イメージ「ghcr.io/moelove/redis:alpine」をプルしています 
  12.  15 秒 正常 pod/redis-687967dbc5-27vmr をプルしました イメージ「ghcr.io/moelove/redis:alpine」を正常にプルしました  6.814310968秒後
  13. 14 秒 正常 pod/redis-687967dbc5-27vmr を作成しました コンテナ redis を作成しました
  14. 14秒 正常 pod/redis-687967dbc5-27vmr を起動しました コンテナ redis を起動しました
  15. 22 秒 正常 成功 replicaset/redis-687967dbc5 を作成しました ポッド redis-687967dbc5-27vmr を作成しました
  16. 22秒 通常のスケーリングレプリカセットのデプロイメント/redis レプリカセットredis-687967dbc5を1にスケールアップしました

ただし、デフォルトでは kubectl get events はイベントを発生順に並べ替えないので、出力を時間順に並べ替えるには、--sort-by='{.metadata.creationTimestamp}' パラメータを追加する必要があることがよくあります。

このため、Kubernetes v1.23 では kubectl alpha events コマンドが追加されました。

時間で並べ替えると、次の結果が表示されます。

  1.  (MoeLove) ➜ kubectl -n moelove イベントを取得--sort-by='{.metadata.creationTimestamp}'  
  2. 最終閲覧タイプ理由オブジェクトメッセージ
  3. 2分12秒 通常スケジュール pod/redis-687967dbc5-27vmr moelove/redis-687967dbc5-27vmr をkind-worker3に正常に割り当てました
  4. 2 分 13 秒 正常 成功 replicaset/redis-687967dbc5 を作成しました ポッド redis-687967dbc5-27vmr を作成しました
  5. 2分13秒 通常のスケーリングレプリカセットのデプロイメント/redis レプリカセットredis-687967dbc5を1にスケールアップしました
  6. 2 分 12 秒 通常 pod/redis-687967dbc5-27vmr をプルしています イメージ"ghcr.io/moelove/redis:alpine"をプルしています 
  7.  2 分 6 秒 正常 pod/redis-687967dbc5-27vmr をプルしました イメージ「ghcr.io/moelove/redis:alpine」を正常にプルしました  6.814310968秒後
  8. 2分5秒 正常 pod/redis-687967dbc5-27vmr を作成しました コンテナ redis を作成しました
  9. 2分5秒 正常 pod/redis-687967dbc5-27vmr を起動しました コンテナ redis を起動しました

上記の操作により、イベントが実際には Kubernetes クラスター内のリソースであることがわかります。 Kubernetes クラスター内のリソースのステータスが変化すると、新しいイベントが生成されることがあります。

イベントに飛び込む

単一イベントオブジェクト

イベントは Kubernetes クラスター内のリソースであるため、通常、metadata.name には個々の操作の名前が含まれている必要があります。したがって、次のコマンドを使用してその名前を出力できます。

  1.  (MoeLove) ➜ kubectl -n moelove get events --sort-by='{.metadata.creationTimestamp}' -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'  
  2. レディス-687967dbc5-27vmr.16c4fb7bde8c69d2
  3. レディス-687967dbc5.16c4fb7bde6b54c4
  4. レディス.16c4fb7bde1bf769
  5. レディス-687967dbc5-27vmr.16c4fb7bf8a0ab35
  6. レディス-687967dbc5-27vmr.16c4fb7d8ecaeff8
  7.  redis-687967dbc5-27vmr.16c4fb7d99709da9
  8. レディス-687967dbc5-27vmr.16c4fb7d9be30c06

任意のイベント レコードを選択し、YAML 形式でエクスポートして表示します。

  1.  (MoeLove) ➜ kubectl -n moelove イベントを取得 redis-687967dbc5-27vmr.16c4fb7bde8c69d2 -o yaml
  2. アクション: バインディング
  3. APIバージョン: v1
  4. イベント時間: "2021-12-28T19:31:13.702987Z"  
  5. 最初のタイムスタンプ: null  
  6. 関与オブジェクト:
  7.   APIバージョン: v1
  8.   種類: ポッド
  9. 名前: redis-687967dbc5-27vmr
  10.   名前空間: moelove
  11.   リソースバージョン: "330230"  
  12.   uid: 71b97182-5593-47b2-88cc-b3f59618c7aa
  13. 種類: イベント
  14. 最終タイムスタンプ: null  
  15. メッセージ: moelove/redis-687967dbc5-27vmr をkind-worker3に正常に割り当てました
  16. メタデータ:
  17.   作成タイムスタンプ: "2021-12-28T19:31:13Z"  
  18. 名前: redis-687967dbc5-27vmr.16c4fb7bde8c69d2
  19.   名前空間: moelove
  20.   リソースバージョン: "330235"  
  21.   ユーザID: e5c03126-33b9-4559-9585-5e82adcd96b0
  22. 理由: 予定
  23. reportingComponent:デフォルト-scheduler
  24.  reportingInstance:デフォルト-scheduler-kind-control-plane
  25. ソース： {}
  26. タイプ: 通常

たくさんの情報が含まれていることがわかりますが、ここでは詳しく説明しません。別の例を見てみましょう。

kubectlのイベント記述

Deployment オブジェクトと Pod オブジェクトに対してそれぞれ記述操作を実行すると、次の結果が得られます (中間出力は省略されています)。

  • 展開時の操作
  1. (MoeLove) ➜ kubectl -n moelove deploy/redis を記述します
  2. 名前: redis
  3. 名前空間: moelove
  4.  ...
  5. イベント:
  6.   タイプ 理由 年齢送信元 メッセージ
  7. ---- ------ ---- ---- -------  
  8.   通常のScalingReplicaSet 15m デプロイメント コントローラ レプリカセットredis-687967dbc5を1にスケールアップしました
  • ポッドの操作
  1. (MoeLove) ➜ kubectl -n moelove ポッドを記述します redis-687967dbc5-27vmr
  2. 名前: redis-687967dbc5-27vmr
  3. 名前空間: moelove
  4. 優先度: 0
  5. イベント:
  6.   タイプ 理由 年齢送信元 メッセージ
  7. ---- ------ ---- ---- -------  
  8.   通常スケジュール 18 分デフォルト-scheduler moelove/redis-687967dbc5-27vmrをkind-worker3に正常に割り当てました
  9.   通常の引き込み 18m kubelet 引き込みイメージ"ghcr.io/moelove/redis:alpine"  
  10.   正常にプルされました 17m kubelet イメージ「ghcr.io/moelove/redis:alpine」を正常にプルしました  6.814310968秒
  11.   通常 17m kubelet を作成しました コンテナ redis を作成しました
  12.   正常 17分 kubelet コンテナ redis を開始

さまざまなリソース オブジェクトを説明するときに、表示されるイベントはすべて自分自身に直接関連していることがわかります。デプロイメントを記述する場合、ポッド関連のイベントは表示されません。

これは、イベント オブジェクトに、それが記述するリソース オブジェクトに関する情報が含まれており、それらが直接関連していることを示しています。

先ほど見た単一の Event オブジェクトと組み合わせると、involvedObject フィールドの内容は、イベントに関連付けられたリソース オブジェクトの情報であることがわかります。

イベントの詳細

存在しないイメージを使用してデプロイメントを作成する次の例を見てみましょう。

  1.  (MoeLove) ➜ kubectl -n moeloveデプロイメントを作成non-exist --image=ghcr.io/moelove/non-exist  
  2. デプロイメント.apps/non-exist が作成されました
  3. (MoeLove) ➜ kubectl -n moelove ポッドを取得する
  4. 名前準備完了 ステータス 再起動 年齢
  5. 存在しない-d9ddbdd84-tnrhd 0/1 ErrImagePull 0 11s
  6.  redis-687967dbc5-27vmr 1/1 実行中 0 26分

現在の Pod が ErrImagePull 状態にあることがわかります。現在の名前空間のイベントを表示します（以前の deploy/redis レコードは省略しました）

  1.  (MoeLove) ➜ kubectl -n moelove イベントを取得--sort-by='{.metadata.creationTimestamp}'  
  2. 最終閲覧タイプ理由オブジェクトメッセージ
  3. 35 秒 正常 成功 レプリカセット/non-exist-d9ddbdd84 を作成しました ポッドを作成しました: non-exist-d9ddbdd84-tnrhd
  4.  35 秒 通常の ScalingReplicaSet の展開/非存在 レプリカセットnon-exist-d9ddbdd84を1にスケールアップしました
  5. 35 秒 通常スケジュール pod/non-exist-d9ddbdd84-tnrhd moelove/non-exist-d9ddbdd84-tnrhd をkind-worker3に正常に割り当てました
  6. 17 秒の警告失敗 pod/non-exist-d9ddbdd84-tnrhd エラー: ErrImagePull
  7.  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 禁止
  8. 18 秒 通常 pod/non-exist-d9ddbdd84-tnrhd をプルしています イメージ「ghcr.io/moelove/non-exist」をプルしています 
  9.  4 秒の警告失敗 pod/non-exist-d9ddbdd84-tnrhd エラー: ImagePullBackOff
  10.  4 秒 通常のバックオフ pod/non-exist-d9ddbdd84-tnrhdイメージ「ghcr.io/moelove/non-exist」のバックオフ 

この Pod に対して記述操作を実行します。

  1.  (MoeLove) ➜ kubectl -n moelove ポッドを記述します non-exist-d9ddbdd84-tnrhd
  2.  ...
  3. イベント:
  4.   タイプ 理由 年齢送信元 メッセージ
  5. ---- ------ ---- ---- -------  
  6.   通常スケジュール 4mデフォルト-scheduler moelove/non-exist-d9ddbdd84-tnrhd をkind-worker3に正常に割り当てました
  7.   通常のプル 2 分 22 秒 (3 分 59 秒かけて x4) kubelet イメージ「ghcr.io/moelove/non-exist」のプル 
  8.   警告失敗 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 禁止
  9.   警告失敗 2分21秒 (3分59秒で4倍) kubelet エラー: ErrImagePull
  10.   警告失敗 2 分 9 秒 (3 分 58 秒で x6) kubelet エラー: ImagePullBackOff
  11.   通常のバックオフ 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 形式で出力します。

  1.  (MoeLove) ➜ kubectl -n moelove イベントを取得 non-exist-d9ddbdd84-tnrhd.16c4fce570cfba46 -o yaml
  2.  APIバージョン: v1
  3. 数: 43
  4. イベント時間: null  
  5. 最初のタイムスタンプ: "2021-12-28T19:57:06Z"  
  6. 関与オブジェクト:
  7.   APIバージョン: v1
  8.   フィールドパス: spec.containers{存在しない}
  9.   種類: ポッド
  10. 名前: 存在しない-d9ddbdd84-tnrhd
  11.   名前空間: moelove
  12.   リソースバージョン: "333366"  
  13.   ユーザID: 33045163-146e-4282-b559-fec19a189a10
  14. 種類: イベント
  15. 最終タイムスタンプ: "2021-12-28T18:07:14Z"  
  16. メッセージ: イメージ「ghcr.io/moelove/non-exist」のプルを中止してください 
  17. メタデータ:
  18.   作成タイムスタンプ: "2021-12-28T19:57:06Z"  
  19. 名前: 存在しない-d9ddbdd84-tnrhd.16c4fce570cfba46
  20.   名前空間: moelove
  21.   リソースバージョン: "334638"  
  22.   ユーザID: 60708be0-23b9-481b-a290-dd208fed6d47
  23. 理由: バックオフ
  24. レポートコンポーネント: ""  
  25. レポートインスタンス: ""  
  26. ソース：
  27.   コンポーネント: kubelet
  28.   ホスト: kind-worker3
  29. タイプ: 通常

ここで、フィールドに同じイベントが何回発生したかを示す count フィールドが含まれていることがわかります。 firstTimestamp と lastTimestamp はそれぞれ、このイベントが最初に出現した時刻と最後に出現した時刻を示します。これは、前の出力におけるイベントの連続サイクルを説明しています。

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

以下はイベントからのランダムな選択です。含まれるフィールド情報の一部を確認できます。

  1.  APIバージョン: v1
  2. カウント: 1
  3. イベント時間: null  
  4. 最初のタイムスタンプ: "2021-12-28T19:31:13Z"  
  5. 関与オブジェクト:
  6.   APIバージョン: アプリ/v1
  7.   種類: レプリカセット
  8. 名前: redis-687967dbc5
  9.   名前空間: moelove
  10.   リソースバージョン: "330227"  
  11.   ユーザID: 11e98a9d-9062-4ccb-92cb-f51cc74d4c1d
  12. 種類: イベント
  13. 最終タイムスタンプ: "2021-12-28T19:31:13Z"  
  14. メッセージ: 'ポッドを作成しました: redis-687967dbc5-27vmr'  
  15. メタデータ:
  16.   作成タイムスタンプ: "2021-12-28T19:31:13Z"  
  17. 名前: redis-687967dbc5.16c4fb7bde6b54c4
  18.   名前空間: moelove
  19.   リソースバージョン: "330231"  
  20.   ユーザID: 8e37ec1e-b3a1-420c-96d4-3b3b2995c300
  21. 理由: 成功しました作成
  22. レポートコンポーネント: ""  
  23. レポートインスタンス: ""  
  24. ソース：
  25.   コンポーネント: レプリカセット コントローラ
  26. タイプ: 通常

主なフィールドの意味は次のとおりです。

  • カウント: 同じ種類のイベントが何回発生したかを示します (前述)
  • volvedObject: このイベントに直接関連付けられたリソース オブジェクト (前述)。構造は次のとおりです。
  1.  ObjectReference構造体型{
  2.  種類の文字列
  3.  名前空間文字列
  4. 名前文字列
  5.  UIDタイプ。UID
  6.  APIバージョン文字列
  7.  リソースバージョン文字列
  8.  フィールドパス文字列
  9. }
  • ソース: 直接関連するコンポーネント、構造は次のようになります。
  1.  EventSource構造体型{
  2.  コンポーネント文字列
  3.  ホスト文字列
  4. }
  • 理由: 単純な要約 (または固定コード)。主に機械で読み取り可能にするために、フィルター条件として使用するのに適しています。現在、このようなコードは 50 個以上あります。
  • メッセージ: 人々が理解しやすいように詳細な説明をしてください
  • タイプ: 現在は「通常」と「警告」の 2 つのタイプのみがあります。それらの意味はソースコードにも書かれています:
  1.  // ステージング/src/k8s.io/api/core/v1/types.go
  2. 定数(
  3.  // 情報のみ そして何の問題も起こさない
  4.  EventTypeNormal 文字列 = "Normal"  
  5.  // これらのイベントは、何か問題が発生する可能性があることを警告するためのものです
  6.  EventTypeWarning 文字列 = "警告"  
  7.  ）

したがって、これらすべてのイベントをトレース範囲として収集すると、ソースに従って分類し、関連するオブジェクトに従って関連付け、時間で並べ替えることができます。

要約する

この記事では、正しくデプロイされた Deploy と存在しないイメージを使用してデプロイされた Deploy の 2 つの例を通じて、主に Events オブジェクトの実際の役割とさまざまなフィールドの意味を紹介します。

Kubernetes の場合、イベントには多くの有用な情報が含まれていますが、この情報は Kubernetes に影響を与えず、実際の Kubernetes ログではありません。デフォルトでは、Kubernetes のログは etcd リソースを解放するために 1 時間後にクリーンアップされます。

したがって、クラスター管理者に何が起こったかをより適切に知らせるために、実稼働環境では通常、Kubernetes クラスターからイベントも収集します。私が個人的にお勧めするツールは、https://github.com/opsgenie/kubernetes-event-exporter です。

この記事はWeChatの公式アカウント「MoeLove」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合はMoeLove公式アカウントまでご連絡ください。

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

>>:  Microsoft Ignite China の詳細な読み物 |クラウド上の6つのデータ機能の長所と短所

推薦する

AWSは、起業のハードルを下げることで、スタートアップ企業や開発者がより早く成功できるよう支援します。

[51CTO.com からのオリジナル記事] クラウド コンピューティングの登場により、IT 供給の...

softshellweb: バレンタインデー、米国/オランダ、無制限トラフィック VPS、年間 25 ドルから、1G メモリ/1 コア/20g SSD、PayPal/Alipay

Softshellweb は、2 月 14 日より、米国西海岸のサンノゼとオランダのアムステルダムの...

モバイル インターネットの 7 つの黄金律: トラフィックが王様、ユーザー第一

1. トラフィックこそが王様、ユーザーが至高モバイル インターネットの時代では、トラフィックは力であ...

ロック後も同時実行の問題は残りますか? Redis 分散ロック、本当に正しく使用されていますか?

新しく引き継いだプロジェクトでは、アカウントの不均衡により問題が発生する場合があります。前の技術担当...

Vagrant をインストールして設定するにはどうすればいいですか?

Vagrant は仮想マシン用の強力なツールです。ここでは、Ubuntu 上で Virtualbox...

エンタープライズウェブサイト変革マーケティング戦略

企業のウェブサイトは、従来のマーケティングからオンライン マーケティングへと移行中です。インターネッ...

Reprisehosting: シアトルの月額 30 ドル以下の格安専用サーバーのレビュー

Reprisehostingはどうですか? Reprisehostingは、アメリカ西海岸のシアトル...

Google ランキングの秘密: アンダースコアは単語の区切り文字と同じ

Matt Cutts 氏は最近、WordPress ユーザーと開発者向けの WordCamp2007...

注目すべき 5 つの重要なマルチクラウド トレンド

現在、一部の企業は、適切なマルチクラウド戦略を策定せずに、複数のクラウド プラットフォームにアプリケ...

画像ネットワークの最適化とトラフィック分析

美人写真は、国内のインターネット初心者のウェブマスターに最も人気のあるウェブサイトの1つです。 良い...

群集心理がSEO最適化に与える影響は良くない

Baidu は新たな変更を加えました。検索結果を収集、共有、報告できるようになりました。これは LE...

ミニプログラム開発が簡単になる「ミニプログラムクラウド開発」が正式リリースされました！

[51CTO.com からのオリジナル記事] 小さなプログラムを開発するには、バックエンド サーバー...

夜も更けたので、分散ロックについて学んでみましょう

[[354141]]この記事はWeChatの公開アカウント「故郷でJavaを学ぶ」から転載したもので...

HTML5 の最新の脆弱性: ユーザーのハードドライブがジャンクデータでいっぱいになる可能性がある

新浪科技報北京時間3月4日朝のニュースによると、HTML5プログラミング言語に新たな脆弱性が本日発見...

法律業界のウェブサイト構築プロセスと計画

2018年最もホットなプロジェクト：テレマーケティングロボットがあなたの参加を待っています今日では、...