dns

Kubernetes之Service https://blog.lecury.cn/2016/06/20/Kubernetes之Service/ 在Kubernetes中Pod是终将消失的，从创建到销毁的过程中，它们是无法自动重启的。而ReplicationController可以用来动态的创建和销毁Pod（比如说在进行滚动升级的时候，可以进行扩展和收缩）。每一个Pod都得到一个属于自己的IP，但这些IP不能一直有效存在，因为这些IP随着Pod的销毁而变得没有了意义。那么这就导致了一个问题，如果一些Pods为集群内部的其他Pods（我们称它们为前端）提供服务，那么这些前端怎么发现、追踪这些后端集合中的服务呢？Service就是做这个事情的。 Service是一个抽象概念，它定义了一些逻辑上的Pods集合，并且定义了访问这些Pods集合的策略，也被称作为micro-service。Service通常通过Label标签选择器来对应相应的Pods集合（也有一些没有标签选择器的，请看下文介绍）。 举个例子，考虑一个运行的镜像，它在集群中有三个副本，这些副本是可以相互替代的，前端并不关心它现在与哪个后端服务打交道。实际上Pods组成的后端服务集合可以是变化的，比如说通过scale进行副本增加或者副本减少，但我们的前端不应该关心或者跟踪后端服务的变化，Service这一层抽象可以做到这一点。

1、简述DNS服务器原理，并搭建主-辅服务器。 DNS服务器原理 1、本机发出DNS请求到本地DNS服务器。本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。 2、本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果。如果没有，本地DNS服务器还要向DNS根服务器进行查询。 3、根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，可以到域服务器上去继续查询，并给出域服务器的地址。 4、本地DNS服务器继续向域服务器发出请求，如果请求对象是.com域服务器。.com域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名的解析服务器的地址。 5、最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系； 6、本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。 主--辅实验： 主：192.168.43.107 辅：192.168.43.127 主dns服务器： 1、安装bind [root@dns1~]#yum -y install bind 2、改配置 [root@dns1~]#vim /etc/named.conf listen-on port

前言 dubbo是一个成熟且被广泛运用的框架。饶是如此,在某些极端条件下基于dubbo的应用还会出现无法重连zookeeper的问题。由于此问题容易导致比较大的故障，所以笔者费了一番功夫去定位，现将排查过程写成博文分享出来。 Bug现场 这是一起在测试环境出现的故障。起因是网工做交换机切换演练，可能由于姿势不对，使得断网的时间从预估的秒级达到了分钟级。等网络恢复后，测试环境就炸开了锅，基本上所有应用再也无法提供服务，在dubbo控制台上也看不到任何提供者，他们和zk的连接都断开而且似乎完全没有重连的迹象。如下图所示: 无法快速恢复 为了不影响测试的进度，运维同学紧急进行了重启，但坑爹的是大部分系统都有启动依赖，盲目的重启只会因为xxx provider不存在而无法启动。只能从最基础的服务开始重启，慢慢恢复。如下图所示: 还好只是测试环境，但为了不让产线出现这种问题，必须一查到底，把这个Bug揪出来。 着手排查 模拟zookeeper连接断开 测试环境的好处是我们可以用各种手段去模拟复现，而不用和处理产线一样到处寻找蛛丝马迹然后进行逻辑推理(推理是一个非常烧脑的过程)。于是笔者联系了SA同学，通过iptables进行线下的断网模拟。命令如下所示: // 禁用本机和zk三台机器的流量进出 iptables -A INPUT -s zk-1-ip/32 -j DROP iptables

在上一篇文章（http://blog.csdn.net/cywosp/article/details/38014581）中讲到了使用HTTP重定向来实现服务器的负载均衡，本文则讲解另一种实现服务器集群的负载均衡方案——DNS域名解析。 DNS（Domain Name System）是因特网的一项服务，它作为域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网。人们在通过浏览器访问网站时只需要记住网站的域名即可，而不需要记住那些不太容易理解的IP地址。在DNS系统中有一个比较重要的的资源类型叫做主机记录也称为A记录，A记录是用于名称解析的重要记录，它将特定的主机名映射到对应主机的IP地址上。如果你有一个自己的域名，那么要想别人能访问到你的网站，你需要到特定的DNS解析服务商的服务器上填写A记录，过一段时间后，别人就能通过你的域名访问你的网站了。DNS除了能解析域名之外还具有负载均衡的功能，下面是利用DNS工作原理处理负载均衡的工作原理图： 由上图可以看出，在DNS服务器中应该配置了多个A记录，如： www.apusapp.com IN A 114.100.20.201; www.apusapp.com IN A 114.100.20.202; www.apusapp.com IN A 114.100.20.203; 因此

随着网站流量上升，服务的负载不堪重负。造成崩溃问题。 对此，有两种解决方法，首先，第一种，升级服务器，购买更高的配置的服务器，这种方式简单易行，缺点是投资比较大，然后流量再次上升，就会面临同样的问题。另一种方法是采用集群技术。采用两台以上的服务器进行协同工作（集群系统中的服务器不一定非得是高性能的服务器，但是可以提供高性能的不停机服务，随着需求的增加，可以在集群追加服务器），集群的优点是高可靠性，和强大灵活的系统扩展能力。 两台以上的服务器协同工作必然涉及到负载均衡，常用的负载均衡技术有NAT负载均衡，反向代理负载均衡，DNS负载均衡。NAT负载均衡是将外部的IP地址映射为多个内部的IP地址，对每次请求连接动态的转换为内部服务器的ip地址，对外部服务器的访问也转接到这个内部服务器上。 反向代理负载均衡是使用代理服务器，将请求均匀的转发给多台内部服务器之一上。从而达到负载均衡的效果。 DNS负载均衡是在DNS中，为多个地址配置同一个名字，从而使不同的客户，访问不同的服务器来实现负载均衡。DNS的负载均衡是通过循环复用实现的。如果发现主机的多个资源记录，则循环使用包含在查询应答中的主机记录。在默认情况下，DNS服务器的循环复用，对资源记录进行排序，这些资源记录是在解析为多个映射的主机名应答中返回的，该功能提供了一种非常简便的方法

原文还是在简书编写的： DNS Prefetching的两三事 年前年后有点忙，又是追加功能，修改富文本编辑器，又是切我们的整体架构，好久没有更新了，最近同事发现了个有意思的文章，如下，是讲 DNS Prsfetching的。 预加载-有赞-DNS 看完之后，觉得原文，有些地方还没有提及到，所以有必要写一篇文章来记录下自己的心得体会，所有原始内容来源于 Google 和 火狐 官方文档, 正文如下： 什么是DNS Prefetching 如果你在网上搜 DNS Prefetching的相关资料，要不就是到上面的官方文档，要不就是基本上一致的中国版本copy & paste，如下图所示： 那么DNS Prefetching 是什么 ： DNS 是什么-- Domain Name System，域名系统，作为域名和IP地址相互映射的一个分布式数据库。 DNS大家都懂，那么浏览器访问域名的时候，是需要去解析一次DNS，也就是把域名 google.com解析到对应的ip地址上，相信有些人也通过修改本机hosts来翻墙访问Google吧，这个就是主动的影响DNS解析。到这里大家就比较清楚，既然要解析就会损耗时间，对于前端特别是移动端而言，分秒必争，这个时间大家也想省去，所以浏览器厂商-Chrome最想搞了这个新功能。 定义--浏览器根据自定义的规则，提前去解析后面可能用到的域名