Kubernetes—网络解决方案Calico

Calico是一个纯三层的数据中心网络方案，Calico支持广泛的平台，包括Kubernetes、OpenStack等。
Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的虚拟路由器（ vRouter） 来负责数据转发，而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息向整个 Calico 网络内传播。
此外，Calico 项目还实现了 Kubernetes 网络策略，提供ACL功能。

1、BGP概述

实际上，Calico项目提供的网络解决方案，与Flannel的host-gw模式几乎一样。也就是说，Calico也是基于路由表实现容器数据包转发，但不同于Flannel使用flanneld进程来维护路由信息的做法，而Calico项目使用BGP协议来自动维护整个集群的路由信息。
BGP英文全称是Border Gateway Protocol，即边界网关协议，它是一种自治系统间的动态路由发现协议，与其他 BGP 系统交换网络可达信息。
为了能让你更清楚理解BGP，举个例子：

在这个图中，有两个自治系统（autonomous system，简称为AS）：AS 1 和 AS 2。
在互联网中，一个自治系统(AS)是一个有权自主地决定在本系统中应采用何种路由协议的小型单位。这个网络单位可以是一个简单的网络也可以是一个由一个或多个普通的网络管理员来控制的网络群体，它是一个单独的可管理的网络单元（例如一所大学，一个企业或者一个公司个体）。一个自治系统有时也被称为是一个路由选择域（routing domain）。一个自治系统将会分配一个全局的唯一的16位号码，有时我们把这个号码叫做自治系统号（ASN）。
在正常情况下，自治系统之间不会有任何来往。如果两个自治系统里的主机，要通过 IP 地址直接进行通信，我们就必须使用路由器把这两个自治系统连接起来。BGP协议就是让他们互联的一种方式。

2、Calico BGP实现

在了解了 BGP 之后，Calico 项目的架构就非常容易理解了，Calico主要由三个部分组成：
Felix：以DaemonSet方式部署，运行在每一个Node节点上，主要负责维护宿主机上路由规则以及ACL规则。
BGP Client（BIRD）：主要负责把 Felix 写入 Kernel 的路由信息分发到集群 Calico 网络。
Etcd：分布式键值存储，保存Calico的策略和网络配置状态。
calicoctl：允许您从简单的命令行界面实现高级策略和网络。
3、Calico 部署
curl https://docs.projectcalico.org/v3.9/manifests/calico-etcd.yaml -o calico.yaml

下载完后还需要修改里面配置项：
具体步骤如下：
配置连接etcd地址，如果使用https，还需要配置证书。（ConfigMap，Secret）
根据实际网络规划修改Pod CIDR（CALICO_IPV4POOL_CIDR）
选择工作模式（CALICO_IPV4POOL_IPIP），支持BGP，IPIP
修改内容为：

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: calico-etcd-secrets
  namespace: kube-system
data:
  # Populate the following with etcd TLS configuration if desired, but leave blank if
  # not using TLS for etcd.
  # The keys below should be uncommented and the values populated with the base64
  # encoded contents of each file that would be associated with the TLS data.
  # Example command for encoding a file contents: cat <file> | base64 -w 0  
  etcd-key:      
  etcd-cert:
  etcd-ca:
  #这里用base64 加密然后填写  

kind: ConfigMap
apiVersion: v1
metadata:
  name: calico-config
  namespace: kube-system
data:
  # Configure this with the location of your etcd cluster.
  etcd_endpoints: "https://192.168.190.101:2379"
  # If you're using TLS enabled etcd uncomment the following.
  # You must also populate the Secret below with these files.
  etcd_ca: "/calico-secrets/etcd-ca"
  etcd_cert: "/calico-secrets/etcd-cert"
  etcd_key: "/calico-secrets/etcd-key"
#解开注释，并且 填写ectd连接方式，如果etcd的配置中弃用了tls那么这里就http如果启用了那么就https，并且需要加入etcd的证书配置

            - name: CALICO_IPV4POOL_CIDR
              value: "10.244.0.0/16"
#这个需要修改为集群的pod ip网段
#修改完后应用清单：
# kubectl apply -f calico.yaml
# kubectl get pods -n kube-system

4、Calico 管理工具

下载工具：https://github.com/projectcalico/calicoctl/releases

# wget -O /usr/local/bin/calicoctl https://github.com/projectcalico/calicoctl/releases/download/v3.9.1/calicoctl
# chmod +x /usr/local/bin/calicoctl

# mkdir /etc/calico
# vim /etc/calico/calicoctl.cfg  



apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
  datastoreType: "etcdv3"
  etcdEndpoints: "https://192.168.31.61:2379,https://192.168.31.62:2379,https://192.168.31.63:2379"
  etcdKeyFile: "/opt/etcd/ssl/server-key.pem"
  etcdCertFile: "/opt/etcd/ssl/server.pem"
  etcdCACertFile: "/opt/etcd/ssl/ca.pem"

使用calicoctl查看服务状态：

# calicoctl node status
Calico process is running.

IPv4 BGP status
+---------------+-------------------+-------+----------+-------------+
| PEER ADDRESS  |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+---------------+-------------------+-------+----------+-------------+
| 192.168.31.62 | node-to-node mesh | up    | 09:09:20 | Established |
| 192.168.31.63 | node-to-node mesh | up    | 09:09:20 | Established |
+---------------+-------------------+-------+----------+-------------+

# calicoctl get nodes
NAME         
k8s-master   
k8s-node1    
k8s-node2  

查看 IPAM的IP地址池：
# calicoctl get ippool -o wide

