# Kubernetes集群中的高性能网络策略

Kubernetes集群中的高性能网络策略

​ 自从7月份发布Kubernetes 1.3以来，用户已经可以在其集群中定义和实施网络策略。这些策略是防火墙规则，用于指定容许流入和流出的数据类型。若是须要，Kubernetes能够阻止全部未明确容许的流量。本文针对K8s的网络策略进行介绍并对网络性能进行测试。

网络策略

​ K8s的网络策略应用于经过经常使用标签标识的pod组。而后，可使用标签来模拟传统的分段网络，这些网络一般用于在多层应用程序中隔离层：例如，您能够经过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量，甚至控制来自外部源的流量。

分段流量

​ 这对于应用程序开发人员意味着什么？最后，Kubernetes得到了提供 深度防护 的必要能力。流量能够分段，应用程序的不一样部分能够独立保护。例如，您能够经过特定的网络策略很是轻松地保护每一个服务：由服务器后的Replication Controller标识的全部窗格都已由特定标签标识。所以，您可使用同一标签将策略应用于这些pod。

​ 长期以来，深度防护被建议做为最佳实践。在AWS和OpenStack上，经过将安全组应用于VM，能够轻松实现应用程序的不一样部分或层之间的这种隔离。

​ 然而，在网络策略以前，这种对容器的隔离是不可能的。VXLAN覆盖能够提供简单的网络隔离，可是应用程序开发人员须要对流量访问pod进行更细粒度的控制。从这个简单的例子能够看出，Kubernetes网络策略能够根据源和源头，协议和端口来管理流量。

apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
 name: pol1
spec:
 podSelector:
   matchLabels:
     role: backend
 ingress:
   - from:
   - podSelector:
      matchLabels:
       role: frontend
   ports:
   - protocol: tcp
     port: 80

并不是全部的网络后端都支持策略

​ 网络策略是一个使人兴奋的功能，Kubernetes社区已经工做了很长时间。可是，它须要一个可以应用策略的网络后端。例如，简单路由网络或经常使用的 flannel 网络程序自己不能应用网络策略。

​ 今天Kubernetes只有几个具备政策功能的网络组件：Romana，Calico和Canal;与Weave在不久的未来指示支持。 Red Hat的OpenShift还包括网络策略功能。

​ 咱们选择Romana做为这些测试的后端，由于它将pod配置为在完整L3配置中使用本地可路由的IP地址。所以，网络策略能够直接由Linux内核中的主机使用iptables规则应用。这个结果是一个高性能，易于管理的网络。

测试网络策略的性能影响

​ 在应用网络策略以后，须要根据这些策略来检查网络分组，以验证这种类型的业务是容许的。可是，对每一个数据包应用网络策略的性能损失是多少？咱们可使用全部的策略功能，而不会影响应用程序性能？咱们决定经过运行一些测试来找出。

​ 在深刻研究这些测试以前，值得一提的是，“性能”是一个棘手的测量，网络性能尤为如此。吞吐量（即以Gpbs测量的数据传输速度）和延迟（完成请求的时间）是网络性能的经常使用度量。文章：K8s网络延迟和比较k8s的网络方案已经检查了运行覆盖网络对吞吐量和延迟的性能影响。咱们从这些测试中学到的是Kubernetes网络一般至关快，服务器没有麻烦使1G链路饱和，有或没有覆盖。只有当你有10G网络，你须要开始思考封装的开销。

​ 这是由于在典型的网络性能基准测试期间，没有用于主机CPU执行的应用逻辑，使得它可用于任何须要的网络处理。**为此，咱们在不使链路或CPU饱和的操做范围内运行咱们的测试。这具备隔离处理网络策略规则对主机的影响的效果。**对于这些测试，咱们决定测量由在一系列响应大小范围内完成HTTP请求所需的平均时间来衡量的延迟。

测试步骤：

硬件

两台服务器采用IntelCore i5-5250U CPU（2核，每核2个线程），运行速度1.60GHz，16GBRAM和512GB SSD。

• NIC：Intel以太网链接I218-V（rev 03）
• Ubuntu14.04.5 
• Kubernetes 1.3（v1.4.0-beta.5上的验证样本）
• Romana v0.9.3.1
• 客户端和服务器负载测试软件。

