场景判断

四类暴露面各有边界：ClusterIP 只在集群内；NodePort 在每节点开高位端口（demos 方便、生产易被扫）；LoadBalancer 依赖云厂商；Ingress 是七层路由，必须有 Controller。本场景用 examples/minimal-loop/ 的 ClusterIP 当基线，刻意不装 Ingress Controller，让你看见「对象存在 ≠ 流量进来」。

真实事故骨架：为省事把对内 API 改成 NodePort，安全扫描报全网段高位端口；另一起只 apply Ingress 对象却没装 Controller，get ingress 有 host/path 但 ADDRESS 空、外网 404——规则写在 etcd 里，数据面从未启动。

复现步骤

本机勾选备忘（localStorage），不代表你已在集群里跑过，也不连接任何 API。只是帮你对照步骤，别当成「学会了」的勋章。

— / 5本机勾选

01基线：kubectl apply -f examples/minimal-loop/；get svc web -o wide — 确认 TYPE=ClusterIP、有 CLUSTER-IP。
02本机调试：kubectl port-forward svc/web 8080:80；curl -sS localhost:8080 | head — 会话结束即断，未扩大集群暴露面。
03读模型：kubectl explain service.spec.type；口述 ClusterIP / NodePort / LB / Ingress 各适合谁。
04Ingress 空地址演练：若集群无 Controller，get ingress -A 可能为空或 ADDRESS 空 — 记录「先装 Controller 再谈路由」，不要反复改 path 碰运气。
05清理：kubectl delete -f examples/minimal-loop/；总结：生产对外 HTTP 优先 Ingress+证书，而非裸 NodePort。

关键配置

SHELLbash

kubectl apply -f examples/minimal-loop/
kubectl get svc web -o wide
kubectl explain service.spec.type

# 临时本机访问（不改 Service type）
kubectl port-forward svc/web 8080:80
# 另开终端：curl -sS localhost:8080 | head

# 有无 Ingress 数据面？
kubectl get ingress -A
kubectl get pods -A | grep -i ingress || true

kubectl delete -f examples/minimal-loop/

get 到 Ingress 对象只证明 API 记住了规则——ADDRESS 空时，流量从未进门。

验收：能画出浏览器 → LB/Ingress → Service → Pod；能说明何时用 port-forward 而不是改 NodePort。交付清单会继续问：对外入口谁管证书、谁有权改 Service type。

现场记录

先写自己的证据，再看参考答案。输入只留在当前页面，本站不会读取或验证你的集群。

暴露面选型：ClusterIP · port-forward · Ingress 空地址

Evidence Receipt · 执行凭证

Kubernetes 版本验证日期版本 / 产物引用

只填写你实际运行过的环境；stdout / Events 请脱敏后写入下方证据句。

现象

第一条命令

证据句

判断

动作与回滚

这是你的手动确认，不代表本站已检测命令执行结果。

关联命令

跳转图鉴并展开对应条目（可复制示例）。

kubectl apply -f kubectl get svc kubectl get ingress kubectl port-forward kubectl explain kubectl delete

对应路径课节

路径 · 网络模型直觉