如何基于K8s管理1600个微服务？某数字化银行秘诀公开

2020年3月17日，业界应用最为广泛的Kubernetes管理平台创建者Rancher Labs（以下简称Rancher）宣布完成新一轮4000万美元D轮融资，本轮融资由Telstra Ventures领投，既有投资者Mayfield、Nexus Venture Partners、国富绿景创投（GRC SinoGreen）和F&G Ventures跟投。Telstra Venture的投资者之一澳大利亚电信（Telstra Corporation）是澳大利亚最大的电信企业，同时也是Rancher的客户。

此前，Rancher曾在2019年7月获得C轮2500万美元融资，2016年获得B轮2000万美元融资，2015年获得A轮1000万美元融资。新一轮融资使Rancher融资总金额累计至9500万美元（逾6亿6千万人民币）。Rancher透露，本轮融资用于进一步推动产品的持续创新，加大对Go-To-Market的投入，以及拓宽Kubernetes在全新市场与行业中的无限可能。

Rancher成立于2014年，由CloudStack之父梁胜创建，是业界领先的企业级容器管理软件提供商，帮助用户轻松地统一管理在数据中心、云、分支机构和边缘运行的Kubernetes集群。得益于企业对Kubernetes的强劲需求，以及Rancher创新且独特的功能和价值主张，2019年，Rancher全球营业收入同比增长169%，客户数量同比增长100%。

“这一轮融资再次说明，投资机构对Kubernetes市场及Rancher的技术实力充满了信心。”Rancher联合创始人及CEO梁胜表示：“正如Linux在21世纪初成为了数据中心、云和设备的标准计算平台一样，我们充分相信，Kubernetes将于2020年迅速成长为多云及异构IT环境中无处不在的企业计算平台。”

Rancher，推动计算无处不在

第三方数据统计公司451 Research在研究指出，到2022年，76%的企业将采用Kubernetes作为标准的基础设施计算平台。这一数据充分表明，Kubernetes将成为与企业IT战略和云原生应用程序关联度最高的平台。Rancher的旗舰产品Rancher是业界应用最为广泛的Kubernetes管理平台，全球累计下载次数逾一亿次，拥有知名企业客户逾40，000家。除此之外，Rancher还围绕Kubernetes生态进行了一系列的延展与探索，其中Rancher推出的轻量级Kubernetes发行版k3s是目前业界公认的边缘Kubernetes最佳解决方案。

Rancher+k3s组成了Rancher “Kubernetes即服务（Kubernetes-as-a-Service）”解决方案堆栈，将Kubernetes的能力从数据中心、云端延展至边缘端，充分赋予企业在任何基础设施上部署Kubernetes的自由。梁胜表示，未来，Rancher将在产品、行业解决方案和团队建设三个方向发力，为企业在生产环境中落地Kubernetes提供更为夯实的基础。

在产品方面， Rancher将持续发力让Kubernetes进一步成为通用计算标准，在Kubernetes关键领域进行持续创新，包括异构集群联邦（heterogenous cluster federation）、车队管理（fleet management）和边缘计算环境中的Kubernetes落地等等。

更重要的是，Rancher还将凭借其自身在Kubernetes领域的领导者地位，与其他领先的科技公司合作，在5G、数字工厂、车联网、视频监控和医学研究等领域共同开发基于Kubernetes的行业解决方案，拓展Kubernetes在新行业与新领域的无限可能。

在全球扩张及团队建设方面，Rancher将扩大现有的销售、市场、财务、运营、客户成功和客户支持团队。此外，Rancher全球团队分布当前已覆盖14个国家，未来还将进一步在地理版图上扩大国家与城市的覆盖率，为全球企业客户提供更为专业的技术服务。

