云原生生态系统的持续扩展和运营复杂性的驯服

Posted 2021-04-06 开源村OSV

导语

容器和Kubernetes显然是势头强劲的，这反过来催生了一个充满活力的生态系统，该生态系统由各种各样的互补开源项目和商业产品组成。CNCF还对超过15，000名开发人员进行了认证，这些开发人员已经通过了Sharma所说的具有挑战性的考试，这是CNCF在其提供的培训课程中进行的。

正文

云原生计算基金会（CNCF）总经理Priyanka Sharma在本周在线KubeCon +大会上的主题演讲中指出，云原生开发者社区的整体规模似乎正在以每年约28％的速度增长。CloudNativeCon欧洲2020年大会。

Sharma 引用了SlashData进行的研究，称截至2月，已有650万云原生开发人员。

根据对1.7万名开发人员的半年度调查，SlashData报告估计，去年有180万开发人员增加了云原生技能，全球60％的后端开发人员现在都在使用容器。

该报告进一步指出，目前有270万开发人员在使用Kubernetes，而27％的后端开发人员已在使用Kubernetes来管理容器，同比增长了7％。但是，该报告指出，更多的后端开发人员可能会在没有意识到的情况下使用Kubernetes，因为编排引擎通常嵌入在另一个平台中。

相比之下，该报告估计现在有400万开发人员采用无服务器架构和云功能。但是，报告发现，云功能和无服务器架构的使用年复一年保持相对稳定。

Sharma表示，总的来说，容器和Kubernetes显然是势头强劲的，这反过来催生了一个充满活力的生态系统，该生态系统由各种各样的互补开源项目和商业产品组成。CNCF还对超过15，000名开发人员进行了认证，这些开发人员已经通过了Sharma所说的具有挑战性的考试，这是CNCF在其提供的培训课程中进行的。

目前尚不清楚组织在何种程度上要求认证才能填补IT职位。从理论上讲，至少，具有经过认证的容器和Kubernetes技能的IT专业人员应该能够获得更高的薪水。但是，COVID-19大流行带来的衰退对IT招聘模式产生了重大影响。许多采用Kubernetes的组织也正在投资培训现有的IT员工。

从长远来看，还不清楚Kubernetes是由内部IT员工管理还是作为云服务提供商或第三方IT服务提供商提供的服务使用。

无论采用哪种方法，随着IT组织希望部署可以在任何地方进行管理的更灵活，更具弹性的应用程序，该流行病正在加快将应用程序工作负载迁移到云的速度。作为这些努力的一部分，大多数IT专业人员接触容器和Kubernetes只是时间问题。这样的暴露自然会导致容器和Kubernetes也更广泛地用于本地IT环境，尤其是随着混合云计算策略的不断发展。

同时，获得容器和Kubernetes专业知识的IT专业人员可能会在经济困难时期享受更高的保护措施，以免被解雇。同样重要的是，具有容器和Kubernetes专业知识的IT专业人员更容易找到工作。

同时，我们也注意到DevOps的挑战性。其某些复杂性需要一个既是SaaS平台又是受管环境的平台，该平台必须在多个云提供商以及潜在的本地运行。在企业加速数字化转型的过程中，是否有一个平台可以连接应用程序和系统，同时为企业提供支持？如果采用传统方式，您将陷入一场运营噩梦中。除非您从第一天开始就使用云原生方法解决挑战。

让我们探索解决DevOps操作复杂性的三种方法。

云原生架构

为什么要使用Kubernetes？该技术是用于自动化部署，处理大规模和容器化应用程序管理的开源系统。如果主要措施是隔离运行的每个集成，请选择一个可以让您获得领先的架构组件。

经过精心设计的基于微服务并在容器上运行的应用程序可以通过以下方式从Kubernetes等技术中大量受益：

弹性和容错能力：这些是当今高度可用，始终在线的系统的关键要素。借助活动性和就绪性探针，我们可以建立一个环境，在该环境中，任何行为异常的容器都可以自动回收并准备使用新实例。

多区域群集：对于多区域群集，可以应用容错体系结构，其中在发生故障时将在区域上运行的容器自动移动到另一个区域。通过将其与Google Cloud Platform（GCP）跨区域复制卷的功能相结合，您可以提供真正的容错架构。

毫秒级恢复：任何重新启动的容器都需要数毫秒才能再次准备就绪，因此绝对不会发生中断。

微服务隔离：容器的行为异常不会影响其他容器，因为在CPU和内存使用方面有严格的限制。

以代码部署

GitOps是我们的口头禅。GitOps是一种为云原生应用程序实施连续部署的方法。通过使用开发人员已经熟悉的工具（包括Git和连续部署工具），在操作基础架构时，它着重于以开发人员为中心的体验。

这里的技术是遵循常规的Git Flow方法，并让自动化的“操作员”将更改应用于Kubernetes集群。这些运算符是运行在Kubernetes集群上的常规容器，该集群不断监视Git源存储库的更改。一旦检测到更改，操作员将自动触发更新。

对于自动化安装，请使用Helm作为部署引擎。将更改提交到Git中的Helm配置后，操作员将自动应用这些更改。

