SIG-Networking：Kubernetes 网络策略 API 将在 1.3 中推出

编者按：本周我们将重点介绍Kubernetes 特别兴趣小组；今天的文章由网络 SIG 团队撰写，描述了 1.3 版本中即将推出的网络策略 API - 用于安全、隔离和多租户的策略。

Kubernetes 网络 SIG 自去年年底以来一直在定期举行会议，致力于将网络策略引入 Kubernetes，我们开始看到这项工作的成果。

许多用户遇到的一个问题是，Kubernetes 的开放访问网络策略不适用于需要更精确地控制访问 pod 或服务的流量的应用程序。如今，这可能是一个多层应用程序，其中只允许来自层邻居的流量。但随着新的云原生应用程序通过组合微服务构建，控制流量在这些服务之间流动的能力变得更加重要。

在大多数 IaaS 环境（公共和私有）中，这种控制是通过允许 VM 加入“安全组”来提供的，其中到组成员的流量由网络策略或访问控制列表 (ACL) 定义，并由网络数据包过滤器强制执行。

网络 SIG 通过确定具体的用例场景来启动这项工作，这些场景需要基本的网络隔离来增强安全性。为这些简单和常见的用例获得正确的 API 非常重要，因为它们也是 Kubernetes 内多租户所需更复杂的网络策略的基础。

根据这些场景，考虑了几种可能的方法，并定义了最小的策略规范。基本思想是，如果在每个命名空间的基础上启用隔离，则将选择允许特定流量类型的特定 pod。

快速支持此实验性 API 的最简单方法是以 API 服务器的 ThirdPartyResource 扩展的形式，这在 Kubernetes 1.2 中是可行的。

如果您不熟悉它的工作原理，可以通过定义 ThirdPartyResources 来扩展 Kubernetes API，这些资源会在指定的 URL 处创建一个新的 API 端点。

third-party-res-def.yaml

kind: ThirdPartyResource

apiVersion: extensions/v1beta1

metadata:

  name: network-policy.net.alpha.kubernetes.io

description: "Network policy specification"

versions:

- name: v1alpha1

$kubectl create -f third-party-res-def.yaml

这将创建一个 API 端点（每个命名空间一个）

/net.alpha.kubernetes.io/v1alpha1/namespace/default/networkpolicys/

第三方网络控制器现在可以侦听这些端点，并在创建、修改或删除资源时做出必要的反应。注意：随着 Kubernetes 1.3 的即将发布 - 当网络策略 API 以测试版形式发布时 - 将无需如上所示创建 ThirdPartyResource API 端点。 

默认情况下，网络隔离处于关闭状态，以便所有 pod 都可以正常通信。但是，重要的是要知道，一旦启用网络隔离，所有命名空间中所有 pod 的所有流量都将被阻止，这意味着启用隔离将改变 pod 的行为

网络隔离是通过在命名空间上定义 _network-isolation_ 注释来启用的，如下所示

net.alpha.kubernetes.io/network-isolation: [on | off]

启用网络隔离后，**必须应用**显式网络策略才能启用 pod 通信。

可以将策略规范应用于命名空间以定义策略的详细信息，如下所示

POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys/


{

"kind": "NetworkPolicy",

"metadata": {

"name": "pol1"

},

"spec": {

"allowIncoming": {

"from": [

{ "pods": { "segment": "frontend" } }

],

"toPorts": [

{ "port": 80, "protocol": "TCP" }

]

},

"podSelector": { "segment": "backend" }

}

}

在此示例中，“ tenant-a ”命名空间将应用策略“ pol1 ”，如所示。具体来说，具有 segment 标签“ backend ”的 pod 将允许接收来自具有 segment 标签“ frontend ”的 pod 在端口 80 上的 TCP 流量。

如今，Romana、OpenShift、OpenContrail 和 Calico 支持应用于命名空间和 pod 的网络策略。思科和 VMware 也在致力于实施。Romana 和 Calico 最近在 KubeCon 上使用 Kubernetes 1.2 演示了这些功能。您可以在这里观看他们的演示文稿：Romana（幻灯片），Calico（幻灯片）。 

它是如何工作的？

每个解决方案都有其自己的具体实现细节。如今，它们依赖于某种主机上的强制机制，但将来也可以构建在虚拟机管理程序上甚至直接由网络本身应用策略的实现。 

外部策略控制软件（具体细节因实现而异）将监视新 API 端点，以了解正在创建的 pod 和/或正在应用的新策略。当发生需要策略配置的事件时，侦听器将识别更改，控制器将通过配置接口并应用策略来响应。 下图显示了 API 侦听器和策略控制器通过主机代理本地应用网络策略来响应更新。pod 上的网络接口由主机上的 CNI 插件配置（未显示）。

如果您由于网络隔离和/或安全问题而一直不愿使用 Kubernetes 开发应用程序，那么这些新的网络策略将大大有助于提供您所需的控制。无需等到 Kubernetes 1.3，因为网络策略现在可以作为实验性 API 使用，并作为 ThirdPartyResource 启用。

如果您对 Kubernetes 和网络感兴趣，可以通过多种方式参与 - 加入我们

• 我们的网络 Slack 频道 
• 我们的Kubernetes 网络特别兴趣小组电子邮件列表 

网络“特别兴趣小组”，每两周在太平洋时间下午 3 点（15:00）举行一次会议，网址为SIG-Networking 视频群聊。

• ←上一页
下一页→