一.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）

二、Flannel网络

1.flannel组件

VXLAN
即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。
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等网络数据信息。

原理图：

当容器发送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网桥，最后到达目标容器。

2.vxlan模式

Directrouting直连路由模式，适用于同网段通信。表现为host-gw，主机网关，性能好，但只能在二层网络中，不支持跨网。

查看server3的网关，Flannel .1的模式
route -n

查看arp

arp -an

3.host-gw模式

因为在一个电脑上的虚拟机做实验，所以用host-gw直连模式就可以了！
修改kube-flannel配置文件，将type改为直连模式

kubectl -n kube-system get cm
cd
kubectl -n kube-system edit cm kube-flannel-cfg

type: host-gw

我们查看pod信息的时候，flannel模式还在！

kubectl -n kube-system get pod

是因为没有更新pod节点：
那么就更新它！并查看pod节点信息

kubectl get pod -n kube-system |grep kube-flannel | awk '{system("kubectl delete pod "$1" -n kube-system")}'

kubectl get pod -o wide

此时在server3上查看网关，发现方式变为了eth0

在server4上查看网关，也是一样发变为了eth0

三.calico网络插件

1.calico简介：

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

2.calico组件安装

安装caloco替换原先的flannel

建立一个目录calico用来存放它的文件

cd
mkdir calico
cd calico/

wget https://docs.projectcalico.org/manifests/calico.yaml

在私有仓库建立新的项目calico

然后将calico-v3.19.1.tar拉取下来上传私有仓库！
因为本人本地有不需要拉取！

上传仓库！

上传成功！

将calico.yaml资源清单的镜像版本改对：

image:calico/cni:v3.19.1

3833,3547,3574,3615行都需要改！

将隧道模式关闭

IPIP
vaule: "off"

删除之前的网络插件flannel

kubectl delete -f kube-flannel.yml

将所有k8s节点的网络插件配置缓存文件移走！
server2.3.4都需要移走！

cd /etc/cni/net.d/
ls
mv 10-flannel.conflist /mnt/

执行calico.yaml清单，完成初始化！

kubectl apply -f calico.yaml

查看节点，可以看到正在初始化：
等一会就会完成！

kubectl get pod -n kube-system

查看网关，和svc信息

kubectl -n kube-system svc
route -n

将之前实验的svc删除

重新运行一个svc,并访问IP！！

kubectl apply -f lb-svc.yaml
kubectl get svc
curl 10.98.183.249

四.calico网络策略

1.限制访问指定服务

vim deny-nginx.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-nginx
spec:
  podSelector:
    matchLabels:
      app: myapp

查看标签：

运行 deny-nginx.yaml清单，查看状态

kubectl apply -f  deny-nginx.yaml
kubectl get networkpolicies.

访问IP

kubectl get svc
curl 10.98.183.249

完成之后，删除svc节点

修改svc清单内容再次执行：

cd /root/metallb

vim lb-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: lb-svc
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
  selector:
    app: myapp
  type: LoadBalancer

kubectl apply -f lb-svc.yaml
kubectl get svc

访问生成的IP

cd
kubectl run demo --image=busyboxplus -it --restart=Never
curl 10.107.242.186

2.允许指定pod访问服务：

deny-nginx.yaml文件下面继续添加!

vim deny-nginx.yaml

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  -  from:
     -  podSelector:
          matchLabels:
            run: test

执行清单，查看信息，发现多了一条允许的策略！

kubectl apply -f deny-nginx.yaml
kubectl get networkpolicies.

运行一个容器test，使用镜像busyboxplus，标签名为test

kubectl run test --image=busyboxplus -it --labels app=test

查看ip，访问：

发现失败了，是因为标签的名字没有对应一致，更改标签名：

kubectl get pod --show-labels
kubectl label pod test run=test

再次进入容器test，访问IP发现成功了！

kubectl attach test -it
ip addr
curl 10.244.22.2

实验完成之后，将deny-nginx.yaml节点删掉!!

3.禁止 namespace 中所有 Pod 之间的相互访问

vim ns.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}

执行ns.yaml清单并查看状态：

kubectl apply -f ns.yaml
kubectl get networkpolicies.

查看详细信息：

kubectl describe networkpolicies.

查看节点的IP地址：

kubectl get pod -o wide

测试：发现内外都不能访问了！！

curl 10.244.22.3
kubectl attach test -it
curl 10.244.22.3

重新创建一个namespace

kubectl create namespace test
kubectl get ns

运行容器查看IP，并访问：

kubectl run test --image=busyboxplus -it -n test
ip addr
curl *****

4.只允许指定namespace访问服务：

在ns.yaml后面添加

vim ns.yaml

---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-namespace
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          role: prod

执行ns.yaml文件，进入容器中访问：
访问的时候会发现失败了！

kubectl apply -f ns.yaml
kubectl attach test -it -n test
curl 10.244.22.3

为什么？
因为ns.yaml里面指定的是prod角色，而我们的标签不对所以访问呢不了！
更改标签后再次访问：

kubectl label namespace test role=prod
kubectl get ns --show-labels

但是我们发现外部访问还是不成功，如下图：

kubectl get pod -o wide
curl ********

5.允许外网访问：

修改ns.yaml清单内容！

vim ns.yaml


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-external
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - ports:
    - port: 80
    from: []

执行清单，在外部访问172.25.0.10：
成功！

kubectl apply -f ns.yaml
curl 172.25.0.10