尤为值得一提的是，2019年全年，Rancher在大中华地区的业务年复合增长率超越300%，中国有望成为Kubernetes全球增长最快的企业级市场。正是基于对中国Kubernetes市场的看好，Rancher已于2020年2月完成了中国本土化和国产化，从2020年3月1日开始，Rancher在中国大陆、香港澳门地区、台湾地区的业务，均由全中资公司Rancher中国云澈信息技术（深圳）有限公司承载，并面向中国企业客户提供了中国企业版Rancher产品和中国版k3s边缘计算平台。

Telstra Ventures，独特的“客户变投资人”

澳大利亚电信（Telstra Corporation）以Rancher为基础，打造了企业核心的客户联络中心、客户网络以及客户服务中心。正是澳大利亚电信的成功案例，以及其间Rancher展现出的强大的技术实力吸引了Telstra Ventures，使其对Rancher产生了浓厚的兴趣。

Telstra Ventures是一家全球知名的战略风投机构，专注于市场领先及拥有出色产品的高增长技术企业的投资，由全球20大电信运营商之一的澳大利亚电信（Telstra Corporation）和全球最大的私募股权资金之一HarbourVest两名战略投资者共同构成。

Telstra Ventures参与投资的知名技术企业包括开源代码库GitLab、企业云档案管理Box、电子签名认证DocuSign和终端安全防护平台CrowdStrike等。

“除谷歌外，Rancher是全球首家意识到Kubernetes将对IT市场产生深远影响的公司之一。在我们进行早期投资相关讨论的时候，梁胜曾表示‘Kubernetes具有成为云计算的TCP/IP协议角色的潜力’，这是一个极具吸引力且令人印象深刻的描述。”负责Telstra Venture企业投资的投资合伙人Steve Schmidt感叹道。

对于像Telstra一样正在部署5G的领先电信公司而言，Rancher无疑是令人无法忽视的存在。“我们相信，Rancher将在把Kubernetes引入5G的方向上起到独特的桥梁作用。”

另一方面，梁胜在云计算领域的丰富履历及技术魅力也是促使Telstra Venture投资Rancher的另一关键要素。作为全球知名的风投机构，Telstra Ventures一直致力于寻找世界一流的企业家。他们认为，世界一流的企业家可以打造出色的产品，同时也能成功地将其推广向市场。

“我们的使命是‘与非凡的人合作’，在接触梁胜后，我们坚信他是一个世界一流的企业家。”Steve Schmidt补充道：“更为显而易见的是，Rancher正在梁胜及其创始团队的带领下走向卓越。”

最后，Rancher中国CEO秦小康总结道：“容器技术在全球新一轮技术创新及应用领域的广阔前景正在逐步展开，我们尤其看好实现国产化和本地化的Rancher中国强劲的发展前景。在全新的发展阶段和下一代技术浪潮中，Rancher中国也将与广大中国用户和合作伙伴一起，践行‘Computing Everywhere’的新一代计算平台理念，以持续创新的技术能力，为中国客户数字化信息化建设保驾护航。”

GitLab发布实验性新功能Partial Clone

Git近期版本开始支持部分复制（Partial Clone）功能，而程式码托管服务GitHub与GitLab也开始跟进，GitHub在年初时提到他们正在评估部分复制功能，成熟时会逐步发布，而GitLab现在则宣布开始提供部分复制功能实验性测试。部分复制是Git的一项新功能，用来取代Git LFS（Large File Storage），部分复制使Git不再下载储存库中的每个档案，使其在大型储存库运作得更好。部分复制经GitLab、GitHub、微软和Google多年合作发展，在近期开花结果，现在于GitLab中开始实验性测试，管理员可以视情况启用该功能。

Git发展至今已经快15年，过去有许多项目不使用Git，因为像是电玩游戏这类具有许多大型二进位档案的项目，当Git复制储存库时，Git会下载储存库中每个档案的每个版本，在大多数的使用情况中，下载歷史纪录或许是有用的功能，但大型二进位档案的复制和撷取速度却非常慢。而要在Git处理大型档案，需要额外的工具，像是2010年发布的git-annex和2015年的Git LFS，以类似的方式增加Git处理大型档案的能力，其主要中心思想是，不在Git中储存大型档案，而是储存大型档案的指标，当需要使用到大型档案时，再使用指标按需下载档案。

