Service 服务发现的两种方式-通过案例来理解+服务外部访问类型+selector-label

1.环境变量

在创建一个Pod时，kubelet在该Pod的所有容器中为当前所有Service添加一系列环境变量。

例如，已存在名称为“redis-master”的Service，它对外暴露6379的TCP端口，且集群IP为10.0.0.11。kubelet会为新建的容器添加以下环境变量：

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379

通过环境变量来创建Service会带来一个不好的结果，即任何被某个Pod所访问的Service，必须先于该Pod创建，否则和这个后创建的Service相关的环境变量，

将不会被加入该Pod的容器中

当Pod运行的时候，Kubernetes会将之前存在的Service的信息通过环境变量写到Pod里面，以Redis Master Service为例，它的信息会被写到新的Pod里面：

"REDIS_MASTER_PORT_6379_TCP=tcp://10.254.189.63:6379",
"REDIS_MASTER_PORT_6379_TCP_PROTO=tcp",
"REDIS_MASTER_PORT_6379_TCP_ADDR=10.254.189.63",
"REDIS_MASTER_SERVICE_PORT=6379",
"REDIS_MASTER_SERVICE_HOST=10.254.189.63",
"REDIS_MASTER_PORT=tcp://10.254.189.63:6379",
"REDIS_MASTER_PORT_6379_TCP_PORT=6379",
1
2
3
4
5
6
7
这种方法有个比较明显的缺陷，Pod必须在Service之后启动，之前启动的Pod将没有这些环境变量。

2.DNS

DNS服务器通过Kubernetes API Server监控与Service相关的活动。当监控到添加Service的时，DNS服务器为每个Service创建一系列DNS记录。

例如：有个叫做”my-service“的service，他对应的kubernetesnamespace为”my-ns“，那么会有他对应的dns记录，叫做”my-service.my-ns“。

那么在my-ns的namespace中的pod都可以对my-service做name解析来轻松找到这个service。在其他namespace中的pod解析”my-service.my-ns“来找到他。

解析出来的结果是这个service对应的cluster ip。

3.集群外部的用户希望Service能够提供一个供集群外用户访问的IP地址。

一个是“NodePort”，另一个是“LoadBalancer”。

每个service都有个type字段，值可以有以下几种：

· ClusterIP：使用集群内的私有ip —— 这是默认值。

· NodePort：除了使用cluster ip外，也将service的port映射到每个node的一个指定内部port上，映射的每个node的内部port都一样。（端口30000~32767）

· LoadBalancer：使用一个ClusterIP & NodePort，但是会向cloud provider申请映射到service本身的负载均衡。

如果将type字段设置为NodePort，kubernetes master将会为service的每个对外映射的port分配一个”本地port“，这个本地port作用在每个node上，且必须符合定义在配置文件中的port范围（为–service-node-port-range）。这个被分配的”本地port“定义在service配置中的spec.ports[*].nodePort字段，如果为这个字段设定了一个值，系统将会使用这个值作为分配的本地port 或者 提示你port不符合规范。

4.label+selector

使用Label可以给对象创建多组标签，Service，RC组件通过Label Selector来选择对象范围，Label 和 Label Selector共同构成了Kubernetes系统中最核心的应用模型，使得对象能够被精细的分组管理，同时实现了高可用性。