flanneld和calico
Kubernetes的网络通信问题:
1. 容器间通信： 即同一个Pod内多个容器间通信，通常使用loopback来实现。
2. Pod间通信： K8s要求,Pod和Pod之间通信必须使用Pod-IP 直接访问另一个Pod-IP
3. Pod与Service通信： 即PodIP去访问ClusterIP，当然，clusterIP实际上是IPVS 或 iptables规则的虚拟IP，是没有TCP/IP协议栈支持的。但不影响Pod访问它.
4. Service与集群外部Client的通信，即K8s中Pod提供的服务必须能被互联网上的用户所访问到。
需要注意的是，k8s集群初始化时的service网段，pod网段，网络插件的网段，以及真实服务器的网段，都不能相同，如果相同就会出各种各样奇怪的问题，而且这些问题在集群做好之后是不方便改的，改会导致更多的问题，所以，就在搭建前将其规划好。
CNI(容器网络接口)：
这是K8s中提供的一种通用网络标准规范，因为k8s本身不提供网络解决方案。
目前比较知名的网络解决方案有:
flannel
calico
canel
kube-router
.......
等等，目前比较常用的时flannel和calico，flannel的功能比较简单，不具备复杂网络的配置能力，calico是比较出色的网络管理插件，单具备复杂网络配置能力的同时，往往意味着本身的配置比较复杂，所以相对而言，比较小而简单的集群使用flannel，考虑到日后扩容，未来网络可能需要加入更多设备，配置更多策略，则使用calico更好
所有的网络解决方案，它们的共通性：
1. 虚拟网桥
2. 多路复用：MacVLAN
3. 硬件交换：SR-IOV（单根-I/O虚拟网络）：它是一种物理网卡的硬件虚拟化技术，它通过输出VF(虚拟功能)来将网卡虚拟为多个虚拟子接口，每个VF绑定给一个VM后，该VM就可以直接操纵该物理网卡。
kubelet来调CNI插件时，会到 /etc/cni/net.d/目录下去找插件的配置文件，并读取它，来加载该插件,并让该网络插件来为Pod提供网络服务。
flannel网络插件要怎么部署？
1. flannel部署到那个节点上？
因为kubelet是用来管理Pod的，而Pod运行需要网络，因此凡是部署kubelet的节点，都需要部署flannel来提供网络，因为kubelet正是通过调用flannel来实现为Pod配置网络的(如:添加网络，配置网络，激活网络等)。
2. flannel自身要如何部署？
1》它支持直接运行为宿主机上的一个守护进程。
2》它也支持运行为一个Pod
对于运行为一个Pod这种方式：就必须将flannel配置为共享当前宿主机的网络名称空间的Pod，若flannel作为控制器控制的Pod来运行的话，它的控制器必须是DaemonSet，在每一个节点上都控制它仅能运行一个Pod副本，而且该副本必须直接共享宿主机的网络名称空间，因为只有这样，此Pod才能设置宿主机的网络名称空间，因为flannel要在当前宿主机的网络名称空间中创建CNI虚拟接口，还要将其他Pod的另一半veth桥接到虚拟网桥上，若不共享宿主机的网络名称空间，这是没法做到的。
3. flannel的工作方式有3种:
1) VxLAN:
而VxLAN有两种工作方式:
a. VxLAN: 这是原生的VxLAN，即直接封装VxLAN首部，UDP首部，IP，MAC首部这种的。
b. DirectRouting: 这种是混合自适应的方式, 即它会自动判断，若当前是相同二层网络
(即：不垮路由器,二层广播可直达)，则直接使用Host-GW方式工作，若发现目标是需要跨网段
(即：跨路由器)则自动转变为使用VxLAN的方式。
2) host-GW: 这种方式是宿主机内Pod通过虚拟网桥互联，然后将宿主机的物理网卡作为网关，当需要访问其它Node上的Pod时，只需要将报文发给宿主机的物理网卡，由宿主机通过查询本地路由表，来做路由转发，实现跨主机的Pod通信，这种模式带来的问题时，当k8s集群非常大时，会导致宿主机上的路由表变得非常巨大，而且这种方式，要求所有Node必须在同一个二层网络中，否则将无法转发路由，这也很容易理解，因为如果Node之间是跨路由的，那中间的路由器就必须知道Pod网络的存在，它才能实现路由转发，但实际上，宿主机是无法将Pod网络通告给中间的路由器，因此它也就无法转发理由。
3) UDP: 这种方式性能最差的方式，这源于早期flannel刚出现时，Linux内核还不支持VxLAN，即没有VxLAN核心模块，因此flannel采用了这种方式，来实现隧道封装，其效率可想而知，因此也给很多人一种印象，flannel的性能很差，其实说的是这种工作模式，若flannel工作在host-GW模式下，其效率是非常高的，因为几乎没有网络开销。
4. flannel的网络配置参数：
1) Network: flannel使用的CIDR格式的网络地址，主要用于为Pod配置网络功能。
如: 10.10.0.0/16 --->
master: 10.10.0.0/24
node01: 10.10.1.0/24
.....
node255: 10.10.255.0/24
2) SubnetLen: 把Network切分为子网供各节点使用时，使用多长的掩码来切分子网，默认是24位.
3) SubnetMin: 若需要预留一部分IP时，可设置最小从那里开始分配IP，如：10.10.0.10/24 ，这样就预留出了10个IP
4) SubnetMax: 这是控制最多分配多个IP，如: 10.10.0.100/24 这样在给Pod分配IP时，最大分配到10.10.0.100了。
5) Backend: 指定后端使用的协议类型，就是上面提到的：vxlan( 原始vxlan，directrouter)，host-gw, udp
flannel的配置：
.....
net-conf.json: |
{
"Network": "10.10.0.0/16",
"Backend": {
"Type": "vxlan", #当然，若你很确定自己的集群以后也不可能跨网段，你完全可以直接设置为 host-gw.
"Directrouting": true #默认是false，修改为true就是可以让VxLAN自适应是使用VxLAN还是使用host-gw了。
}
}
#在配置flannel时，一定要注意，不要在半道上，去修改，也就是说要在你部署k8s集群后，就直接规划好，而不要在k8s集群已经运行起来了，你再去修改，虽然可能也不会出问题，但一旦出问题，你就！！
#在配置好，flannel后，一定要测试，创建新Pod，看看新Pod是否能从flannel哪里获得IP地址，是否能通信。
Calico：
Calico是一种非常复杂的网络组件，它需要自己的etcd数据库集群来存储自己通过BGP协议获取的路由等各种所需要持久保存的网络数据信息，因此在部署Calico时，早期是需要单独为Calico部署etcd集群的，因为在k8s中，访问etcd集群只有APIServer可以对etcd进行读写，其它所有组件都必须通过APIServer作为入口，将请求发给APIServer，由APIServer来从etcd获取必要信息来返回给请求者，但Caclico需要自己写，因此就有两种部署Calico网络插件的方式，一种是部署两套etcd，另一种就是Calico不直接写，而是通过APIServer做为代理，来存储自己需要存储的数据。通常第二种使用的较多，这样可降低系统复杂度。
当然由于Calico本身很复杂，但由于很多k8s系统可能存在的问题是，早期由于各种原因使用了flannel来作为网络插件，但后期发现需要使用网络策略的需求，怎么办？
目前比较成熟的解决方案是：flannel + Calico, 即使用flannel来提供简单的网络管理功能，而使用Calico提供的网络策略功能。
Calico网络策略：
Egress：是出站的流量，即自己是源，远端为服务端，因此我自己的源IP可确定，但端口不可预知， 目标的端口和IP都是确定的，因此to 和 ports都是指目标的IP和端口。
Ingress：是入站的流量，即自己为目标，而远端是客户端，因此要做控制，就只能对自己的端口 和 客户端的地址 做控制。
我们通过Ingress 和 Egress定义的网络策略是对一个Pod生效 还是 对一组Pod生效？
这个就要通过podSelector来实现了。
而且在定义网络策略时，可以很灵活，如：入站都拒绝，仅允许出站的； 或 仅允许指定入站的，出站都允许等等。
另外，在定义网络策略时，也可定义 在同一名称空间中的Pod都可以自由通信，但跨名称空间就都拒绝。
网络策略的生效顺序：
越具体的规则越靠前，越靠前，越优先匹配
网络策略的定义：
kubectl explain networkpolicy
spec:
egress: <[]Object> :定义出站规则
ingress: <[]Object>: 定义入站规则
podSelector： 如论是入站还是出站，这些规则要应用到那些Pod上。
policyType：[Ingress|Egress| Ingress,Egress] :
它用于定义若同时定义了egress和ingress，到底那个生效？若仅给了ingress，则仅ingress生效，若设置为Ingress,Egress则两个都生效。
注意：policyType在使用时,若不指定，则当前你定义了egress就egress生效，若egress,ingress都定义了,则两个都生效！！
还有，若你定义了egress， 但policyType: ingress, egress ； egress定义了，但ingress没有定义,这种要会怎样？
其实，这时ingress的默认规则会生效，即：若ingress的默认规则为拒绝，则会拒绝所有入站请求，若为允许，则会允许所有入站请求，
所以，若你只想定义egress规则，就明确写egress ！！
egress：<[]Object>
ports: <[]Object> :因为ports是有端口号 和 协议类型的，因此它也是对象列表
port :
protocol: 这两个就是用来定义目标端口和协议的。
to :<[]Object>
podSelector: <Object> : 在控制Pod通信时，可控制源和目标都是一组Pod，然后控制这两组Pod之间的访问。
ipBlock：<[]Object> : 指定一个Ip地址块，只要在这个IP范围内的，都受到策略的控制，而不区分是Pod还是Service。
namespaceSelector： 这是控制对指定名称空间内的全部Pod 或 部分Pod做访问控制。
Ingress：
from： 这个from指访问者访问的IP
ports: 也是访问者访问的Port
#定义网络策略：
vim networkpolicy-demo.yaml
apiVersion: networking.k8s.io/v1
#注意：虽然kubectl explain networkpolicy中显示为 extensions/v1beta1 ，但你要注意看说明部分.
kind: NetworkPolicy
metadata:
name: deny-all-ingress
namespace: dev
spec:
podSelector: {} #这里写空的含义是，选择指定名称空间中所有Pod
policyTypes:
- Ingress #这里指定要控制Ingress(进来的流量)，但又没有指定规则，就表示全部拒绝，只有明确定义的,才是允许的。
#egress: 出去的流量不控制，其默认规则就是允许，因为不关心，所以爱咋咋地的意思。
#写一个简单的自主式Pod的定义:
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
containers:
- name: myapp
image: harbor.zcf.com/k8s/myapp:v1
#创建dev名称空间，并应用规则
kubectl apply -f networkpolicy-demo.yaml -n dev
# kubectl describe -n dev networkpolicies
Name: deny-all-ingress
Namespace: dev
........................
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)
#查看dev名称空间中的网络规则:
kubectl get networkpolicy -n dev
或
kubectl get netpol -n dev
#然后在dev 和 prod 两个名称空间中分别创建pod
kubectl apply -f pod1.yaml -n dev
kubectl apply -f pod1.yaml -n prod
#接着测试访问这两个名称空间中的pod
kubectl get pod -n dev -o wide
#测试访问:
curl http://POD_IP
kubectl get pod -n prod -o wide
#测试访问:
curl http://POD_IP
#通过以上测试，可以看到，dev名称空间中的pod无法被访问，而prod名称空间中的pod则可被访问。
#测试放行所有dev的ingress入站请求。
# vim networkpolicy-demo.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-ingress
namespace: dev
spec:
podSelector: {}
ingress:
- {} #这就表示允许所有，因为定义了规则，但规则是空的，即允许所有。
policyTypes:
- Ingress
#接着测试，和上面测试一样，也是访问dev 和 prod两个名称空间中的pod，若能访问，则成功。
# kubectl describe -n dev netpol
Name: deny-all-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: <any> (traffic not restricted by source)
Allowing egress traffic:
<none> (Selected pods are isolated for egress connectivity)
Policy Types: Ingress
#测试定义一个仅允许访问dev名称空间中，pod标签 app=myapp 的一组pod的80端口
#先给pod1打上app=myapp的标签
#kubectl label pod pod1 app=myapp -n dev
vim allow-dev-80.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-myapp-ingress
spec:
podSelector:
matchLabels:
app: myapp
ingress:
- from:
- ipBlock:
cidr: 10.10.0.0/16
except:
- 10.10.1.2/32
ports:
- protocol: TCP
port: 88
- protocol: TCP
port: 443
#查看定义的ingress规则
kubectl get netpol -n dev
#然后测试访问 dev 名称空间中的pod
curl http://Pod_IP
curl http://Pod_IP:443
curl http://Pod_IP:88
上图测试：
1. 先给dev名称空间打上标签
kubectl label namespace dev ns=dev
2. 编写网络策略配置清单
vim allow-ns-dev.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ns-dev
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
ns: dev
egress:
- to:
- namespaceSelector:
matchLabels:
ns: dev
#要控制egress，也是如此，只是将ingress替换为egress即可，然后在做测试。
另外，关于网络策略，建议：
名称空间内：
拒绝所有出站，入站流量
仅放行出站目标为当前名称空间内各Pod间通信，因为网络策略控制的颗粒度是Pod级别的，不是名称空间级别。
具体的网络策略，要根据实际需求，来定义ingress 和 egress规则。
