基于Calico的CNI

Calico为容器或虚拟机提供安全的网络连接，它创建一个扁平化的第3层网络，为每个节点分配一个可路由的IP地址。网络中的节点不需要NAT或IP隧道就可以相互通信，因此性能很好，接近于物理网络，不使用网络策略的情况下，可能引入0.01毫秒级别的延迟，带宽影响不明显）。 在需要Overlay的应用场景下，Calico可以支持IP-in-IP隧道，也可以与其它Overlay网络（例如Flannel）配合，IP-in-IP隧道会带来较小的性能下降。

Calico支持动态的网络安全策略（NetPolicy），你可以细粒度的控制容器、虚拟机、物理机端点之间的网络通信。

Calico在每个节点运行一个虚拟路由器（vRouter），vRouter利用Linux内核自带的IP转发功能，工作负载依赖于此路由器和外部通信。节点上的代理组件Felix负责根据分配到节点上的工作负载的IP地址信息为vRouter提供L3转发规则。vRouter基于BIRD实现了边界网关协议（BGP）。通过vRouter，工作负载直接基于物理网络进行通信，甚至可以被分配外网IP并直接暴露到互联网上。

术语	说明
BGP	边界网关协议（Border Gateway Protocol）是互联网上一个核心的去中心化自治路由协议，它通过维护IP路由表或前缀表来实现自治系统（AS）之间的可达性 大多数ISP使用BGP来与其他ISP创建路由连接，特大型的私有IP网络也可以使用BGP BGP的通信对端（对等实体，Peer）通过TCP（端口179）会话交换数据，BGP路由器会周期地发送19字节的保活消息来维护连接。在路由协议中，只有BGP使用TCP作为传输层协议
IBGP	内部边界网关协议。同一个AS内部的两个或多个对等实体之间运行的BGP被称为IBGP
IGP	内部网关协议。同一AS内部的对等实体（路由器）之间使用的协议，它存在可扩容性问题： 一个IGP内部应该仅有数十（最多小几百）个对等实体 对于端点数，也存在限制，一般在数百（最多上千）个Endpoint级别 IBGP和IGP都是处理AS内部路由的，仍然需要IGP的原因是： IBGP之间是TCP连接，也就意味着IBGP邻居采用的是逻辑连接的方式，两个IBGP连接不一定存在实际的物理链路。所以需要有IGP来提供路由，以完成BGP路由的递归查找 BGP协议本身实际上并不发现路由，BGP将路由发现的工作全部移交给了IGP协议，它本身着重于路由的控制
EBGP	外部边界网关协议。归属不同的AS的对等实体之间运行的BGP称为EBGP
Border Router	边界路由器，在AS边界上与其他AS交换信息的路由器
AS	自治系统（Autonomous system），一个组织（例如ISP）管辖下的所有IP网络和路由器的整体 参与BGP路由的每个AS都被分配一个唯一的自治系统编号（ASN）。对BGP来说ASN是区别整个相互连接的网络中的各个网络的唯一标识。64512到65535之间的ASN编号保留给专用网络使用
Route Reflector	同一AS内如果有多个路由器参与BGP路由，则它们之间必须配置成全连通的网状结构——任意两个路由器之间都必须配置成对等实体。由于所需要TCP连接数是路由器数量的平方，这就导致了巨大的TCP连接数 为了缓解这种问题，BGP支持两种方案：Route Reflector、Confederations 路由反射器（Route Reflector）是AS内的一台路由器，其它所有路由器都和RR直接连接，作为RR的客户机。RR和客户机之间建立BGP连接，而客户机之间则不需要相互通信 RR的工作步骤如下： 从非客户机IBGP对等实体学到的路由，发布给此RR的所有客户机 从客户机学到的路由，发布给此RR的所有非客户机和客户机 从EBGP对等实体学到的路由，发布给所有的非客户机和客户机 RR的一个优势是配置方便，因为只需要在反射器上配置
工作负载	Workload，即运行在Calico节点上的虚机或容器
全互联	全互联网络（Full node-to-node Mesh）是指任何两个Calico节点都进行配对的L3连接模式

关于如何快速启用基于Calico的CNI网络连接，参考Kubernetes学习笔记。

Calico支持K8S的NetworkPolicy，下面是一个示例。

首先创建一个名字空间：

然后创建一个5实例的部署：

将上述部署暴露为服务：

执行类似下面的命令，确认服务能够正常响应HTTP请求：

下面将上述名字空间dev隔离掉，Calico会阻止访问此名字空间中各的Pod：

这是再次执行curl命令，你无法得到响应。

下面我们再创建一个网络策略， 允许API网关层访问上面的服务：

要删除网络策略，执行：

