容器网络是如何影响Kubernetes中数据库性能的？

关于Kubernetes中的数据库，大家最关心的第一个问题是性能。由于这种担心的存在，许多使用Kubernetes进行生产应用程序工作的客户正在Kubernetes之外的裸机或VM上运行数据库。因此，我们致力于深入研究Kubernetes抽象层，确定值得测试的关键领域，并设计有用的基准。

我们从网络入手，因为由于需要在大多数Kubernetes环境中利用网络存储来提高弹性，因此网络对性能的影响很大。此外，我们知道联网一直是容器化领域不断挑战和改进的领域。最后，对于考虑将其数据库工作负载迁移到Kubernetes的人们来说，我们通常将性能视为网络采用的主要障碍，而将网络性能视为特定的主要障碍。拥有一个数据库到Kubernetes的桥梁是很有价值的，这使在这里运行生产工作负载更加可行。最后，我们想了解在Kubernetes中运行数据库所需的一切。
这篇博客文章直接基于这些努力的结果。

基准方法 为了进行此基准测试，我们试图建立一种方法来专门隔离尽可能多的变量，以专门研究网络如何影响性能。为此，我们确保使用的数据集适合内存，在执行运行之前预热所有缓存，在Kubernetes中利用本地存储，并执行足够的基准测试运行以消除可变性。我们还希望数据能够进行真正的比较，因此我们确保通过基础架构拓扑进行比较。

我们的测试数据中心内机柜中的五台物理服务器中的每台都连接到机架式10GbE和机架式1GbE交换机，该交换机包括位于单独IP子网中的两个单独的物理网络。五台服务器中的一台充当sysbench客户端，用于模拟工作负载，其余四台由Kubernetes和Database角色组成。在裸机测试期间，这三台服务器作为Kubernetes节点按原样运行，在Kubernetes测试期间，这三台服务器被部署为托管数据库Pod的节点，而第四台服务器被预留为仅充当Kubernetes Master。
为了部署Kubernetes环境，我们使用了kubeadm并尝试尽可能保持基本默认设置，以确保我们在测试中不会产生混杂因素。我们使用了Kubernetes 1.16。在Percona XtraDB群集5.7.27-31.39的基础上，使用Percona XtraDB群集的Percona Kubernetes Operator 1.2.0版本部署了Percona XtraDB群集。为了部署裸机环境，使用来自我们公共仓库的Percona XtraDB Cluster 5.7.27-31.39的Percona装运包手动执行安装。在这两种情况下，我们都禁用ProxySQL并将Percona XtraDB Cluster群集成员直接暴露给网络，并配置了sysbench客户端，以便所有流量仅定向到Percona XtraDB Cluster群集的单个成员。对于裸机测试和基于Kubernetes的测试，主机操作系统都是Ubuntu 16.04 LTS，该内核运行的内核版本为4.15.0-66（与Ubuntu 16.04 LTS一起提供）。

服务器中包含的硬件如下：

对于环境设置，我们按照提供的说明将每个CNI插件安装在Kubernetes的全新部署中，以确保它通过10GbE网络发送流量。我们使用sysbench和oltp读写工作负载运行数据库基准测试。此外，我们使用iPerf3捕获了网络吞吐量数据。为了确保数据库本身不是瓶颈，我们利用了经过优化的 MySQL 配置，该配置作为ConfigMap提供给Kubernetes Operator。最后，对于本地存储，我们利用Kubernetes中的HostPath方法来确保我们可以为数据库提供卷而不会越过网络边界，从而只有事务和复制工作负载会接触到网络。

我们调整的my.cnf如下：

[mysqld]
table_open_cache = 200000
table_open_cache_instances=64
back_log=3500
max_connections=4000
innodb_file_per_table
innodb_log_file_size=10G
innodb_log_files_in_group=2
innodb_open_files=4000
innodb_buffer_pool_size=100G
innodb_buffer_pool_instances=8
innodb_log_buffer_size=64M
innodb_flush_log_at_trx_commit = 1
innodb_doublewrite=1
innodb_flush_method       = O_DIRECT
innodb_file_per_table      = 1
innodb_autoinc_lock_mode=2
innodb_io_capacity=2000
innodb_io_capacity_max=4000
wsrep_slave_threads=16
wsrep_provider_options="gcs.fc_limit=16;evs.send_window=4;evs.user_send_window=2"

我们对Kubernetes中资源的调整设置如下：

resources:
requests:
memory: 150G
cpu: "55"
limits:
memory: 150G
cpu: "55"