不过，这种方法的缺点不只是易受人为错误影响，而且指针的编码方式依频宽以及档案类型决定，并同时影响储存库的所有人，由于对频宽或是储存的假设，会随着时间改变，同时也会依位置而有所不同，但是储存库的编码策略却不够灵活到可随时改变。现在推出的部分复制功能可解决这些问题，因为传输的资料较少，加快了撷取和复制的速度，也减少本机电脑的硬盘使用量，GitLab以自家gitlab-com项目举例，复制速度快50％，传输资料量减少70％。

当用户在普通的git clone指令之后加入过滤器规範，就能以该规範排除特定内容，像是使用—filter=blob:none，就可在复制时排除大型二进位档案，GitLab提到，在像是gitlab-com这类包含许多图像的项目上使用，更能体现出部分复制的优点。

GitLab的部分复制现在支持多个远端服务器，而且将会让大型档案可以储存在像是AWS S3等物件储存中，但与Git LFS不同的是，储存库或是实例管理员，可以决定物件储存的位置，以及按需求改变配置。部分复制比Git LFS使用起来更简单，因为Git LFS需要安装其他工具，而部分复制不需要，不过使用者仍需要学习使用新选项和配置。

由于在最新的Git 2.25中，过滤功能并未最佳化，因此当使用过滤规範要从Git服务器中，撷取并排除特定物件，Git需要检查储存库中的每个档案，并排除所有与过滤器规範相符的物件，不过，Git开发社群已经改进Blob大小过滤效能，预计会在Git 2.26中更新，GitLab计画会在12.10版本中跟进。

近期Git在复制相关功能的更新，除了增加部分复制功能外，也新增了稀疏签出（Sparse Checkout）功能，GitLab解释，部分复制是针对大型储存库的特定效能最佳化，而稀疏签出则是一个相关的最佳化功能，特别针对具有极大量档案和版本的储存库。

GitHub同意购买代码分发初创公司Npm

微软的GitHub子公司周一表示，已同意收购Npm，这是一家经营在线服务的公司，该服务用于分发以流行的JavaScript编程语言编写的开源软件包，并提供公司可用于其专有代码的软件。这项新交易表明，尽管微软一直在分发诸如Windows之类的价格昂贵的产品，但微软却在帮助个人和企业开发人员采用开源软件的战略上加倍努力。微软在2018年以75亿美元的价格收购了GitHub，这是一个用于许多开源项目的在线存储库，根据初创公司Stack Overflow的最新调查，这一策略特别是在JavaScript中为开发人员提供了最有效的帮助。
去年5月，GitHub引入了Package Registry服务，它代表了Npm的竞争程度。允许人们从他们的代码中发布新软件包。“对于使用npm Pro，Team和Enterprise托管私人注册表的付费客户，我们将继续为您提供支持。GitHub首席执行官Nat Friedman在博客中写道：“我们还大力投资GitHub Packages，将其作为与GitHub完全集成的强大的多语言包注册中心。” “今年晚些时候，我们将使npm的付费客户能够将其私人npm软件包移至GitHub软件包，从而使npm可以专注于成为JavaScript的大型公共注册表。”
“当我在旧金山的GitHub HQ看到GitHub Packages beta公告和演示时，我记得转向Shanku Niyogi时，笨拙地脱口而出，'你为什么不打算收购我们？'” Npm软件包的发明者Isaac Schlueter Npm的经理兼创始人在周一的博客中写道。
Npm成立于2014年，总部位于加利福尼亚州奥克兰，拥有46名员工。开源的Npm软件包管理器的日期为2009年。初创公司的投资者包括Bessemer Venture Partners和True Ventures。截至周一，Npm主页将Microsoft以及Adobe，Nike和Salesforce列为“感恩地服务”的公司之一。

