K8s部署与NodePort暴露全指南

K8s 配置 Deployment 端口与 NodePort Service：核心知识与实操

在 Kubernetes（K8s）集群中，Deployment 负责管理 Pod 的生命周期，而 Service 负责暴露 Pod 的网络访问能力 —— 两者通过 “标签选择器” 协作，构成 “应用部署→网络暴露” 的完整链路。本文结合 “修改 front-end Deployment 暴露端口 + 创建 NodePort Service” 的任务，梳理所需关键知识，帮你精准完成配置，确保外部能通过 NodePort 访问 nginx 服务。

一、先搞懂：任务涉及的核心组件关系

在深入配置前，必须明确 Deployment、Pod、Service 三者的协作逻辑 —— 这是理解任务的基础，避免后续配置 “只知其然不知其所以然”。

1. 组件关系图

Deployment（front-end） → 管理Pod（含nginx容器） → Service（front-end-svc）通过标签关联Pod → 外部通过NodePort访问

2. 核心逻辑

• Deployment：定义 “期望的 Pod 状态”（如副本数、容器镜像、端口），并自动维护 Pod 数量（如 Pod 异常时重启）；

• Pod：nginx 容器的运行载体，每个 Pod 有独立的 IP（集群内可访问），但 Pod 重启后 IP 会变化；

• Service：作为 “Pod 的固定访问入口”，通过标签选择器关联 Pod，即使 Pod IP 变化，Service IP（ClusterIP）也不变；

• NodePort：Service 的一种类型，在集群所有节点上开放一个 “静态端口”，外部通过 “节点 IP+NodePort” 即可访问 Pod 内的服务（如 nginx 80 端口）。

二、核心知识 1：Deployment 的容器端口声明（containerPort）

任务第一步是 “重新配置 front-end Deployment，公开现有 nginx 容器的 80/tcp 端口”—— 这里的 “公开” 并非 “外部可访问”，而是 K8s 内部的 “端口声明”，需明确其含义与配置逻辑。

1. 什么是 containerPort？

containerPort是 Deployment 的 Pod 模板中，对容器 “监听端口” 的声明性配置，核心作用：

• 告知 K8s “该容器在 80 端口提供服务”（仅为元数据，不直接暴露端口）；

• 为后续 Service 的targetPort提供 “匹配依据”（Service 需通过targetPort指向容器的实际监听端口）；

• 便于集群内其他组件（如监控、日志）识别容器的服务端口。

注意：containerPort≠“端口映射”—— 它不会将容器端口映射到节点端口，也不会限制容器只能在该端口监听（若容器实际监听其他端口，containerPort配置无效）。

2. 为什么必须配置 80/tcp？

因为 nginx 默认在 80 端口提供 HTTP 服务，配置containerPort: 80且协议为TCP（默认就是 TCP，可显式指定），能确保：

• Service 的targetPort可精准指向 nginx 的监听端口；

• 避免因端口不匹配导致 Service 转发失败（如 Service 指向 8080，但容器实际监听 80，会出现 “连接拒绝”）。

3. 配置方式（Deployment YAML 关键片段）

在spline-reticulator命名空间的 front-end Deployment 中，找到spec.template.spec.containers下的 nginx 容器，添加ports字段：

spec:template:spec:containers:- name: nginx # 现有nginx容器名称，需与实际一致image: nginx:xxx # 现有镜像，不修改# 新增：声明容器端口80/tcpports:- containerPort: 80 # 容器监听端口protocol: TCP # 协议（可选，默认TCP）name: http # 端口名称（可选，便于后续Service引用）

4. 配置时的注意事项

• 与容器实际监听端口一致：必须确保 nginx 容器确实在 80 端口监听（可通过kubectl exec -it <pod-name> -n spline-reticulator -- netstat -tuln验证）；

• 不影响现有配置：仅添加ports字段，不修改 Deployment 的副本数、镜像、资源限制等其他配置；

• 滚动更新机制：修改 Deployment 后，K8s 会触发 “滚动更新”—— 先创建新 Pod（含端口配置），再删除旧 Pod，确保服务不中断。

三、核心知识 2：NodePort Service—— 外部访问 Pod 的 “桥梁”

任务第二步是 “创建 front-end-svc Service，通过 NodePort 公开 Pod”，需掌握 NodePort 类型的特点、配置逻辑及访问方式。

1. Service 的 3 种核心类型对比

K8s Service 支持 3 种主流类型，本次任务选择 NodePort，需先明确其与其他类型的区别：

类型	核心特点	适用场景	外部访问方式
ClusterIP	仅集群内可访问（默认类型）	集群内服务间通信	集群内 IP+Service 端口
NodePort	在所有节点开放静态端口，外部可访问	测试 / 小规模外部访问	节点 IP+NodePort
LoadBalancer	依赖云厂商负载均衡器，自动分配公网 IP	生产环境大规模外部访问	负载均衡器公网 IP+Service 端口

本次任务选择 NodePort，是因为它无需依赖云厂商，可直接通过节点 IP + 静态端口访问，适合快速暴露服务。

