标签：插件 Kubernetes 网络 节点 BGP Calico 路由

Calico网络插件

  Calico 是一个开源网络和网络安全解决方案，适用于容器、虚拟机和基于本地主机的工作负载。Calico 支持广泛的平台，包括 Kubernetes、OpenShift、Mirantis Kubernetes Engine (MKE)、OpenStack 和裸机服务。（官网翻译：https://projectcalico.docs.tigera.io/about/about-calico）

  无论您选择使用 Calico 的 eBPF 数据平面还是 Linux 的标准网络管道，Calico 都能提供超快的性能和真正的云原生可扩展性。Calico 为开发人员和集群运营商提供一致的体验和一组功能，无论是在公共云或本地、单个节点上还是跨数千个节点的集群上运行。（官网翻译：https://projectcalico.docs.tigera.io/about/about-calico）

  Calico本身是一个三层的虚拟网络方案，它将每个节点都当作路由器（router），将每个节点的容器都当作是“节点路由器”的一个终端并为其分配一个IP地址，各节点路由器通过BGP（Border Gateway Protocol）学习生成路由规则，从而将不同节点上的容器连接起来。因此，Calico方案其实是一个纯三层的解决方案，通过每个节点协议栈的三层（网络层）确保容器之间的连通性，这摆脱了flannel host-gw类型的所有节点必须位于同一二层网络的限制，从而极大地扩展了网络规模和网络边界。

一、Calico工作特性

  Calico 利用 Linux 内核在每一个计算节点上实现了一个高效的 vRouter（虚拟路由器）进行报文转发，而每个 vRouter(虚拟路由器) 都通过 BGP 负责把自身所属的节点上运行的 Pod 资源的 IP 地址信息基于节点的 agent 程序（Felix）直接由 vRouter 生成路由规则向整个 Calico 网络内进行传播。小规模部署可以直接互联，大规模建议使用 BPP 路由反射器（router reflector）来完成。Felix 也支持在每个节点上按需生成 ACL(Access Control List)从而实现安全策略，如隔离不同的租户或项目的网络通信。vRouter 利用 BGP 通告本节点上现有的地址分配信息，每个 vRouter 均接入 BGP 路由反射器以实现控制平面扩展。

  Calico承载的各Pod资源直接通过vRouter经由基础网络进行互联，它非叠加、无隧道、不使用VRF表，也不依赖于NAT，因此每个工作负载都可以直接配置使用公网IP接入互联网，当然，也可以按需使用网络策略控制它的网络连通性。

1.1）经过 IP 路由直连

  Calico 中，Pod 收发的 IP 报文由所在节点的 Linux 内核路由表负责转发，并通过 iptables 规则实现其安全功能。

  某 Pod 对象发送报文时，Calico 应确保节点总是作为下一跳 MAC 地址返回，不管工作负载本身可能配置什么路由，而发往某 Pod 对象的报文，其最后一个 IP 跃点就是 Pod 所在的节点。也就是说，报文的最后一程即由节点发网目标 Pod 对象，如下图所示：

  需为某 Pod 对象提供连接时，系统上的专用插件（如 Kubernetes 的 CNI）负责将需求通知给 Calico Agent。收到消息后，Calico Agent 会为每个工作负载添加直接路径信息到工作负载的 TAP 设备（如 veth）。而运行于当前节点的 BGP 客户端监控到此类消息后会调用路由 reflector 向工作于其他节点的 BGP 客户端进行通告。

1.2）简单、高效、易扩展

  Calico未使用额外的报文封装和解封装，从而简化了网络拓扑，这也是Calico高性能、易扩展的关键因素。毕竟，小的报文减少了报文分片的可能性，而且较少的封装和解封装操作也降低了对CPU的占用。此外，较少的封装也易于实现报文分析，易于进行故障排查。

  创建、移动或删除Pod对象时，相关路由信息的通告速度也是影响其扩展性的一个重要因素。Calico出色的扩展性缘于与互联网架构设计原则别无二致的方式，它们都使用了BGP作为控制平面。BGP以高效管理百万级的路由设备而闻名于世，Calico自然可以游刃有余地适配大型IDC网络规模。另外，由于Calico各工作负载使用基IP直接进行互联，因此它还支持多个跨地域的IDC之间进行协同。

