Calico 是一种网络和安全解决方案，使 Kubernetes 工作负载和非 Kubernetes/遗留工作负载能够无缝、安全地通信。

Calico 由用于保护网络通信的网络和用于大规模保护云原生微服务/应用程序的高级网络策略组成。

Calico是一个三层的虚拟网络解决方案，它把每个节点都当作虚拟路由器（vRouter），并把每个节点上的Pod都当作是“节点路由器”后的一个终端设备并为其分配一个IP地址。各节点路由器通过BGP协议学习生成路由规则，从而实现不同节点上Pod间的互联互通，并且比 kubenet 或 flannel 等其他常见替代方案更高效。

Calico cni 特点：

• 内置数据加密
• 高级 IPAM 管理
• overlay和non-overlay网络选项
• 数据平面选择：iptables、eBPF、Windows HNS 或 VPP

Calico 网络策略套件是 Calico CNI 的接口，其中包含数据平面要执行的规则。

Calico 网络策略：
• 采用零信任安全模型设计（拒绝所有，仅在需要时允许）
• 与 Kubernetes API 服务器集成（因此您仍然可以使用 Kubernetes 网络策略）
• 支持旧系统（裸机、非-集群主机）使用相同的网络策略模型。

用于网络策略的Calico 网络策略套件的特点：

• 允许/拒绝集群内、Pod 与外部世界之间以及非集群主机之间的流量的命名空间和全局策略。
• 网络集（任意一组IP 子网、CIDR 或域），用于限制工作负载的出口和入口流量的IP 范围。
• 应用层(L7) 策略，使用HTTP 方法、路径和加密安全身份等属性来强制执行流量。

BGP（边界网关协议）是一种基于标准的网络协议，用于在网络上共享路由。它是互联网的基本组成部分之一，具有特殊的扩展特性。

Calico内置了对BGP的支持。在预部署中，这允许Calico与物理网络对等以交换路由，从而形成一个non-overlay网络，其中pod IP地址可以在更广泛的网络中路由，就像连接到网络的任何其他工作负载一样。

Calico可以以三种模式运行 BGP：

Full mesh - 在底层L2网络之上或使用IPIP overlay网络的情况下，每个节点相互进行BGP通信，轻松扩展到100个节点。
BGP路由反射器 - 每个节点与一个或多个BGP路由反射器进行通信，扩展到100个节点以上，位于底层L2网络之上或使用IPIP overlay网络。
Peered with TOR (Top of Rack) routers - 在物理数据中心中，每个节点都与相应机架顶部的路由器进行通信，从而扩展到物理数据中心的极限。

overlay网络是分层在另一个网络之上的网络。在 Kubernetes 环境中，overlay网络可用于处理底层网络顶部节点之间的 Pod 到 Pod 流量，该网络不知道 Pod IP 地址或哪些 Pod 正在哪些节点上运行。overlay网络的工作原理是将底层网络不知道如何处理（例如使用 Pod IP 地址）的网络数据包封装在底层网络知道如何处理（例如节点 IP 地址）的外部数据包中。用于封装的两种常见网络协议是 VXLAN 和 IP-in-IP。

使用overlay网络的主要优点是它减少了对底层网络的依赖。例如，您可以在几乎任何底层网络之上运行 VXLAN overlay，而无需与底层网络集成或对其进行任何更改。

使用overlay网络的主要缺点是：

  对性能有轻微影响。封装数据包的过程需要占用少量 CPU，并且数据包中需要额外的字节来对封装进行编码（VXLAN 或 IP-in-IP 标头），从而减少了可发送的内部数据包的最大大小，从而可以减少内部数据包的大小。意味着需要为相同数量的总数据发送更多数据包。
  Pod IP 地址在集群外部不可路由。

除了标准 VXLAN 或 IP-in-IP overlay之外，Calico 还支持 VXLAN 和 IP-in-IP 的“跨子网”模式。在此模式下，在每个子网内，底层网络充当 L2 网络。在单个子网内发送的数据包不会被封装，因此您可以获得non-overlay网络的性能。跨子网发送的数据包被封装，就像普通的overlay网络一样，减少了对底层网络的依赖（无需与底层网络集成或对其进行任何更改）。

