ServiceにNodeのポートという入口を足し、MacからAPIへ到達する経路を実際に確かめる章です。検証用の公開と本番のHTTP入口を分けて理解します。
Node IP:nodePortから、selectorに一致するReady Podまで到達する。
`type: NodePort`にすると、既存ServiceのselectorとtargetPortを保ったまま、各Nodeのポートが外部入口になる。PodのIPやDeploymentを公開する設定ではない。
判断できるようになること：NodePortを「ClusterIPを含むServiceに外部入口を追加する方式」と説明できる。
Serviceの状態を読んで、Macから到達できるURLを組み立てる。
`kubectl get svc`でTYPEとPORT(S)を確認し、`minikube ip`でNode IPを取得する。`http://<node-ip>:<nodePort>`へのcurlがHTTP応答を返せば、外部からServiceまでの経路を確認できる。
失敗時は、Service type → EndpointsのReady Pod → Node IP/Port → HTTP応答の順に1段ずつ切り分ける。
ポート直公開の制約を知り、HTTPの責務をIngress Controllerへ分ける。
NodePort単体はドメイン、TLS終端、ホスト・パス別ルーティングを担わない。次章ではServiceをClusterIPへ戻し、IngressとIngress ControllerにHTTP入口を任せる。
NodePortは「早く届くかを確かめる」ため、Ingressは「HTTPを安全に公開する」ため、と使い分ける。