我们这样做是因为Kubernetes中的Pod资源服务质量（QoS）。Kubernetes根据Pod的请求和限制设置为Pod提供不同级别的QoS。在典型情况下，您仅指定请求块而不指定限制，Kubernetes使用“尽力而为QoS”，但是当为所有容器中的所有资源设置请求和限制并且它们相等时，Kubernetes将改为使用“保证的QoS”。这可能会对性能差异产生重大影响。

此外，您需要了解以下用于运行测试的sysbench命令行：

./sysbench --test=tests/db/oltp.lua --oltp_tables_count=10 -- oltp_table_size=10000000 --num-threads=64 --mysql-host=172.16.0.4 -- mysql-port=30444 --mysql-user=root --mysql-password=root_password --mysql-db=sbtest10t --oltp-read-only=off --max-time=1800 --max- requests=0 --report-interval=1 --rand-type=pareto --rand-init=on run

我们测试了哪些CNI插件
我们选择了CNI插件来进行测试，基于我们与客户和合作伙伴以及一些由于性能原因而特别有趣的参与者的经验。该列表没有特别的顺序，我们的目标不是总结使用哪个插件的具体建议。所有CNI插件的项目目标都不同，这导致它们进行不同的设计和工程折衷，这可能会对性能产生影响，但是根据您的环境，这些折衷可能是合理的。

Project Calico

由于其简单性，您可以将可路由IP分配给Pods并将其与您现有的机架式网络设备集成在一起，因此，Project Calico是许多进行内部部署的企业的热门选择。因此，我们测试了启用（默认）和禁用IP-in-IP的Calico。

Flannel

Flannel是带有Kubernetes的网络结构，支持可插入后端。默认后端基于UDP，但它也支持vxlan和host-gw后端。我们无法使host-gw正常工作，但是我们能够使用UDP和vxlan进行测试。

Cilium

Cilium是使用BPF和XDP的API感知网络和安全性。主要侧重于网络安全政策用例。它的安装非常简单，但是在可用的基准测试时间内，我们无法使其跨10GbE网络进行路由，这显然影响了性能结果。否则测试成功了，但请记住，我们仍在报告这些结果。

Weave (weave-net)

Weave是一个紧密集成且易于部署的多主机容器联网系统。尽管显示Pods已在我们的10GbE网络块中分配了IP，但流量仍在1GbE网络中路由。我们花费了大量时间来解决此问题，但在可用时间内无法解决。我们仍在报告这些结果。

Intel SR-IOV and Multus

Multus是一个CNI插件，可将多个网络接口附加到Pod。这是必需的，因为SR-IOV CNI插件不能是您唯一的Pod网络，它是默认Pod网络之外的附加接口。我们将Kube-Router用于默认的Pod网络，并为此测试分配了另一个10GbE网络上的SR-IOV接口。SR-IOV具有复杂的设置过程，但允许将大部分网络卸载到硬件，并有效地将硬件（VF）中的虚拟NIC分配给作为网络设备的主机上的每个Pod。从理论上讲，它应该具有接近线速的性能，因此值得尝试的复杂性。

Kube-Router

Kube-Router是Kubernetes网络的简单交钥匙解决方案。它也是kubeadm部署的默认插件，因此部署非常简单。最小的功能集所产生的开销很少，您将在结果中看到这一点。

结论 作为基准，我们首先在裸机上进行了测试，并表明我们的基准仅受网络性能的限制。在这些测试中，我们在1GbE上达到了2700 tps，在10GbE上达到了7302 tps。

一个非常有趣的结果是，由iPerf3衡量的网络吞吐量与由sysbench衡量的数据库吞吐量之间的相关性强。SR-IOV打破了这种相关性，我们期望它是性能最好的。它具有接近裸机的网络吞吐量，但是大约是预期数据库吞吐量的一半。我们怀疑此结果与事务大小有关，这是由于SR-IOV固有的硬件虚拟化层内部发生延迟导致的，因此我们计划在将来的基准测试中验证这种怀疑。
我们发现的另一个关键问题是，即使在使用Kube-Router的最佳情况下，与在Kubernetes中运行裸机相比，我们也看到数据库性能下降了约13％。这说明在Kubernetes中仍需要对容器网络的性能进行改进。

以下为3月19日开源要闻推荐：

Spectro Cloud获得750万美元融资，提升托管Kubernetes体验

Kubernetes是一个非常流行的容器管理平台，但是如果要使用它，则几乎必须在让别人为您管理它还是自己构建它之间进行选择。Spectro Cloud脱颖而出，获得了750万美元的投资，并正致力于为您提供介于中间的第三种选择。

