Kubernetesのネットワークとストレージ
届く経路と消えないデータ

5日目です。昨日の第3章では、Deployment api の前にServiceを置き、ReadyなPodにだけ通信が届くところまで確かめました。ただ、そのときは同じNamespaceの中から http://api と呼んだだけです。今日は、別のNamespaceから名前で呼び、外からの入口の考え方を押さえ、NetworkPolicyで通信を絞ります。後半はストレージに移って、Podを消しても残るデータを作ります。

昨日の最後に lab は片付けたので、今日も作るところから始めます。Serviceの port と targetPort があやふやな方は、第3章の「Serviceとラベル選択」を先に読んでおくと、演習1が追いやすくなります。

この章の結論

この章で手に入れてほしいのは、「繋がらない」を1つの症状として扱わない目です。名前が引けないのか、転送先がないのか、ポートが違うのか、ポリシーに止められているのか。それぞれ見る場所が違います。ストレージも同じで、Bound と表示されても、アプリが書けるとは限りません。

今日つくる構成

今日はNamespaceを2つ使います。lab にサーバー側の api とストレージの演習用Pod、lab-front に呼び出す側の一時Podを置きます。最終的に図4-1の形になります。

図4-1: 今日つくる構成。上半分がネットワーク、下半分がストレージ。

まずContextを確かめて、Namespaceを2つ作ります。

kubectl config current-context      # kind-xxx / minikube / docker-desktop などが出ればOK
kubectl create namespace lab
kubectl create namespace lab-front

サーバー側は、昨日の完成形からProbeと設定を省いた簡略版です。今日はネットワークの話に集中したいので、2台にしています。

# api.yaml ― 第3章の api を簡略化。Deployment と Service を1ファイルに
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: api
    spec:
      containers:
        - name: api
          image: nginx:stable
          ports:
            - name: http
              containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app.kubernetes.io/name: api
  ports:
    - name: http
      port: 80
      targetPort: http

kubectl -n lab apply -f api.yaml
kubectl -n lab rollout status deployment/api
kubectl -n lab get svc,endpointslice,pod -o wide

ネットワークの4つの層

Kubernetesの通信で迷う原因の多くは、いくつもの層を1つに見てしまうことです。図4-2のように、下から順に分けて考えます。

図4-2: ネットワークは4つの層に分けて見る。障害のときは、どの層まで届いているかを確かめる。

かなり雑に言うと、Pod IPは「今日の席番号」、Serviceは「部署の代表番号」、DNS名は「電話帳の名前」、外からの入口は「会社の受付」です。席替えがあっても代表番号は変わらず、電話帳から代表番号を引けば、いま座っている人に繋がります。

ServiceとDNS ― 別のNamespaceから名前で呼ぶ

Serviceを作ると、クラスター内のDNS（多くの環境ではCoreDNS）が名前を答えるようになります。名前は <Service名>.<Namespace>.svc.<クラスターのドメイン> の形で、クラスターのドメインは既定で cluster.local です。

lab-front に使い捨てのPodを作って、確かめます。

# 名前を引く（DNSの層）
kubectl -n lab-front run dns --image=busybox:1.36 --rm -i --restart=Never -- \
  nslookup api.lab.svc.cluster.local

# 名前で呼ぶ（HTTPまで）。同じNamespaceではないので、api だけでは届かない
kubectl -n lab-front run curl --image=curlimages/curl:8.10.1 --rm -i --restart=Never -- \
  curl -s -m 5 -o /dev/null -w '%{http_code}\n' http://api.lab

# 出力の例（IPは環境によって違う）
Name:	api.lab.svc.cluster.local
Address: 10.96.142.17
pod "dns" deleted

200
pod "curl" deleted

DNSが返したのは、Podではなく Service の ClusterIP（10.96.x.x のような番号）です。実際にどのPodへ届くかは、EndpointSliceが決めます。だから、名前が引けたのに繋がらないときは、次にEndpointSliceを見ます。

kubectl -n lab get endpointslice -l kubernetes.io/service-name=api
kubectl -n lab get pod -o wide        # EndpointSlice の IP と、Pod の IP が一致するか

古い入門記事では kubectl get endpoints を使っていますが、Endpoints APIは v1.33 で非推奨になりました。今後はEndpointSliceを見る習慣を付けておくと、表示の警告に戸惑いません。

