ログから学ぶ Kubernetes ~ Deployment がコンテナを動かすまで ~ Kubernetes Novice Tokyo #36 セッション枠1 (と Kubernetes History Inspector の紹介)

自己紹介 Kakeru Ishii Google Cloud Technical Solutions Engineer Google Cloud のサポート内のエンジニア Google Kubernetes Engine (GKE) / Google Distributed Cloud (GDC) 等を中心としたトラブ ルシューティングを主にやっています。 今日の話で後ほど出てくる OSS ログビューア Kubernetes History Inspectorの作者 (GoogleCloudPlatform/khi on GitHub)

Kubernetes 利用者が一番最初に学ぶ事と言えば ...? $ kubectl apply -f my-deployment.yaml 1. ユーザが Deployment を作る 2. ReplicaSet ができる 3. Pod ができる Deployments | Kubernetes公式ドキュメント より引用 (CC-BY)

実際に起こっていることはもう少し複雑 1. ユーザが Deployment を作る 2. ReplicaSet ができる 3. Pod ができる 1-1. ユーザが kube-apiserver を介して Deployment リソースを作成 1-2. deployment-controller が Deployment の新規作成を検知して、 kube-apiserver を介して ReplicaSet リソースを作成 2-1. replicaset-controller が ReplicaSet の新規作成を検知して kube-apiserver 介して Pod を作成 3-1. kube-scheduler がどの Node にも紐づいていない Pod を検知して kube-apiserver を介して Binding サブリソースを作成 3-2. kubelet が自分のノードに紐づいている Pod を検知して、 　　CRI に Pod のサンドボックス、コンテナの実行をリクエスト 3-3. kubelet が各コンテナや Pod の状態を kube-apiserver を介して記録 $ kubectl apply -f my-deployment.yaml Deployments | Kubernetes公式ドキュメント より引用 (CC-BY)

この振る舞いをログで観察する 1. ユーザが Deployment を作る 2. ReplicaSet ができる 3. Pod ができる 1-1. ユーザが kube-apiserver を介して Deployment リソースを作成 1-2. deployment-controller が Deployment の新規作成を検知して、 kube-apiserver を介して ReplicaSet リソースを作成 2-1. replicaset-controller が ReplicaSet の新規作成を検知して kube-apiserver 介して Pod を作成 3-1. kube-scheduler がどの Node にも紐づいていない Pod を検知して kube-apiserver を介して Binding サブリソースを作成 3-2. kubelet が自分のノードに紐づいている Pod を検知して、 　　CRI に Pod のサンドボックス、コンテナの実行をリクエスト 3-3. kubelet が各コンテナや Pod の状態を kube-apiserver を介して記録 $ kubectl apply -f my-deployment.yaml ログからこれらを観察したい ! ● 始めの操作とリソースの結果のみではなく 過程がよく理解でき、トラブル解決に強くなる ● 問題が起きた後自動的に解決してしまっても調査することが できて再発防止に努められる ● 上手く行っていた時と何故か動作しない時を比べて調査す ることができる ● 自分が詳しくないアプリケーションでも Kubernetesの振る 舞いの観点で調査ができる、クラスタ上で動作するアプリ ケーションに依存しない汎用性の高い知識

この振る舞いをログで観察する 1. ユーザが Deployment を作る 2. ReplicaSet ができる 3. Pod ができる 1-1. ユーザが kube-apiserver を介して Deployment リソースを作成 1-2. deployment-controller が Deployment の新規作成を検知して、 kube-apiserver を介して ReplicaSet リソースを作成 2-1. replicaset-controller が ReplicaSet の新規作成を検知して kube-apiserver 介して Pod を作成 3-1. kube-scheduler がどの Node にも紐づいていない Pod を検知して kube-apiserver を介して Binding サブリソースを作成 3-2. kubelet が自分のノードに紐づいている Pod を検知して、 　　CRI に Pod のサンドボックス、コンテナの実行をリクエスト 3-3. kubelet が各コンテナや Pod の状態を kube-apiserver を介して記録 $ kubectl apply -f my-deployment.yaml

