神结合!一招玩转K8s和微服务治理

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 云原生技术已经深刻的改变了软件的开发和交付过程,让软件开发回归业务,是开发者长久以来的共同愿望,云原生的出现,恰好提供完美的工具,帮开发者将软件的业务功能和运维治理分离开。而K8s作为云原生技术中调度编排的核心,对运维治理的提供了实施标准,早已被证明可有效的提升复杂系统稳定性,降低运维成本,随着它的逐渐成熟,K8s已经开始吸引越来越多开发者的注意。

发布会传送门

进入直播间还有好礼等你拿!

EDAS产品免费试用:https://www.aliyun.com/activity/middleware/edaspromotiononmay

首届云原生编程挑战赛正式开战!立即报名瓜分330000现金奖:https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition

观看《云原生架构师培训课程》领取新用户折扣:https://yqh.aliyun.com/live/AlibabaCloudNative

云原生的发展速度日新月异,要用好却绝非轻而易举,当开发者开始使用云原生或向云原生架构迁移时,往往会面临一些困境:

  • 第一,云原生对于软件产品存在约束,如必须满足容器化,12要素等,因此要让一个遗留系统适配云原生体系,不免会需要做一些改造,其中甚至会涉及到开发模式的转变,对部分团队而言,转变的过程可能充满挑战。
  • 第二,K8s复杂性足以让很多开发者望而却步,而只有对其有较好的掌握才能发挥好云原生带来的优势,否则可能导致系统难以维护,甚至因错误的配置引发故障。而让开发者的技术水平紧跟K8s的发展速度,这本身也需要持续投入,这些额外的投入也背离了让开发只关注业务的初衷。
  • 第三,虽然开源社区给云原生贡献了丰富的能力组件,但对于线上业务,尤其是企业级的服务来说,开源组件的性能,可靠性和可维护性能否经得住考验,以及运维团队是否有能力对这些开源组件兜底,这也是在技术选型前所必须做的考虑。

总之,了解云原生和K8s只是开始,想要将云原生在业务落地,发挥云原生的价值,选择一条合理的“原生化”路径,才是开发者要关注的核心问题。

阿里巴巴对于云原生的运用起步很早,对于在具有大规模,高可靠和分布式特征的系统上应用云原生技术有丰富经验。EDAS作为出品自阿里巴巴云原生团队,阿里云上aPaaS的旗舰产品,在早期也提供了容器和K8s的支持能力。近期随着EDAS 3.0版本的重磅发布,更是将云原生融入了EDAS的功能核心,致力于帮助业务进行云原生落地,立足云原生平台打造更强大的应用管理能力,释放技术红利,服务广大开发者。

下文将通过一些示例,带领大家一窥究竟,看EDAS如何帮开发者“躺着”进入云原生时代,玩转云原生。

“纯粹”的云原生

无法否认,EDAS是阿里云平台上的商业化产品,而云原生主要由开源社区所倡导,两者显然出自泾渭分明的两个阵营,那“纯粹”是在掩耳盗铃?

其实不然,商业化与开源并非水火不容,相反在很多领域他们总是相辅相成,这个话题并非本文关注的重点,若抛开“出身”的因素,我们理解的“纯粹”指的是:

  1. 在原生的体系下,对资源进行组合和抽象,抽象后的资源也不脱离原生体系
  2. 不侵入,不限制,不破坏已有云原生资源的使用约定

得益于K8s的开放性,EDAS实现的原理并不复杂,用户只需要在K8s配置资源(应用),通过声明式的配置将其置于期望的状态上,EDAS就能感知变更,自动维护并调整状态,使其最终与用户期望一致,从而达到管控应用的目的,这一切并不需要修改K8s的版本,只需要安装EDAS提供的扩展即可。

下面从两方面来具体介绍EDAS的做法和因之带来的优势。

云原生应用定义

前文提到,EDAS将应用抽象成了资源,这个过程中,应用定义的设计是至关重要的。在声明式的规则下,应用定义需要能覆盖软件生命周期过程中每个主体的配置,状态和关系的描述,并保证良好的可读性,因此,它必须归纳自大量应用,复杂场景和长久维护的经验总结,也只有这样才能保证定义不脱离实际,能被高效的推演到其他应用上。