1.3）较好的安全性

  原则上，Calico 网络允许 IDC 中的任何工作负载与其他任意目标进行通信，但管理员或用户却未必期望如此，在多租户 IDC 中隔离租户挽留过几乎是必需之需。于是，Calico 操纵节点上的 iptables 规则以管控工作负载的互联许可。此种 iptables 规则操纵功能是节点间的警戒哨，负责阻挡任何非许可流量，并防止通过工作负载危及自身。

• • 严格的域间流量分隔: 运行于某个租户虚拟网络内的应用应严禁访问其他租户的应用，这种流量分隔是由久经考验的 Linux 内核中的 ACL 子系统予以实现的。
  • 精细的策略规则: 实现了租户间隔离的网络方案大多并没有额外实现细粒度的安全策略，而 Calico 通过使用 Linux 内建的 ACL 扩展来支持一众安全规则，任何可由 ACL 支持的功能均能通过 Calico 实现。
  • 简洁而不简单: Calico 直接使用个 IP 网络，无须任何地址转换或隧道承载的机制实现了一个简洁的 "WYSIWYG"(what you see is what you get)网络模型，它可以清晰地标识出每个报文从哪儿来，到哪儿去。于是，管理员可因此而清晰地理解流量的来去。

二、Calico 系统架构

  概括来说，Calico 主要由 Felix、Orchestrator Plugin、etcd、BIRD 和 BGP Router Reflector 等组件组成，其组件架构如下图所示：

• • Felix: Calico Agen，运行于每个节点。主要负责网络接口管理和监听、路由、ARP 管理、ACL管理和同步、状态上报等。
  • Orchestrator Plugin: 编排系统（如 k8s、openstack等）以将 Calico 整合进系统中的插件，例如 k8s 的 CNI。
  • etcd：持久存储 Calico 数据的存储管理系统。分布式键值存储，主要负责网络元数据一致性，确保 Calico 网络状态的准确性，可以与 Kubernetes 共用。
  • BIRD：用于分发路由信息的 BGP 客户端。Calico 可以为每一台节点部署一个 BGP Client，使用 BIRD 实现，BIRD 是一个单独的持续发展项目，实现了众多动态路由协议比如 BGP、OSPF、RIP 等。在 Calico 的角色是监听 节点上由 Felix 注入的路由信息 ，然后通过 BGP 协议广播告诉剩余节点，从而实现网络互通。
  • BGP Route Reflector：BGP 路由反射器，可选组件，用于较大规模的网络场景。在大型网络规模中，如果仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制，因为所有节点之间俩俩互联，需要 N^2 个连接，为了解决这个规模问题，可以采用 BGP 的 Router Reflector 的方法，使所有 BGP Client 仅与特定 RR 节点互联并做路由同步，从而大大减少连接数。

2.1）Felix

  Felix 运行于各节点的用于支持端点（VM或Container）构建的守护进程，它负责生成路由和ACL，以及其他任何由节点用到的信息，从而为各端点构建连接机制。Felix在各编排系统中主要负责以下任务:

1. 1. 首先是接口管理（Interface Management）功能，负责为接口生成必要的信息并送往内核，以确保内核能够正确处理各端点的流量，尤其是要确保各节点能够响应目标MAC为当前节点上各工作负载的MAC地址的ARP请求，以及为其管理的接口打开转发功能。另外，它还要监控各接口的变动以确保规则能够得到正确的应用。
   2. 其次是路由规划（Route Programming）功能，其负责为当前节点运行的各端点在内核FIB（Forwarding Information Base）中生成路由信息，以保证到达当前节点的报文可正确转发给端点。
   3. 再次是ACL规划（ACL Programming）功能，负责在Linux内核中生成ACL，用于实现仅放行端点间的合法流量，并确保流量不能绕过Calico的安全措施。
   4. 最后是状态报告（State Reporting）功能，负责提供网络健康状态的相关数据，尤其是报告由其管理的节点上的错误和问题。这些报告数据会存储于etcd，供其他组件或网络管理员使用。

2.2）容器系统插件

  编排系统插件（Orchestrator Plugin）依赖于编排系统自身的实现，故此并不存在一个固定的插件以代表此组件。编排系统插件的主要功能是将Calico整合进系统中，并让管理员和用户能够使用Calico的网络功能。它主要负责完成API的转换和反馈输出。

  编排系统通常有其自身的网络管理API，网络插件需要负责将对这些API的调用转为Calico的数据模型并存储于Calico的存储系统中。如果有必要，网络插件还要将Calico系统的信息反馈给编排系统，如Felix的存活状态，网络发生错误时设定相应的端点为故障等。