この振る舞いをログで観察する 1. ユーザが Deployment を作る 2. ReplicaSet ができる 3. Pod ができる 1-1. ユーザが kube-apiserver を介して Deployment リソースを作成 1-2. deployment-controller が Deployment の新規作成を検知して、 kube-apiserver を介して ReplicaSet リソースを作成 2-1. replicaset-controller が ReplicaSet の新規作成を検知して kube-apiserver 介して Pod を作成 3-1. kube-scheduler がどの Node にも紐づいていない Pod を検知して kube-apiserver を介して Binding サブリソースを作成 3-2. kubelet が自分のノードに紐づいている Pod を検知して、 　　CRI に Pod のサンドボックス、コンテナの実行をリクエスト 3-3. kubelet が各コンテナや Pod の状態を kube-apiserver を介して記録 $ kubectl apply -f my-deployment.yaml Kubernetes では全てのリソースへの操作が kube-apiserver を介して行われる ▶ これら操作は kube-apiserver の Audit 機能で 監査ログとして記録される

この振る舞いをログで観察する 1. ユーザが Deployment を作る 2. ReplicaSet ができる 3. Pod ができる 1-1. ユーザが kube-apiserver を介して Deployment リソースを作成 1-2. deployment-controller が Deployment の新規作成を検知して、 kube-apiserver を介して ReplicaSet リソースを作成 2-1. replicaset-controller が ReplicaSet の新規作成を検知して kube-apiserver 介して Pod を作成 3-1. kube-scheduler がどの Node にも紐づいていない Pod を検知して kube-apiserver を介して Binding サブリソースを作成 3-2. kubelet が自分のノードに紐づいている Pod を検知して、 　　CRI に Pod のサンドボックス、コンテナの実行をリクエスト 3-3. kubelet が各コンテナや Pod の状態を kube-apiserver を介して記録 $ kubectl apply -f my-deployment.yaml Kubernetes では全てのリソースへの操作が kube-apiserver を介して行われる ▶ これら操作は kube-apiserver の Audit 機能で 監査ログとして記録される Kubernetes では様々なリソースの更新を 各種コントローラが監視し、変更に応じてリソースを操作する ▶ これら操作はコントローラの ログとして出力される

この振る舞いをログで観察する 1. ユーザが Deployment を作る 2. ReplicaSet ができる 3. Pod ができる 1-1. ユーザが kube-apiserver を介して Deployment リソースを作成 1-2. deployment-controller が Deployment の新規作成を検知して、 kube-apiserver を介して ReplicaSet リソースを作成 2-1. replicaset-controller が ReplicaSet の新規作成を検知して kube-apiserver 介して Pod を作成 3-1. kube-scheduler がどの Node にも紐づいていない Pod を検知して kube-apiserver を介して Binding サブリソースを作成 3-2. kubelet が自分のノードに紐づいている Pod を検知して、 　　CRI に Pod のサンドボックス、コンテナの実行をリクエスト 3-3. kubelet が各コンテナや Pod の状態を kube-apiserver を介して記録 $ kubectl apply -f my-deployment.yaml Kubernetes では全てのリソースへの操作が kube-apiserver を介して行われる ▶ これら操作は kube-apiserver の Audit 機能で 監査ログとして記録される Kubernetes では様々なリソースの更新を 各種コントローラが監視し、変更に応じてリソースを操作する ▶ これら操作はコントローラの ログとして出力される ノード上の要素もそれぞれノード上で Pod が示された状態 で稼働するように監視し続け、必要に応じて実際のコンテナ を操作する ▶ これら操作はノード上にそれぞれの要素から ログとして出力される ( journald など)

