Kubernetes Service 增加第二个端口后报 name: Required value

一个只有单端口的 Service 可以不写端口名称，但往 spec.ports 加入第二项后，提交可能被拒绝：

spec.ports[0].name: Required value
spec.ports[1].name: Required value

这条错误指向 Service 对象的端口定义。修改 Pod 标签、放开防火墙或重启应用，都不能让缺少名称的多端口清单通过校验。对于 apiVersion: v1 的 Service，只定义一个端口时名称可选；定义多个端口时，每项都需要名称，而且在同一 Service 内必须唯一。

名称写在每个 ServicePort 上

metadata.name 是整个 Service 的名字，不能代替 spec.ports[].name。把名称加到第二个端口上也不够：原先省略名称的第一项此时也必须补齐。

下面是一个完整的双端口示例，保存为 service.yaml。app: demo-worker 要替换成实际后端 Pod 标签，两个 targetPort 要对应应用实际监听的端口；示例不要求应用同时使用 HTTP 和 HTTPS。

apiVersion: v1
kind: Service
metadata:
  name: demo-worker
spec:
  type: ClusterIP
  selector:
    app: demo-worker
  ports:
    - name: api
      protocol: TCP
      port: 8080
      targetPort: 8080
    - name: metrics
      protocol: TCP
      port: 9090
      targetPort: 9090

api 和 metrics 用来区分同一 Service 的两组端口。选择小写字母、数字和连字符组成、首尾为字母或数字的稳定名称，不使用空格或下划线，不给两项重复命名。

这里的 name: api 并不要求 Pod 的容器端口也命名为 api。示例的 targetPort 是整数，直接指定后端端口号；只有把 targetPort 写成字符串时，才需要按这个字符串查找 Pod 中对应的命名端口。不要为解决缺少 ServicePort 名称的错误，顺便把原本正确的数字端口改成未经核对的字符串。

核对真正提交的清单

如果使用 Helm、Kustomize 或流水线模板，检查最终生成的 YAML，而不只是模板中某一段。模板条件可能只给其中一个端口生成名称，或者渲染出空的 name。

在支持服务端 dry-run 的当前 kubectl 与集群上，可先提交校验而不保存对象：

kubectl apply --dry-run=server -f service.yaml

命令仍会联系当前 kubeconfig 指向的集群，并经过权限及准入校验。先确认上下文和命名空间正确；使用 Helm 等工具管理对象时，应在原发布流程中修正并检查渲染结果，避免另起一套管理方式。

校验通过后，再按正常变更流程应用清单。若返回新的错误，例如端口号冲突或准入策略拒绝，应按新错误处理；给端口起名只解决名称缺失或重复的问题。

保存成功和服务可用要分别检查

更新后读取实际 Service，确认每个端口都保留了预期名称和映射：

kubectl get service demo-worker -o yaml
kubectl get endpointslices \
  -l kubernetes.io/service-name=demo-worker -o yaml

命令假定对象位于当前命名空间，其他命名空间应显式加 -n。对于示例这种带 selector、由控制器维护端点的 Service，还要检查 EndpointSlice 中的端口与就绪后端，再从原客户端访问各自的业务端口。API 接受 YAML，并不能证明 Pod 已监听端口或网络路径可达。

不要删除并重建 Service 来绕过这条校验。这样做不会免除多端口命名要求，还可能改变分配的地址或端口。对于已在使用的端口名称，应先检查 Ingress、监控或其他配置是否按名称引用它；优先给缺失项补名，保留现有正确映射。需要回退时恢复变更前有效清单及相关引用，不能把一个仍有多个端口的 Service 又改回无名称状态。