K8s已经成为云原生时代的安卓，这就够了吗？
发布时间：2022-10-19 10:41:31 所属栏目：云计算 来源：
导读： 云原生时代，直接使用Kubernetes和云基础设施过于复杂，如用户需要学习很多底层细节、应用管理的上手成本高、容易出错、故障频频。随着云计算的普及，不同云又有不同的细节，进一步加剧了上述问题。
本文
本文
|
云原生时代，直接使用Kubernetes和云基础设施过于复杂，如用户需要学习很多底层细节、应用管理的上手成本高、容易出错、故障频频。随着云计算的普及，不同云又有不同的细节，进一步加剧了上述问题。 本文将介绍如何在Kubernetes上构建新的应用管理平台，提供一层抽象以封装底层逻辑，只呈现用户关心的接口，使用户可以只关注自己的业务逻辑，管理应用更快更安全。 云原生时代是一个非常好的时代，我们所面临的是整体技术的颠覆性革新，全面地对应用做端到端重构。目前，云原生在演进过程中产生了三个关键技术： 这三项关键技术其实是逐渐演进的关系，另外，在应用交付领域，也有与之对应的理论在跟随上述技术不断地演进。云原生的崛起，带来了交付介质、基础设施管理、运维模型和持续交付理论的全面升级和突破，加速了云计算时代的到来。 图1 云原生技术全景图（来源：CNCF Landscape 2021-10，） 从CNCF发布的云原生技术全景图（见图1）中，可以看到云原生的蓬勃生态，细数图中这900+Logo，其中不乏开源项目、创业公司，未来云原生的技术都会在这些地方诞生。 云原生“操作系统”Kubernetes带来的应用交付挑战 上文提到，Kubernetes已成为云原生的标配，其对下封装基础设施的差异，对上支持各种应用的运维部署，如无状态应用、微服务，再如有状态、批处理、大数据、AI、区块链等新技术的应用，在Kubernetes上面都有办法部署。Kubernetes已经成为了现实意义的“操作系统”。它在云原生的地位正如移动设备中的Android。为什么这样讲？Android不仅仅装在我们的手机上，它还进一步渗透到汽车、电视、天猫精灵等智能终端里，移动应用可以通过Android运行在这些设备上。而Kubernetes也有这样的潜力或发展趋势，当然它不是出现在智能家电中，而是出现在各家公有云、自建机房，以及边缘集群。可以预想，Kubernetes未来会像Android一样无处不在。 那么，有了Kubernetes这层交付以后，容器+Kubernetes这层界面是不是就可以解决掉所有的交付问题了？答案肯定不是。试想，如果我们的手机中只有Android系统，它能够满足我们工作和生活需求吗？不能，必须有各种各样的软件应用才行。对应到云原生，它除了Kubernetes这个“操作系统”外，也需要一套应用的交付能力。在手机中，软件应用可以通过类似“豌豆荚”这样的应用以便用户安装，同样在云原生时代，我们也需要将应用部署到不同的Kubernetes集群上。但由于Kubernetes海量琐碎的设施细节与复杂各异的操作语言，导致部署过程中会遇到各种各样的问题，这时就需要云原生的“豌豆荚”来解决这个问题，也就是应用管理平台，去屏蔽交付的复杂性。 应用管理平台在业界有两种主流模式云计算结构图，第一种是传统平台模式，在Kubernetes上“盖一个大帽子”，将所有复杂度屏蔽，在此之上，再根据需求自己提供一层简化的应用抽象。通过这种方式，虽然应用平台变得易用了，但新的能力需要由平台开发实现，也就带来了扩展难、迭代缓慢的问题，无法满足日益增长的应用管理诉求。 另一种解法是容器平台模式。这种模式比较云原生，组件是开放的，扩展性强，但是，它缺乏应用层的抽象，导致了很多问题，比如开发者学习路线陡峭。举个例子，当一个业务开发者把自己的代码提交到应用平台时，他需要写Deployment部署应用、写Prometheus规则配置监控、写HPA设置弹性伸缩，写Istio规则控制路由等，这些都不是业务开发希望去做的。 所以，不论是哪种解法，都有优缺点，需要取舍。那么，到底怎么做才能封装平台的复杂性，还能拥有良好的扩展性？这是我们一直在探索的。 通过应用管理平台，屏蔽云原生应用交付的复杂性 2012年，阿里巴巴已经开始做容器化相关的调研，起初主要是为了提高资源利用率，开始了自研容器虚拟化技术之路。随着应对大促的机器资源量不断增多，在2015年开始采用容器的混合云弹性架构，并使用阿里云的公有云计算资源，支撑大促流量高峰。这也是阿里巴巴做云原生的早期阶段。 转折发生在2018年，阿里巴巴的底层调度采用开源的Kubernetes后，我们从面对虚拟机的脚本化安装部署模式，转变为基于标准的容器调度系统部署应用，全面推进阿里巴巴基础设施的Kubernetes升级。但很快，新的问题就出现了：应用平台没有标准、不统一，大家“各自为政”。 因此，我们在2019年携手微软发布了开放应用模型——OAM（Open Application Model），并开始做OAM平台化改造。一切都比较顺利，2020年OAM的实现引擎KubeVela正式开源，在内部推进多套应用管理平台基于OAM和KubeVela演进。并推动了三位一体战略，不仅阿里内部的核心系统全面使用这套技术，而且在面向客户的商业化云产品以及在开源时，都使用同样的技术。通过全面拥抱开源，让整个OAM和KubeVela社区参与共建。 在这段探索历程中，我们走了不少弯路，也累积了许多踩坑经验，接下来将作具体介绍，同时分享KubeVela的设计原理和使用方法，帮助开发者了解云原生应用管理平台的完整解决方案，提高应用开发者的使用体验和应用交付效率。 云原生应用管理平台的解决方案 在探索云原生应用管理平台解决方案的过程中，我们主要遇到4项重大挑战，并总结了4个基本原则，下文将一一介绍。 挑战1：不同场景的应用平台接口不统一，重复建设。 虽然，云原生有了Kubernetes系统，但在不同场景它会构建不一样的应用平台，且接口完全不统一，交付能力存在很大差异，比如AI、中间件、Serverless和电商在线业务都有各自不同的服务平台。因此，在构建应用管理平台时，难免重复开发和重复运维。最理想的状况当然是实现复用，但运维平台架构模式各有不同，没办法做到互通。另外，业务开发者在不同场景对接应用交付时，对接的API完全不同，交付能力存在很大差异。这是我们遇到的第一个挑战。 挑战2：“面向终态”无法满足过程式的交付方式。 在云原生时代，面向终态的设计很受欢迎，因为它能减少使用者对实现过程的关心。使用者只需要描述自己想要什么，不需要详细规划执行路径，系统就能自动把事情做好。但在实际使用过程中，交付过程通常需要审批、暂停观察、调整等人为干预。举个例子，我们的Kubernetes系统在交付过程中处于强管护的状态，要审批发布。在《阿里集团变更管理规范》中明确“线上变更，前 x 个线上生产环境批次，每个批次变更后观察时间应大于y分钟。”“必须先在安全生产环境（SPE）内进行发布，只有在SPE验证无问题后，才能在线上生产环境进行灰度发布。”因此，应用交付是一个面向过程而非面向终态的执行流程，我们必须考虑，怎样让它更好地适应面向过程的流程。 挑战3：平台能力扩展复杂度太高。 上文提到，传统模式下的应用平台扩展性差，那么在云原生时代，有哪些常见扩展平台的机制？在Kubernetes系统中，可以直接用Go Template等模板语言做部署，但缺点是灵活性不够，整个模板写下来结构复杂，难以做大规模的维护。有些高手可能会说“我可以自定义一套Kubernetes Controller，扩展性一定很好！”没错，但是，了解Kubernetes及CRD扩展机制的人比较少。即使高手把Controller写出来了，他还有后续的许多工作要做，比如需要编译并将其安装在Kubernetes上运行，另外，Controller数量也不能一直这样膨胀上去。因此，要想做一个高可扩展的应用平台有很大挑战。 挑战4：不同环境不同场景，交付差异巨大。 在应用交付过程中，对于不同用途的环境，其运维能力差异特别大。比如开发测试环境，重视开发和联调效率，每次修改采用热加载，不重新打包、走镜像部署的一套流程，同时为开发人员部署按需创建的独立环境。再比如预发联调环境，有攻防演练、故障注入的日常运维诉求。以及在生产环境，需要加入安全生产、服务高可用方面的运维能力。此外，同一个应用，组件依赖也有巨大差异，数据库、负载均衡、存储，在不同云上存在诸多差异。 （编辑：天瑞地安资讯网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