EDAS没有重复造轮子,选择了“开放应用模型(OAM)”这一开放标准来作为应用定义,并选择与之共建的方式来丰富标准的内容。可以说,EDAS是OAM在阿里云上的一个实现。

对于开发者来说,EDAS使用OAM提供了两大好处:

  1. OAM消除了厂商平台对开发者的绑定,虽然不同平台能支持的运维特征以及底层实现方式各部相同,但只要厂商都遵循同样的标准,同一份应用配置是可以在不同的平台之间进行迁移的。因此对于EDAS上产生的应用,是可以被迁移到其他同样遵循OAM规范的平台的,针对其他平台迁移EDAS的场景也同理。
  2. OAM隐藏了特定的底层workload类型,通过更高的抽象层次避免了直接操作底层K8s的复杂性,提供了独立的ApplicationConfiguration资源,通过对Component(组件)配置Trait(运维特征)来施加不同的运维能力,Component和Trait的设计较好的分离了开发和运维团队的关注点,让应用生命周期中的配置和协作工作变得更为简单。

由于ApplicationConfiguration也是K8s自定义资源(CR),所以开发者可以直接使用kubectl工具对其进行增删查改操作,EDAS遵循K8s面向终态的设计原则,最终将应用调整到预期的状态,对开发者来说操作应用与操作常规的Deployment资源并没有差异,也可以非常方便的与其他CI/CD工具或者GitOps工作流相集成。

下面给出了一份EDAS的应用yaml示例片段,通过kubectl apply这样一份配置即可创建一个用指定Jar包部署的EDAS应用:

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: helloedas
namespace: default
spec:
components:

  • componentName: stateless-component
    instanceName: group-1
    parameterValues:

    • name: packageVersion
      value: '{"buildPackageUrl":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar","showName":"2020-05-07

      20:20:18","type":"war","url":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar"}'
    • name: artifactFormat
      value: FatJar
    • name: softwareComponents
      value: '[{"componentId":"5","componentKey":"Open JDK 8","createTime":0,"desc":"Open

      JDK 8","downloadUrl":"http://edas-hz.oss-cn-hangzhou.aliyuncs.com/agent/prod/files/jdk-8u65-linux-x64.rpm","expired":false,"id":"5","imageId":"","md5":"1e587aca2514a612b10935813b1cef28","type":"JDK","version":"8"}]'
    • name: replicas
      value: "1"
    • name: showName
      value: helloedas
    • name: description
      value: ""

    traits:

    • name: rollout
      properties:

      • name: auto
        value: "true"
      • name: batches
        value: "1"
    • name: imagebuilder
      properties:

      • name: tag
        value: helloedas-1588854022
      • name: registry
        value: registry-vpc.ap-northeast-1.aliyuncs.com
      • name: baseImage
        value: registry-vpc.cn-hangzhou.aliyuncs.com/edas_unified/edas-openjdk:8-1.0
      • name: timeout
        value: "900"

Deployment编辑

EDAS通过OAM给用户提供了统一的应用模型,而对底层工作负载的管理主要是借助Deployment来完成。

对于无状态应用的管理,Deployment的使用是相当普遍的,它的配置项也颇为丰富。对于习惯了使用Deployment来管理应用的开发者,常常会存在一些相对复杂的配置需求,这里会产生一个矛盾,当特定workload(这里是Deployment)的配置能力超过了OAM模型所定义的运维能力,如何在保留底层自定义配置同时还能维持OAM规范的简洁性和管控的有效性?

纵观软件开发历史,类似的问题并不新鲜,编程语言的发展也是如此,在通用开发领域,高级语言早就替代了机器语言成为开发的主流,因为人的智力是有限的,“抽象”一定是解决复杂问题的利器,这也是前文应用定义产生的重要原因,但对于特殊领域和过渡时期,需要一些“例外”手段来提供足够的灵活性。

因此,尽管用Deployment来直接操作应用存在一些问题,但EDAS并没有“一刀切”的将Deployment的控制权完全收回,而是用“插件式”增强的能力给出了一个答案。

从实现看,EDAS在操作Deployment时默认会通过patch的方式,若需要新建Deployment(比如分批发布),EDAS也会先以之前Deployment为蓝本复制后再进行对应配置调整。因此,只要在配置不冲突的情况下,用户自定义的配置是完全可以继承的,用户可以在EDAS控制台,通过EDAS的API/SDK,或是直接用kubectl工具来修改Deployment,体验上与独立使用Deployment完全一样。

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