Google Kubernetes Engine (GKE)でこれらログを観察してみる GKE ではこれらは全て Cloud Logging 上に連携される (一部ログは環境により手動で有効にする必要があります [1] ) →理想的には ログフィルタが書ければ Kubernetes の細かな動きがわかるはず ...? [1] https://cloud.google.com/kubernetes-engine/docs/concepts/about-logs?hl=ja#available-logs Kubernetes の振る舞いの十分な情報を含むログが有ること 　　　　　　　　　　　　　　 ≠ Kubernetes の振る舞いをログから理解できる Kubernetes では全てのリソースへの操作が kube-apiserver を介して行われる ▶ これら操作は kube-apiserver の Audit 機能で 監査ログとして記録される Kubernetes では様々なリソースの更新を 各種コントローラが監視し、変更に応じてリソースを操作する ▶ これら操作はコントローラの ログとして出力される ノード上の要素もそれぞれノード上で Pod が示された状態 で稼働するように監視し続け、必要に応じて実際のコンテナ を操作する ▶ これら操作はノード上にそれぞれの要素から ログとして出力される ( journald など) ● 関係するコンポーネントに当たりをつけないとログフィルタは書けない ● 最小限のクラスタで数分でも数千のログがあり、実際には膨大な量のログを分析 しなければならないが、ログは通常一覧性に乏しい ● 構造化ログの様々なフィールドをそれぞれのログで読まないと 状態を理解できない

Place Image Here Kubernetes History Inspector (KHI) ● GoogleCloudPlatform Github 組織配下 に 1/29 に公開したオープンソースな K8s に適したリッチなログビューア GoogleCloudPlatform/khi ● Google Cloud のサポートチームで迅速か つ正確に GKE のトラブルシューティングが できるように開発されたツール ● ログストレージ(現状では Cloud Logging のみ)からログを取得、 リソースごとのタイムラインやダイアグラムと して可視化 ● ログから可視化するのでクラスタが既に消 えていても OK 、クラスタ内へのエージェン ト類の導入一切必要なし

Deployment の振る舞いを見るデモ

デモ中説明用スライド KHIの動かし方 1. Cloud Shell を開く a. https://shell.cloud.google.com/ 2. kubectl apply -f deployment.yaml (マニフェストはこちらから : Deployments | Kubernetes) 3. docker run -p 127.0.0.1:8080:8080 asia.gcr.io/kubernetes-history-inspector/release:latest 4. 対象のクラスタのログを KHI で見る https://github.com/GoogleCloudPlatform/khi/blob/main/docs/ja/images/guide-timeline-screen.png クラスタの設定

KHI で確認できた振る舞い $ kubectl apply -f my-deployment.yaml 1. ユーザが Deployment を作る 2. ReplicaSet ができる 3. Pod ができる 1-1. ユーザが kube-apiserver を介して Deployment リソースを作成 1-2. deployment-controller が Deployment の新規作成を検知して、 kube-apiserver を介して ReplicaSet リソースを作成 2-1. replicaset-controller が ReplicaSet の新規作成を検知して kube-apiserver 介して Pod を作成 3-1. kube-scheduler がどの Node にも紐づいていない Pod を検知して kube-apiserver を介して Binding サブリソースを作成 3-2. kubelet が自分のノードに紐づいている Pod を検知して、 　　CRI に Pod のサンドボックス、コンテナの実行をリクエスト 3-3. kubelet が各コンテナや Pod の状態を kube-apiserver を介して記録

まとめ ● ログからクラスタの振る舞いを説明できると様々な利点がある (問題収束後の調査、より深い K8s の理解...etc) ● ログを元に Deployment からコンテナが起動するまでの振る舞いを確認 した ● KHI は Google Cloud のサポートチームが開発した、ログを元にクラスタ のリソースのタイムラインやダイアグラムを可視化してくれる OSS ツール ● ログビューアなので、クラスタへのエージェント導入の必要がなく 、既に 消されているクラスタにも適用可能で、 docker さえあれば 1 コマンドで動 作可能 GoogleCloudPlatform/khi Now available on GitHub!