5、Calico BGP 原理剖析

Pod 1 访问 Pod 2大致流程如下：
数据包从容器1出到达Veth Pair另一端（宿主机上，以cali前缀开头）；
宿主机根据路由规则，将数据包转发给下一跳（网关）；
到达Node2，根据路由规则将数据包转发给cali设备，从而到达容器2。
路由表：

# node1
10.244.36.65 dev cali4f18ce2c9a1 scope link 
10.244.169.128/26 via 192.168.31.63 dev ens33 proto bird 
10.244.235.192/26 via 192.168.31.61 dev ens33 proto bird 
# node2
10.244.169.129 dev calia4d5b2258bb scope link 
10.244.36.64/26 via 192.168.31.62 dev ens33 proto bird
10.244.235.192/26 via 192.168.31.61 dev ens33 proto bird 

其中，这里最核心的“下一跳”路由规则，就是由 Calico 的 Felix 进程负责维护的。这些路由规则信息，则是通过 BGP Client 也就是 BIRD 组件，使用 BGP 协议传输而来的。
不难发现，Calico 项目实际上将集群里的所有节点，都当作是边界路由器来处理，它们一起组成了一个全连通的网络，互相之间通过 BGP 协议交换路由规则。这些节点，我们称为 BGP Peer。

6、Route Reflector 模式（RR）

https://docs.projectcalico.org/master/networking/bgp
Calico 维护的网络在默认是（Node-to-Node Mesh）全互联模式，Calico集群中的节点之间都会相互建立连接，用于路由交换。但是随着集群规模的扩大，mesh模式将形成一个巨大服务网格，连接数成倍增加。
这时就需要使用 Route Reflector（路由器反射）模式解决这个问题。
确定一个或多个Calico节点充当路由反射器，让其他节点从这个RR节点获取路由信息。
具体步骤如下：

1、关闭 node-to-node BGP网格

添加 default BGP配置，调整 nodeToNodeMeshEnabled和asNumber：

 cat << EOF | calicoctl create -f -
 apiVersion: projectcalico.org/v3
 kind: BGPConfiguration
 metadata:
   name: default
 spec:
   logSeverityScreen: Info
   nodeToNodeMeshEnabled: false  
   asNumber: 63400
EOF

ASN号可以通过获取 # calicoctl get nodes --output=wide

2、配置指定节点充当路由反射器

为方便让BGPPeer轻松选择节点，通过标签选择器匹配。
给路由器反射器节点打标签：
kubectl label node my-node route-reflector=true
然后配置路由器反射器节点routeReflectorClusterID：

apiVersion: projectcalico.org/v3
kind: Node
metadata:
  annotations:
    projectcalico.org/kube-labels: '{"beta.kubernetes.io/arch":"amd64","beta.kubernetes.io/os":"linux","kubernetes.io/arch":"amd64","kubernetes.io/hostname":"k8s-node2","kubernetes.io/os":"linux"}'
  creationTimestamp: null
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/os: linux
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: k8s-node2
    kubernetes.io/os: linux
  name: k8s-node2
spec:
  bgp:
    ipv4Address: 192.168.31.63/24
    routeReflectorClusterID: 244.0.0.1   # 集群ID
  orchRefs:
  - nodeName: k8s-node2
    orchestrator: k8s
    
 calico apply -f  xxx.yam

现在，很容易使用标签选择器将路由反射器节点与其他非路由反射器节点配置为对等：

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: peer-with-route-reflectors
spec:
  nodeSelector: all()
  peerSelector: route-reflector == 'true'
  
  
  #这里面nodeselector表示所有node
  #peerselector表示 都连接含有这个标签的 node
  #合起来表示所有node都连接含有这个标签的node
  
  calico apply -f    xxx.yaml

查看节点的BGP连接状态：

calicoctl  get bgppeer
calicoctl node status

7、IPIP模式

在前面提到过，Flannel host-gw 模式最主要的限制，就是要求集群宿主机之间是二层连通的。而这个限制对于 Calico 来说，也同样存在。
修改为IPIP模式：

# calicoctl get ipPool -o yaml > ipip.yaml
# vi ipip.yaml

apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: default-ipv4-ippool
spec:
  blockSize: 26
  cidr: 10.244.0.0/16
  ipipMode: Always
  natOutgoing: true

# calicoctl apply -f ipip.yaml
# calicoctl get ippool -o wide

IPIP示意图：

Pod 1 访问 Pod 2大致流程如下：
数据包从容器1出到达Veth Pair另一端（宿主机上，以cali前缀开头）；
进入IP隧道设备（tunl0），由Linux内核IPIP驱动封装在宿主机网络的IP包中（新的IP包目的地之是原IP包的下一跳地址，即192.168.31.63），这样，就成了Node1 到Node2的数据包；
数据包经过路由器三层转发到Node2；
Node2收到数据包后，网络协议栈会使用IPIP驱动进行解包，从中拿到原始IP包；
然后根据路由规则，根据路由规则将数据包转发给cali设备，从而到达容器2。
路由表：

# node1
10.244.36.65 dev cali4f18ce2c9a1 scope link 
10.244.169.128/26 via 192.168.31.63 dev tunl0 proto bird onlink 
# node2
10.244.169.129 dev calia4d5b2258bb scope link 
10.244.36.64/26 via 192.168.31.62 dev tunl0 proto bird onlink 

不难看到，当 Calico 使用 IPIP 模式的时候，集群的网络性能会因为额外的封包和解包工作而下降。所以建议你将所有宿主机节点放在一个子网里，避免使用 IPIP。