一、使用现状

当前我们服务既有部署在虚机，也有部署在K8S上的，部署在虚机上的服务注册到eureka的地址很好理解，就是虚机的ip地址，那么问题来了，k8s上部署的服务在eureka上提供的地址是什么呢？

直接说答案：是pod的地址。

在K8S上的网络可以配置的，具体待调研，但是无论如何，eureka上注册的地址一定要是可访问的。

二、K8S的网络基础

K8S上的应用运行在容器之中，容器处于 Pod 之内。
每个 Pod 都会附着在同一个大的扁平的 IP 网络之中，被称为 Pod 网络（通常是 VXLAN 叠加网络）。
每个 Pod 都有自己的唯一的 IP 地址，这个 IP 地址在 Pod 网络中是可路由的。

上述三个因素结合起来，让每个应用（应用的组件和服务）无需通过 NAT 之类的网络过程，就能够直接通信。

动态网络
在对应用进行横向扩容时，会在 Pod 网络中加入新的 Pod，新 Pod 自然也伴随着新的 IP 地址；如果对应用进行缩容，旧的 Pod 及其 IP 会被删除。这个过程看起来很是混乱。
应用的滚动更新和撤回也存在同样的情形——加入新版本的新 Pod，或者移除旧版本的旧 Pod。新 Pod 会加入新 IP 到 Pod 网络中，被终结的旧 Pod 会删除其现存 IP。
如果没有其它因素，每个应用服务都需要对网络进行监控，并管理一个健康 Pod 的列表。这个过程会非常痛苦，另外在每个应用中编写这个逻辑也是很低效的。

幸运的是，Kubernetes 用一个对象完成了这个过程——Service。
还有一个值得注意的事情：Kubernetes 执行 IP 地址管理（IPAM）职责，对 Pod 网络上已使用和可用的 IP 地址进行跟踪。

三、K8S的Service

Kubernetes Service 对象在一组提供服务的 Pod 之前创建一个稳定的网络端点，并为这些 Pod 进行负载分配。
一般会在一组完成同样工作的 Pod 之前放置一个 Service 对象。

客户端和 Service 通信，Service 负责把流量负载均衡给 Pod。

在上图中，底部的 Pod 会因为伸缩、更新、故障等情况发生变化，而 Service 会对这些变化进行跟踪。同时 Service 的名字、IP 和端口都不会发生变化。

Service的负载均衡是一个简单的 4 层轮询。它工作在连接层面，所以同一个连接里发起的所有请求都会进入同一个 Pod。因为在 4 层工作，所以对于 7 层的 HTTP 头或者 Cookie 之类的东西是无法感知的。

参考：

一文了解 Kubernetes 中的服务发现

k8s中的网络（较详细汇总）