继往方可开来:Kubernetes 2018态势回顾与2019年前景展望


【编者的话】2018年Giant Swarm公司联合创始人Oliver Thylmann对Kubernetes的走向做了自己的预测和简单的分析。2019年初笔者再次回顾2018年的预测博客,是应验了?还是偏离了实时呢?让我们看下笔者在年初的总结,以及自己对于2019年Kubernetes的走向预测。
the-state-of-kubernetes-2019.jpg





去年我写了一篇题为《Kubernetes过去到未来之旅》的文章。在本文中,我谈到了我们技术栈的KVM与AWS版本,以及即将推出的Azure版本。此外,我还提到了最近两年如过山车一般起伏不定的技术变化态势。

下面,我们一同回顾一下去年我做出的部分预测:

1. Kubernetes将进一步成为“云API”(The Cloud API)

我想我们可以回看这一条预测。过去的12个月时间里,Kubernetes已经成为绝对的焦点,在增长度和关注度方面皆拥有惊人表现。BM收购了Redhat并借此将OpenShift招至麾下,VMware买下Heptio,KubeCon的与会群体也快速由数百人增长至数千人。这些例子也说明Kubernetes已经成为主流。当我们与正在构建现代化技术栈的公司讨论技术问题时, Kubernetes往往是个无法回避的话题。



2. Kubernetes的管理与支持业务规模开始扩展,并确定自身发展方向

再来看这条预测。用户对于使用我们的平台运行大规模Kubernetes保持愈发浓厚的兴趣。 一年或两年前开始尝试Kubernetes的组织现在已将其引入生产环境。 他们发现Kubernetes编排方案与以往的业务规划思路存在很大的不同。 Kubernetes更容易入门,但在生产环境下的实施却比较困难。因此,最理想的办法自然是将集群托管工作交由第三方打理,而您自身建立专项团队负责根据业务情况评估集群的弹性需求。



3. Kubernetes将走向消亡

再看这一条预测,预测正确。 仅仅拥有Kubernetes还远远不够。因此到目前为止,我们已经在服务目录方面投入了将近一年的时间。我们的客户不仅在谈论Kubernetes,同时也在谈论Istio、Prometheus、Kibana等等。他们希望从这些云原生工具中获益,但又不希望因为新工具的引入而提升日常管理开销。有了Giant Swarm的管理,我们的客户可以专注于管理核心业务所需的应用程序。总之,托管型Kubernetes正逐渐转化为托管型云原生技术栈。

因此,我觉得新一年的预测不妨更大胆一点。至于这些推断是否成立,我将在2019年年底的时候再做一番回顾。



2019年关于云原生市场的预测:

1. 大型企业将会在Kubernetes上加大投入

在这一领域中,我们已经看到大型云服务提供商,以及IBM与VMWare等其他参与者。 Red Hat和Heptio的收购举措表明这些公司正在积极进军这一市场。 当然,这些主要面向支持层面。而如果着眼于管理服务市场,以埃森哲为代表的很多公司将继续为需要强化自身业务的客户提供服务。 随着基础设施迎来更多重大变化,整个行业也将重新洗牌。

这里所指的大型企业也包括一部分规模较大的财富500强企业,他们决定以Kubernetes为基础重构内部平台,并利用开源工具规划自己的发展方向。考虑到客观存在的人才稀缺性压力,这些企业未来也将发布更多开源工具并邀请贡献者加入进来。我将在第五条预测中对这一主题做出进一步讨论。



2. 重点在于后续运营

安装Kubernetes非常简单,但是接下来呢?我们更关注后续运营工作,包括在安全性、更新、事后分析等方面进行测试与验证。大型企业将在生产流程中争分夺秒地推出更新的版本,而CVE漏洞在生产过程中也将快速得到修复。客户需要这种能力,并需要努力调整自身流程以适应这样的新常态。
我们已经和许多在这方面遇到过难题技术的客户进行交流,他们仍然在运行Kubernetes 1.8或更低版本,而且还没有升级的打算。这将给他们留下巨大的安全漏洞——因为最近的补丁只面向Kubernetes的1.10或更高版本。



3. 大数据将转移至Kubernetes

您将看到大数据参与方尽其所能支持Kubernetes。 这些企业将把他们的生产系统从庞大但陈旧的大数据技术栈中剥离出来。此外,他们还将从专有云服务提供商技术栈转向支持多集群环境的专业Kubernetes解决方案。 云与非云之间的区别将因此变得逐渐模糊,但必须承认,整个转移过程可能需至少一年的时间才能完成。
我建议大家关注DotscienceAljabr等公司的动向。



4. 控制平面的崛起

如果不在Kubernetes当中运行自己的控制平面,我们将无法实现Kubernetes的规模化运作。我们使用Operators(自定义控制器)来管理租户集群。而且无论是否使用Operators,各参与方都将高度关注这一趋势,因为事实证明单凭一套集群并不足以解决所有问题。在这方面,Cluster API是个值得关注的重要项目。

客户将在零售、工业以及物联网工作负载的边缘建立更多集群。通过为每个站点建立独立集群,客户可以更轻松地将应用程序部署到对应位置并加以更新。然而,集群数量的增加也对我们的自动化能力提出更高要求。



5. 扩展Kubernetes API

这一项预测分为两大主要方面:


第一:越来越多的应用程序将由定制化资源定义(简称CRD)进行部署与管理。 独立软件供应商(ISV),特别是将软件以工具包的形式交付的供应商,将在产品中引入持续更新机制,或者利用Operators实现同样的效果。这类软件通常会打包为Helm图表。



第二:Kubernetes主要使用CRD扩展自身各项新旧功能。一方面,这种新机制将作用于集群API——例如Giant Swarm或者上游Cluster API。 另一方面,其也将影响到以Kubernetes为基础的各类平台,例如 ML / AI平台、PaaS类产品以及CI / CD管道等,未来这一切都将以原生Kubernetes扩展的形式呈现。



在Giant Swarm,我们正在利用CRD取代我们的API网关并直接使用Kubernetes API。 这让我们可以充分发挥Kubernetes功能的作用,例如RBAC和Admission Controllers。 此外,我们的API也因此得以更轻松地与我们的Operators进行交互。

当然,这种规模扩展将增加API服务器作为事件管理器的负载强度。 因此,社区将致力于扩展API服务器和etcd本身,或者采用群集外解决方案。



总之,Kubernetes现在已经成为真正的主流。 对于大型服务提供商及大用户来说,这是一个绝对不容忽视的焦点。 然而,Kubernetes的发展也绝非毫无波澜。 这一方面将给大规模运营带来挑战,另一方面也将在生态系统之内表现为诸多变化与极快的发展速度。 大家对我的2019年Kubernetes展望作何感想?请在评论中分享您的真知灼见:)

原文链接:The State of Kubernetes 2019(翻译:ylzhang)

0 个评论

要回复文章请先登录注册