做婚姻网站流程,wordpress文章显示时间,上线了做网站价格贵,海外网站推广方法文章目录 一.overlay vs underlayL2 underlayL3 underlay 二、calico vs flannel2.1 calico架构2.2 flannel架构 三、iptables四、Vxlan五、kubernetes网络架构综述六、DNS七、Kubernetes域名解析策略 一.overlay vs underlay
overlay网络是在传统网络上虚拟出一个虚拟网络承载的底层网络不再需要做任何适配。在容器的世界里物理网络只承载主机网络通信虚拟网络只承载容器网络通信。overlay网络的任何协议都要求在发送方对报文进行包头封装接收方剥离包头。
L2 overlay传统的二层网络的范围有限L2 overlay网络是构建在底层物理网络上的L2网络相较于传统的L2网络L2 overlay网络是个“大二层”的概念其中“大”的含义是可以跨越多个数据中心即容器可以跨L3 underlay进行L2通信而“二层”指的是通信双方在同一个逻辑的网段内例如172.17.1.2/16和172.17.2.3/16。VXLAN就是L2 overlay网络的典型实现其通过在UDP包中封装原始L2报文实现了容器的跨主机通信。 L2 overlay网络容器可在任意宿主机间迁移而不改变其IP地址的特性使得构建在大二层overlay网络上的容器在动态迁移时具有很高的灵活性。
L3 overlayL3 overlay组网类似L2 overlay但会在节点上增加一个网关。每个节点上的容器都在同一个子网内可以直接进行二层通信。跨节点的容器间通信只能走L3都会经过网关转发性能相比于L2 overlay较弱。牺牲的性能获得了更高的灵活性跨节点通信的容器可以存在于不同的网段中例如192.168.1.0/24和172.17.16.0/24。flannel的UDP模式采用的就是L3 overlay模型。L3 overlay网络容器在主机间迁移时可能需要改变其IP地址。
underlay网络underlay网络一般理解为底层网络传统的网络组网就是underlay类型区别于上文提到的overlay网络。
L2 underlay
L2 underlay网络就是链路层L2互通的底层网络。IPvlan L2模式和Macvlan属于L2underlay类型的网络。
L3 underlay
在L3 underlay组网中可以选择IPvlan的L3模式该模式下IPvlan有点像路由器的功能它在各个虚拟网络和主机网络之间进行不同网络报文的路由转发工作。只要父接口相同即使虚拟机/容器不在同一个网络也可以互相ping通对方因为IPvlan会在中间做报文的转发工作。IPvlan的L3模式flannel的host-gw模式和Calico的BGP组网方式都是L3 underlay类型的网络。
二、calico vs flannel
2.1 calico架构
Calico的设计灵感源自通过将整个互联网的可扩展IP网络原则压缩到数据中心级别。Calico在每一个计算节点利用Linux Kernel实现高效的vRouter来负责数据转发而每个vRouter通过BGP把自己节点上的工作负载的路由信息向整个Calico网络传播。小规模部署可以直接互联大规模下可通过指定的BGP Route Reflector完成。保证最终所有的容器之间的数据流量都是通过IP路由的方式完成互联的。 路由方案的另一个优点是出了问题也很容易排查。路由方案往往需要用户了解底层网络基础结构因此使用和运维门槛较高。
2.2 flannel架构
flannel的想法很好每个主机负责一个网段在这个网段里分配一个IP地址。访问另外一台主机时通过网桥到达主机上的IP地址这边会有一个设备程序会把你发的包读出来去判断你的目的地址是什么归哪台机器管。flannel的UDP封包协议会在原始的IP包外面加一个UDP包发到目的地址。收到之后会把前面的UDP包扔掉留下来的就是目标容器地址。这个方法有几个问题第一个问题是要做封包的操作。第二个问题是每个主机上的容器是固定的容器的不同主机之间的迁移必然带来IP的变化。使用UDP封包的一个比较大的问题是性能较差我们会在后面的章节专门说明。 overlay网络最大的优点是适用于几乎所有网络基础架构它唯一的要求是主机之间的IP连接。但overlay网络的问题是随着节点规模的增长复杂度也会随之增加而且用到了封包因此出了网络问题定位起来比较麻烦。
三、iptables
iptables是用户空间的一个程序通过netlink和内核的netfilter框架打交道负责往钩子上配置回调函数。一般情况下用于构建Linux内核防火墙特殊情况下也做服务负载均衡这是Kubernetes的特色操作我们将在后面章节专门分析。iptables的工作原理如图所示。 iptables的工作原理我们常说的iptables 5X5即5张表table和5条链chain。5条链即iptables的5条内置链对应上文介绍的netfilter的5个钩子。这5条链分别是
INPUT链一般用于处理输入本地进程的数据包OUTPUT链一般用于处理本地进程的输出数据包FORWARD链一般用于处理转发到其他机器/network namespace的数据包PREROUTING链可以在此处进行DNATPOSTROUTING链可以在此处进行SNAT。
除了系统预定义的5条iptables链用户还可以在表中定义自己的链我们将通过例子详细说明。5张表如下所示。 那么一个网络包经过iptables的处理路径如图所示 任何概念都不是凭空想象出来的它都是有实际用途的。其实iptables的表是来分类管理iptables规则rule的系统所有的iptables规则都被划分到不同的表集合中。上文也提到了filter表中会有过滤数据包的规则nat表中会有做地址转换的规则。因此iptables的规则就是挂在netfilter钩子上的函数用来修改数据包的内容或过滤数据包iptables的表就是所有规则的5个逻辑集合 ilter表上挂了5条链分别是INPUT、FORWARD和OUTPUT这三条系统内置链以及KUBE-FIREWALL和KUBE-FORWARD这两条用户自定义链。iptables的内置链都有默认规则例如在我们的例子中INPUT、FORWARD和OUTPUT的默认规则是ACCEPT即全部放行。用户自己定义的链后面都有一个引用计数在我们的例子中KUBE-FIREWALL和KUBE-FORWARD都有一个引用它们分别在INPUT和FORWARD中被引用。iptables的每条链下面的规则处理顺序是从上到下逐条遍历的除非中途碰到DROPREJECTRETURN这些内置动作。如果iptables规则前面是自定义链则意味着这条规则的动作是JUMP即跳到这条自定义链遍历其下的所有规则然后跳回来遍历原来那条链后面的规则。
四、Vxlan
VXLANVirtual eXtensible LAN虚拟可扩展的局域网是一种虚拟化隧道通信技术。它是一种overlay覆盖网络技术通过三层的网络搭建虚拟的二层网络。RFC7348中是这样介绍VXLAN的A framework for overlaying virtualized layer 2 networks over lay 3 networks. 简单来讲VXLAN是在底层物理网络underlay之上使用隧道技术依托UDP层构建的overlay的逻辑网络使逻辑网络与物理网络解耦实现灵活的组网需求。它不仅能适配虚拟机环境还能用于容器环境。由此可见VXLAN这类隧道网络的一个特点是对原有的网络架构影响小不需要对原网络做任何改动就可在原网络的基础上架设一层新的网络。不同于其他隧道协议VXLAN是一个一对多的网络并不仅是一对一的隧道协议。一个VXLAN设备能通过像网桥一样的学习方式学习到其他对端的IP地址也可以直接配置静态转发表。
VXLAN协议原理简介
VXLAN隧道网络方案相比改造传统的二层或三层网络对原有的网络架构影响小。隧道网络不需要原来的网络做任何改动可直接在原来的网络基础上架设一层新的网络。图1-21所示为VXLAN的工作模型它创建在原来的IP网络三层上只要是三层可达能够通过IP互相通信的网络就能部署VXLAN。在VXLAN网络的每个端点都有一个VTEP设备负责VXLAN协议报文的封包和解包也就是在虚拟报文上封装VTEP通信的报文头部。物理网络上可以创建多个VXLAN网络可以将这些VXLAN网络看作一个隧道不同节点上的虚拟机/容器能够通过隧道直连。通过VNI标识不同的VXLAN网络使得不同的VXLAN可以相互隔离。 VXLAN的几个重要概念如下
VTEPVXLAN Tunnel EndpointsVXLAN网络的边缘设备用来进行VXLAN报文的处理封包和解包。VTEP可以是网络设备例如交换机也可以是一台机器例如虚拟化集群中的宿主机VNIVXLAN Network IdentifierVNI是每个VXLAN的标识是个24位整数因此最大值是22416777216。如果一个VNI对应一个租户那么理论上VXLAN可以支撑千万级别的租户。tunnel隧道是一个逻辑上的概念在VXLAN模型中并没有具体的物理实体相对应。隧道可以看作一种虚拟通道VXLAN通信双方图中的虚拟机都认为自己在直接通信并不知道底层网络的存在。从整体看每个VXLAN网络像是为通信的虚拟机搭建了一个单独的通信通道也就是隧道。 前文提到VXLAN其实是在三层网络上构建出来的一个二层网络的隧道。VNI相同的机器逻辑上处于同一个二层网络中。VXLAN封包格式如图1-22所示。 VXLAN的报文就是MAC in UDP即在三层网络的基础上构建一个虚拟的二层网络。为什么这么说呢VXLAN的封包格式显示原来的二层以太网帧包含MAC头部、IP头部和传输层头部的报文被放在VXLAN包头里进行封装再套到标准的UDP头部UDP头部、IP头部和MAC头部用来在底层网络上传输报文。 可以看出VXLAN报文比原始报文多出了50个字节包括8个字节的VXLAN协议相关的部分8个字节的UDP头部20个字节的IP头部和14个字节的MAC头部。这降低了网络链路传输有效数据的比例特别是对小包。 需要注意的是UDP目的端口是接收方VTEP设备使用的端口IANAInternet AssignedNumbers Authority互联网号码分配局分配了4789作为VXLAN的目的UDP端口。 VXLAN的配置管理使用iproute2包这个工具是和VXLAN一起合入内核的我们常用的ip命令就是iproute2的客户端工具。VXLAN要求Linux内核版本在3.7以上最好为3.9以上所以在一些旧版本的Linux上无法使用基于VXLAN的封包技术。
五、kubernetes网络架构综述
谈到Kubernetes的网络模型就不能不提它著名的“单Pod单IP”模型即每个Pod都有一个独立的IPPod内所有容器共享network namespace同一个网络协议栈和IP。 “单Pod单IP”网络模型为我们勾勒了一个Kubernetes扁平网络的蓝图在这个网络世界里容器是一等公民容器之间直接通信不需要额外的NAT因此不存在源地址被伪装的情况Node与容器网络直连同样不需要额外的NAT。扁平化网络的优点在于没有NAT带来的性能损耗而且可追溯源地址为后面的网络策略做铺垫降低网络排错的难度等。 总体而言集群内访问Pod会经过Service集群外访问Pod经过的是Ingress。Service和Ingress是Kubernetes专门为服务发现而抽象出来的相关概念后面会做详细讨论。 与CRI之于Kubernetes的runtime类似Kubernetes使用CNI作为Pod网络配置的标准接口。需要注意的是CNI并不支持Docker网络也就是说docker0网桥会被大部分CNI插件“视而不见” 具体过程如下
当用户在Kubernetes的Master里创建了一个Pod后Kubelet观察到新Pod的创建于是首先调用CRI后面的runtime实现比如dockershim、containerd等创建Pod内的若干个容器。在这些容器里第一个被创建的pause容器是比较特殊的这是Kubernetes系统“赠送”的容器也称pause容器。里面运行着一个功能十分简单的C程序具体逻辑是一启动就把自己永远阻塞在那里。一个永远阻塞而且没有实际业务逻辑的pause容器到底有什么用呢用处很大。我们知道容器的隔离功能利用的是Linux内核的namespace机制而只要是一个进程不管这个进程是否处于运行状态挂起亦可它都能“占”用着一个namespace。因此每个Pod内的第一个系统容器pause的作用就是占用一个Linux的network namespace。Pod内其他用户容器通过加入这个network namespace的方式共享同一个networknamespace。用户容器和pause容器之间的关系有点类似于寄居蟹和海螺。因此Containerruntime创建Pod内的用户容器时调用的都是同一个命令docker run–netnone。意思是只创建一个network namespace不初始化网络协议栈。如果这个时候通过nsenter方式进入容器会看到里面只有一个本地回环设备lo。容器的eth0是怎么创建出来的呢答案是CNI。CNI主要负责容器的网络设备初始化工作。Kubelet目前支持两个网络驱动分别是Kubenet和CNI。Kubenet是一个历史产物即将废弃因此本节不过多介绍。CNI有多个实现官方自带的插件就有p2p、bridge等这些插件负责初始化pause容器的网络设备也就是给pause容器内的eth0分配IP等到时候Pod内其他容器就使用这个IP与其他容器或节点进行通信。Kubernetes主机内容器的默认组网方案是bridge。flannel、Calico这些第三方插件解决容器之间的跨机通信问题典型的跨机通信解决方案有bridge和overlay等。
六、DNS
Kubernetes DNS的命名方案也遵循可预测的模式使各种服务的地址更容易被记住。服务不仅可以通过完全限定域名FQDN引用还可以仅通过服务本身的name引用。 目前Kubernetes DNS加载项支持正向查找A Record、端口查找SRV记录、反向IP地址查找PTR记录及其他功能。对于ServiceKubernetes DNS服务器会生成三类DNS记录分别是A记录、SRV记录和CNAME记录。 headless”服务与“normal”服务的不同之处在于它们未分配Cluster IP且不执行负载均衡。 “normal”服务分配一个DNS A Record作为表单your-svc.your-namespace.svc.cluster.local的name根域名可以在kubelet设置中更改。此name解析为服务的集群IP。“ headless”服务为表单your-svc.your-namespace.svc.cluster.local的name分配一个DNS A Record。与“normal”服务相反此name解析的是为服务选择的一组PodIP。DNS不会自动将此设置解析为特定的IP因此客户端应该负责集合中进行的负载均衡或循环选择。
A记录 A记录与普通Service和headless Service有区别。普通Service的A记录的映射关系是 headless Service的A记录的映射关系是 一旦启用了DNSPod将被分配一个DNS A记录格式如下所示 如果在Pod Spec指定hostname和subdomain那么Kubernetes DNS会额外生成Pod的A记录 SRV记录 SRV记录是通过描述某些服务协议和地址促进服务发现的。SRV记录通常定义一个符号名称和作为域名一部分的传输协议如TCP并定义给定服务的优先级、权重、端口和目标。详细内容请参阅下面的示例 在上面的示例中_sip是服务的符号名称_tcp是服务的使用传输协议。记录内容代表两个记录都定义了10的优先级。另外第一个记录的权重为70第二个记录的权重为20。优先级和权重通常用于建议指定使用某些服务器。记录中的最后两个值定义了要连接的端口和主机名以便与服务通信。
Kubernetes DNS的SRV记录是按照一个约定俗成的规定实现了对服务端口的查询 SRV记录是为“normal”或“headless”服务的部分指定端口创建的。SRV记录采用_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local的形式。对于常规服务它被解析的端口号和域名是my-svc.my-namespace.svc.cluster.local。在“headless”服务的情况下此name解析为多个answer每个answer都支持服务。每个answer都包含auto-generated-name.my-svc.my-namespace.svc.cluster.local表单的Pod端口号和域名。 CNAME记录 CNAME记录用于将域或子域指向另一个主机名。为此CNAME使用现有的A记录作为其值。相反A记录会解析为指定的IP地址。此外在Kubernetes中CNAME记录可用于联合服务的跨集群服务发现。在整个场景中会有一个跨多个Kubernetes集群的公共服务。所有Pod都可以发现这项服务无论这些Pod在哪个集群上。这是一种跨集群服务发现方法。 dns使用及kubernetes dns策略 options ndots:5的含义是当查询的域名字符串内的点字符数量超过ndots5值时则认为是完整域名直接解析否则Linux系统会自动尝试用default.pod.cluster.local、default.svc.cluster.local或svc.cluster.local补齐域名后缀。 例如查询whoami会自动补齐成whoami.default.pod.cluster.local、whoami.default.svc.cluster.local和whoami.svc.cluster.local查询过程中任意一个记录匹配便返回显然能返回DNS记录的匹配是whoamidefault.svc.cluster.local。而查询whoami.default能返回DNS记录的匹配是whoami.defaultsvc.cluster.local。
最后运行DNS Pod可能需要特权即配置Kubelet的参数–allow-privilegedtrue。
七、Kubernetes域名解析策略
Kubernetes域名解析策略对应到Pod配置中的dnsPolicy有4种可选策略分别是None、ClusterFirstWithHostNet、ClusterFirst和Default其中
None从Kubernetes 1.9版本起引入的一个新选项值。它允许Pod忽略Kubernetes环境中的DNS设置。应使用dnsConfigPod规范中的字段提供所有DNS设置ClusterFirstWithHostNet对于使用hostNetwork运行的Pod用户应该明确设置其DNS策略为ClusterFirstWithHostNetClusterFirst任何与配置的群集域后缀例如cluster.local不匹配的DNS查询例如“www.kubernetes.io”将转发到从宿主机上继承的上游域名服务器。集群管理员可以根据需要配置上游DNS服务器DefaultPod从宿主机上继承名称解析配置。None一个配置了None类型的dnsPolicy的Pod如下 以上Pod被创建后test容器的/etc/resolv.conf内容如下所示 ClusterFirstWithHostNet 使用ClusterFirstWithHostNet策略的一个Pod配置文件如下 如上所示当Pod使用主机网络hostNetwork:true时DNS策略需要设置成ClusterFirstWithHostNet。对于那些使用主机网路的Pod它们是可以直接访问宿主机的/etc/resolv.conf文件的。因此如果不加上dnsPolicy:ClusterFirstWithHostNet则Pod将默认使用宿主机的DNS配置这样会导致集群内容器无法通过域名访问Kubernetes的服务除非在宿主机的/etc/resolv.conf文件配置了Kubernetes的DNS服务器。 ClusterFirst 使用ClusterFirst策略的一个Pod配置文件如下所示 ClusterFirst策略就是优先使用Kubernetes的DNS服务解析失败后再使用外部级联的DNS服务解析工作流程如图3-21所示
