Calico 性能不错，而且支持kubernetes网络策略，用的人也多。如果你的环境非常需要支持网络策略，而且对性能和其他功能也有要求，那么Calico会是一个理想的选择。
Calico作为容器网络方案和我们前面介绍的那些方案最大的不同就是它没有采用overlay网络报文做转发，而是提供了纯三层的网络模型。三层通信模型表示每个容器都通过IP直接通信，中间通过路由转发找到对方。在这个过程中，容器所在的节点类似于传统的路由器，提供了路由查找的的功能。要路由能够正常工作，每个容器所在的节点扮演了虚拟路由器 vRoute的功能，而且这些vRoute必须有某种方法，能够知道整个集群的路由信息。
Calico是一个几区BGP的纯三层的数据中心网络方案（也支持overlay网络），并且与kubernetes、openStack、AWS、GCE等laaS和容器平台有良好的集成。
Calico 的设计比较新颖，之前提法哦flannel的host-gw模式之所以不能跨二层网络，是因为它只能修改主机的路由，Calico把该路由表的做法缓存了标准的BGP路由协议。相当于在每个节点上模拟处一个额外的路由器，由于采用的是标准协议，Calico模拟路由器的路由表信息可以被传播到网络的其他路由设备中，这样就实现了在三层网络上的高速跨节点网络。
注：现实中的网络并不总是支持BGP路由，因此Calico也设计了一种ipip模式，使用overlay的方式传输数据，ipip的包头非常小，而且也是内置在内核中，因此它的速度理论上要比VXLAN快，但是安全性更差。

Calico简介

Calico以其丰富的网络共患难著称，不仅能够提供容器的网络解决方案，还可以用在虚拟机网络上。除了网络连接、网络策略是Calico最受追捧的功能之一。使用Calico的策略语言，可以实现对容器、虚拟机工作负载和裸机主机各节点之间网络通信进行细粒度和动态的安全规则控制。Calico基于iptables实现了Kubernetes的网络策略，通过在各个节点上应用ACL（访问控制列表）提供工作负载的多租户隔离、安全组及其他可达性限制等功能。此外，Calico还可以与服务网格Istio集成，以便在服务网格层和网络基础架构层中解释和实施集群内工作负载的网络策略。
在一个kubernetes集群中，用户可以通过manifest文件快速部署Calico。如果 对Calico的网络策略功能感兴趣，则统一可以向集群应用manifest启用这些功能。
Calico还支持容器漂移。因为Calico配置的三层网络使用BGP路由协议在主机之间路由数据包。BGP路由机制可以本地引导数据包，这意味着无须overlay网络中额外的封包解包操作。由于免去了额外的包头（大部分情况下依赖宿主机IP地址）封装数据包，容器在不同主机之间迁移没有网络的限制。
虽然VXLAN等技术进行封装也是一个不错的解决方案，但该过程处理数据包的方式通常难以追踪。在Calico网络出现问题时，用户号网络管理员可以使用常规的方式进行故障定位。
Calico在每一个计算节点利用Linux内核的一些功能实现了一个高效的vRoute负责数据转发，而每个vRoute通过BGP把自己运行的工作负载的路由信息向整个Calico网络传播。小规模部署可以直接互联，大规模下可以通过指定的BGP Route Reflector完成。最终保证所有工作负载之间的数据流量都是通过IP路由的方式完成互联的。Calico节点组网可以直接利用数据中心的网络结构（无论是L2还是L3），不需要额外 的NAT或隧道。

1、名称解释

在深入解析Calico原理之前，让我们先来熟悉Calico的几个重要名词：
Endpoint：接入Calico网络中的网卡（IP）；
AS：网络自治系统，通过BGP与其他AS网络交换路由信息；
iBGP：AS 内部的BGP Speaker，与同一个AS内部的iBGP、eBGP交换路由信息；
eBGP：AS 边界的BGP Speaker，与同一个AS内部的iBGP 、其他AS的eBGP 交换路由信息；
workloadEndpoint：虚拟机和容器端点，一般指它们的IP地址
hostEndpoint： 宿主机端点，一般指它们的IP地址；

2、Calico架构解析

