Kubernetesは怖くない！開発者のためのインフラトラブルシューティング入門

Kubernetesが導入される企業が徐々に増える中で、「これまでインフラレイヤに触ったことがないのにKubernetesを触る必要が出てきた」という開発者の方もいるのではないかと思います。そういった方にむけて「Kubernetesとはなにか」からはじまり、Kubernetesに乗せたアプリケーションが動かなくなって困ったときのトラブルシューティング方法を紹介するスライドです。
残念ながら資料内で動画を再生することができないためターミナル画面の画像のみになっているスライドがあります。

1. Kubernetesは怖くない！ 開発者のための インフラトラブルシューティング 入 門 高 橋あおい
2. 自己 紹介 ๏ 高 橋あおい • 大手 メーカーでソフトウェアエンジニアとしてキャリアを積んだ後、前 職はサイボウズ株式会社でSREを、現職では教育系アプリケーションの SREに従事 • 趣味：漫画を描く（まんがではじめるKubernetesなど） • X（旧twitter）アカウント:_a 0 i
3. 近々Kubernetesのトラブルシューティング 本を翔泳社から出します！お楽しみに！ https://www.amazon.co.jp/dp/ 4 7 9 8 1 8 3 9 6 2 Ϋόωςε 入門 ͭ͘ ͬͯɺ ͯ͠ɺ ͯ͠ Ϳ յ ௚ 学 ߴڮ͓͍͋
   ஶ ޒेཛྷ
   ҁ
   ؂म Kubernetes ๛෋ͳϚϯΨͱ Π ϥε τͰ ͸͡ΊͯͰ΋ ݟͯΘ͔Δ ʂ ͭ ͘ ỳ ͯ ỏ ɹ
   
   ͠ ͯ ỏ ɹ
   
   ͠ ͯ ֶ Ϳ ೖ ໳ ௚ ߴ ڮ ͋ ͓ ͍
   ஶ ޒ े ཛྷ
   ҁ
   ؂ म Kubernetes Ϋόωςε յ ,VCFSOFUFTΫϥελΛͭ͘ ͬͯɺ յ͢ ؆୯ϞχλϦϯά༻γεςϜΛͭ͘ Δ 00.LJMMFEΛൃੜͤͯ͞ɺ ௚͢ LVCFDUM Ͱσόοά͢Δ...and more! ಈ ͔ ͳ ͘ ͯ ΋ ỏ ΋ ͏ ා ͘ ͳ ͍ τ ϥ ϒ ϧ γ ỿ ồ ς ỹ ϯ ά Λ ମ ݧ ͠ ͳ ͕ Β ֶ Ϳ ࣮ ફ త ೖ ໳ ॻ Ố
4. 目 次 ๏怖くなくなるKubernetes • Kubernetesの特徴を知る • Kubernetesのアーキテクチャーを知る • 何が起きているか知る 方 法を知る ๏【デモ】実践！トラブルシューティング
5. 今 日 はこういう話はしません ๏Dockerとは何か、コンテナとは何か ๏Kubernetesに関する細かなTips • 安全にアプリケーションを運 用 する 方 法や関連するKubernetesの機能 など
6. このセッションを通して ๏Kubernetesが怖くなくなるといいな • 詳しく理解する必要はないです、なんとなくわかればOK！ • トラブルシューティングのやり 方 の参考になれば • インフラだから特別なポイント、アプリケーションのデバッグと変わらないポ イント
7. ා͘ͳ͘ͳΔ
   ,VCFSOFUFT
