Z.S.K.'s Records

Kubernetes学习(在云架构外运行flannel)

发表于 | 分类于

该文章为翻译文档, 这里是原文地址, 比较清晰地说明了flannel在VxLAN下的实现原理

在本文中，我们将详细介绍flannel及其在Kubernetes网络中的作用。我强烈建议您点击参考链接，以更好地了解flannel工作原理。

在上一篇文章中，我们介绍了etcd并对其进行了简要概述。

这些文章是我们的Kubernetes旅程的一部分。我希望您很高兴深入了解如何从云中安装和配置Kubernetes！

集群网络

“网络是Kubernetes的核心部分，但要确切地了解其预期工作方式可能会有些困难。”

参考：https://kubernetes.io/docs/concepts/cluster-administration/networking/

在讨论flannel之前，了解群集的网络特性很重要。

在本节中，我们将主要集中于了解Pod到Pod的通信方式。

Kubernetes网络模型遵循一些基本假设。在官方文件说，Kubernetes网络模型的要求：

  • Pod都可以彼此通信，而无需使用网络地址转换（NAT）。
  • 节点-运行Kubernetes集群的机器。这些可以是虚拟机或物理机，或者实际上可以运行Kubernetes的任何其他机器-也可以与所有Pod通信，而无需NAT。
  • 每个Pod会看到与其他Pod一样的IP

Kubernetes网络模型

每个Kubernetes节点（主节点或工作节点）都是Linux机器（VM或Bare Metal），其具有网络命名空间**-netns-以网络接口作为其主要接口。上图中的eth0**对此进行了说明。

仔细观察，我们可以看到每个Pod都有自己的eth接口，这意味着每个Pod都有自己的网络配置（IP，路由等）。这也意味着每个Pod都有自己的网络，因此我们有一个按网络接口分隔的网络命名空间。

为了说明这一点，假设您与同事一起参加在拉斯维加斯举行的会议。贵公司将赞助您参加此次会议，因此您将全部留在同一家酒店（Kubernetes节点）。这家酒店的每个房间（一个Pod）都配备了客房电话（网络接口）。

您可以使用客房电话与不在酒店的家人进行通讯。没有免费的午餐，因此酒店显然会向您收取使用客房电话拨打的任何外部电话的费用。为此，所有外部呼叫都要经过一个中心（eth0），该中心将对其进行注册，然后将这些呼叫重定向到外部世界。客房电话和此中央设备之间的链接类似于虚拟接口（veth）在网络中扮演的角色

“第五个设备是虚拟以太网设备。它们可以充当网络名称空间之间的隧道，以创建到另一个名称空间中的物理网络设备的桥，但也可以用作独立的网络设备。

veth设备总是以互连对的形式创建。”

参考：https://man7.org/linux/man-pages/man4/veth.4.html

现在，您和您的同事希望例如在您离开会议或吃晚饭时让对方知道。您想节省一些钱，因此决定使用客房电话互相通话，而不是使用手机。当您在酒店办理入住手续时，礼宾部解释说，您可以通过输入＃<房间号>在各个房间之间互相呼叫。有一个内部中心，可以进行这种通信。这类似于cni0（如上图所示）扮演的角色，充当允许Pod到Pod通信的桥梁。

这家酒店可能有多栋建筑，而您的一些同事则位于第二栋建筑中。不过，礼宾部解释说根本没有问题。要与他们进行通信，您只需要在房间号之前添加建筑物号：＃ <房间号>。内部中央（cni）将注意到此地址不是其自己建筑物的内部地址，会将呼叫重定向到中央（eth0），这将使它们再次将呼叫重定向到另一个建筑物（另一个Kubernetes节点）中央（类似于eth0），依次将呼叫传递到它自己的内部中心，使呼叫最终在目标房间完成。有关此方案的更多技术说明，请检查在下面的“跨不同主机路由流量”部分。

在Kubernetes上，所有这些配置和管理都是通过CNI（容器网络接口）插件进行的

什么是CNI

CNI是Container Networking Interface（容器网络接口）的缩写，它基本上是一个外部软件（模块），它实现了规范明确定义的接口，该接口允许Kubernetes执行操作以提供网络功能。

“每个CNI插件必须实现为由容器管理系统（例如rkt或Kubernetes）调用的可执行文件。

CNI插件是负责将网络接口到所述容器网络命名空间（例如一个的一端VETH在主机上对），使任何必要的变更（例如，另一端附接VETH成桥）。然后，它应该通过调用适当的IPAM插件，将IP分配给该接口并设置与IP地址管理部分一致的路由。”

参考：https://github.com/containernetworking/cni/blob/master/SPEC.md#cni-plugin

Kubernetes请求路由

