用织梦软件如何做网站国内做的比较简洁的网站

用织梦软件如何做网站,国内做的比较简洁的网站,公司网站建设合同模板,山西工程项目视频制作公司一、K8s网络模型K8s网络模型设计的一个基础原则是#xff1a;每个Pod都拥有一个独立的IP地址#xff0c;而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中。同一个Pod内的不同容器将会共享一个网络命名空间#xff0c;也就是说同一个Linux网络协议栈。意味着同一个…一、K8s网络模型K8s网络模型设计的一个基础原则是每个Pod都拥有一个独立的IP地址而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中。同一个Pod内的不同容器将会共享一个网络命名空间也就是说同一个Linux网络协议栈。意味着同一个Pod内的容器可以通过localhost来连接对方的端口。二、Docker的网络模型Docker使用到的与Linux网络有关的主要技术Network Namespace(网络命名空间)Veth设备对Iptables/Netfilter网桥路由三、网络的命名空间为了支持网络协议栈的多个实例Linux中网络栈中引入了网络命名空间Network Namespace这些独立的协议栈被隔离到不同的命名空间中处于不同命名空间的网络栈是完全隔离的彼此之间无法通信。通过这种对网络资源的隔离就能在一个宿主机上虚拟多个不同的网络环境。Docker正是利用了网络的命名空间特性实现了不同容器之间网络的隔离。Linux的网络命名空间内可以有自己独立的路由表及独立的Iptables/Netfilter设置来提供包转发、NAT及IP包过滤等功能。为了隔离出独立的协议栈需要纳入命名空间的元素有进程、套接字、网络设备等。进程创建的套接字必须属于某个命名空间套接字的操作也必须在命名空间内进行。同样网络设备也必须属于某个命名空间。因为网络设备属于公共资源所以可以通过修改属性实现这命名空间之间移动。当然是否允许移动和设备的特征有关。1.网络命名空间的实现Linux实现网络命名空间的核心Linux的网络协议十分复杂为了支持独立的协议栈相关的全局变量都必须修改为协议栈私有。最好的办法就是让全局变量成为一个Net Namespace变量的成员然后为协议栈私有。最好的办法就是让这些全局变量成为一个Net Namespace变量的成员然后为协议栈的函数调用加入一个Namespace参数。所有的网络设备物理的或虚拟接口、桥等着内核里都叫作Net Device都只能属于一个命名空间。通常物理的设备只能关联到root这个命名空间中虚拟的网络设备虚拟的以太网接口或者虚拟网口对则可以被创建并关联到一个给定的命名空间中而且可以在命名空间之间移动。网络命名空间代表的是一个独立的协议栈它们之间是相互隔离的彼此无法通信在协议栈内部都看不到对方。打破这种限制让处于不同命名空间的网络相互通信甚至和外部的网络进行通信的方法就是Veth设备对。Veth设备对重要作用就是打破相互看不到的协议栈之间的壁垒就像一个管子一端连着这个网络命名空间的协议栈一端连着另一个网络命名空间的协议栈。所以如果想在两个命名空间之间进行通信就必须有一个Veth设备对。2.网络命名空间的操作命令需要root用户运行创建一个命名空间ip nets add name在命名空间内执行命令ip netns exec name command如果想执行多个命令可以先进入内部sh然后执行ip netns exec name bash之后就是在新的命名空间内进行操作了退出到外面的命名空间输入exit3.网络命名空间的一些技巧可以在不同的网络命名空间之间转移设备例如Veth设备对的转移。设备里面有一个重要属性NETIF_F_ETNS_LOCAL这个属性为on则不能转移到其他命名空间内。Veth设备属于可以转移的设备很多其他设备如lo设备、vxlan设备、ppp设备、bridge设备等都是不可以转移的。使用ethtool工具可以查看ethtool -k br0 netns-local: on [fixed]netns-local的值是on就说明不可以转移否则可以四、Veth设备对引入Veth设备对是为了在不同的网络命名空间之间进行通信利用它可以直接将两个网络命名空间连接起来。由于要连接两个网络命名空间所以veth设备都是成对出现的很像一对以太网卡并且中间有一个直连的网线。既然是一对网卡将其中一端称为另一端的peer在Veth设备的一端发送数据时会将数据直接发送到另一端并触发另一端的接收操作。1.Veth设备对的操作命令创建Veth设备对连接到不同的命名空间并设置它们的地址让它们通信。创建Veth设备对ip link add veth0 type veth peer name veth1创建后查看Veth设备对的信息使用ip link show命令查看所有网络接口ip link show会生成两个设备一个是veth0,peer是veth1 两个设备都在同一个命名空间将Veth看作是有两个头的网线将另一个头甩给另一个命名空间ip link set veth1 netns netns1再次查看命名空间只剩下一个veth0ip link show在netns1命名空间可以看到veth1设备符合预期。现在看到的结果是两个不同的命名空间各自有一个Veth的网线头各显示为一个Device。Docker的实现里面除了将Veth放入容器内下一步给两个设备veth0、veth1分配IP地址ip netns exec netns1 ip addr add 10.1.1.1/24 dev veth1 ip addr add 10.1.1.2/24 dev veth0现在两个网络命名空间可以互相通信了ping 10.1.1.1 ip netns exec netns1 ping 10.1.1.2至此两个网络命名空间之间就完全相通了。至此就能够理解Veth设备对的原理和用法了。在Docker内部Veth设备对也是联系容器到外面的重要设备离开它是不行的。2.Veth设备对如何查看对端一旦将Veth设备对的peer端放入另一个命名空间在本命名空间就看不到了想查看peer端连接的命名空间可以使用ethtool工具来查看。首先在一个命名空间中查询Veth设备对端接口在设备列表中的序列号ip nets exec netns1 ethtool -S veth1 NIC statistics: peer_ifindex: 5得知另一端的接口设备的序列号是5再到命名空间中查看序列号5代表的设备ip netns exec netns2 ip link | grep 5 veth0现在就找到下标为5的设备了是veth0另一端自然就是另一个命名空间中的veth1了互为peer。五、网桥Linux可以支持多个不同的网络网络之间能够相互通信网桥将这些网络连接起来并实现网络中主机的相互通信。网桥是一个二层的虚拟网络设备把若干个网络接口连接起来以使得网口之间的报文能够互相转发。网桥能够解析收发的报文读取目标MAC地址的信息和自己记录的MAC表结合来决策报文的转发目标网口。为了实现这些功能网桥会学习源MAC地址二层网桥转发的依据就是MAC地址。在转发报文时网桥只需要向特定的网口进行转发避免不必要的网络交互。网桥如果遇到一个未学习到的地址就无法知道这个报文应该向哪个网口转发就将报文广播给所有的网口报文来源的网口除外。在实际网络中网络拓扑不可能永久不变。网桥需要对学习到的MAC地址表加上超时时间默认为5分钟如果网桥收到了对应端口MAC地址回发的包则重制超时时间否则过了超时时间后就认为设备已经不在那个端口上了就会重新广播发送。Linux内核支持网口的桥接与单纯的交换机不同交换机只是一个二层设备对于接收到的报文要么转发要么丢弃。运行着linux内核的机器本身就是一台主机有可能是网络报文的目的地收到的报文除了转发和丢弃还可能被送到网络层协议栈的上层网络层从而被主机本身的协议栈消化既可以把网桥看作一个二层设备也可以看作一个三层设备。1.Linux网桥的实现Linux内核是通过一个虚拟的网桥设备Net Device来实现桥接的。虚拟设备可以绑定若干个以太网接口设备从而将它们桥接起来。虚拟的网桥设备和普通设备的不同最明显的一个特性是可以有一个IP地址网桥br0绑定了eth0和eth1。对于网络协议栈的上层来说只看的到br0。桥接是在数据链路层实现的上层不需要关心桥接的细节协议栈上层需要发送的报文被送到br0网桥设备的处理代码判断报文该被转发到eth0还是eth1或者两者皆转发。协议栈的上层需要发送的报文被提交给网桥的处理代码在这里会判断报文应该被转发丢弃还是提交到协议栈上层。有时eth0、eth1也可能会作为报文的源地址或目的地址直接参与报文的发送与接收从而绕过网桥。2.网桥的常用操作命令Docker自动完成了对网桥的创建和维护。新增一个网桥设备brctl addbr xxxxx为网桥增加网口在Linux中一个网口其实就是一个物理网卡将物理网卡和网桥连接起来。brctl addif xxxxx ethx网桥的物理网卡作为一个网口由于在链路层工作就不再需要IP地址了这样上面的IP地址自然失效。ifconfig ethx 0.0.0.0给网桥配置一个IP地址Ifconfig brxxx xxx.xxx.xxx.xxx这样网桥就有一个IP地址连接到上面的网卡就是一个纯链路层设备了。六、Iptables/NetfilterLinux提供了一套机制来为用户实现自定义的数据包处理过程。在linux网络协议中有一组回调函数挂接点通过这些挂接点挂接的钩子函数可以在linux网络栈处理数据包的过程中对数据进行一些操作例如过滤、修改、丢弃等。整个挂接点技术叫作Netfilter和Iptables。Netfilter负责在内核中执行各种挂接的规则运行在内核模式中。而Iptables是在用户模式下运行的进程负责协助维护内核中Netfilter的各种规则表。通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。四表raw、mangle、nat、filterNetfilter可以挂接的规则点有5个(链)INPUTOUTPUTFORWARDPREROUTINGPOSTROUTING流入PREROUTING - INPUT流出OUTPUT - POSTROUTING转发PREROUTING - FORWARD - POSTROUTING七、路由Linux系统包含一个完整的路由功能。当IP在处理数据发送或者抓发时会使用路由表来决定发往哪里。通常情况下如果主机与目的主机直接相连那么主机可以直接发送IP报文到目的主机这个过程比较简单。例如通过点对点的链接或通过网络共享如果主机与目的主机没有直接相连那么主机会将IP报文发送给默认的路由器然后由路由器来决定往哪发送IP报文。路由功能由IP层维护的一张路由表来实现。当主机收到数据报文时用此表来决策接下来应该做什么操作。当从网络侧接收到数据报文时IP层首先会检查报文的IP地址是否与主机自身的地址相同。如果数据报文中的IP地址是主机自身的地址那么报文将被发送到传输层相应的协议中去。如果报文中的IP地址不是主机自身的地址并且配置了路由功能那么报文将被转发否则报文将被丢弃。路由表中的数据一般是以条目形式存在的。一个典型的路由表条目通常包含以下主要的条目项。目的IP地址此字段表示目标的IP地址。这个IP地址可以是某台主机的地址也可以是一个网络地址。如果这个条目包含的是一个主机地址那么主机ID将被标记为非零。如果这个条目包含的是一个网络地址主机ID将被标记为零。下一个路由器的IP地址下一个路由器并不总是最终的目的路由器很可能是一个中间路由器。条目给出下一个路由器的地址用来转发从相应接口收到的IP数据报文。标志这个字段提供了另一组重要信息例如目的IP地址是一个主机地址还是一个网络地址。从标志中可以得知下一路由器是一个真实的路由器还是一个直接相连的接口。网络接口规范数据报文的网络接口规范该规范将与该报文一起被转发。1.路由表的创建Linux的路由表至少包括两个表一个是LOCAL另一个是MAIN。在LOCAL表中会包含所有的本地设备地址。LOCAL路由表是在配置网络设备地址时自动创建的。LOCAL表用于供Linux协议栈识别本地地址以及进行本地各个不同网络接口之间的数据转发。可以通过下面的命令查看LOCAL表的内容ip route show table local type localMAIN表用于各类网络IP地址的转发。MAIN表的建立可以使用静态配置生存也可以使用动态路由发现协议生成。2.路由表的查看使用ip route list命令查看当前的路由表。ip route list另一个查看路由表的工具netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.128.232.1 0.0.0.0 UG 0 0 0 ens5 10.128.232.0 0.0.0.0 255.255.252.0 U 0 0 0 ens5标志是U说明是可达路由标志是G,说明这个网络接口连接的是网关否则说明是直连主机。八、Docker的网络实现Docker支持以下4类网络模式host模式使用–nethost指定containe模式使用–netcontainer:NAME_or_ID指定none模式使用–netnone指定bridge模式使用–netbridge指定为默认设置在K8s管理模式下通常只会使用bridge模式在bridge模式下Docker Daemon第一次启动时会创建一个虚拟的网桥默认的名字是docker0在私有网络空间中给这个网桥分配一个子网。针对由Docker创建出来的每一个容器都会创建一个虚拟的以太网设备Veth设备对其中一端关联到网桥上另一端使用Linux的网络命名空间技术映射到容器内的eth0设备然后从网桥的地址段内给eth0接口分配一个IP地址。ip1是网桥的IP地址Docker Daemon会在几个备选地址段里选一个通常是172开头的一个地址。ip2是Docker在启动容器时在这个地址段随机选择的一个没有使用的IP地址。相应的MAC地址也根据这个IP地址在02:42:ac:11:00:00和02:42:ac:11:ff:ff的范围内生存可以确保不会有ARP的冲突。启动后Docker还将Veth对的名字映射到eth0网络接口。ip3就是主机的网卡地址。ip1、ip2和ip3是不同的IP段外部是看不到ip1和ip2的。同一台机器内的容器之间可以相互通信。不同主机上的容器不能够相互通信。为了跨节点互相通信必须在主机的地址上分配端口然后通过这个端口路由代理到容器上这种做法显然意味着一定要在容器之间小心谨慎地协调好端口的分配或者使用动态端口分配技术。1.查看Docker启动后的系统情况Docker网络中bridge模式下Docker Daemon启动时创建docker0网桥并在网桥使用的网段为容器分配IP。ip addr iptables-saveDocker创建了docker0网桥并添加了Iptables规则。2.查看容器启动后的情况(容器无端口映射)docker run --name register -d registry ip addr iptables-save ip route可以看到如下情况。宿主机器上的Netfilter和路由表都没有变化说明在不进行端口映射时Docker的默认网络上没有特殊处理的。相关的NAT和FILTER两个Netfilter链还是空的。宿主机上的Veth对已经建立并连接到了容器内。进入容器查看网络栈容器内部的IP地址和路由如下ip route ip addr可以看到默认停止的回环设备lo已经被启动外面宿主机连接进来的Veth设备也被命名成了eth0并且已经配置了地址172.17.0.10。3.查看容器启动后的情况容器端口映射用带端口映射的命令启动registrydocker run --name register -d -p 1180:5000 registry启动后查看Iptables的变化iptables-saveDocker服务在NAT和FILTER两个表内添加的两个Docker子链都是给端口映射用的。例如需要把宿主机的1180端口映射到容器的5000端口。无论是宿主机接收还是宿主机本地协议栈发出的目标地址是本地IP地址的包都会经过NAT表中的DOCKER子链。Docker为每一个端口映射都在这个链上增加了到实际容器目标地址和目标端口的转换。经过这个DNAT的规则修改后的IP包会重新经过路由模块的判断进行转发。由于目标地址和端口已经是容器的地址和端口所以数据自然就送到docker0上从而送到对应的容器内部。在Forward时需要在Docker子链中添加一条规则如果目标端口和地址是指定容器的数据则允许通过。在Docker按照端口映射的方式启动容器时主要的不同就是上述Iptables部分。从而容器内部的路由和网络设备都和不做端口映射时一样没有任何变化。九、K8s的网络实现K8s网络的设计主要致力于解决以下场景容器到容器之间的直接通信抽象的pod到pod之间的通信Pod到Service之间的通信集群外部与内部组件之间的通信1.容器到容器的通信在同一个Pod内的容器共享同一个网络命名空间共享同一个linux协议栈。对于网络的各类操作就和它们在同一台机器上一样设置可以用localhost地址访问彼此的端口。容器1和容器2共享网络命名空间打开的端口不会有冲突可以直接使用linux的本地IPC进行通信例如消息队列或者管道互相访问只需要使用localhost就可以了。2.Pod之间的通信每一个Pod都有一个真实的全局IP地址同一个Node内的不同Pod之间可以直接采用对方Pod的IP地址通信而且不需要使用其他发现机制例如DNS或者etcd。Pod容器既有可能在同一个Node上运行也有可能在不同的Node上运行通信分为两类同一个Node内的Pod之间的通信和不同Node上的Pod之间的通信1) 同一个Node内的Pod之间的通信Pod1和Pod2都是通过Veth连接在同一个docker0网桥上的IP地址IP1、IP2都是从docker0到网段上动态获取的和网桥本身的IP3是同一个网段的。在Pod1、Pod2的Linux协议上默认路由都是docker0的地址也就是说所有非本地地址的网络数据都会被默认发送到dockero网桥上由docker0网桥直接中转。综上所述Pod1和Pod2关联在同一个docker0网桥上地址段相同所以Pod1和Pod2之间是能直接通信的。2不同Node上的Pod之间的通信Pod的地址是与docker0在同一个网段内的docker0网段与宿主机网卡是两个完全不同的IP网段并且不同Node之间通信只能通过宿主机的物理网卡进行因此要实现位于不同Node上的Pod容器之间通信就必须想办法通过主机的这个IP地址来进行寻址和通信。K8s会记录所有正在运行Pod的IP分配信息并将这些信息保存在etcd中作为Service的Endpoint。要想支持不同Node上的Pod之间的通信就要达到两个条件在整个K8s集群中对Pod的IP分配进行规划不能有冲突将Pod的IP和所在Node的IP关联起来通过这个关联让Pod可以互相访问根据条件1需要在部署k8s时对docker0的IP地址进行规划保证每一个Node上的docker0地址没有冲突。可以在规划后手工配置到每个Node上或者做一个分配规则由安装的程序自己去分配占用。例如K8s的网络增强开源软件Flannel就能够管理资源池的分配。根据条件2:Pod中的数据中发出时需要有一个机制能够知道对方Pod的IP地址挂在哪个具体的Node上。也就是先要找到Node对应宿主机的IP地址将数据发送到宿主机的网卡上然后在宿主机上将相应的数据转到具体的docker0上一旦数据到达宿主机Node则那个Node内部的docker0便知道如何将数据发送到Pod。十、Pod和Service网络实战K8s网络模型要求每个Node上的容器都可以相互访问。一个Pod内的所有容器都需要共用同一个IP地址意味着一定要使用网络的容器映射模式。Pod会启动一个基础容器然后将Pod内所有容器都连接到上面只需要为基础的这个Google_containers/pause容器执行端口映射规则。1.部署一个RC/PodapiVersion: v1 kind: ReplicationController metadata: name: frontend labels: name: frontend spec: replicas: 1 selector: name: frontend template: metadata: labels: name: frontend spec: containers: - name: php-redis image: kubeguide/guestbook-php-frontend env: - name: GET_HOSTS_FROM value: env ports: - containerPort: 80 hostPort: 80假设在一个空的K8s集群上运行检查下此时Node上网络接口有哪些ifconfig可以看出有一个docker0网桥和一个本地地址的网络端口。部署RC/Pod配置文件kubectl create -f frontend-controller.yaml kubectl get pods docker ps运行了两个容器其中一个是google_containers/pause:latest的镜像。实际Pod的IP数据流的网络目标都是这个google_containers/pause容器而google_containers/pause容器实际上只负责接管这个Pod的Endpoint。通过docker port命令来检验下docker port2.发布一个服务Service允许在多个Pod之间抽象一些服务服务可以通过提供在同一个Service的多个Pod之间的负载均衡机制来支持水平扩展。K8s集群会为服务分配一个虚拟IP地址这个IP地址是在K8s的Portal Network中分配的Portal Network的地址范围则是在Kubmaster上启动API服务进程时使用–service-cluster-ip-rangexx命令行参数指定的。这个IP段可以是任何段只要不和docker0或者物理网络的子网冲突就可以。目标为Service IP地址和端口的任何流量都将被重新定向到本地端口。 frontend-service.yamlapiVersion: v1 kind: Service metadata: name: frontend labels: name: frontend spec: ports: - port: 80 selector: name: frontend然后在K8s集群中定义这个服务kubectl create -f frontend-service.yaml kubectl get servicesK8s集群已经为这个服务分配了一个虚拟IP地址这个IP地址是在K8s的Portal Network中分配的。Portal Network的地址范围则是在K8s上启动API服务进程时使用–service-cluster-ip-rangexx命令行参数指定的。kube-proxy服务给每一个新创建的服务关联了一个随机的端口号并且监听特定端口为服务创建相关的负载均衡对象。K8s的kube-proxy作为一个全功能的代理服务器管理了两个独立的TCP连接一个是从容器到kube-proxy另一个是kube-proxy到负载均衡的目标pod。登陆服务器检查Iptables/Netfilter的规则iptables-save所有流量都被导入kube-proxy中需要kube-proxy完成一些负载均衡工作创建Replication Controller并观察结果。apiVersion: v1 kind: ReplicationController metadata: name: frontend labels: name: frontend spec: replicas: 3 selector: name: frontend template: metadata: labels: name: frontend spec: containers: - name: php-redis image: kubeguide/example-guestbook-php-redis env: - name: GET_HOSTS_FROM value: env ports: - containerPort: 80 hostPort: 80在集群上发布配置文件等待并观察确保所有Pod都运行起来了kubectl create -f frontend-controller.yaml kubectl get pods -o wide所有Pod都运行起来后Service会将匹配到的标签为namefrontend的所有Pod都进行负载分发。因为Service的选择匹配所有这些Pod负载均衡将会对这3个Pod进行分发。