转载

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

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

网络策略

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

分段流量

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

长期以来，深度防御被建议作为最佳实践。在AWS和OpenStack上，通过将安全组应用于VM，可以轻松实现应用程序的不同部分或层之间的这种隔离。

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

yaml

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或任何其他服务器配合使用。