我们将在两种情况下更详细地说明如何在Pod之间路由流量

在同一主机上路由流量

从Pod 4到Pod 6的逐步通信：

  1. 程序包通过eth4接口离开Pod 4网络，并通过虚拟接口veth4到达根网络
  2. 请求到达cni0，寻找Pod 6的地址
  3. 请求离开cni0并重定向到veth6
  4. 请求通过veth6离开根网络，并通过eth6接口到达pod6网络

跨不同主机路由流量

从Pod 1到Pod 6的逐步通信：

  1. 程序包通过eth1接口离开Pod 1网络并通过虚拟接口veth1到达根网络
  2. 请求离开veth1并到达cni0，寻找Pod6地址
  3. 请求离开cni0并重定向到eth0
  4. 请求从主机1离开eth0到达网关
  5. 请求离开网关，并通过Worker1上的eth0接口到达根网
  6. 请求离开eth0并到达cni0，以查找Pod6的地址；
  7. 请求离开cni0并重定向到veth6虚拟接口
  8. 请求从根netns通过veth6并到达Pod6 netns的eth6接口;

flannel

“ Flannel是配置专为Kubernetes设计的第3层网络结构的简单方法

Flannel 在每个主机上运行一个小的单一二进制代理程序，称为flanneld，并负责从更大的预配置地址空间中为每个主机分配子网租约。Flannel *直接使用Kubernetes API或etcd来存储网络配置，分配的子网以及任何辅助数据（例如主机的公共IP）。数据包使用包括VXLAN和各种云集成在内的几种后端机制之一转发。”

参考：https://github.com/coreos/flannel

backend

“ flannel可以与几个不同的后端进行配对。设置后，不应在运行时更改后端。

推荐使用VXLAN。建议有经验的用户使用 host-gw*来提高性能并获得基础架构的支持（通常不能在云环境中使用）。建议将UDP*仅用于调试或不支持VXLAN的非常老的内核。”

参考 https://github.com/coreos/flannel/blob/master/Documentation/backends

在本文中，我们将讨论在解决方案中将使用的VXLAN模式的内部

flannel namespace

默认情况下，flannel使用CIDR 10.244.0.0/16为每个节点分配具有10.244.X.0 / 24掩码的较小子网，而Pod将使用这些子网之一分配给给定节点的IP地址。

简而言之，这意味着每个节点最多可以有254个活动Pod，其中每个Pod将具有与此分配的子网不同的IP。

你可以看到在本说明书KUBE-flannel.yml清单，在定义网conf.json。（官方flannel repository位于下面的链接中）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
kind: ConfigMap 
apiVersion: v1
metadata:
  name: kube-flannel-cfg
  namespace: kube-system
  labels:
    tier: node
    app: flannel
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
    }

Virtual Ethernet Devices — veth

“veth设备是虚拟以太网设备。它们可以充当网络名称空间之间的隧道，以创建到另一个名称空间中的物理网络设备的桥梁，但也可以用作独立的网络设备。”

参考 https://man7.org/linux/man-pages/man4/veth.4.html

Bridge — cni0

cni0是Linux网络桥接设备，所有veth设备都将连接到该桥接器，因此同一节点上的所有Pod都可以相互通信，如Kubernetes网络模型和上述酒店类比中所述

vxlan-flannel

“ 虚拟可扩展局域网（VXLAN）是一种网络虚拟化技术，旨在解决与大型云计算部署相关的可扩展性问题。它使用类似VLAN的封装技术将OSI第2层以太网帧封装在第4层UDP数据报中，并使用4789作为默认IANA分配的目标UDP端口号。终止VXLAN隧道的VXLAN终结点，可以是虚拟或物理交换机端口，称为VXLAN隧道终结点（VTEP ).”

参考：https://en.wikipedia.org/wiki/Virtual_Extensible_LAN

该接口（在我们的图中，flannel.1）的主要功能是通过覆盖来确保Pod及其网络之间的通信前提之一（记住每个节点都有一个子网，每个Pod都有该子网的IP)。

使用VXLAN，可以通过使两个或多个网络像在同一个网络中一样进行操作来连接两个或多个网络，也就是说，每个网络都是其自身网络的一部分，但在同一域内。

在以前使用的类比中，VXLAN是将一栋建筑物连接到另一栋建筑物的（物理）电话线，从而允许您所在建筑物（Node1）中一个（Pod1)与位于您的同事所在的另一座建筑物（Node2）中的Pod4通信。

flanneld是一个守护程序，负责使节点（及其所包含的Pod）之间的路由保持最新。

原文地址

https://itnext.io/kubernetes-journey-up-and-running-out-of-the-cloud-flannel-c01283308f0e

wechat
Scan Me To Read on Phone
I know you won't do this,but what if you did?