個々のPodのIPをDNSで知りたい場合は、clusterIP: None のHeadless Serviceを使います。DNSはServiceの仮想IPではなく、ReadyなPodのIPを全部返します。第3章で触れたStatefulSetと組み合わせて、db-0.db のようにPodを1つずつ名前で呼ぶ用途です。通常のWeb APIでは、振り分けをServiceに任せるほうが扱いやすいです。

ClusterIP・NodePort・LoadBalancer

Serviceの type は、どこまで外に開くかを決めます。3つは別物というより、図4-3のように外側へ重ねていく関係です。

図4-3: Serviceの種類は「どこまで外に開くか」。外側ほど、クラウドや費用の都合が増える。

学習環境で外から試したいだけなら、Serviceの種類を変えずに port-forward を使うのが手軽です。

kubectl -n lab port-forward svc/api 8080:80    # このターミナルは開いたまま
# 別のターミナルで
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8080      # 200

port-forward は、kubectlがAPI Server経由でPodを1つ選んで直接つなぐ仕組みです。Serviceの振り分けやreadinessの確認にはならないので、動作確認用と割り切ってください。Ctrl+Cで止めます。

IngressとGateway API

外からのHTTP/HTTPSを、ホスト名とパスでServiceへ振り分けるのが、IngressとGateway APIです。どちらもYAMLだけでは動きません。YAMLを読んで実際に通信を中継するプログラム（Ingress ControllerやGatewayの実装）が、クラスターに入っている必要があります。

図4-4: Ingressは1枚にまとめて書く。Gateway APIは担当者ごとにリソースを分ける。

Ingressは長く使われてきたAPIで、今も使えます。ただし、ホスト名とパス以外の設定（タイムアウト、ボディサイズ、リダイレクトなど）は、Controllerごとのアノテーションで書くことが多く、Controllerを替えるとYAMLも書き直しになります。Gateway APIは、それを標準の項目として持ち、インフラ担当とアプリ担当の責任を分けられるように作られています。

Gateway APIで書くと、次のような形になります。example-gateway と api.example.com は例です。

# httproute.yaml（例）― api.example.com/ への通信を Service api へ
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs:
    - name: example-gateway            # 運用者が用意した Gateway の名前
      namespace: infra
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: api                    # Service の名前と port
          port: 80

今日はControllerを入れないので、適用はしません。代わりに、自分のクラスターに何が入っているかを確かめます。

kubectl get ingressclass                         # Ingress Controller が入っていれば一覧が出る
kubectl api-resources | grep gateway.networking  # Gateway API の定義（CRD）が入っているか

kindの初期状態では、どちらも何も出ません。この状態で上のHTTPRouteを適用すると、no matches for kind "HTTPRoute" というエラーになります。Gateway APIはKubernetes本体とは別に配布され、定義（CRD）と実装を後から入れる仕組みだからです。Ingressのほうは、定義は最初からあるので適用は成功します。ただしControllerがなければ ADDRESS が空のままで、どこにも繋がりません。「適用できた」と「通信が届く」は別、というのは第3章のProbeと同じ話です。

NetworkPolicyで通信を絞る

ここまでの状態では、クラスター内のどのPodからでも api に届きます。多くのクラスターでは、Pod同士の通信は初めから全部許可されているからです。NetworkPolicyは、Podに対して「この通信だけ許可する」を書くリソースです。

押さえておく決まりは3つです。

• どのPolicyにも選ばれていないPodは、全部許可のまま
• あるPodが Ingress（受信）のPolicyに1つでも選ばれると、そのPodへの受信は「どれかのPolicyで許可されたものだけ」になる
• Policyは足し算。複数あれば、許可の和になる。「拒否」を書く欄はない

# np-allow-front.yaml ― api への受信を、lab-front の TCP 80 だけに絞る
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-front
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: api      # 守る対象のPod
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: lab-front   # Namespaceに自動で付くラベル
      ports:
        - protocol: TCP
          port: 80                     # Serviceの番号ではなく、Pod側の番号

kubectl -n lab apply -f np-allow-front.yaml

# lab-front から：許可されているので 200
kubectl -n lab-front run curl --image=curlimages/curl:8.10.1 --rm -i --restart=Never -- \
  curl -s -m 5 -o /dev/null -w '%{http_code}\n' http://api.lab

