k8s原生dns在istio场景的问题
dns的作用
DNS解析是Kubernetes上任何应用程序基础架构的重要组成部分.当您的应用程序代码尝试访问Kubernetes集群中的另一个服务甚至是Internet上的服务时,它必须先查找与该服务的主机名相对应的IP地址,然后再启动与该服务的连接.此名称查找过程通常称为服务发现。在Kubernetes中,server(无论是kube-dnsCoreDNS还是CoreDNS)将服务的主机名解析为唯一的不可路由的虚拟IP(VIP),如果它是clusterIP类型的服务.在kube-proxy每个节点上这个VIP映射到该服务的一组pod,并随机选择一个pod进行转发。使用服务网格时,边车的工作原理就流量转发而言与kube-proxy相同。
下图描述了当今DNS的作用:
DNS带来的问题
尽管DNS在服务网格中的作用似乎微不足道,但它始终代表着将网格扩展到VM并实现无缝多集群访问的方式。
虚拟机访问Kubernetes服务
考虑到VM带有sidecar的情况。如下图所示,VM上的应用程序会查找Kubernetes集群内服务的IP地址,因为它们通常无法访问集群的DNS服务器。
如果有人愿意参与一些涉及dnsmasq和使用NodePort服务对kube-dns进行外部暴露的复杂变通方法,从技术上讲,可以在虚拟机上使用kube-dns作为域名服务器:假设您设法说服集群管理员这样做.即使这样,您仍在打开许多安全问题的大门.归根结底,对于那些组织能力和领域专业知识有限的人来说,这些解决方案通常超出范围。
没有VIP的外部TCP服务
不仅网状网络中的VM遭受DNS问题。为了使Sidecar能够准确地区分网格外部的两个不同TCP服务之间的流量,这些服务必须位于不同的端口上,或者它们需要具有全局唯一的VIP,就像clusterIP分配给Kubernetes服务一样。但是,如果没有VIP,该怎么办？云托管服务(例如托管数据库)通常没有VIP。取而代之的是,提供者的DNS服务器返回实例IP之一,然后可由应用程序直接访问这些实例IP。例如,考虑以下两个服务条目,它们指向两个不同的AWS RDS服务:
Copy apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: db1
namespace: ns1
spec:
hosts:
- mysql–instance1.us-east-1.rds.amazonaws.com
ports:
- name: mysql
number: 3306
protocol: TCP
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: db2
namespace: ns1
spec:
hosts:
- mysql–instance2.us-east-1.rds.amazonaws.com
ports:
- name: mysql
number: 3306
protocol: TCP
resolution: DNS 边车上有一个监听器 0.0.0.0:3306,该监听器从公共DNS服务器查找mysql-instance1.us-east1.rds.amazonaws.com的IP地址并将流量转发给它。它无法将流量路由至db2因为它无法区分到达的流量 0.0.0.0:3306是绑定db1还是绑定db2。实现此目的的唯一方法是将解析设置为NONE,使Sidecar将端口上的所有流量盲目转发3306到应用程序请求的原始IP。这类似于在防火墙上打一个洞,使所有流量都可以3306传入端口,而与目标IP无关。为了使流量畅通,现在您不得不在系统的安全性上做出妥协。
为远程集群中的服务解析DNS
多集群网格的DNS限制是众所周知的。如果没有笨拙的解决方法(例如在调用方名称空间中创建存根服务),则一个集群中的服务无法查找其他集群中服务的IP地址。
控制DNS
总而言之,DNS在Istio中一直是一个棘手的问题。现在是时候杀死那只野兽了。我们(Istio网络团队)决定以对您(最终用户)完全透明的方式彻底解决该问题。我们的首次尝试涉及利用Envoy的DNS代理。事实证明这是非常不可靠的,并且由于Envoy使用的c-ares DNS库普遍缺乏复杂性,因此总体上令人失望。为了解决这个问题,我们决定在Go语言编写的Istio sidecar代理中实现DNS代理。我们能够优化实现,以处理我们要解决的所有场景,而不会影响规模和稳定性。我们使用的Go DNS库与可扩展DNS实现(例如CoreDNS,Consul,Mesos等)使用的库相同。
从Istio 1.8开始,Sidecar上的Istio代理将附带由Istiod动态编程的缓存DNS代理。Istiod基于Kubernetes服务和集群中的服务条目,为应用程序可以访问的所有服务推送主机名到IP地址的映射。来自应用程序的DNS查找查询被Pod或VM中的Istio代理透明地拦截并提供服务。如果查询是针对网格中的服务,则无论该服务所在的集群是什么,代理都会直接对应用程序做出响应。如果不是,它将查询转发到/etc/resolv.conf中定义的上游域名服务器。下图描述了当应用程序尝试使用其主机名访问服务时发生的交互。
正如您将在以下各节中看到的那样,DNS代理功能已在Istio的许多方面产生了巨大的影响。
降低DNS服务器的负载并提高解析度
集群中Kubernetes DNS server上的负载急剧下降,因为Istio在Pod内几乎解决了所有DNS查询。集群上的网格使用范围越大,DNS服务器上的负载就越小。在Istio代理中实现自己的DNS代理使我们能够实现出色的优化,例如CoreDNS auto-path,而不会出现CoreDNS当前面临的正确性问题。
要了解此优化的影响,让我们在标准Kubernetes集群中采用简单的DNS查找方案,而无需为Pod进行任何自定义DNS设置-即,默认/etc/resolv.conf中设置为ndots:5。当您的应用程序启动DNS查找 productpage.ns1.svc.cluster.local时,它会在按原查询主机之前将DNS搜索名称空间作为DNS查询的一部分附加在/etc/resolv.conf(例如ns1.svc.cluster.local)中。结果,实际上发出的第一个DNS查询看起来像 productpage.ns1.svc.cluster.local.ns1.svc.cluster.local,当不涉及Istio时,它将不可避免地使DNS解析失败。如果您 /etc/resolv.conf有5个搜索名称空间,则应用程序将为每个搜索名称空间发送两个DNS查询,一个用于IPv4 A记录,另一个用于IPv6 AAAA记录,然后是最后一对查询,其中包含代码中使用的确切主机名。在建立连接之前,该应用程序将为每个主机执行12个DNS查找查询！
使用Istio实现的CoreDNS样式自动路径技术,Sidecar代理将检测到在第一个查询中查询的真实主机名,并将cname记录 返回productpage.ns1.svc.cluster.local为该DNS响应的一部分以及的A/AAAA记录 productpage.ns1.svc.cluster.local。现在,收到此响应的应用程序可以立即提取IP地址,并继续建立与该IP的TCP连接。Istio代理中的智能DNS代理将DNS查询数量从12个大大减少到2个！
虚拟机到Kubernetes集成
由于Istio代理对网格内的服务执行了本地DNS解析,因此从VM进行的Kubernetes服务的DNS查找查询现在将成功完成,而无需笨拙的变通办法来暴露kube-dns 到集群外部。现在,无缝解析集群中内部服务的能力将简化您到微服务的旅程,因为VM现在可以访问Kubernetes上的微服务,而无需通过API网关进行其他级别的间接访问。
尽可能自动分配VIP
您可能会问,代理中的此DNS功能如何解决区分在同一端口上没有VIP的多个外部TCP服务的问题？
从Kubernetes获得启发,Istio现在将自动将不可路由的VIP(来自E类子网)分配给此类服务,只要它们不使用通配符主机即可。边车上的Istio代理将使用VIP作为来自应用程序的DNS查找查询的响应。现在,Envoy可以清楚地区分绑定到每个外部TCP服务的流量,并将其转发到正确的目标。通过引入DNS代理,您将不再需要resolution: NONE用于非通配TCP服务,从而改善了整体安全性。Istio在通配符外部服务(例如*.us-east1.rds.amazonaws.com)方面无济于事。您将不得不诉诸NONE解析模式来处理此类服务。
多集群DNS查找
对于喜欢冒险的人来说,尝试编织一个多集群网格,其中应用程序直接调用远程集群中名称空间的内部服务,DNS代理功能非常方便。您的应用程序可以解析任何名称空间中任何集群上的Kubernetes服务,而无需在每个集群中创建存根Kubernetes服务。
DNS代理的优势超出了Istio当前描述的多集群模型。在Tetrate,我们在客户的多集群部署中广泛使用此机制,以使Sidecar能够为网格中所有集群的入口网关处暴露的主机解析DNS,并通过相互的TLS访问它们。
istio DNS实现原理
简介
在istio1.8中为了支持DNS解析功能,并且实现了dns cache,不需要通过search域进行多次查询,例如解析bar.foo.svc.cluster.local可能需要依次解析bar.foo.svc.cluster.local.foo.svc.cluster.local/bar.foo.svc.cluster.local.svc.cluster.local/bar.foo.svc.cluster.local.cluster.local/bar.foo.svc.cluster.local,这是因为search域的配置影响,而istio pilot-agent dns代理则只需要一次解析,提高了解析速度。
为了支持dns cache,则需要控制面下发网格内部的现有服务的域名IP配置到agent,为了解决数据传输问题引入了NDS(NameTable Service Discovery)协议,其url定义为type.googleapis.com/istio.networking.nds.v1.NameTable。
本位将探索NDS资源的下发方式及客户端的dns解析原理
pilot-agent
在通过以下方式安装istio后
Copy istioctl install --set profile=demo --set meshConfig.defaultConfig.proxyMetadata.ISTIO_META_DNS_CAPTURE='\"true\"' pilot-agent的istio-iptables将在添加iptables规则时将53的dns请求重定向到pilot-agent同时启动dns server
Copy func (sa *Agent) initLocalDNSServer(isSidecar bool) (err error) {
if sa.cfg.DNSCapture && sa.cfg.ProxyXDSViaAgent && isSidecar {
if sa.localDNSServer, err = dns.NewLocalDNSServer(sa.cfg.ProxyNamespace, sa.cfg.ProxyDomain); err != nil {
return err
}
sa.localDNSServer.StartDNS()
}
return nil
} NewLocalDNSServer
根据集群域及命名空间获取LocalDNSServer
Copy func NewLocalDNSServer(proxyNamespace, proxyDomain string) (*LocalDNSServer, error) {
h := &LocalDNSServer{
proxyNamespace: proxyNamespace,
}
// proxyDomain可以包含使其成为冗余的名称空间.我们只需要.svc.cluster.local部分
parts := strings.Split(proxyDomain, ".")
if len(parts) > 0 {
if parts[0] == proxyNamespace {
parts = parts[1:]
}
h.proxyDomainParts = parts
h.proxyDomain = strings.Join(parts, ".")
}
// 使用本地的resolv.conf作为dns代理配置
dnsConfig, err := dns.ClientConfigFromFile("/etc/resolv.conf")
if err != nil {
log.Warnf("failed to load /etc/resolv.conf: %v", err)
return nil, err
}
// 与传统的DNS解析器不同,不需要将搜索名称空间附加到查询再解析。这是因为代理充当应用程序进行的DNS查询的DNS拦截器。应用程序的解析器已经向我们发送了DNS查询,每个DNS搜索名称空间都有一个。我们只需要在本地命名表中检查此名称是否存在.如果没有,我们会将查询原样转发给上游解析器。
if dnsConfig != nil {
for _, s := range dnsConfig.Servers {
h.resolvConfServers = append(h.resolvConfServers, s+":53")
}
h.searchNamespaces = dnsConfig.Search
}
if h.udpDNSProxy, err = newDNSProxy("udp", h); err != nil {
return nil, err
}
if h.tcpDNSProxy, err = newDNSProxy("tcp", h); err != nil {
return nil, err
}
return h, nil
} newDNSProxy
将LocalDNSServer作为resolver传递给对应的tcp和udp proxy
StartDNS
分别启动tcpDNSProxy和udpDNSProxy
ServeDNS
对于miekg/dns来说handler需要实现ServeDNS也就是LocalDNSServer的ServeDNS方法
Copy func (h *LocalDNSServer) ServeDNS(proxy *dnsProxy, w dns.ResponseWriter, req *dns.Msg) {
var response *dns.Msg
if len(req.Question) == 0 {
response = new(dns.Msg)
response.SetReply(req)
response.Rcode = dns.RcodeNameError
} else {
// 获取 LookupTable
lp := h.lookupTable.Load()
if lp == nil {
response = new(dns.Msg)
response.SetReply(req)
response.Rcode = dns.RcodeNameError
_ = w.WriteMsg(response)
return
}
lookupTable := lp.(*LookupTable)
var answers []dns.RR
//获取要解析的主机名
hostname := strings.ToLower(req.Question[0].Name)
// 判断LookupTable中是否存在,存在则直接返回
answers, hostFound := lookupTable.lookupHost(req.Question[0].Qtype, hostname)
if hostFound {
response = new(dns.Msg)
response.SetReply(req)
response.Answer = answers
if len(answers) == 0 {
// 我们在预编译的已知主机列表中找到了该主机,但是该查询类型没有有效记录.所以返回NXDOMAIN
response.Rcode = dns.RcodeNameError
}
} else {
// 我们没有在内部缓存中找到主机.向上游查询并按原样返回响应。
response = h.queryUpstream(proxy.upstreamClient, req)
}
}
_ = w.WriteMsg(response)
} 更新本地缓存
Copy if p.localDNSServer != nil && len(resp.Resources) > 0 {
var nt nds.NameTable
// TODO we should probably send ACK and not update nametable here
if err = ptypes.UnmarshalAny(resp.Resources[0], &nt); err != nil {
log.Errorf("failed to unmarshall name table: %v", err)
}
p.localDNSServer.UpdateLookupTable(&nt)
} 通过UpdateLookupTable更新localDNSServer数据
pilot-discovery
在istio的xds实现中分为以下两个channel
pushChannel 用于主动推送xds数据变更
他们最终都将调用 pushXds
pushXds
Copy func (s *DiscoveryServer) pushXds(con *Connection, push *model.PushContext,
currentVersion string, w *model.WatchedResource, req *model.PushRequest) error {
if w == nil {
return nil
}
gen := s.findGenerator(w.TypeUrl, con)
if gen == nil {
return nil
}
t0 := time.Now()
cl := gen.Generate(con.proxy, push, w, req)
if cl == nil {
// If we have nothing to send, report that we got an ACK for this version.
if s.StatusReporter != nil {
s.StatusReporter.RegisterEvent(con.ConID, w.TypeUrl, push.Version)
}
return nil // No push needed.
}
defer func() { recordPushTime(w.TypeUrl, time.Since(t0)) }()
resp := &discovery.DiscoveryResponse{
TypeUrl: w.TypeUrl,
VersionInfo: currentVersion,
Nonce: nonce(push.Version),
Resources: cl,
}
err := con.send(resp)
if err != nil {
recordSendError(w.TypeUrl, con.ConID, err)
return err
}
// Some types handle logs inside Generate, skip them here
if _, f := SkipLogTypes[w.TypeUrl]; !f {
adsLog.Infof("%s: PUSH for node:%s resources:%d", v3.GetShortType(w.TypeUrl), con.proxy.ID, len(cl))
}
return nil
} 通过对应的TypeUrl,获取对应的Generator
Copy s.findGenerator(w.TypeUrl, con) 然后从根据客户端的配置生产成对应的资源
Copy cl := gen.Generate(con.proxy, push, w, req) 对于nds服务发现类型其对应的url为type.googleapis.com/istio.networking.nds.v1.NameTable 其对应的Generate实现为
Copy func (n NdsGenerator) Generate(proxy *model.Proxy, push *model.PushContext, w *model.WatchedResource, req *model.PushRequest) model.Resources {
if !ndsNeedsPush(req) {
return nil
}
nt := n.Server.ConfigGenerator.BuildNameTable(proxy, push)
if nt == nil {
return nil
}
resources := model.Resources{util.MessageToAny(nt)}
return resources
} 其主要逻辑为BuildNameTable,获取nametable序列化后返回给客户端
BuildNameTable
BuildNameTable生成一个主机名及其关联的IP的表,然后代理可以使用该表来解析DNS.此逻辑始终处于活动状态.但是,只有在代理中启用DNS捕获后,本地DNS解析才会生效
Copy func (configgen *ConfigGeneratorImpl) BuildNameTable(node *model.Proxy, push *model.PushContext) *nds.NameTable {
// 只对sidecar类型的代理生效
if node.Type != model.SidecarProxy {
return nil
}
out := &nds.NameTable{
Table: map[string]*nds.NameTable_NameInfo{},
}
for _, svc := range push.Services(node) {
目前无法解析泛域名
if svc.Hostname.IsWildCarded() {
continue
}
svcAddress := svc.GetServiceAddressForProxy(node, push)
var addressList []string
//对于headless svc或者对于自动分配的serviceentry此处未指定IP,缺乏对有状态应用解析的支持
if svcAddress == constants.UnspecifiedIP {
// 用ep填充
if svc.Attributes.ServiceRegist ry == string(serviceregistry.Kubernetes) &&
svc.Resolution == model.Passthrough && len(svc.Ports) > 0 {
for _, instance := range push.ServiceInstancesByPort(svc, svc.Ports[0].Port, nil) {
addressList = append(addressList, instance.Endpoint.Address)
}
}
if len(addressList) == 0 {
continue
}
} else {
addressList = append(addressList, svcAddress)
}
nameInfo := &nds.NameTable_NameInfo{
Ips: addressList,
Registry: svc.Attributes.ServiceRegistry,
}
if svc.Attributes.ServiceRegistry == string(serviceregistry.Kubernetes) {
nameInfo.Namespace = svc.Attributes.Namespace
nameInfo.Shortname = svc.Attributes.Name
}
out.Table[string(svc.Hostname)] = nameInfo
}
return out
} 
