本篇已加入《.NET Core on K8S学习实践系列文章索引》，可以点击查看更多容器化技术相关系列文章。
一、Kubernetes网络模型
我们都知道Kubernetes作为容器编排引擎，它有一个强大又复杂的网络模型，也牵引出了Pod网络、Service网络、ClusterIP、NodePort、Ingress等多个概念。这里我们采用杨波老师（架构师杨波）模仿TCP/IP协议栈总结的一个K8S网络模型图来看看K8S的四个抽象层次，从而了解一下K8S的网络。本小节的文字主要引用自杨波老师关于K8S网络模型的文章及CloudMan的《每天5分钟玩转Kubernetes》一书。
K8S网络层次模型图 （From 波波老师）
根据上图模型中展示的四个层次，从0到3，除了第0层，每一层都是构建于前一层之上。
（1）第0层：节点主机互通互联
主要保证K8S节点(物理或虚拟机)之间能够正常IP寻址和互通的网络，这个一般由底层(公有云或数据中心)网络基础设施支持，这里我们无需过多关心。
（2）第1层：Pod虚拟机互联
在一个Pod中可以运行一个或多个容器，且Pod中所有容器使用同一个网络namespace，即相同的IP和端口空间，可以直接用localhost通信，而且还可以共享存储（本质是通过将Volume挂载到Pod中的每个容器）。
Pod网络模型图 （From 波波老师）
（3）第2层：服务发现和负载均衡
在K8S集群中，Pod的IP并不是固定的，可能会频繁地销毁和创建实例，为了解决此问题，Service提供了访问Pod的抽象层。即无论后端Pod如何变化，Service都作为稳定的前端对外提供服务。此外，Service还提供了高可用和负载均衡的功能，它负责将请求转发给正确的Pod。
Service网络模型图 （From 波波老师）
（4）第3层：外部流量接入
K8s的Service网络只是一个集群内部网络，集群外部是无法直接访问的。为此，想要将应用暴露出去让公网能够访问，K8S提供了两种方式：
① NodePort：使Service通过Cluster节点的静态端口对外提供服务，外部可以通过 NodeIP:NodePort 来访问Service。
Node Port方式示意图 （From 波波老师）
② LoadBalancer：使Service利用Cloud Provider提供的Load Balancer对外提供服务，Cloud Provider负责将Load Balancer的流量导向Service。目前支持的Cloud Provider包括AWS、Azure、阿里云、腾讯云等。
Load Balancer方式示意图 （From 波波老师）
More：关于K8S网络的更多基本原理与讲解，强力推荐阅读波波老师的以下文章：
- Kubernetes网络三部曲-Pod网络（From 杨波老师）
- Kubernetes网络三部曲-Service网络（From 杨波老师）
- Kubernetes网络三部曲-外部接入网络（From 杨波老师）
二、传说中的CNI规范
为了保证网络方案的标准化、扩展性和灵活性，K8S采用了CNI（Container Networking Interface）规范。CNI是一个Pod网络集成标准，简化了K8S和不同Pod网络实现技术的集成。CNI最大的优点就是支持多种容器runtime，而不仅仅是Docker。目前已经有多种支持K8S的网络方案，包括 Flannel、Calico、Canal等，它们都实现了CNI规范，因此无论我们选择哪种具体方案，它们的网络模型都是一致的。
CNI模型图
More：关于CNI的更多基本原理与讲解，推荐阅读陈Sir的文章《K8S网络详解：CNI与CNI网络模型》
三、Network Policy
3.1 关于Network Policy
Network Policy是K8S的一种资源，它使K8S可以通过Label选择Pod，并指定其他Pod或外界如何与这些Pod通信。换句话说，当Pod被定义了Network Policy时，只有Policy允许的流量才能访问Pod（默认情况下，任何来源的流量都可以访问Pod，是没有限制的）即帮助K8S实现更为精细的流量控制，实现租户隔离机制。
But，并不是所有K8S网络方案都支持Network Policy，比如Flannel就不支持，而Calico是支持的。
3.2 Network Policy实践
3.2.1 部署Canal
想要部署Canal，需要切换网络方案，这里我们使用最简单粗暴的方式：重建当前K8S集群
kubeadm reset # 在每个节点上执行一次
然后，重新对Master节点进行初始化：
kubeadm init --apiserver-advertise-address=192.168.2.100 --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.13.3 --service-cidr=10.1.0.0/16 --pod-network-cidr=10.244.0.0/16
在两个Node节点上执行以下命令重新加入集群：（注意这里的token请填写你的Master节点初始化后的输出结果）
kubeadm join 192.168.2.100:6443 --token ekqxk2.iiu5wx5bbnbdtxsw --discovery-token-ca-cert-hash sha256:c50bb83d04f64f4a714b745f04682b27768c1298f331e697419451f3550f2d05
最后，通过以下命令部署Canal：（参考自K8S官方文档）
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
此时，再次令验证的集群结果如下：
（1）集群节点状态
（2）Pod状态
3.2.2 部署测试应用
这里通过一个httpd应用来演示Network Policy，该应用的yaml定义如下：
apiVersion: apps/v1 kind: Deployment metadata: name: httpd spec: replicas: 3 selector: matchLabels: name: networkpolicy-demo template: metadata: labels: name: networkpolicy-demo spec: containers: - name: httpd image: httpd:latest ports: - containerPort: 80 imagePullPolicy: IfNotPresent --- kind: Service apiVersion: v1 metadata: name: httpd-svc spec: type: NodePort ports: - protocol: TCP nodePort: 31000 port: 8080 targetPort: 80 selector: name: networkpolicy-demo
通过kubectl将其部署到K8S集群：
kubectl apply -f httpd-demo.yaml
这时候三个httpd Pod已经成功Running：
由于定义的是NodePort方式暴露服务，这里我们在集群外部访问Service看看：
由于当前并没有创建任何Network Policy，这里我们可以通过创建一个Pod应用（我们熟悉的busybox）来验证一下是否可以在K8S集群内部随意访问该httpd应用：
kubectl run busybox --rm -it --image=busybox /bin/sh
从上图可以知道，它可以正常访问到Service，也可以正常ping到Pod节点。
3.2.3 测试Network Policy有效性
现在我们创建一个Network Policy，其配置文件yaml如下：
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-httpd spec: podSelector: matchLabels: name: networkpolicy-demo ingress: - from: - podSelector: matchLabels: access: "true" ports: - protocol: TCP port: 80
该Network Policy定义了如下规则：
（1）应用于所有 label 为 name : networkpolicy-demo 的Pod，这里即刚刚创建的三个httpd pod。
（2）ingress中定义了只有 label 为 access : "true" 的Pod才能访问应用。
（3）即使通过Policy也只能访问80端口
通过kubectl将其应用到K8S集群中：
kubectl apply -f networkpolicy.yaml
下面再次在busybox pod中验证Network Policy的有效性：
从上图中可以看到，已经无法再成功访问Service，也无法再ping通三个Pod节点。
这个时候，集群外也无法再通过NodePort访问到Service：
如果想要让测试Pod（busybox）能访问到应用了Network Policy的httpd应用，我们可以对busybox pod加一个label就可以：
kubectl run busybox --rm -it --image=busybox --labels="access=true" /bin/sh
运行后的验证结果如下，可以访问到Service，但Ping却被禁止：
但是，此时集群节点（k8s-master与两个node）与集群仍然无法访问到应用了Network Policy的httpd应用，如果想要让它们也访问到，则需要修改Network Policy做一个类似于开防火墙白名单的操作（注意下面的ipBlock配置）：
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-httpd spec: podSelector: matchLabels: name: networkpolicy-demo ingress: - from: - podSelector: matchLabels: access: "true" - ipBlock: cidr: 192.168.2.0/24 ports: - protocol: TCP port: 80
再次应用到K8S集群后，再来通过集群外部的访问者浏览器试试：
可以看到，已经可以正常访问啦！
四、小结
本文简单介绍了Kubernetes的4层网络模型、CNI 容器网络接口规范 以及 Network Policy，并通过改造K8S集群的网络配置从Flannel到Canal来验证Network Policy的有效性。对于Kubernetes的网络模型的原理与介绍，强烈推荐阅读杨波老师的《Kubernetes网络三部曲》，它的传送门位于下方的参考资料列表中。最后，希望能够对初学者的你有所帮助！
参考资料
（1）CloudMan，《每天5分钟玩转Kubernetes》
（2）李振良，《一天入门Kubernets教程》
（3）马哥（马永亮），《Kubernetes快速入门》
（4）Liang，《K8S CNI网络最强对比》
（5）杨波，《K8S网络三部曲》
（6）陈Sir，《K8S网络详解：CNI与CNI网络模型》