Oteemo启动企业Kubernetes和云原生培训计划

企业DevSecOps和Cloud Native Transformation咨询公司Oteemo近日启动了其企业kubernetes和Cloud Native学习计划。该计划旨在提高整个IT组织在Kubernetes和Cloud Native计算原理上的技能。企业Kubernetes和Cloud Native培训计划，面向希望通过容器和kubernetes将其团队从传统应用程序开发转变为现代Cloud Native开发的IT组织，面向希望通过容器和kubernetes将其团队从传统应用程序开发转变为现代Cloud Native开发的IT组织。

随着IT企业将Kubernetes和Cloud Native视为其数字化转型旅程的核心部分，CIO，CTO和IT组织领导者的主要关注点是为其全体员工提供正确的培训，并将他们从进行遗留应用程序开发转变为实施现代技术。使用云原生范例进行应用程序开发。

“我们很高兴启动我们的企业kubernetes和云原生学习计划。通过该计划，我们将能够全面考察IT组织并创建学习策略，以提升其IT团队在kubernetes和cloud native上的技能通过此计划，我们认为我们可以帮助我们的客户快速而持续地培训他们最重要的资产-他们的员工-在他们将组织转变为云计算的过程中获得最大的培训投资回报Oteemo首席执行官Raja Gudepu说。该计划将满足IT组织中的以下关键角色；软件开发人员，DevOps工程师，站点可靠性工程师，项目经理和执行人员。针对每种角色都有单独的培训课程。该计划的独特性基于其个性化和自定义功能，这将使Oteemo可以根据组织当前的IT生态系统，技能水平和用例进行培训。

了解更多：

https://news.yahoo.com/oteemo-launches-enterprise-kubernetes-cloud-170000400.html

有关使用Kubernetes获得全栈可见性监控的最佳实践

微服务（现在已成为我们构建基础架构的实际选择）为容器铺平了道路。借助Docker以及用于容器编排的Kubernetes等工具，组织现在可以更快，更大规模地发布应用程序。但是，所有这些功能和自动化带来了挑战，尤其是如何保持对这些临时基础结构的可见。Kubernetes很复杂。为了成功使用它，它需要同时监视几个组件。为了简化监控策略，请将监控操作分为几个区域，每个部分都涉及Kubernetes环境的单个层。然后从上到下分解对工作负载的监视：集群、pod、应用程序以及最终用户体验。

该集群是Kubernetes的最高级别组成部分。大多数Kubernetes安装只有一个集群。这就是为什幺当您监视群集时，可以在所有区域看到完整的视图。并且可以轻松地确定组成集群的Pod，节点和应用程序的运行状况。使用联合部署多个群集时，必须分别监视每个群集。您将在集群级别监视的区域是：

失败的Pod：失败和中止的Pod是Kubernetes进程的正常部分。当Pod应该以更高的效率工作或处于非活动状态时，调查Pod故障异常背后的原因至关重要。

节点负载：跟踪每个节点上的负载对于监视效率是不可或缺的。一些节点可能比其他节点使用更多。重新平衡负载分配是保持工作负载流畅和有效的关键。这可以通过DaemsonSets完成。

群集使用情况：通过监视群集基础结构，您可以调整使用中的节点数量并分配资源以有效地为工作负载供电。您可以查看资源的利用方式，从而可以扩大或缩小规模，并避免了额外基础架构的成本。

集群监控提供了Kubernetes环境的宏观视图，但是从单个Pod收集数据也是必不可少的。它揭示了各个Pod的运行状况以及它们托管的工作负载。在集群之外，您可以在粒度级别上更清晰地了解Pod的性能。这里将监视：

