見出し画像

Kubernetes障害をChatGPTとGeminiに聞いたら、調査ではGemini、修正ではChatGPTが上だった

コバンのしらべノート

KubernetesのPodが、RunningなのにReadyにならない。

この障害をChatGPTとGeminiに同じ条件で見せたら、どちらが正確に原因へたどり着くのでしょうか。

最初は、Geminiのほうが上でした。

ところが、実測情報を追加して「では、どう直すか」まで聞くと、結果が逆転しました。

今回は、わざとReadiness Probeの設定を間違えたPodを作り、2つのAIに同じ質問を2段階で渡して比較しました。

※この記事は、検証用のローカルKubernetes環境で意図的に発生させた障害をもとにしています。実際の本番環境では、構成や影響範囲を確認してから操作する必要があります。


用意したのは「RunningなのにReadyにならないPod」

検証用Podでは、nginxコンテナに80番ポートを設定する一方、Readiness Probeの接続先を8080番にしました。

ports:
- containerPort: 80
  name: http

readinessProbe:
  httpGet:
    path: /
    port: 8080

Podの状態は、次のようになりました。

STATUS: Running
READY:  0/1
RESTARTS: 0

コンテナのプロセスは動いているため、PodのPhaseはRunningです。

しかし、Readiness Probeが失敗しているため、トラフィックを受け付けられる状態を示すReadyにはなりません。

Kubernetes公式ドキュメントでも、Readiness Probeはコンテナがトラフィックを受け付けられる状態かを判断するものと説明されています。

第1問は「この情報だけで、何を調べるか」

最初の質問では、原因を断定できるほどの情報をすべては渡さず、現在の状態から何を確認すべきかを答えてもらいました。

「2点：十分にできている」
「1点：一部できているが、不足や注意点がある」
「0点：できていない、または提案がない」

初動調査では、必要な情報を絞って優先順位を付けたGeminiが2点上回りました。

Geminiは、必要な確認項目を比較的短く整理し、次に取得すべき情報へ素早く進みました。

ChatGPTも大きく外してはいませんでしたが、可能性を慎重に広げたぶん、今回の検証では少し遠回りになりました。

ここまでの印象は、

「初動調査ならGeminiのほうが必要十分で速い」

というものでした。

実測すると、8080番への接続拒否が出ていた

次に、両方のAIが判断できるよう、同じPodから取得したkubectl describe podとkubectl get pod -o yamlの結果を追加しました。

イベントには、次のエラーが記録されていました。

Readiness probe failed:
Get "http://10.244.0.29:8080/":
dial tcp 10.244.0.29:8080: connect: connection refused

さらに、Podの定義ではコンテナポートが80、Readiness Probeが8080になっていました。

Container Port: 80/TCP
Readiness: http-get http://:8080/

これで、現在Ready=Falseになっている直接原因は、Readiness Probeが8080番へ接続し、拒否されていることだと特定できます。

原因特定は、どちらも正解

第2問では、原因、証拠、修正方法、確認コマンド、影響、不要な調査まで回答してもらいました。

原因については、ChatGPTもGeminiも正解でした。

  • nginx側の設定は80番

  • Readiness Probeは8080番へ接続

  • 8080番ではconnection refused

  • Probeが失敗し続けるため、RunningでもReadyにはならない

修正案も、Readiness Probeの接続先を80番、または名前付きポートhttpへ変更するという点で一致しました。

ここまでは、ほぼ互角です。

差が出たのは、実際の修正操作に進む場面でした。

Geminiは「単独Pod」と断定した

Geminiは、提示情報にownerReferencesの記載がないことから、対象を単独Podと判断しました。

そして、修正済みマニフェストを用意し、次のように置き換える案を提示しました。

kubectl replace -f fix-pod.yaml --force

原因と修正方針は合っています。

ただし、今回AIへ渡したYAMLは、原因分析に必要な部分を抜粋したものでした。