“专业”的云原生

因为“纯粹”云原生,开发者可以以原生的方式去理解和使用EDAS,但仅有这一点是远远不够的,云原生只是一个技术框架,而应用管理则是个更具体的业务命题,aPaaS平台必须要有血有肉,才能完成在应用托管,应用可观测性,微服务治理等诸多领域,全方位解决问题的任务。

EDAS既然帮开发者打开了云原生的大门,下一步自然就是将阿里云和阿里中间件的技术优势融入aPaaS,以专业领域的技术优势来帮开发者更好更省的管理应用,这些才是EDAS的“血”和“肉”。

不可否认,开源社区确实贡献了很多的优秀工具,解决了很多的问题,但他们的短板也同样存在,比如:

    1. 特定的工具往往设计为解决某个“点”或某条“线”上的问题,但解决真实的问题很多是需要多角度协作的,在解决这些问题上,使用多个工具难度会更高,效果也不理想。
    1. 在深度使用开源工具后,最终问题可能变成工具自身的维护能力问题,对运维团队更高要求。

EDAS从开始就摒弃了使用开源工具集合来拼凑功能的路线,而是基于经过验证的技术或成熟的云产品,从问题出发,构建一整套专业的解决方案给用户。这样对常见的问题更具有针对性,没有整合和维护的问题。如果开源工具就像瑞士军刀,小巧灵活,随取随用;那EDAS提供的能力更像是数控机床,精准高效,可规模化。

当然,对于开发者而言,使用开源工具或EDAS从不是单选题,在云原生平台下,完全可以通过组合的方式来取长补短,形成最合适的方案。

这里没有全量讲解EDAS功能,仅列举几个典型的微服务治理的场景。

金丝雀发布

金丝雀发布是比较理想的发布方式,可以有效的降低版本发布的风险,也被广泛的用于线上系统的运维过程中,这里不赘述它的好处,对于一次简单的金丝雀发布过程来说,只需要在全量部署前先部署金丝雀实例,能够在验证新版本,验证完发布到全网即可。

但要在生产系统的实现金丝雀发布,至少还需要解决几个问题:

    1. 部署金丝雀实例后需要将特定的请求流量引入金丝雀实例
    1. 观测到金丝雀实例的运行状况并与原有实例的运行状况进行对比
    1. 当金丝雀发布不符合预期时可回滚整个发布过程

可见,“完整”的金丝雀发布所需要的能力并不只是应用托管能力,还需要配合可观测性和微服务治理一起协作完成,因此单纯用某个工具或者用简单的Deployment可能很难解决这些问题。

EDAS也提供了金丝雀发布功能,EDAS的金丝雀发布支持SpringCloud和Dubbo两种开发框架的流量调度,用户只需要上传Jar包,不需要对应用做任何修改,开箱即用。关于EDAS金丝雀发布的使用这里不做详细介绍,可以参考这篇文章:
https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247489003&idx=3&sn=a7827438814bec3175743d77e3cb4aab&chksm=fdeb278bca9cae9dc08912e7b23669b67bb8145f709d155e84f0d6b63fd278df5b954c3b41f9&token=209782105&lang=zh_CN#rd

这里简要列出了EDAS金丝雀发布的重要步骤和参与的组件,可看到一些云产品参与了金丝雀发布的过程,其中ACM用来推送灰度流量规则,ARMS负责采集并呈现监控数据,运行于用户侧的Agent则保证了程序可在用户完全无感知下,按照灰度的规则进行服务注册和数据上报:

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

日志管理

另一个例子是日志管理,应用日志对线上运维有着非比寻常的意义,日志查询也一直是EDAS使用频度最高的功能之一,对于开发者来说完备的日志管理功能就是刚需,EDAS将日志管理的功能通过“日志中心”提供给开发者来使用,其中:

• 实时日志功能可以让开发者在控制台查看到指定容器在前台产生的输出。

• 日志目录功能可以方便用户收藏应用需要关注的特定日志项,并提供了即席查询指定的日志文件内容,和检索特定模式的功能。

