【ツール活用｜初心者向け】Kubernetesでトラブルシューティングを劇的に効率化！エフェメラルコンテナ入門

はじめに

Kubernetes (K8s) 環境でアプリケーションが動かなくなった時、原因を特定するのは一苦労ですよね。特に、セキュリティのために最小限のツールしか含まれていないコンテナ（DistrolessやScratchベースのイメージ）を使っている場合、デバッグ用のツールを後から追加するのはさらに困難です。そんな時に役立つのが「エフェメラルコンテナ」です。エフェメラルコンテナを使えば、本番環境のセキュリティを維持したまま、必要な時だけデバッグ用のコンテナを起動して、Pod内の問題を調査できます。

エフェメラルコンテナとは？

エフェメラルコンテナは、Kubernetes 1.18から導入された機能で、既存のPodに一時的にアタッチしてデバッグを行うためのコンテナです。通常のコンテナとは異なり、Podのライフサイクルとは独立して管理され、デバッグが終われば削除されます。

主な特徴は以下の通りです。

一時的な利用: デバッグ目的でのみ使用され、デバッグ終了後は自動的に削除されます。
セキュリティの維持: 本番環境のコンテナイメージにはデバッグツールを含めず、エフェメラルコンテナで必要なツールを提供することで、セキュリティリスクを低減します。
`kubectl debug` コマンド: エフェメラルコンテナの作成とアタッチは、`kubectl debug` コマンドを使って簡単に行えます。

なぜエフェメラルコンテナが重要なのか？

従来のデバッグ方法では、問題が発生したPodのコンテナイメージにデバッグツールを追加したり、一時的にシェルを起動できるように変更したりする必要がありました。これは、以下のような問題を引き起こす可能性がありました。

セキュリティリスクの増大: デバッグツールが増えることで、攻撃対象が増加します。
イメージ管理の複雑化: デバッグ用に別イメージを作成・管理する手間が発生します。
本番環境への影響: コンテナの再起動やイメージの変更が、一時的なサービス停止につながる可能性があります。

エフェメラルコンテナは、これらの課題を解決し、安全かつ効率的なトラブルシューティングを可能にします。

エフェメラルコンテナの使い方 (`kubectl debug`)

エフェメラルコンテナを利用するには、`kubectl debug` コマンドを使用します。基本的な使い方は以下の通りです。

`kubectl debug -it –image= –target=`

``: デバッグしたいPodの名前を指定します。
`–image=`: デバッグに使用するイメージを指定します。例えば、`busybox` や `ubuntu` など、シェルやネットワークツールが含まれているイメージを選びます。
`–target=`: Pod内に複数のコンテナがある場合、どのコンテナのプロセス名前空間を共有するかを指定します。指定しない場合は、Podの最初のコンテナのプロセス名前空間が共有されます。

たとえば、`my-app-pod` という名前のPodで、`my-app-container` というコンテナをデバッグしたい場合、以下のように実行します。

kubectl debug -it my-app-pod –image=busybox –target=my-app-container

このコマンドを実行すると、指定したPodにデバッグ用のコンテナが起動し、そのコンテナのシェルに接続されます。このシェルから、`netstat` や `ps` などのコマンドを使って、Pod内のプロセスやネットワークの状態を調査できます。

サンプルプログラム：ネットワークトラブルの調査

WebアプリケーションのPodで、外部からアクセスできないという問題が発生したとします。このPodはDistrolessイメージで構築されており、通常はシェルから確認できません。

まず、問題のPodの名前を確認します。

kubectl get pods

仮にPod名が `webapp-pod-xxxxx` だったとします。次に、`kubectl debug` コマンドで、デバッグ用のコンテナをアタッチします。ここでは、ネットワーク調査に便利な `nicolaka/netshoot` イメージを使用します。

デバッグ用のコンテナを起動し、シェルに接続する
kubectl debug -it webapp-pod-xxxxx –image=nicolaka/netshoot –target=webapp-container

コンテナにアタッチされたら、以下のようなコマンドでネットワークの状態を確認できます。

Pod内のIPアドレスとルーティングテーブルを確認
ip addr
ip route

外部のサービスへの疎通確認 (例: Google DNS)
ping 8.8.8.8

指定したポートが開いているか確認 (例: PodがListenしているポート)
nc -zv <ポート番号>

もし、Podが外部のデータベースに接続できないという問題であれば、データベースのIPアドレスやポートを指定して `nc` コマンドで接続を試みることができます。

コード例 (デバッグコンテナ内での実行)

!/bin/bash

現在のPodのIPアドレスを表示
echo “Pod IP Address: $(hostname -i)”

デフォルトゲートウェイを確認
echo “Default Gateway:”
ip route show default

外部DNSサーバー (8.8.8.8) への疎通確認
echo “Pinging 8.8.8.8…”
ping -c 4 8.8.8.8

アプリケーションがListenしているポート (例: 8080) が開いているか確認
実際のポート番号に合わせて変更してください
APP_PORT=8080
echo “Checking if port $APP_PORT is open on localhost…”
nc -zv localhost $APP_PORT

別のPod (例: Database Pod) への接続確認 (IPアドレスとポートを適宜変更)
DB_IP=”10.42.0.10″
DB_PORT=”5432″
echo “Checking connection to Database at $DB_IP:$DB_PORT…”
nc -zv $DB_IP $DB_PORT

echo “Debug session finished.”

このスクリプトは、デバッグコンテナ内で実行することで、Podのネットワーク状態を包括的に確認するのに役立ちます。

応用・注意点

`–target` オプションの重要性: Pod内に複数のコンテナがある場合、`–target` オプションでデバッグしたいコンテナのプロセス名前空間を共有させることが重要です。これにより、目的のコンテナで実行されているプロセスを `ps` コマンドなどで確認できます。
イメージの選択: デバッグには、`busybox`、`ubuntu`、`nicolaka/netshoot` のような、必要なツールが含まれたイメージを選択しましょう。
永続化しない: エフェメラルコンテナは一時的なものです。デバッグが終わったら、Podから自動的に削除されます。
Kubernetesのバージョン: エフェメラルコンテナは比較的新しい機能です。お使いのKubernetesクラスターが対応しているバージョン（1.18以降）であることを確認してください。
セキュリティコンテキスト: デバッグコンテナは、Podのセキュリティコンテキストの一部を引き継ぎますが、必ずしも本番コンテナと同じ権限で実行されるとは限りません。必要に応じて、デバッグコンテナの権限を調整する必要がある場合もあります。

エフェメラルコンテナを使いこなせば、Kubernetes環境でのトラブルシューティングが格段に楽になります。ぜひ、日々の運用に活用してみてください。