云主机(云服务器)_云主机云服务器vps「云主机官网」

　　在企业内利用Kubernetes，对摆设在Kubernetes上的应用做访问控制是比力根本的安全需求，不但要控制外部流量，而且各服务之间的流量也要分身。对此Kubernetes也给出了官方的解法——NetworkPolicy。然而，这还要仰仗各网络驱动的支持程度。而对于差别范例的网络驱动（如基于路由技能或隧道技能）又各有各的解法和困难。文章中，我们将分析主流Kubernetes网络驱动是怎样支持NetworkPolicy的，同时，分享面对公有云复杂需求探索的履历和企业落地Kubernetes私有云的办理思绪。

　　在企业内利用Kubernetes，其上摆设的应用是否必要严格的访问控制，这个答案并不总是肯定的，至少支持访问控制并不是方案选型时的优先思量要素。但对于我们行云创新来讲，这种控制必不可少。由于，我们提队供的公有云业务答应任何个人和团自由地开辟和摆设应用到恣意云端，那么为每位用户的应用提供安全可靠的访问控制是一个非常根本的要求。信托我们对公有云复杂需求的探索履历和一些办理思绪也将对浩繁企业落地Kubernetes私有云非常有鉴戒意义。

　　NetworkPolicy

　　Kubernetes提供了一种叫NetworkPolicy的对象，专门用来办理L3/L4访问控制的题目。然而，它只界说了怎样订定这些战略，而它们怎样来发挥作用却还要仰仗各Kubernetes网络插件的支持程度。而对于差别范例的网络插件在支持NetworkPolicy方面又有各自的解法和面对的挑衅。

　　在本次分享中，我们将在简单分析主流Kubernetes网络插件怎样支持NetworkPolicy之余，报告行云创新在实现访问控制的过程中遇过到的那些挑衅，以及它们又是怎样被办理的。

　　起首我们来聊聊KubernetesNeworkPolicy对象。

　　简单的说，NetworkPolicy是通过界说战略对选定Pod举行网络通讯控制的，如许可以让运行在POD里的业务受到安全掩护。Kubernetes早在1.6版本中就支持了NetworkPolicy对象，但只能通过Selector对Pod间通讯举行控制，直至1.8版本在NetworkPolicyPeer对象支持IPBlock之后，才具备了通过指定IP段（CIDR）的方式对集群表里访问举行全面控制。

　　下面我们分析一下NetworkPolicy是怎样工作的。

　　上图是NetworkPolicy对象的布局平铺图。NetworkPolicy的作用域在Namespace内，它通过podSelector来确定哪些Pod将受这个policy束缚。在一个NetworkPolicy对象中，可以设置多条NetworkPolicyEgressRule和NetworkPolicyIngressRule，分别用来做出口和入口的访问控制。每条Rule由一组NetworkPolicyPeer和一组NetworkPolicyPort构成，意思比力明白，这组Peers的这些Ports被授予了访问权限。

　　NetworkPolicyPeer则可以是两类资源，其一是通过namespaceselector和podselector来筛选出Pod，另一则是前文提到过的IPBlock，它通过CIDR来指定。具体的设置方式可以参考官方文档：https://kubernetes.io/docs/concepts/services-networking/network-policies。

　　从上图我们可以看出，无论Ingress还是Egress，NetworkPolicy界说的是Pod之间大概Pod和某些CIDR之间的关系。从Kubernetes的计划理念和访问实际发生的位置来看，如许的计划着实再公道不外。然而，却给实现层面增长了不少复杂度，乃至大概会影响到是否可以或许让方案落地实现。题目重要出在以下几方面。

　　Pod网络由各网络插件提供的网络驱动支持，NetworkPolicy险些全部依靠这些网络驱动来实现，而差别原理的网络驱动并不肯定能实现NetworkPolicy的全部功能，而且难易程度也有所差别，即便到了本日，Kubernetes已经发布了1.10，NetworkPolicy仍旧没有被全部主流网络插件完备支持。