2. NodePort 的关键配置字段

创建 front-end-svc Service 时，需重点配置以下字段（YAML 关键片段）：

apiVersion: v1 # Service的API版本（稳定版，固定为v1）kind: Service # 资源类型为Servicemetadata:name: front-end-svc # Service名称（任务要求）namespace: spline-reticulator # 与Deployment同命名空间spec:type: NodePort # 类型为NodePort（核心，必须指定）selector: # 标签选择器（关联front-end Deployment的Pod）app: front-end # 需与Deployment的Pod标签一致（如Deployment的spec.template.metadata.labels）ports:- port: 8080 # Service的集群内端口（ClusterIP端口，可自定义，如80、8080）targetPort: 80 # 指向Pod的容器端口（需与Deployment的containerPort一致）nodePort: 30080 # 节点开放的静态端口（可选，K8s自动分配范围：30000-32767）protocol: TCP # 协议（默认TCP，可选）name: http # 端口名称（可选，与容器端口名称一致更佳）

字段详解（重点！避免混淆）

• type: NodePort：必须显式指定，告知 K8s 创建 NodePort 类型的 Service；

• selector：Service 与 Pod 的 “关联钥匙”—— 必须与 front-end Deployment 的 Pod 标签（spec.template.metadata.labels）完全匹配，否则 Service 找不到 Pod（会显示ENDPOINTS <none>）；

• port：Service 在集群内的 “访问端口”（ClusterIP:port），集群内其他 Pod 通过该端口访问 Service，与容器端口无关；

• targetPort：Service 转发请求的 “目标端口”—— 必须与 Deployment 中 nginx 容器的containerPort一致（此处为 80），否则请求无法到达容器；

• nodePort：K8s 在每个节点上开放的 “静态端口”（可选，若不指定，K8s 会从 30000-32767 中自动分配），外部通过 “节点 IP+nodePort” 访问服务。

3. NodePort 的访问链路

外部访问 nginx 服务的完整链路：

1. 外部客户端（如浏览器、curl）发送请求到 “任意集群节点的 IP:nodePort”（如 192.168.1.100:30080）；

1. 节点接收请求后，转发到 Service 的 ClusterIP:port（如 10.96.0.10:8080）；

1. Service 根据selector找到关联的 front-end Pod，将请求转发到 Pod 的targetPort（80）；

1. nginx 容器处理请求，沿原链路返回响应。

4. 配置注意事项

• 命名空间一致：Service 的namespace必须为spline-reticulator，与 Deployment 同命名空间（Service 默认只能关联同一命名空间的 Pod）；

• 标签选择器精准匹配：若 Deployment 的 Pod 标签为app: front-end-v2，Service 的selector也必须设为app: front-end-v2，否则 Service 无法关联 Pod；

• nodePort 范围限制：若手动指定nodePort，必须在 30000-32767 之间（K8s 默认端口范围，可通过 API Server 参数--service-node-port-range修改）；

• 节点网络可达：外部客户端需能访问集群节点的 IP（如节点有公网 IP，或客户端在同一局域网），否则无法通过 NodePort 访问。

四、核心知识 3：命名空间隔离 —— 资源的 “边界”

任务中所有操作都在spline-reticulator命名空间下，需理解命名空间的核心作用，避免因 “跨命名空间操作” 导致配置失败。

1. 命名空间的核心作用

命名空间是 K8s 中 “资源隔离” 的基础机制，主要作用：

• 资源名称隔离：不同命名空间可存在同名资源（如 default 命名空间有 front-end Deployment，spline-reticulator 也可有）；

• 权限控制：可通过 RBAC（基于角色的访问控制）为不同命名空间设置独立权限（如仅允许特定用户操作 spline-reticulator 的资源）；

• 资源配额：可限制命名空间的资源使用（如 spline-reticulator 最多使用 2 核 CPU、4GB 内存）。

2. 操作时的命名空间指定

所有针对 front-end Deployment 和 front-end-svc 的命令，都必须通过-n spline-reticulator指定命名空间，否则会默认操作default命名空间，导致 “资源找不到”：

• 编辑 Deployment：kubectl edit deploy front-end -n spline-reticulator；

• 创建 Service：kubectl apply -f service.yaml -n spline-reticulator；

• 查看资源：kubectl get deploy,svc -n spline-reticulator。

五、实操步骤与验证方法（结合知识点）

掌握上述知识后，可按以下步骤完成任务，并通过命令验证配置是否生效。

步骤 1：修改 front-end Deployment，暴露 80/tcp 端口

方法 1：kubectl edit 在线编辑（快速）

# 编辑spline-reticulator命名空间的front-end Deploymentkubectl edit deployment front-end -n spline-reticulator

在编辑器中找到 nginx 容器，添加ports字段（如前文 YAML 片段），保存退出（vim 中按:wq）。

方法 2：YAML 文件修改（可版本控制）

1. 导出现有 Deployment YAML：

kubectl get deployment front-end -n spline-reticulator -o yaml > deploy-old.yaml

1. 复制为deploy-new.yaml，添加ports字段；