资金由Sierra Ventures领导，Boldstart Ventures参与。Boldstart创始人Ed Sim说，他喜欢Spectro Cloud的团队和技术。Spectro Cloud解决了每个大型企业都在努力解决的巨大难题：如何在托管平台上推出自己的Kubernetes服务，而又不依赖任何大型供应商。

Spectro联合创始人兼首席执行官Tenry Fu表示，企业不应该在控制和易用性之间妥协。“我们希望成为第一家为企业带来易于使用的托管Kubernetes体验的公司，同时也使他们能够灵活地大规模定义自己的Kubernetes基础架构堆栈，” Fu解释说。

Fu说，在这种情况下，堆栈由Kubernetes版本的基础操作系统，存储，网络和其他层（如安全性，日志记录，监视，负载平衡或与Kubernetes相关的任何基础结构）组成。他解释说：“在企业内的组织内，您可以满足各个组的需求，就基础结构堆栈中的内容而言，可以降至相当细致的水平，因此您不必担心生命周期管理。”这是因为Spectro Cloud会为您处理这些问题，同时仍为您提供控制权。

这为企业开发人员提供了更大的部署灵活性，并且使他们能够更轻松地在云基础架构提供商之间迁移，这是当今公司的头等大事，因为公司不想将自己锁定在一个供应商中。“存在一个基础设施控制连续体，迫使企业必须权衡这些需求。在一个极端情况下，托管产品围绕易用性提供了一种必杀技，但这是以控制您所处的云之类的东西或采用新的生态系统选项（例如Kubernetes的更新版本）为代价的。虽然还处于发展初期，但该公司一直在与16个Beta客户合作。

GNOME 3.36可提供基于Fedora 32 Beta Linux的操作系统

Fedora是 Linux 发行版之一。它不浮华，相反要稳定可靠。这就是为什么许多Linux用户在尝试其他发行版后，又回到Fedora的原因。GNOME的爱好者尤其喜欢Fedora，因为该操作系统是体验桌面环境的最佳方法之一。近日，Fedora 32 Beta可以进行测试了。它随GNOME 3.36一起提供最新、最好的桌面环境版本。如果您不是GNOME的粉丝，您可以选择KDE Plasma，Cinnamon，MATE等。甚至还有Fedora 32的特殊ARM变体，可与Raspberry Pi设备一起使用。

“ Fedora 32 Workstation Beta中的新增功能默认情况下启用EarlyOOM。EarlyOOM使用户可以在低内存情况下通过频繁交换使用来更快地恢复并重新获得对系统的控制。Fedora32 Workstation Beta默认还启用fs.trim计时器，可以改善固态硬盘的性能和磨损平衡。” Fedora项目的Matthew Miller说。

Miller进一步说：“ Fedora 32 Beta包含许多流行的软件包的更新版本，例如Ruby，Python和Perl。它还包含流行的GNU编译器集合（GCC）的版本10。我们还对底层基础结构软件进行了常规更新，例如GNU C库。”但是，在安装Fedora 32 Beta之前，请记住这是一个预发行的操作系统。它很可能包含错误，可能会导致潜在的数据丢失。建议在安装之前，先通读并了解已知错误信息。

微软发布VS Code Docker扩充套件1.0

微软推出Visual Studio Code的第一个 Docker 扩充套件主要版本，这个新版本更好地支持 Python 网页框架，并且为Python和.NET Core开发人员，提供与Node.js相同的Compose支持，开发者使用Docker扩充套件建构、执行和除错容器化应用程序，将会更简单。

回应开发人员的建议，微软提升Docker扩充套件对Python网页框架Django与Flask的支持程度，由于当工作区添加Docker档案时，开发者可以选择要使用Django或是Flask，而现在系统会自动架构出Dockerfile、除错任务以及启动配置。微软提到，Docker扩充套件仍会继续支持一般选项，供开发者取得更通用的Dockerfile。

Docker扩充套件现在支持使用Compose.yml档案或是Dockerfile。微软表示，当用户只需要启动带有少量参数的单一容器，可以仅使用Dockerfile，但是要一次启动一个以上的服务，或是要启动一个服务，但是要修改多个Docker执行参数，就可以使用Docker Compose。除此之外，Docker扩充套件针对Node.js、Python和.NET Core开发语言，支持使用Dockerfile对单一服务进行整合性除错。

在这个新版本中，用户可以自定义各种命令，像是执行映像档时，指定扩充套件将产生的容器放置在特定的网络上等。最多使用者要求的更新，是希望在执行像是启动、停止或是删除映像档等命令时，可以一次选择多个容器或是映像档，因此微软这次新增了功能，让用户可以一次选择多个容器或映像档，并从右键选单选择要对选定项目执行的命令。