就像标准overlay网络一样，底层网络不知道 Pod IP 地址，并且 Pod IP 地址在集群外部不可路由。

不同Kubernetes网络实现的一个重要区别特征是pod IP地址是否可以在集群之外的网络中路由。

如果 Pod IP 地址在集群外部网络中不可路由，那么当 Pod 尝试与集群外部的 IP 地址建立网络连接时，Kubernetes 将使用一种称为 SNAT（源网络地址转换）的技术来更改源 IP地址从 Pod 的 IP 地址到托管 Pod 的节点的 IP 地址。连接上的任何返回数据包都会自动映射回 pod IP 地址。因此，Pod 不知道 SNAT 正在发生，连接的目的地将该节点视为连接的源，而集群外部网络永远不会看到 Pod IP 地址。

对于相反方向的连接，即集群外部的数据需要连接到 Pod，这只能通过 Kubernetes 服务或 Kubernetes ingress来完成。集群外部的任何内容都无法直接连接到 Pod IP 地址，因为集群外部网络不知道如何将数据包路由到 Pod IP 地址。

如果 Pod IP 地址在集群外部可路由，则 Pod 可以在没有 SNAT 的情况下连接到外部网络，并且外部网络可以直接连接到 Pod，而无需通过 Kubernetes 服务或 Kubernetes Ingress。

可在集群外部路由的 pod IP 地址的优点是：

  避免出站连接的 SNAT 对于集成现有的更广泛的安全要求可能至关重要。它还可以简化调试和操作日志的理解。
  如果您有专门的工作负载，这意味着需要直接访问某些 pod，而无需通过 Kubernetes 服务或 Kubernetes Ingress，那么可路由 pod IP 在操作上可能比使用主机网络pod更简单。

可在集群外路由的pod IP地址的主要缺点是，pod IP在网络中必须是唯一的。例如，如果运行多个集群，则需要为每个集群中的pod使用不同的IP地址范围（CIDR）。这反过来又可能导致在大规模运行时，或者在现有企业对IP地址空间有其他重大需求的情况下，IP地址范围会耗尽。

如果您的集群使用overlay网络，则 Pod IP 通常无法在集群外部路由。

如果您不使用overlay网络，则 Pod IP 是否可在集群外部路由取决于所使用的 CNI 插件、云提供商集成或（对于本地）与物理网络的 BGP 对等互连的组合。

Calico 灵活的网络模块化架构包括以下内容。

Calico CNI 网络插件使用一对虚拟以太网设备（veth 对）将 Pod 连接到主机网络命名空间的 L3 路由。这种 L3 架构避免了许多其他 Kubernetes 网络解决方案中额外的 L2 桥带来的不必要的复杂性和性能开销。

Calico CNI IPAM 插件从一个或多个可配置的 IP 地址范围中为 Pod 分配 IP 地址，根据需要动态为每个节点分配小块 IP。与许多其他 CNI IPAM 插件（包括许多网络解决方案中使用的主机本地 IPAM 插件）相比，IP 地址空间使用效率更高。

Calico 可以提供 VXLAN 或 IP-in-IP overlay网络，包括Cross-SubNet（跨子网）模式。

Calico可以提供运行在任何底层L2网络之上的non-overlay网络，或L3网络，该网络是具有适当云提供商集成的公共云网络，或具有BGP功能的网络。

Calico的网络策略执行引擎实现了Kubernetes网络策略的全部功能，以及Calico网络策略的扩展功能。这与Calico的内置网络模式或任何其他Calico兼容的网络插件和云提供商集成配合使用。

想要启用VXLAN隧道，只需要把环境变量CALICO_IPV4POOL_VXLAN的值设置为Always或Cross-SubNet即可，但在全局流量上使用VXLAN隧道时建议将ConfigMap/calico-node中calico_backend键的值设置为vxlan以禁用BIRD，并在DaemonSet/calico-node资源的Pod模型中禁用calico-node容器的存活探针和就绪探针对bird的检测。