策略	说明
禁止所有入站连接	YAML 1 2 3 4 5 6 7 8 9 10 11 12 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:   name: default-deny-ingress   namespace: advanced-policy-demo spec:   # 下面的选择器匹配所有Pod   podSelector:     matchLabels: {}   # 策略类型：入站   policyTypes:   - Ingress
禁止对特定Pod的入站连接	YAML 1 2 3 4 5 6 7 8 9 spec:   podSelector:     # 允许对Nginx的入站访问     matchLabels:       run: nginx   ingress:     - from:       - podSelector:           matchLabels: {}
禁止所有出站连接	YAML 1 2 3 4 5 spec:   podSelector:     matchLabels: {}   policyTypes:   - Egress
允许进行DNS查询的出站连接	YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 spec:   podSelector:     matchLabels: {}   policyTypes:   - Egress   # 允许针对kube-system名字空间中的Pod的53端口进行UDP访问   egress:   - to:     # 名字空间选择器     - namespaceSelector:         matchLabels:           name: kube-system     # 53端口     ports:     - protocol: UDP       port: 53
允许对Nginx的出站访问	YAML 1 2 3 4 5 6 7 8 9 10 spec:   podSelector:     matchLabels: {}   policyTypes:   - Egress   egress:   - to:     - podSelector:         matchLabels:           run: nginx

通常你应该使用Service（具有集群静态IP）而不是尝试为Pod指定静态IP。

如果非要这么做，Calico为Pod提供了一些注解：

Calico依赖于Etcd来存放配置信息，缺省情况下它会容器化安装单实例的Etcd。你可以修改其Configmap，指定使用外部的、高可用的Etcd：

所谓出站外部连接，是指从Calico端点到位于Calico集群外部的目的主机的连接。

最简单的实现外部出站连接的方式是为Calico池开启NAT：

你可以针对某个IP池进行NAT设置。

所谓入站外部连接，是指从Calico集群外部主机发起的，针对Calico端点的连接。实现入站外部连接的方式主要由两种。

利用BGP配对，将外部网络的基础设施配对到Calico集群中的某些节点。这需要外部网络中包含支持BGP协议的交换机或者路由器，该路由器作为访问Calico集群内部端点的网关。

如果网络规模较小，你可以让外部路由器和所有Calico节点之间建立BGP会话；如果网络规模较大，可能需要利用RR来创建一个第三层拓扑。 

下面是一个基于BIRD（支持BGP协议的软路由）的示例：Calico集群使用AS号65000，外部网络使用AS号65001，Calico集群内部节点10.0.0.100配对到外部路由器（BIRD）10.0.0.1，Calico内部使用节点全互联模式：

1. Calico BGP Peer配置文件：
   
   Shell

   1 2 3 4 5 6 7 8

   apiVersion: projectcalico.org/v3 kind: BGPPeer metadata:   name: bgppeer-xenial-100-zircon spec:   peerIP: 10.0.0.1   node: xenial-100   asNumber: 65001

2. BIRD配置文件：
   
   Shell

   1 2 3 4 5 6 7 8 9

   protocol bgp xenial100 {     description "10.0.0.100";     local as 65001;     neighbor 10.0.0.100 as 65000;     source address 10.0.0.1;     graceful restart;     import all;     export all; }

按照上面方式配置后，可以在BIRD上看到学习到的路由：

此外，下一章的RR示例也可以支持入站外部链接。

Calico支持多种容器编排器（Orchestrator）特有的入站连接方式，例如Kubernetes的Service IP。

本节内容和Calico无直接关系，Calico仅仅为K8S提供容器连接性，它不知道K8S的服务（Service）是何物。

K8S中Service IP仅仅在集群内部可以访问，集群内节点或者Pod依赖Kube Proxy来访问Service IP。外部访问Service的规范化方式是，使用NodePort（可以配合LoadBalancer），向外部暴露服务。

但是，要直接暴露Service的IP地址到集群外部也是可以实现的。你只需要配置适当的路由规则，将Service IP子网的网关设置为K8S集群的任意节点即可：

较大规模的网络拓扑中，启用节点全互联需要大量的TCP连接，可以考虑引入Router Refactor并禁用全互联。实践中“较大规模”网络拓扑包含50+节点，但是也有超过100节点的正常运作的全互联网络。

BIRD是一个BGP实现，支持完全的动态路由，本章以BIRD软路由器作为RR。

配置完毕后，重启BIRD： sudo service bird restart

很快，你就可以看到RR从Calico节点同步了路由信息过来：

首先禁用全互联，查看Calico的BGP选项，如果启用全互联则禁用之：

然后，添加一个全局的Peer，指向先前创建的RR：

现在，登陆到某个Calico节点，查看其配对情况，应该仅仅和10.0.0.1进行了配对：

