使用Google Kubernets的集群管理方法Rancher中国CTO江鹏手把手共享量子比特

晶少发凹非寺量子位报道_公众号QbitaI

Kubernetes是作为Google于2014年发布的开源项目。

它是一个开源平台，可以自动部署、伸缩和操作应用程序容器，可以快速提供给基础架构的真正以容器为中心的开发环境。

毕竟，在云原生风靡的今天，容器将是最重要的计算资源形式。

在过去的一年里，关于Kubernetes的技术发展怎么样。

成熟和稳定这两个词也许最能概括。

其中值得提及的一点是，越来越多的重量级玩家开始进入云本地市场。

现在不是热衷于技术革新的风险企业聚集的时代。

对于这种结构变化，Rancher将记忆犹新。

RancherLabs由CloudStack之父梁胜设立，迄今为止一直被认为是最先扎进该领域的“先头兵”。

其旗舰产品Rancher作为开源的企业级Kubernetes管理平台，率先实现了Kubernetes集群对混合云+本地数据中心的集中部署和管理，并于2020年2月完成了中国的本土化和国产化。

对此，Rancher中国CTO江鹏感同身受，2017-2018年，当时更多的云服务厂商将集装箱视为自身服务的一种，但不是最核心的。

但如今，各与会者已将以集装箱为代表的云本机服务提升到核心服务范畴。

当然，这种变化集中在参与者在承认云本地领域和技术栈的同时，更多地思考业务“落地”。

例如，应用程序的执行、微服务的管理、以及Kubernetes集群的管理和安全性、以及与新技术AI的结合等。

由此推测，只有更加关注生态方面的创新，越来越灵活地适应用户需求的变化，通过创新的项目产品解决云本地人在推广或落地过程中的诸多问题这可能是企业赢得云本地人之战的关键。

此外，对于云本地的落地问题，K8S多集群管理、集装箱边缘布局包括与AI技术的结合等方面都是不可避免的难点。

如果你在容器实践过程中“犯下了困难”，往下看，你可能会在理念意识上消除一些疑问。

从关注到实战应对：集群管理表明“有话要说”

如果我们的推论仍然可信，实战云本地密钥之一可以聚焦于Kubernetes集群的管理。

Rancher如最初开始的产品定位：聚焦于多集群管理或混合云、多云的多集群管理。

到底什么是多群集？

从实践上看，对于大多数开始使用云本机或Kubernetes技术的公司来说，使用的不是单一集群，但在这种情况下，它往往很容易定义为少量集群。

例如，许多企业开发环境中有集群，生产环境中有集群，这可能是刚刚上线的典型场景。

但随着业务的发展，海量的扩大，集装箱平台在企业内部的采用程度越来越高，用户可以随之发现，更多的应用需要转移到集群上。

从单个数据中心部署迁移到多数据中心时，可能会出现多云场景，从而导致多集群管理问题。

江鹏进一步明确了多集群管理中的“多”不仅是集群的尺度，在不同的团队中理念也有很大的差异。

对于平台构建团队来说，多集群管理技术意味着如何能够屏蔽基础架构差异，提供一致的认证权限，并提供管理和运营能力。

对于应用程序团队来说，希望以统一一致的方式部署和使用这些集群，从而在不同集群之上提供一致的高层支持能力。在多个群集上快速部署各种应用程序（包括监视、警告、日志收集或微服务管理）非常重要。

以金融用户大量生存的数据中心为例，它是一个比较典型的两个三中心架构，对于应用团队来说，他们的关注点更为集中：将一些核心业务系统迅速用一个关键点部署到数据中心可以实现数据中心之间的灾难和多活动吗？

在此基础上，我们增强了自己的一些产品，包括多集群、多租户监控功能、多Kubernetes集群之间的单个应用程序部署和管理。

具体来说，在定义群集模板的基础上，可以将应用程序存储库的应用系统无缝地部署到任意数量的群集中的多个项目中。

安全性一直是企业非常关注的问题，在集装箱集群管理的范畴也不例外。

从整个平台的安全角度考虑，我们通常讨论安全问题。那肯定是端到端的解决方案。

从集装箱平台的安全性来看，不仅仅是集群的安全本身

相反，从应用程序开发到最终容器化运行的整个生命周期的安全过程会更多。

定向安全等。

对于如何保证整个容器镜像所内置的组件和服务没有安全漏洞，用户的兴趣是比较普遍的。

当涉及到群集的安全级别时，是否符合行业中的最佳建议是至关重要的。