# lab の中から：同じNamespaceでも、許可していないので届かない（5秒で打ち切り）
kubectl -n lab run curl --image=curlimages/curl:8.10.1 --rm -i --restart=Never -- \
  curl -s -m 5 -o /dev/null -w '%{http_code}\n' http://api

# 出力の例（NetworkPolicyが効いている場合）
200
pod "curl" deleted

000
pod "curl" deleted
pod lab/curl terminated (Error)

000 は、HTTPの応答が返ってこなかったという意味です。拒否の応答が返るのではなく、パケットが捨てられてタイムアウトします。これがNetworkPolicyで止められたときの典型的な見え方で、「アプリが落ちている」と取り違えやすい点です。

本番に入れるときは、いきなり「全部拒否」にしません。DNS、監視、ログ収集、Namespaceをまたぐ必要な通信を先に洗い出し、許可のPolicyを用意してから絞ります。また、NetworkPolicyはアプリの認証の代わりにはなりません。侵入されたときに横へ広がるのを減らす、防御の1層です。

Podの一時ファイルとPVC

ここからストレージです。コンテナの中に書いたファイルは、コンテナを作り直すと消えます。emptyDir は、同じPodの中のコンテナで共有できる一時領域ですが、Podが消えれば一緒に消えます。Podより長くデータを残すには、PVC（PersistentVolumeClaim）を使います。

図4-5: PVCは要求、PVは実体、StorageClassは作り方の方針。emptyDirはPodの一部。

まず、クラスターにどのStorageClassがあるかを見ます。

kubectl get storageclass