2.3）etcd 存储系统

  Calico 使用 etcd 完成组件间的通信，并以之作为一个持久数据存储系统。根据编排系统的不同，etcd 所扮演角色的重要性也因之而异，但它贯穿了整个 Calico 部署全程，并被分为两类主机：

• • • 核心集群
    • 代理（proxy）

  在每个运行着 Felix 或编排系统插件的主机上都应该运行一个 etcd 代理以降低 etcd 集群和集群边缘节点的压力。此模式中，每个运行着插件的节点都会运行着 etcd 集群的一个成员节点。

  etcd 是一个分布式、强一致、具有容错功能的存储系统，这一点有助于将Calico网络实现为一个状态确切的系统：要么正常，要么发生故障。另外，分布式存储易于通过扩展应对访问压力的提升，而避免成为系统瓶颈。另外，etcd也是Calico各组件的通信总线，可用于确保让非etcd组件在键空间（keyspace）中监控某些特定的键，以确保它们能够看到所做的任何更改，从而使它们能够及时地响应这些更改。

2.4）BGP客户端（BIRD）

  Calico 要求在每个运行着 Felix 的节点上同时还要运行一个 BGP 客户端，负责将 Felix 生成的路由信息载入内核并通告到整个IDC。在 Calico 语境中，此组件是通用的 BIRD，因此任何 BGP 客户端（如GoBGP等）都可以从内核中提取路由并对其分发对于它们来说都适合的角色。

  BGP 客户端的核心功能就是路由分发，在 Felix 插入路由信息至内核 FIB 中时，BGP 客户端会捕获这些信息并将其分发至其他节点，从而确保了流量的高效路由。

2.5）BGP路由反射器（BIRD）

  在大规模的部署场景中，简易版的BGP客户端易于成为性能瓶颈，因为它要求每个BGP客户端都必须连接至其同一网络中的其他所有BGP客户端以传递路由信息，一个有着N个节点的部署环境中，其存在网络连接的数量为N的二次方，随着N值的逐渐增大，其连接复杂度会急剧上升。因而在较大规模的部署场景中，Calico应该选择部署一个BGP路由反射器，它是由BGP客户端连接的中心点，BGP的点到点通信也就因此转化为与中心点的单路通信模型。出于冗余之需，生产实践中应该部署多个BGP路由反射器。对于Calico来说，BGP客户端程序除了作为客户端使用之外，还可以配置成路由反射器。

 三、Calico 部署要点

  安装 Calico 需要事先有运行中的 Kubernetes 1.1 及以上版本的集群，如果要用到网络策略，则 Kubernetes 版本需要 1.3.0 及以上才可以。另外，还需要一个可由 Kubernetes 集群各节点访问到的 etcd 集群。虽然可以让 Calico 和 Kubernetes 共同使用一个 etcd 集群，然而有些场景中推荐为 etcd 使用集群，如需要获得较好的性能时：

  与 Kubernetes 集群进行整合时，Calico 需要提供三个组件，具体如下：

• calico/node: Calico 于 Kubernetes 集群中为每个节点上运行的容器提供 Felix Agent 和 BGP 客户端。
• cni-plugin: CNI 网络插件，用于整合 Calico 和 kubelet，发现 Pod 资源，并将其添加进 Calico 网络，因此，每个运行 kubelet 的主机都需要配置。
• calico/kube-controller: Calico 网络策略控制器。

  Calico 的安装有两种方式：

1. 配置其独立运行于 Kubernetes 集群之外，但 Calico/kube-controller 依然需要安装以 Pod 资源运行于集群之上。
2. 以插件方式配置 Calico 完全托管运行于 Kubernetes 集群之上，不过此种方式运行要求 Kubernetes 版本至少在 1.4.0 以上。
1. 标准托管部署，即 Calico 使用专用的 etcd 存储管理数据持久化及组件间的通信。
2. 以 Kubernetes API Server 为 Datastore，调用 Kubernetes 的 API 完成所需的操作。（自 3.0 版本起，Calico 官方推荐这种方式）

  Calico 既可以单独为 Kubernets 系统提供网络服务及网络策略，也可以与 flannel 整合在一起由 flannel 实现网络服务而 Calico 仅提供网络策略。事实上，还有一个本身即是将 flannel 或 Calico 合二为一的解决方案 Canal，不过，这已经是另外一个独立的项目了。

  Calico 分配的地址池与 Kubernetes 集群的 --pod-network-cidr 的值应该保持一致，默认情况下，Calico 的配置清单中使用 192.168.0.0/16 作为 Pod 网络。不过，如果用户计划将 Calico 和 flannel 协同进行部署，则可以在此之前将已有 flannel 插件才对基础上直接添加 Calico。(后面独立部署 Calico 的同时提供网络服务及网络策略，协同 flannel 的部署方式时再详细讲这个。)

