去年我写了一篇题为《Kubernetes过去到未来之旅》(https://blog.giantswarm.io/kubernetes-and-giantswarm-in-2018/)的文章。在本文中,我谈到了我们技术栈的KVM与AWS版本,以及即将推出的Azure版本。此外,我还提到了最近两年如过山车一般起伏不定的技术变化态势。下面,我们一同回顾一下去年我做出的部分预测:
再看这一条预测,预测正确。 仅仅拥有Kubernetes还远远不够。因此到目前为止,我们已经在服务目录方面投入了将近一年的时间。我们的客户不仅在谈论Kubernetes,同时也在谈论Istio、Prometheus、Kibana等等。他们希望从这些云原生工具中获益,但又不希望因为新工具的引入而提升日常管理开销。有了Giant Swarm的管理,我们的客户可以专注于管理核心业务所需的应用程序。总之,托管型Kubernetes正逐渐转化为托管型云原生技术栈。因此,我觉得新一年的预测不妨更大胆一点。至于这些推断是否成立,我将在2019年年底的时候再做一番回顾。
2019年关于云原生市场的预测:
您将看到大数据参与方尽其所能支持Kubernetes。 这些企业将把他们的生产系统从庞大但陈旧的大数据技术栈中剥离出来。此外,他们还将从专有云服务提供商技术栈转向支持多集群环境的专业Kubernetes解决方案。 云与非云之间的区别将因此变得逐渐模糊,但必须承认,整个转移过程可能需至少一年的时间才能完成。我建议大家关注Dotscience与Aljabr等公司的动向。
如果不在Kubernetes当中运行自己的控制平面,我们将无法实现Kubernetes的规模化运作。我们使用Operators(自定义控制器)来管理租户集群。而且无论是否使用Operators,各参与方都将高度关注这一趋势,因为事实证明单凭一套集群并不足以解决所有问题。在这方面,Cluster 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展望作何感想?请在评论中分享您的真知灼见:)
原文链接:https://blog.giantswarm.io/the-state-of-kubernetes-2019/
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/a9484f92d181ccf5147145e72af025fb.jpeg)