​ 对于测试，咱们有一个客户端pod向服务器pod发送2,000个HTTP请求。 HTTP请求由客户端pod以确保服务器和网络均未饱和的速率发送。咱们还确保每一个请求经过禁用持久链接（如 HTTP 的Keep-alive）启动一个新的TCP会话。咱们使用不一样的响应大小运行每一个测试，并测量平均请求持续时间（完成该大小的请求须要多长时间）。最后，咱们用不一样的策略配置重复每组测量。

​ Romana检测Kubernetes网络策略建立时，将其转换为Romana本身的策略格式，而后将其应用于全部主机。目前，Kubernetes网络策略仅适用于入口流量。这意味着传出的流量不受影响。

​ 首先，咱们进行了没有任何政策的测试来创建基线。而后，咱们再次运行测试，增长测试网段的策略数量。策略是常见的“容许给定协议和端口的流量”格式。为了确保数据包必须遍历全部策略，咱们建立了一些不匹配数据包的策略，最后是一个将致使接受数据包的策略。

下表显示不一样请求大小和策略数量的结果（以毫秒为单位）：

​ 咱们在这里看到的是，随着策略数量的增长，即便在应用200个策略以后，处理网络策略也会引入很是小的延迟，毫不会超过0.2ms。为了全部实际目的，当应用网络策略时不引入有意义的延迟。还值得注意的是，响应大小从0.5k增长到1.0k几乎没有效果。这是由于对于很是小的响应，建立新链接的固定开销支配总体响应时间（即传送相同数量的分组）。

注意： 0.5k和1k线在上图中的〜.8ms重叠

​ 即便做为基准性能的一个百分比，影响仍然很小。下表显示，对于最小响应大小，最差状况下的延迟保持在7％或更小，最多200个策略。对于较大的响应大小，延迟降低到约1％。

​ 在这些结果中还感兴趣的是，随着策略数量的增长，咱们注意到较大的请求经历较小的相对（即百分比）性能降级。

​ 这是由于当Romana安装iptables规则时，它确保首先评估属于已创建链接的数据包。仅须要遍历链接的第一个数据包的完整策略列表。以后，链接被认为“创建”，而且链接的状态被存储在快速查找表中。所以，对于较大的请求，链接的大多数数据包都将在“已创建”表中进行快速查找，而不是对全部规则进行彻底遍历。这个iptables优化结果的性能在很大程度上独立于网络策略的数量。

​ 这样的“流表”是网络设备中的常见优化，彷佛iptables使用相同的技术至关有效。

​ 它还值得注意的是，在实践中，一个至关复杂的应用程序能够为每一个段配置几打规则。一样的，诸如Websockets和持久链接之类的公共网络优化技术甚至会进一步提升网络策略的性能（特别是对于小请求大小），由于链接保持打开时间更长，所以能够从已创建的链接优化中受益。 

​ 这些测试是使用Romana做为后端策略提供程序执行的，其余网络策略实现可能会产生不一样的结果。可是，这些测试显示，对于几乎每一个应用程序部署情形，可使用Romana做为网络后端应用网络策略，而不会对性能产生任何负面影响。 

​ 若是你想本身尝试，咱们建议使用Romana。在咱们的GitHub代码仓库中，您能够找到一个易于使用的安装程序，它与AWS，Vagrant VM或任何其余服务器配合使用。

总结

​ 经过以上的功能介绍和测试分析，k8s能够对应用之间流量以更小的颗粒度进行控制。网络性能损耗在能够接受的范围以内。

​ 好雨云帮目前的生产环境使用的是k8s 1.2.x版本，咱们在使用个版本的时候k8s尚未网络策略控制的功能，所以咱们是基于网络插件的方式来实现访问控制的。

​ 咱们正在进行k8s 1.3.x版本生产环境的性能及兼容性测试，随后会将全部的企业版本中进行升级，社区版会在企业版升级后的当月25日进行升级。

​ 后续咱们会针对calico与k8s结合的方式来完成网络互通和网络的隔离控制并对性能的损耗进行测试分析，在之后的文章中我会把测试的状况跟你们分享和讨论。

原文连接：http://blog.kubernetes.io/2016/09/high-performance-network-policies-kubernetes.html

云盟认证成员：JCH