吊舱实例总数：吊舱实例必须足够，以确保高可用性。这样就不会浪费托管带宽，并且您不会运行超出所需数量的Pod实例。

Pod部署：监视Pod部署可让您查看是否存在任何可能降低Pod可用性的错误配置。请务必注意资源如何分配到节点。

实际的Pod实例：监视每个Pod正在运行的实例数与预期运行的实例数，将揭示如何重新分配资源以实现Pod实例的所需状态。如果您看到不同的指标，则副本集可能配置错误，因此定期进行分析很重要。

监视群集中托管的应用程序对于成功至关重要。应用程序监控发现的问题可能是Kubernetes环境或应用程序代码中的问题。通过监视应用程序，您可以识别故障并立即解决它们。 了解更多，请后台回复指令：全栈可见性监控。

微服务管理器Istio 1.5中的网络代理Envoy，开始支持WebAssembly增加动态可扩充性

Google、Lyft及IBM合作开发的微服务管理器Istio，最近推出了1.5版本，而Google说明这个版本其中最大的特色，便是Istio的网络代理Envoy开始支持WebAssembly，而这让Envoy和Istio能够获得WebAssembly扩充套件的加持，借以将Istio可扩展性从控制层（Control Plane）移到侧车代理（Sidecar Proxy）。目前这项功能还在Alpha测试阶段。

Lyfty在2016年开源了Envoy服务代理项目，现在逐渐成为云端原生应用程式部署的固定工具，包括在边缘以及侧车应用都受到欢迎。Envoy原本就有其扩充机制，可以使用预编译的C++模组或是Lua脚本增加扩充功能，但Google提到，这两者都有其缺点，由于Istio的设计目标之一，就是要简化政策、遥测和日誌系统的扩充性，虽然使用控制层元件和程序外配置器可以达到这目的，但是却会增加多余的网络跳跃点以及延迟。

WebAssembly是一种二元指令格式，Istio现在透过Envoy把WebAssembly带进服务器端中。WebAssembly现在已经是W3C推荐的网页应用标准，使用者可从30多种语言编译成WebAssembly程式码，并在沙盒环境中执行。透过WebAssembly在Envoy代理中扩充功能，则不需要重新编译程式码，部署也更加简单，Istio能够将扩充套件发布给代理，在不需要重新启动的情况下，载入扩充套件。

Envoy项目创造者Matt Klein提到，在Envoy中支持WebAssembly，将会解开更多服务网状网络和API闸道的使用案例。而为了要强化WebAssembly扩充套件的使用体验，他们与Solo.io合作，Solo.io创建了WebAssembly Hub服务，可用来建置、共享、探索和部署WebAssembly扩充套件，让使用者够简单地将WebAssembly扩充套件部署到Envoy上。

WebAssembly Hub高度自动化了开发和部署WebAssembly扩充套件的步骤，使用WebAssembly Hub工具，使用者可以轻松地将任何支持的语言程式码，编译成为WebAssembly扩充套件，接着把这些扩充套件上传至Hub註册服务中，用户只要使用单个指令，就可以将扩充套件部署至Istio中。

Google提到，WebAssembly扩充套件与容器一样易于管理，能简单地安装以及执行。

WebAssembly Hub在背后处理了许多细节问题，像是ABI版本验证和权限控制等问题，而且也会自动扩展部署，减少跨Istio服务代理配置的麻烦，避免配置错误或是版本不符的意外错误。

目前Envoy支持WebAssembly的功能，仍在Alpha测试中，接下来开发团队会最终确定ABI，并将其转变为标准，以在标准组织中取得更广泛的回馈。另外，Google提到，他们会继续向Envoy上游项目提供支持，并且为相关工具以及WebAssembly Hub寻找适合的社群。

捷克新冠状病毒筛检中心遭黑客攻击