可以尝试在集群内连接某个Pod，如果可以连接，说明配置成功。 

现在，你可以在任何物理节点上，执行calico node run命令，运行一个容器，将节点加入Calico CNI网络：

这样的节点可以直接作为路由反射器使用，也可以直连Pod。

从3.3开始，任何Calico节点均可以作为RR来运行，不需要基础设施或外部的专用RR节点。

最简单的配置，为Node加上routeReflectorClusterID字段即可：

3.3为BGPPeer资源添加了字段：

1. nodeSelector：配对应该在该选择器匹配的节点上发生。原先只能指定节点名称
2. peerSelector：配对应该在该选择器匹配的RR上发生。原先只能指定RR的IP

示例：

一种典型的BGP拓扑划分方式：

1. 将节点分组，每个组包含一个RR
2. 所有RR进行全互联 

概念	说明
Node-to-node mesh	使用full node-to-node mesh选项，可以自动化的配置所有Calico节点之间的对等实体。该选项默认启用，每个Calico节点都自动和任何其它节点进行BGP Peering 适用于几十个节点的规模
Global BGP peers	全局BGP Peer是一个BGP代理，它和网络中所有其它Calico节点进行Peering，典型应用场景是中等规模的部署，所有节点运行在同一个L2网络中，每个节点和RR（一个或一组）配对

默认AS号为64512。如果所有节点在一个AS内部但是你需要定制AS号（例如需要同边界路由器进行Peering），执行以下命令：

修改sepc.nodeToNodeMeshEnabled即可。

如果你准备从零开始构建网络，并且不希望使用全互联，可以禁用之。如果你准备从全互联切换到其它方式，则需要预先配置好Peering然后再禁用全互联，以保证系统持续的提供对外服务。

如果你的网络拓扑中存在可以和任意Calico节点配对（Peering）的BGP Speakers，这种BGP Speaker被称为全局对等实体（Global Peer）。一旦配置了全局对等实体，Calico就会自动将所有节点与之配对。

全局对等实体以下场景中有价值：

1. 添加了一个边界路由器，将其配对到全互联网络中
2. 配置使用一个或两个RR的Calico网络，这种情况下每个节点都应该和RR配对，全互联应该禁用

配置示例：

BGP网络拓扑更加复杂的情况下，你可能考虑针对每个Calico节点配置对等实体。示例：

要检查某个节点的BGP Peer，执行命令：

Calico选择器语法：

语法	说明
all()	匹配所有资源
k == ‘v’	匹配标签k的值为v的资源
k != ‘v’	匹配具有标签k，且其值不为v的资源
has(k)	匹配具有标签k的资源
!has(k)	匹配不具有标签k的资源
k in { ‘v1’, ‘v2’ }	匹配标签k的值为v1或v2的资源
k not in { ‘v1’, ‘v2’ }	匹配标签k的值不为v1或v2的资源，或者没有标签k的资源

calicoctl是一个命令行工具，使用它可以创建、修改、删除Calico对象。你可以在任何能够访问Calico数据库的主机上使用该命令。

很多calicoctl命令都需要访问Calico数据库，你需要通过配置文件来指定数据库的信息：

注意：在Kubeadm部署方式下，Calico不会使用K8S的etcd，而是自己创建一个，执行下面的命令可以查看：

如果配置正确，下面的命令将会返回节点列表：