此方法实质上将经典的命令式部署模型还原为将环境中的状态由一组规则定义并由这些运算符保持同步的声明式方法，在该声明式方法中，在环境中执行操作。

也可以从单一事实来源在所有集群中实现卓越的治理水平。如果在任何环境中进行了手动更改，则操作员将检测到并返回到定义的状态。

规范混合环境

Kubernetes 功能强大，但要付出代价。维护不同的版本和发行版非常具有挑战性，尤其是在使用不同的云提供商和本地环境时。因此，您必须确定一种可以将复杂性抽象化，使操作规范化的技术。

考虑使用Google Anthos，它是基于Google Kubernetes Engine的完整Kubernetes发行版，可供GCP客户使用。多年来，谷歌完善了其Kubernetes发行版，并最终将其作为产品发布到其云平台中。这是一个精心设计的坚实平台。

如果难以在GKE中运行SaaS平台，请考虑选择Anthos作为我们所有实施，SaaS，专用SaaS或本地部署的基础。

使用诸如Anthos之类的技术的主要优势包括：

适用于基于VMware的本地环境的标准Kubernetes安装。

适用于AWS和Azure云提供商的Kubernetes引擎的连接器。

内置的配置管理功能使我们能够声明集群并使它们保持同步。

通过单个管理门户即可远程控制Kubernetes环境，因此可以轻松访问所有群集资源。

监控指标已整合到Google的StackDriver中。

这三种方法足以实现更大的可伸缩性，混合环境的管理和控制。实际上，它们是应用程序设计和操作的新思路。我坚信，它们可以帮助公司交付更好的软件，同时认识到处理企业应用程序的复杂性和挑战。

以下为今日开源领域资讯推荐：

没修补Citrix重大漏洞让黑客有机可趁，全球最大游轮业者Carnival遭勒索软件攻击

全球最大游轮业者Carnival本周坦承，该集团旗下某一品牌的资讯系统在8月15日遭到勒索软件攻击，黑客下载并加密了特定的资料，包含客户与员工资料，目前Carnival仍与执法机关及鑑识机构合作进行调查。

成立于1972年的Carnival为全球最大的游轮业者，旗下有十多个游轮品牌，包括公主游轮、爱达游轮或嘉年华游轮等，总计有超过100艘游轮在全球航行，员工数为15万，每年载运的旅客数量则有1，300万。

Carnival只透露有一个品牌的资讯系统被黑客入侵，员工与客户资料被存取，系统遭加密，但并未公布被骇品牌或勒索软件名称，只强调其它品牌或该公司的营运并未受到波及。

在Bleeping Computer发表该新闻时，资安业者Bad Packets旋即回覆该攻击行动并不令人讶异，因为Carnival使用了许多含有CVE-2019-19781漏洞的Citrix服务器。

CVE-2019-19781漏洞藏匿在Citrix应用程序交付控制器（Application Delivery Controller，ADC）与Citrix Gateway上，前者为一应用程序交付与负载平衡解决方案，后者则是一个自远端存取混合云端与SaaS服务的解决方案，皆为Citrix的知名产品。

CVE-2019-19781属于路径穿越漏洞，成功的开採将允许黑客无需经过认证而执行任意程序，在去年12月揭露后，攻击程序在一个月内便现身，使得美国国土安全部及Citrix相继释出CVE-2019-19781漏洞扫描工具，协助使用者辨识系统上是否含有该漏洞以便展开修补。

Carnival显然没有採取最佳安全措施，此一案例再度彰显了及时修补重大安全漏洞的重要性。

Mozilla裁员衝击Rust发展，官方急成立基金会稳阵脚

Rust项目发展的歷史，最早可以追溯到2006年，是由Mozilla Research启动的项目，长期目标是要让Rust成为一个可自营运的项目，在2015年的时候，Rust正式发布了1.0版本，确定独立于Mozilla，是一个自指导与治理的自治组织，Mozilla仅扮演赞助财务和法律服务的角色。

就在最近，Mozilla发布了重组公司的消息，于8月11日裁员250人，甚至连Mozilla在臺北的办公室都被关闭。被裁员的员工中，包括了部分积极参与Rust项目和社群的人，而这带给Rust项目许多不确定性，因此Rust官方开始着手解决面临的问题。

Mozilla裁员确实对Rust社群成员造成影响，虽然如此，官方提到，Rust是一个开源社群，有来自不同背景的贡献者，而多样性是支撑Rust项目重要的力量。Rust官方试图澄清Mozilla与Rust项目之间的关係，官方表示，部分参与领导Rust项目的成员，过去的确是Mozilla的员工，但是这些Mozilla员工都是利用个人时间贡献项目，Rust项目并非这些员工在Mozilla工作的一部分。

而且Rust团队的成员资格是授与个人，跟雇主没有关係，即便这些塬为Mozilla员工的Rust团队成员，遭到了裁员，他们仍然是Rust团队的成员，官方表示，虽然这些之中有一些人，可能会选择减少参与，也并非所有人都能够继续做出贡献，官方也会选择尊重，并且感谢他们过去对项目的贡献。