位于捷克第二大城布尔诺（Brno）的布尔诺大学医院，在上周传出遭到网络攻击，布尔诺大学医院不仅是当地的大学医院，也是捷克18个新冠状病毒（COVID-19）筛检中心之一，就在欧洲开始因新冠状病毒疫情的扩散，而造成医疗资源吃紧之际，此一攻击行动无疑令当地的防疫能力雪上加霜。

目前该大学医院尚未对外公布详细的资讯，只说该院的电脑系统在上周五（3/13）遭到攻击而陆续当机，最后只得将电脑系统关闭。外传医院员工还被交代不要开启电脑，而信息安全专家则推测，可能是遭到勒索软件攻击。

不过，由于布尔诺大学医院目前，正在筛检数十个可能罹患新冠状病毒的案例，原本一天就能取得结果，但因院方遭受攻击之故，相关筛检作业可能要拉长到数天。

信息安全业者Emsisoft针对美国勒索软件调查显示，去年前三季美国有621个组织遭到勒索软件攻击，当中就有491个隶属于健康医疗领域，老旧的系统再加上IT资源不足，都让医疗院所成为黑客的目标。而在此一全球对医疗资源需求甚殷的时刻，信息安全专家也只能再度奉劝医院提高警觉，及时修补所有系统的安全漏洞。

Slack修补了可用来接管大量帐号的安全漏洞

安全研究人员Evan Custodio在本周公布了一个存在于Slack上的安全漏洞，该漏洞将允许黑客接管大量的Slack帐号，不过，Custodio早在去年11月便透过HackerOne平台提报了该漏洞，Slack则在得知漏洞的24小时内完成修补，也颁发6，500美元的抓漏奖金予Custodio。

根据Custodio的说明，Slack平台上含有一个「HTTP 请求走私」（HTTP Request Smuggling）漏洞，将允许黑客针对邻近的客户请求，执行基于CL.TE的挟持行动，迫使受害者进入开放式重定向，把受害者及其Slack网域cookies转移到黑客的协作客户端，而当中即含有客户的秘密期间cookie，将使得黑客得以接管任何Slack用户的使用期间。

Custodio认为，这是一个严重的安全漏洞，将可曝露大多数的Slack用户资料，黑客可建立多个机器人以展开持续性的攻击，先是接管Slack用户的使用期间，进而窃取用户资料。

苹果、Google、微软及Amazon出面反对美国制定歧视LGBTQ族群的法案

包括Amazon、Google、微软、苹果、PayPal及IBM等逾40家企业，在本周连署了一份公开信，宣称它们拥护多样性与包容性，鼓励员工呈现真实的自我，因此反对美国订定各种歧视同性恋、双性恋、跨性别或不明性别等族群的法令。

此一公开信是由Freedom for All Americans（FFAA）所发起的，这是一个专门反对歧视LGBTQ族群的运动，该运动追踪并公布了美国各州所拟定的、与LGBTQ族群相关的法案，并邀请支持该运动理念的组织或企业参与。在FFAA所列出的歧视LGBTQ族群的数十个法案中，有的是LGBTQ希望推动的非歧视法案，也有些是针对LGBTQ族群所制定的不平等法案。

此一公开信表达了对LGBTQ族群的支持，指出不管是公平，或是平等的待遇与机会，都是企业最重要的价值观之一，他们关注那些不平等对待LGBTQ族群的法案，因为相关法案不仅会损害团队成员及其家人，剥夺他们的机会，也会让他们在社群中感到不受欢迎，甚至是处于危险当中。这些企业指出，某些州准备制定的LGBTQ歧视法案可能直接影响公司的业务，唿吁美国政府应该放弃或反对制定歧视性的法规，应该公平对待所有的美国人。

关于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中仍需要对容器网络的性能进行改进。

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更于本周宣布要设立一个有关疫情的资讯网站，而微软则推出了新冠状病毒疫情追踪地图网站。业者的共同声明替各内容平台带来了一个因应疫情的准则，避免不实资讯的传递，或造成民众的恐慌。

