K8s 网络和 Calico CNI 插件
Kubernetes 网络 那么,除了其他网络实现之外,kubernetes 中的网络有什么特别之处呢?那是因为 k8s 没有。准确地说,k8s 本身并没有实现网络,它依赖于不属于标准 k8s 对象的网络插件。 任何人都可以通过实现容器网络接口(CNI)在k8s中实现网络。 CNI 是为了在同一节点或不同节点中建立 pod 到 pod 通信而要遵循的一组标准。创建这些标准是为了让每个人都可以实施自
Kubernetes 网络
那么,除了其他网络实现之外,kubernetes 中的网络有什么特别之处呢?那是因为 k8s 没有。准确地说,k8s 本身并没有实现网络,它依赖于不属于标准 k8s 对象的网络插件。
任何人都可以通过实现容器网络接口(CNI)在k8s中实现网络。 CNI 是为了在同一节点或不同节点中建立 pod 到 pod 通信而要遵循的一组标准。创建这些标准是为了让每个人都可以实施自己的网络解决方案,但要遵守使其与 k8s 兼容的标准。让我们简要介绍一下 pod 是如何相互通信的。
Pod 到 Pod 通信
k8s 网络的经验法则是每个 pod 在整个集群中都有自己唯一的 ip,从而避免了执行NAT的开销。每当创建一个 pod 时,它都会被放置在它自己的网络命名空间中(更多关于网络命名空间这里是)。 linux 安装附带了一个默认的主机网络命名空间。每个网络命名空间都有一个或多个网络接口连接到它们,并分配给它的 IP 地址。
附加到 pod 的接口实际上是一对接口(veth pair),其中一个接口附加到主机网络命名空间,如下所示。
所以我们在同一台主机上有两个网络接口,我们现在如何连接它们?这是通过主机 netns 中的虚拟网桥完成的。因此,每当一个 pod 发送一个 IP 数据包到同一主机中的一个 pod 时,它会将其吐出到连接到根 netns 的另一个 veth 对,并且网桥会向与其连接的所有接口发出ARP请求并发送相应的数据包到 pod。
那么,不同主机上的 Pod 是如何相互通信的呢?有多种实现方式。每个 CNI 插件都以自己的方式实现这一点,当您在 eks 中有一个集群时,像 AWS VPC CNI 这样的云插件,只需在创建 pod 并且 pod 获取来自的 IP 时将其弹性网络接口附加到主机即可VPC 子网。现在,由于 Elastic 接口位于同一子网中,因此它们可以像普通主机一样相互通信。
但在非云环境中,通过 Flannel、Cilium 或 Calico 等 CNI 插件创建一个 Overlay 网络(跨不同主机形成的逻辑网络),以实现 pod 到 pod 通信。覆盖网络需要单独讨论。所以我们将在以后的帖子中讨论它。
所以现在我们知道是谁创建了这一切(当然是 CNI 插件),其中一个这样的 CNI 插件是Calico。
Calico CNI 插件
所有网络插件都实现了网络(路由流量)和网络安全(过滤流量),calico 也是如此。您可以按照此doc在您的 k8s 集群中安装 calico。
印花布的成分
Calico 在各自的命名空间下创建所有这些组件。
老虎运营商
pod/tigera-operator u003d 负责安装使 calico 成为 kubernetes 对象的 CRD(自定义资源定义),还负责启动 calico 控制器(policy、ns、pod、node 控制器)并将更改应用于 calico 资源。
印花布系统
pod/calico-kube-controllers——负责识别影响路由的 Kubernetes 对象的变化。控制器内部包含多个控制器,监视网络策略、服务、命名空间、服务帐户、节点的变化。
pod/calico-node — calico 的核心,作为守护程序集运行,并运行三个内部守护程序,负责不同的网络功能。
Felix — 负责对主机进行编程以满足 pod 路由和网络策略。为此,它与 Linux 内核的路由表和 Linux IPtables(用于网络策略)进行交互。
Bird — 采用 Felix 编写的路由规则,并与默认在所有主机上运行的其他 BIRD 实例对等。这些 BGP 对等体不断共享有关其已知路由的路由信息。 BIRD 是一个功能强大的守护进程,它支持多种拓扑结构。
Confd — 一个使用来自 etcd 的模板和数据管理本地应用程序配置文件的开源项目。
pod/calico-typha — Typha 是一个将配置扇出到集群中所有 calico-node 实例的进程。它充当缓存,可以从 API 服务器中删除重复事件,从而显着减轻负载。随着 Calico 数据存储的更改,这些更改必须传播到 calico-node 的每个实例,可能是数百或数千个实例。这会在具有 50 多个节点的集群中产生扩展问题,因为每个节点都将监视 API 服务器事件。 Typha 通过作为 API 服务器和 calico-node 的所有实例之间的中介来解决这个问题。
! zoz100037](https://devpress-image.s3.cn-north-1.jdcloud-oss.com/a/698521ed8c_1*WtDqYkpYRNFY2C2uqZZi5Q.jpg)
** Calico-apiserver**
pod/calico-apiserver — 在现有集群上安装 Calico API 服务器,以启用使用 kubectl 而不是 calicoctl 管理 Calico API。
印花布数据存储
Calico 数据存储是一个通用术语,指的是用于存储 Calico 配置、路由、策略和其他信息的任何内容。 Calico 支持 2 种数据存储模式,Kubernetes 和 etcd。
概括
所以,事情就是这样。当您创建一个 calico 对象时,例如网络策略,请求将通过 calico-apiserver 到达 kube-apiserver,该 calico-apiserver 通知负责策略管理的 calico kube 控制器之一。控制器将数据放入数据存储中,typha 将这个新配置扇出到所有 calico-node deamonset。然后 felix 进程相应地更新 IP 表,如果是路由表更新,则 BIRD 守护进程将与集群中节点中的其他鸟类对等点共享路由。
您可以使用 calico 仅强制执行网络策略,并让 aws vpc cni 插件处理网络部分。为此,当安装在托管云服务中时,calico 默认以仅 felix 模式运行。
快乐的网络:)
更多推荐
所有评论(0)