Service 服务发现的两种方式-通过案例来理解

标签：clust   port   添加   轻松   名称   两种   将不   Kubernete   相关   

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以上）

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

Service 服务发现的两种方式-通过案例来理解

标签：clust   port   添加   轻松   名称   两种   将不   Kubernete   相关   

原文地址：https://www.cnblogs.com/hixiaowei/p/9314934.html