本文经AI新媒体量子位（公众号ID:QbitAI）授权转载，转载请联系出处。
Kubernetes，作为Google在2014年发布的一个开源项目。
这是一个自动化部署、伸缩和操作应用程序容器的开源平台，可以做到快速提供给基础架构以真正的以容器为中心的开发环境。
毕竟在云原生风靡的今天，容器将成为最重要的计算资源形式。
过去一年，要论Kubernetes的技术发展咋样？
可能成熟与稳定二词最能概括。
其中值得提及的一点，越来越多的重量级玩家开始入局云原生市场。
再也不是热衷于技术创新的初创型公司扎推聚集的时代。
关于这种格局变化，Rancher想必记忆犹新。
Rancher Labs由CloudStack之父梁胜创建，一直以来都算是最先扎入该领域的“排头兵”。
其旗舰产品Rancher，作为一个开源的企业级Kubernetes管理平台，率先实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理，并已于2020年2月完成了中国本土化和国产化。
对此，Rancher中国 CTO 江鹏感同身受，2017-2018年，那时更多的云服务厂商将容器视为自身服务的一种，但并不是最核心的那一个。
但如今，各家参与者都会将以容器为代表的云原生服务提升到核心服务的范畴。
当然，这种变化还集中表现在参与者在认可云原生领域或者技术栈的同时，更多思考业务“落地”的问题。
例如应用的运行、微服务的治理甚至是Kubernetes集群的管理与安全，还包括与新技术AI的结合等。
就此推断，或许更加关注生态层面的创新，越发灵活适应用户需求变化，通过创新性的项目产品来解决云原生推广或者落地过程中的诸多问题，可能才是企业决胜云原生战事的关键。
此外谈及云原生的落地问题，K8S多集群管理、容器边缘部署包括与AI技术相结合等层面都是不容规避的难点。
如果你在容器实践过程中“犯了难”，不妨往下看看，或许可以在理念意识上消除部分疑惑。
从关注发展到应对实战：集群管理表示“有话要说”
如果我们的推断还算靠谱，实战云原生的关键之一可以聚焦为Kubernetes集群的管理。
就如同Rancher最早开始的产品定位一样：聚焦多集群管理或者混合云、多云的多集群管理。
究竟何为多集群？
从实践看，对于大部分刚开始使用云原生或者Kubernetes技术的企业来说，使用的就已经不是单集群了，但此时更多被简单定义为少量集群。
举个例子，很多企业开发环境中有一个集群，生产环境中又有一个集群，这或许是刚开始上线的典型场景。
但伴随业务发展体量扩大，容器平台在企业内部采纳的程度变得越来越高，用户就会随之发现有更多应用需要迁移到集群之上。
从单一数据中心部署过渡到多数据中心，甚至会出现多云场景，进而产生多集群管理的问题。
江鹏进一步透露，多集群管理中的“多”还不单单体现在集群的量级，哪怕在不同团队中，理念上也会存在不小的差异。
对于平台建设团队，多集群管理技术更多意味着如何能够帮助屏蔽底层基础设施的差异性，来提供一致性的认证授权，以及管理、运维能力。
而针对应用团队来说，更希望以一个统一且具备一致性的方式去部署和使用这些集群，能够在不同的集群之上提供一个一致性的上层支撑能力。将监控、告警、日志采集或者包括微服务治理在内的种种应用，更快速地部署到多个集群中是关键。
以金融用户多活的数据中心为例，它是比较典型的两地三中心的架构，对于应用团队而言，他们的关注点更加集中在：是否能将一些核心业务系统快速一键部署到数据中心，来实现跨数据中心的容灾或者多活？
基于此，Rancher对自己的产品做了一些增强，包括多集群、多租户的监控功能以及单一应用跨多Kubernetes集群的部署和管理等。
具体来说，在定义集群模板的基础上，可以一键将应用商店的应用程序系统无缝部署到任意数量集群中的多个Project里。
谈及安全，一直以来都是企业非常关注的问题，在容器集群管理的范畴亦不例外。
如果说从整个平台安全角度考虑的话，我们一般讨论安全问题，它一定是一个端到端的解决方案。
从容器平台的安全性着眼，往往关注的就不仅仅是集群的安全本身
反而会更多地覆盖到从应用开发到最后交付容器化运行的整个生命周期的安全过程。
例如定向安全。
整个容器的镜像怎么保证其中内置的组件或者服务不存在一些安全漏洞，用户对于这一点的关注还算比较常见。
如果涉及到集群安全层面，是否符合业内的最佳推荐建议则变得重要起来。
比方说遵照安全基准测试benchmark，关闭匿名访问端口，各个组件之间使用双向的TLS加密，判断相关组件是不是以最小权限去启动等。
除此之外，集群的运行安全还涉及到集群更上层的应用运行时的一些配置，例如容器运行时runtime。
如果是在多租户的场景中，不同的租户之间如何去做网络隔离也会被考虑其中，甚至还会借助一些专业安全厂商的技术支持。
尽管容器安全非常复杂，但安全管理不容忽视。
边缘侧场景下的集群管理，难在何处？
其实容器技术用在边缘侧并不新鲜，对该论断江鹏表示认可。
例如微软的Azure，Azure IoT中心的配置是业界早已客观存在的实例。
区别在于，Azure IoT中心是基于Docker容器技术，现阶段可能还没有使用类似Kubernetes的一些编排。
更重要的一点，容器技术天然可作为一种应用交付方式或者应用打包交付的方式存在。
也就是说，这种“天然”适合在类似于边缘侧这样的大规模应用统一标准化部署。
这么一总结就更加司空见惯。
尽管容器具有与生俱来的天然属性，但部署管理的过程所面临的问题却并没有在云端、数据中心甚至是异构基础设施上部署那么简单。
从直观数量上看，边缘侧的集群量级不再是传统数据中心中几十个或者是十几个集群的情况。
反而可能是几千个或者上万个，甚至是几十万个这样一个集群量级。
更重要的是，边缘场景与传统的云端或者是数据中心场景，最大的区别在于，边缘场景是一个非常多样化或者碎片化的场景。
相对于数据中心来说，大家使用的是标准的X86服务器以及统一存储，Kubernetes可以提供一致性的API去支撑业务的标准化运行。
但在边缘侧，不管是业务场景使用设备本身，还是使用的协议上都会存在很大区别。
“举个简单的例子，一些制造业客户的生产线上会有很多windows系统，而不是Linux系统，甚至更多可能还不是windows server。如果这些设备通过一些协议去和产线上的其他设备进行交互的话，难度可想而知。”
那么究竟该如何管理这样一个超大规模集群呢？
目前来看，还没有一个统一的数据中心场景或者平台推出，来形成大一统规范。
在边缘场景中，用户要去进行一些系统或是应用的容器化或者是云原生改造，还需要有一个逐步适配、改造的过程。
但江鹏也坦承，将容器技术利用在边缘侧，确实是一个亟待发扬光大的趋势与需求。
“我们已经看到将Docker引擎用在边缘侧，但在边缘侧要实现更强大的编排能力，是否将标准的Kubernetes的推到边缘侧，还亟待探讨。”
据量子位了解，大部分投身容器的云服务商还是更多选择将标准的Kubernetes部署在边缘侧，以求有效管理；但Rancher例外，这也是K3s应时而出的原因。
降低用户去部署和管理Kubernetes的复杂度，不再需要管理各种复杂的组件，开箱即用一键部署。
也不用费尽心力去维护像ETCD这种比较新的key-value数据。
从以上出发，降低资源消耗，让用户在低计算资源的设备上也能够去运行Kubernetes 集群等，或许是K3s的优势所在。
此外，最近官宣开源的Fleet，也正是Rancher以管理cattle的方式去管理部门的子集群，确保海量Kubernetes集群的集中管理优势体验。
“关注的着眼点不再是某一个集群的应用部署情况，而是把集群作为一个集群组（cluster group），从一个更高维度去做管理。”
容器+AI ，究竟能够做啥？
如今，无论是AI行业的专业厂商，还是实际AI训练的场景应用，出现了越来越多将AI业务运行在容器之上的情况，此举也逐渐成为探究业务落地的重要问题之一。
例如在AI模型的训练中，大量访问或者读取的数据、图片或者源文件等注定了大规模算力的消耗，然而典型的大规模计算场景，正是容器所需要的。
但喜忧参半，AI在实际落地在容器场景中也多少存在挑战。
比方说资源共享划分的粒度。
如今Kubernetes 本身对于CPU资源的共享和调度的能力还不是太强。
江鹏表示，由于Nvidia官方并没有像vGPU的实现，导致在标准的Kubernetes或者社区版的Kubernetes集群之中，资源调度的粒度比较粗，资源的利用率不是太高。
另外在容器化场景中，可能对于模型训练碎片化的小文件、海量文件处理的性能表现也不甚理想。
尽管如此，Gartner 在2019年发布的一份关于AI的预测报告中依旧表明了“态度”。
当企业CIO们将AI作为被思考的头等大事儿时，对于Kubernetes的关键作用也不容小觑。
Gartner称，Kubernetes将成为企业内部AI应用首选的运行环境和平台。
容器和Serverless将使机器学习模型作为独立的功能提供服务，从而以更低的开销运行AI应用，足见Kubernetes+AI前景光明。
针对Kubernetes的成熟稳定，你又有什么看法呢？
附：采访嘉宾简介