1. 应用更新：

kubectl apply -f deploy-new.yaml -n spline-reticulator

验证 Deployment 配置：

# 查看Deployment的Pod模板，确认ports字段已添加kubectl get deployment front-end -n spline-reticulator -o jsonpath='{.spec.template.spec.containers[?(@.name=="nginx")].ports}'# 输出应包含：[{"containerPort":80,"protocol":"TCP","name":"http"}]# 查看新Pod是否创建（滚动更新后，旧Pod会被删除）kubectl get pods -n spline-reticulator -l app=front-end # -l指定Pod标签# 新Pod状态应为Running

步骤 2：创建 front-end-svc NodePort Service

编写 Service YAML（front-end-svc.yaml）

apiVersion: v1kind: Servicemetadata:name: front-end-svcnamespace: spline-reticulatorspec:type: NodePortselector:app: front-end # 与Deployment的Pod标签一致ports:- port: 80 # Service集群内端口（自定义，如80）targetPort: 80 # 指向容器端口（与Deployment的containerPort一致）protocol: TCPname: http应用 Service 配置：kubectl apply -f front-end-svc.yaml -n spline-reticulator

验证 Service 配置：

# 查看Service基本信息，确认类型为NodePortkubectl get svc front-end-svc -n spline-reticulator# 输出示例：# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE# front-end-svc NodePort 10.96.123.45 <none> 80:30080/TCP 5m# 关键信息：PORT(S)中80是Service端口，30080是自动分配的NodePort# 查看Service详情，确认ENDPOINTS有Pod IP（表示已关联Pod）kubectl describe svc front-end-svc -n spline-reticulator# 输出中ENDPOINTS字段应显示Pod的IP:80（如10.244.1.2:80）

步骤 3：验证外部访问（关键）

# 1. 获取集群任意节点的IP（如节点名为node-1，可通过kubectl get nodes -o wide查看）NODE_IP=$(kubectl get nodes -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}')# 2. 获取Service的NodePort（从kubectl get svc的输出中提取，如30080）NODE_PORT=$(kubectl get svc front-end-svc -n spline-reticulator -o jsonpath='{.spec.ports[0].nodePort}')# 3. 外部客户端执行curl，验证是否访问到nginx默认页面curl http://$NODE_IP:$NODE_PORT# 成功输出：nginx的默认HTML页面内容（如"<h1>Welcome to nginx!</h1>"）

六、常见误区与避坑指南

1. Deployment 端口配置错误：

• • 误区：将containerPort设为 8080，但 nginx 实际监听 80；

• • 后果：Service 转发到 8080，出现 “connection refused”；

• • 解决：通过kubectl exec进入 Pod，用netstat -tuln或ss -tuln确认 nginx 监听端口，再修改containerPort。

1. Service 标签选择器不匹配：

• • 误区：Deployment 的 Pod 标签为app: front-end，Service 的selector设为app: frontend（少横杠）；

• • 后果：Service 的ENDPOINTS为空，无法关联 Pod；

• • 解决：执行kubectl get pods -n spline-reticulator --show-labels查看 Pod 标签，确保 Service 的selector完全匹配。

1. 跨命名空间操作：

• • 误区：创建 Service 时未指定-n spline-reticulator，默认创建在default命名空间；

• • 后果：Service 在default命名空间，无法关联spline-reticulator的 Pod；

• • 解决：所有命令添加-n spline-reticulator，或通过kubectl config set-context --current --namespace=spline-reticulator切换默认命名空间。

1. NodePort 端口不可达：

• • 误区：外部客户端能 ping 通节点 IP，但无法访问 NodePort；

• • 可能原因：节点防火墙（如 iptables、firewalld）禁止 30000-32767 端口；

• • 解决：在节点上开放 NodePort 范围（如firewall-cmd --add-port=30000-32767/tcp --permanent，再firewall-cmd --reload）。

七、总结：任务知识链与核心逻辑

完成 “修改 Deployment + 创建 NodePort Service” 的任务，需串联以下知识链：

1. Deployment 端口声明：通过containerPort告知 K8s 容器监听 80/tcp，为 Service 提供目标端口；

1. Service 类型选择：NodePort 类型在节点开放静态端口，实现外部访问；

1. 标签关联：Service 的selector与 Deployment 的 Pod 标签匹配，确保请求能转发到 Pod；

1. 命名空间隔离：所有操作在spline-reticulator命名空间，避免资源混淆；

1. 验证逻辑：从 Deployment 配置→Service 关联→外部访问，逐步验证，确保每个环节生效。

本质上，这一过程是 K8s “声明式 API” 的体现 —— 我们只需定义 “期望状态”（Deployment 暴露 80 端口、Service 为 NodePort 类型），K8s 会自动维护 “实际状态”（滚动更新 Pod、分配 NodePort、关联 Pod），无需手动管理底层细节。掌握这些知识，不仅能完成本次任务，更能应对 “不同服务暴露场景”（如 ClusterIP 用于内部通信、LoadBalancer 用于生产环境），真正理解 K8s 网络模型的核心。