# 出力の例（kind）
NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
standard (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  2d

次に、PVCと、それを使うPodを作ります。Podには emptyDir とPVCの両方を付けて、違いを並べて確かめます。

# notes.yaml ― PVC と、それを使う Pod
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: notes
spec:
  accessModes: [ReadWriteOnce]         # 1つのNodeからだけマウントできる、という意味が多い
  resources:
    requests:
      storage: 1Gi
  # storageClassName を省略 → (default) の StorageClass を使う
---
apiVersion: v1
kind: Pod
metadata:
  name: notes
spec:
  terminationGracePeriodSeconds: 5     # sleep は停止の合図を無視するので、待ち時間を短く
  containers:
    - name: notes
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cache
          mountPath: /cache
        - name: data
          mountPath: /data
  volumes:
    - name: cache
      emptyDir: {}                     # Podと一緒に消える
    - name: data
      persistentVolumeClaim:
        claimName: notes               # Podより長く残る

適用して、PVCとPVの状態を見ます。

kindでは、Podが置かれるまでの数秒間、PVCが Pending と表示されることがあります。WaitForFirstConsumer なので、Podの置き場所が決まるまでPVを作らないからです。describe pvc のEventsに waiting for first consumer to be created before binding と出ていれば、正常な待ちです。Podが動き出すと Bound に変わり、get pv に pvc- で始まる名前のPVが1つ現れます。

では、両方に書いて、Podを消して、作り直します。

kubectl -n lab exec notes -- sh -c 'date > /data/hello.txt; date > /cache/hello.txt'
kubectl -n lab delete pod notes
kubectl -n lab apply -f notes.yaml     # PVCはそのまま。Podだけ作り直される
kubectl -n lab wait --for=condition=Ready pod/notes --timeout=60s
kubectl -n lab exec notes -- cat /data/hello.txt     # さっきの日時が残っている
kubectl -n lab exec notes -- cat /cache/hello.txt    # No such file or directory

Podを消しても、PVCを消していなければデータは残ります。逆に言うと、kubectl delete pvc notes を実行すると、RECLAIMPOLICY が Delete のStorageClassでは、PVと中身も一緒に消えます。本番では、大事なデータのStorageClassを Retain にするか、消す手順に承認を入れるかを決めておきます。

アクセスモードも、名前どおりに受け取らないようにします。ReadWriteOnce は「1つのNodeからだけ読み書きできる」という意味のことが多く、同じNodeの複数Podからは使えても、別のNodeのPodとは共有できません。複数のNodeで共有したいからと ReadWriteMany を選んでも、アプリが同時書き込みを想定していなければファイルが壊れます。

第3章で触れたStatefulSetは、volumeClaimTemplates でPodごとに専用のPVCを作ります。db-0 が作り直されても、同じ data-db-0 のPVCに繋がります。ただし、壊れたトランザクションを直したり、レプリカ間の整合をとったりするのはDB自身の仕事です。StatefulSetが保証するのは、名前とディスクの対応までです。

バックアップと復元テスト

「YAMLはGitにあるから大丈夫」は、半分しか正しくありません。YAMLから作り直せるのは定義だけで、PVCの中のデータ、外部のDNSや証明書、Secretの実際の値は戻りません。何を、どこへ、どの頻度で取るかを一覧にします。

DBなら、スナップショットの前にDBのバックアップモードを使うか、DB自身のダンプ・ログを取ります。そのうえで、2つの数字を決めます。RPO（どの時点まで戻れればよいか）とRTO（何分で戻せればよいか）です。決めた数字は、実際に復元してみるまで当てになりません。

復元テストは、元のPVCに上書きせず、別のNamespaceに戻して、件数やスキーマを確かめます。保存先が元と同じ障害の範囲（同じZone、同じアカウント）にあれば、ディスクと一緒に失う可能性もあります。

kubectl api-resources | grep -i volumesnapshot   # スナップショットの定義が入っているか

kindの初期状態では何も出ません。VolumeSnapshot は、スナップショット用の定義（CRD）・コントローラー・対応したCSIドライバーがそろって初めて使えます。クラウドのマネージドKubernetesでは用意されていることが多いので、自分の環境で確かめてください。

わざと壊す演習

今日作った api・NetworkPolicy・notes を使って、3つ壊します。壊したら、図4-2のどの層で止まっているかを考えてから直してください。

kubectl -n lab delete networkpolicy api-allow-front    # 演習1の間だけ外す
kubectl -n lab patch svc api --type=json \
  -p='[{"op":"replace","path":"/spec/ports/0/targetPort","value":8080}]'

kubectl -n lab-front run curl --image=curlimages/curl:8.10.1 --rm -i --restart=Never -- \
  curl -sS -m 5 http://api.lab

kubectl -n lab get endpointslice -l kubernetes.io/service-name=api
# PORTS が 8080、ENDPOINTS には Pod の IP が2つ。転送先はあるのに、番号が違う

kubectl -n lab apply -f api.yaml                # ファイルの定義（targetPort: http）に戻す
kubectl -n lab apply -f np-allow-front.yaml     # 外したPolicyを戻す

# np-front-egress.yaml ― lab-front の全Podの送信を止める（許可の欄なし）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: front-deny-egress
spec:
  podSelector: {}                      # Namespace内の全Pod
  policyTypes: [Egress]

kubectl -n lab-front apply -f np-front-egress.yaml
kubectl -n lab-front run curl --image=curlimages/curl:8.10.1 --rm -i --restart=Never -- \
  curl -sS -m 5 http://api.lab

# np-front-egress.yaml に追記する2つ目のPolicy
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: front-allow-dns-and-api
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:                              # クラスターのDNS（CoreDNS）へ
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - to:                              # lab の api へ
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: lab
          podSelector:
            matchLabels:
              app.kubernetes.io/name: api
      ports:
        - protocol: TCP
          port: 80

kubectl -n lab-front apply -f np-front-egress.yaml
kubectl -n lab-front run curl --image=curlimages/curl:8.10.1 --rm -i --restart=Never -- \
  curl -s -m 5 -o /dev/null -w '%{http_code}\n' http://api.lab      # 200

# pvc-bad.yaml ― このクラスターにない StorageClass を指定
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uploads
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: fast-encrypted
  resources:
    requests:
      storage: 1Gi

kubectl -n lab apply -f pvc-bad.yaml      # 適用は成功する
kubectl -n lab get pvc uploads             # STATUS Pending のまま
kubectl -n lab describe pvc uploads        # Events を見る

kubectl -n lab delete pvc uploads
# pvc-bad.yaml の storageClassName の行を消す（既定を使う）か、get storageclass にある名前に直して
kubectl -n lab apply -f pvc-bad.yaml
kubectl -n lab get pvc uploads             # kind では、使うPodがないので Pending（WaitForFirstConsumer の正常な待ち）

壊したら、メモを残す

第1章から使っている6項目です。今日は「最初に見たもの」に、図4-2のどの層かを添えてください。

# 演習メモの例
日時/Context : 2026-10-23 21:30 / kind-kind（Namespace: lab, lab-front）
症状         : lab-front から curl http://api.lab が Could not resolve host
最初に見たもの: エラーの種類（6 = 名前解決の失敗）→ ③DNSの層。get networkpolicy -n lab-front
原因         : front-deny-egress で送信を全部止め、DNS（53番）を許可していなかった
修正         : kube-dns への UDP/TCP 53 と、lab の api への TCP 80 を許可するPolicyを追加
再発防止     : Egressを絞るPolicyには、DNSの許可を必ずセットで書く。適用後に名前解決から確かめる

繋がらないときに見る順番

演習で見たとおり、エラーの見え方で、止まっている層の見当がつきます。図4-6の順に、送信元に近いほうから確かめます。

図4-6: 送信元に近い層から順に見る。エラーの種類が、止まっている層の手がかりになる。

大事なのは、実際の送信元と同じ条件で試すことです。デバッグ用のPodを別のNamespaceに作ると、NetworkPolicyの条件が変わり、「自分のPodからは繋がるのに」という食い違いが起きます。演習で lab-front と lab の両方から試したのは、このためです。

# ネットワークの確認セット
kubectl -n lab get svc,endpointslice
kubectl -n lab describe svc api
kubectl get networkpolicy -A
# ストレージの確認セット
kubectl -n lab get pvc
kubectl get pv
kubectl -n lab describe pvc notes
kubectl -n lab describe pod notes          # Events にマウントの成否が出る

ストレージも、Bound を「アプリから使える」と読み替えません。Podのイベントでマウントの成功を確かめ、コンテナの中で書き込み、再起動後に読めるかまで試します。書けないときは、ファイルの権限（コンテナを動かすユーザー）、アクセスモード、NodeとディスクのZone、容量、CSIドライバーのイベントを順に見ます。

設計レビューで確かめること

ネットワークは、利用者 → 外部ロードバランサー → Ingress/Gateway → Service → Pod → DB という経路を図にし、矢印ごとに次の項目を書きます。ストレージは、アプリが書くデータ、キャッシュ、バックアップ、監査ログを分けて書きます。

どの項目も、200 が返った、Bound になった、だけで完了にしないためのものです。

片付け

kubectl delete namespace lab lab-front
kubectl get namespaces          # lab と lab-front が消えたことを確認
kubectl get pv                  # notes の PV も消えている（RECLAIMPOLICY が Delete のため）

Namespaceを消すと、中のPVCも消え、kindの standard では対応するPVと中身も消えます。PVは数秒遅れて消えることがあります。Retain のStorageClassを使った場合は、PVが Released で残るので、手で消してください。クラウドで同じことをすると、残ったディスクに料金がかかり続けます。今日は、ロードバランサーは作っていません。

まとめ

• ネットワークは Pod IP・Service・DNS名・外からの入口の4層で見る。Pod IPは設定に書かない
• 別のNamespaceからは api.lab。名前が引けても繋がらなければ、EndpointSliceとポートを見る
• Serviceの種類は「どこまで外に開くか」。外からのHTTPは Ingress か Gateway API。どちらも実装が要る。Ingress NGINXは2026年3月に保守終了
• NetworkPolicyは許可の足し算。効くかはCNIしだい。Egressを絞るならDNSを忘れない
• PVCは要求、PVは実体、StorageClassは方針。Podを消してもPVCが残ればデータは残る
• バックアップは復元して初めて意味がある。RPO・RTOを決め、別の場所へ戻して確かめる

公式資料

• Services, Load Balancing, and Networking: https://kubernetes.io/docs/concepts/services-networking/
• DNS for Services and Pods: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
• EndpointSlices: https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/
• Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/
• Gateway API: https://gateway-api.sigs.k8s.io/
• Ingress NGINX Retirement: What You Need to Know（2025年11月）: https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• Volumes: https://kubernetes.io/docs/concepts/storage/volumes/
• Persistent Volumes: https://kubernetes.io/docs/concepts/storage/persistent-volumes/
• Storage Classes: https://kubernetes.io/docs/concepts/storage/storage-classes/
• Volume Snapshots: https://kubernetes.io/docs/concepts/storage/volume-snapshots/

※本章の記述は2026年10月時点の公式ドキュメントと公式ブログに基づきます。イベントの文言、kubectl の出力形式、StorageClassの名前、NetworkPolicyへの対応は、Kubernetesのバージョンや学習環境（kind・minikube・Docker Desktop）によって異なることがあります。本章のコマンドは手順として整理したもので、すべての環境での動作を確認したものではありません。