Calico的基本工作原理如图：
（由于图片大小限制，上传不了，敬请谅解。）
calicoctl：Calico的命令行工具，允许从命令行界面配置实现高级策略和网络；
orchestrator plugins：提供与各种流行的云计算编排工具的紧密集成和同步支持；
key/value store；存储Calico的策略配置和网络状态信息，目前主要使用etcdv3或kubernetes API Server；
calico/node：在每个主机上运行agent，从key/value存储中读取相关的策略和网络配置信息，并在Linux内核中实现；
Dikastes/Envoy：可选的kubernetes sidecar，可以通过相互TLS身份验证保护工作负载之间的通信安全，并动态配置应用层控制策略。
下面对Calico几个重要的组件进行分析：
Orchestrator Plugin
每个主要的云编排平台都有单独的Calico网络插件。这些插件的目的是将Calico无缝集成到编排工具中，就像他们在管理编排工具中内置的网络工具一样管理Calico网络，除此之外，一个好的Orchestrator Plugin还应该允许用户直接调用编排层的API配置Calico网络，例如 kubernetes 的NetworkPolicy API。
Orchestrator Plugin一般负责以下工作：
API转换：每个编排工具都不可避免的拥有自己的一套用于管理网络的API接口规范，Orchestrator Plugin的作用就是将这些API转换为Calico的数据模型，然后将其存储在Calico的数据存储中；
如有需要，Orchestrator Plugin 将从Calico网络向编排器提供管理命令的反馈信息，包括提供有关Felix存活的信息，以及如果网络配置失败，就将某些Endpoint标记为失败

etcd
etcd 是一个分布式键值存储数据库，专注于实现数据存储的一致性。Calico使用etcd提供节点上组件之间的数据协同。
在一个Calico中，etcd负责：

• 数据存储。etcd以分布式、一致和容错的方式存储Calico网络数据（一般至少由3个etcd节点组成一个集群）。确保Calico网络始终处于已知良好状态，同时允许运行etcd个别机器节点失败或无法访问。Calico网络数据的这种分布式存储提高了Calico组件从数据库读取的能力。
• 组件之间协同交互。通过让Calico其他组件watch etcd键值空间中的某些key，确保它们能够及时响应集群状态的更新。

注：Calico还可以使用kubernetes API datastore作为数据库。这还是一个beta版本的功能，因为该API不支持Calico的 IPAM功能。

Calico内部的实现机制如图
（由于图片大小限制，上传不了，敬请谅解。）

Felix
Felix是一个守护程序，作为agent运行在托管容器或虚拟机的Calico节点上。Felix负责刷新主机路由和ACL规则等，以便为该主机上的Endpoint正常运行提供所需的网络连接和管理。进出容器、虚拟机和物理主机的所有流量，都会便利由Calico利用Linux内核原生路由和iptables生成的规则。
Felix一般负责以下工作：

• 管理网络接口。Felix将有关网络接口的一些信息编程到内核中，使内核能够正确处理该Endpoint发出的流量。Felix将确保主机正确响应来自每个工作负载的ARP请求，并将其管理的网卡启用IP
  Forward。
• 编写路由。Felix负载将到其主机上Endpoint的路由编写到Linux内核FIB（转发信息库）中。这确保那些发往目标主机的Endpoint的数据包被正确的转发；
• 编写ACL。Felix还负责将ACL编程到Linux内核中，即iptables规则，这些ACL用于确保只在Endpoint之间发送有效的网络流量，并确保Endpoint无法绕过Calico的安全措施；
• 报告状态。Felix负责提供有关网络健康状况的数据，例如，它将报告配置其主机时发生的错误和问题。该数据会被想接入etcd，并对网络中其他的组件可见。

BGP Client
Calico在每个运行Felix服务的节点上部署一个BGP Client，BGP客户端的作用是读取Felix编写到内核中的路由信息，由BGP客户端对这些路由信息进行分发。具体来说，当Felix将路由插入Linux内核的FBI时，BGP客户端将接收它们，并将它们分发到集群中的其他工作节点。

BGP Route Reflector（BIRD）
简单的BGP可能成为较大规模部署的性能瓶颈，因为它要求每个BGP客户端连接到网络拓扑中的每一个其他BGP客户端。随着集群规模的扩大，一些设备的路由表可能会被撑满。
因此，在较大规模的部署中，Calico建议使用BGP Route Reflector（路由器反射器）。互联网中通常使用BGP Route Reflector 充当BGP客户端连接中心点，从而避免与互联网中的每个BGP客户端进行通信。Calico使用BGP Route Reflector是为了减少给点一个BGP客户端与集群其他BGP客户端的连接。用户也可以同时部署多个BGP Route Reflector 服务实现高可用。Route Reflector 仅仅协助管理BGP网络，并没有工作负载的数据包经过它们。
在Calico中，最常见的BGP组件是BIRD，配置为 Route Reflector运行，而非标准的BGP客户端。
BGP Route Reflector 主要负责集中式的路由信息分发，当Calico BGP客户端将路由信息报告到Route Reflector时，Route Reflector会将这些路由通告给集群中的其他节点。

