且看K8S 1.3中将引入的网络策略API

Kubernetes在网络管理上目前为止是最为缺失的一个环节，但这将在1.3中有极大的改变。今天这篇帖子是由Network－SIG（Kubernetes Special Interest Groups）小组撰写，描述Kubernetes1.3中将加入网络策略API —— 关于安全、隔离、多租户。

Kubernetes SIG 小组自去年年底以来一直频繁开会，旨在给 Kubernetes 添加网络策略，也收获很多进展。

很多用户都遇到过一个问题，就是 Kubernetes 的开放网络策略对于有些程序是不合适的，比如那些需要更精确控制流量来问访问 pod 或者 service 的程序。现在，这可能是一个只允许流量从隔壁层流过来的多层应用程序。但是随着新的云原生应用组合着微服务的产生，控制信息流量在这些 service 间的流动的能力变得愈发重要。

在大多数的 IaaS 环境（无论公有还是私有），这种控制能力都是通过虚拟机加入一个“安全组”获得，在这个组里面流动到每个成员的流量是通过网络策略或者 ACL（Access Control List）来定义，并且由一个网络包过滤器执行。

网络 SIG 小组努力搭建，从识别特定的需要网络隔离增强安全性的案例场景（网址）着手。正确获得这些简单使用案例的 API 对于工作十分重要，因为这也是更加复杂的网络协议的基础，对于 Kubernetes 里面的多租户来说十分重要。

从这些场景中，一些可行的办法早就想到了，最小的策略规范已经被定义好了。基础的想法就是，如果每个命名空间之间开启隔离，那么特殊 pods 之间的通信就需要启用特定的策略。

要快速支持这个实验的 API 最简单的方法就是以第三方资源拓展（ThirdPartyResource）的形式到 API 服务器，Kubernetes 1.2 现在已经支持了。

如果对这个运行不熟悉，Kubernetes API 可以通过定义第三方资源（ThirdPartyResources）拓展，在指定的 URL 上创建一个新的 API 端点。

这样就可以创建一个 API 端点（每个命名空间一个）：

第三方网络控制器可以在这些端点上监听，当资源被创建、修改或者删除的时候作出必要的回应。注意：kubernetes 1.3 版本即将发布，网络策略 API 会以测试版的形式发布，那么也就没有必要像上文提到那样去创建一个第三方资源 API 端点了。

网络隔离默认设置下是关闭的，所以所有的 pods 之间正常情况下可以互相交流。然而，重点是一旦网络隔离打开，在所有的命名空间里，所有到 pods 的流量都会被拦截，也就是说，打开隔离将会改变你的 pods 的行为反应。

通过定义命名空间上的网络隔离注释来打开网络隔离，如下图所示：

只要网络隔离打开，网络协议肯定被用来做 pod 之间的交流。

政策规范可以应用到一个命名空间来定义政策的细节，具体如下图所示：

在这个例子中，‘tenant－a’命名空间 get 到‘pol 1’，如图所示。具体来说，带有段落标签‘backend’的 pods 会在 80 端口允许 TCP 流量在带有段落标签‘frontend’接收。

现在，Romana，OpenShift，OpenContrail 和 Calico 都支持网络协议应用到命名空间和 pods。Cisco 和 VMware 也都在致力于这方面的实施工作。Romana 和 Calico 最近在 KubeCon 证实了 Kubernetes1.2 的性能。你可以点击这里查看他们的 presentation：Romana幻灯片地址，Calico幻灯片地址。

如何运作

每个解决方案都有各自的实施细节。目前，他们依靠的是主机执行机制，但是未来的实施也会在超级管理器上面创建应用协议，或者直接依靠网络本身。

外部协议控制软件（不同实施细节）会为 pods 创建或者运用新的协议，查看新的 API 端点。当一个 event 要求策略配置，收听器会识别区别，控制器会通过配置界面、运用策略来回应。下面的框架展示了一个 API 收听器和协议控制器如何通过主机来应用网络策略，然后回应更新。pods 上面的网络界面是通过主机上一个 CNI 插件配置的（没有在图中展示）。

如果你因为网络隔断或者安全问题（或者两者都有）在开发程序时被绊住了，这些新的网络协议对提供你需要的 control 很有帮助。因为网络策略现在已经像一个 API 一样可得到，所以不需要等到 Kubernetes1.3。

本文转载自才云 Caicloud 公众号。

原文链接：https://mp.weixin.qq.com/s/yArhduqKagBW2iqEkuU7nA