即使只有一个pod，也要使用service。service起到负载均衡器的作用，通过proxy和selector决定服务请求传递给后端的哪个pod。然后对外提供固定的IP和port，所以即使redis master pod迁移变化也没有影响。

（1）redis master service

附件略。

注释里的，和redis-master的label对应，是指哪个labels？

 

 

现在出现labels的地方：

redis-master-controller.yaml

 

redis-master-service.yaml

 

所以究竟是和谁的labels对应？

 

RC中的label：

参看书《kubernetes的权威指南》的p58.

被RC管控的所有pod实例，都是通过RC里定义的pod模板创建的。

改模板包含pod的标签属性，同时RC里包含一个标签选择器label selector，它的值表明了该RC所关联的pod。

RC会保证每个由它创建的pod都包含与它的selector label匹配的label。

 

所以说，RC里的selector与模板里的label是一致的咯？是的。

可是RC自己的label又是什么？

同样是p58，例子显示RC自己的label不与selector与template下的label相同。

 

service中的label:

参看书《kubernetes权威指南》的p65.

service.yaml文件和RC.yaml文件一样，都有两个和label相关的东西。

一个是自己的label，一个是selector。

selector中的标签和某些pod的label相同，表示service将这些pod纳入了集合。对他们进行一些port的设置。

 

所以这段话的意思是：

 

service将所有标签为redis-master（selector的值）的pod作为一个集合来处理。将这个集合里的所有pod的6379端口（port）映射到节点本地的6379端口（targetport）。

并且service还会获得一个clusterIP。

其实service可以看做pod的一个小组，这个小组里的所有pod有共同的标签。

 

综上所述：

有三个值。

（1）RC的label，与他人无关。

（2）service的label，与他人无关。

（3）pod的label，将会出现三次。RC的template里有个label，以及RC的selector值，Service的selector值。

template里的label=redis，表示rc创建的pod标签为redis。

RC和service里的selector=redis，表示rc和service将会管理标签为redis的pod。