子命令	说明
create	根据指定的文件名或者从标准输入来创建资源
replace	替换资源
apply	应用资源：如果资源不存在则创建之，如果存在则替换之
delete	删除资源
get	获取资源信息，支持的资源包括： bgpConfiguration bgpPeer felixConfiguration globalNetworkPolicy hostEndpoint ipPool networkPolicy node profile workloadEndpoint 示例： Shell 1 2 # 把默认IP池的配置输出为yaml calicoctl get ippool -o yaml
convert	转换不同API版本的配置文件
ipam	IP地址管理器相关命令： Shell 1 2 3 4 5 # 释放一个原先被IPAM分配的IP地址，释放完毕后此IP地址可以被重用 calicoctl ipam release --ip=192.168.1.2    # 显示一个IP地址的信息，例如是否被分配，是否被用户或IPAM保留 calicoctl ipam show --ip=192.168.1.1
node run	注意：节点的很多配置可以通过环境变量提供 在当前节点上启动一个calico/node容器实例，以提供Calico网络、网络策略的支持： Shell 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 # ip/ip6 当前节点的路由IP地址，如果不指定，使用node资源上配置的值 #        如果没有对应的node资源，则尝试自动检测IP地址，如果设置为autodetect则在 #        节点每次启动时强制检测 # as     使用的AS号，如果不指定则使用全局AS号 calicoctl node run [--ip=<IP>] [--ip6=<IP6>] [--as=<AS_NUM>] # 节点名称，默认为主机名                      [--name=<NAME>] # IP地址自动检测方法 # first-found 使用第一个发现的IP地址，如果具有多网卡不建议使用。默认 # can-reach=ip/hostname 使用能到达目标的网络接口 # interface=regrex 网络接口名字正则式 # skip-interface=regrex 排除的网络接口名字正则式 # 示例： #   --ip-autodetection-method interface=eth.* #   --ip-autodetection-method interface=eth0                      [--ip-autodetection-method=<IP_AUTODETECTION_METHOD>]                      [--ip6-autodetection-method=<IP6_AUTODETECTION_METHOD>] # 日志存储路径，默认/var/log/calico                      [--log-dir=<LOG_DIR>]                      [--node-image=<DOCKER_IMAGE_NAME>] # BGP后端，gobgp目前试验阶段                      [--backend=(bird|gobgp|none)] # 指定配置文件，默认/etc/calico/calicoctl.cfg                      [--config=<CONFIG>] # 启动时不创建默认IP池                      [--no-default-ippools]                      [--dryrun] # 执行适当的命令，以配合init system                      [--init-system] # 禁用Docker网络                      [--disable-docker-networking] # Docker容器中网络接口的名字前缀                      [--docker-networking-ifprefix=<IFPREFIX>]                      [--use-docker-networking-container-labels]     # 示例 calicoctl node run --node-image=docker.gmem.cc/calico/node:latest --ip-autodetection-method interface=virbr0
node status	检查节点的状态
node diags	收集Calico节点的诊断信息
node checksystem	检查节点内核，是否可以作为Calico节点

资源类型	说明
node	表示运行Calico的节点，当添加一个主机到Calico集群中后，你需要创建相应的Node资源 当启动一个Calico节点时，它的名称必须和此资源的名称一致 默认情况下，启动一个calico/node实例会自动创建Node资源，使用机器的hostname作为节点名称
bgpPeer	BGP Peer资源代表Calico集群中某个节点与之配对的远程BGP Peer 使用BGP Peer你可以将Calico Newtwork和数据中心结构（例如ToR）连接起来
bgpConfiguration	表示集群的BGP相关的选项
felixConfiguration	表示集群的Felix相关的选项 Felix是运行在任何提供端点（Endpoint）的机器（运行VM或容器的节点）上的守护程序，它负责编程式的路由和ACL，以及为机器上端点提供预期连接性所需的任何东西
hostEndpoint	表示运行Calico的主机上的一个网络接口 每个HostEndpoint可以包含一系列的标签、一个Profile列表，Calico基于这些来应用策略到网络接口。如果没有任何标签、Profile则Calico不会应用任何策略
workloadEndpoint	表示将基于Calico实现网络连接的VM、容器，连接到它们的宿主机的网络接口 WorkloadEndpoint是具有名字空间的资源，只有相同名字空间内定义的networkPolicy才能应用到其上
ipPool	表示一个IP集合，工作负载端点的IP从此集合中分配 IP-in-IP隧道可以用在网络结构（network fabric ）强制进行Src/Dest地址检查、并丢弃无法识别的地址的流量的场景下。在某些公有云环境下，你可能无法完全控制网络，特别是无法进行网络路由器和Calico节点之间的BGP配对、各Calico节点也不能L2直连，使用IP-in-IP封装可以确保跨工作负载（Inter-workload）流量正常传输 当启用IP-in-IP模式时，Calico在路由到IP池范围内的工作负载IP时，会对IP封包进行一次包装 设置ipipMode=Always，则从任何启用Calico的主机发往任何基于Calico网络的容器、虚拟机的流量，都会进行包装 设置ipipMode=CrossSubnet，则可以在下面的场景下优化性能： AWS multi-AZ部署 多组L2直连的Node，通过路由器建立L3连接
globalNetworkPolicy	全局性的网络策略，不具有名字空间，应用到任何名字空间中的工作负载端点、主机端点
networkPolicy	应用到匹配标签选择器的端点的网络策略，网络策略是命名空间内部的资源 网络策略是一个有序的规则的集合，它应用到标签选择器所匹配的端点
profile	包含应用到分配了Profile的单个的端点的网络策略

某次操作意外删除了节点上的calico_node容器，重新执行calicoctl node run恢复容器后，发现此节点无法连接到K8S容器网络，无法ping通任何容器地址。

最终发现，是此节点的配置出现问题（可能是calicoctl node  run的参数不对引发），ipv4Address的掩码错误：

除了此节点以外，其上运行的虚拟机出现同样的问题。修复上述掩码后问题消失。

需要注意一点，正常的路由，出口应该是calicoctl node run时检测到的网络接口：

而出现问题时，该节点上的出口从期望的virbr0变成了tunl0。