另外，当用户执行包含WSL 2（Windows Subsystem for Linux 2）的Windows版本，可以在Docker Desktop中启动WSL 2实验引擎，该引擎会以WSL 2执行，而非使用HyperV执行Linux容器，微软表示，他们从Docker扩充套件0.9版本开始，就支持并且鼓励使用WSL 2。

IBM今年力推6大云原生软件产品组合Cloud Paks

IBM完成红帽并购案后，去年秋季发布并以非正式方式向媒体介绍了全新云原生软件产品组合Cloud Paks，以容器化技术将软件整合为多组解决方案。近日，IBM在线上举办的记者会，正式介绍了这个以套餐形式设计的云端软件产品组合。IBM今年重要策略宗旨是，以认知型企业（Cognitive Enterprise）混合多云平台为核心，提供IBM Cloud Paks、Red Hat、IBM Cloud的解决方案。在IBM完成红帽并购案后，IBM将既有的软件平台与红帽产品线进行整合，推出6个Cloud Paks，涵盖了企业客户端到端的整个数字化转型过程，所需要的产品线与服务。他更提到，在数字化转型过程中，企业面临混合多重云是必然的趋势。

IBM Cloud Paks包括的6大产品线，分为应用程序开发解决方案Cloud Pak for Applications、自动化资料分析解决方案Cloud Pak for Data、整合套件组Cloud Pak for Integration、流程自动组Cloud Pak for Automation、混合云管理解决方案Cloud Pak for Multicloud Management，这前5项都在去年秋季已在国外发布，新增的第6个信息安全解决方案Cloud Pak for Security，是IBM去年第四季的最新发布。

Gartner：企业短期抗疫推BCP得留意细节

新冠状病毒全球大流行的现状直接冲击了企业的营运表现，不少企业早已订定了一套营运持续计划（BCP），或因应疫情，紧急订定，不过，Gartner 在最近一场研讨会中提醒，企业订定BCP得留意许多细节，例如不同因应情境的时间单位不一样。Gartner建议，BCP应加入时间的概念，即时反应以小时为单位、復原措施则可以天数衡量、另外还要有以周或月为单位的长期应对策略，并在事件发生后的不同时间内，执行对应的措施；企业应该认知到，整体反应时间不断缩短。比如过去核心系统中断，还能容忍以天为单位的修復时间，但现在就算赶在几个小时内修復，也可能不被业务单位所接受。

另外，订定BCP的同时，也要一并考量到触发应变措施的条件，以及负责执行者，来减少应变过程中的不确定性，以及因不确定性而导致的决策缓慢，才不会错过最佳执行计划的时机。同时，设定明确的触发条件也更易于与员工沟通。Gartner举例，比如设定1位员工病毒检测阳性，就触发对应的计划。

营运持续计划（BCP）是企业风险管理的一环，但令人沮丧的事实是，许多企业并无意识到风险管理的重要性。Gartner观察，部分企业的风险管理业务没有指定负责人、负责人经验也不足，也并非因自身业务需求去评估风险，反而是受到外部法规所驱动，甚至没有订定系统性的营运持续计划；再者，绝大多数利益相关者缺乏相关意识，就算有计划，也未展开压力测试和相关演习。

对于企业被动、缺乏组织性的风险管理现况，Gartner建议，企业应根据自身所属行业、地理位置等面向进行风险评估，订定出适合自己的营运持续计划，比如根据B2B或B2C的业务类型、容易发生地震或颱风的地理位置属性不同，对业务的影响也不同，需要确实评估与分析；接着，应先拟定大方向的復原策略、再进一步订定细节，若预设的情境真实发生，就须确实执行计划，若没发生，也应定期安排演习，并持续透过测试来改进流程。

面对新冠状病毒疫情，许多企业要在短期内维运远距工作的IT环境，比如确保员工能连线到公司并维持工作效率、确保远距办公的资讯安全，或实践IT维运的A、B分组机制等。不过Gartner也表示：CIO除了基本的IT支持，应向更多长期的IT维运面向来进行探索。

比如说，企业面对疫情，可能会走向数字化化业务与数字化生态系，或是改为采用RPA等自动化技术，甚至因疫情长期对供应链的冲击，可能因供应链转移、流动到其他地区，引发企业并购等重新配置的状况。面对企业在疫情中可能发展出的新商业模式、工作流程、或客户的新需求，IT系统是否有足够的弹性来因应？这是CIO可以趁这一波疫情思考的问题。Gartner表示。