　　固然Pod网络由网络驱动实现，但Service网络却是Kubernetes管理的，而Kubernetes应用都是通过Service向外提供服务的，这中心的转换也会对NetworkPolicy的实现有严峻的影响。

　　在依照NetworkPolicy的条件下，同时还要思量以下各种环境怎样应对：

Pod访问APIserver的情况

基于网络访问的Probes（LivenessProbe和ReadinessProbe）

kube-proxy的--masquerade-all选项的开启和关闭

NodePort范例的Service是否会受到影响

集群扩容时NetworkPolicy的思量等

　　接下来我们简单分析一下主流的网络插件对NetworkPolicy的支持程度。

　　Kubernetes网络插件

　　Calico

　　Calico提供的是一个基于路由的办理方案，也就是说Pod之间的交互将通过在Node上见效的各种路由规则来实现。如下图所示。

　　Calico摆设完成后，每台Node上的Calico组件Felix会负责根据etcd中的设置来修改路由和iptables规则。Calico的组件BIRD则负责将这些路由战略分发到其他Node。Calico不但支持NetworkPolicy的特性，还支持了更多的安全战略，用户可以通过calicoctl客户端来设置，而这些特性也皆是通过iptables来实现的。

　　Flannel

　　Flannel的目标在于办理Node之间的网络互联题目，它支持浩繁实现方式，不但包罗VxLAN，IPIP等广泛的实现方式，还可以和不少公有云的网络办法直接集成，对于在公有云上摆设Kubernetes集群非常友爱。然而它旨在办理网络通讯的题目，因此并不支持NetworkPolicy。官方的发起是共同在这方面善于的Calico来利用，大概利用Canal。

　　Cilium

　　Cilium是一个非常风趣的项目，在组网方面它同时提供了基于路由的组网方式和基于VxLAN的Overlay网络。而在访问控制方面，它利用了BPF而非Netfilter。如下图所示。

　　比起其他的网络驱动，Cilium还比力年轻，尚未完全支持NetworkPolicy，但是它提供了CiliumNetworkPolicy对象用来提供更多的访问控制特性，不但包罗L3/L4的访问控制，乃至涵盖了L7的访问控制，非常了得。

　　WeaveNet

　　WeaveNet提供了一种非常便利的方式在Kubernetes主机之间构建一个Overlay网络，工作原理如下图所示。

　　WeaveNet在Kubernetes上以DaemonSet的情势摆设，每个Pod中包罗两个容器，分别是weave-kube和weave-npc。前者负责构建网络，后者则是[n]etwork-[p]olicy-[c]ontroller。WeaveNet必要在每台主机上创建一个bridge，作为主机上全部接入weave网络的Pod的网关，差别主机的bridge之间的数据流则会通过VxLAN协议转发，其他的数据流都会在主机上颠末SNAT从而进入主机网络。

　　对于NetworkPolicy，WeaveNet仅仅支持NetworkPolicyIngressRule和基于Selector的NetworkPolicyPeer，并不支持IPBlock范例的Peer。WeaveNet的实现方式和其他插件雷同，通过从APIServer监听NetworkPolicy的状态，修改主机上iptables战略和ipset来实现控制。

　　行云创新的选择

　　我们行云创新是怎样举行选择呢？

　　行云创新的公有云服务必须要具备跨多个云供应商的本领来资助用户打扫对单一云依靠，并构筑本钱上风。差别的云厂商，如阿里、华为、Azure、Ucloud、AWS等提供的网络架构和网络本领是差别很大的，这就决定了我们肯定谋面对非常复杂而且多样的网络环境，也应该选择一种与各公云的网络架构兼容最好的Kubernetes网络方案。先看看我们曾经在阿里上碰到的一个题目：

