Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ログから学ぶKubernetes

 ログから学ぶKubernetes

GoogleCloudPlatformJapan

February 20, 2025
Tweet

More Decks by GoogleCloudPlatformJapan

Other Decks in Business

Transcript

  1. 自己紹介 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)
  2. Kubernetes 利用者が一番最初に学ぶ事と言えば ...? $ kubectl apply -f my-deployment.yaml 1. ユーザが

    Deployment を作る 2. ReplicaSet ができる 3. Pod ができる Deployments | Kubernetes公式ドキュメント より引用 (CC-BY)
  3. 実際に起こっていることはもう少し複雑 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)
  4. この振る舞いをログで観察する 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の振る 舞いの観点で調査ができる、クラスタ上で動作するアプリ ケーションに依存しない汎用性の高い知識
  5. この振る舞いをログで観察する 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
  6. この振る舞いをログで観察する 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 機能で 監査ログとして記録される
  7. この振る舞いをログで観察する 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 では様々なリソースの更新を 各種コントローラが監視し、変更に応じてリソースを操作する ▶ これら操作はコントローラの ログとして出力される
  8. この振る舞いをログで観察する 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 など)
  9. 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 など) • 関係するコンポーネントに当たりをつけないとログフィルタは書けない • 最小限のクラスタで数分でも数千のログがあり、実際には膨大な量のログを分析 しなければならないが、ログは通常一覧性に乏しい • 構造化ログの様々なフィールドをそれぞれのログで読まないと 状態を理解できない
  10. Place Image Here Kubernetes History Inspector (KHI) • GoogleCloudPlatform Github

    組織配下 に 1/29 に公開したオープンソースな K8s に適したリッチなログビューア GoogleCloudPlatform/khi • Google Cloud のサポートチームで迅速か つ正確に GKE のトラブルシューティングが できるように開発されたツール • ログストレージ(現状では Cloud Logging のみ)からログを取得、 リソースごとのタイムラインやダイアグラムと して可視化 • ログから可視化するのでクラスタが既に消 えていても OK 、クラスタ内へのエージェン ト類の導入一切必要なし
  11. デモ中説明用スライド 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 クラスタの設定
  12. 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 を介して記録
  13. まとめ • ログからクラスタの振る舞いを説明できると様々な利点がある (問題収束後の調査、より深い K8s の理解...etc) • ログを元に Deployment からコンテナが起動するまでの振る舞いを確認

    した • KHI は Google Cloud のサポートチームが開発した、ログを元にクラスタ のリソースのタイムラインやダイアグラムを可視化してくれる OSS ツール • ログビューアなので、クラスタへのエージェント導入の必要がなく 、既に 消されているクラスタにも適用可能で、 docker さえあれば 1 コマンドで動 作可能 GoogleCloudPlatform/khi Now available on GitHub!