|NO.Z.00411|——————————|CloudNative|——|KuberNetes&NetworkPolicy.V03|——|NetworkPolicy.v03|注意事项.v01|

一、k8s命名空间隔离性

### --- k8s命名空间的隔离性

~~~     在k8s应用上部署应用的时候；根据不同的项目组，应用，应用类型部门来划分不同的namespace
~~~     项目组A创建namespace.A；项目组B创建namespace.B
~~~     这样项目组在各自的namespace下部署不同的deployment、daemonset、service、ingress
~~~     pod的名称是可以和另外一个命名空间下pod的名称是可以相同的

### --- service跨namespace访问方式

~~~     假设在namespace.A的一个pod下去请求namespace.B的一个service
~~~     直接请求http://servicecs是不能访问到namespace.B下的ServiceC的
~~~     若是namespace.A下是有ServiceC，可以去访问；若是没有，不能访问其它namespace下ServiceC服务
~~~     但是在http://servicec加上.namespaceb就可以访问到其它namespace下的service：http://servicec.namespaceb/x
~~~     kubernetes的namespace隔离性并不是强制性隔离的
~~~     kubernetes的namespace相当于是软隔离；只要后面加上.namespace名称就可以跨namespace访问
~~~     所以说这种形式是非常不安全的

二、k8s.pod之间无隔离性

### --- k8s pod之间无隔离性概述：# 引入NetworkPolicy机制的必要性

~~~     若是知道其它namespace下的任意一个pod的IP地址，
~~~     就可以在任意namespace下的任意的pod都能访问到其它任意namespace下的任意这个pod

~~~     # 假设namespace.A下pod-A：10.244.0.1；登录到10.244.0.1这个pod；
~~~     可以ping通Namespace.B下pod-B:10.144.1.5；
~~~     也可以ping通Namespace.C下pod-x：10.248.0.100；
~~~     都是可以ping通的，只要是k8s集群中的pod；都是可以通的；这样就是一种非常不安全的策略
~~~     假设namespace.A下pod-A:10.244.0.1被攻击了；
~~~     黑客登录到namespace.A下pod-A:10.244.0.1；就可以通过某种手段扫描整个集群的IP地址；
~~~     就可以对k8s集群内部进行攻击；这样就是非常不安全

~~~     # 在传统模式下可以通过iptables机制进行控制
~~~     但是在k8s下通过这些策略是达不到这个要求的；因为k8s下pod是有非常高的弹性机制的；
~~~     pod进行发版或者扩容；后面的副本就会变的非常多；IP地址也会发生一系列的变化
~~~     那么在k8s下怎样实现网络上的隔离？

~~~     # 基于以上的情况：k8s就出现了NetworkPolicy的概念机制
~~~     可以利用CNI网络插件；进行网络之间的访问控制 
~~~     比如calico；view都是支持这种网络策略的；flannel是不支持的

三、k8s网络策略：k8s网络策略架构

### --- 使用网络策略需要达到一种什么样的目的

~~~     假设这个pod默认情况下是在一种非隔离的状态；可以访问到集群中所有命名空间下的任何一个pod
~~~     而且service也是可以跨namespace访问
~~~     基于这种情况；可以依据网络策略做一些访问控制

### --- 网络策略架构说明

~~~     # 假设：ingress-nginx ingress controller是一个k8s集群；
~~~     project-A是一个namespace
~~~     project-B是一个namespace
~~~     project-C是一个namespace

### --- NetworkPolicy需求一：需要实现的逻辑

~~~     假设project-A是一个项目：这个项目有前端：Frontend；后端：Backend；
~~~     数据库：MySQL，redis
~~~     实现的逻辑：假设project-A下的数据库：MySQL，redis只能被project下的backend访问；
~~~     也不希望project-A下的所有服务被其它namespace服务访问；跨namespace访问直接拒绝掉
~~~     就可以通过网络策略实现这种逻辑

### --- NetworkPolicy需求二：发布对外访问流量

~~~     需要通过ingress代理进来
~~~     假设project-A下的前端Frontend只能被ingress controller去访问；不能被其它的任何pod访问

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

——W.S.Landor