1.k8s如何实现网络通信？

k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等。
CNI插件存放位置：# cat /etc/cni/net.d/10-flannel.conflist
插件使用的解决方案如下：
虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。

容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现；

pod之间的通信：
同一节点的pod之间通过cni网桥转发数据包。
不同节点的pod之间的通信需要网络插件支持。

pod和service通信: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换。

pod和外网通信：iptables的MASQUERADE。

Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）

2、Flannel vxlan模式

Flannel vxlan模式跨主机通信原理：
Flannel的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。但是随着容器数量的增加，虚拟ip不够用。
VXLAN，即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一种网络虚拟化技术，主要是要解决ip不够分的问题。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（Overlay Network）。

VTEP：VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中 VNI的默认值是1，所以宿主机的VTEP设备都叫flannel.1。

Cni0: 网桥设备，每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）。

Flannel.1: TUN设备(虚拟网卡)，用来进行 vxlan 报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。

Flanneld：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。
vxlan的运行模式图如下

当容器发送IP包，通过veth pair 发往cni网桥，再路由到本机的flannel.1设备进行处理。
VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。
内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。
Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。
flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的。
linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取。
此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器。

3、flannel模式类型

flannel支持多种后端：
1、Vxlan，报文封装，默认使用vxlan
2、host-gw，主机网关，性能好，但只能在二层网络中，不支持跨网络，如果有成千上万的Pod，容易产生广播风暴
3、UDP，性能差，不推荐

默认是vxlan模式，查看下图，server3在自己节点访问就是通过cni0，当访问server2和server4时使用flannel.1。

kubectl -n kube-system edit cm kube-flannel-cfg进入kube-flannel-cfg进行配置更改
由于我们这里都是在同一个网段中，不用跨网段，所以这里改为host-gw模式。

删除flannel的相关pod，控制器会自动补上，达到更新配置的效果。

再次查看，使用的都是eth0

两个节点在一个网段，跳过Vxlan直接到eth0，性能更好。

4、calico

由于flannel组件只可以实现网络的通信，无法写入策略，无法实现对服务、对pod的控制（黑名单白名单pod之间的隔离等等），所以我们把网络组件替换为calico，不仅支持网络的通信，还支持策略的写入

calico简介：

flannel实现的是网络通信，calico的特性是在pod之间的隔离。
通过BGP路由，但大规模端点的拓扑计算和收敛往往需要一定的时间和计算资源。
纯三层的转发，中间没有任何的NAT和overlay，转发效率最好。
Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。

Felix：监听ECTD中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。

BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里来。

5、calico安装与部署

官网：

https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises

（1）删除flannel组件

删除刚开始安装k8s时安装的flannel组件，使用kube-flannel.yml文件删除，查看确实没有flannel组件了。

在CNI插件存放的目录中，把原来的flannel组件的遗留东西移走或者删除，避免影响calico网络组件的使用

server3和sever4都要移除,删除多余的服务，保持纯净环境.

（2）镜像与文件

创建calico的仓库项目

导入镜像

上传镜像

上传成功,创建calico目录，拉取calico.yaml文件

编辑calico.yaml文件

 name: CALICO_IPV4POOL_IPIP
              value: "off"
# kubectl apply -f calico.yaml

查看发现多了四个组件

查看网关，把10.244.1网段直接和server3的ip（172.25.11.3）连接起来，把10.244.2网段直接和server3的ip（172.25.11.3）连接起来。

6、calico网络策略

正常情况下，我们不做任何限制，服务不限制，pod不限制，namespace 不限制，外网访问不限制。

查看pod信息

编辑之前的svc.yaml文件，设置类型为LoadBalancer

已有标签是myapp的后端

物理机充当外部集群主机访问172.25.10.11成功，并且满足负载均衡

（1）、限制访问指定服务

创建deny-nginx文件，然后编辑

编辑lb-svc.yaml文件

apiVersion: v1
kind: Service
metadata:
  name: lb-svc
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
  selector:
    app: myapp          ## 给标签是myapp的pod创建服务
  type: LoadBalancer

无法访问

（2）、允许指定pod访问服务

直接限制整个服务无法访问，影响有过于大了。我们想允许特定的pod可以访问该服务，其他pod都不可以访问

编辑deng-nginx.yaml文件，在上一个的基础上，再添加一条策略。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-nginx
spec:
  podSelector:
    matchLabels:
      app: myapp
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: test       ##允许标签为test的pod访问
~                                 

应用该策略，可以看到生效了两条策略。连接test这个pod，curl访问成功。

（3）、禁止 一个namespace 中所有 Pod 之间的相互访问

首先删除前面的策略，以免影响，默认同一个ns中，pod是可以相互访问的.
现在我想设定为不可互相访问。编辑ns.yml文件

[root@server2 calico]# vim ns.yaml
[root@server2 calico]# cat ns.yaml 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default      ### 控制default这个namespace     
spec:
  podSelector: {}
[root@server2 calico]# 

应用该策略，查看到一条策略已生效。现在进入test，curl访问失败

（4）、禁止其他 namespace 访问服务

kubectl create namespace test创建一个新的ns叫test。
删除之前的策略，在test这个ns中创建一个叫test1的pod运行，可以看到不控制时，两个不同的ns之间的pod也是可以访问的。

编辑ns.yaml文件

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-namespace
spec:
  podSelector:
    matchLabels:     ##匹配的标签没有写，就是都满足
  ingress:
  - from:
    - podSelector: {}                 ### 其他namespace都无法访问

应用策略，进入test这个ns中的一个叫test1的pod，curl访问失败。

（5）、只允许指定namespace访问服务

其他namespace都无法访问，范围太大，我们还想让某些特殊的namespace可以访问
修改ns.yaml文件

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-namespace
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - podSelector: {}
---             
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-namespace
spec:
  podSelector:
    matchLabels:
      app: myapp   ## 匹配到标签是myapp的pod时，允许访问服务
  ingress:
  - from:
    - namespaceSelector:   ### namespaceSelector 满足选择
        matchLabels:
          role: prod       ### 匹配到角色是prod的ns时，允许访问服务

注意要给test这个ns添加prod角色,可以访问

（6）、允许外网访问服务

默认情况下是不允许外网访问服务的，
在上面的基础上，再次添加策略，修改ns.yaml文件
添加:

---            
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-external
spec:
  podSelector:
    matchLabels:
      app: myapp    # 允许标签是myapp的pod通过外网访问服务
  ingress:
  - ports:
    - port: 80   ## 端口是80
    from: []   ##访问来源不限制

外网可以访问，并且满足负载均衡。