Calico的隧道模式

Calico可以创建并管理一个三层网络，为每个工作负载分配一个完全可路由的IP地址。工作负载可以在没有IP封装和NAT的情况下进行通信，以实现裸机性能，简化故障配出和提供更好的互操作性。我们称这种模式为vRoute模式。vRoute模式直接用物理机作为虚拟路由器，不再创建额外的隧道。然而在需要使用overlay网络环境中，Calico也提供了IP-in-IP简称ipip的隧道技术。
和其他overlay模式一样，ipip是在各节点之间架起一个隧道，通过隧道两端节点上的容器网络连接，实现机制简单说就是用IP包头封装原始IP报文。启用ipip模式时，Calico在各节点上创建一个名为tunl0的虚拟网络接口。我们以flannel为例，已经对隧道网络做了非常详细的介绍，下面将重点介绍Calico的vRoute实现机制。

安装 Calico
通过kubernetes 的add-on机制安装Calico非常方便，用户可以通过向kubernetes应用一个manifest文件部署Calico，用一条命令即可（最新的安装命令可以查看Calico官网）

kubectl apply -f http://docs.projectaclico.org/v2.1/getting-started/kubernetes/installation/hosted/kubeadn/1.6/calico.yaml

如果要是用Calico的可选网络策略，也可以通过kubernetes创建相应的Network Policy 对象。更多关于kubernetes安装Calico可以查看官网，这里就不再赘述。
Calico不仅支持CNI还支持CNM模型，即实现了Docker libnetwork 的网络驱动。因此，在Docker中是用Calico作为网络驱动的命令如下：

docker network create --driver --ipam-driver calico-ipam net1

上面命令创建了一个以Calico为网络驱动盒的Docker网络，是用的是calico-ipam模块分配容器IP地址。
安装好calico后，在后续的Pod创建过程中，kubelet将通过CNI接口调用Calico进行Pod网络配置，包括IP地址、路由规则、iptables规则等。
注：如果设置CALICO_IPV4POOL_IPIP=“off”，既不使用ipip模式，则calico不会创建tunl0网络接口，路由规则直接使用物理机网卡作为路由器进行转发。

Calico报文路径

我们来分析同一个网络，不同节点的容器是怎么通信的，借此一窥Calico的实现原理。以容器1 ping 容器2 为例，先进入容器1中查看它的网路配置和路由表。
可以看到容器1 的地址为192.168.18.64/32（读者环境可能不是这个地址），需要注意的是，它的Mac地址为ee:ee:ee:ee:ee:ee，很明显是个固定的特殊地址。事实上，Calico为所有容器分配容器Mac地址都一样，这么做是因为Calico只关心三层的IP地址，根本不关心二层Mac地址。
要ping的目的地址是192.168.196.129/32，因为两者不是在同一个网络中，所有容器1会查看自己的路由表获取下一跳的地址。j进入容器1，查看容器1的路由信息：

ip route
default  via  169.254.1.1  dev  cali0
169.254.1.1  dev calio

容器的路由表非常奇怪，所有的报文都会经过cali0 发送到下一跳169.254.1.1（这是预留的本地IP网段）。Calico为了简化网络配置将容器里的路由规则都配置成一样的，不需要动态更新。知道下一跳后。容器会查询下一跳168.254.1.1的Mac地址，这个ARP请求发到哪里呢？cali0是veth pair的一端，其另一端是主机上以caliXXX命名的网卡，通过 ethtool -S cali0 列出对端的网卡 index。

ethtool -S cali0
NIC statistics:
    peer_ifindex: 6

可以查看主机 index为6 的网卡信息，这块网卡被分配了一个随机的Mac地址，但是没有IP地址，接收到想要169.254.1.1 Mac地址的ARP请求报文，它收到ARP请求后，直接进行了应答，应答报文中的Mac地址就是自己的Mac地址。容器后续的报文都会发送给主机，主机根据IP地址再进行路由转发。
主机上这块网卡不管ARP请求的内容，直接将自己的Mac地址作为应答的行为被称为“ARP proxy”，可以通过检查一下内核参数检查：

