Kubernetes的网络模型和网络策略 1、Kubernetes网络模型和CNI插件 在Kubernetes中设计了一种网络模型，要求无论容器运行在集群中的哪个节点，所有容器都能通过一个扁平的网络平面进行通信，即在同一IP网络中。需要注意的是：在K8S集群中，IP地址分配是以Pod对象为单位，而非容器，同一Pod内的所有容器共享同一网络名称空间。
1.1、Docker网络模型 了解Docker的友友们都应该清楚，Docker容器的原生网络模型主要有3种：Bridge（桥接）、Host（主机）、none。
Bridge：借助虚拟网桥设备为容器建立网络连接。 Host：设置容器直接共享当前节点主机的网络名称空间。 none：多个容器共享同一个网络名称空间。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 ls local local local link /loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00link /ether 00:0c:29:69:a7:23 brd ff:ff:ff:ff:ff:fflink link /ether 02:42:29:09:8f:dd brd ff:ff:ff:ff:ff:fflink id STP enabled interfacesid STP enabled interfacesexec -it c760a1b6c98 bashlink /loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00link /ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
从上可以看到容器内有一个网卡eth0@if39，实际上eth0@if39和veth3f1b114是一对veth pair。veth pair是一种成对出现的特殊网络设备，可以想象它们由一根虚拟的网线进行连接的一对网卡，eth0@if39在容器中，veth3f1b114挂在网桥docker0上，最终的效果就是eth0@if39也挂在了docker0上。
桥接式网络是目前较为流行和默认的解决方案。但是这种方案的弊端是无法跨主机通信的，仅能在宿主机本地进行，而解决该问题的方法就是NAT。所有接入到该桥接设备上的容器都会被NAT隐藏，它们发往Docker主机外部的所有流量都会经过源地址转换后发出，并且默认是无法直接接受节点之外的其他主机发来的请求。当需要接入Docker主机外部流量，就需要进行目标地址转换甚至端口转换将其暴露在外部网络当中。如下图：
容器内的属于私有地址，需要在左侧的主机上的eth0上进行源地址转换，而右侧的地址需要被访问，就需要将eth0的地址进行NAT转换。SNAT—->DNAT
这样的通信方式会比较麻烦，从而需要借助第三方的网络插件实现这样的跨主机通信的网络策略。
1.2、Kubernetes网络模型 我们知道的是，在K8S上的网络通信包含以下几类：
容器间的通信：同一个Pod内的多个容器间的通信，它们之间通过lo网卡进行通信。
Pod之间的通信：通过Pod IP地址进行通信。
Pod和Service之间的通信：Pod IP地址和Service IP进行通信，两者并不属于同一网络，实现方式是通过IPVS或iptables规则转发。
Service和集群外部客户端的通信，实现方式：Ingress、NodePort、Loadbalance
K8S网络的实现不是集群内部自己实现，而是依赖于第三方网络插件—-CNI（Container Network Interface）
flannel、calico、canel等是目前比较流行的第三方网络插件。
这三种的网络插件需要实现Pod网络方案的方式通常有以下几种：
虚拟网桥、多路复用（MacVLAN）、硬件交换（SR-IOV）
无论是上面的哪种方式在容器当中实现，都需要大量的操作步骤，而K8S支持CNI插件进行编排网络，以实现Pod和集群网络管理功能的自动化。每次Pod被初始化或删除，kubelet都会调用默认的CNI插件去创建一个虚拟设备接口附加到相关的底层网络，为Pod去配置IP地址、路由信息并映射到Pod对象的网络名称空间。
在配置Pod网络时，kubelet会在默认的/etc/cni/net.d/目录中去查找CNI JSON配置文件，然后通过type属性到/opt/cni/bin中查找相关的插件二进制文件，如下面的”portmap”。然后CNI插件调用IPAM插件（IP地址管理插件）来配置每个接口的IP地址：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [root@k8s-master ~]# cat /etc/cni/net.d/10-flannel.conflist "name" : "cbr0" ,"plugins" : ["type" : "flannel" ,"delegate" : {"hairpinMode" : true ,"isDefaultGateway" : true "type" : "portmap" ,"capabilities" : {"portMappings" : true
CNI主要是定义容器网络模型规范，链接容器管理系统和网络插件，两者主要通过上面的JSON格式文件进行通信，实现容器的网络功能。CNI的主要核心是：在创建容器时，先创建好网络名称空间（netns），然后调用CNI插件为这个netns配置网络，最后在启动容器内的进程。
常见的CNI网络插件包含以下几种：
Flannel：为Kubernetes提供叠加网络的网络插件，基于TUN/TAP隧道技术，使用UDP封装IP报文进行创建叠 加网络，借助etcd维护网络的分配情况，缺点：无法支持网络策略访问控制。 Calico：基于BGP的三层网络插件，也支持网络策略进而实现网络的访问控制；它在每台主机上都运行一个虚拟路由，利用Linux内核转发网络数据包，并借助iptables实现防火墙功能。实际上Calico最后的实现就是将每台主机都变成了一台路由器，将各个网络进行连接起来，实现跨主机通信的功能。 Canal：由Flannel和Calico联合发布的一个统一网络插件，提供CNI网络插件，并支持网络策略实现。 其他的还包括Weave Net、Contiv、OpenContrail、Romana、NSX-T、kube-router等等。而Flannel和Calico是目前最流行的选择方案。 1.3、Flannel网络插件 在各节点上的Docker主机在docker0上默认使用同一个子网，不同节点的容器都有可能会获取到相同的地址，那么在跨节点通信时就会出现地址冲突的问题。并且在多个节点上的docker0使用不同的子网，也会因为没有准确的路由信息导致无法准确送达报文。
而为了解决这一问题，Flannel的解决办法是，预留一个使用网络，如10.244.0.0/16，然后自动为每个节点的Docker容器引擎分配一个子网，如10.244.1.0/24和10.244.2.0/24，并将分配信息保存在etcd持久存储。
第二个问题的解决，Flannel是采用不同类型的后端网络模型进行处理。其后端的类型有以下几种：
VxLAN：使用内核中的VxLAN模块进行封装报文。也是flannel推荐的方式，其报文格式如下：
host-gw：即Host GateWay，通过在节点上创建目标容器地址的路由直接完成报文转发，要求各节点必须在同一个2层网络，对报文转发性能要求较高的场景使用。 UDP：使用普通的UDP报文封装完成隧道转发。 1.4、VxLAN后端和direct routing VxLAN（Virtual extensible Local Area Network）虚拟可扩展局域网，采用MAC in UDP封装方式，具体的实现方式为：
1、将虚拟网络的数据帧添加到VxLAN首部，封装在物理网络的UDP报文中 2、以传统网络的通信方式传送该UDP报文 3、到达目的主机后，去掉物理网络报文的头部信息以及VxLAN首部，并交付给目的终端 跨节点的Pod之间的通信就是以上的一个过程，整个过程中通信双方对物理网络是没有感知的。如下网络图：
VxLAN的部署可以直接在官方上找到其YAML文件，如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [root@k8s-master:~# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
运行正常后，flanneld会在宿主机的/etc/cni/net.d目录下生成自已的配置文件，kubelet将会调用它。
网络插件运行成功后，Node状态才Ready。
1 2 3 4 5 [root@k8s-master ~]# kubectl get node
flannel运行后，在各Node宿主机多了一个网络接口：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 link >link >link >
从上面的结果可以知道 ：
flannel默认就是VXLAN模式，即Overlay Network。 flanneld创建了一个flannel.1接口，它是专门用来封装隧道协议的，默认分给集群的Pod网段为10.244.0.0/16。 flannel给k8s-master节点配置的Pod网络为10.244.0.0段，给k8s-node01节点配置的Pod网络为10.244.1.0段，给k8s-node01节点配置的Pod网络为10.244.2.0段，如果有更多的节点，以此类推。 举个实际例子
1 2 3 4 5 6 7 8 9
可以看到，3个Pod都分别运行在各个节点之上，其中master上的Pod的ip为：10.244.0.17，在master节点上查看网络接口可以发现在各个节点上多了一个虚拟接口cni0，其ip地址为10.244.0.1。它是由flanneld创建的一个虚拟网桥叫cni0，在Pod本地通信使用。 这里需要注意的是，cni0虚拟网桥，仅作用于本地通信！！！！
1 2 3 4 5 6 7 8 9 [root@k8s-master ~]# ifconfig cni0link >
flanneld为每个Pod创建一对veth虚拟设备，一端放在容器接口上，一端放在cni0桥上。 使用brctl查看该网桥：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 id STP enabled interfaces
在现有的Flannel VxLAN网络中，两台主机上的Pod间通信，也是正常的，如master节点上的Pod访问node01上的Pod：
1 2 3 4 5 6 7 8 9 10 11 [root@k8s-master ~]# kubectl exec -it nginx-5bd76bcc4f-pb257 -- /bin/bash
可以看到容器跨主机是可以正常通信的，那么容器的跨主机通信是如何实现的呢？？？？？master上查看路由表信息：
1 2 3 4 5 [root@k8s-master ~]# ip route
发送到10.244.1.0/24和10.244.20/24网段的数据报文发给本机的flannel.1接口，即进入二层隧道，然后对数据报文进行封装（封装VxLAN首部–>UDP首部–>IP首部–>以太网首部），到达目标Node节点后，由目标Node上的flannel.1进行解封装。使用tcpdump进行 抓一下包，如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 exec -it nginx-5bd76bcc4f-pb257 -- /bin/bashfor full protocol decodeecho request, id 29493, seq 1, length 64echo reply, id 29493, seq 1, length 64echo request, id 29493, seq 2, length 64echo reply, id 29493, seq 2, length 64echo request, id 837, seq 1, length 64echo reply, id 837, seq 1, length 64echo request, id 837, seq 2, length 64echo reply, id 837, seq 2, length 64echo request, id 837, seq 3, length 64echo reply, id 837, seq 3, length 64
VXLAN是Linux内核本身支持的一种网络虚拟化技术，是内核的一个模块，在内核态实现封装解封装，构建出覆盖网络，其实就是一个由各宿主机上的Flannel.1设备组成的虚拟二层网络。
由于VXLAN由于额外的封包解包，导致其性能较差，所以Flannel就有了host-gw模式，即把宿主机当作网关，除了本地路由之外没有额外开销，性能和calico差不多，由于没有叠加来实现报文转发，这样会导致路由表庞大。因为一个节点对应一个网络，也就对应一条路由条目。
host-gw虽然VXLAN网络性能要强很多。，但是种方式有个缺陷：要求各物理节点必须在同一个二层网络中。物理节点必须在同一网段中。这样会使得一个网段中的主机量会非常多，万一发一个广播报文就会产生干扰。在私有云场景下，宿主机不在同一网段是很常见的状态，所以就不能使用host-gw了。
VXLAN还有另外一种功能，VXLAN也支持类似host-gw的玩法，如果两个节点在同一网段时使用host-gw通信，如果不在同一网段中，即 当前pod所在节点与目标pod所在节点中间有路由器，就使用VXLAN这种方式，使用叠加网络。 结合了Host-gw和VXLAN，这就是VXLAN的Direct routing模式
Flannel VxLAN的Direct routing模式配置
修改kube-flannel.yml文件，将flannel的configmap对象改为：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [root@k8s-master ~]# vim kube-flannel.yml "Network" : "10.244.0.0/16" , "Backend" : {"Type" : "vxlan" ,"Directrouting" : true
从上面的结果可以看到，发往10.244.1.0/24和10.244.1.0/24的包都是直接经过eth0网络接口直接发出去的，这就是Directrouting。如果两个节点是跨网段的，则flannel自动降级为VxLAN模式。
此时，在各 个 集群节点上执行“iptables -nL”命令 可以 看到， iptables filter 表 的 FORWARD 链 上 由其 生成 了 如下 两条 转发 规则， 它 显 式 放行 了10. 244. 0. 0/ 16 网络 进出 的 所有 报文， 用于 确保 由 物理 接口 接收 或 发送 的 目标 地址 或 源 地址 为10. 244. 0. 0/ 16网络 的 所有 报文 均能 够 正常 通行。 这些 是 Direct Routing 模式 得以 实现 的 必要条件：
1 2 3 target prot opt source destination
再在此之前创建的Pod和宿主机上进行ping测试，可以看到在flannel.1接口上已经抓不到包了，在eth0上可以用抓到ICMP的包，如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [root@k8s-master ~]# tcpdump -i flannel.1 -nn host 10.244.1.146for full protocol decodefor full protocol decodeecho request, id 839, seq 1, length 64echo reply, id 839, seq 1, length 64echo request, id 839, seq 2, length 64echo reply, id 839, seq 2, length 64echo request, id 46141, seq 1, length 64echo reply, id 46141, seq 1, length 64echo request, id 46141, seq 2, length 64echo reply, id 46141, seq 2, length 64
1.5、Host-gw后端 Flannel除了上面2种数据传输的方式以外，还有一种是host-gw的方式，host-gw后端是通过添加必要的路由信息使用节点的二层网络直接发送Pod的通信报文。它的工作方式类似于Directrouting的功能，但是其并不具备VxLan的隧道转发能力。
编辑kube-flannel的配置清单，将ConfigMap资源kube-flannel-cfg的data字段中网络配置进行修改，如下：
1 2 3 4 5 6 7 8 9 10 11 12 [root@k8s-master ~]# vim kube-flannel.yml "Network" : "10.244.0.0/16" ,"Backend" : {"Type" : "host-gw"
配置完成后，各节点会生成类似directrouting一样的 路由和iptables规则，用于实现二层转发Pod网络的通信报文，省去了隧道转发模式的额外开销。但是存在的问题点是，对于不在同一个二层网络的报文转发，host-gw是无法实现的。延续上面的例子，进行抓包查看：
master上的Pod：10.244.0.17向node01节点上的Pod：10.244.1.146发送ICMP报文
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 for full protocol decodeecho request, id 59528, seq 1, length 64echo reply, id 59528, seq 1, length 64echo request, id 59528, seq 2, length 64echo reply, id 59528, seq 2, length 64
该模式下，报文转发的相关流程如下：
1、Pod（10.244.0.17）向Pod（10.244.1.146）发送报文，查看到报文中的目的地址为：10.244.1.146，并非本地网段，会直接发送到网关（192.168.56.11）；
2、网关发现该目标地址为10.244.1.146，要到达10.244.1.0/24网段，需要送达到node2 的物理网卡，node2接收以后发现该报文的目标地址属于本机上的另一个虚拟网卡，然后转发到相对应的Pod（10.244.1.146）
工作模式流程图如下：
以上就是Flannel网络模型的三种工作模式，但是flannel自身并不具备为Pod网络实现网络策略和网络通信隔离的功能，为此只能借助于Calico联合统一的项目Calnal项目进行构建网络策略的功能。
2、网络策略 网络策略（Network Policy ）是 Kubernetes 的一种资源。Network Policy 通过 Label 选择 Pod，并指定其他 Pod 或外界如何与这些 Pod 通信。
Pod的网络流量包含流入（Ingress）和流出（Egress）两种方向。默认情况下，所有 Pod 是非隔离的，即任何来源的网络流量都能够访问 Pod，没有任何限制。当为 Pod 定义了 Network Policy，只有 Policy 允许的流量才能访问 Pod。
Kubernetes的网络策略功能也是由第三方的网络插件实现的，因此，只有支持网络策略功能的网络插件才能进行配置网络策略，比如Calico、Canal、kube-router等等。
PS：Kubernetes自1.8版本才支持Egress网络策略，在该版本之前仅支持Ingress网络策略。
2.1、部署Canal提供网络策略功能 calico官网
Calico可以独立地为Kubernetes提供网络解决方案和网络策略，也可以和flannel相结合，由flannel提供网络解决方案，Calico仅用于提供网络策略，此时将Calico称为Canal。结合flannel工作时，Calico提供的默认配置清单式以flannel默认使用的10.244.0.0/16为Pod网络，因此在集群中kube-controller-manager启动时就需要通过–cluster-cidr选项进行设置使用该网络地址，并且—allocate-node-cidrs的值应设置为true。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Canal作为DaemonSet部署到每个节点，属于kube-system这个名称空间。需要注意的是，Canal只是直接使用了Calico和flannel项目，代码本身没有修改，Canal只是一种部署的模式，用于安装和配置项目。
2.2、配置网络策略 在Kubernetes系统中，报文的流入和流出的核心组件是Pod资源，它们也是网络策略功能的主要应用对象。NetworkPolicy对象通过podSelector选择 一组Pod资源作为控制对象。NetworkPolicy是定义在一组Pod资源之上用于管理入站流量，或出站流量的一组规则，有可以是出入站规则一起生效，规则的生效模式通常由spec.policyTypes进行 定义。如下图：
默认情况下，Pod对象的流量控制是为空的，报文可以自由出入。在附加网络策略之后，Pod对象会因为NetworkPolicy而被隔离，一旦名称空间中有任何NetworkPolicy对象匹配了某特定的Pod对象，则该Pod将拒绝NetworkPolicy规则中不允许的所有连接请求，但是那些未被匹配到的Pod对象依旧可以接受所有流量。
就特定的Pod集合来说，入站和出站流量默认是放行状态，除非有规则可以进行匹配。还有一点需要注意的是，在spec.policyTypes中指定了生效的规则类型，但是在networkpolicy.spec字段中嵌套定义了没有任何规则的Ingress或Egress时，则表示拒绝入站或出站的一切流量。定义网络策略的基本格式如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-myapp-ingress namespace: default spec: podSelector: matchLabels: app: myapp policyTypes ["Ingress" ] ingress: - from: - ipBlock: cidr: 10.244 .0 .0 /16 except: - 10.244 .3 .0 /24 - podSelector: matchLabels: app: myapp ports: - protocol: TCP port: 80 该网络策略就是将default名称空间中拥有标签"app=myapp"的Pod资源开放80/TCP端口给10.244.0.0/16网段，并排除10.244.3.0/24网段的访问，并且也开放给标签为app=myapp的所有Pod资源进行访问。
为了看出Network Policy的效果，先部署一个httpd的应用。配置清单文件如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [root@k8s-master ~ ]root@k8s-master ~ ]root@k8s-master network-policy-demo ]apiVersion: apps/v1beta1 kind: Deployment metadata: name: httpd spec: replicas: 3 template: metadata: labels: run: httpd spec: containers: - name: httpd image: httpd:latest imagePullPolicy: IfNotPresent ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: httpd-svc spec: type: NodePort selector: run: httpd ports: - protocol: TCP nodePort: 30000 port: 8080 targetPort: 80
创建三个副本，通过NodePort类型的Service对外方服务，部署应用：
1 2 3 4 5 6 7 8 9 10 11 [root@k8s-master network-policy-demo]# kubectl apply -f httpd.yaml
当前没有定义任何Network Policy，验证应用的访问：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 rm -it --image=busybox /bin/sh't see a command prompt, try pressing enter. / # wget httpd-svc:8080 Connecting to httpd-svc:8080 (10.99.222.179:8080) index.html 100% |*********************************************************************************************| 45 0:00:00 ETA / # ping -c 2 10.244.1.2 PING 10.244.1.2 (10.244.1.2): 56 data bytes 64 bytes from 10.244.1.2: seq=0 ttl=63 time=0.507 ms 64 bytes from 10.244.1.2: seq=1 ttl=63 time=0.228 ms --- 10.244.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.228/0.367/0.507 ms #集群节点也可以访问Sevice和ping通副本Pod [root@k8s-node01 ~]# curl 10.99.222.179:8080 <html><body><h1>It works!</h1></body></html> [root@k8s-node01 ~]# ping -c 2 10.244.2.2 PING 10.244.2.2 (10.244.2.2) 56(84) bytes of data. 64 bytes from 10.244.2.2: icmp_seq=1 ttl=63 time=0.931 ms 64 bytes from 10.244.2.2: icmp_seq=2 ttl=63 time=0.812 ms --- 10.244.2.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.812/0.871/0.931/0.066 ms #集群外部访问192.168.56.11:30000也是通的 [root@localhost ~]# curl 192.168.56.11:30000 <html><body><h1>It works!</h1></body></html>
那么下面再去设置不同的Network Policy来管控Pod的访问。
2.3、管控入站流量 NetworkPolicy资源属于名称空间级别，它的作用范围为其所属的名称空间。
1、设置默认的Ingress策略
用户可以创建一个NetworkPolicy来为名称空间设置一个默认的隔离策略，该策略选择所有的Pod对象，然后允许或拒绝任何到达这些Pod的入站流量，如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [root@k8s-master network-policy-demo]# vim policy-demo.yaml"Ingress" ] rm -it --image=busybox /bin/sh't see a command prompt, try pressing enter. / # wget httpd-svc:8080 Connecting to httpd-svc:8080 (10.99.222.179:8080) wget: can' t connect to remote host (10.99.222.179): Connection timed out
如果要将默认策略设置为允许所有入站流量，只需要定义Ingress字段，并将这个字段设置为空，以匹配所有源端点，但本身不设定网络策略，就已经是默认允许所有入站流量访问的，下面给出一个定义的格式：
1 2 3 4 5 6 7 8 9 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-ingress spec: podSelector: {}policyTypes: ["Ingress" ]ingress: - {}
实践中，通常将默认的网络策略设置为拒绝所有入站流量，然后再放行允许的源端点的入站流量。
2、放行特定的入站流量
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [root@k8s-master network-policy-demo ]apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-httpd spec: podSelector: matchLabels: run: httpd policyTypes: ["Ingress" ]ingress: - from: - ipBlock: cidr: 10.244 .0 .0 /16 except: - 10.244 .2 .0 /24 - 10.244 .1 .0 /24 - podSelector: matchLabels: access: "true" ports: - protocol: TCP port: 80 root@k8s-master network-policy-demo ]networkpolicy.networking.k8s.io/access-httpd created root@k8s-master network-policy-demo ]NAME POD-SELECTOR AGE access-httpd run=httpd 6s
验证NetworkPolicy的有效性：
1 2 3 4 5 6 7 8 9 10 11 rm -it --labels="access=true" --image=busybox /bin/sh't see a command prompt, try pressing enter. / # wget httpd-svc:8080 Connecting to httpd-svc:8080 (10.99.222.179:8080) index.html 100% |*********************************************************************************************| 45 0:00:00 ETA / # ping -c 3 10.244.0.2 PING 10.244.0.2 (10.244.0.2): 56 data bytes --- 10.244.0.2 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
2.4、管控出站流量 通常，出站的流量默认策略应该是允许通过的，但是当有精细化需求，仅放行那些有对外请求需要的Pod对象的出站流量，也可以先为名称空间设置“禁止所有”的默认策略，再细化制定准许的策略。networkpolicy.spec中嵌套的Egress字段用来定义出站流量规则。
1、设定默认Egress策略
和Igress一样，只需要通过policyTypes字段指明生效的Egress类型规则，然后不去定义Egress字段，就不会去匹配到任何目标端点，从而拒绝所有的出站流量。
1 2 3 4 5 6 7 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-egress spec: podSelector: {}policyTypes: ["Egress" ]
实践中，需要进行严格隔离的环境通常将默认的策略设置为拒绝所有出站流量，再去细化配置允许到达的目标端点的出站流量。
2、放行特定的出站流量
下面举个例子定义一个Egress规则，对标签run=httpd的Pod对象，到达标签为access=true的Pod对象的80端口的流量进行放行。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [root@k8s-master network-policy-demo ]apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: httpd-egress spec: podSelector: matchLabels: run: httpd policyTypes: ["Egress" ]egress: - to: - podSelector: matchLabels: access: "true" ports: - protocol: TCP port: 80 root@k8s-master ~ ]If you don't see a command prompt, try pressing enter. / Connecting to httpd-svc:8080 (10.99.222.179:8080) index.html 100 % |*********************************************************************************************| 45 0 :00:00 ETA / Session ended, resume using 'kubectl attach busybox-686cb649b6-6j4qx -c busybox -i -t' command when the pod is running deployment.apps "busybox" deleted root@k8s-master ~ ]If you don't see a command prompt, try pressing enter. / Connecting to httpd-svc:8080 (10.99.222.179:8080) wget: can't connect to remote host (10.99.222.179): Connection timed out
从上面的检测结果可以看到，带有标签access=true的Pod才能访问到httpd-svc，说明上面配置的Network Policy已经生效。
2.5、隔离名称空间 实践中，通常需要彼此隔离所有的名称空间，但是又需要允许它们可以和kube-system名称空间中的Pod资源进行流量交换，以实现监控和名称解析等各种管理功能。下面的配置清单示例在default名称空间定义相关规则，在出站和入站都默认均为拒绝的情况下，它用于放行名称空间内部的各Pod对象之间的通信，以及和kube-system名称空间内各Pod间的通信。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: namespace-deny-all namespace: default spec: policyTypes: ["Ingress" ,"Egress" ]podSelector: {}--- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: namespace-allow namespace: default spec: policyTypes: ["Ingress" ,"Egress" ]podSelector: {}ingress: - from: - namespaceSelector: matchExpressions: - key: name operator: In values: ["default" ,"kube-system" ]egress: - to: - namespaceSelector: matchExpressions: - key: name operator: In values: ["default" ,"kube-system" ]
需要注意的是，有一些额外的系统附件可能会单独部署到独有的名称空间中，比如将prometheus监控系统部署到prom名称空间等，这类具有管理功能的附件所在的名称空间和每一个特定的名称空间的出入流量也是需要被放行的。
