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

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的容器中

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不符合规范。

猜你喜欢

转载自www.cnblogs.com/hixiaowei/p/9314934.html