kubernetes的service和pod是如何关联的？

kubernetes的service和pod是如何关联的？

kubernetes为我们提供了更方便管理容器的方式，大服务集群环境下不需要开发人员去关注底层的网络层逻辑，就能创建出一个稳定的集群服务。

下图说明了pod和service的关联原理图，且说明了服务之间通信数据转发的原理

创建有副本的pod

当我们创建pod时，仅仅是创建了pod，要为其创建rc（ReplicationController)，他才会有固定的副本。

创建service

然后为其创建service，集群内部才能访问该pod，使用 NodePort 或者 LoadBalancer 类型的 Service，外部网络也可以访问该pod；每个 service 会创建出来一个虚拟 ip，通过访问 vip:port 就能获取服务的内容（内部访问，因为这是一个vip，外部无法访问的）创建service时，其配置文件中的selector:指定后端绑定的pod，

例如serviceA的

selector:app：aenv：dev

podA

labels：app：aenv：dev

podB

labels：app：aenv：dev那么我们的serviceA 就会绑定podA,podB，绑定的pod的ip会填写到serviceA的endpoint中，内部访问（vip：port方式访问）serviceA，根据serviceA的vip：port直接访问，serviceA会随机的将服务转发给后端的pod（podA，podB）已上实现是通过kube-proxy实现的，kube-proxy默认使用iptables模，实际中使用ipvs会更实用；

kube-proxy的模式

userspace: client -> iptables -> kube-proxy -> backend pod(rr), iptables只是把虚ip转换成kube-proxy的ip，通过kube-proxy自己维护的不同端口来轮询转发到后端的pod上。iptables: client -> iptables -> backend pod(random)，kube-proxy只是监听master上service的创建，之后动态添加/删除本机上的iptables规则ipvs: client -> ipvs ->backend pod, ipvs是一个内核模块

在ipvs模式下，kube-proxy监听API Server中service和endpoint的变化情况，调用netlink接口创建相应的ipvs规则，并定期将ipvs规则与Kubernetes服 Services和Endpoints同步。保证IPVS状态。当访问Services时，IPVS将流量定向到后端pod之一。

ipvs 为大型集群提供了更好的可扩展性和性能ipvs 支持比 iptables 更复杂的负载均衡算法（最小负载、最少连接、加权等等）ipvs 支持服务器健康检查和连接重试等功能

服务发现

在k8s中用了两个方案让服务使用方找到我们定义的Service：环境变量 和 DNS。

环境变量每当有service被创建出来之后，各个node(宿主机)上的kubelet，就会把service name加到自己宿主机的环境变量中，供所有Pod使用。环境变量的命名规则是

{SERVICE_NAME}_SERVICE_HOST,

${SERVICE_NAME}SERVICE_PORT，其中SERVICE_NAME是新serviceName的大写形式，serviceName中的横杠-会被替换成下划线.使用环境变量有一个隐含的创建顺序，即服务使用方在通过环境变量访问一个service的时候，这个service必须已经存在了。使用env命令可以看到pod内部有很多kubernetes内部组件的环境变量

DNS这是官方不推荐的做法，推荐用来跟k8s的外部服务进行交互。