Gartner的一篇报告中也举例，部分企业制造业已经根据疫情需求来调整产品类型。比如日本电子产品制造商夏普（Sharp），将其中一家工厂改为制作口罩；而中国富士康，也将其部分因疫情而需求低迷的传统产品，改为生产需求更高的产品，如防护装备等。这都是快速因应新商业模式而做出改变的案例。

因此，Gartner也建议，企业可以藉着疫情来加速数字化转型，比如导入敏捷开发流程，来改变企业内部文化与工作方式，之前一直没机会做的，现在是一个好机会，将一些新的工作方式、新的思维方式进行实践，来提升整个团队、企业的能力，帮助企业在危机中胜出。

在IT预算上，多数CIO为了因应疫情对企业造成的冲击，已经规划缩减IT预算来降低企业整体营运成本。不过，Gartner指出，企业IT成本通常占整体企业的2～10%，就算消减IT预算，对企业的效果有限，因此，CIO也可以思考如何进行成本优化、甚至价值优化，来更有效的提升业务流程的效率与价值。

首先，在IT成本降低方面，CIO可能采取的作法，包括停办一些培训、供应商活动，或降低顾问的支出，也可能对员工进行交叉培训，让每位员工获得更多技能，来减少员工数的增长；其他作法，还包括推迟大型IT项目的建置，或是减少员工奖金的发放，来直接降低IT预算。不过，CIO也能进一步思考，如何透过IT来提升业务流程的效率与生产力，帮企业降低整体业务的预算支出。比如投资远距工作、协作 工具 、安全工具，或是评估业务上云的可能，来实际增加业务效率，并降低业务本身执行的成本。甚至，CIO还能藉此理清业务对IT的需求。最后一步，则是直接透过IT来赋予业务新价值，达到价值的优化。

对此，Gartner也提醒，CIO要制定预算缩减计划时，也要根据可能发生的场景来订定多种方案，比如以预算缩减比例为指标，在需要缩减不同比例的预算时，采取对应的措施，随着情况不同而调整。

CIO面对新冠状病毒疫情冲击，可能需要缩减IT预算，但除了预算的直接缩减，用IT来提升业务效率与生产力，进而减少业务的预算支出，也是一种解方。

微软Windows 10安装数终于达到10亿

微软在2015年正式推出Windows 10操作系统，它除了成为所有微软装置的操作系统之外，也透过定期的更新来取代名称的世代更迭，当时微软发下豪语，要在2017年中让Windows 10的全球安装数量达到10亿，不过，微软一直到本周才抵达此一目标，迟到了近3年。现在的Windows 10不只被安装在个人电脑上，它也是Xbox游戏机、Surface装置、及HoloLens所使用的平台，根据微软的统计，有超过1，000家的制造商，生产了超过8万款不同配置的Windows 10笔电与二合一装置。此外，在财富杂誌《Fortune》的全球五百大企业中，全部都使用了Windows 10装置。在Windows 10问世之后，微软放弃了每三年进行大改版并更名的Windows开发策略，而是一年进行数次的功能与安全更新。而微软在今年发表的、基于Chromium的Edge浏览器，未来将能独立更新，也能支持更多版本的Windows。在达到10亿的安装门槛之后，微软承诺未来将继续投资各种版本的Windows 10，不管是供PC使用的，或者是Windows IoT、Windows 10 Teams edition for Surface Hub、Windows Server、Windows Mixed Reality on HoloLens、Windows 10 in S mode或Windows 10X，以满足不同客户的需求。

七家科技大厂发表共同抵抗新冠状病毒的联合声明

Google、脸书、微软、Linkedin、reddit、Twitter与YouTube等网络平台，在本周发表了联合声明，承诺它们将与全球的政府医疗机构合作，递送与新冠状病毒（COVID-19）相关的正确资讯，并扫盪不实资讯，共同捍卫全球社群的健康与安全。声明的内容简单扼要，表示将在有关新冠状病毒（COVID-19）的应对上彼此合作，包括协助数百万的人们彼此联繫，也会共同对抗COVID-19病毒的诈骗与不实资讯，在各自的平台上突显官方的内容，也会与全球政府的医疗机构合作发布重大的资讯更新，亦邀请其它的企业参与，以共同捍卫人们的健康与安全。其实早在发表此一声明之前，各大科技业者都已针对新冠状病毒疫情采取了行动，例如脸书与Twitter都已禁止了可能造成伤害的不实内容，Google也宣布要移除搜寻结果与YouTube的不实内容，Google更于本周宣布要设立一个有关疫情的资讯网站，而微软则推出了新冠状病毒疫情追踪地图网站。业者的共同声明替各内容平台带来了一个因应疫情的准则，避免不实资讯的传递，或造成民众的恐慌。