Calico ¶

Calico 是一款开源网络和网络安全解决方案，适用于容器、虚拟机和本地主机工作负载。

Calico 将灵活的网络功能与随处可用的安全执行结合在一起，提供了一种具有原生 Linux 内核性能和真正云原生可扩展性的解决方案。Calico 为开发人员和集群运营商提供了始终如一的用户体验和功能集，无论是在公有云还是本地部署，无论是在单节点还是跨数千节点的集群上。

安装 ¶

要使用 Calico，请在集群规范中指定以下内容。

  networking:
    calico: {}

以下命令使用 Calico 设置集群。

export ZONES=mylistofzones
kops create cluster \
  --zones $ZONES \
  --networking calico \
  --yes \
  --name myclustername.mydns.io

配置 ¶

选择封装模式（仅限 IPv4） ¶

在 IPv6 集群中，kOps 配置（并要求）Calico 不使用封装。

在 IPv4 集群中，为了将网络流量发送到和从 Kubernetes pod，Calico 可以使用两种网络封装模式之一：IP-in-IP 或 VXLAN。尽管 IP-in-IP 封装在每个数据包中使用的开销字节少于 VXLAN 封装，但在与 Calico 的 eBPF 数据平面配合使用时，VXLAN 可能是一个更好的选择。特别是，eBPF 程序可以在二层设备之间重定向数据包，但不能在二层设备和三层设备之间重定向数据包，如使用 IP-in-IP 隧道所必需的。

默认情况下，kOps 使用 IP-in-IP 封装模式；这是 Calico 项目的默认选择。这等效于在集群规范中写入以下内容

  networking:
    calico:
      encapsulationMode: ipip

要改为使用 VXLAN 封装模式，请在集群规范中添加以下内容

  networking:
    calico:
      encapsulationMode: vxlan

从 Calico 3.17 版本开始，为了使用 IP-in-IP 封装，Calico 必须使用其 BIRD 网络后端。这会在每个“calico-node”容器中运行 BIRD BGP 守护程序，以便将路由分发到每台机器。使用 BIRD 后端，Calico 可以使用 IP-in-IP 或 VXLAN 封装在机器之间。目前，IP-in-IP 封装需要使用 BGP 维护路由，而 VXLAN 封装则不需要。相反，使用 VXLAN 后端，Calico 不会运行 BIRD 守护程序，也不会使用 BGP 维护路由。这排除了使用 IP-in-IP 封装，只允许 VXLAN 封装。Calico 可能会在将来消除对 IP-in-IP 封装使用 BGP 的需求。

配置跨子网模式（仅限 IPv4） ¶

在 IPv4 集群中，Calico 支持其 IP-in-IP 和 VXLAN 封装模式的两种选择，其中仅当流量的目标是缺少 Calico 路由感知的中间基础设施的子网时才进行封装，例如，跨异构公有云或在 AWS 上跨可用区时。

使用此模式，封装仅选择性地执行。这在 AWS 多 AZ 部署或跨单个 AZ 内的多个 VPC 子网的部署中提供了更好的性能，以及在一般情况下，在具有 L2 连接的节点池通过路由器连接的网络上部署时提供了更好的性能。

请注意，在使用 Calico 时（使用其 BIRD 网络后端时）—— 同一子网内的节点之间的路由是使用完整的节点到节点 BGP 网状网络分发的。每个节点都会自动与同一 L2 网络中的所有其他节点建立 BGP 对等关系。这种每 L2 网络的完整节点到节点网状网络对于大规模部署来说具有其扩展挑战。BGP 路由反射器可以用作完整网状网络的替代方案，对于扩展集群很有用。一旦节点数量超过约 50-100 个，建议使用 BGP 路由反射器。目前，BGP 路由反射器的设置超出了 kOps 的范围。

在此处阅读更多内容：BGP 路由反射器

在 AWS 的情况下，EC2 实例的 ENI 默认情况下启用了源/目标检查。当 kOps 1.19+ 中启用跨子网模式时，它等效于以下两种情况之一：

  networking:
    calico:
      awsSrcDstCheck: Disable
      IPIPMode: CrossSubnet

或

  networking:
    calico:
      awsSrcDstCheck: Disable
      encapsulationMode: vxlan

取决于您选择的封装模式。

**kOps 1.22+ 中的跨子网模式是默认模式**，适用于 IP-in-IP 和 VXLAN 封装。可以通过设置 ipipMode、vxlanMode 和 awsSrcDstCheck 选项来禁用或调整它。

在 AWS 中，将向所有节点添加一个 IAM 策略，以允许 Calico 执行 ec2:DescribeInstances 和 ec2:ModifyNetworkInterfaceAttribute，这是当 awsSrcDstCheck 设置时所需的。对于旧版本的 kOps，将部署一个附加组件控制器（k8s-ec2-srcdst）作为 Pod（将调度到控制平面节点之一）以促进禁用源/目标地址检查。只有控制平面节点具有 IAM 策略，以允许 k8s-ec2-srcdst 执行 ec2:ModifyInstanceAttribute。

