Kubernetesのイベントを徹底的に理解する
20131 ワード
こんにちは皆さん、これはJintao張です.
記事を書く前に"A More Elegant Kubernetes Cluster Event Measurement Scheme" , Kabernetesクラスタのイベントを収集し、それを表示するために追跡を使用するJaegerを使用します.最後の効果は次のとおりです.
私がその記事を書いたとき、私は詳細に原則を導入するために旗を立てました.私は長い間鳩が鳴っている.今では今年の終わりであり、それを送信する時間です.
最初にKubernetesクラスタのイベントが何であるかを見る簡単な例を作りましょう.
新しい名前空間を作成する
これがKubernetesが追加する理由です
時間順にソートした後、次のような結果が表示されます.
イベントはKubernetesクラスタのメタデータです.名前は、個々の操作のために通常の状況の下でその名前を含むべきです.以下のコマンドを使って名前を出力できます:
展開オブジェクトとPODオブジェクトをそれぞれ記述し、以下の結果を得ることができます(中間出力は省略されます). 展開の操作
ポッドで動く
これは、それが記述するリソースオブジェクトに関する情報を含むイベントオブジェクトであることを示します.
以前に見たシングルイベントオブジェクトを組み合わせることで、イベントに関連するリソースオブジェクトのInvolveDoObjectを見つけました.
次の例を見てみましょう.
意味は:このタイプのイベントは3 m 58 sで7回起こり、最近のものは以前に起こった
しかし、我々が直接Kubectlに行ったとき、我々は7つの繰り返されたイベントを見ませんでした.これはKubernetesが自動的に複製イベントをマージすることを示します.
最後のイベントを選択します(このメソッドは前の内容で説明されており、YAML形式でその内容を出力します:
次のコンテンツはイベントからのランダムな選択です.
count :現在の類似イベントが何回発生したかを示す InvolveDoObject :このイベントに直接関連するリソースオブジェクト(上記で紹介されている)は、次のようになります.
ソース:直接関連するコンポーネントは、次のようになります.
理由:単純な要約(または固定コード)は、フィルタリングの条件に適しています.現在50以上のそのようなコードがあります メッセージ:人々が理解するために簡単です詳細な説明を与える type :現在は正常で警告があり、ソースコードにもその意味が書かれています:
この記事では、主に2つの例、適切に配置された展開、および存在しないイメージ展開を使用する展開を使用して、イベントオブジェクトの実際の機能と各フィールドの意味を深く説明します.
Kubernetesのために、イベントは多くの有用な情報を含んでいます、しかし、この情報はKubernetesにどんな影響も持ちません、そして、彼らは実際のKubernetes記録でありません.デフォルトでは、Ketbernetesのログは、ETCDのリソース占有を解放するために1時間後にクリーンアップされます.
それで、クラスタ管理者が何が起こったかをよりよく知っているようにするために、生産環境で、我々は通常Kubernetesクラスタのイベントを集めます.私が個人的に推薦するツールはhttps://github.com/opsgenie/kubernetes-event-exporter
もちろん、あなたも私の前の記事に従うことができます"A More Elegant Kubernetes Cluster Event Measurement Scheme" , Kabernetesクラスタのイベントを収集し、それらを表示するために追跡を使用するJaegerを使用します.
ようこそ私の記事を購読する
記事を書く前に"A More Elegant Kubernetes Cluster Event Measurement Scheme" , Kabernetesクラスタのイベントを収集し、それを表示するために追跡を使用するJaegerを使用します.最後の効果は次のとおりです.
私がその記事を書いたとき、私は詳細に原則を導入するために旗を立てました.私は長い間鳩が鳴っている.今では今年の終わりであり、それを送信する時間です.
イーエンス概要
最初にKubernetesクラスタのイベントが何であるかを見る簡単な例を作りましょう.
新しい名前空間を作成する
moelove
, そして、redis
それで.次に、この名前空間のすべてのイベントを見てください.(MoeLove) ➜ kubectl create ns moelove
namespace/moelove created
(MoeLove) ➜ kubectl -n moelove create deployment redis --image=ghcr.io/moelove/redis:alpine
deployment.apps/redis created
(MoeLove) ➜ kubectl -n moelove get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
redis 1/1 1 1 11s
(MoeLove) ➜ kubectl -n moelove get events
LAST SEEN TYPE REASON OBJECT MESSAGE
21s Normal Scheduled pod/redis-687967dbc5-27vmr Successfully assigned moelove/redis-687967dbc5-27vmr to kind-worker3
21s Normal Pulling pod/redis-687967dbc5-27vmr Pulling image "ghcr.io/moelove/redis:alpine"
15s Normal Pulled pod/redis-687967dbc5-27vmr Successfully pulled image "ghcr.io/moelove/redis:alpine" in 6.814310968s
14s Normal Created pod/redis-687967dbc5-27vmr Created container redis
14s Normal Started pod/redis-687967dbc5-27vmr Started container redis
22s Normal SuccessfulCreate replicaset/redis-687967dbc5 Created pod: redis-687967dbc5-27vmr
22s Normal ScalingReplicaSet deployment/redis Scaled up replica set redis-687967dbc5 to 1
しかし、デフォルトではkubectl get events
イベントが発生する順序では配置されませんので、しばしば--sort-by='{.metadata.creationTimestamp}'
その出力が時間内に配置できるようにパラメータを設定します.これがKubernetesが追加する理由です
kubectl alpha events
コマンドv 1.23バージョン.私は前の記事で詳細な紹介をしました.時間順にソートした後、次のような結果が表示されます.
(MoeLove) ➜ kubectl -n moelove get events --sort-by='{.metadata.creationTimestamp}'
LAST SEEN TYPE REASON OBJECT MESSAGE
2m12s Normal Scheduled pod/redis-687967dbc5-27vmr Successfully assigned moelove/redis-687967dbc5-27vmr to kind-worker3
2m13s Normal SuccessfulCreate replicaset/redis-687967dbc5 Created pod: redis-687967dbc5-27vmr
2m13s Normal ScalingReplicaSet deployment/redis Scaled up replica set redis-687967dbc5 to 1
2m12s Normal Pulling pod/redis-687967dbc5-27vmr Pulling image "ghcr.io/moelove/redis:alpine"
2m6s Normal Pulled pod/redis-687967dbc5-27vmr Successfully pulled image "ghcr.io/moelove/redis:alpine" in 6.814310968s
2m5s Normal Created pod/redis-687967dbc5-27vmr Created container redis
2m5s Normal Started pod/redis-687967dbc5-27vmr Started container redis
以上の操作を通じて、イベントが実際にKubernetesクラスタのリソースであることがわかります.Kubernetesクラスタのリソース状態が変更されると、新しいイベントが生成されます.詳細イベント
シングルイベントオブジェクト
イベントはKubernetesクラスタのメタデータです.名前は、個々の操作のために通常の状況の下でその名前を含むべきです.以下のコマンドを使って名前を出力できます:
(MoeLove) ➜ kubectl -n moelove get events --sort-by='{.metadata.creationTimestamp}' -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'
redis-687967dbc5-27vmr.16c4fb7bde8c69d2
redis-687967dbc5.16c4fb7bde6b54c4
redis.16c4fb7bde1bf769
redis-687967dbc5-27vmr.16c4fb7bf8a0ab35
redis-687967dbc5-27vmr.16c4fb7d8ecaeff8
redis-687967dbc5-27vmr.16c4fb7d99709da9
redis-687967dbc5-27vmr.16c4fb7d9be30c06
イベントレコードのいずれかを選択し、YAML形式で出力します.(MoeLove) ➜ kubectl -n moelove get events redis-687967dbc5-27vmr.16c4fb7bde8c69d2 -o yaml
action: Binding
apiVersion: v1
eventTime: "2021-12-28T19:31:13.702987Z"
firstTimestamp: null
involvedObject:
apiVersion: v1
kind: Pod
name: redis-687967dbc5-27vmr
namespace: moelove
resourceVersion: "330230"
uid: 71b97182-5593-47b2-88cc-b3f59618c7aa
kind: Event
lastTimestamp: null
message: Successfully assigned moelove/redis-687967dbc5-27vmr to kind-worker3
metadata:
creationTimestamp: "2021-12-28T19:31:13Z"
name: redis-687967dbc5-27vmr.16c4fb7bde8c69d2
namespace: moelove
resourceVersion: "330235"
uid: e5c03126-33b9-4559-9585-5e82adcd96b0
reason: Scheduled
reportingComponent: default-scheduler
reportingInstance: default-scheduler-kind-control-plane
source: {}
type: Normal
多くの情報が含まれているのを見ることができます.別の例を見てみましょう.クベッテのイベント
展開オブジェクトとPODオブジェクトをそれぞれ記述し、以下の結果を得ることができます(中間出力は省略されます).
(MoeLove) ➜ kubectl -n moelove describe deploy/redis
Name: redis
Namespace: moelove
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 15m deployment-controller Scaled up replica set redis-687967dbc5 to 1
(MoeLove) ➜ kubectl -n moelove describe pods redis-687967dbc5-27vmr
Name: redis-687967dbc5-27vmr
Namespace: moelove
Priority: 0
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 18m default-scheduler Successfully assigned moelove/redis-687967dbc5-27vmr to kind-worker3
Normal Pulling 18m kubelet Pulling image "ghcr.io/moelove/redis:alpine"
Normal Pulled 17m kubelet Successfully pulled image "ghcr.io/moelove/redis:alpine" in 6.814310968s
Normal Created 17m kubelet Created container redis
Normal Started 17m kubelet Started container redis
異なったリソースオブジェクトを記述するとき、見ることができる出来事の内容は直接それ自体に関連していることを見つけることができます.展開を記述すると、pod関連のイベントを見ることができません.これは、それが記述するリソースオブジェクトに関する情報を含むイベントオブジェクトであることを示します.
以前に見たシングルイベントオブジェクトを組み合わせることで、イベントに関連するリソースオブジェクトのInvolveDoObjectを見つけました.
イベントについて詳しく知る
次の例を見てみましょう.
(MoeLove) ➜ kubectl -n moelove create deployment non-exist --image=ghcr.io/moelove/non-exist
deployment.apps/non-exist created
(MoeLove) ➜ kubectl -n moelove get pods
NAME READY STATUS RESTARTS AGE
non-exist-d9ddbdd84-tnrhd 0/1 ErrImagePull 0 11s
redis-687967dbc5-27vmr 1/1 Running 0 26m
現在のポッドが現在の名前空間のイベントを表示するerrimagepullの状態になっているのを見ることができます.(MoeLove) ➜ kubectl -n moelove get events --sort-by='{.metadata.creationTimestamp}'
LAST SEEN TYPE REASON OBJECT MESSAGE
35s Normal SuccessfulCreate replicaset/non-exist-d9ddbdd84 Created pod: non-exist-d9ddbdd84-tnrhd
35s Normal ScalingReplicaSet deployment/non-exist Scaled up replica set non-exist-d9ddbdd84 to 1
35s Normal Scheduled pod/non-exist-d9ddbdd84-tnrhd Successfully assigned moelove/non-exist-d9ddbdd84-tnrhd to kind-worker3
17s Warning Failed pod/non-exist-d9ddbdd84-tnrhd Error: ErrImagePull
17s Warning Failed pod/non-exist-d9ddbdd84-tnrhd Failed to pull image "ghcr.io/moelove/non-exist": rpc error: code = Unknown desc = failed to pull and unpack image "ghcr.io/moelove/non-exist:latest": failed to resolve reference "ghcr.io/moelove/non-exist:latest": failed to authorize: failed to fetch anonymous token: unexpected status: 403 Forbidden
18s Normal Pulling pod/non-exist-d9ddbdd84-tnrhd Pulling image "ghcr.io/moelove/non-exist"
4s Warning Failed pod/non-exist-d9ddbdd84-tnrhd Error: ImagePullBackOff
4s Normal BackOff pod/non-exist-d9ddbdd84-tnrhd Back-off pulling image "ghcr.io/moelove/non-exist"
このPODの操作を説明します(MoeLove) ➜ kubectl -n moelove describe pods non-exist-d9ddbdd84-tnrhd
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 4m default-scheduler Successfully assigned moelove/non-exist-d9ddbdd84-tnrhd to kind-worker3
Normal Pulling 2m22s (x4 over 3m59s) kubelet Pulling image "ghcr.io/moelove/non-exist"
Warning Failed 2m21s (x4 over 3m59s) kubelet Failed to pull image "ghcr.io/moelove/non-exist": rpc error: code = Unknown desc = failed to pull and unpack image "ghcr.io/moelove/non-exist:latest": failed to resolve reference "ghcr.io/moelove/non-exist:latest": failed to authorize: failed to fetch anonymous token: unexpected status: 403 Forbidden
Warning Failed 2m21s (x4 over 3m59s) kubelet Error: ErrImagePull
Warning Failed 2m9s (x6 over 3m58s) kubelet Error: ImagePullBackOff
Normal BackOff 115s (x7 over 3m58s) kubelet Back-off pulling image "ghcr.io/moelove/non-exist"
ここでの出力は前のPODと正しく動作していることがわかります.主な違いは、ここで我々が出力115 s(3 m 58 s以上のx 7)を見るコラム時代です意味は:このタイプのイベントは3 m 58 sで7回起こり、最近のものは以前に起こった
しかし、我々が直接Kubectlに行ったとき、我々は7つの繰り返されたイベントを見ませんでした.これはKubernetesが自動的に複製イベントをマージすることを示します.
最後のイベントを選択します(このメソッドは前の内容で説明されており、YAML形式でその内容を出力します:
(MoeLove) ➜ kubectl -n moelove get events non-exist-d9ddbdd84-tnrhd.16c4fce570cfba46 -o yaml
apiVersion: v1
count: 43
eventTime: null
firstTimestamp: "2021-12-28T19:57:06Z"
involvedObject:
apiVersion: v1
fieldPath: spec.containers{non-exist}
kind: Pod
name: non-exist-d9ddbdd84-tnrhd
namespace: moelove
resourceVersion: "333366"
uid: 33045163-146e-4282-b559-fec19a189a10
kind: Event
lastTimestamp: "2021-12-28T18:07:14Z"
message: Back-off pulling image "ghcr.io/moelove/non-exist"
metadata:
creationTimestamp: "2021-12-28T19:57:06Z"
name: non-exist-d9ddbdd84-tnrhd.16c4fce570cfba46
namespace: moelove
resourceVersion: "334638"
uid: 60708be0-23b9-481b-a290-dd208fed6d47
reason: BackOff
reportingComponent: ""
reportingInstance: ""
source:
component: kubelet
host: kind-worker3
type: Normal
ここでは、フィールドには、同じ型のイベントが何回発生したかを示すカウントフィールドが含まれていることがわかります.そして、firsttimestampとlasttimestampは、最初にこのイベントの最後の発生の時刻をそれぞれ表します.これも前の出力のイベントの期間を説明します.完全にイベントを理解する
次のコンテンツはイベントからのランダムな選択です.
apiVersion: v1
count: 1
eventTime: null
firstTimestamp: "2021-12-28T19:31:13Z"
involvedObject:
apiVersion: apps/v1
kind: ReplicaSet
name: redis-687967dbc5
namespace: moelove
resourceVersion: "330227"
uid: 11e98a9d-9062-4ccb-92cb-f51cc74d4c1d
kind: Event
lastTimestamp: "2021-12-28T19:31:13Z"
message: 'Created pod: redis-687967dbc5-27vmr'
metadata:
creationTimestamp: "2021-12-28T19:31:13Z"
name: redis-687967dbc5.16c4fb7bde6b54c4
namespace: moelove
resourceVersion: "330231"
uid: 8e37ec1e-b3a1-420c-96d4-3b3b2995c300
reason: SuccessfulCreate
reportingComponent: ""
reportingInstance: ""
source:
component: replicaset-controller
type: Normal
主な分野の意味は以下の通りである.type ObjectReference struct {
Kind string
Namespace string
Name string
UID types.UID
APIVersion string
ResourceVersion string
FieldPath string
}
type EventSource struct {
Component string
Host string
}
// staging/src/k8s.io/api/core/v1/types.go
const (
// Information only and will not cause any problems
EventTypeNormal string = "Normal"
// These events are to warn that something might go wrong
EventTypeWarning string = "Warning"
)
したがって、これらのイベントをトレースソースとして収集するときには、それらをIndeveObjectと分類し、それらを時間順に並べ替えることができます.要約する
この記事では、主に2つの例、適切に配置された展開、および存在しないイメージ展開を使用する展開を使用して、イベントオブジェクトの実際の機能と各フィールドの意味を深く説明します.
Kubernetesのために、イベントは多くの有用な情報を含んでいます、しかし、この情報はKubernetesにどんな影響も持ちません、そして、彼らは実際のKubernetes記録でありません.デフォルトでは、Ketbernetesのログは、ETCDのリソース占有を解放するために1時間後にクリーンアップされます.
それで、クラスタ管理者が何が起こったかをよりよく知っているようにするために、生産環境で、我々は通常Kubernetesクラスタのイベントを集めます.私が個人的に推薦するツールはhttps://github.com/opsgenie/kubernetes-event-exporter
もちろん、あなたも私の前の記事に従うことができます"A More Elegant Kubernetes Cluster Event Measurement Scheme" , Kabernetesクラスタのイベントを収集し、それらを表示するために追跡を使用するJaegerを使用します.
ようこそ私の記事を購読する
Reference
この問題について(Kubernetesのイベントを徹底的に理解する), 我々は、より多くの情報をここで見つけました https://dev.to/zhangjintao/thoroughly-understand-events-in-kubernetes-29ljテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol