存量业务（在虚机中）访问K8S 集群内业务（在容器中）不通，有哪些解决方案？
存量业务（在虚机中）访问K8S 集群内业务（在容器中）不通，（两者业务都使用微服务架构，都已注册到注册中心），除了做虚机和POD的路由、nodeport、hostnetwork等还有哪些解决方案？
场景描述如下：
K8S集群内部POD访问外部虚机是通的。比如使用springcloud框架，容器化后的服务注册的是172网段的IP，外部系统是虚机IP10.0.xx，外部系统服务怎么调用容器服务。外部系统也是注册微服务的，注册后的是10.0.xx的网络地址，10.0.xx要调用172.xx网段服务，这个方式不走ingress。
2同行回答
不过一般容器对外提供服务都是通过Service。一句话：pod不能被外网访问，service是访问入口。
为了适应快速的业务需求，微服务架构已经逐渐成为主流，微服务架构的应用需要有非常好的服务编排支持，k8s中的核心要素Service便提供了一套简化的服务代理和发现机制，天然适应微服务架构，任何应用都可以非常轻易地运行在k8s中而无须对架构进行改动；
Service是Kubernetes里最核心的资源对象之一,Service定义了一个服务的访问入口地址,前端的应用(Pod)通过这个入口地址访问其背后的一组由Pod副本组成的集群实力。 Service与其后端Pod副本集群之间则是通过Label Selector来实现"无缝对接"。而RC的作用实际上是保证Service 的服务能力和服务质量处于预期的标准。
收起
1、macvlan CNI，原生用法比较弱，需要做集中化ipam改造
2、deployment加环境变量参数，微服务的注册中心可以支持应用自上报的IP PORT
浏览1866
- 首先感谢回答问题。1、macvlan最大的问题：受技术原理限制（主要是underlay 2层流量不经过宿主机的3层及以上的协议栈，报文没有用iptables，ipvs处理，所以K8s里的Service、QoS、networkpolicy没法实现） 2、deployment加环境变量参数，对于少量业务可使用此法写个yaml即可，但是对于大量的业务来说，此法需要定制化较多
- 你的存量微服务肯定有自己的存量注册中心，用不上你说的这些：iptables，ipvs处理，K8s里的Service、QoS、networkpolicy
- 只允许有一套注册中心供存量服务和容器化后服务使用，微服务平台是做微服务化+服务治理用，重点是业务管理，但你服务实际运行的载体pod肯定是K8S来管理，重点是基础设施及架构，两者既有互通、分工也要明确