配置 Calico MTU ¶

Calico MTU 可以通过在 Calico 配置中设置 mtu 字段来配置。如果保留其默认空值，Calico 将检查网络设备并自动选择合适的 MTU 值。如果您决定覆盖此自动调整，请为 mtu 字段指定一个正值。在 AWS 中，VPC 支持大小为 9,001 的巨型帧，因此推荐的 Calico MTU 选择是 IP-in-IP 封装为 8,981，VXLAN 封装为 8,951，WireGuard 为 8,941，在每种情况下都减去封装格式的适当开销。

spec:
  networking:
    calico:
      mtu: 8981

配置 Calico 使用 Typha ¶

从 kOps 1.12 版本开始，Calico 使用 kube-apiserver 作为其数据存储。默认设置不使用 Typha——旨在降低 Calico 对 Kubernetes API 服务器影响的组件，该组件建议在超过 50 个节点的集群中使用，并且强烈建议在 100 个以上节点的集群中使用。可以通过编辑集群并将 typhaReplicas 字段添加到 Calico 规范中并赋予其一个正值来配置 Calico 使用 Typha

  networking:
    calico:
      typhaReplicas: 3

配置 eBPF 数据平面 ¶

介绍	最小 K8s 版本
kOps 1.19	k8s 1.16

Calico 支持使用 eBPF 数据平面作为标准 Linux 数据平面（基于 iptables）的替代方案。虽然标准数据平面侧重于兼容性，它依赖于 kube-proxy 和您自己的 iptables 规则，但 eBPF 数据平面则侧重于性能、延迟和通过标准数据平面无法实现的功能来改善用户体验。作为其中的一部分，eBPF 数据平面使用 eBPF 实现替换 kube-proxy。主要“用户体验”功能是当流量到达节点端口时保留来自集群外部的流量的源 IP 地址；这使得服务器端日志和网络策略在该路径上更有用。

有关启用 eBPF 数据平面的更多详细信息，请参阅 Calico 文档。

在 kOps 中启用 eBPF 数据平面 - 同时禁用 kube-proxy 的使用 - 如下所示

  kubeProxy:
    enabled: false
  networking:
    calico:
      bpfEnabled: true

您可以使用其他选项进一步调整 Calico 的 eBPF 数据平面，例如启用 DSR 模式以消除节点端口流量中的网络跳跃（仅在您的集群符合某些限制时可行）或提高 Calico 的 eBPF 程序的日志详细程度

  kubeProxy:
    enabled: false
  networking:
    calico:
      bpfEnabled: true
      bpfExternalServiceMode: DSR
      bpfLogLevel: Debug

注意：在现有集群中切换到或从 Calico 的 eBPF 数据平面是具有破坏性的。 kOps 今天无法自动协调这种转换。

配置 WireGuard（仅 IPv4） ¶

介绍	最小 K8s 版本
kOps 1.19	k8s 1.16

在 IPv4 集群中，Calico 支持 WireGuard 对 Pod 到 Pod 的流量进行加密。如果您启用此选项，WireGuard 加密将自动为所有节点启用。目前，kops 仅在主机操作系统为 Ubuntu 时才自动安装 WireGuard。对于其他操作系统，WireGuard 必须是基本映像的一部分或通过挂钩安装。

有关 Calico WireGuard 的更多详细信息，请参阅 Calico 文档。

  networking:
    calico:
      wireguardEnabled: true

获取帮助 ¶

如需获取有关 Calico 的帮助或报告任何问题，请访问：* Calico Github * Calico 用户 Slack

有关 Calico 可用选项的更多一般信息，请参见官方 Calico 文档：* 请参见 Calico 网络策略，了解 Kubernetes 网络策略中不可用的其他功能的详细信息。 * 请参见确定最佳 Calico 网络选项，了解有关 Calico 可用网络选项的帮助。

故障排除 ¶

新节点需要几分钟才能同步 IP 路由，并且它们上的新 Pod 无法访问 kubedns ¶

这是因为 Calico etcd 节点存储中不再存在节点。由于 AWS EC2 实例的短暂性，新的节点会使用不同的主机名启动，并且下线的节点会保留在 Calico 节点存储中。这与大多数数据中心部署不同，在数据中心部署中，主机名在集群中通常是静态的。阅读此问题以获取更多详细信息。

这个问题已在 kOps 1.9.0 中得到解决，在创建新的集群时无需采取任何操作，但如果使用之前的 kOps 版本创建了集群，则应执行以下操作

使用 kOps 更新集群 kops update cluster <name> --yes 并等待 calico-kube-controllers 部署和 calico-node daemonset pod 更新
停用所有无效节点，请参阅此处
此操作后从集群中删除的所有节点都应从 Calico 的 etcd 存储中清除，并且延迟编程路由问题应得到解决。