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

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

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

许多用户面临的一个问题是，Kubernetes 的开放访问网络策略不适用于需要更精确控制访问 Pod 或服务的流量的应用程序。目前，这可能是一个多层应用程序，流量只允许来自某层的相邻层。但是，随着新的云原生应用程序通过组合微服务来构建，控制这些服务之间流量流动的能力变得更加关键。

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

网络 SIG 开始这项工作，首先确定了需要基本网络隔离以增强安全性的特定用例场景。正确地为这些简单常见的用例设计 API 非常重要，因为它们也是 Kubernetes 内部多租户所需更复杂网络策略的基础。

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

快速支持此实验性 API 的最简单方法是使用第三方资源扩展 API 服务器，这在 Kubernetes 1.2 中已可用。

如果您不熟悉其工作原理，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 以 Beta 形式发布时——将不再需要创建如上所示的第三方资源 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" }

}

}

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

目前，Romana、OpenShift、OpenContrail 和 Calico 支持应用于命名空间和 Pod 的网络策略。Cisco 和 VMware 也在开发实现。Romana 和 Calico 最近在 KubeCon 上展示了这些与 Kubernetes 1.2 结合使用的功能。您可以在这里观看他们的演示：Romana (幻灯片)、Calico (幻灯片)。 

它是如何工作的？

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

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

如果您一直因为网络隔离和/或安全问题而迟迟未在 Kubernetes 上开发应用程序，那么这些新的网络策略在提供您所需的控制方面大有裨益。无需等到 Kubernetes 1.3，因为网络策略现在作为实验性 API 提供，并作为第三方资源启用。

如果您对 Kubernetes 和网络感兴趣，有多种参与方式——欢迎加入我们：

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

网络“特别兴趣小组”，每两周一次在太平洋时间下午3点（15:00）在 SIG-Networking 聚会上开会。

• ←上一篇
• 下一篇→