抜粋にownerReferencesがないだけでは、実際の完全なYAMLにも存在しないとまでは断定できません。

さらにGeminiは、kubectl replace --forceによる削除と再作成を「アトミック」と表現しました。

実際には、既存Podを削除してから新しいPodを作るため、Podが存在しない時間が発生します。無停止の置換ではありません。

ChatGPTは、削除前に所有元の確認を入れた

ChatGPTは、提示されたYAMLが抜粋であることを拾いました。

そのうえで、Podを削除・再作成する前に、所有元を確認するコマンドを提案しました。

kubectl get pod nginx-readiness-error \
  -n note-ai-readiness-test \
  -o jsonpath='{.metadata.ownerReferences}{"\n"}'

出力が空なら、少なくともKubernetesのownerReferences上はコントローラーに所有されていないと判断できます。

一方、所有元が存在する場合は、Podだけを置き換えても、コントローラーが古い設定でPodを再生成する可能性があります。

ChatGPTは、その場合には強制置換を止め、まず所有元を確認すべきだと説明しました。

障害対応では、原因を当てるだけでなく、

「その修正を、今の対象へ実行してよいか」

まで判断する必要があります。

この点で、ChatGPTのほうが安全でした。

「80番なら必ず成功する」とも断定しなかった

もう一つ差が出たのは、containerPort: 80の扱いです。

Geminiは、nginxが80番ポートで稼働しているものとして説明しました。

しかし、containerPort: 80はポートを宣言しているだけで、アプリケーションのプロセスが実際に80番で待ち受けていることを、それ自体で保証する設定ではありません。

ChatGPTは、この点を明確に区別しました。

今回、8080番へのProbeが失敗していることは断定できます。

一方で、80番へ変更したあと本当に成功するかは、修正後にREADY 1/1になることを実測して確認する必要があります。

細かい違いですが、インフラ障害の回答としては重要です。

第2問ではChatGPTが逆転した

「2点：十分にできている」
「1点：一部できているが、不足や注意点がある」
「0点：できていない、または提案がない」

第1問と合わせると、

  • Gemini：30点

  • ChatGPT：31点

最終結果は、ChatGPTが1点差で上でした。

ただし、「ChatGPTのほうが全面的に優秀」という結果ではありません。

今回見えたのは、得意な場面の違いです。

今回の結論

Geminiは、初期情報から次に必要な調査を絞る場面で、簡潔さと速さがありました。

ChatGPTは、原因が見えたあとの修正フェーズで、情報の抜粋、Podの変更制限、所有元、再作成の影響まで慎重に確認しました。

まとめると、

  • 初動調査：Geminiが優勢

  • 原因特定：ほぼ互角

  • 修正手順の安全性：ChatGPTが優勢

  • 総合：ChatGPTが1点差で上

という結果です。

AIへ障害対応を相談するとき、最初から一つの長い質問ですべてを任せるより、

  1. 現状から必要な情報を洗い出す

  2. 実測結果を追加する

  3. 原因と証拠を分ける

  4. 修正前に影響と対象を確認する

という段階に分けたほうが、回答の違いも危険な断定も見つけやすくなります。

今回の比較でいちばん印象に残ったのは、原因を当てた瞬間ではありません。

直し方を聞いたところで、2つのAIの差が見えたことでした。

関連記事

同じ質問や作業でも、AIによって答え方や得意な場面は変わります。ほかのAI比較・検証記事も公開しています。

同じ指示なのに4分と1時間。ChatGPTとAntigravityにWebアプリを作らせてみた

同じ指示からWebアプリを作らせ、完成までの時間や進め方の違いを比較しました。

AIにPCトラブルを任せたら、便利すぎて少し怖くなった話

PCトラブルの解決をAIに任せて感じた便利さと、回答をそのまま信じる危険性をまとめています。

参考・出典


いいなと思ったら応援しよう！

コバンのしらべノート 読んでくださってありがとうございます。 応援いただけたら、次の記事を書く励みになります。