Khronos推开放跨平台Vulkan光线追踪加速功能

多媒体标準制定组织Khronos发布了Vulkan光线追踪（Ray Tracing）临时扩展，而这是第一个开放、跨供应商与跨平台的光线追踪加速框架。开发者社群可在最终规格确定之前，提供回馈帮助官方进行调整。

Vulkan是一个开放免版税的的高效能绘图API，可跨平台取用GPU资源，现在已经于许多热门的游戏引擎、游戏以及应用程序中支持。Vulkan在2015年的游戏开发者大会中发表，要提供与Direct3D和OpenGL类似的功能，与两者不同的是，Vulkan是一个底层API，可以良好地使用多个CPU核心，更擅于处理平行任务。Vulkan支持非常广泛的平台，包括各式个人电脑、行动装置以及嵌入式操作系统。

Khronos现在发布的Vulkan光线追踪临时扩展，可以满足桌面电脑，对即时与离线光线追踪的需求。光线追踪是一种图像渲染技术，可以真实地模拟光线与场景几何图形、材质与光源互动的情况，以产生逼真的场景渲染图。这项技术被广泛的应用在电影以及艺术作品中，随着硬体运算能力的提升，这项技术也逐渐在即时应用程序和游戏中实作。

Vulkan光线追踪扩充将光线追踪框架无缝地整合进Vulkan API，开发者现在可于多媒体应用中，灵活地合併使用光栅化（Rasterization）与光线追踪来渲染画面。Vulkan光线追踪扩充经特别设计，使其运算无关硬体，因此可用在现有GPU和光线追踪专用核心上，进行光线追踪加速运算。Khronos的Vulkan光线追踪任务小组负责人Daniel Koch提到，开发人员对于跨平台光线追踪加速API有很高的需求，而现在推出的Vulkan光线追踪扩充则能满足这些需求。

Vulkan光线追踪的整体基础架构，与市面上现存的专有光线追踪API相似，但Vulkan光线追踪框架有更多新的功能与实作弹性，开发者可简单地进行移植。新框架由一系列Vulkan、标準移植中介表示语言SPIR-V（Standard Portable Intermediate Representation）与GLSL扩充组成，并非所有扩充都是必要元件，部分扩充为可选项目。

而Khronos也在Vulkan光线追踪扩充中，增加对微软开源HLSL编译器的支持，让开发者可做最少的修正，就能使用微软定义的语法，在HLSL中编写Vulkan光线追踪SPIR-V着色器相关程序码。官方提到，当所有相关的元件都更新到上游，包含光线追踪扩充的Vulkan SDK就会释出。

BitDefender强化端点进阶威胁侦测

端点防护发展至今，许多防毒厂商都在端点防护平台（EPP）之外，提供了端点侦测与回应（EDR）的模组。但也有厂商并非将EDR视为独立产品，而是纳为端点防毒产品套餐的进阶功能，像是BitDefender 就提供含有这种模组的GravityZone Ultra，让企业能够同时取得防毒和EDR的保护能力。

针对端点电脑的威胁侦测与回应，这组套件提供的功能，包括了事件记录、威胁分析，以及比对IoC特徵。以事件调查而言，该系统采用黑名单及网路隔离，除了图像化的分析功能与黑名单封锁机制，若是资安人员想要运用沙箱检测来分析档案是否被植入恶意软体，这裡提供云端沙箱做为模拟触发的环境。GravityZone Ultra近期的改版，也持续强化威胁的侦测，可防御网路攻击、异常行为，以及无档案攻击等面向。举例来说，面对基于网路流量的攻击行为，GravityZone Ultra能藉由多种面向来加以侦测，进而在攻击发生之前封锁。

