K8s 服务发现：环境变量和DNS

K8s 服务发现：环境变量和DNS

环境变量

创建Pod资源时，kubectl会将其所属名称空间内的每个活动的Service对象以一系列环境变量的形式注入其中。它支持使用Kubernetes Service Service环境变量以及与Docker的links兼容的变量。 Kubernetes Service环境变量 Kubernetes为每个Service资源生成包括以下形式的环境变量在内的一系列环境变量，在同一名称空间中创建的Pod对象都会自动拥有这些变量：{SVCNAME}_SERVICE_HOST、{SVCNAME}_SERVICE_PORT。 Docker Link形式的环境变量 Docker使用–link选项实现容器连接时所设置的环境变量形式。在创建Pod对象时，K8S也会将与此形式兼容的一系列环境变量注入Pod对象中。例如，在Service资源myapp-svc创建后创建的pod对象中查看可用的环境变量，其中以MYAPP_SVC_SERVICE开头的表示K8S环境变量，名称中不包含SERVICE字符串的环境变量为Docker Link形式的环境变量：

printenv | grep MYAPPMYAPP_SVC_PORT_80_TCP_ADDR=10.107.208.93MYAPP_SVC_PORT_80_TCP_PORT=80...MYAPP_SVC_SERVICE_HOST=10.107.208.93...

DNS

k8s系统之上用于名称解析和服务发现的ClusterDNS是集群的核心附件之一。集群中创建的每个Service对象，都会由其自动生成相关的资源记录。默认情况下，集群内各Pod资源会自动配置其作为名称解析服务器，并在其DNS搜索列表中包含它所属名称空间的域名后缀。 无论是使用kubeDNS还是CoreDNS，它们提供的基于DNS的服务发现解决方案都会负责解析以下资源记录类型以实现服务发现。 （1）拥有ClusterIP的Service资源，需要具有以下类型的资源记录 A记录：​​​..svc.. IN a ​​​ SRV记录：​​_._...svc.. IN SRV ..svc.​​ PTR记录：​​....in-addr-arpa. IN PTR ..svc.​​ （2）Headless类型的Service资源，需要具有以下类型的资源记录。 A记录：​​..svc.. IN a ​​ SRV记录：​​_._...svc.. IN SRV ...svc.​​ PTR记录：​​....in-addr-arpa. IN PTR ...svc.​​ （3）ExternalName类型的service资源，需要具有CNAME类型的资源记录 CNAME记录：​​..svc.. IN CNAME ​​

基于DNS服务发现不受Serivce资源所在的名称空间和创建时间的限制 创建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创建时以DNS配置的相关信息注入它的/etc/resolv.conf配置文件中。

cat /etc/resolv.confnameserver 10.96.0.10search default.svc.cluster.local svc.cluster.local cluster.local ilinux.io

上述search参数中指定的DNS各搜索域，是以次序指定的几个域名后缀，具体如下所示： {NAMESPACE}.svc.{CLUSTER_DOMAIN}：如default.svc.cluster.local svc.{CLUSTER_DOMAIN}：如svc.cluster.local {CLUSTER_DOMAIN}：如cluster.local {WORK_NODE_DOMAIN}：如ilinux.io

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。