<返回更多

CloudOS:不懂K8s,也能用上K8s!

2023-10-31    行云创新
加入收藏

关于容器技术

你是否听说过容器技术(以Docker和Kube.NETes为代表)?容器技术呱呱坠地到如今,在国内经历了如下3个阶段:

· 婴儿期:2014-2016年的技术探索期;

· 少儿期:2017-2018年的行业试水期;

· 少年期:2019年以后的规模应用期。

容器技术作为技术圈儿中的香饽饽,如果你还没有听说过,建议你立刻了解一下,以免跟不上当今的技术潮流。

容器技术带来的价值,通过它的广泛使用已经不言而喻,因此不再多费文字阐述。这里直接向大家大致介绍容器技术的趋势。

1、Kubernetes(K8s)已成为容器技术的事实标准。

CloudOS:不懂K8s,也能用上K8s!

2、大量企业已经在使用或者计划使用容器云。

CloudOS:不懂K8s,也能用上K8s!

3、K8s从CO走向OS

K8s一直以来被当做容器编排工具(ContAIner Operation, CO),而这些年的发展,K8s已经成了云原生领域事实的操作系统(Operation System, OS)。

CloudOS:不懂K8s,也能用上K8s!

难以驾驭的K8s

K8s功能固然强大,但同时从K8s目前的定位——操作系统,就能看出它最大的特征:复杂!!!

复杂真是万恶之源!复杂会带来一系列衍生问题:

1、上手k8s绝非易事,用一个高级点的说法,叫学习曲线陡峭。并且容器技术的更新迭代非常快,Kubernetes衍生出的新概念新工具也在蓬勃发展(有兴趣的朋友可以搜索一下“Kubernetes生态”)。然而更有挑战性的点在于,如果想在实际的工作中用上K8s,不只你一人要学,整个研发团队都需要学,包括开发人员、测试人员、运维人员。

2、市场上,K8s相关人才不多。

3、项目使用K8s的不确定性太高,可能会导致失败。

4、项目切换到K8s的成本太大,导致你的老板可能会叫停。

5、你需要适应K8s的工作模式,软件研发本来就是一个复杂的体系,包括了很多人使用很多工具分工合作,而使用K8s,很多工作方式与原来不一样。

下面罗列一下,以供参考。

CloudOS:不懂K8s,也能用上K8s!

在实际使用中,还有很多非常棘手的问题,比如:

· K8s yaml的配置一部分是开发关注的,一部分是运维关注的,如何分工协作?

· ConfigMap/Secret 不支持版本控制,参数多时配置起来很麻烦;

· 集群如何给外部暴露端口?

· 如何做热更新?

· 多K8s集群如何管理?

· K8s集群本身如何备份和恢复?

· 如何对K8s集群进行升级而不影响业务?

· K8s集群如何做资源规划?

我的团队该如何上K8s?

企业应用上K8s已经是大势所趋,不再是要不要做的选择题,而是什么时候做,如何做的必答题。

团队如何上K8s,从大面上,我的答案包含2点,二者缺一不可:

1、渐进式上K8s;

2、分工 + 云原生产品解决复杂性。

渐进式上K8s:

渐进式上K8s听上去很简单,但实施起来不然,具体来说包括如下几点:

· 特定项目。选择即将要开发的新项目,简单一点的项目,没有迁移成本。

· 特定团队。项目的leader需要有新技术的探索精神,项目中核心成员也有新技术的探索精神。关于特定团队,团队中的研发人员、测试人员、运维人员都需要从一开始就直接或间接使用K8s。直接是上原生K8s,间接是指通过第三方平台上K8s。

笔者曾经碰到很多上了K8s的客户,推进得都无比艰难!除了上述的诸多的难题之外,还有一个最重要的原因——这些客户上K8s是先从运维部门开始。这些客户认为,正是因为K8s如此复杂和不确定性高,所以引入第三方的产品或解决方案,先从一个部门开始使用,再逐步推广到研发部门。而现实是:K8s是涉及研发、测试、运维的整体协作方式变革,引入第三方的产品或解决方案时,要么是研发测试人员没有参与,要么是没有深度参与,导致在推广时,第三方的产品或解决方案不被研发测试人员接受。

测试环境。项目先在测试环境以K8s方式部署。

取得成功之后,再扩展至生产环境、其他项目、其他团队。这样的方式,有利于团队积累对K8s的自信心。取得一定的广度成功的同时,在深度上也可以做一定的探索,比如,使用K8s配套的测试工具、运维工具,甚至采用一些开源项目的CRD,比如Open Kruise。甚至编写自己公司特有的CRD。

分工 + 云原生产品解决复杂性:

人类解决复杂性有2个非常重要的手段:分工、封装。这里就不举例子了,在IT领域,这两个手段的例子俯拾皆是。具体到上K8s体现为:

人员分工是指不需要整个团队的人都懂K8s,只需要特定的一两个人懂K8s,研发人员、测试人员只需配合相关的工作,由这一两个人来编写Dockerfile、K8s yaml,也可以由这一两个人写好脚本,开发人员和测试人员直接调用脚本,传递合适参数。

什么样的云原生产品能解决复杂性:

答案是以应用为中心的云原生产品。什么是以应用为中心?从企业上云的过程来看,企业上云越来越关注上层,越来越趋向应用,越来越不关心资源。

CloudOS:不懂K8s,也能用上K8s!

从某个角度上说,容器仍然是资源。当前企业上云,说的其实都是上容器。未来能否再往上走,企业不用运维容器,也完全不用管资源呢?

完全可以!

把上面图的右半部分变一下形,如下图所示。

CloudOS:不懂K8s,也能用上K8s!

企业都是在应用云上进行应用的全生命周期管理,不用再看到阿里云、腾讯云、AWS、企业私有云的细节,也不用运维云资源,这些云服务厂商只是提供了在世界各地不同的服务规格的云资源。企业只需要在应用云上把应用交付到不同云服务。这样,就彻底做到了以应用为中心,应用开发人员、测试人员、运维人员需要关注的是应用,是业务,再也不用关注容器,自然就不用理会容器的复杂度。个人认为,这是云原生的终态。这就是我们产品CloudOS的理念,也是我们的实践。

 

附注:笔者容器云行业从业好几年,略有心得,聊作分享。如有疏漏,多谢指正,欢迎留言探讨。
引用说明:本文大量数据来源于《艾瑞咨询:2020年中国容器云市场研究报告》
关键词:CloudOS      点击(19)
声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多CloudOS相关>>>