　　阿里云在网络底层采取了ARP挟制技能，全部网络通讯（包罗L2）都要到网关中转，自界说的“非法网络”将被扬弃，此时必要在阿里云平台上的路由表中增长战略，才有大概乐成。而别的家云在这些方面的举动又会大不雷同，包罗大概会存在路由表条目数量的限定。因此，基于路由技能的网络插件，如Calico就不是最符合的选择。

　　那么看看基于“隧道”技能的实现方案。同样利用VxLAN技能的Flannel和WeaveNet要怎样选择呢？WeaveNet除了设置简单，它尚有一个独特的功能，那就是它并不要求全部主机必须处于fullmeshnetwork中，对于如下这种网络拓扑它也可以或许支持。

　　以是行云创新在公有云的实现上选择了WeaveNet，但如同别的网络插件一样，在NetworkPolicy的支持上，它也无法完全满意我们应对的公有云环境下应用控问控制需求。

　　对于我们来说，对NetworkPolicy最急迫的需求当是支持IPBlock范例的NetworkPolicyPeer，这也是多集群管理的必要。试想多个微服务分别摆设在差别地理位置、差别云商的集群中时，IPBlock是Kubernetes给我们的唯一选择。为什么WeaveNet只支持了通过Selector来界说NetworkPolicyPeer，IPBlock不能用雷同的方法来实现吗？那我们必须来分析一下。

　　weave-npc通过APIServer监听NetworkPolicy的变革，并随之改变设置。它在得到NetworkPolicyPeer对象后，根据此中的Selector筛选出符合条件的Pod，在得到Pod的IP地点后便可以在Pod地点主机iptables的Filter表中设置规则，担当来自这些地点的哀求。固然，实际的实现方式要更高效和复杂一点。那么基于IPBlock的NetworkPolicyPeer是否也能云云简单？答案固然是否定的，至于缘故起因还要从怎样从集群外访问到集群内应用提及，我们称之为L3接入方式。

　　Kubernetes以Service的方式管理L3接入，那么便可以通过LoadBalancer和NodePort直接从集群外访问Service，这是比力常见的方式。但技能上来讲，我们还可以买通集群外到ClusterIP的路由，来直接访问Service的ClusterIP。照此原理，若各人盼望从集群外直接访问Pod网络本身，通过直接路由的方式也是可以告竣的，只不外要把Pod的IP袒露到全网中。

　　我们来看看自集群外访问集群内服务的简图。

　　如上图所示，无论是通过NodePort还是直接访问ServiceClusterIP的方式来接入，全部哀求都会在进入主机网络时颠末DNAT，将目标地点和端口转换成Service对应的Pod及其端口。而在经过Weavebridge将哀求转发到Pod大概另一台Node的WeaveBridge前（此时会通过隧道方式以VxLAN协议传输）会再做一次SNAT，将源地点修改为WeaveBridge的地点，这是Kubernetes确定的规则。

　　若我们如法炮制实现IPBlock，肯定谋面对如许的困难。如上图示例，Node2在吸取到对PodB的哀求时，该哀求已然在Node1上颠末了SNAT，其源地点已经变成了Node1上WeaveBridge的地点，而非原始的源地点，此时再在Node2上实行NetworkPolicy怕是会发生错误，由于我们想要做访问控制的是原始的源地点。那么Kubernetes为何要在这个关键位置做SNAT？这是必须的吗？

