はじめに：なぜこれが必要なのか？

EKSクラスタを構築した際、AWSコンソール上のステータスが Active となったとしても、Kubernetesとしてのネットワーク機能が正常に動作しているとは限りません。

本記事では、構築直後のEKSクラスタに対して実施すべき一連の疎通確認手順と、使用する kubectl コマンドの詳細なオプション、および確認意図を解説します。

検証の目的

以下のネットワークコンポーネントが正常に機能しているかを、実際のワークロードを用いて検証します。

NAT Gateway / Route Table: ノードからインターネットへのOutbound通信（コンテナイメージのPull等）
CoreDNS: クラスタ内部の名前解決
VPC CNI / Security Group: Pod間およびノード間の通信
Control Plane: APIサーバー経由のトンネリング通信

Phase 1: ワークロードの準備とトラブルシュート

まずはテスト用のWebサーバー（Nginx）を立てる。

1. Deployment作成（と、うっかりミス）

$ kubectl create deployment nginx-test --image=nginx:apline
deployment.apps/nginx-test created

create deployment: 指定した名称でDeploymentリソースを作成します。
nginx-test: 作成するDeploymentの名前です。
--image=nginx:alpine: 使用するコンテナイメージを指定します。alpine タグを使用することで軽量なイメージを展開します。

2. 修正と起動確認（Outbound通信の証明）

※これは手順ではないです。単なる修正
aplineでコンテナ作成しようとしてミスったので、イメージ変更。
ここで慌てず、正しいイメージを設定し直す。

$ kubectl set image deployment/nginx-test nginx=nginx:alpine
deployment.apps/nginx-test image updated

$ kubectl get pods
NAME                          READY   STATUS    RESTARTS   AGE
nginx-test-66cf5ddf9b-9m94v   1/1     Running   0          8s

set image: 既存リソースのコンテナイメージを更新します。
deployment/nginx-test: 対象リソースを指定します。
nginx=: コンテナ名を指定します（Deployment作成時に自動的に付与された名前）。
nginx:alpine: 正しいイメージタグを指定します。

3. Serviceの公開（DNS検証の準備）

$ kubectl expose deployment nginx-test --port=80 --target-port=80 --name=nginx-svc
service/nginx-svc exposed

Podにアクセスするための「窓口（Service）」を作った。これを作らないと、この後の「名前解決（DNS）」のテストができない。

expose deployment: 指定したDeploymentをServiceとして公開します。
--port=80: Serviceが待ち受けるポート番号です（クラスタ内で利用されるポート）。
--target-port=80: 転送先となるコンテナ側のポート番号です（Nginxのデフォルトポート）。
--name=nginx-svc: 作成するServiceの名前です。これがクラスタ内DNS名として登録されます。

Phase 2: 外部からの到達性確認

次に、「俺たちのPCからクラスタの中まで手が届くか」を確認する。

4. Port-Forwardによるトンネリング

$ kubectl port-forward svc/nginx-svc 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Handling connection for 8080

ローカル環境からクラスタ内部のPodへ、APIサーバーを経由して直接アクセスします。

svc/nginx-svc: 接続先のServiceを指定します。
8080:80: [ローカルポート]:[リモートポート] の形式です。ローカルの8080番へのアクセスを、Serviceの80番へ転送します。

ブラウザ等で localhost:8080 にアクセスできれば、以下の経路が正常であることが証明されます。

IAM認証: クライアントが正しく認証されている。
API Server到達性: ローカルからAWS上のコントロールプレーンへの通信が可能である。
Pod制御: コントロールプレーンからデータプレーン（Pod）へのトンネリングが可能である。

Phase 3: 内部ネットワークの健全性（最重要）

ここからが本番だ。外から見るだけじゃなく、「Podの中に入って」ネットワークを検証する。これこそがSREの流儀だ。

5. 調査用Podへの潜入

$ kubectl run debug-check -it --rm --image=curlimages/curl --restart=Never -- sh

最後に、クラスタ内部に検証用Podを立ち上げ、Podの中からネットワーク状況を確認します。これが最も重要な検証工程です。

run debug-check: debug-check という名前でPodを単独起動します。
-it: インタラクティブモード（標準入力を接続し、TTYを割り当てる）で起動します。シェル操作に必須です。
--rm: シェル終了後、Podを自動的に削除します（ゴミを残さないため）。
--image=curlimages/curl: curl コマンドが含まれる軽量イメージを使用します。
--restart=Never: 使い捨てのため、終了しても再起動させません。
-- sh: コンテナ起動後に実行するコマンド（シェル）を指定します。

6. 内部DNSとEast-West通信（サーバー間通信）の確認

~ $ curl -I http://nginx-svc
HTTP/1.1 200 OK
Server: nginx/1.29.4

nginx-svc という名前でアクセスして 200 OK が返ってきた。これが何を意味するか。
CoreDNSが生きてる: nginx-svc → 10.x.x.x への名前解決に成功した。
VPC CNI / Kube-proxyが正常: 解決されたIPに対して、パケットが正しく転送された。
Security Groupが正常: ノード間（またはPod間）の通信がファイアウォールで遮断されていない。

7. 外部へのEgress通信の確認

~ $ curl -I https://www.google.com
HTTP/2 200

Pod内部からインターネット上のサイトへアクセスを試行します。
NAT Gatewayの動作: プライベートIPしか持たないPodからの通信が、NAT変換されてインターネットに出られているか。
Security Group (Egress): アウトバウンド通信が許可されているか。