cat  /peoc/sys/net/ipv4/conf/caliXXX/proxy_arp
1

总体来说，可以认为Calico把主机作为容器的默认网关使用，所有的报文发送到主机上，主机根据路由表进行转发。和经典的网络架构不同的是，Calico并没有给默认网关配置一个IP地址，而是通过 “ARP proxy” 和修改容器路由表的机制实现。
主机上的calico-XXX网卡接收到报文后，所有的报文会根据路由表转发

IP route
169.254.0.0/16  dev eth0 scope link  metric  1002
192.168.18.64  dev caliXXX  scope link
blackhole  192.168.18.64/26  proto  bird
192.168.18.65  dev caliXXX  scope  link
192.168.196.128/26  via  172.17.8.101  dev eth0  proto brid

由于我们ping的目的地址是192.168.196.129，所有会匹配到最后一条路由规则，把172.17.8.101 作为下一跳，并通过主机的eth0网卡发出。
注：在发送到另一台主机之前，报文会先经过Calico配置的iptables 规则，如果被iptables规则拦住，包就会被内将丢弃。
报文到达容器B所在的主机172.17.8.101，再来看看该主机上的路由表信息

ip route
169.254.0.0/16  dev eth0 scope  link  metric 1003
192.168.18.64/26  via  172.17.8.100  dev etn0  proto bird
192.168.196.128 dev caliXXX  scope link 
blackhole 192.168.196.128/26  proto  bird
192.168.196.129  dev caliXXX  scope  link

同样的，这个报文会匹配到最后一条路由表项，这个表项匹配的是一个IP地址，而不是网段。也就是说，主机上的每个容器都会有一个对应的路由表项。报文被发送到caliXXX这个 veth pair，然后从另一端发送给目标容器。目标容器收到报文后，回复ICMP报文，应答报文原路返回。

Calico使用指南

在了解了Calico的实现机制后，来了解一下Calico常见的用法

1、Calico CNI插件配置说明

Calico CNI插件是按照标准的CNI配置规范进行配置的。一个最小化的配置文件如下：

{
    "name": "any_name",
    "cniVersion": "0.1.0",
    "type": "calico",
    "ipam": {
        "type": "calico-ipam"
    }
}

如果节点上的calico-node容器注册了节点主机名以外的NODENAME，则此节点上的CNI插件必须配置使用相同的NODENAME，例如：

{
    "name": "any_name",
    "nodename": "<NODENAME>",
    "type": "calico",
    "ipam": {
        "type": "calico-ipam"
    }
}

一些常见的配置项如下：

• datastore_type、Datastore type、default:etcdv3，设置为kubernetes时表示直接使用kubernetes API读取数据库服务。

• etcd location，在使用etcd作为后端数据库服务时，以下配置有效

   — etcd_endpoint
   — etcd_key_file
   — etcd_cert_file
   — etcd_ca_cert_file
  

• log_level，可选值为WARNING、INFO、DEBUG，默认值是WARNING，日志打印到stderr。

• ipam，IP地址管理工具，值为一个JSON字典，可以包含以下子配置项：

   — "type" : "calico-ipam"
   — "assign_ipv4" : "true"
   — "assign_ipv6" : "true"
   — "ipv4_pools" : [ "10.0.0.0/24", "20.0.0.0/16", "default-ipv4-ippool" ]
   — "ipv6_pools" : [ "allow_ip_frowarding", "default-ipv6-ippool"]
   — "container_setings" : { "allow_ip_frowarding" : true}， 默认是false，该选项允许在容器命名空间内配置设置
  

将Calico CNI插件与kubernetes一起使用时，插件必须能够访问kubernetes API服务器，才能找到分配给kubernetes Pod的标签，一般都通过在Calico CNI配置文件中指定kubeconfig文件解决，例如：

{
    "name": "any_name",
    "cniVersion": "0.1.0",
    "type": "calico",
    "kubernetes": {
        "kubeconfig": "/path/to/kubeconfig"
    },
    "ipam": {
        "type": "calico-ipam"
    }
}

或者通过kubernetes API Server，例如：

{
    "name": "any_name",
    "cniVersion": "0.1.0",
    "type": "calico",
    "kubernetes": {
        "k8s_api_server": "http://127..0.0.1:8080"
    },
    "ipam": {
        "type": "calico-ipam"
    }
}