　　面对这个题目，我们的办理思绪是，只要将针对每个Pod的NetworkPolicy应用到全部的Node上而非仅仅在Pod地点的Node上即可，如同kube-proxy一样。如许，WeaveNet就可以全面支持单Kubernetes集群的NetworkPolicy了。别的，尚有一个风趣的题目值得思考，Pod和Node之间的交互是否要受NetworkPolicy的束缚[？这个题目我将在稍后和各位朋侪加以分析。

　　接下来，我们来报告一个更加复杂的场景，也是行云创新要面对的场景，即将差别的微服务摆设到差别地理位置、差别云商的Kubernetes集群，它们要怎样相互访问，又怎样来做访问控制呢？为了连续用户在Kubernetes集群中的利用风俗和代码风俗，在跨集群摆设服务时维持Service和Kubernetes的服务发现机制是必须的(跨地理位置、跨云商的服务发现我们会在将来分享中具体加以交换)。请看下图。

　　从路由的角度来看，跨集群访问并没有什么特别之处，买通双向路由即可。然而WeaveNet提供的是Overlay的办理方案，主机网络上并不存在到Pod网络的路由战略，全部的Pod到集群外的访问均在从主机网卡发出时做了SNAT，故在Cluster2的Node上看到的哀求源地点是Cluster1的Node地点，而非PodA的地点，因此不能在Cluster2上简单地利用PodA的地点通过IPBlock设置NetworkPolicy。

　　那么WeaveNet在此时做SNAT是须要的吗？答案是肯定的。Pod网络和主机网络是相互隔离的，若他们要相互访问，则必须要创建起路由(Calico的做法)，大概在这种特别架构的条件下利用SNAT，使得Pod网络保持独立且不污染外部网络环境。那么为了实现跨集群的访问控制，我们必须对从Pod发出的哀求区别对待，如果访问其他集群的Service则不必要SNAT，否则依然要做SNAT。

　　至此，WeaveNet在行云创新跨地理位置、跨云商的场景下的连通和访问控制就完全实现了，而且它最大限度地继承了用户对Kubernetes的利用风俗。至于怎样利用和开辟网络插件，关键还是在于充实明白Kubernetes对Service和Pod网络的界说。

　　末了，对于前文中提出的题目“Pod和Node之间的交互是否要受NetworkPolicy的束缚？”来分享一下我们的思考。

　　从完备性的角度来讲，一旦开启了NetworkPolicy，那么全部的交互都应当受其控制，这此中天然包罗Pod和Node之间的通讯。此时就必要思量，当Pod必要访问APIServer大概设置Probe战略时，为它们开通访问控制的责任是否要交给用户？用户是否有充足的信息来完成这些设置？但从运营的角度来讲，集群中全部的Node都在运营商的控制中，是安全的，也就可以以为Pod和这些Node之间的通讯也是安全的。

　　固然，在跨地点位置、跨云商的复杂公有云环境中摆设业务其所面对的挑衅和技能陷阱并非本日的分享就可以或许先容全面的。

　　QA

　　Q：根据https://cmgs.me/life/docker-network-cloud的测试，Weave网络方案在性能上比其他方案差很多，这是真的吗？

　　A：该文章测试的时间并未开启fast-data-path，颠末我们的测试，在fast-data-path开启的环境下，还是很可观的。何况这个测试到本日已经已往了2年时间，Weave社区不停以来还是很活泼的，信托将来只会更好。

　　Q：叨教针对Azure和AWS在网络方面有没有碰到什么坑？好像前面只看到Aliyun的。

　　A：AWS有个“源/目标地点查抄”，华为云也有雷同功能，假如在你的网络计划中云主机出来或进去的IP与注册的云主机IP不符，则必要把它关掉，别的假如不关“源/目标”地查抄，也无法把目标主机设置成路由的next-hop；Azure重要就是默认动态公网IP，必要调解成固定IP。别的要特别留意主机间copy数据的流量费。

　　AWS上设置KubernetesforWindows确实大费周折，我们当时和Kubernetes社区的WindowsAIG的人一起搞了个方案，比力复杂。

　　Q：有没有什么办法为每个定名空间设置一个全局的NetworkPolicy，还是说必须要先创建定名空间才华界说NetworkPolicy（盼望是就像ClusterRoleBinding一样）？

　　A：至少如今还不可以，一样平常来说这不应该是广泛的需求，由于每个应用在一个Namespace下，而每个应用的的访问控制战略不大大概是雷同的。从另一个方面看，以Kubernetes社区的风格，任何广泛的需求终极都是会被实现的，而且速率很快。