官方提到，不少企业虽有兴趣在财务上资助Rust项目，但误解Rust项目为Mozilla所有，使他们不愿投资，而创建基金会则将项目独立运作这件事付诸实践，使Rust项目真正由独立组织运作，同时成立基金会可使赞助更为直觉，提供企业明确资助项目的方法。

对成立开源基金会有经验的Rust团队成员，讨论了当前的形势，并且确认了成立基金会需要的资源，Rust核心团队与Mozilla共同宣布创建Rust基金会的计画，预计Rust基金会将会在年底前，开始启动营运。

Rust基金会的首要目标是取得所有权，包括Rust、Cargo和crates.io相关的各种商标和域名，都会进到基金会中，而基金会也会负担产生的费用。目前已经有不少大型企业皆持续赞助Rust项目，包括微软、AWS、Integer 32、1Password、ARM、Google云端、GitHub以及Mozilla，微软赞助Rust的CI支出，而AWS支付Rust项目使用S3的费用，在成立基金会之后，Mozilla对Rust项目的影响将会减弱，角色煺回到仅是赞助商之一。

甲骨文也有意买下TikTok

金融时报本周引述消息来源报导，除了微软与Twitter之外，甲骨文（Oracle）也正在考虑买下字节跳动位于美国、加拿大、澳洲及纽西兰的TikTok服务。

根据报导，甲骨文联手字节跳动的既有股东，包括General Atlantic与Sequoia Capital等，且已与字节跳动展开协商。

外界估计TikTok的身价超过500亿美元，而Twitter的市值只有300亿美元，因此相较于Twitter，市值接近1，700亿美元的甲骨文，再加上联手既有的字节跳动股东，将握有足以于微软竞争的筹码。

只不过，令外界好奇的是，身为全球第二大软件公司，专门提供企业软件服务且并无任何消费者服务的甲骨文，为何想入主TikTok，有分析师认为，一来甲骨文拥有庞大的云端架构，得以支撑这4个TikTok市场的运作，以及存放大量的使用者资料，同时也可藉此推广甲骨文Data Cloud的广告业务。

另一方面，金融时报也指出，其实微软正在认真考虑接管字节跳动在全球的TikTok服务，但字节跳动目前并不想出售上述4个市场以外的TikTok服务。

渠道激活专题文章推荐：

01

进入2020年，新冠状病毒疫情突发，云计算市场渠道招募和拓展工作也受到了一些影响，甚至在业界，已经很少人再谈及渠道一词了。但，绝不会永远这样。

02

从开源云计算厂商此前进行的渠道拓展来看：首先，整个渠道拓展体系从不是随意建立，而是需要根据不同区域市场情况，以及渠道伙伴拥有的不同技术能力来进行内容宣导。其次，渠道内容的设计和组织也不是自由的，要根据行业客户实际场景需求来做相应输出。

03

开源云计算厂商通常会构建大量的产品线和复杂的解决方案体系，这就需要借助渠道伙伴的力量面向最终用户输出，以此保障最佳客户体验和售后支持。因此，渠道伙伴在开源云计算市场拓展方面的能力强弱，关系到厂商整体的市场战略实施效果。

04

             

在近几年，很多开源云计算厂商携手渠道伙伴共同应对云化时代的变化与挑战，加速行业云计算转型。实际上，这一调整意味着开源云计算厂商将更加重视与伙伴的生态合作，并鼓励合作伙伴发挥各自优势，协同为客户传递价值。但开源村也发现，也还有很多开源云计算厂商没有成功建立起自己的渠道体系。

05

云化时代到来之际，行业客户业务场景会根据云化转型的节奏进行调整。开源云计算服务提供商在此时的作用是帮助渠道伙伴学会借助平台之力，满足行业客户的真实需求。这是相比友商而言，更具竞争优势之处。优质的平台，会助力渠道伙伴获得更多行业用户的信任。

06

对于开源云计算厂商而言，如果希望在抢滩新基建上构建差异化竞争优势，具备高超的售前技能、售后体验，并拥有创新的技术服务能力与解决方案构建能力是实有必要的。巧了，这些都与渠道构建息息相关。

07

私有云凉了么？当然没有！连当事人都出来辟谣了！私有云需不需要渠道？当然需要！没有渠道，开源云厂商怎么为私有云产品、营销和销售提供售前支持？没有渠道，开源云厂商怎么能够既少花钱，又能实现高效、便捷、快速的售后服务？

08

开源云计算市场竞争激烈、用户需求多变，对于怎样带货，怎样推动市场增长，也成为让很多厂商头疼的事。开源村觉得，开源云计算渠道虽不比网红，但此时应当勇于站出，全面激发和表现出自身的“带货”实力。

09

有报道称，一名开发者用两年的业余时间开发并维护了一个开源项目因为微软的剽窃而被迫中止。有网友评论说，这也是很多大公司的通用策略，比如组织技术人员与之交流，然后套取有用信息，然后发展自己的产品，这在中国叫做“偷艺”。事实上，设想一下，如果这个项目能够早日产品化，并且建构好了一套成熟的市场分发渠道，或许形势就会完全不同。