四、Calico原理、网络工作模式和性能压测

  Calico 是一个纯三层的网络插件，calico 的 bgp 模式类似于 flannel 的 host-gw。

4.1）Calico基本原理

  calico是一个纯三层的虚拟网络，它没有复用docker的docker0网桥，而是自己实现的， calico网络不对数据包进行额外封装，不需要NAT和端口映射，扩展性和性能都很好。Calico网络提供了DockerDNS服务， 容器之间可以通过hostname访问，Calico在每一个计算节点利用LinuxKernel实现了一个高效的vRouter（虚拟路由）来负责数据转发，它会为每个容器分配一个ip，每个节点都是路由，把不同host的容器连接起来，从而实现跨主机间容器通信。而每个vRouter通过BGP协议（边界网关协议）负责把自己节点的路由信息向整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGProute reflector来完成；Calico基于iptables还提供了丰富而灵活的网络策略，保证通过各个节点上的ACLs来提供多租户隔离、安全组以及其他可达性限制等功能。

4.2）BGP模式

  BGP（Border Gateway Protocol）即边界网关协议，是互联网上一个核心的去中心化自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统（AS）之间的可达性，属于矢量路由协议。BGP不使用传统的内部网关协议（IGP）的指标，而使用基于路径、网络策略或规则集来决定路由。因此，它更适合被称为矢量性协议，而不是路由协议。

  BGP是为了取代外部网关协议（EGP）协议而创建的，允许运行一个完全分散的路由系统，从ARPANET模型的核心路由系统过渡到包括NSFNET骨干网及其相关区域网络的分散系统。这使得互联网成为一个真正的分权制度。自1994年以来，BGP已有四个版本在互联网上使用，所有以前的版本现在已经过时不可用。在第4版主要的增强功能是通过支持无类别域间路由和路由聚合来减少路由表的大小。第4版是在早期的RFC 1771第4版的基础上编纂，通过20多个草案修改，最终在2006年1月通过形成RFC 4271。RFC 4271版本纠正了一些错误，澄清模糊之处，带来了更接近工业级应用标准的RFC行业惯例。

  大多数互联网服务提供商（ISP）必须使用BGP来与其他ISP建立路由连接（尤其是当它们采取多宿主连接时）。因此，即使大多数互联网用户不直接使用它，但是与7号信令系统（SS7）相比，即通过PSTN的跨供应商核心响应设置协议，BGP仍然是互联网最重要的协议之一。特大型的私有IP网络也可以使用BGP。例如当需要将若干个大型的开放最短路径优先（OSPF）网络进行合并，而开放最短路径优先协议本身又无法提供这种可扩展性时。使用BGP的另一个原因是其能为多宿主的单个ISP（RFC 1998）或多个ISP网络提供更好的冗余网络。

4.3）IPIP模式（默认模式）

  把一个IP数据包又套在一个IP包里，即把IP层封装到IP层的一个 tunnel，它的作用其实基本上就相当于一个基于IP层的网桥，一般来说，普通的网桥是基于mac层的，根本不需要IP，而这个ipip则是通过两端的路由做一个tunnel，把两个本来不通的网络通过点对点连接起来；

  calico以ipip模式部署完毕后，node上会有一个tunl0的网卡设备，这是ipip做隧道封装用的,也是一种overlay模式的网络。当我们把节点下线，calico容器都停止后，这个设备依然还在，执行 rmmodipip命令可以将它删除。

4.4）性能压测（pod-to-pod、pod-to-node、node-to-node）

ping延迟：用 ping 测试 hosts 之间和 pods 之间的延迟。

带宽测试：用 iperf 测试 hosts 之间和 pods 之间的带宽。

HTTP性能压测：部署一个 nginx-server 并使用 ab命令 压测。