实时日志和日志目录功能主要用于满足常用的即席查询需求,但全面的日志管理功能并不仅仅是查询,还包括汇聚,转储,统计分析,监控告警等很多场景,对于这些需求,阿里云的日志服务(SLS)提供了完善的解决方案,SLS完全可以胜任海量日志数据存储,检索,复杂统计分析,多维度数据可视化等场景;而且与流行的开源日志系统(如EFK)相比,SLS在日志管理的功能丰富度,效率,稳定性,成本等方面也均有过之而无不及。

所以,EDAS与阿里云日志服务(SLS)做了很好的集成,开发者只需要在日志中心配置待采集的日志项,即可将相应的日志转储到SLS,完全免去了配置logtail客户端的操作。EDAS + SLS的组合对开发者来说是一对“黄金搭档”,将应用与数据无缝的衔接起来,带来的不仅是流畅的用户体验,而且是直接将产生的数据服务于数据化运营或智能运维决策的能力,这对产品的带来的价值是不言而喻的。

下图描述了EDAS日志管理功能的设计思路:

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

开发者工具

软件开发是软件生命周期的重要环节,开发与运维是密不可分的,开发的质量决定了现网故障数量和维护工作的投入,开发的效率影响着版本迭代速度和问题修复速度。EDAS在提升软件开发者维护效率的同时,也同样关注开发者软件在生产阶段的体验,从提升开发体验中获取更高的生产力。

EDAS提供了丰富的开发者工具集来帮助开发者更高效的完成测试和部署,目前全面支持了EDAS云原生应用,工具如下表:

工具 适用场景 参考文档
OpenAPI 使用编程的方式来使用EDAS功能 https://help.aliyun.com/document_detail/62038.html
SDK 同OpenAPI,支持Java,Python https://help.aliyun.com/document_detail/62123.htmlhttps://help.aliyun.com/document_detail/123354.html
CLI 用命令行的方式使用EDAS功能 https://help.aliyun.com/document_detail/104440.html
Maven Plugin 快速将Java代码部署到EDAS上 https://help.aliyun.com/document_detail/150674.html
AlibabaCloudToolkit 快速部署代码和端云互联测试等 https://help.aliyun.com/document_detail/150670.html
Terraform Provider 快速创建EDAS应用和依赖的资源 https://www.terraform.io/docs/providers/alicloud/d/edas_applications.html

开启云原生时代

EDAS努力为开发者提供“更好”的云原生技术,一方面致力于让云原生从少数人能玩转的“阳春白雪”变成真正成熟易用的技术,释放云原生的价值;另一方面,通过集成阿里云的各种优势技术来增强云原生下aPaaS平台的能力,提供更强大和稳定的应用托管服务。

但如果这些能力需要用户付出高昂的改造成本才能获取,那就是南辕北辙了,所以,使用EDAS必须要比直接使用K8s更为简易,EDAS确实也做到了。对于使用常见的Java框架如SpringCloud,Dubbo开发的应用,EDAS都提供了很方便的接入途径,多数时候并不需要修改软件或者开发流程即可顺利使用,在EDAS创建应用并部署对应的程序包即可;对于使用镜像的应用,EDAS也可以提供正常的功能支持。

