Kubernetes：ContainerPorts真的仅为信息性配置？Service路由实例存疑

首先明确：官方说containerPorts「主要为信息性配置」的描述完全准确，你忽略的是它核心定位和附加实用功能的区别：

• 官方所说的「信息性」，核心指的是它不决定容器端口是否能被网络访问：哪怕你完全不配置containerPorts，只要容器内进程监听了0.0.0.0:8089，集群内其他Pod/节点直接访问Pod IP+8089就能连通，外部也能通过NodePort/LoadBalancer等方式访问——这是containerPorts的核心定位：仅用于向集群声明「这个容器在监听哪些端口」，而非「控制哪些端口可被访问」。

• 你遇到的Service路由失败场景，是用到了containerPorts的附加功能：端口命名映射：
  当你在Deployment的containerPorts里给8089端口命名为web，这个名字就成了该Pod上对应端口的「符号别名」；
  Service的targetPort如果引用这个名字，K8s会去Pod的containerPorts配置里查找匹配的名称，再转发到对应端口；
  一旦拼写错误成webz，K8s找不到对应的别名，自然不知道要把流量转发到Pod的哪个端口，因此路由失败。

反过来验证就能回到官方描述的核心：如果你的Service把targetPort直接写为8089，哪怕完全不配置containerPorts，Service照样能正常把流量转发到容器的8089端口——这说明containerPorts不是路由的必要条件，它的存在主要是提供信息，命名映射只是锦上添花的维护便利，而非核心功能。

总结：官方称它「主要为信息性配置」，是因为它的核心作用是声明信息，命名映射只是附加的实用功能，不能因为这个附加功能的依赖，就否定它的核心定位。

内容的提问来源于stack exchange，提问作者zerohedge