# 设置在IPv4类型的地址池上启用的IP-IP及其类型，支持3种可用值
# Always（全局流量）、Cross-SubNet（跨子网流量）和Never
- name: CALICO_IPV4POOL_IPIP
  value: "Never"
# 是否在IPV4地址池上启用VXLAN隧道协议，取值及意义与Flannel的VXLAN后端相同，
# 但在全局流量启用VXLAN时将完全不再需要BGP网络，建议将相关的组件禁用
- name: CALICO_IPV4POOL_VXLAN
  value: "Always"

kind: ConfigMap
apiVersion: v1
metadata:
  name: calico-config
  namespace: kube-system
data:
  # Typha is disabled.
  typha_service_name: "none"
  # Configure the backend to use.
  calico_backend: "vxlan"

livenessProbe:
  exec:
    command:
    - /bin/calico-node
    - -felix-live
    # - -bird-live
  readinessProbe:
    exec:
      command:
      - /bin/calico-node
      # - -bird-ready
      - -felix-ready

将环境变量CALICO_IPV4POOL_IPIP的值设置为Cross-SubNet（不区分大小写）来启用混合网络模型，它将启用BGP路由网络，且仅会在跨节点子网的流量间启用隧道封装。

# 设置在IPv4类型的地址池上启用的IP-IP及其类型，支持3种可用值
# Always（全局流量）、Cross-SubNet（跨子网流量）和Never
- name: CALICO_IPV4POOL_IPIP
  value: "Always"
# 是否在IPV4地址池上启用VXLAN隧道协议，取值及意义与Flannel的VXLAN后端相同，
# 但在全局流量启用VXLAN时将完全不再需要BGP网络，建议将相关的组件禁用
- name: CALICO_IPV4POOL_VXLAN
  value: "Never"

不确定网络模式，可以选择几乎可以在任何环境中以VXLAN + Cross-subnet(跨子网)模式运行Calico 网络模式。

1. IP in IP 仅支持 IPv4 地址
2. IPv6 中的 VXLAN 仅支持内核版本 >=4.19.1 或 redhat 内核版本 >=4.18.0

Calico 将有关集群的操作和配置状态的数据存储在中央数据存储中。如果数据存储不可用，您的 Calico 网络将继续运行，但无法更新（新 Pod 无法联网，无法应用策略更改等）。

Calico 有两个数据存储驱动程序可供选择

  etcdv3 - 使用 etcdv3 集群作为Dabastore
  Kubernetes - 使用 Kubernetes API 作为Dabastore

1. 不需要额外的数据存储，因此更易于管理
2. 使用 Kubernetes RBAC 来控制对 Calico 资源的访问
3. 使用 Kubernetes 审核日志记录来生成 Calico 资源更改的审核日志

1. 可以在非 Kubernetes 平台（例如 OpenStack）上运行 Calico
2. 可以解耦 Kubernetes 和 Calico 资源，例如允许您独立扩展数据存储
3. 可以运行包含多个 Kubernetes 集群的 Calico 集群，例如带有 Calico 主机保护的裸机服务器与 Kubernetes 集群联动；或多个 Kubernetes 集群。

# wget https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/crds.yaml

# kubectl apply -f crds.yaml

可以直接使用kubectl管理Calico资源。

Felix 是运行于各节点上守护进程程，它主要负责完成接口管理、路由规划、ACL规划和状态报告几个核心任务，从而为各端点（VM或Container）生成连接机制。

负责创建网络接口、生成必要信息并送往内核，以确保内核能正确处理各端点的流量，尤其是要确保目标节点MAC能响应当前节点上各工作负载的MAC地址的ARP请求，以及为Felix管理的接口打开转发功能。另外，接口管理还要监控各接口的变动以确保规则能得到正确应用。

负责为当前节点上运行的各端点在内核FIB（Forwarding Information Base）中生成路由信息，以保证到达当前节点的报文可正确转发给端点。

负责在Linux内核中生成ACL，实现仅放行端点间的合规流量，并确保流量不能绕过Calico等安全措施。

