云原生之Kubernetes：21、Network-Policy详解
文章目录
- 前言
- 1、Network-Policy概述
- 2、Network-Policy策略
- 3、基于Flannel网络叠加Calico策略
- 4、实战：Calico网络策略
前言
网络策略是关于如何定义Pod组与彼此间，以及其他网络端点进行通信的规范。
NetworkPolicy资源使用标签选择pod并且定义网络流量策略。
1、Network-Policy概述
默认情况下，pod资源是非隔离性的，它可以接收任何来源的流量。
这其实不是我们生产环境所期望的，因为它不够安全！
此时就诞生了Network-Policy，如果做个比喻，我觉得它更像是云上的安全组的概念。
用于实现：
- 1、多租户的隔离（名称空间级别、Pod级别）
- 2、K8S集群概念的安全组
Network-Policy的策略不仅仅于此，还有更高级功能：如流量镜像、流量分割等。
我们使用kubeadm初始化学习环境的时候，使用的是flannel网络插件。
在上一节的学习中，我是这样描述的：
flannel是一个非常简单的覆盖网络，可以满足Kubernetes的基本要求
flannel本身并不支持Network Policy，需要使用calico、envoy、istio等service mesh服务网格插件进行赋能。
最后，我来聊一聊Network Policy的作用：
- Network Policy的作用对象是Pod，也可以应用到Namespace和集群的入和出的流量；
- Network Policy是作用在L3/4层的，即限制的是对IP地址和端口的访问；
- 如果需要对应用层做访问限制需要使用如Istio这类Service Mesh服务网格。
2、Network-Policy策略
如图所示，Network-Policy细分为Ingress和egress两种，其中：
Ingress（类似安全组的内外网入）：
定义能接收哪些客户端的访问（-from，ports：需要指明自己端口）
egress（类似安全组的内外网出）：
定义能访问哪些目标（-to，ports：目标端口）
备注：当对应区域有多条规则时，满足其一即可
3、基于Flannel网络叠加Calico策略
我们初始化集群时候使用的是flannel，他本身并不具有网络策略的功能，所以我这里将演示：
如何基于已有的flannel网络，将calico的网络策略的能力进行赋能。
1、因为我们初始化集群配置flannel的时候用的是10.244.0.0/16，所以不需要额外调整calico的配置文件，直接下载下来，apply即可
curl https://docs.projectcalico.org/v3.10/manifests/canal.yaml -O
kubectl apply -f canal.yaml
更多calico介绍，可参阅Calico官方文档。
2、等相关pod运行成功之后，我们就可以编辑网络策略进行测试
[root@centos-1 dingqishi]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
canal-5jp8z 2/2 Running 0 22m
canal-85l9r 2/2 Running 0 22m
canal-mgfzd 2/2 Running 0 22m
4、实战：Calico网络策略
1、实战开始之前，你可以通过kubectl explain netpol帮助命令，了解并获得相关配置
[root@centos-1 dingqishi]# kubectl explain netpol
KIND: NetworkPolicy
VERSION: networking.k8s.io/v1
2、首先，我们先创建两个namespace，用于运行pod，其中dev的名称空间运行服务端，prod的名称空间中运行客户端进行模拟测试
#创建namespace
[root@centos-1 dingqishi]# kubectl create ns dev
namespace/dev created
[root@centos-1 dingqishi]# kubectl create ns prod
namespace/prod created
#部署服务端pod
[root@centos-1 dingqishi]# kubectl create deployment myapp --image=registry.cn-hangzhou.aliyuncs.com/aaron89/myapp:v1 -n dev
deployment.apps/myapp created
#部署客户端pod.yaml，其运行在prod的名称空间
kubectl apply -f pod.yaml -n prod
3、观察pod情况，并进客户端的交互式接口进行测试，发现pod通信是成功的。
我上面说过：默认情况下，pod资源是非隔离性的，它可以接收任何来源的流量。
[root@centos-1 dingqishi]# kubectl get pod -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-5c6976696c-fhn9q 1/1 Running 0 4m31s 10.244.2.2 centos-3.shared <none> <none>
[root@centos-1 dingqishi]# kubectl get pod -n prod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
client-pod 1/1 Running 0 31s 10.244.2.3 centos-3.shared <none> <none>
#测试
[root@centos-1 dingqishi]# kubectl exec -it client-pod -n prod -- /bin/sh
/ # ping 10.244.2.2
PING 10.244.2.2 (10.244.2.2): 56 data bytes
64 bytes from 10.244.2.2: seq=0 ttl=63 time=0.265 ms
64 bytes from 10.244.2.2: seq=1 ttl=63 time=0.137 ms
4、这时候，我们编辑deny-all-ingress.yaml（拒绝所有入站流量，且dev内pod不能相互通信）,并apply
apiVersion: networking.k8s.io/v1 #dev名称空间下的所有pod，不允许相互访问也不允许被外部访问
kind: NetworkPolicy
metadata:
name: deny-all-ingress
namespace: dev
spec:
podSelector: {} #没指定 就是该名称空间下所有的Pod
# ingress: #补充:注释的这两行表示放行所有入站流量
# - {}
policyTypes:
- Ingress #只控制入站流量，没具体定义，就表示一个都不放行
5、查看对应的netpol生成情况
[root@centos-1 dingqishi]# kubectl get netpol -n dev
NAME POD-SELECTOR AGE
deny-all-ingress <none> 6s
[root@centos-1 dingqishi]# kubectl describe netpol -n dev
Name: deny-all-ingress
Namespace: dev
Created on: 2019-12-11 14:04:23 +0800 CST
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"networking.k8s.io/v1","kind":"NetworkPolicy","metadata":{"annotations":{},"name":"deny-all-ingress","namespace":"dev"},"spe...
Spec:
PodSelector: <none> (Allowing the specific traffic to all pods in this namespace)
Allowing ingress traffic:
<none> (Selected pods are isolated for ingress connectivity)
Allowing egress traffic:
<none> (Selected pods are isolated for egress connectivity)
Policy Types: Ingress
6、返回我们之前的交互式接口，测试发现，现在已经访问不到dev名称空间下面的资源了，和预期隔离配置一致
（同理：dev内的pod也不能相互访问）
/ # wget -o - -q 10.244.2.2
/ # ping 10.244.2.2
PING 10.244.2.2 (10.244.2.2): 56 data bytes
7、接下来我们需要开放ingress规则，使得他们能够访问,首先给prod的名称空间打标签，以便network policy能够用选择器选中
[root@centos-1 dingqishi]# kubectl label ns prod name=prod
namespace/prod labeled
[root@centos-1 dingqishi]# kubectl get ns --show-labels
NAME STATUS AGE LABELS
default Active 15d <none>
dev Active 23m <none>
ingress-nginx Active 5d23h app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx
kube-node-lease Active 15d <none>
kube-public Active 15d <none>
kube-system Active 15d <none>
kubernetes-dashboard Active 25h <none>
prod Active 19m name=prod
8、新增dev-allow-prod-ingress配置文件，并apply
apiVersion: networking.k8s.io/v1 #dev名称空间下的所有pod，不允许相互访问也不允许被外部访问
kind: NetworkPolicy
metadata:
name: dev-allow-prod-ingress
namespace: dev
spec:
podSelector: {} #没指定 就是该名称空间下所有的Pod
ingress:
- from:
- namespceSelector:
matchLabels:
name: prod #指定prod名称空间下的pod可以进行访问
policyTypes:
- Ingress #只控制入站流量，没具体定义，就表示一个都不放行
9、观察配置是否生效
[root@centos-1 dingqishi]# kubectl describe netpol dev-allow-prod-ingress -n dev
Name: dev-allow-prod-ingress
Namespace: dev
Created on: 2019-12-11 14:58:06 +0800 CST
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"networking.k8s.io/v1","kind":"NetworkPolicy","metadata":{"annotations":{},"name":"dev-allow-prod-ingress","namespace":"dev"...
Spec:
PodSelector: <none> (Allowing the specific traffic to all pods in this namespace)
Allowing ingress traffic:
To Port: <any> (traffic allowed to all ports)
From:
NamespaceSelector: name=prod
Allowing egress traffic:
<none> (Selected pods are isolated for egress connectivity)
Policy Types: Ingress
10、继续进行测试，发现此时已可以访问dev下的pod资源。
[root@centos-1 dingqishi]# kubectl exec -it client-pod -n prod -- /bin/sh
/ # ping 10.244.2.2
PING 10.244.2.2 (10.244.2.2): 56 data bytes
64 bytes from 10.244.2.2: seq=0 ttl=63 time=0.166 ms
64 bytes from 10.244.2.2: seq=1 ttl=63 time=0.091 ms
上面实战，我们已经充分了解了：
1、基于flannel底层网络的calico网络策略的赋能作用
2、Network-Policy中ingress和egress的实际配置效果