深入容器之构建大型容器网络-低调大师

深入容器之构建大型容器网络

2021-06-11 744

好未来技术团队出品, 专注于容器底层基础设施建设

背景介绍

构建一个大型混合云容器网络，首先需要考虑的是性能问题，还有容器网络架构是不是经过大规模验证，云厂商是不是有类似方案的选择，如何设计一个能支撑 5K 节点的容器网络呢？其实经过大规模验证的容器网络组件屈指可数，其中大名鼎鼎的 cilium 公开数据显示支持过单集群 5k node 规模，各大云厂商齐头并进支持 cilium ebpf。

本文将包括如下几部分：

Kubernetes Pod 网络概览
Kubernetes Service 网络概览
构建一个大型容器网络

阅读本文你将了解到我司容器网络的进化路线，从容器小集群成长为大集群的新一代容器网络架构；您还将发现老容器集群潜在的网络架构缺陷，除旧迎新恒久不变，一代更比一代强。

『深入容器』系列文章第一篇，请收藏与关注系列文章，欢迎加入我们。

1、Kubernetes Pod 网络概览

在使用 Kubernetes 编排应用时，您必须改变对应用和其主机的网络的思维方式。使用 Kubernetes 时，您需要考虑的是 Pod、Service 和外部客户端的通信方式，而不是主机或虚拟机的连接方式。
Kubernetes 的高级软件定义网络 (SDN) 支持在同一区域级集群中的不同地区之间路由和转发 Pod、Service、Node 的数据包。

IP 地址相关的术语
Kubernetes 网络模型在很大程度上依赖于 IP 地址。Service、Pod、容器和 Node 使用 IP 地址和端口进行通信。Kubernetes 提供不同类型的负载均衡，用于将流量定向到正确的 Pod。

2、Kubernetes Service 网络概览

Kubernetes 的 Service 到底是个啥？其实 Kubernetes 的 Service 主要解决的是 Pod IP 短生命周期带来的问题，Service clutserIP 就是 node side Loadbalancer。

需要思考的问题：

当一个应用拥有多个 Pod 时如何去做负载均衡
会话保持如何去处理
某个容器销毁后短生命周期的 IP 变更如何去处理

下图显示了 Service 负载均衡的不同实现性能对比（数据来源于阿里云容器团队）

2.1、iptables 与 IPVS 的实现

iptables的实现

iptables 的 Serivce 实现诞生于 kubernetes 1.2 版本，iptables 和 -j DNAT 为 Service 提供负载均衡的规则。

iptables 规则更新的缺点：

更新时延：规则更新是全量更新，缺乏增量，增加/删除一条规则，需要整体修改 netfilter 规则表
可扩展性：iptables 增加规则的时延，随着规则数的增加呈指数级上升，同时因为全量提交的过程中做了保护会出现 kernel lock 问题
可用性不足：服务扩容/缩容时，iptables 规则的刷新会导致连接中断，服务不可用。

iptables 的更新时延统计：