如果要使用kubernetes Network Policy功能，则必须在网络配置中设置策略类型。Calico目前只支持一个策略类型，即kubernetes。

{
    "name": "any_name",
    "cniVersion": "0.1.0",
    "type": "calico",
    "policy": {
        "type": "k8s"
    }
    "kubernetes": {
        "kubeconfig": "/path/to/kubeconfig"
    },
    "ipam": {
        "type": "calico-ipam"
    }
}

当使用type: k8s时，Calico CNI插件需要对所有命名空间中的Pods资源具备读访问权限。

2、Pod 分配固定 IP

很多传统的应用程序，在上容器云时都会使用固定的ip地址的需求。虽然这不符合kubernetes对网络的基础假定，但Calico IPAM 却支持为Pod分配固定的IP。kubernetes有两个相关的annotations 可以使用。
cni.projectcalico.org/ipAddrs
指定一个要分配给Pod的IPv4或IPv6的地址列表。请求的IP地址将从Calico IPAM分配，并且必须存在于已配置的IP池中。例如：

annotations: "cni.projectcalico.org/ipAddrs": "[\"192.168.0.1\"]"

cni.projectcalico.org/ipAddrsNoIPam
指定一个要分配给Pod的IPv4或IPv6地址列表，绕过IPAM。任何IP冲突和路由配置都必须由人工或其他系统管理。Calico仅处理那些属于Calico IP池中的IP地址，将其路由分配到Pod。如果分配的IP地址不在Calico IP池中，则必须保证通过其他机制正确地处理该IP地址的路由。例如：

annotations: "cni.projectcalico.rog/ipAddrsNoIpanm": "[\"10.0.0.1\"]"

默认情况下，Calico禁用ipAddrsNoIpam功能，若用户需要使用该功能，还需要爱CNI网络配置的 feature_control 字段中启用：

{
    "name": "any_name",
    "cniVersion": "0.1.0",
    "ipam": {
        "type": "calico-ipam"
    }
    "fretrue_control": {
        "ip_addrs_no_ipam": "true"
    }
}

注：此功能允许通过IP欺骗绕过网络策略。用户应确保适当的准入规则，以防止用户使用不当的IP地址。
需要注意的是：

• ipAddrs和ipAddrsNoIpam 不能同时使用；
• 只能使用这些批注指定有个IPv4/IPv6 地址或一个IPv4和一个IPv6地址
• 当ipAddrs 或 ipAddrsNoIpam与 ipv4pools或ipv6pools一起使用时，ipAddrs/ipAddrsNoIpam有更高的优先级。

3、IPAM

使用CNI 的host-local IPAM插件时，subnet字段允许使用一个特殊的值“usePodCidr”。告诉插件从kubernetes API获取Node.podCIDR字段，以确定自己要用的的子网。Calico不使用网段范围的网关字段，因此不需要该字段。如果提供了，则忽略该字段。
注：usePodCidr 只能作为子网字段的值，不能再rangeStart或rangeEnd中使用，因此，如果子网设置为usePodCidr，则这些值无用。

Calico 支持host-local IPAM插件的route字段，如下所示：

• 如果没有route字段，Calico将在pod中安装默认0.0.0.0的路由规则（取决于Pod是否具有IP地址）
• 如果存在route字段，Calico将仅将route字段中的路由规则添加到Pod中，Calico在Pod中实现了点对点连接，因此不需要gw字段，如果存在则忽略。Calico安装所有路由都会讲Calico的link-local
  IP作为下一跳
• node_name 字段，指定用于查询“usePodCidr”的节点的

nodename，默认值为当前节点的hostname。

{
    "name": "any_name",
    "cniVersion": "0.1.0",
    "type": "calico",
    "kubernetes": {
        "kubeconfig": "/path/to/kubeconfig",
        "node_name": "node-name-in-k8s"
    }
    "ipam": {
        "type": "host-local",
        "ranges": [
            [
                {"subnet": "usePodCidr"}
            ],
            [
                {"subnet": "2001:db8::/96"}
            ]
        ],
        "route": [
            {"dst": "0.0.0.0/0"},
            {"dst": "2001:db8::/96"}
        ]
    }
}

4、基于每个命名空间或每个Pod指定专属IP池

