Kubernetes--服务发现方式
服务发现方式：环境变量
创建Pod资源时，kubelet会将其所属名称空间内的每个活动的Service对象以一系列环境变量的形式注入其中。它会支持使用Kubernetes Service环境变量以及与Docker的links兼容的变量。
（1）Kubernetes Service环境变量
Kubernetes Service为每个Service资源生成包括以下形式的环境变量在内的一系列环境变量，在同一名称空间中创建的Pod对象都会自动拥有这些变量。
- {SVCNAME}_SERVICE_HOST
- {SVCNAME}_SERVICE_PORT
注意：如果SERVICE中使用了连接线，那么Kubernetes会在定义为环境变量时将其转换为下划线。
（2）Docker Link形式的环境变量
Docker使用 --Link选项是实现容器连接时所设置的环境变量形式，具体使用形式请参考Docker的相关文档。在创建Pod对象时，Kubernetes也会将于此形式兼容的一系列环境变量注入Pod对象中。
例如，在Service资源myapp-svc创建后创建的Pod对象中查看可用的环境变量，其中以MYAPP_SVC_SERVICE开头的表示Kubernetes Service环境变量，名称中不包含“SERVICE”字符串的环境变量为Docker Link形式的环境变量：
/ # printenv | grep MYAPP MYAPP_SVC_PORT_80_TCP_ADDR=10.108.17.20 MYAPP_SVC_PORT_80_TCP_PORT=80 MYAPP_SVC_PORT_80_TCP_PROTO=tcp MYAPP_SVC_PORT_80_TCP=tcp://10.108.17.20:80 MYAPP_SVC_SERVICE_HOST=10.108.17.20 MYAPP_SVC_PORT=tcp://10.108.17.20:80 MYAPP_SVC_SERVICE_PORT=80 / #
基于环境变量的服务发现其功能简单、易用，但存在一定的局限，例如，仅有那些与创建的Pod对象在同一名称空间中且事先存在的Service对象的信息才会以环境变量的形式注入，那些处于非同一名称空间，或者是在Pod资源创建之后才创建的Service对象的相关环境变量则不会被添加。幸而，基于DNS的发现机制并不存在此类限制。
服务发现方式：DNS
创建Service资源对象时，ClusterDNS会为它自动创建资源记录用于名称解析和服务注册，于是，Pod资源可直接使用标准的DNS名称来访问这些Service资源。每个Service对象相关的DNS记录包含如下两个：
- {SVCNAME}.{NAMESPACE}.{CLUSTER_DOMAIN}
- {SVCNAME}.{NAMESPACE}.svc.{CLUSTER_DOMAIN}
另外，“--cluster-dns”指定了集群DNS服务的工作地址，“--cluster-domain”定义了集群使用的本地域名，因此，系统初始化时默认会将“cluster.local.”和主机所在的域“ilinux.io.”作为Dns的本地域使用。例如，在此前创建的用于交互式Pod资源的客户端中查看其配置，命令如下：
/ # cat /etc//resolv.conf nameserver 10.96.0.10 search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5 / #
上述search参数中指定的DNS各搜索域，是以次序指定的几个域名后缀，具体如下所示。
- {NAMESPACE}.svc.{CLUSTER_DOMAIN}：如default.svc.sluster.local。
- svc.{CLUSTER_DOMAIN}：如svc.cluster.local。
- {CLUSTER_DOMAIN}：如cluster.local。
- {WORK_NODE_DOMAIN}：如ilinux.io。
例如，在此之前创建的用于交互式Pod客户端中尝试请求解析myapp-svc的相关DNS记录：
/ # nslookup myapp-svc.default Server: 10.96.0.10 Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local Name: myapp-svc Assress 1: 10.107.208.93 myapp-svc.default.svc.cluster.local