而在异常行为的侦测上，GravityZone Ultra不只能搭配BitDefender定义的入侵指标，也整合了MITRE ATT&CK攻击框架的知识库，能自动标记需要特别留意的现象。至于无档案攻击的防御，这套系统则是针对透过任何命令转译器的攻击行为，例如近期时有所闻的PowerShell无档案攻击，增加额外侦测的功能，以便在执行之前封锁。

值得一提的是，对于Windows端点电脑是否存在含有风险的设置，塬厂在GravityZone Ultra套餐中，纳入Endpoint Risk Analytics（ERA）模组，以供资安人员快速判读端点电脑是否安全。这项模组针对3种面向，进行解析，分别是网页浏览器安全、网路设置，以及操作系统安全基準等。

以网路设置的部分而言，该模组会检查是否存在没有设置密码的使用者帐号，或者电脑是否连接网域等，以求端点电脑能符合资安政策的要求配置。而在ERA裡，也针对Office巨集的设定，以及上网应用程序存放凭证等，判断电脑是否存在风险。

Amazon Elastic Inference新增支持PyTorch机器学习模型

AWS现在让用户可以在机器学习服务Amazon SageMaker以及运算服务Amazon EC2中，以Amazon Elastic Inference服务运用PyTorch模型进行预测，而由于Elastic Inference可让用户附加适当的GPU运算资源，不只能够用GPU加速预测工作，付出的成本也低于使用独立GPU执行个体。PyTorch是脸书在2018年底释出的深度学习框架，由于其采用动态运算图（Dynamic Computational Graph），因此可让开发者简单地运用指令式程序设计方法，以Python开发深度学习模型，AWS提到，使用PyTorch这类框架开发深度学习应用程序，预测阶段可占全部运算资源的90％。

要为执行预测工作，选择适当的执行个体规格并不简单，因为深度学习模型需要不同数量的GPU、CPU和记忆体资源。使用独立GPU执行个体通常过于浪费，虽然速度很快，但因为独立GPU执行个体通常为模型训练工作设计，而大多数预测工作通常都只会是单一输入，即便是尖峰负载也不会用上所有GPU容量，因此可能会造成资源浪费。

Amazon Elastic Inference可让用户在SageMaker和EC2执行个体，附上适当的GPU资源来加速预测工作。因此用户可以选择应用程序需要的CPU和记忆体规格的执行个体，并且额外附加适当的GPU容量，以更有效的方式使用资源，并且降低预测成本。Amazon Elastic Inference服务之前只支持TensorFlow和Apache MXNet框架，而现在还额外多支持PyTorch。

要把PyTorch用在Elastic Inference中，必须要把模型先转换成TorchScript格式。TorchScript是可将PyTorch程序码转换成序列化与最佳化模型的方法，AWS表示，因为PyTorch使用动态运算图大幅简化模型开发的过程，但是这种方法同时也增加模型部署的困难，在生产环境中，模型以静态图（Static Graph）表示较佳，不只使模型可以在非Python环境中使用，而且还可以最佳化其效能和记忆体使用量。

TorchScript便可编译PyTorch模型，使其以非Python的方式表示，能在各种环境中执行，TorchScript也会对模型进行即时（Just-In-Time）图最佳化，使编译过的模型比起塬本的PyTorch模型效能还要好。

AWS比较附加Elastic Inference、独立GPU与纯CPU叁类型执行个体的延迟与成本。CPU执行个体效能较差，预测延迟最长。独立GPU执行个体的预测效能则最好，速度约是CPU执行个体的7倍。而有使用Elastic Inference的CPU执行个体，因为获得GPU的加速，虽然预测速度仍然比独立GPU执行个体慢，但是比纯CPU执行个体快了近3倍。

而在成本上，纯CPU执行个体的每次预测成本最高，AWS解释，虽然CPU执行个体每小时的成本最低，但因为每次预测的时间较长，反使得单次成本较高，而每次预测价格最低的则是Elastic Inference，还可灵活地分离主机实体和推理加速硬体，组合出最适合应用程序的运算资源。