五、部署 Calico 提供网络服务和网络策略（Calico Version 3.23、date-time: Tue Jul  5 22:18:55 CST 2022 ）

  为了便于简化部署环境及操作复杂度，以一个示例介绍，部署时 --pod-network-cidr 选项指定了使用 192.168.0.0/16 网络以适配 Calico 的默认网络配置。Calico 的部署方式极其灵活，这里难以详细的把所有的都说明白，只能以具体的场景对其加以说明。

  Calico 部署极其灵活，同时不同版本的 Calico 部署方式不同，需要根据不同版本/不同架构方案来选择不同的部署方式，这里我尽量以官方文档，来确定具体的部署方案和部署步骤。

5.1）官方推荐部署 Calico 的几种方式

以下是 Calico 官方推荐的安装场景的安装方式（https://projectcalico.docs.tigera.io/getting-started/kubernetes/）：

• • Quickstart：Install Calico on a single-host Kubernetes cluster for testing or development in under 15 minutes.
  • Managed public cloud：Enable Calico on EKS, GKE, AKS, or IKS.
  • Self-managed public cloud：Manage your own Kubernetes clusters in AWS, GCE, or Azure public clouds.
  • Self-managed on-premises：Install Calico for on-premises deployments to provide networking and network policy, in either overlay or non-overlay networking modes.
  • OpenShift：Install Calico on OpenShift for networking and network policy.
  • Rancher Kubernetes Engine：Install Calico on a Rancher Kubernetes Engine cluster.
  • Flannel：Use Calico network policy on top of flannel networking.
  • Calico for Windows：Install and configure Calico for Windows.
  • K3s：Get Calico up and running in your K3s cluster.
  • Install with Helm 3：Install Calico on a Kubernetes cluster using Helm 3.
  • MicroK8s：Install Calico on a single-host MicroK8s cluster for testing or development in under 5 minutes.
  • Minikube：Enable Calico on a single/multi-node minikube cluster for testing or development in under 1 minute.
  • Calico the hard way：Up for the challenge? Calico the hard way takes you under the covers of an end-to-end Calico installation.
  • System requirements：Review requirements before installing Calico to ensure success.
  • VPP dataplane：Install the VPP userspace dataplane to unlock extra performance for your cluster!

5.2）Quickstart：Quickstart for Calico on Kubernetes（第一种部署 Calico方式）

官方文档：https://projectcalico.docs.tigera.io/getting-started/kubernetes/quickstart

• • 5.2.1）环境准备（Befor you begin）

• • • Make sure you have a linux host that meets the following requirements:

• • • • x86-64, arm64, ppc64le, or s390x processor
      • 2CPU
      • 2GB RAM
      • 10GB free disk space
      • RedHat Enterprise Linux 7.x+, CentOS 7.x+, Ubuntu 16.04+, or Debian 9.x+

• • Ensure that Calico can manage cali and tunl interfaces on the host. If NetworkManager is present on the host, refer to Configure NetworkManager.

• 5.2.2）Quickstart for Calico on Kubernetes，go，go，go！（创建一个单机 Kubernets 集群）

• 5.2.2.1）Follow the Kubernetes instructions to install kubeadm.

  安装过程略过，想看的可以点击链接跳转过去：https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
  注意: 安装 kubeadm 后，不要关机或重新启动主机，而是直接进入下一步。

• 5.2.2.2）As a regular user with sudo privileges, open a terminal on the host that you installed kubeadm on.

  作为拥有 sudo 特权的普通用户，在安装 kubeadm 的主机上打开一个终端。

• 5.2.2.3）Initialize the master using the following command.

  sudo kubeadm init --pod-network-cidr=192.168.0.0/16
  

  Note: If 192.168.0.0/16 is already in use within your network you must select a different pod network CIDR, replacing 192.168.0.0/16 in the above command.

• 5.2.2.4）Execute the following commands to configure kubectl (also returned by kubeadm init).

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

• • 5.2.3）安装 Calico

