Kubernetes NetworkPolicy网络策略零接触到应用

1. NetworkPolicy简介

在K8s中，可以用名称空间来隔离集群当中的多个资源，可以实现不同名称空间中创建具备同样名称及同类别的资源。可是在k8s中，名称空间不能隔离网络，无论是在那个名称空间中创建的pod,pod之间都能够进行互访。但是很多实际生产环境当中，都要求其他名称空间或外部客户端约束对此名称空间中的pod的访问，这时我们就可以在此名称空间中创建NertworkPolicy资源来实现该目的。

NertworkPolicy资源可以约束 外界客户端是否能够访问该名称空间下的pod，或那些pod不可以由哪一个名称空间或者pod访问。除了限制名称空间中的pod网络入站流量之外，还能够限定名称空间中的pod出站流量，允许或者拒绝pod访问某个名称空间下的pod或者外部服务。

通俗来说，NetworkPolicy对应名称空间中的网络防火墙。可以根据需求，在对应名称空间中创建NetworkPolicy资源，对名称空间中的pod实行流量管控。

2. NetworkPolicy工作原理

Pod 有两种隔离: 出口的隔离（Ingress）和入口的隔离（Egress）。

默认情况下，一个Pod的出口是非隔离的，即所有出口连接都是允许的。如果有任何的 NetworkPolicy选择该Pod并在其policyTypes中包含“Egress”，则该Pod是出口隔离的， 我们称这样的策略适用于该Pod的出口。当一个Pod的出口被隔离时，唯一允许的来自Pod 的连接是适用于出口的Pod的某个NetworkPolicy的egress列表所允许的连接。值得注意的是，这些egress列表的效果是相加的。

默认情况下，一个Pod对入口是非隔离的，即所有入站连接都是被允许的。如果有任何的NetworkPolicy选择该Pod并在其policyTypes中包含“Ingress”，则该Pod被隔离入口，我们称这种策略适用于该Pod的入口。当一个Pod的入口被隔离时，唯一允许进入该 Pod 的连接是来自该Pod节点的连接和适用于入口的Pod的某个NetworkPolicy的ingress列表所允许的连接。这些ingress列表的效果也是相加的。

网络策略是相加的，所以不会产生冲突。如果策略适用于Pod某一特定方向的流量， Pod 在对应方向所允许的连接是适用的网络策略所允许的集合。因此，评估的顺序不影响策略的结果。

要允许从源Pod到目的Pod的连接，源Pod的出口策略和目的Pod的入口策略都需要允许连接。 如果任何一方不允许连接，建立连接将会失败。

NetworkPolicy基础工作逻辑

3. NetworkPolicy示例

l spec：NetworkPolicy 中包含了在一个名称空间中定义特定网络策略所需的所有信息。

l podSelector：每个NetworkPolicy都包括一个podSelector，主要是对该策略所适用的Pod 进行选择。示例中的策略选择带有 “role=db” 标签的 Pod。如果 podSelector 为空，选择该名称空间下的所有Pod。

l policyTypes：每个 NetworkPolicy 都包含一个 policyTypes 列表，其中包含 Ingress 或 Egress 或两者兼具。policyTypes字段表示给定的策略是应用于进入所选Pod的入站流量还是来自所选Pod的出站流量，或两者兼有。如果 NetworkPolicy 未指定 policyTypes则默认情况下始终设置Ingress；如果NetworkPolicy有任何出口规则的话则设置Egress。

l ingress：每个NetworkPolicy可包含一个ingress 规则的白名单列表。每个规则都允许同时匹配from和ports部分的流量。示例策略中包含一条简单的规则： 它匹配某个特定端口，来自三个来源中的一个，第一个通过 ipBlock 指定，第二个通过名称空间Selector 指定，第三个通过 podSelector 指定。

l egress：每个 NetworkPolicy 可包含一个egress规则的白名单列表。每个规则都允许匹配to和port部分的流量。该示例策略包含一条规则，该规则将指定端口上的流量匹配到 10.0.0.0/24 中的任何目的地。

所以，该网络策略示例表示的含义如下:隔离default名称空间下role=db的 Pod，（Ingress 规则）允许以下 Pod 连接到default名称空间下的带有role=db标签的所有 Pod 的 6379 TCP 端口：default名称空间下带有role=frontend标签的所有Pod带有 “project=myproject” 标签的所有名称空间中的Pod IP地址范围为172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255 （即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16）（Egress 规则）允许 “default”名称空间中任何带有标签 “role=db” 的 Pod 到 CIDR 10.0.0.0/24下5978 TCP端口的连接。

4.NetworkPolicy默认策略

默认情况下，如果名称空间中不存在任何策略，则所有进出该名称空间中Pod的流量都被允许。以下示例可以更改该名称空间中的默认行为。

4.1默认拒绝所有入站流量

4.2允许所有入站流量

4.3默认拒绝所有出站流量

4.4允许所有出站流量https://zhuanlan.zhihu.com/p/582201890/edit#allow-all-egress-traffic

4.5默认拒绝所有入站和所有出站流量

5.NetworkPolicy应用

示例：使用NetworkPolicy限制Ingress服务发布。

一般来说，一个项目服务发布将域名根路径指向前端的应用，接口路径指向对应的网关或微服务。例如Kubernetes上运行的Spring Cloud项目，应用Zuul做为网关，前面是NodeJS。在这样的情况下，配置域名根路径指向NodeJS应用，配置/api路径指向Ingress里的Zuul。无论用什么方式发布应用，最后是由Ingress代理实现的，只开放自已的应用给Ingress，会起到一定的安全作用。现在，假定创立了一个Nginx服务做为前端，并配置NetworkPolicy，让仅有Ingress Controller能够访问应用。注意，以下应用内容，需要读者提前部署好ingress，本项目就不再单独讲解。

5.1：创建nginx deployment

首先创建一个ngixn的应用，用来进行访问。

Service内容

该svc指向nginx pod。

Ingress内容

创建ingress，后续用于域名访问。

5.2：进行测试

此时部署的nginx deployment可以被任意节点和pod进行访问

使用service地址访问，可以访问

使用ingress地址可以访问（域名访问地址需要进行解析至节点IP）

5.3：给ingress名称空间打标签

为了在网络策略放行来自ingress中的pod，需要给ingress空间打上标签，后续网络策略当中进行选择。

5.4：增加网络策略

只让ingress controller访问，并且让该名称空间内部的pod可以互访。

5.5：再次访问测试

使用svc已经无法访问。

通过ingress可以访问。

浏览器使用ingress域名地址也可以访问。

至此，我们完成了NetworkPolicy的应用。

本文作者丁运管：深信服云计算认证专家（SCCE-C），产业教育中心资深讲师，云计算认证架构师，曾就职于阿里云、宏福集团，担任高级运维工程师和云计算高级讲师；多次作为电信、移动等众多大型企业特聘讲师，提供课程培训和技术顾问；持有ACE、ACP、CKA等行业证书，致力于Docker、Kubernetes、OpenStack等前沿技术研究，具有丰富的云计算一线实战经验以及课程资源建设和交付经验。

感谢楼主分享，每日学习打卡

楼主的文章图文并茂，清晰易懂

感谢分享

感谢楼主分享，学习一下

感谢楼主分享，每日学习打卡

每天学习一点点，每天进步一点点

每日打卡学习，感谢分享，学习了！！！

感谢分享有助于工作和学习！

感谢分享，有助于工作和学习！