当浏览器访问某个网站域名或者应用服务通过域名方式访问API接口的时候，需要用IP和port建立TCP连接或者复用底层连接，IP地址的获取依赖对域名的解析，完成解析的角色称为域名解析器（dns resolver）。解析的大致过程就是检查cache是否有该记录，本地hosts文件是否有，都没有命中就查询dns server进行CNAME和A记录的查询。在linux系统下，dns server的IP一般在/etc/resolv.conf文件中。
公司主营业务：成都做网站、网站制作、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联推出嵊泗免费做网站回馈大家。
域名解析常用dig命令，以及在 进行域名解析测试。
考虑到域名IP地址不是经常变动，减少查询dns的冗余，并显著降低高QPS应用服务查询dns的压力(最后一节有benchmark对比)，需要对dns信息进行缓存。因为软件应用不同、开发语言不同、操作系统不同，dns resolver的实现和封装也不同，会遇到不同的层面的cache。比如windows的dns resolver会有cache，linux默认不缓存；go语言可以选择cgo或者自己实现的dns resolver；chrome浏览器也会有自己的cache。
dns cache除了好处以外，也带来了其他问题。比如dns cache可能被恶意病毒修改，将真实IP改成钓鱼网站的IP，对用户进行诱导和钓鱼。还有在服务发现的这种特定场景下，dns cache是不被允许的，会出现IP更新不及时导致API流量的损失和错误，例如部署上线或者宕机，相比之下，运维响应的时长会造成更大的损失。但为了解决这个问题，在client和server端中间增加一层代理，dns记录指向这个代理。如图：
代理职责一般有：
代理一般分为：
四层代理对外暴露的IP一般称为虚IP(VIP)
example_test.go
性能对比：
从对比中可看出：go的pure resolver因没有cache和网络不稳定的因素，总耗时较多。而cgo的resolver比较稳定且耗时较低。
linux或类unix系统是没有操作系统级别的dns cache。除非安装了dnsmasq或者
nscd(Name Service Caching Daemon)，并开启。
从Kubernetes 1.11版本开始，Kubernetes集群的DNS服务由CoreDNS提供。CoreDNS是CNCF基金会的一个项目，是用Go语言实现的高性能、插件式、易扩展的DNS服务端。CoreDNS解决了KubeDNS的一些问题，例如dnsmasq的安全漏洞、externalName不能使用stubDomains设置，等等。
CoreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS。
CoreDNS没有使用多个容器的架构，只用一个容器便实现了KubeDNS内3个容器的全部功能。
从kubernetes官方提供的 coredns.yml 文件中，不难看出coredns服务配置至少需要一个ConfigMap、一个Deployment和一个Service共3个资源对象。ConfigMap coredns 主要配置文件Corefile的内容：
其中主要有二个地方来解析配置
1、这段配置的意思是cluster.local后缀的域名都是kubernetes内部域名，coredns会监控service的变化来修改域名的记录
2、如果coredns没有找到dns记录，则去找 /etc/resolv.conf 中的 nameserver 解析
接下来使用一个带有nslookup工具的Pod来验证DNS服务能否正常工作：
通过nslookup进行测试。
查找defaul命名空间存在的ng-deploy-80服务
如果某个Service属于不同的命名空间，那么在进行Service查找时，需要补充Namespace的名称，组合成完整的域名。下面以查找kubernetes-dashboard服务为例，
众所周知, DNS 服务器用于将域名转换为 IP (具体为啥要转换建议复习下 7 层网络模型). Linux 服务器中 DNS 解析配置位于 /etc/resolv.conf , 在 Pod 中也不例外,
DNS 策略可以逐个 Pod 来设定。当前kubernetes支持这4中DNS 策略
如果我们不填dnsPolicy, 默认策略就是 ClusterFirst 。
kubelet 在起 pause 容器的时候，会将其 DNS 解析配置初始化成集群内的配置。配置: 它的 nameserver 就是指向 coredns 的
k8s里面有4种DNS策略， 而coredns使用的DNS策略就是Default， 这个策略的意思就是继承宿主机上的/etc/resolve.conf, 所以coredns Pod 里面的/etc/resolve.conf 的内容就是宿主机上的内容。
在集群中 pod 之间互相用 svc name 访问的时候，会根据 resolv.conf 文件的 DNS 配置来解析域名，下面来分析具体的过程。
pod 的 resolv.conf 文件主要有三个部分，分别为 nameserver、search 和 option。而这三个部分可以由 K8s 指定，也可以通过 pod.spec.dnsConfig 字段自定义。
nameserver
resolv.conf 文件的第一行 nameserver 指定的是 DNS 服务的 IP，这里就是 coreDNS 的
clusterIP：
也就是说所有域名的解析，都要经过coreDNS的虚拟IP 10.100.0.2 进行解析， 不论是内部域还是外部域名。
search 域
resolv.conf 文件的第二行指定的是 DNS search 域。解析域名的时候，将要访问的域名依次带入 search 域，进行 DNS 查询。
比如我要在刚才那个 pod 中访问一个域名为 ng-deploy-80的服务，其进行的 DNS 域名查询的顺序是：
options
resolv.conf 文件的第三行指定的是其他项，最常见的是 dnots。dnots 指的是如果查询的域名包含的点 “.” 小于 5，则先走 search 域，再用绝对域名；如果查询的域名包含点数大于或等于 5，则先用绝对域名，再走 search 域。K8s 中默认的配置是 5。
也就是说，如果我访问的是 a.b.c.e.f.g ，那么域名查找的顺序如下：
通过 svc 访问
在 K8s 中，Pod 之间通过 svc 访问的时候，会经过 DNS 域名解析，再拿到 ip 通信。而 K8s 的域名全称为 "service-name.namespace.svc.cluster.local"，而我们通常只需将 svc name 当成域名就能访问到 pod，这一点通过上面的域名解析过程并不难理解。
参考
（1）K8S落地实践 之 服务发现（CoreDNS）
（2）自定义 DNS 服务
（3）Kubernetes 服务发现之 coreDNS
（4）Kubernetes 集群 DNS 服务发现原理
（5）Kubernetes之服务发现和域名解析过程分析
当客户端在 发出POST请求时/albums，您希望将请求正文中描述的专辑添加到现有专辑数据中。
为此，您将编写以下内容：
1、编写代码
a.添加代码以将专辑数据添加到专辑列表。
在此代码中：
1）用于Context.BindJSON 将请求正文绑定到newAlbum。
2） album将从 JSON 初始化的结构附加到albums 切片。
3）向响应添加201状态代码，以及表示您添加的专辑的 JSON。
b.更改您的main函数，使其包含该router.POST函数，如下所示。
在此代码中：
1）将路径中的POST方法与 /albumspostAlbums函数相关联。
使用 Gin，您可以将处理程序与 HTTP 方法和路径组合相关联。这样，您可以根据客户端使用的方法将发送到单个路径的请求单独路由。
a.如果服务器从上一节开始仍在运行，请停止它。
b.从包含 main.go 的目录中的命令行，运行代码。
c.从不同的命令行窗口，用于curl向正在运行的 Web 服务发出请求。
该命令应显示添加专辑的标题和 JSON。
d.与上一节一样，使用curl检索完整的专辑列表，您可以使用它来确认添加了新专辑。
该命令应显示专辑列表。
当客户端向 发出请求时GET /albums/[id]，您希望返回 ID 与id路径参数匹配的专辑。
为此，您将：
a.在您在上一节中添加的函数下方postAlbums，粘贴以下代码以检索特定专辑。
此getAlbumByID函数将提取请求路径中的 ID，然后找到匹配的专辑。
在此代码中：
（1）Context.Param用于从 URL 中检索id路径参数。当您将此处理程序映射到路径时，您将在路径中包含参数的占位符。
（2）循环album切片中的结构，寻找其ID 字段值与id参数值匹配的结构。如果找到，则将该album结构序列化为 JSON，并将其作为带有200 OK HTTP 代码的响应返回。
如上所述，实际使用中的服务可能会使用数据库查询来执行此查找。
（3）如果找不到专辑，则返回 HTTP 404错误。
b.最后，更改您的main，使其包含对router.GET的新调用，路径现在为/albums/:id ，如以下示例所示。
在此代码中：
（1）将/albums/:id路径与getAlbumByID功能相关联。在 Gin 中，路径中项目前面的冒号表示该项目是路径参数。
a.如果服务器从上一节开始仍在运行，请停止它。
b.在包含 main.go 的目录中的命令行中，运行代码以启动服务器。
c.从不同的命令行窗口，用于curl向正在运行的 Web 服务发出请求。
该命令应显示您使用其 ID 的专辑的 JSON。如果找不到专辑，您将收到带有错误消息的 JSON。
恭喜！您刚刚使用 Go 和 Gin 编写了一个简单的 RESTful Web 服务。
本节包含您使用本教程构建的应用程序的代码。
