网络策略NetworkPolicy
网络策略
在 Kubernetes 里，网络隔离能力的定义，是依靠一种专门的 API 对象来描述的，即： NetworkPolicy。
Kubernetes 里的 Pod 默认都是“允许所有”（Accept All）的，即：Pod 可以接收来自任何发送方的请求；或者，向任何接收方发送请求。而如果要对这个情况作出限制，就必须通过 NetworkPolicy 对象来指定。
一个完整的NetworkPolicy对象示例如下所示：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
- ports:
- protocol: TCP
port: 80
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
与所有其他的 Kubernetes 资源对象一样，NetworkPolicy 需要 apiVersion、kind 和 metadata 字段，我们通过 spec.podSelector 字段定义这个 NetworkPolicy 的限制范围，因为 NetworkPolicy 目前只支持定义 ingress 规则，所以这里的 podSelector 本质上是为该策略定义 “目标pod”, 比如我们这里 matchLabels:role=db 表示的就是当前 Namespace 里携带了 role=db 标签的 Pod。而如果把 podSelector 字段留空：
spec:
podSelector: {}
那么这个 NetworkPolicy 就会作用于当前 Namespace 下的所有 Pod。
每个 NetworkPolicy 包含一个 policyTypes 列表，可以是 Ingress、Egress 或者两者都包含，该字段表示给当前策略是否应用于所匹配的 Pod 的入口流量、出口流量或者二者都包含，如果没有指定 policyTypes，则默认情况下表示 Ingress 入口流量，如果配置了任何出口流量规则，则将指定为 Egress。
一旦 Pod 被 NetworkPolicy 选中，那么这个 Pod 就会进入“拒绝所有”（Deny All）的状态，即：这个 Pod 既不允许被外界访问，也不允许对外界发起访问。
比如上面示例表示的是该隔离规则只对 default 命名空间下的，携带了 role=db 标签的 Pod 有效。限制的请求类型包括 ingress（流入）和 egress（流出）。
ingress: 每个 NetworkPolicy 包含一个 ingress 规则的白名单列表。其中的规则允许同时匹配 from 和 ports 部分的流量。比如上面示例中我们配置的入口流量规则如下所示：
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
- ports:
- protocol: TCP
port: 80
这里的 ingress 规则中我们定义了 from 和 ports，表示允许流入的白名单和端口，Kubernetes 会拒绝任何访问被隔离 Pod 的请求，除非这个请求来自于以下“白名单”里的对象，并且访问的是被隔离 Pod 的端口。而这个允许流入的白名单中指定了三种并列的情况，分别是：ipBlock、namespaceSelector 和 podSelector：
- default 命名空间下面带有
role=frontend标签的 Pod - 带有
project=myproject标签的 Namespace 下的任何 Pod - 任何源地址属于
172.17.0.0/16网段，且不属于172.17.1.0/24网段的请求。
egress: 每个 NetworkPolicy 包含一个 egress 规则的白名单列表。每个规则都允许匹配 to 和 port 部分的流量。比如我们这里示例规则的配置：
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
表示 Kubernetes 会拒绝被隔离 Pod 对外发起任何请求，除非请求的目的地址属于 10.0.0.0/24 网段，并且访问的是该网段地址的 5978 端口。
安装Calico
要让网络策略生效，就需要特定的网络插件支持，目前已经实现了 NetworkPolicy 的网络插件包括 Calico、Weave 和 kube-router 等项目，但是并不包括 Flannel 项目。
所以说，如果想要在使用 Flannel 的同时还使用 NetworkPolicy 的话，就需要再额外安装一个网络插件，比如 Calico 项目，来负责执行 NetworkPolicy。由于我们这里使用的是 Flannel 网络插件，所以首先需要安装 Calico 来负责网络策略。
详细可以参考官方文档：https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel
首先确定 kube-controller-manager 配置了如下的两个参数：
......
spec:
containers:
- command:
- kube-controller-manager
- --allocate-node-cidrs=true
- --cluster-cidr=10.244.0.0/16
......
下载需要使用的资源清单文件：
$ curl https://docs.projectcalico.org/manifests/canal.yaml -O
如果之前配置的 pod CIDR 就是 10.244.0.0/16 网段，则可以跳过下面的配置，如果不同则可以使用如下方式进行替换：
$ POD_CIDR="<your-pod-cidr>" \
$ sed -i -e "s?10.244.0.0/16?$POD_CIDR?g" canal.yaml
最后直接安装：
$ kubectl apply -f canal.yaml
测试
首先我们准备两个待测试的Pod:
apiVersion: v1
kind: Pod
metadata:
name: test-np
spec:
containers:
- name: test-np
image: nginx:1.17.1
---
apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","sleep 86400"]
直接创建这两个pod:
$ kubectl apply -f test-np.yaml
pod/test-np unchanged
pod/busybox configured
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED ...
busybox 1/1 Running 0 3m38s 10.244.2.3 node1 <none> ...
test-np 1/1 Running 0 3m38s 10.244.1.6 node2 <none> ...
我们使用busybox来访问test-np,在没有加任何网路策略的情况下，测试是否能正常请求：
$ kubectl exec -it busybox ping 10.244.1.6
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
PING 10.244.1.6 (10.244.1.6): 56 data bytes
64 bytes from 10.244.1.6: seq=0 ttl=62 time=0.642 ms
64 bytes from 10.244.1.6: seq=1 ttl=62 time=0.536 ms
64 bytes from 10.244.1.6: seq=2 ttl=62 time=0.981 ms
......
这时候我们添加上面的网络策略，同时给test-np打上role=db的标签：
$ kubectl label pod test-np role=db --overwrite
pod/test-np labeled
$ kubectl get networkpolicy
kubectl get networkpolicy
NAME POD-SELECTOR AGE
test-network-policy role=db 10s
这时候test-np这个Pod就匹配了网络策略，由于匹配了网络策略的就会拒绝所有的网络请求，需要通过白名单来进行开启请求，但是busybox这个Pod 明显没有在白名单之中，所以应该会拒绝网络请求：
kubectl exec -it busybox ping 10.244.1.6
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
PING 10.244.1.6 (10.244.1.6): 56 data bytes
^C
--- 10.244.1.6 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss
command terminated with exit code 1
那么现在我想让busybox能正常请求test-np这个pod，我们来看test-np绑定的网路策略中的白名单，第一条我们明显不符合要求，第二条将busybox转移标签 project=myproject 的 Namespace 下面，这个实现也不是特别容器，接着我们来看第三条，带有role=frontend这个标签的Pod就可以访问，那么我们就可以直接给我busybox打上这个标签：
$ kubectl label pod busybox role=frontend --overwrite
pod/busybox labeled
接着我们继续请求test-np，这次应该可以成功：
kubectl exec -it busybox ping 10.244.1.6
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
PING 10.244.1.6 (10.244.1.6): 56 data bytes
64 bytes from 10.244.1.6: seq=0 ttl=62 time=0.519 ms
64 bytes from 10.244.1.6: seq=1 ttl=62 time=0.761 ms
64 bytes from 10.244.1.6: seq=2 ttl=62 time=1.682 ms
64 bytes from 10.244.1.6: seq=3 ttl=62 time=0.432 ms
......
