网络课程网站建设,360优化大师下载官网,网络架构模式,罗湖商城网站建设找哪家公司比较安全云计算网络极速入门-容器网络
本文是《云计算网络极速入门》三部曲#xff1a; 《云计算网络极速入门-虚拟机网络》#xff08;点击直接进入#xff09; 《云计算网络极速入门-容器网络》 《云计算网络极速入门-混合云网络》
的第二篇。
1、容器概述
1.1、容器基础
…云计算网络极速入门-容器网络
本文是《云计算网络极速入门》三部曲 《云计算网络极速入门-虚拟机网络》点击直接进入 《云计算网络极速入门-容器网络》 《云计算网络极速入门-混合云网络》
的第二篇。
1、容器概述
1.1、容器基础
前一篇文章介绍的虚拟机网络主要通过虚拟化来实现而容器网络的实现机制不同主要通过资源的隔离机制来实现。容器技术的兴起主要是由于虚拟机存在两大无法回避的问题 Hypervisor自身资源消耗较大同时磁盘IO性能低下。 一个虚拟机本身仍是一个独立的操作系统这对诸如微服务或者函数式应用来说仍显得太重了。
图1是容器技术的架构实现原理图为了便于读者理解每一个架构层的典型技术或者代表产品也在图上用红字标注。 图1-容器技术整体架构
其中运行引擎和资源管理都是单机程序。运行引擎类似虚拟化中的KVM和Xen运行在服务器和操作系统之上接受上层集群管理系统的管理运行引擎最典型的代表就是Docker它运行在Linux上但不仅仅Linux有容器技术Windows系统也有自己的容器化技术叫Hyper-V。
在容器资源管理上Docker最早使用LXCLinux Container后来开发了自己的LibContainer而CoreOS则开发了rkt微软则于2016年发布了基于Windows的容器技术Hyper-V Container原理与Linux的容器技术类似。
1.2、容器编排系统Kubernetes
容器是很轻量化的技术相对于物理机和虚拟机而言在等量资源的基础上能创建出更多的容器实例。一旦面对着分布在多台主机上且拥有数百个容器的大规模应用时传统的或单机的容器管理解决方案就会变得力不从心。另一方面由于为微服务提供了越来越完善的原生支持在一个容器集群中的容器粒度越来越小、数量越来越多这种情况下容器或微服务都需要接受管理并有序接入外部环境从而实现调度、负载均衡等任务。这就是容器编排。简单而高效地管理快速增长的容器实例是容器编排系统的主要任务而K8Skubernetes则是此方面的当红选手下面我们重点介绍K8S。
K8S是主从模式的分布式集群架构其整体架构如图2所示共包含Master和Node两种节点 Master控制节点调度管理整个系统 Node运行节点运行业务容器。每个Node上运行多个Pod每个Pod中可以运行多个容器通常一个Pod中只部署一个容器也可以将一些高度耦合的容器部署在一起然而Pod无法直接对来自K8S集群外部的访问提供服务。 图2-Kubernetes架构
1.2.1、Master主控机
K8S的Master节点包含如下4大组件 etcdK8S用于存储各个资源状态的分布式数据库采用Raft协议作为一致性算法。 API Serverkube-apiserver主要通过REST提供认证和授权、管理API版本等功能任何对资源Pod、Deployment、Service等进行增、删、改、查等操作都要交给API Server处理后再提交给etcd。 Schedulerkube-scheduler负责调度Pod到合适的Node上根据集群的资源和状态选择合适的节点创建PodScheduler的输入是Pod和多个Node组合的列表输出是Pod和一个Node的绑定即将Pod部署到Node上。K8S提供了调度算法的实现接口用户可以根据自己的需求定义自己的调度算法。 Controller ManagerK8S的后台每个资源一般都对应一个控制器Controller Manager就是负责管理这些控制器的Pod创建之后保证Pod的状态始终和预期一样的重任就由Controller Manager去完成了。
1.2.2、Pod容器集
“容器集”Pod是K8S的基本操作单元也是应用运行的载体。Pod为容器分组增加了一个抽象层有助于调整工作负载均衡并为这些容器提供所需的联网和存储等服务。一个Pod表示一组容器所形成的集合以及这些容器所共享的一些资源这些资源包括 共享的存储如卷Volume 网络 运行这些容器所需的相关信息如容器镜像版本、使用的特定端口等。
同一个Pod下的多个容器共用一个IP这就要求这些容器中不能出现同样的端口号比如一个Pod下运行两个Apache服务器就会有一个容器异常。同一个Pod下的多个容器可以使用localhost加端口号访问对方的端口。
1.2.3、Node工作机
Node可以是虚拟机也可以是物理机但不管是那种都统一由Master来管理。Node上可以有1~N个PodMaster会根据集群中每个Node上的可用资源情况自动地调度Pod的部署。Node包含如下3大组件 kubelet是Master在每个Node节点上的agent主要负责容器管理包括Master和Node之间的通信、管理Pod和容器。 kube-proxy实现了K8S中的服务发现和反向代理功能面向应用K8S通过它实现虚拟IP路由及转发每个Node上都需要部署Proxy组件从而实现K8S层级的虚拟转发网络。 反向代理支持TCP和UDP连接转发默认基于Round Robin算法将客户端流量转发到与Service对应的一组后端Pod。 服务发现使用etcd的监听机制监控集群中Service和Endpoint对象数据的动态变化并且维护一个Service到Endpoint的映射关系从而保证了后端Pod的IP变化不会对访问者造成影响。此外kube-proxy还支持session affinity会话关联。 一个容器负责从Registry拉取容器镜像、解压缩容器及运行应用程序等工作。
K8S中Pod的迁移实际指的是在新Node上重建Pod。当某个Pod失败时首先会被K8S清理掉之后Replication Controller会在其他机器或本机上重建Pod重建之后Pod的ID发生了变化与原有的Pod将拥有不同的IP地址因而将会是一个新的Pod。
node上包含两大核心概念 Replication ControllerRC是K8S的一个核心概念它会确保任何时间K8S中都有指定数量的Pod在运行。同时提供弹性伸缩根据负载的高低动态调整Pod的副本数量、滚动升级逐步替代策略同步Pod的不同版本来实现等能力。RC与Pod的关联是通过Label标签来实现的Label不具有唯一性为了准确标识Pod应该为Pod设置多个维度的Label。此外新一代的Service命名为Replica Set引入了对基于子集的selector查询条件而RC仅支持基于值相等的selector查询条件。 ServiceK8S的另一个核心概念是服务的抽象定义了一个Pod的逻辑分组和访问这些Pod的策略执行相同任务的Pod可以组成一个Service并以Service的IPVIP不是一个真实的IP地址在外部无法寻址提供服务。Service的目标是提供一种桥梁它会为访问者提供一个固定的访问地址。用于在访问时重定向到相应的后端。Service同RC一样也是通过Label来关联Pod的。一组Pod能够被Service访问到通常是通过Label selector实现的。Service负责将外部的请求发送到Kubernetes内部的Pod同时也将内部Pod的请求发送到外部从而实现服务请求的转发。Service可以作为Pod的访问入口起到代理服务器的作用。K8S为每个Service分配一个唯一的ClusterIP所以当使用ClusterIPPort的组合访问一个Service的时候不管Port是什么这个组合是一定不会发生重复的。
此外K8S还有Deployment和Namespace两大概念 DeploymentK8S提供了一种简单的更新RC和Pod的机制叫做Deployment它使用了RS(Replica Set)。通过在Deployment中描述所期望的集群状态Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成期望的集群状态。Deployment的主要职责同样是为了保证Pod的数量和健康继承了上面所述的Replication Controller全部功能90%的功能与RC完全一样可以看出是新一代的RC。但它又具有新的特性 时间和状态查看可以查看Deployment的升级详细进度和状态。 回滚 版本记录每次Deployment操作都能够记录下来 暂停和启动 Namespace不同于Linux的Namespace。而是对于同一个物理集群K8S可以虚拟出多个虚拟集群这些虚拟集群即称为Namespace。可以通过Namespace将一个集群的资源分配给多个用户IaaS。
2、基础Docker网络
K8S的默认容器实现是DockerDocker容器基本上成为了容器引擎的事实标准。我们本篇文章就以Docker为例来介绍容器网络。
Docker最初只支持三种网络驱动bridge、none、host在引入Libnetwork之后又增加了overlay、remote driver、macvlan等驱动类型。Docker在Libnetwork中使用它主导的CNMContainer Network Model虚拟化网络模型提供了可以用于开发多种网络驱动的标准化接口和组件。用户能以驱动/插件的形式使用其它特定类型的网络插件实体例如overlay。CNM中主要有沙盒sandbox、端点endpoint和网络network3种组件 沙盒一个沙盒包含了一个容器网络栈的信息。沙盒可以对容器的接口interface、路由和DNS设置等进行管理。沙盒的实现可以是Linux network namespace、FreeBSD Jail或类似的机制。一个沙盒可以有多个端点和网络。 端点一个端点可以加入一个沙盒和一个网络。端点的实现可以是veth pair、Open vSwitch内部端口或类似的设备。一个端点可以属于一个网络并且只属于一个沙盒。 网络一个网络是一组可以直接互相联通的端点。网络的实现可以是Linux Bridge、VLAN等。一个网络可以包含多个端点。
目前通过不同的驱动Docker可以实现不同类型的网络以下是Dock常用的几种网络驱动 Bridge驱动默认的网络驱动创建的网络为桥接网络。桥接网络适用于在同一个主机上运行的容器直接的通信。 host驱动使用host作为驱动程序容器直接使用宿主机网络并去除容器与宿主机之间的网络隔离。 overlay网络驱动可以连接多个宿主机从而使Swarm服务之间能够互相通信。 macvlan网络驱动为容器分配mac地址从而使其显示为网络上的物理设备。 network plugin可以从Docker Store或第三方供应商处获得网络插件。 none使用none驱动的容器被禁止使用网络。
Docker默认设置下使用Linux bridge驱动来实现Bridge网络。此时Docker会自动生成一个虚拟网桥docker0并且从RFC1918定义的私有地址块中为其分配一个子网。Docker为每一个生成的容器分配一个已连接至网桥的虚拟以太网设备veth而veth则通过Linux Namespace在容器中映射显示为eth0容器内部的eth0会在网桥的地址段内被分配一个IP地址。
Bridge网络下仅当多个Docker容器处于同一个物理主机内时才能互相通信。为了使得跨主机的Docker容器间能够实现互相通信必须要在主机自身的IP地址上为它们分配端口并将这些端口转发或代理至容器处如图3所示。 图3-Docker的网络实现
显然同一主机上的容器之间必须相互协调小心使用分配的端口或是动态分配这些端口以防止端口冲突。
3、进阶Kubernetes网络
K8S作为容器的编排框架在网络层面并没有进入更底层的具体容器互通互联的网络解决方案的设计中而是将网络功能一分为二主要关注Kubernetes服务在网络中的暴露以及Pod自身网络的配置至于Pod具体需要配置的网络参数以及Service、Pod之间的互联互通则交给CNI容器网络接口规范来解决。这样K8S本身不会具有太复杂的网络功能从而能够将更多的精力放在K8S服务和容器的管理上最终能够对外呈现一个易于管理、可用性高的应用服务集群。
我们前面介绍了Docker的CNM容器模型而CNI则是由Google、CoreOS、K8S主导的容器网络模型它们之间是直接竞争关系但不管是CNM还是CNI只是容器网络的规范并不是网络实现从开发者的角度看它们就是一堆接口。CNI的接口主要包含4大方法 添加网络 删除网络 添加网络列表 删除网络列表
CNI插件必须是实现为一个可执行文件这个可执行文件再被容器编排管理系统例如K8S所调用。CNI插件负责将网络接口插入容器网络命名空间例如veth pair的一端并在主机上进行任何必要的改变例如将veth的另一端连接到网桥然后将IP分配给接口并通过调用适当的IPAMIP Address Management IP地址管理插件来设置路由。一些常见的CNI插件如下 FlannelCoreOS开源的网络方案负责为K8S集群中的多个Node间提供Layer3的IPV4网络它的底层通信可以选择UDP、VxLAN、AWS VPC等不同协议默认为UDP协议部署和管理相对简单。 Calico一个基于BGP的纯三层的数据中心网络方案。它主要通过Linux内核实现一个高效的vRouter来负责数据转发基于iptables创建相应的路由规则。 Weave Net会创建一个虚拟网络实现跨主机的Docker容器互联并提供了自动发现机制。 Contiv思科开源方案兼容CNI和CNM模型它的特点是用户可以根据容器实例IP地址直接进行访问。 CNI-Genie支持为一个Pod分配多个IP地址每个IP地址由不同的CNI插件提供。 Cilium主要运行在网络Layer3层及Layer4层以一种不干涉运行在容器中的应用程序的方式提供了安全的网络连接和负载均衡。 Contrail基于OpenContrail是一个真正开放的多云网络虚拟化和策略管理平台。Contrail和OpenContrail已经与各种编排系统集成如K8S、OpenShift、OpenStack和Mesos并为容器或Pod、虚拟机和裸机的工作负载提供了不同的隔离模式。 Multus可以解决K8S的Pod默认不支持多网卡配置的问题。Multus自己不会进行任何网络配置而是调用其它CNI插件来实现多个网络接口配置。
有了CNI的支持就可以在K8S中很容易的构建各种网络接下来我们就来看看容器网络下的各类应用场景是如何实现的。
3.1、Pod内部的容器间通信
K8S为每一个Pod分配一个IP地址且同一个Pod内的容器共享Pod的网络命名空间。K8S在创建Pod时会首先在Node节点上创建一个运行在Docker Bridge网络上的“Pod容器”并为这个Pod容器创建虚拟网卡eth0及分配IP地址。而Pod里的容器称为APP容器只需要在创建时使用--netcontainer:id加入该网络命名空间这样所有的Docker容器就可以都运行在同一个网络命名空间中。
K8S这种“IP-per-pod”网络模型能让Pod里的容器之间通过localhost网络访问但这同时也意味着Pod里的容器必须有效协调使用端口在端口分配上不能发生冲突。由于不同的Pod之间拥有不同的IPPod里的容器根本不用担心和其它Pod里的容器发生端口冲突。
3.2、Pod间通信
3.2.1、同一个Node主机内的Pod之间通信
由于每一个Pod都有一个真实的全局IP地址因此同一个Node内的不同Pod之间可以直接采用对方的IP地址通信而且不需要使用DNS等其它发现机制。 图4-同一Node内的Pod通信架构
如图4所示在Pod1、Pod2的Linux协议栈上默认路由都是Docker0的地址也就是说所有非本地地址的网络数据都会被默认发送到Docker0网桥上由Docker0网桥直接中转。由于Pod1和Pod2都关联在同一个Docker0网桥上位于同一个网段它们之间是能直接通信的。
3.2.2、不同Node主机上的Pod之间通信
要想支持不同Node上的Pod间通信要满足如下两个条件 在整个K8S集群中对Pod的IP地址分配进行全局合理规划不能有冲突。我们前面介绍了Pod的调度是通过kube-scheduler来实现的这个条件可以通过在kube-scheduler中进行规划的时候用诸如ETCD这样的统一存储服务保存IP来实现。 找到一种办法将Pod的IP地址和所在Node的IP地址关联起来让Pod之间可以互相访问。
因此如图5所示在实际环境中除了部署K8S和Docker外还需要额外的网络配置甚至通过一些软件或插件来实现K8S对网络管控的要求。在此之上Pod之间才能无差别地进行通信。 图5-不同Node的Pod之间通信架构
3.3、Pod与Service之间的网络通信
前面介绍了K8S中的Service是一个抽象的实体Kubernetes在创建Service实体时为其分配了一个虚拟的IP这个IP地址是相对固定的此外K8S还通过Service实现了负载均衡、服务发现和DNS等功能。当需要访问Pod里的容器所提供的功能时不直接使用Pod的IP地址和端口而是访问Service的这个虚拟IP和端口再由Service把请求转发给它背后的Pod。
如图6所示K8S在创建Service时根据Service的标签选择器Label Selector来查找Pod据此创建与Service同名的EndPoints对象Service的targetPort和Pod的IP地址都记录在与Service同名的Endpoints里。当Pod的地址发生变化时EndPoints也随之变化。当Service接收到请求时就能通过EndPoints、找到请求需要转发的目标地址。 图6-K8S中的Service请求分发原理
Service只是一个虚拟概念是一个抽象实体为其分配的IP地址也只是一个虚拟的IP地址这背后真正负责转发请求的是运行在Node上的kube-proxy。目前kube-proxy共有三种请求转发模式分别为userspace、iptables和ipvs userspacekube-proxy会监控Master对Service和Endpoints对象的添加和删除操作。创建Service时Node节点上的kube-proxy会为其随机开放一个端口简称代理端口然后建立一个iptables规则iptables会完成服务虚拟IP端口与代理端口的流量转发再从Endpoints里选择一个Pod把代理端口的流量转给该Pod。 iptables这种模式下创建Service时Node节点上的kube-proxy会建立两个iptables规则一个为Service服务用于将服务虚拟IP端口的流量转给后端另一个为Endpoints创建用于选择Pod。 ipvs调用netlink接口以创建相应的ipvs规则并定期与Service和Endpoint同步ipvs规则从而确保ipvs状态与期望一致。ipvs模式需要在Node上预装ipvs内核模块。
3.4、K8S外界与Service之间的网络通信
根据应用场景的不同K8S提供了4种类型的Service ClusterIP默认类型。在集群内部的IP地址上提供服务并且该类型的Service只能从集群内部访问。 NodePort通过每个Node IP上的静态端口NodePort来对外提供服务集群外部可以通过访问NodeIP:NodeProt来访问对应的端口。在使用该模式时会自动创建ClusterIP访问NodePort的请求会最终路由到ClusterIP。 LoadBalancer通过使用云服务提供商的负载均衡器对集群外部提供服务。使用该模式时会自动创建NodePort和ClusterIP集群外部的负载均衡器最终会将请求路由给NodePort和ClusterIP。 ExternalName将服务映射到集群外部的某个资源例如foo.bar.example.com。
4、容器网络的缺陷及解决办法
在生产环境中为了保证安全和性能不同功能的网络进行隔离是一个必须要的措施一般常用的可以分为 管理网络 控制网络 数据网络
这三种类型网络的隔离。这种隔离对于物理机和虚拟机来说很容易实现但是在使用Kubernetes容器的Pod时则会面临一些限制尤其是现在K8S的Pod默认还不支持多网卡设置。
可以通过Multus来解决这个缺陷Multus能够支持几乎所有的CNI插件包括Flannel、DHCP和Macvlan等。Multus使用“delegates”的概念将多个CNI插件组合起来并指定一个master plugin作为Pod的主网络并且被K8S感知。
Multus自己不会进行任何网络设置而是调用其它插件如Flannel、Calico来完成真正的网络配置。它重用了Flannel中调用代理的方式通过将多个插件分组再按照CNI配置文件的顺序来调用它们。默认的网络接口名称为“eth0”而Pod中的网络接口名称为net0、net1、...netX。通过这种方式就可以让同一个Pod同时支持多个互相隔离的网络。 附参考文献 《Linux开源网络》 《Docker 容器与容器云》 《软件定义网络 SDN与OpenFlow解析》 《混合云架构》 《深度探索Linux系统虚拟化》
最后——
我把十几年的经验总结起来出了本书叫做《微服务治理体系、架构及实践》大家如果感兴趣可以关注一下。
