Port-forward 端口转发

kubectl port-forward 适合本地调试，把集群内的 Pod 或 Service 暴露到本机端口。

常见用法

kubectl port-forward svc/api 8080:80
kubectl port-forward pod/api-7c9d8d9c8c-abcde 8080:80

适用场景

快速验证 API
本地 UI 访问
临时排查问题

注意事项

仅适合开发调试，不适合生产流量
端口占用冲突时换本地端口

实操要点

先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

资源定义与业务意图一致。
Namespace、权限、镜像与环境匹配。
上线前具备健康探针与可观测日志。

网络身份与服务发现

Kubernetes 网络强调“稳定名称”而不是“稳定 IP”。Service 提供稳定的虚拟 IP 和 DNS 名称，Endpoints 会追踪后端 Pod。端口转发是在这个模型上构建网络访问与发现规则的关键环节。

Service 类型与路由选择

ClusterIP 适合内部访问，NodePort 与 LoadBalancer 用于对外暴露，Ingress 则负责 HTTP 路由与域名管理。选择何种类型取决于环境与流量路径，建议明确哪些入口是用户访问、哪些是内部调用、哪些仅用于调试。

Headless 与直连模式

Headless Service 不创建虚拟 IP，而是直接发布 Pod IP，适合需要固定地址或集群内 peer 发现的系统。此时客户端需要自行处理连接均衡与故障转移，但可以获得更直接的拓扑控制。

Port forward 的定位与限制

端口转发适合临时调试，不改变集群网络配置即可从本地访问 Pod 或 Service。它不应作为生产访问方式，也不适合长期自动化。需要常规访问时，应设计正式的 Service 或 Ingress。

DNS 命名习惯

Kubernetes DNS 支持短名称与完整名称，跨命名空间时建议使用 service.namespace 形式。稳定的命名规则可以减少配置混乱，提升团队协作效率。

外部流量路径

外部流量通常经过负载均衡、NodePort、kube-proxy 到达 Pod，每一跳都会引入超时与失败点。排障时应按路径逐段确认连接状态。

安全与策略

NetworkPolicy 可能阻断通信，即便 DNS 能解析也无法连通。若使用 mTLS 或服务网格策略，要确保策略与 Service 选择器一致，避免意外断流。

运维建议

统一命名规则便于 DNS 预测。上线时关注 endpoints 是否及时更新，尤其是在滚动更新期间。外部流量要设置健康检查与超时策略，避免负载均衡层把请求打到不可用实例。

kubectl get svc -n demo
kubectl get endpoints -n demo
kubectl get endpointslices -n demo
kubectl port-forward svc/demo-api 8080:80 -n demo

实战补充

把快速入门应用到真实业务时，建议固定一套检查项：资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复，并随仓库一起维护，这样每次发布都能快速对齐标准。

排障路径

从现象入手，不要先猜原因。先看事件，再看日志，最后验证流量路径和配置版本是否一致。若访问异常，先确认 readiness 和 endpoints，再逐段排查入口到后端的链路。记录每一步改动，方便回滚和复盘。

小练习

在测试环境做几次常见操作：扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习，你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口，准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划，确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次：访问核心接口、观察延迟和错误率，确认新旧 Pod 的状态稳定。如果涉及存储或网络，顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤，包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原，而不是现场临时拼步骤。