负责提供网络健康状态的相关数据，尤其是报告由Felix管理的节点上的错误和问题。这些报告数据会存储在etcd，供其他组件或网络管理员使用。

从Felix获取路由，并将其分发到网络上的BGP对等点以进行主机间路由。在承载Felix代理的每个节点上运行。BGP守护程序。BGP客户端负责：路由规划和BGP路由反射器。

当Felix将路由插入到Linux内核FIB中时，BGP客户端会将它们分发到部署中的其他节点。这确保了部署的有效流量路由。

Calico在每一个计算节点利用Linux内核实现了一个高效的vRouter（虚拟路由器）进行报文转发。每个vRouter通过BGP协议将自身所属节点运行的Pod资源的IP地址信息，基于节点上的专用代理程序（Felix）生成路由规则向整个Calico网络内传播。尽管小规模部署能够直接使用BGP网格模型，但随着节点数量（假设为N）的增加，这些连接的数量就会以N2的规模快速增长，从而给集群网络带来巨大的压力。因此，一般建议大规模的节点网络使用BGP路由反射器进行路由学习，BGP的点到点通信也就转为与中心点的单路通信模型。另外，出于冗余考虑，生产实践中应该部署多个BGP路由反射器。而对于Calico来说，BGP客户端程序除了作为客户端使用外，也可以配置为路由反射器。

监控Calico数据存储对BGP配置和全局默认值（如as号、日志记录级别和IPAM信息）的更改。开源、轻量级的配置管理工具。
Confd根据数据存储中数据的更新动态生成BIRD配置文件。当配置文件发生更改时，confd会触发BIRD来加载新文件。

强制执行Istio服务网格的网络策略。作为Istio Envoy的sidecar代理在集群上运行。

Dikaste可以通过向使用环境变量DIKASTES_HTTP_BIND_ADDR和DIKASTES_HTTP_BIND_PORT指定的套接字地址发出HTTP POST请求来终止。这是为了允许优雅的终止，以便Kubernetes Jobs能够成功完成，类似于Envoy的/quitquitquit。例如 curl -X POST http://127.0.0.1:7777/terminate

Kubernetes 如何为 Pod 分配 IP 地址由所使用的 IPAM（IP 地址管理）插件决定。

Calico IPAM插件根据需要动态地将小块 IP 地址分配给节点，以有效地整体利用可用的 IP 地址空间。此外，Calico IPAM 支持高级功能，例如多个 IP 池、指定命名空间或 Pod 应使用的特定 IP 地址范围的能力，甚至是 Pod 应使用的特定 IP 地址。

监控Kubernetes API并根据集群状态执行操作。

该 tigera/kube-controllers 包括以下控制：
  Policy controller
  Namespace controller
  Serviceaccount controller
  Workloadendpoint controller
  Node controller

通过减少每个节点对数据存储的影响来增加规模。作为守护进程在数据存储和Felix实例之间运行。默认情况下已安装，但未配置。

Typha代表其所有客户端（如Felix和confd）维护单个数据存储连接。它缓存数据存储状态并消除重复数据事件，以便将它们分散到许多侦听器。因为一个Typha实例可以支持数百个Felix实例，所以它大大降低了数据存储的负载。因为Typha可以过滤掉与Felix无关的更新，它也减少了Felix的CPU使用量。在高规模（100+节点）的Kubernetes集群中，这一点至关重要，因为API服务器生成的更新数量会随着节点数量的增加而增加。

创建、读取、更新和删除Calico对象的命令行界面。calicoctl命令行可在任何以二进制或容器形式对Calico数据存储进行网络访问的主机上使用。需要单独安装。

将用于管理网络的 Orchestrator API 转换为 Calico 数据模型和数据存储。

对于云提供商来说，Calico 为每个主要的云编排平台提供了单独的插件。这使得 Calico 能够与编排器紧密绑定，因此用户可以使用其编排器工具来管理 Calico 网络。需要时，编排器插件会从 Calico 网络向编排器提供反馈。例如，提供有关 Felix 活跃度的信息，并在网络设置失败时将特定端点标记为失败。