关于DNS的问题？（欢迎有这方面管理经验的大虾回答。）

1,用微软自带的DNS服务器,在添加组件里加上DNS服务

2,打开他,在里面建立区域(aaacom),在里面正向区域里添加主机名(例如abc)

IP地址指向要用这个主机名的电脑,那么abcaaacom就是那个电脑的域名

明白不

XP是没有DNS服务的,需要安装WIN2000 SERVER版或者WIN2003

3,至于原理,就是通过DNS(UDP包)查询DNS主机，DNS主机负责递归解析，先找com的根域，再找aaacom的域（第2点建的那个DNS区域就是aaacom域）从中找到abc这个主机，返回给电脑

答案：A

缓存域名服务器将向其他域名服务器进行域名查询并将查询结果保存在缓存中。缓存域名服务器可以改进网络中DNS服务器性能。当DNS经常查询一些相同目标时，安装缓存域名服务器可以对查询提供更快速响应，而不需要通过主域名服务器或辅助域名服务器。缓存域名服务器因此特别适合于在局域网内部使用，其主要目是提高域名解析速度和节约对互联网访问出口带宽。某些网络连接不鼓励向本地以外发送很大数据流量，这要么是因为网络连接是按流量计费，或网络连接本身是带宽不足。在这样情况下，如果想将发往外部 DNS 流量限制到尽可能小，就需要使用 BIND 转发机制。或者你网络中只有一台机器能连接到 Internet ，而你在这台机器上运行了 BIND ，那么你可以将这台 BIND 作为内部网络中其他 BIND 转发器，也就是转发域名服务器，使得其他 DNS 也能查找 Internet 域名。域名查询转发机制是：当设置了转发器后，所有非本域和在缓存中无法找到域名查询都将转发到设置 DNS 转发器上，由这台 DNS 来完成解析工作并做缓存，因此这台转发器缓存中记录了丰富域名信息。因而对非本域查询，很可能转发器就可以在缓存中找到答案，避免了再次向外部发送查询，减少了流量。

我们创建的service并不存在coredns里面 而是存在了etcd中 当我们请求某个域名的时候 会把请求发给coredns coredns再把请求发给apiserver apiserver 再去etcd中拿取数据返回给dns dns返回给客户端

nginx想要请求后端的tomcat 首先nginx会把tomcat的service地址发送给coredns coredns发给apiserver apiserver去etcd中拿取对应的解析地址返回给coredns nginx从coredns中拿到tomcat的ip地址后就会把客户端请求转发给tomcat

当pod需要访问k8s集群外的域名时 pod还是会把解析请求发给coredns 我们会在coredns里面配置forward转发到我们公司内部的域名服务器（bind） 如果域名是公司内部使用的 bind就会解析此域名并把ip返回给coredns

如果此域名为外部互联网域名 我们还会在bind中配置forward转发到公网dns中进行解析

我们配置service地址段的时候 此地址段的第一个IP默认分发给apiserver 第二个IP默认分发给dns

在kubenetes的安装包中包含了许多组件的yaml模板 我们可以通过模板来安装coredns

打开github搜索kubernetes 选择右下角的release 选择k8s相应版本

https://githubcom/kubernetes/kubernetes

查看_ DNS__DOMAIN _的值 此值为/etc/kubeasz/clusters/qijia01/hosts里面CLUSTER_DNS_DOMAIN的值

查看一下coredns的地址

替换coredns中的k8sgcrio/coredns/coredns:v180镜像为coredns/coredns:180 应为k8sgcrio/coredns/coredns:v180镜像是谷歌的在国外法拉取成功

完整的yaml文件，修改了dns_doman地址 dns_forward地址 coredns镜像 dns地址 内存大小

创建成功

验证域名解析成功

实时修改coredns的副本数,把replicas修改为2

可以看到第二个pod正在启动

node级别 localdns-cache （需要每个node节点都缓存一份，node过多不建议使用）

pod级别 dnsmasq （需要每个pod都缓存一份，pod过多不建议使用）

coredns 延长coredns缓存的时间（最优但是需要消耗内存）

添加一个forword，假如我有一个域名为myserveronline是公司内部使用的测试域名，当k8s中的pod访问这个后缀的域名时 我希望他把解析请求交给内部的bind服务器（172161616:53）

在核心文件Corefile最下面加上forward

删掉再重新创建 也可以直接用apply

使用nslookup测试dns解析,前提是你的 net-test1要有nslookup没有的话需要安装bind-utils

先看一下k8s的版本，然后选择兼容版本的dashboard

https://githubcom/kubernetes/dashboard/releases

dashboard-240支持k8s121

github上面提供了dashboard的镜像还有yaml文件

创建dashboard的pod

查看dashboard的service是否创建成功

我们发现kubernetes-dashboard这个service默认使用的是 ClusterIP ，并没有把443端口给映射到宿主机，所以此端口只能在集群内部使用，我们并没有办法通过浏览器访问

解决方法:在dashboardyaml中找到kubernetes-dashboard 这个service的配置信息并将service的类型改为nodeport，默认是ClusterIP

重新部署后发现service已经把443端口暴露出来了

3004会监听在任意一个宿主机上面（master和node） 因为这些宿主机都是通过apiserver从etcd统一拿取的数据

此时我们可以通过任意一个master或者node的ip加上30004通过https协议来访问dashboard

此时我们需要创建一个登录的账号并且授予权限

查看新建用户的token