8. Kubernetesが怖い？ ๏わからなくて怖い ๏ 目 に 見 えないから怖い ๏何が起きてるかわからなくて怖い
9. 知ることで怖さを減らす ๏Kubernetesの特徴を知る ๏Kubernetesのアーキテクチャーを知る ๏何が起きているか知る 方 法を知る
10. Kubernetesの特徴を知る
11. Kubernetesとは ๏open-source system for automating deployment, scaling, and management of containerized applications.※ ๏コンテナ化されたアプリケーションのデプロイ、スケーリング、お よび管理を 自 動化するためのオープンソースシステム ※Kubernetes公式サイトより引 用 (https://kubernetes.io/)
12. Kubernetesの特徴 1 . 障害発 生 時に、各コンテナの設定 ・ 復旧を簡単にする 2 . コンテナの仕様の管理を簡単にする 3 . 複数台のサーバを利 用 してコンテナを起動したいとき、最適な起動 先を決定を簡単にする
13. 1. 障害発 生 時に、各コンテナの設定 ・ 復旧を簡単にする ๏障害から 自 動復旧するよう試みる Reconciliation Loop といいます
14. 2. コンテナの仕様の管理を簡単にする ๏ファイルを利 用 して各設定を管理することができる マニフェストファイルといい YAMLで書くことが多いです
15. 3. 複数台のサーバを利 用 してコンテナを起動したいとき、 最適な起動先の決定を簡単にする ๏KubernetesのAPIで抽象化されており、サーバー固有の設定を知る 必要がない ๏コンテナを起動するマシンについての 　 情報は書く必要がない apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.24.0 ports: - containerPort: 80 resources: requests: memory: 100Mi コンテナイメージを指定する だけ Podというリソースを 使ってコンテナを起動
16. これらの特徴のおかげで ๏開発者でもアプリケーションのデプロイが楽にできるようになっ た！ ๏ 一方 、いままで関わってきていない領域の知識も必要に… 大 変なポイント
17. Kubernetesの アーキテクチャーを知る
18. Kubernetesのアーキテクチャ
19. Kubernetesのアーキテクチャ Database API server
20. 何が起きているか 知る 方 法を知る
21. 何が起きているか把握することで怖くなくなる ๏これまでの「何が起きているか」を把握する難しさ • 「OSやアプリケーションによってログの保存場所が違う」 • systemd?journalctl? • そもそも何が動いているの？ • さまざまなコマンドを覚える必要がある • ps, top …
22. 何が起きているか把握することで怖くなくなる ๏Kubernetesで 見 る場所/ 見方 が集約される • Kubernetesのログ • KubernetesのEvents
23. Kubernetesのログ ๏Kubernetesのコンテナのログはkubectlというツールを使うことで 見 ることができる • kubectlで全てのコンテナのログが 見 れる ๏ただしkubectlで 見 れるログは永久保存ではない • 永久保存するための転送先は環境それぞれなので、転送先のログの 見方 は覚える必要がある
24. KubernetesのEvents ๏Kubernetesのリソースごとに何が起こったか 見 ることができる
25. kubectlを使えるようになろう ๏kube-apiserverにアクセスするためのコマンドラインインター フェース ๏kubectlでアクセスしたその先に全てがある（といっても過 言 ではな い） ๏公式から提供されているツール • 他にもk 9 sなど便利なツールはたくさんありますが、今回は基礎的な kubectlの使い 方 のみ説明する
26. これだけ覚えて帰ってください ๏kubectl get <リソース名> • リソースの情報を取得するコマンド ๏kubectl describe <リソース名> • リソースの詳細を表 示 するコマンド ๏kubectl logs <Pod名> • ログを取得するコマンド 困ったらchatGPTに聞こう！ リソースとは Kubenetesで扱う オブジェクトのこと
27. ʲσϞʳ
    ࣮ફʂτϥϒϧγϡʔςΟϯά
28. Pod/ReplicaSet/Deployment ๏Pod: コンテナを起動するための最 小 の単位、リソース ๏ReplicaSet: Podを複数管理するためのリソース ๏Deployment: ReplicaSetを複数管理するためのリソース
29. Service ๏Deploymentで作成した複数Podへのアクセスを適切にルーティング してもらうために、Serviceというリソースを利 用
30. トラブルシューティングのコツ1：狭い範囲から調査していく
31. トラブルシューティングのコツ2：仮説検証を繰り返す ๏これはインフラのトラブルシューティングに限った話ではない ๏XXではないか？→確かめる ๏仮説を組み 立 てるために証拠をたくさん集める
32. 動かしてみよう Kubernetes
33. リポジトリの紹介 ๏皆様の 手 元で再現させることができます ๏https://github.com/aoi 1 /developers-summit- 2 0 2 4
34. これまでの知識を使ってトラブルシューティング実演
35. ๏動画1
36. これまでの知識を使ってトラブルシューティング実演
38. 実際にはより複雑な問題であるケースの 方 が多い ๏しかも 自 分たちで書いたコードではないことが多い • デバッグ 用 のコードを 入 れ込めない ๏kubectlでできることは限りがあるので、あらかじめ情報を取得して おくことが鍵となる • ログがローテートされてしまう、Eventsがローテートされてしまう etc … ๏「オブザーバビリティ（可観測性）」を向上させよう
39. Kubernetesは怖くない！ ๏けれど難しくなっている部分があるのは事実 ๏ 一 緒に旅を楽しみましょう！
40. "QQFOEJY
41. ローカルでKubernetesクラスタをつくろう ๏kindを使おう • https://kind.sigs.k 8 s.io/ • macOS： brew install kind • goがインストールされていれば：go install sigs.k 8 s.io/kind@v 0 . 2 0 . 0
42. ローカルでKubernetesクラスタをつくろう ๏コマンドを 一行 実 行 するだけで良い • kind create cluster
43. τϥϒϧγϡʔςΟϯάΛ
    ॿ͚ΔΦϒβʔόϏϦςΟ
44. （再）インフラのトラブルシューティングの難しさ • 何が起きているか把握することが難しい • 様々なログディレクトリ、ツール • デバッグ 用 のコードを 入 れられないことがほとんど
45. Kubernetesによって解決されることもあるが… ๏実際は難しくなっていることがほとんど • 昔）サーバーにログインしてログを参照する、psコマンドを実 行 する • Kubernetes）コンテナにログインしてもshellがない、何もできない、 ログはローテートされてクラスタから消えている
46. そこでオブザーバビリティ ๏ 日 本語では「可観測性」 ๏「外部からシステムがどれくらい観測可能か」という指標 • 指標とは…Logs、Metrics、Traces、Pro fi les、Dumps ๏可観測になると… • コンテナがどれくらいリソースを使っているかがわかる • 通信の経路がわかる
47. 3つのプライマリシグナル ๏Logs ๏Metrics • メトリクスは測定値の集合です。測定値を利 用 した統計的な処理をした り、傾向を 見 たい場合に活 用 できます ๏Traces • ユーザーないしアプリケーションの通信を追跡するための概念
48. Traces
49. モニタリング ๏ダッシュボード • 収集したメトリクスやログなどを 見 える状態にする ๏アラート • 収集したメトリクスやログなどからシステムの異常を知らせる
50. kubectlでよくハマる罠 ๏--namespaceでnamespaceを指定していない • kubectl get podしても 見 つからない→実は違うnamespaceにありまし た • —namespaceを指定しないとcon fi gで設定されているデフォルトの namespace内のリソースしか探しません