Calico IPAM支持为每个命名空间或者每个Pod指定专用的IP池资源，这一功能是通过应用kubernetes annotations实现的。
cni.projectcalico.org/ipv4pools
已配置的IPv4 pool列表，可以从中选择pod的地址。

annotations: "cni.projectcalico.org/ipv4pool": "[\"default-ipv4-ippool\"]"

cni.projectcalico.org/ipv6pools
已配置的IPv6 pool列表，可以从中选择pod的地址。

annotations: "cni.projectcalico.org/ipv6pool": "[\"2001:db8::1/120\"]"

如果提供上面的配置，则这些指定的ip地址池将覆盖CNI基础配置中指定的任何ip地址池资源。
Calico CNI插件支持为每个namespace配置annotations。如果namespace和Pod中都有此配置，则优先使用Pod的配置。

为什么选择Calico 网络选择BGP

为什么选择BGP而不选择IGP？首先明确BGP和IGP是如何在一个大规模网络中工作的。
任何网络，尤其是大规模网络，都需要处理两个问题：
发现网络中路由器之间的拓扑结构
发现网络中正在工作的节点，以及可到达该网络的外部连接。
IGP 需要执行大量复杂计算，才能让每台设备在同一时刻得到对所处网络拓扑的相同认知。这限制了IGP所能运行的规模（几百个路由器规模，虽然有一些技术可以突破该限制，但同时也带来了架构上的其他限制）。同时IGP也被限制在它们能够通告的最大Endpoint数量上，这个数量浮动范围比较大，但最多也只能到一万多。
BGP 可以在一个网络中扩展到几百台路由器规模，如果使用了Route Reflector这一数量可以到达数万台。并且在实践中得到了验证。

小结

Calico是一个虚拟网络解决方案，完全利用路由规则实现动态组网，通过BGP通告路由。由于Calico 利用宿主机协议栈的三层确保容器之间跨主机的连通性，报文的流向完全通过路由规则控制，没有overlay、NAT，直接经过宿主机协议栈处理，因此我们称Calico是一个纯三层的组网方案，转发效率也高。
Calico 的核心设计思想就是Route，它把每个操作系统的协议栈看做一个路由器，然后把所有的容器看成连接在这个路由器上的网络终端，在路由器之间运行标准的BGP，并让节点自己学习这个网络拓扑该如何转发。然而，当网络端点数量足够大时，自我学习发现拓扑的收敛过程非常消耗资源和时间。
Calico 的缺点是网络规模会受到BGP网络规模的限制。Calico路由的数目与容器数目相同，极易超过三层交换、路由器或节点的处理能力，从而限制了整个网络的扩张，因此Calico网络瓶颈在于路由信息的容量。Calico会在每个节点上设置大量的iptables规则和路由规则，这将带来极大的运维和故障排查难度。Calico的原理决定了它不能支持VPC，容器只能从Calico设置的网段中获取IP。Calico目前的实现没有流量控制的功能，会出现少量容器抢占节点多数带宽的情况。但是我们可以结合CNI的bandwidth插件实现流量的控制。
Calico 的应用场景主要在IDC内部，Calico官方推荐将其部署在大二层网络上，这样所有的路由器之间是互通的。所谓的大二层就是没有任何三层的网关，所有的机器、宿主机、物理机在二层可达的。大二层主要的问题时弹性伸缩的问题。频繁开关机的时候，容器的启停虽然不影响交换机，但是容器产生广播风暴。事实上，在很多有经验的网络工程师眼里，大二层存在单一故障问题，也就是说，任何一个都会有一定的硬件风险让整个大二层瘫痪。因此，实际场景中经常会把集群划分成多个网段，对外是三层网络的结构。
从架构上看，Calico在每个节点上会运行两个主要的程序，一个是Felix，另一个是BIRD。Felix会监听etcd的事件，并负责配置节点上容器的网络协议栈和主机的iptables规格及路由表项。BRID会从内核中获取IP的路由发生了变化的信息，并告知Route Reflector。Route Reflector是一个路由程序，它会通过标准BGP的路由协议扩散到其他宿主机上，让集群的其他容器都知道这个IP。

(本文章是学习《kubernetes 网络权威指南》 一书时做的笔记，由于本人是刚学习k8s，且自学方式就是把它敲一遍，然后加一些自己的理解。所以会发现很多内容是跟书中内容一模一样，如果本文是对本书的侵权，敬请谅解，告知后会删除。如果引用或转载，请注明出处——谢谢)