5k service (40k 规则），每增加一条 iptables 规则需要 11min
20k service (160k 规则），每增加一条 iptables 规则需要 5h

IPVS 的 Service 实现

显然由于 iptabes 的缺点只能运行在小规模集群下，2018 年华为容器团队使用 IPVS 取代 iptables 实现大规模 Service 负载均衡，社区 GA 于 kubernetes 1.11 版本。IPVS 与 iptables 都是基于 netfilter 框架实现，规则存储于 hash 表中，规则更新的时延不会随着基数上升而不可用。

iptabes VS IPVS 规则增加时延（数据来源于华为容器团队）

内核 conntrack 竞态问题

kubeproxy 的 IPVS 模式，由于 IPVS 缺乏 SNAT 模块，利用 nf_conntrack/iptables 实现 SNAT，IPVS 使用 ipset 来存储需要 DROP 或 masquared 的流量的源或目标地址。
iptables 依赖 netfilter 和 kernel conntrack 连接跟踪模块，Linux 低版本内核在进行源网络地址转换 (SNAT) 时存在已知的竞态问题，这可能导致 SYN 数据包被丢弃。

规避建议

iptables 需要开启 random-fully 选项端口随机，缓解 SNAT 端口竞争情况
Pod 容器环境开启 DNS single-request-open 选项禁用并行查找
由于常用容器镜像 alpine 系统的 musl libc 限制，导致无法生效 single-request-open 禁用并行查找，故不建议使用 alpine 系统

2.2、eBPF 的实现

近年来 BPF 以疯狂的速度发展，应用范围从内核性能分析扩展到了网络领域。这是由于 BPF 提供了强大、高效的可编程性。
Linux 内核社区在 2018 年宣布了 bpfilter ，它将取代 iptables 的长期内核实现，由 Linux BPF 提供支持的网络过滤，同时保证无中断。

BPF 主要推动者:

Facebook 率先使用 BPF/XDP 代替 IPVS 实现负载均衡，Facebook 从 IPVS 迁移到 BPF 后性能提高了几倍
大名鼎鼎的 Brendan Gregg（《性能之鼎》作者），一直在利用 BPF 用于性能分析和跟踪的能力
kubernetes 网络组件 Cilium 使用 BPF 实现容器网络与 Serivce 负载均衡，项目发起者为十年以上 Linux 网络模块维护者

早期的 bpfilter 与 iptables 的比较（数据来源于 cilium 团队）

用 Cilium/BPF 替换 kube-proxy
Cilium 里基于 BPF 实现了一个连接跟踪器，完全替换了 nf_conntrack。基于 BPF 的 SNAT 实现中，用一个 LRU BPF map 存放 Service 和 backend pods 的映射信息。SNAT 会替换 src_ip和src_port，由于不同客户端的 src_port 可能是相同的，如果只替换 src_ip，不同客户端的应答包在反向转换时就会失败。因此这种情况下需要做 src_port 转换。目前做法是先进行 hash，如果 hash 失败则调用 prandom() 随机选择一个端口。

重复利用
通过过期 NAT entry 的快速重复利用（fast recycling）技术。如果一个连接断开时，不会直接删除对应的 entry，而是进行标记为过期；如果有新的连接刚好命中了这个 entry，会将其标记为正常，以达到重复利用这个 entry 的目的。

DSR 模式
之前跨宿主机转发是 SNAT 模式，Cilium 1.8+ 开始支持 DSR 模式。DSR 的好处是 backend pods 直接将包回给客户端，回包不再经过当前节点转发。

3、构建大型容器网络

3.1、VxLAN 隧道模式

构建大型容器网络最经典的方式是用 VxLAN 方式构建大型 overlay 网络，从 Google 到阿里云底层皆使用 VxLAN 方式构建数据中心网络，使用MAC in UDP的方法进行封装，对端进行解封。
基于 VxLAN 的高度可扩展性，可以绕过物理网络进行大规模网络扩展，cilium 基于 bpf 实现了多云 VxLAN 网络（clustermesh），简单部署即可实现多云互联互通的容器网络。

VxLAN 报文：

由于 VxLAN 报文包体较大，封解包过程性能折损较大。适合需要突破 vlan 4096 规模限制的超大规模数据中心并且 VxLAN 有一定性能优化能力。显然大部分业务场景并没有这种超大规模的扩展性需求，而性能在大多数场景下显得至关重要，需要寻求其他轻量级方案。

3.2、BGP Router 模式

Facebook 选择了 BGP 用于构建大型数据中心，BGP 是自治系统间的路由协议，BGP 分为 eBGP 和 iBGP 自治系统间，边界路由器之间使用 eBGP 广播路由。边界路由器通过 iBGP 将学习到的路由信息导入到内部网络，BGP 协议的其中一个缺点是收敛过程慢。

如果不考虑具体的 BGP 方案，很难讨论容器网络的 bgp 配置。然而 BGP 方案设计超出的本文章的讨论范围。如果您对此主题感兴趣，请参阅 BGP in the Data Center （O’Reilly，2017)。

下面将讨论容器网络实施 bgp 路由模式的几种通用方案，适用于从单集群小规模节点到数个中型集群的网络互联互通再到与物理网络 bgp 融合的逐步演进方案，可根据不同应用规模和场景选择对应方案。

全网格 Full-mesh

Full-mesh （全网格）对于小于 100 个节点的小型部署非常有效。Full-mesh 模式的代表 kuberouter 和 calico，把每个 node 都当成 router。启用 BGP 时 Calico 的默认行为是创建一个完整的内部 BGP（iBGP）连接网格，其中每个节点彼此对等路由信息，直接路由的方式性能相当不错。

路由反射器 Route reflectors

在更大的规模下，Full-mesh 的效率会降低，所以建议使用 Route reflectors（路由反射器），来减少每个节点上使用的 BGP 对等体的数量。
在这个模型中，一些节点充当 Route reflectors（路由反射器），并被配置为在它们之间建立一个完整的网格。其他节点随后被配置为对应 Route reflectors（路由反射器）的子集进行对等（通常为 2 个用于冗余），与全网相比减少了 BGP 对等连接的总数。该模式适用于多个容器集群的互联互通，利用 bgp 路由协议构建 3 层容器网络。

RR 模式的注意事项：

BGP 只允许在任何 L2 网络上运行，RR 模式不可以与 VxLan 共用
跨 VLAN 网络情况则需要配置 IPIP 隧道，有一定性能折损
在大规模应用下，RR 所在节点将可能成为性能瓶颈点

顶架式 Top of Rack (ToR)

Cilium 的 BGP 顶架式方案，纯物理网络，适用于约 2k nodes 单集群规模。该模式需要与数据中心网络工程师进行大量测试，我们目前使用该方案推进容器网络升级。

三层分层体系结构

节点通过第 2 层交换机连接到物理网络
通过 bird 软件向物理网络宣布每个节点的 PodCIDR
对于每个 node，不要从物理网络导入路由宣告

在这个设计里，BGP 连接如下所示：

注：这里 node 上使用 host-local 的 IPAM 地址管理方式，每个节点分配个/24 子网的 PodCIDR

核心路由器从 bird 那里学习 PodCIDR 的路由，Pod IP 地址就可以在整个网络中路由。bird 不向核心路由器学习路由信息，这让每个节点上路由表非常干净简洁。每个节点只需向节点的默认网关（核心路由器）发送 pod 出口流量，并让核心路由器进行路由。

BGP 邻居规模上限问题

通过 bird 上报路由的方式，规模受限于物理网络设备的 bgp 邻居数量上限和 IP 地址分配策略
也可通过 gobgp 开源库，开发 ibgp 路由上报程序，由上报程序向核心路由器统一上报所有的 PodCIDR，从而减少 ibgp 邻居数量

3.3、IPVlan L2 直通模式

IPVlan L2 模式和 macvlan 类似，都是从一个主机接口虚拟出多个虚拟网络接口。一个重要的区别就是所有的虚拟接口都有相同的 mac 地址和不同的 IP 地址，而macvlan则是不同的 IP 同时不同的 mac 地址。需要注意的是地方是IPVlan L2同网络子接口的生成的IP， mac 地址是一样的。

Linux kernel 3.19 首次支持 IPVlan，各大厂商推荐使用的版本是 >= 4.19 内核代码目录：/drivers/net/ipvlan/

IPVlan 网络的应用
阿里云基于 cilium cni channing 的扩展能力（aws 也是使用该方式），使得阿里云的容器网络插件 terway 能和 cilium 集成从而支持 bpf。因为 IPVlan L2 模式具备独立的网络 namespace，并不共享 host 的网络 namespace，利用 tc 将 Service 流量劫持重定向到 host 网络 namespace 下达到兼容节点侧的 Service 负载均衡的目的，有兴趣的可以阅读阿里云的（ Kubernetes网络的IPVlan方案）。
IPVlan L2 模式数据路径非常简洁，Pod 网络通信不从 host 网络 namespace 下通过，直通物理子网卡。由于网络堆栈不从节点的 iptables 或路由表通过，因此可以绕过 kubernets conntrack竞争问题，令人头疼的 DNS 超时问题大部分是由 conntrack 引起的。

（来源于阿里云容器团队）

TC 劫持重定向 Service 流量的命令

tc filter add dev $ENIA egress proto ip u32 \
    match ip dst $SERVICE_CIDR \
	action tunnel_key unset pipe \
	action tc_mirred ingress redirect dev ipvl_a0

由于阿里云 terway 的方案使用的是 Cilium1.8 系列版本，未持续跟进升级 Cilium 版本，实现方式绑定阿里云配套的网络产品，故目前只适合在阿里云上时候。但该方案数据路径简洁，与 Cilium 兼容的方式打通数据路径，有较大的架构优势，未来将向该方案靠拢。

3.4、NodeLocal DNS

NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 dns 缓存代理来提高集群 DNS 性能。集群优先 DNS 模式的 Pod 可以连接到 CoreDNS 的 ClusterIP 进行 DNS 查询。
通过 kube-proxy 添加的 iptables 规则将其转换为 CoreDNS 端点。借助这种新架构，Pods 将可以访问在同一节点上运行的 dns 缓存代理，从而避免了 iptables DNAT 规则和连接跟踪。

主要动机

拥有本地缓存将有助于改善延迟，降低 CoreDNS 服务的查询数量
跳过 iptables DNAT 和连接跟踪将有助于减少 conntrack 竞争并避免 UDP DNS 条目填满 conntrack 表

值得注意的是 NodeLocal DNS 与 MacVlan、IPVlan L2 等独立的网络 namespace 并不兼容，上文有提到阿里云使用 TC 劫持重定向 Service 流量达到兼容目的。

参考附录

(2017) BGP in the Data Center https://www.oreilly.com/library/view/bgp-in-the/9781491983416/
(2018) 华为云在 K8S 大规模场景下的 Service 性能优化实践 https://zhuanlan.zhihu.com/p/37230013
(2018) 为什么内核使用 BPF 替换 iptables https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables
(2019) 利用 eBPF 支撑大规模 Kubernetes Service https://arthurchiao.art/blog/cilium-scale-k8s-service-with-bpf-zh
(2019) Kubernetes 网络的 IPVlan 方案 https://kernel.taobao.org/2019/11/ipvlan-for-kubernete-net/
(2020) 阿里云如何在生产环境中构建高性能云原生 Pod 网络 https://www.alibabacloud.com/blog/how-does-alibaba-cloud-build-high-performance-cloud-native-pod-networks-in-production-environments_596590
(2020) 腾讯云绕过 conntrack，使用 eBPF 增强 IPVS 优化 K8s 网络性能 https://cloud.tencent.com/developer/article/1687922

微信关注我们

原文链接：https://my.oschina.net/u/4471526/blog/5076844

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

【ShardingSphere】springboot整合shardingjdbc使用精确分片算法自定义分库分表

上两篇文章讲到了两种分库分表的方式，这两种方式可以归结为一种类型，都是通过配置的形式来分片数据。本文我们继续讲解一种新的方式来分片数据，除了配置的形式外，shardingjdbc还支持通过代码来自定义规则。自定义规则之前我们实现了id取模和按日期分库分表，这里我们为了展示技术，还是继续按照日期分表，不过这里通过代码来自定义。在开始写代码之前，我们先将分库分表规则定义好。这里我们建立两个库ds0,ds1。每个库建立表t_order2021、t_order2022两个表，语句如下： CREATE TABLE `t_order2021` ( `id` bigint(32) NOT NULL, `user_id` int(11) DEFAULT NULL, `order_id` int(11) DEFAULT NULL, `cloumn` varchar(45) DEFAULT NULL, `day_date` char(8) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE ...

2021-06-11

543

事实表明，许多没有创建FinOps(云财务运营)团队的企业在试图控制和报告成本方面面临一些痛苦和挑战。大多数企业表示，云计算基础设施和应用程序将在他们的工作、创新和支持客户方面发挥重要作用。根据调查机构Gartner 公司的调查和预测：全球最终用户2021年在云计算软件方面的支出将达3320亿美元，而2020年为2700亿美元。尽管这项投资规模巨大，但大多数企业都难以掌握他们在云计算服务方面的支出。更糟糕的是，大多数企业都没有衡量盈利的关键指标，例如按产品/服务计算的云计算成本、按客户计算的成本，或者相对于传统内部部署环境的云计算投资回报率。全球各地的企业正在努力应对这些挑战，而FinOps行业如今取得了令人兴奋的进展。任何大规模使用云计算服务的企业都可以从这些实践中受益。确定问题的范围在2019年之前，FinOps从业人员发现自己正在孤立地寻找云计算财务管理挑战的解决方案，大多数人没有能力从标准化的最佳实践中获益。FinOps基金会是一个非营利性、标准制定和知识共享组织，旨在通过帮助FinOps从业人员记录和分享最佳实践来解决这一问题。 FinOps基金会如今是Linux基...

2021-06-11

498

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。