• • 5.2.3.1）Install the Tigera Calico operator and custom resource definitions.

    kubectl create -f https://projectcalico.docs.tigera.io/manifests/tigera-operator.yaml

  •  5.2.3.2）Install Calico by creating the necessary custom resource. For more information on configuration options available in this manifest, see the installation reference.

    kubectl create -f https://projectcalico.docs.tigera.io/manifests/custom-resources.yaml

    注意: 在创建此清单之前，请阅读其内容并确保其设置对于您的环境是正确的。例如，您可能需要更改默认 IP 池 CIDR 以匹配您的 pod 网络 CIDR。

  • 5.2.3.3）Confirm that all of the pods are running with the following command.

    watch kubectl get pods -n calico-system
    

      Wait until each pod has the STATUS of Running.

    Note: The Tigera operator installs resources in the calico-system namespace. Other install methods may use the kube-system namespace instead.

  • 5.2.3.4）Remove the taints on the master so that you can schedule pods on it.

    kubectl taint nodes --all node-role.kubernetes.io/master-

      It should return the following.

    node/<your-hostname> untainted

  • 5.2.3.5）Confirm that you now have a node in your cluster with the following command.

    kubectl get nodes -o wide

      It should return something like the following.

    NAME              STATUS   ROLES    AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
    <your-hostname>   Ready    master   52m   v1.12.2   10.128.0.28   <none>        Ubuntu 18.04.1 LTS   4.15.0-1023-gcp   docker://18.6.1

  • 5.2.3.6）Congratulations! You now have a single-host Kubernetes cluster with Calico.（安装成功了！）

5.4）Install with Helm 3（第二种部署 Calico方式）

官方文档：https://projectcalico.docs.tigera.io/getting-started/kubernetes/helm

• • 5.4.1）环境准备（Befor  you begin）

Install Helm 3

Kubernetes cluster meets these requirements:

• • • • • Kubernetes is installed without a CNI plugin OR cluster is running a compatible CNI for Calico to run in policy-only mode
        • x86-64, arm64, ppc64le, or s390x processors
        • RedHat Enterprise Linux 7.x+, CentOS 7.x+, Ubuntu 16.04+, or Debian 9.x+

kubeconfig is configured to work with your cluster (check by running kubectl get nodes)

Calico can manage cali and tunl interfaces on the hosts. If NetworkManager is present on the hosts, refer to Configure NetworkManager.

• • 5.4.2）helm install Calico，go，go，go!

    • 5.4.2.1）Download the Helm char

      helm repo add projectcalico https://projectcalico.docs.tigera.io/charts

    • 5.4.2.2）Customize the Helm chart

      • 如果您正在安装 EKS、 GKE、 AKS 或 Mirantis Kubernetes Engine (MKE)安装的集群上，或者您需要自定义 TLS 证书，则必须通过创建 values.yaml 文件来自定义此 Helm chart。否则，您可以跳过此步骤。

        1. 如果您安装在由 EKS、 GKE、 AKS 或 Mirantis Kubernetes Engine (MKE)安装的集群上，请按照安装参考文献中的描述设置 kubernetesProvider。例如:

           echo '{ installation: {kubernetesProvider: EKS }}' > values.yaml

           对于没有预安装 Kubernetes CNI 的 Azure AKS 集群，使用以下命令创建 values.yaml: 

           cat > values.yaml <<EOF
           installation:
             kubernetesProvider: AKS
             cni:
               type: Calico
             calicoNetwork:
               bgp: Disabled
               ipPools:
               - cidr: 10.244.0.0/16
                 encapsulation: VXLAN
           EOF

        2. 向 values.yaml 添加您需要的任何其他定制：

           helm show values projectcalico/tigera-operator --version v3.23.2

  • 5.4.3）安装 Calico

    • 5.4.3.1）Create the tigera-operator namespace:

      kubectl create namespace tigera-operator

    • 5.4.3.2）Install the Tigera Calico operator and custom resource definitions using the Helm chart:

      helm install calico projectcalico/tigera-operator --version v3.23.2 --namespace tigera-operator

       或者你是否创建了一个 values.yaml:

      helm install calico projectcalico/tigera-operator --version v3.23.2 -f values.yaml --namespace tigera-operator

    • 5.4.3.3）确认所有的 pods 都使用以下命令运行：

      watch kubectl get pods -n calico-system

    • 5.4.3.4) Wait until each pod has the STATUS of Running.

      Note: The Tigera operator installs resources in the calico-system namespace. Other install methods may use the kube-system namespace instead.
      
      注意: Tigera 操作符在 calico-system 命名空间中安装资源。其他安装方法可以使用 kube-system 命名空间。

    • 5.4.3.5) 恭喜! 您现在已经安装了 Calico，使用的是 Helm3图表。

 

标签：插件,Kubernetes,网络,节点,BGP,Calico,路由
来源： https://www.cnblogs.com/zuoyang/p/16447958.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。