Kubernetes集群中通过容器本地IP提供HTTP端点的方案是否可行？

你这套思路在临时测试环境偶尔跑通是有可能的，但绝对不能上生产，存在非常多致命隐患，完全没利用K8s本身的服务治理能力，稳定性完全没有保障。

• Pod IP是临时可变的，没有任何稳定性可言
  K8s里Pod的IP是动态分配的：Pod重启、滚动更新、节点故障漂移、扩缩容的时候，旧Pod会被销毁，IP会被回收甚至分配给其他完全不相关的Pod。消息队列的消息本身存在消费延迟——如果消息入队后过了几分钟甚至几小时才被消费，你写在消息里的Pod IP大概率已经失效了，要么请求直接超时，要么打到别的服务上返回完全错误的响应，甚至可能误请求到数据库、中间件等敏感服务带来安全风险，根本拿不到文件。
• 完全绕过了K8s的负载均衡与故障转移机制
  你直接把请求打给单个Pod IP，相当于完全弃用了K8s Service的能力：只要你写的那个Pod刚好负载过高、正在下线、本地磁盘故障，请求就直接失败，没有自动重试、切到健康副本的机制，服务可用性根本没法保障。
• 本地存储的文件会随Pod销毁直接丢失
  如果你是把待下载的文件存在Pod的本地磁盘里，那Pod被调度到其他节点、或者重启重建之后，本地存储的文件会直接清空，就算IP没变化，你也找不到之前存的文件。
• 网络访问策略不可控
  大部分生产K8s集群都会配置NetworkPolicy做网络隔离，直接通过Pod IP跨命名空间、跨工作负载访问端口，很可能被网络策略拦截，而且这类网络问题排查成本极高，流量日志都很难追踪。
• 大文件下载场景容错率为0
  如果传输的文件体积较大，下载过程中只要Pod因为资源不足被驱逐、或者被滚动更新逻辑杀掉，下载就会直接中断，没有任何兜底机制。

• 不要在消息里写任何Pod IP这类可变地址，集群内服务访问统一走K8s Service的固定DNS地址，比如你的文件服务叫file-service，部署在default命名空间，固定访问根路径就是http://file-service.default.svc.cluster.local，不管后端Pod怎么变，这个地址永远有效，自带负载均衡和健康检查能力。
• 消息队列里不要传全量下载URL，只传文件的唯一标识、MD5校验值、过期时间这类元信息就够了。消费者拿到消息后，自己用固定的Service地址拼接文件ID构造下载请求就行，从根源上避免地址失效的问题。
• 文件不要存在Pod本地磁盘，统一存到集群内的共享存储（比如分布式文件系统、私有对象存储），所有文件服务的副本都能从共享存储读取文件，不管Pod调度到哪个节点都能正常提供服务。
• 如果确实需要做临时的点对点文件传输，也要给对应Pod打固定标签，通过无头Service配合标签选择器做路由，不要直接硬编码IP。

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