例如，根据安全标准测试benchmark，关闭匿名访问端口，并在每个组件之间使用双向TLS加密来确定相关组件是否以最低权限启动。

此外，群集的运行安全性还与群集的高级应用程序运行时配置有关，例如容器运行时runtime。

如果是多租户的场景，考虑到不同租户之间如何进行网络隔离，也可以借助专业安全制造商的技术支持。

容器的安全性非常复杂，但安全管理不容忽视。

在边缘场景中管理群集有什么困难。

其实容器技术在边缘侧使用并不新鲜，对该论断江鹏表示认可。

比如微软的Azure、Azure IoT中心的构成，就是一个行业中已经客观存在的例子。

不同的是，Azure IoT中心基于Docker容器技术，现阶段可能没有使用Kubernetes这样的一些编排。

更重要的是，容器技术可以天然地以应用程序交付或应用程序包交付方式存在。

也就是说，这种“天然”适用于大型应用程序（如边缘侧）的统一标准化部署。

这样总结起来，越来越看惯啦。

尽管容器具有天生的天然属性，但部署管理过程所面临的问题并不像部署到云、数据中心或异构基础架构那样简单。

从直观的数量来看，边缘侧的群集级别不再是传统数据中心的几十个或几十个群集。

相反，它可能是数千个或数万个，甚至数十万个集群级别。

更重要的是，边缘场景与传统的云或数据中心场景非常多样化或碎片化。

与数据中心相比，它使用标准的X86服务器和统一存储，Kubernetes可以提供一致的API来支持业务的标准化运营。

但是，在边缘侧，在业务场景中使用设备本身或使用的协议有很大的不同。

“举一个简单的例子，一些制造业客户的生产线上有很多windows系统而不是Linux系统，甚至更多的可能不是windows server。如果这些设备通过一些协议与生产线上的其他设备交互，难度是可以考虑的。”

那么，如何管理这样的超大规模集群呢。

目前还没有引入统一的数据中心场景和平台，没有形成统一的规范。

在边缘场景中，用户需要逐步适应和改造某些系统或应用程序的容器化或云本机改造过程。

但是，江鹏在边缘侧利用容器技术，确实是急着大发展的倾向和需要，这也是坦率地支持的。

“我们已经看到将Docker引擎用于边缘侧，但为了在边缘侧实现更强大的编织能力，是否将标准的Kubernetes推到边缘侧，还需要研究。”。

根据量子比特，大部分投身于集装箱的云服务运营商选择将标准的Kubernetes配置在边缘侧，以有效管理。但是Rancher例外，这也是K3s应时常出现的理由。

减少了用户部署和管理Kubernetes的复杂性，无需管理各种复杂的组件，可以开箱即放。

不必费劲维护相对较新的key-value数据，如ETCD。

综上所述，K3s的优点可能是降低资源消耗并允许用户在低计算资源设备上运行Kubernetes集群。

此外，近期官宣开源的Fleet也以Rancher管理cattle的方式管理部门子集群，确保了大量Kubernetes集群的集中管理优势体验。

“值得注意的是，将群集作为群集组（cluster group），从更高的维管理，而不是将群集部署为应用程序。”

集装箱+AI，到底能做什么？

目前，无论是AI行业的专业厂商，还是实际的AI培训场景应用，将AI业务运行在容器上的案例越来越多，这也逐渐成为探索业务落地的关键问题之一。

例如，在AI模型的训练中，大量存取或读入的数据、图像、源文件等注定了大规模计算力的消耗，而典型的大规模计算场景正是容器所需要的。

但喜事参半，AI实际上落地容器场景也多少有些挑战。

例如资源共享分割的粒度。

目前，Kubernetes本身的CPU资源共享和调度能力不是很强。

由于Nvidia公式没有进行vGPU之类的实现，因此在标准的Kubernetes或社区版的Kubernetes集群中，资源调度的粒度比较粗，资源的利用率不太高。

此外，在容器化场景中，对于模型培训碎片化的小文件，大量文件处理的性能表现也不太理想。

尽管如此，加特纳在2019年发表的关于AI的预测报告中表示了“态度”。

如果企业CIO们把AI作为思考的首要事项，那么Kubernetes的重要作用也不容忽视。

Gartner表示，Kubernetes将成为企业内AI应用的优先运营环境和平台。

容器和Serverless将机器学习模型作为独立的功能提供服务，从而以更低的开销运行AI应用程序，可见Kubernetes+AI前景光明。

对于Kubernetes的成熟稳定性，你是怎么想的。

附：采访嘉宾简介

-结束了

量子比特QbitaI头线合同

关注我们，首先了解最先进的科技动态