Jagu'e'r O11y分科会 0630 - kubectl logsのその先へ、実は使えるいろんなKubernetesログを追ってみよう

Transcript

1. kubectl logs のその先へ、 実は使える GKE の Kubernetes ログ を追ってみよう Kakeru Ishii Google Cloud Japan Technical Solutions Engineer
2. 02 石井 翔 Google Cloud Technical Solutions Engineer @kyasbal_k @kyasbal
3. 03 石井 翔 Google Cloud Technical Solutions Engineer Google Cloud のテクニカルサポートのエンジニア = @kyasbal_k @kyasbal
4. 4 Google Kubernetes Engine (GKE) の Cloud Console の画面までしか見ない こんなログの使い方になっていませんか?
5. 5 Google Kubernetes Engine (GKE) の Cloud Console の画面までしか見ない Cloud Logging の使い方が難しいので kubectl logs と kubectl describe だけでなんとかする こんなログの使い方になっていませんか?
6. Google Cloud 6 Google Kubernetes Engine (GKE) の Cloud Console の画面までしか見ない Cloud Logging の使い方が難しいので kubectl logs と kubectl describe だけでなんとかする Cloud Logging の上に書くログフィルタがこんな感じ : こんなログの使い方になっていませんか? フィルタ例1 : とりあえずエラーの文字列でマッチ
7. Google Cloud 7 Google Kubernetes Engine (GKE) の Cloud Console の画面までしか見ない Cloud Logging の使い方が難しいので kubectl logs と kubectl describe だけでなんとかする Cloud Logging の上に書くログフィルタがこんな感じ : こんなログの使い方になっていませんか? フィルタ例1 : とりあえずエラーの文字列でマッチ フィルタ例2 : いらないログを片っ端からフィルタ
8. Google Cloud Proprietary & Confidential 8 どんなログがあるか分からないし、 適切なログフィルタが分からない
9. 実は 2つ のフィールドに着目すると、分かりやすくフィルタできる "resource (Goole Cloud 上の要素)" の中に、"logName (ログの種類)" というファイルが書き込まれるイメージ おすすめ ログフィルタテンプレート resource.type = "<resource type>" resource.labels.field_A = "foo" resource.labels.field_B = "bar" LOG_ID("<log_name>") # その他のフィルター（必要に応じて追加） 構造のイメージ (リソースとログ名 ) GCE 1 GCE 2 シリアルポート GuestAgent シリアルポート GuestAgent logName resource
10. 実は 2つ のフィールドに着目すると、分かりやすくフィルタできる "resource (Google Cloud 上の要素)" の中に、"logName (ログの種類)" というファイルが書き込まれるイメージ 実際のログフィルタテンプレート (例) resource.type = "k8s_container" resource.labels.cluster_name = "foo" resource.labels.pod_name = "bar" resource.labels.container_name = "qux" LOG_ID("stdout") OR LOG_ID("sterr") 構造のイメージ (リソースとログ名 ) GCE 1 GCE 2 シリアルポート GuestAgent シリアルポート GuestAgent logName resource
11. 実は 2つ のフィールドに着目すると、分かりやすくフィルタできる "resource (Google Cloud 上の要素)" の中に、"logName (ログの種類)" というファイルが書き込まれるイメージ 実際のログフィルタテンプレート (例) resource.type = "k8s_container" resource.labels.cluster_name = "foo" resource.labels.pod_name = "bar" resource.labels.container_name = "qux" LOG_ID("stdout") OR LOG_ID("sterr") 構造のイメージ (リソースとログ名 ) GCE 1 GCE 2 シリアルポート GuestAgent シリアルポート GuestAgent logName resource 今日は resource と logName に着目しながら GKE の様々なログを見ていく
12. Google Cloud 12 今日のシナリオ GKE で Job が動くまで
13. Google Cloud Google Cloud 13 GKE で Job が動くまで コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd kubectl apply -f ./my-job.yaml Job 1. ユーザが Job を kubectl apply する
14. Google Cloud Google Cloud 14 GKE で Job が動くまで コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Job Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る
15. Google Cloud Google Cloud 15 GKE で Job が動くまで コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod binding 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Pod に ノードを紐づける
16. Google Cloud Google Cloud 16 GKE で Job が動くまで コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける 4. 対象のノードの kubelet が Pod の情報を受け取る
17. Google Cloud Google Cloud 17 GKE で Job が動くまで コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Pod に ノードを紐づける 4. 対象のノードの kubelet が Pod の情報を受け取る 5. containerd に指示してコンテナを作る コンテナ作って ! コンテナ
18. Google Cloud 18 同じものを "ログ視点" で見ていく
19. Google Cloud Google Cloud 19 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd kubectl apply -f ./my-job.yaml Job 1. ユーザが Job を kubectl apply する Kubernetes の監査ログ (Kubernetes のリソースをどう変えようとしたか?) LOG_ID("cloudaudit.googleapis.com/activity") もしくは LOG_ID("cloudaudit.googleapis.com/data_access") kube-apiserver が書き込んでいるので resource.type = "k8s_cluster" resource.labels にはクラスタを特定するラベル (location, project, cluster_name などがある)
20. Google Cloud Google Cloud 20 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd kubectl apply -f ./my-job.yaml Job 1. ユーザが Job を kubectl apply する どんな時使う? • 過去の K8s リソースの動きの把握 (特定のPodコンテナ内で完結する問題以外ほとんど全て ) Kubernetes の監査ログ (Kubernetes のリソースをどう変えようとしたか?) LOG_ID("cloudaudit.googleapis.com/activity") もしくは LOG_ID("cloudaudit.googleapis.com/data_access") kube-apiserver が書き込んでいるので resource.type = "k8s_cluster" resource.labels にはクラスタを特定するラベル (location, project, cluster_name などがある)
21. Google Cloud Google Cloud 21 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd kubectl apply -f ./my-job.yaml Job 1. ユーザが Job を kubectl apply する どんな時使う? • 過去の K8s リソースの動きの把握 (特定のPodコンテナ内で完結する問題以外ほとんど全て ) Kubernetes の監査ログ (Kubernetes のリソースをどう変えようとしたか?) LOG_ID("cloudaudit.googleapis.com/activity") もしくは LOG_ID("cloudaudit.googleapis.com/data_access") kube-apiserver が書き込んでいるので resource.type = "k8s_cluster" resource.labels にはクラスタを特定するラベル (location, project, cluster_name などがある)
22. Google Cloud Google Cloud 22 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Job Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る コントロールプレーンログ (有効化の必要あり) resource.type = "k8s_control_plane_component" LOG_ID("container.googleapis.com/controller-manager") など
23. Google Cloud Google Cloud 23 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Job Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る コントロールプレーンログ (有効化の必要あり) resource.type = "k8s_control_plane_component" LOG_ID("container.googleapis.com/controller-manager") など
24. Google Cloud Google Cloud 24 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Job Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る コントロールプレーンログ (有効化の必要あり) resource.type = "k8s_control_plane_component" LOG_ID("container.googleapis.com/controller-manager") など
25. Google Cloud Google Cloud 25 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Job Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る コントロールプレーンログ (有効化の必要あり) resource.type = "k8s_control_plane_component" LOG_ID("container.googleapis.com/controller-manager") など どんな時使う? • スケジューラやコントローラの問題が被 疑される時
26. Google Cloud Google Cloud 26 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod binding 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける イベントログ resource.type = "k8s_pod" OR "k8s_node" OR "k8s_cluster" LOG_ID("events") resource はレポート元ではなく、イベントが紐づくリソースの resource が紐づ く。 Pod, Node 以外は k8s_cluster が紐づく
27. Google Cloud イベントログ resource.type = "k8s_pod" OR "k8s_node" OR "k8s_cluster" LOG_ID("events") イベントログのresourceはレポート元ではなくてイベントが紐づくリソースに対して resourceが紐づく。 Pod, Node以外は k8s_clusterがタイプ紐づく Google Cloud 27 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod binding 1. ユーザが Job をkubectl applyする 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける
28. Google Cloud イベントログ resource.type = "k8s_pod" OR "k8s_node" OR "k8s_cluster" LOG_ID("events") イベントログのresourceはレポート元ではなくてイベントが紐づくリソースに対して resourceが紐づく。 Pod, Node以外は k8s_clusterがタイプ紐づく Google Cloud 28 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod binding 1. ユーザが Job をkubectl applyする 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける
29. Google Cloud Google Cloud 29 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod binding 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける どんな時使う? • 過去の K8s リソースの状態の把握 (監査ログと組み合わせて ) イベントログ resource.type = "k8s_pod" OR "k8s_node" OR "k8s_cluster" LOG_ID("events") resource はレポート元ではなく、イベントが紐づくリソースの resource が紐づ く。 Pod, Node 以外は k8s_cluster が紐づく
30. Google Cloud Google Cloud 30 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける 4. 対象のノードの kubelet が Pod の情報を受け取る K8s ノードログ resource.type = "k8s_node" LOG_ID("kubelet"),LOG_ID("container-runtime")...etc など GKE ノード上で systemd によって起動されている各種非コンテナワークロードのロ グが集まる。
31. Google Cloud Google Cloud 31 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける 4. 対象のノードの kubelet が Pod の情報を受け取る どんな時使う? • probe 系の問題調査 • コンテナがなぜか起動しない、消えたなど K8s ノードログ resource.type = "k8s_node" LOG_ID("kubelet"),LOG_ID("container-runtime")...etc など GKE ノード上で systemd によって起動されている各種非コンテナワークロードのロ グが集まる。
32. Google Cloud Google Cloud 32 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd Pod 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける 4. 対象のノードの kubelet が Pod の情報を受け取る どんな時使う? • probe 系の問題調査 • コンテナがなぜか起動しない、消えたなど K8s ノードログ resource.type = "k8s_node" LOG_ID("kubelet"),LOG_ID("container-runtime")...etc など GKE ノード上で systemd によって起動されている各種非コンテナワークロードのロ グが集まる。
33. Google Cloud Google Cloud 33 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける 4. 対象のノードの kubelet が Pod の情報を受け取る 5. containerd に指示してコンテナを作る コンテナ作って ! コンテナ K8s コンテナログ resource.type = "k8s_container" LOG_ID("stdout") もしくは、LOG_ID("stderr") おなじみのログ。kubectl logsで見れるものと基本的には同じもの
34. Google Cloud Google Cloud 34 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける 4. 対象のノードの kubelet が Pod の情報を受け取る 5. containerd に指示してコンテナを作る コンテナ作って ! コンテナ K8s コンテナログ resource.type = "k8s_container" LOG_ID("stdout") もしくは、LOG_ID("stderr") おなじみのログ。kubectl logsで見れるものと基本的には同じもの
35. Google Cloud Google Cloud 35 GKE で Job が動くまで (ログ視点) コントロールプレーン クラスタの存在する Project kube-apiserver kube-controller-manager kube-scheduler kubelet containerd 1. ユーザが Job を kubectl apply する 2. JobController が Pod を作る 3. kube-scheduler が Podに ノードを紐づける 4. 対象のノードの kubelet が Pod の情報を受け取る 5. containerd に指示してコンテナを作る コンテナ作って ! コンテナ どんな時使う? • アプリケーションの問題調査 K8s コンテナログ resource.type = "k8s_container" LOG_ID("stdout") もしくは、LOG_ID("stderr") おなじみのログ。kubectl logs で見れるものと基本的には同じもの
36. Google Cloud Proprietary & Confidential 36 この種類のログ それぞれのログフィルタ 覚えてられない ですよね。 仮にフィルタが書けても、 この量のログ 見切れない ですよね。
37. Google Cloud Kubernetes の障害調査のためのログビューア (Kubernetes History Inspector) 豊富な可視化機能 Cloud Logging のログをリソースごとに自動整理。マニフェ ストの復元やタイムライン・グラフ化により、障害調査を劇的 に効率化する強力な OSS ログビューア。 開発元と公開コミュニティ 主に東京の Google Cloud サポートチームが実務の知見を 元に主導して開発。 OSSとして全世界に向けて公開中。 37 GoogleCloudPlatform/khi
38. Google Cloud docker run -p 127.0.0.1:8080:8080 gcr.io/kubernetes-history-inspector/release:latest docker コマンドさえあれば OK Cloud Shell で1コマンドで動く。手元の環境に docker コマン ドだけあれば大丈夫 ! クラスタの種類やログを選んで フォームを埋めるだけで自動的にログ収集 ユーザが選ぶログに応じ表示されるフォームを埋めると KHI がログフィルタを生成、ログを自動で収集・可視化 38 Kubernetes の障害調査のためのログビューア (Kubernetes History Inspector) GoogleCloudPlatform/khi
39. Google Cloud 39 デモ "Job が動くまでのログを見てみよう"
40. 40 まとめ • resource, logName を意識した ログフィルタを書こう • 活用のためにも resource, logName を把握してどんなログがある かを抑えると、 K8s の振る舞いの様々なポイントでログで確認できる = 障害発生時にどこ見ればいいのかわかりやすい • KHI を使えば眠っていた Cloud Logging 上のログをわかりやすい形 で様々な調査に活用できる ◦ しかもログを活用するので今日知った方も数日前に起きた問 題のトラブルシューティングから活用可能! GoogleCloudPlatform/khi https://github.com/GoogleCloudPlatform/khi Star us on GitHub!
41. 7 ⽉ 30 ⽇ (⽊)、 東京ビッグサイト 南展⽰棟‧会議棟 31 ⽇ (⾦) もっと詳しいログの話を聞きたい方は Google Cloud Next Tokyo へ 日々業務で活用しているサポート エンジニアが語る "詳解 Google Cloud のログ"
42. Thank you