这里举一些例子看看各种不同的应用如何轻松的接入EDAS:

  1. 如果您已经是EDAS用户了,并且有EDAS K8s应用,您可以通过点击“升级新版应用管理”,仅需要花费几分钟即可得到全新的应用管理能力,详细操作可以参见此文档(https://help.aliyun.com/document_detail/156823.html)。
  2. 如果您是阿里云容器服务(ACK)的用户,并且有基于Deployment的应用,可以选择将集群导入到EDAS后,将它们一键转化为EDAS应用,这样既能享受EDAS所带来的更丰富的能力,同时还能保留原有的Deployment配置信息。
  3. 如果您尚未使用过K8s或者没有使用过EDAS,那可以从容器服务(ACK)创建一个K8s集群,将其导入EDAS,直接部署Jar包或者War包即可,通过这几个简单步骤,开箱即用的就能拥有EDAS的全部功能。

当下云原生已经蔚然成荫,未来已来,是否使用云原生技术不再是问题。如果您渴望治理软件的纷乱绕杂,但对于驾驭云原生没有十足信心,对后期的维护成本倍感压力,不妨把这些难题都交给EDAS,您只需要关注好业务自身,轻装上阵,快速进入云原生时代。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
4天前
|
Kubernetes Nacos 微服务
nacos常见问题之v2.2.3 k8s 微服务注册nacos强制删除 pod不消失如何解决
Nacos是阿里云开源的服务发现和配置管理平台,用于构建动态微服务应用架构;本汇总针对Nacos在实际应用中用户常遇到的问题进行了归纳和解答,旨在帮助开发者和运维人员高效解决使用Nacos时的各类疑难杂症。
14 1
nacos常见问题之v2.2.3 k8s 微服务注册nacos强制删除 pod不消失如何解决
|
8天前
|
监控 Cloud Native 云计算
构建未来:云原生架构下的微服务治理
【2月更文挑战第30天】随着云计算的不断演进,云原生技术逐渐占据了软件开发与运维的核心地位。本文深入探讨了在云原生生态系统中,如何有效管理和治理微服务,确保系统的高可用性、可扩展性和安全性。通过对容器化技术、服务网格、以及微服务框架的剖析,我们展示了在云平台上构建和管理微服务的先进策略和实践。
|
9天前
|
Kubernetes 开发者 Docker
构建高效微服务架构:Docker与Kubernetes的完美搭档
【2月更文挑战第29天】在当今快速发展的软件开发领域,微服务架构已成为提高系统可维护性、扩展性和敏捷性的关键解决方案。本文将深入探讨如何利用Docker容器化技术和Kubernetes集群管理工具,共同构建一个既高效又可靠的微服务环境。我们将分析Docker和Kubernetes的核心功能,并展示它们如何协同工作以简化部署流程、增强服务发现机制以及实现无缝的服务伸缩。通过实际案例分析,本文旨在为开发者提供一套实用的微服务架构设计和实施指南。
|
13天前
|
负载均衡 算法 微服务
常见的微服务流量治理策略
常见的微服务流量治理策略
19 3
|
1月前
|
设计模式 人工智能 负载均衡
《后端架构设计中的微服务治理与容错机制》
【2月更文挑战第8天】在高并发、大规模应用中,微服务架构已经成为一种常见的设计模式。然而,随着微服务数量的增加,服务之间的依赖关系变得复杂,微服务治理和容错机制成为了关键问题。本文将介绍在后端架构设计中,如何进行微服务治理以及如何实现有效的容错机制,以应对复杂的微服务环境。
|
1月前
|
存储 运维 监控
|
1月前
|
缓存 负载均衡 算法
|
1月前
|
开发者 Docker 微服务
深入浅出:使用Docker容器化部署微服务架构
在当今快速迭代的软件开发环境中,微服务架构因其高度解耦和独立性而成为企业首选。然而,微服务的管理和部署可能会变得复杂和繁琐。本文将探讨如何利用Docker,一个轻量级的容器化技术,来简化和加速微服务的部署。我们将从Docker的基础概念入手,详细介绍如何创建、配置和运行微服务容器,最后讨论Docker在微服务架构中的优势和挑战。本文旨在为开发者提供一条清晰的路径,通过容器化技术实现微服务架构的高效部署和管理。
81 0
|
1月前
|
Kubernetes 开发者 Docker
深入浅出:使用Docker容器化部署微服务架构
在当今快速演进的软件开发领域,微服务架构因其高度的模块化和可伸缩性而受到广泛欢迎。然而,微服务的部署和管理也带来了新的挑战。本文旨在通过深入浅出的方式,探讨如何利用Docker容器技术有效地部署和管理微服务架构。我们将从Docker的基本概念出发,逐步深入到如何构建、部署微服务,并讨论在此过程中可能遇到的常见问题及其解决策略。本文不仅适合刚接触Docker和微服务的新手,也为有经验的开发者提供了实用的参考。
54 1
|
1月前
|
JSON JavaScript Docker
深入浅出:使用Docker容器化部署微服务架构
本文旨在向读者展示如何利用Docker技术高效地构建和部署微服务架构。通过深入浅出的方式,我们将探索Docker的基本概念、容器化的优势以及如何将其应用于微服务架构中。此外,文章还将提供一个简单的示例,指导读者实践如何使用Docker将一个现有的后端应用容器化,并部署到本地开发环境中。不同于传统的摘要,这里我们强调实践操作的重要性,鼓励读者通过实际操作来加深对Docker和微服务架构的理解。
47 1

相关产品

  • 微服务引擎
  • 服务网格