kubectlを使ったKubernetesトラブルシューティング
次に、高橋氏は実践的なケーススタディの前提として「小さな単位から問題を切り分け、段階的に原因を特定していく」という、トラブルシューティングの基本方針を説明した。具体的な手法としては、Podから始めてReplicaSet、Deployment、Serviceという順序で問題を洗い出すという。
また、高橋氏は仮説検証の重要性を強調し、「インフラやKubernetesに限らないが、多くの証拠を集め、それに基づいて仮説を立てて原因究明にあたることが重要」と述べた。
ここで、高橋氏は具体的なトラブルシューティングのデモケースを紹介した。このケースでは、Kubernetesの運用経験が非常に浅いエンジニアが、隣のチームから「hello-server」との通信障害について相談を受ける状況を想定している。リポジトリ管理がなされておらず、何から手をつけていいかわからない状態から原因特定を進めなければならないというケースだ。
こうした状況ではまず接続確認から行うが、このデモにおいてはkubectlを使ってPodを探すところから原因特定が行われた。「kubectl get」でネームスペースごとに分けられたPodを探し出すが、このとき「--all-namespaces」というオプションをつけることで効率的に全てのPodを調べることができる。
該当Podのステータス上でエラーが出ていると判明した場合、次は「kubectl describe」コマンドを使用して詳細を確認する。今回はPod内にあるEventsにnot foundの記載が見られたが、「このとき直接Podを修正するのではなく、Deploymentから修正していくことが必要」と高橋氏は指摘する。
次にDeploymentを「kubectl get」で調べると「hello-server」が見つかったため、「kubectl edit」コマンドを使ってこのDeploymentの修正を行う。最後に改めて「kubectl get」し、ステータスがRunningになっていることを確認してPodが起動しているかを確認する。
接続確認は、まず接続先のドメイン名の確認から行う。接続先が「hello-server.svc.cluster.local」である場合、Kubernetesクラスター内のサービス間通信用ドメインである「.svc.cluster.local」を使用しているとわかる。通常、このドメインは外部からのアクセスが不可能であるため、「kubectl port-forward」コマンドを使用してアクセスを行う。
サービスは利用可能だがレスポンスがないという場合はPodのログを確認し、特にエラーが見られなければ「kubectl describe service」でサービスの設定をチェックする。設定ミスなどがあれば「kubectl edit」コマンドでサービスの設定変更・適用を行い、最終的に「curl localhost」でhello-serverに接続できることを確認して終了となる。
今回はSelectorの設定ミスが原因というシナリオだったが、高橋氏は「スペルミスなどの些細なミスや予想外のミスで障害が起こることはよくある話」と語る。そのため「マニフェストファイルをGitHubなどのリポジトリで管理して、環境に適用した変更の差分を確認することで問題を発見しやすくする、というような運用が望ましい」と改善案を示した。
実際のトラブルシューティングではより複雑な問題であるケースが多い。オープンソースソフトウェアの場合はデバッグが難しいため、kubectlでできることには限りがある。ダッシュボードやメトリクスを通じて「外側から何が起こったか」を把握できるような仕組みを構築することも重要だ。
オブザーバビリティを高めてトラブルに迅速に対応しよう
そこで話題は、Kubernetesを使う際のインフラトラブルシューティングの難しさや、オブザーバビリティ（可観測性）の重要性についての話に移った。最新の環境においては、「1台のサーバーにすべてのアプリケーションを入れて解決する」というアプローチではトラブルへの対応が難しいため、オブザーバビリティを高めることで迅速な対応につなげることができるという。
可観測性を高めるには、ログに加えてMetrics（測定値の集合）、Traces（ユーザーないしアプリケーションの通信を追跡するための概念）という3種類の主要シグナルが挙げられる。これらを追うことで、「どの処理にどれくらい時間をかけているかが具体的に分かるので、ボトルネックになっている箇所を割り出せる」とメリットを説明した。
講演の最後に、高橋氏は「kubectlで陥りやすい罠」を挙げた。これはネームスペースで区切られているリソースについての問題で、Kubernetesのリソースはネームスペースを指定して作られるため「ネームスペースを指定しない限り、自分が探したいリソースを見つけられない」という。
高橋氏はこの問題について、「kubectlの実行自体はできるが、デフォルトネームスペースの中に自分が作ったPodが見つからないというケースがよくある」としたうえで、「トラブルシューティングの際は、なるべくネームスペースを指定した方が確実だ」と注意喚起した。
「Kubernetesがどんな環境にもフィットするというわけではない」という高橋氏。講演の最後に、「Dockerだけで十分という環境もあり得ると思っているが、Kubernetesはとても面白いので、皆さんで一緒にKubernetes楽しめたらいいなと思っている」と締めた。
