Kubernetes Serviceの接続確認手順｜EndpointSlice・selector・portの調べ方
Kubernetes Serviceの構成を作成・変更する前や通信経路を確認するときに、selector、Podのlabels、EndpointSlice、port・targetPort、readinessを順番に点検する運用ガイドです。障害時も設定変更より事実確認を先に行います。
この記事の目的
Serviceが正しいPodを選択できているか、転送先ポートとReady条件が一致しているかを確認します。
まず確認すること
kubectl get svcとkubectl get endpointslicesでService定義と転送先の有無を確認します。
app・APP・POD_NAMEなどは説明用です。作業前にcontext・namespace・対象オブジェクトを照合してください。関連ガイド
Kubernetes基本操作
context・namespaceを確認し、kubectlでPod・Eventsを調査します。
ガイドへ →KubernetesDeployment更新・切り戻し
rollout history・status・undoと変更前後の確認を行います。
ガイドへ →KubernetesConfigMap・Secretの確認と安全な更新
Secretを露出させず、設定反映の条件を確認します。
ガイドへ →1. Serviceが接続先を決める仕組み
| 要素 | 役割 | 注意点 |
|---|---|---|
| Service | ClusterIP等の仮想的なアクセス先 | type・port・selectorの確認 |
| selector | ラベルが一致するPodを選ぶ | Podのmetadata.labelsと一致させる |
| EndpointSlice | 転送先Pod等のアドレス・ポートと条件 | すべてがReadyとは限らない |
| targetPort | Pod側の転送先ポート | 数字と名前付きportの解決先を確認 |
| Ingress/Gateway | クラスター外のHTTP等の入口 | コントローラー・証明書・ルート等が別途必要 |
Serviceのportとコンテナの実待受ポートは異なることがあります。targetPortの名前を使う場合はPod内のコンテナport名と対応する必要があります。
2. 参照コマンドで対象を確認
ここでmy-serviceとappは説明用です。selectorのないServiceや外部接続先を手動定義する構成もあるため、EndpointSliceが自動生成されると決めつけないでください。
3. selectorとPod labelsの一致を調べる
Serviceのselectorがapp: apiなら、Podのラベルにも同じキーと値が必要です。一致するPodがあってもReady条件や削除中状態によって、実際の転送候補にならない場合があります。
4. port・targetPort・readinessを点検
| 現象 | 最初に調べること |
|---|---|
| EndpointSliceが空 | selector・Podラベル・Ready・Serviceの設計 |
| EndpointSliceはあるが通信不可 | targetPort・アプリのlisten・NetworkPolicy・CNI |
| Pod Runningだが応答しない | Readiness・コンテナの起動完了・アプリログ |
| Ingress経由だけ失敗 | Ingress/Gatewayルール・バックエンド・TLS・コントローラー |
| Service DNSで解決できない | namespace指定のFQDN・CoreDNS・DNSポリシー |
PodがRunningであってもReadyであるとは限りません。Serviceの転送候補はPodのReady条件やEndpointSliceのconditionsを確認して判断します。
5. 接続結果別の具体的な調査・修正
次のエラー・状態は想定例であり実環境での実測ではありません。変更前はcontext、Namespace、ServiceとPodの管理元、利用中クライアント、従来のService定義を記録してください。
| 結果・想定状態 | 判断と具体的な次の行動 |
|---|---|
| Service selectorとPod labelsが不一致 | 正しい所有Deployment・Podテンプレートを特定。管理元のラベルまたはService定義の差分をレビューし、承認後に整合させる。意図しないPodへ転送しないよう変更前後の転送先を比較 |
| EndpointSliceが空・対象endpointがReadyでない | Pod Ready/Readinessの失敗理由、Pod削除中か、selector無しServiceの手動EndpointSlice構成かを確認。publishNotReadyAddressesの有無にも注意 |
| Readyなendpointがあるが接続拒否 | Service portとtargetPort（名前付きport含む）、コンテナの実listen、アプリログを確認。Serviceのポートを無条件に変更しない |
| Pod直接通信は成功、Service経由だけ失敗 | DNS名/namespace、NetworkPolicy、kube-proxyまたはCNI、Service実装の調査を続ける。権限のある管理者がクラスター内から再試験 |
port-forwardは成功、通常通信は失敗 | ローカル転送はServiceの実通信経路・ネットワークポリシーを再現しないため、通常経路の正常性は未証明と判定 |
変更する場合：GitOps/CI等の管理元から修正定義と旧定義を確保し、影響先を承認後、kubectl apply --dry-run=server -f service-corrected.yamlとkubectl diff -f service-corrected.yamlで事前検証します。反映も切り戻しも変更管理下で行い、誤配信や一時的な通信断に注意します。既存の通信先が不明なら変更を保留してください。
完了判定：EndpointSliceの条件だけでなく、クラスター内のService FQDNからの実疎通・アプリ応答・Ingress/Gateway経由の必要な経路を確認。未解決ならDNS、ポリシー、CNI・Serviceの管理担当者へEventsと変更差分を引き継ぎます。Kubernetes公式 — Serviceの調査。
6. ローカル検証とポート転送の注意
kubectl port-forwardを使うと、API経由でローカルマシンへポートを転送してサービスを確認できます。ただし、クラスター内の通常のService経路・NetworkPolicyをそのまま再現する検証ではありません。
0.0.0.0への公開は不用意に行わないでください。7. 設定変更後に確認すべきこと
- Serviceのselector・type・port・targetPortが設計通りか
- EndpointSliceの転送先とReady条件が一致しているか
- アプリのlisten、Readiness、Podの状態が正常か
- クラスタ内・外それぞれの経路で疎通できるか
- Ingress/GatewayやNetworkPolicyを含む公開範囲が安全か
Podの再作成や変更が必要ならDeployment更新の監査手順を参照。通信障害を一律に「NetworkPolicyのせい」と判断しないことが重要です。