SIG-Networking：Kubernetes 1.3 将带来网络策略 API

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

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

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

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

网络 SIG 通过识别需要基本网络隔离以增强安全的特定用例场景启动了这项工作。为这些简单常见的用例正确设计 API 非常重要，因为它们也是 Kubernetes 中多租户所需更复杂网络策略的基础。

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

快速支持这个实验性 API 的最简单方法是作为 API Server 的 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 将以 Beta 形式发布 - 将不再需要像上面那样创建 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 的网络策略。Cisco 和 VMware 也在开发实现。Romana 和 Calico 最近在 KubeCon 上展示了他们在 Kubernetes 1.2 中的这些能力。您可以在此处观看他们的演示：Romana (幻灯片), Calico (幻灯片)。 

它是如何工作的？

每种解决方案都有其特定的实现细节。目前，它们依赖某种主机上的强制执行机制，但未来的实现也可以构建为在虚拟机监控程序上应用策略，甚至直接由网络本身应用。 

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

如果您因为网络隔离和/或安全顾虑而迟迟没有使用 Kubernetes 开发应用，那么这些新的网络策略将极大地提供您所需的控制。无需等到 Kubernetes 1.3，因为网络策略现在已经作为通过 ThirdPartyResource 启用的实验性 API 提供。

如果您对 Kubernetes 和网络感兴趣，有几种参与方式 - 加入我们：

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

网络“特别兴趣小组”每两周在太平洋时间下午 3 点 (15:00) 在SIG-Networking hangout 会议室见面。

• ←上一页
• 下一页→