云原生的优势简单来说有以下几点:
对于微服务化架构而言,拥有了更小的体积代表了未来将会是更少的下载带宽,而且更快地分发下载速度,在工作上会提高工作效率,节省更多的工作时间。
相比传统的单体应用而言,启动速度与运行效率快慢并不是重要的指标,但是对于需要快速迭代、水平扩展的云原生微服务架构应用而言,更快的启动速度就意味着更高的交付效率,和更加快速的回滚,尤其是面对较多应用的时候,可能仅仅才500ms的反应时间也会让用户感觉到延迟,从而造成用户的体验感变差。
在实际的运行中占用的资源更低,也就代表了更高的部署密度和更低的计算成本,同时,在JVM启动时需要消耗大量CPU资源对字节码进行编译,降低启动时资源消耗,可以减少资源争抢,更好保障其他应用SLA。
也就说,在如今的实际使用中,云原生应用和服务既可以用JSON来处理数据,也可以用protocol buffer 或传统的 XML 来构造数据。很大程度上满足了不同的用户需求,无论是操作,还是实际都带来极大的便利性。
云原生架构的主要特点是微服务、容器化、DevOps 、持续交付四个主要的特点,也正因为如此它的资源是可以按照实际情况进行伸缩,这样不但提高资源的利用率,也大大降低了企业成本。
云原生架构依托于容器编排工具(K8S)与微服务的组合,应用就拥有了自动恢复能力、容错能力、故障隔离能力,让应用时刻处于可用的状态。
因为使用了容器化技术,应用运行于容器之中,应用就不需要考虑底层硬件的差异,只要是能运行容器镜像的硬件都可以运行程序,大大简化了开发工作量。同时对运维人员也非常友好,不需要再为环境问题而苦恼。
云原生技术:重塑数字化未来的关键架构
云原生技术是一个革命性的概念,它涵盖了docker、kubernetes、Service Mesh和Serverless等关键技术,由Google、IBM等科技巨头推动。本文将深入探讨其定义演变、技术路径、与云计算的融合以及对开发者的挑战,以期全面理解这一趋势的力量和影响。
2015年,Pivotal提出了云原生应用的12因素原则和微服务架构,强调自服务和弹性。随后,CNCF在2015年至2018年间,定义了云原生的核心特性,包括容器化、微服务导向和动态编排,进一步明确了在动态环境中构建可扩展应用的技术基础,如容器、服务网格等。
Cloud Native Computing Foundation (CNCF)的Landscape图谱展示了这一领域的丰富生态,囊括了Kubernetes、etcd等核心项目,以及众多围绕容器、服务管理和服务编排的组件,构成了一幅完整的云原生技术生态图谱。
随着云计算的兴起,开发者需要适应云原生架构,频繁进行可预测的变更,以适应云计算的动态环境。云计算提供了弹性裸金属服务器、分离式存储与计算资源,以及混合云网络的支持,与云原生技术共同推动了企业的数字化转型。
开发者的要求开发者在云原生环境中工作,需要掌握CRD(Custom Resource Definitions)和Controller模式,利用Kubernetes提供的强大平台,以实现应用的快速部署、扩展和故障恢复。同时,理解服务网格(Service Mesh)的原理,如Istio和Linkerd,对于优化服务间的通信至关重要。
云原生的最终目标是实现系统的弹性、容错性和高效性,通过快速迭代和交付,推动业务创新。在这个不断变化的时代,深入理解云原生技术,将赋予开发者在数字化竞争中保持领先地位的优势。
进一步研究:
云计算最近几年已经火得不行, 云原生 (Cloud Native)这个概念又来了,如果上云不“原生”,那就等于白上云。究竟什么是云原生?云原生有何优势?怎么从“不原生”一步一步做到云原生?本文将给出切实可行的云原生落地指南。
我们先从云计算说起 。在云计算普及之前,一个应用想要发布到互联网,就需要企业自己先买几台服务器,找一个IDC机房,租几个机架,把服务器放进去。接下来就是装Linux系统,部署应用。我们就假定用Java写了Web应用,怎么部署上去呢?先配置Tomcat服务器,在把编译好的war包上传到服务器,有用FTP的,安全意识高一点的会选SCP,然后配置Nginx、MySQL这些服务,最后一通调试,把应用跑起来,就算齐活。
这种物理机配合自搭网络环境、自搭Linux、自配环境的方式,有很多缺点,但最主要的问题有这么几个:
解决方案是上云 。上云不能解决所有问题,但部分解决了前两个问题:
但是如果仅仅满足上云,把物理机换成虚拟机,把物理网换成虚拟专用网(VPC),是远远不够的。这些是计算资源和网络资源层面的简化。应用方面,如果延续旧的一套开发、测试、部署流程,做不到快速迭代。
要做到快速迭代,敏捷开发,就需要DevOps,即开发运维由一个团队负责,开发阶段,就要把部署、运维的工作考虑进去,而不是发布一个war包或者jar包后扔给运维不管了。
重开发、轻部署,直接后果就是缺少自动化发布流程。想要把部署规范化,就需要整体考虑一系列问题。
还是以Java应用为例,如果是手动部署,那么就上传war包到服务器,覆盖原有的版本,重启Tomcat,再测试。如果发现有严重问题要回滚怎么办?把老版本再传一遍,然后重启Tomcat。
手动部署,每次部署都是一次生死考验,所以最好不要安排在半夜,以免手抖敲错了命令,本来中断10分钟的服务,变成了灾备恢复,中断3天。
稍微靠谱一点的是写脚本部署,但各家写出来的脚本都有各家特色,不通用,不易维护,所以更好的方式是用成熟的部署方案,比如Ansible,把脚本标准化,比如做成蓝绿发布,把服务器分组,比如A、B两组,先把流量切到B组,升级A组服务器,有问题就回滚,没问题了,再把流量切到A组,升级B组服务器,最后,恢复正常流量,整个部署完成。
但是回滚这个事情,远没有那么简单。做过开发的同学都知道,升级新版本,一般要加配置,改配置,如果回滚到旧版本,忘了把配置改回去,那旧版本可能也不能正常工作。
上云,除了物理变虚拟,简化运维外,最重要的特点——弹性计算,一定要充分利用。
理论指导实践,实践完善理论。如果我们分析大多数基于互联网的应用,可以看到,一个应用,通常用到的资源如下:
上云后,云服务商通常都提供托管的数据库,以及大规模存储系统(S3),可解决存储资源问题。通过云服务商提供的负载均衡(Load Balancer),也无需自行部署Nginx等网关,免去了运维的问题。各种标准的业务组件如Redis、Kafka等,均可直接租用云服务商提供的资源。
我们重点讨论计算资源,也就是云上的虚拟机资源。对于应用来说,可以设计成有状态和无状态两种。一个应用在一台虚拟机内跑着,如果有本地文件的修改,它就是有状态的。有状态的应用既不利于扩展,也不利于部署。反过来,如果一个应用在运行期数据总是存在数据库或者缓存集群,本地文件无任何修改,它就是无状态的。
无状态的应用对应的虚拟机实际上就是不变的计算资源。这里的“不变”非常重要,它是指,一台虚拟机通过一个固定的镜像(预先内置好必要的支持环境,如JRE等)启动后,部署一个应用(对应一个war包或者jar包),该虚拟机状态就不再变化了,直接运行到销毁。
有的同学会问:如果给这台虚拟机重新部署一个新的应用版本,它的状态不就发生了变化?
确实如此。为了确保虚拟机的不变性,一旦启动后部署了某个版本,就不允许再重新部署。这样一来,对虚拟机这种计算资源来说,就具有了不变性。不变性意味着某个虚拟机上的应用版本是确定的,与之打包的配置文件是确定的,不存在今天是版本1,明天变成版本2,后天回滚到版本1的情况。
计算资源不变,能确保启动一台虚拟机,对应发布的应用版本和配置是确定的且不变的,对于运维、排错非常重要。
那么如何在保持计算资源不变的前提下发布新版本?
我们以AWS的CodeDeploy服务为例,假设一组正在运行的某应用v1集群包含3台虚拟机:
现在,我们要把应用从v1升级到v2,绝不能直接把现有的3台虚拟机的应用直接升级,而是由CodeDeploy服务启动3台新的一模一样的虚拟机,只是部署的应用是v2。现在,一共有6台虚拟机,其中3台运行v1版本,另外3台运行v2版本,但此刻负载均衡控制的网络流量仍然导向v1集群,用户感受不到任何变化:
v2集群部署成功后,做一些自动化冒烟测试和内网测试,如果有问题,直接销毁,相当于本次部署失败,但无需回滚。如果没有问题,通过负载均衡把流量从v1集群切到v2,用户可无感知地直接访问v2版本:
稳定一段时间(例如15分钟)后,销毁v1集群。至此,整个升级完成。
上述的蓝绿部署就是CodeDeploy的一种标准部署流程。CodeDeploy也支持灰度发布,适用于更大规模的应用。
把计算资源不可变应用到部署上,实际上是充分利用了弹性计算这个优势,短时间创建和销毁虚拟机,只有上云才能做到,并且针对云计算,把部署流程变得更加简单可靠,每天发几个版本甚至几十、几百个版本都变得可能,DevOps能落地,有点“云原生”的味道了。
说到AWS的CodeDeploy,最早我使用AWS时,对于它的计费采用Reserved Instance预付模型感到很不理解,租用一台虚拟机,按国内阿里云、腾讯云包年包月预付享折扣不是更直观吗?如果仅仅把上云变成租用虚拟机,那就完全丧失了弹性计算的优势,相当于租用了一台虚拟机在里面自己折腾。AWS的Reserved Instance计费并不绑定某一台虚拟机,而是一种规格的虚拟机。
我们还是举例说明,如果我们有1台2v4G规格的虚拟机,并购买了1年的Reserved Instance,那么,我随时可以销毁这台虚拟机,并重新创建一台同样规格的新的虚拟机,Reserved Instance计费会自动匹配到新的虚拟机上,这样才能实现计算资源不变,频繁实施蓝绿部署,真正把部署变成一种云服务。最近阿里云终于推出了节省计划的付费模式,有点真正的云计算的付费味道了,但是腾讯云、华为云还停留在包年包月和按量付费这两种原始租赁模型。
讲了这么多自动化部署,实际上一个指导思想就是如何充分利用云的弹性计算资源。从充分利用云的弹性资源为出发点,设计一整套开发、部署、测试的流程,就是云原生。弹性资源利用得越充分,云原生的“浓度”就越高,就越容易实施小步快跑的快速迭代。
那么虚拟机是不是弹性最好的计算资源呢?从应用的角度看,显然容器是一种比虚拟机更具弹性,更加抽象,也更容易部署的计算资源。
容器和虚拟机相比,它实际上是一种资源隔离的进程,运行在容器中的应用比独占一个虚拟机消耗的资源更少,启动速度更快。此外,容器的镜像包含了完整的运行时环境,部署的时候,无需考虑任何额外的组件,比其他任何部署方式都简单。使用容器,开发部署流程就变成了开发,生成镜像,推送至Docker Hub或云服务商提供的Registry,直接启动容器,整个过程大大简化。
使用容器比使用CodeDeploy部署还要更加简单,因为CodeDeploy需要在虚拟机镜像中预置Agent,由于没有统一的发布标准,还需要配置CodeDeploy,告诉它去哪拉取最新版本,这又涉及到一系列权限配置。而容器作为标准的部署方案,连发布系统都以Registry对各个镜像版本进行了有效管理,所以部署非常简单。
容器作为一种弹性计算资源,也应遵循计算不变性,即不要给容器挂载可变的存储卷。一组不变的容器集群才能更容易地升级。容器的运行方式本身就遵循了不变性原则,因为通过一个镜像启动一个容器,在运行过程中,是不可能换一个镜像的。容器本身也强烈不建议应用写入数据到文件系统,因为重启后这些修改将全部丢失。
容器的启动和销毁非常容易,不过,容器的管理却并不简单。容器的管理涉及到创建、调度、弹性扩容、负载均衡、故障检测等等,Kubernetes作为事实上的容器编排标准平台,已经成为各个云服务商的标配。
如果要直接使用K8s,在云环境中首先要有一组虚拟机资源作为底层资源,然后搭建K8s环境,定义好容器编排并启动容器。云服务商几乎都提供托管的K8s服务,但直接管理K8s仍然需要非常熟悉K8s的工程师。
还有一种更简单的使用容器的方式,即完全将底层虚拟机和K8s托管给云服务商,企业客户只需关心如何部署容器,底层的K8s和虚拟机对企业不可见或者无需关心。AWS的Elastic Container和阿里云的弹性容器均为此类服务。对于中小规模的应用来说,计算资源直接使用容器,再配合云服务商提供的负载均衡,托管的数据库、消息系统、日志系统等组件服务,应该是目前最“云原生”的一种方案。
最后,我们总结一下云原生的特点:
所谓云原生,就是在上云的过程中,充分发挥云平台的弹性计算、弹性存储的优势,尽量把应用设计成适合云计算的架构,把部署设计成简单易用的流程,这样才能实现业务快速上线,快速迭代。
云原生是一个大方向,在上云的过程中,逐步改造应用架构和部署流程,从手动往自动转,逐步增加计算资源的弹性,就能把云原生一步步落地。
1、云原生存储云原生存储的概念来源于云原生应用,指一个应用为了满足云原生特性的要求,其对存储所要求的特性是云原生存储的特性,而满足这些特性的存储方案,可以称其为倾向云原生的存储。 能够提供这类服务的产品,就是云原生存储产品。 2、云原生存储产品有哪些特点?块接口——优点:高可用、低延迟、单应用吞吐更高缺点:容量弹缩弱、数据共享性差。 文件系统接口——优点:多负载共享数据、多负载吞吐更高缺点:共享数据时,文件锁性能差。 对象存储接口——优点:高可用、大容量、多负载共享数据、多负载吞吐更高缺点:时延高。 3、具体推荐要根据实际情况来定,不同的接口偏向不同的业务。
华为云原生,是华为云提供的一种面向云原生架构的计算、存储、网络和安全的综合云服务平台,是帮助企业快速构建和运维云原生应用的理想选择。 它采用了业界领先的Kubernetes容器编排引擎,提供了多种PaaS和IaaS层的云服务,能够实现高可用性、弹性扩展和负载均衡等关键功能。 华为云原生的核心特点在于构建和管理企业级应用程序。 它采用的是一种全新的面向微服务的开发模式,将应用程序拆分为各个独立的服务单元,然后对这些服务单元进行组装,以构建出一个完整的分布式系统。 同时,它还提供了完整的生命周期管理服务,包括应用程序开发、构建、测试、部署和运维,以帮助企业快速构建和管理优质的云原生应用。 对于企业来说,华为云原生不仅可以提供快速的应用程序开发和部署,还可以实现更高效的IT资源利用和更低的运维成本。 它提供的多种服务和功能使得企业能够更快速地调整自己的业务和服务,提升自身的竞争力。 同时,由于它采用的是一种分布式计算模式,靠近终端的边缘计算服务可以帮助企业更有效地处理大量数据,以实现更准确和可靠的智能决策。
云原生是一个组合词,可以拆分为“云”和“原生”两个词,“云”我们都知道,即在线网络,传统的应用原本都跑在本地服务器上,很有可能需要停机更新,且无法动态扩展,“云”表示应用程序运行在分布式的云环境中,可以频繁变更,持续交付。 “原生”表示应用程序在设计前期就考虑到了云平台的弹性和分布式特性,也就是为云设计的。 可以简单理解为:云原生=微服务+DevOps+持续交付+容器化| 微服务 |即软件架构,使用微服务架构可以将一个大型的应用程序按照功能模块拆分成多个独立自治的微服务,每个微服务仅仅实现一种功能,具有很明确的边界。 带来的好处有哪些?1)服务的独立部署每个服务都是独立的项目,可以独立部署,不依赖于其他服务,耦合性低。 2)服务的快速启动拆分之后服务启动的速度要比拆分之前快很多,因为依赖的库少了,代码量也少了。 3)更加适合敏捷开发。 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行。 服务拆分可以快速发布新版本,修改哪个服务只需要发布对应的服务即可,不用整体重新发布。 4)职责专一,由专门的团队负责专门的服务。 业务发展迅速时,研发人员也会越来越多,每个团队可以负责对应的业务线,服务的拆分有利于团队之间的分工。 5)服务可以动态按需扩容当某个服务的访问量较大时,我们只需要将这个服务扩容即可。 6)代码的复用每个服务都提供REST API,所有的基础服务都必须抽出来,很多的底层实现都可以以接口方式提供。 | 容器化 |是云原生的核心技术,它是一种相对于虚拟机来说更加轻量的虚拟化技术。 能为我们提供一种可移植、可重用的方式来打包、分发和运行程序。 容器的基本思想就是将需要执行的所有软件打包到一个可执行程序包。 例如,将一个Java虚拟机、Tomcat服务器以及应用程序本身打包进一个容器镜像。 用户可以在基础设施环境中使用这个容器镜像启动容器并运行应用程序。 而Docker是目前应用最为广泛的容器引擎,容器化为微服务提供实施保障,起到应用隔离作用,K8S是容器编排系统,用于容器管理,容器间的负载均衡,Docker和K8s都采用Go编写,(K8s全称Kubernetes,由首字母K,结尾字母s以及中间的8个字母组成,所以简称为K8s)。 | DevOps |是软件开发人员和IT运维人员之间的合作过程,是一种工作环境、文化和实践的集合,目标是高效地自动执行软件交付和基础架构更改流程。 开发和运维人员通过持续不断的沟通和协作,可以以一种标准化和自动化的方式快速、频繁且可靠地交付应用。 | 持续交付 |就是不误时开发,不停机更新,是一种软件开发方法,它利用自动化来加快新代码的发布。 在持续交付流程中,开发人员对应用所做的更改可通过自动化被推送至代码存储库或容器镜像仓库。
Oracle等传统数据库架构无法满足企业面临的业务挑战,电信、金融和政务等客户正在核心系统领域加速上云。 基于这样的背景,6月9日,2020阿里云峰会,阿里巴巴副总裁、阿里云数据库负责人李飞飞提出,“今年要完成套传统数据仓库上云。 ”在许多采访中,企业主们无一例外表示,新冠疫情的冲击反而加速了企业上云的步伐。 诸多案例也表明,上云成为了不可避免的趋势。 但在上云的过程中,技术门槛和高额的试错成本,都有可能变成压垮中小企业的稻草。 作为提供新基础设施的阿里云厂商,其角色更像是一种普惠技术的提供者。 “需要提供一项普惠技术,一是降低技术门槛,不需要学习太长时间,减轻企业上云门槛;二是价格不能太贵,否则中小企业用不起。 科技从诞生到全面普及有一个S曲线,逐渐坡爬到过程,技术越成熟,成本越低,人群越广。 ”商汤产业战略研究院院长、阿里云研究院创始人田丰曾经在采访中表示。 在当天的采访中,李飞飞用了一个案例比喻了云原生数据库的本质。 以往数据库资源的使用方式像是往家里打一口水井,但今天不需要家家户户打井,而是做一个将自来水厂资源池化的工具,按需按量调度,灵活调度。 “实现高可用弹性可拓展,是促成中国企业,甚至世界范围内企业从传统商业数据库向云原生数据库迁移转型的最本质原因。 ”李飞飞认为这样的云原生数据库,给上云中的成本问题提供了一个解决方案。 而云计算云原生架构带来的技术先进性,必然会发生的对传统商业数据库发生挑战和替代的过程。 阿里云智能总裁张建锋表示,今年不仅会在基础设施上加大投入,同时将大规模引进顶级科技人才,阿里云再招5000人,重点吸引云服务器、网络、芯片、数据库、人工智能等核心技术领域的攻坚人才。 中小企业如何上云如今,中小企业在大数据、人工智能上的技术革新,带来了商业和经营模式的创新,这反过来也导致了另一批中小企业在物流、中介、信息收集等领域的护城河和赖以生存的优势受到挑战。 数字化的转型成为了中小企业们不可回避的话题。 尽管数字化转型碰上新基建的风口,这一潮流一方是巨大的投资,一方连接的是千亿市场机会,但成本和如何上云成为了摆在诸多中小企业面前的难题。 尽管一些地方政府会给企业上云提供补贴,但一些企业主们思考的却是如何拿到上云补贴,而不是如何使业务更好地上云。 中小企业在上云的需求上存在诸多不同。 李飞飞的了解中,中小企业上云的前一成本和所需时间和大企业来说更低,时间更短。 其次,所需的产业支撑体系也没有大型企业需要的产品支撑体系那么丰富。 另外,中小企业的整个IT支撑系统,是通过独立软件开发商(ISV)提供的第三方SaaS层解决方案,阿里云需要和这些ISV合作,比如ERP、CRM系统迁移上云,底座换成云原生的数据库,“在这个过程中中小企业可能还没有意识到底座已经用到了云的技术,但实际上已经完成了上云的过程。 ”阿里云官网代金券2000元礼包领取入口:点击领取安全与成本曾经一位帮助中小企业建立数字化转型平台的企业主说,中小企业们在上云时更多还会考虑安全性问题,毕竟要将自己的所有工业数据迁移到公有云上。 李飞飞说,相对于自建云来说,至少在阿里云的实践中,云提供了更加安全的环境和可靠的基础设施。 从数据安全及业务可靠上来说,是不存在这方面的顾虑。 另外,他表示,一些企业有阶段性分批分步骤实施计划,短期内有一些监管原因需要把数据放在自己的机房或者私有云这样的部署方式。 对于数据安全,田丰还曾提出过“数据信托”的概念,“不管在哪个云上,数据始终是客户的,如果想做更多开发,一定要和客户商谈。 现在云计算厂商主要做技术类服务,对数据没有兴趣。 如一些公司跟某些保险公司做数据共创和服务,那是业务层的协议,跟底下云技术服务协没关系的,后者挣的是工具类的钱,而不是数据的钱。 ”但与此同时,高额的试错成本,也使得中小企业在实质上云的过程中出现阻碍。 张建锋表示,阿里云的300多万企业客户中,大部分是中小企业。 阿里云之于中小企业,张建锋比喻,就如同一个新兴淘宝,“原来去做零售,要在线下开一个店,店主要进货要去卖,去做所有不擅长的事情,例如开店租房本质上跟零售没有关系。 现在中小企业在云的时代,相当于在公共服务平台。 ”但成本和价格,两者如何兼顾?“实现资源池化资源解耦更好的弹性以后,使用成本价格一定会下降”,李飞飞认为,以前资源是紧耦合的,当存储需要扩展的时候,计算资源必须绑定一起扩展,虽然可能不需要更多的计算资源,反之亦然。 但今天,资源解耦弹性以后是按需按量、分钟级的弹性,存储计算分开谈,成本和价格肯定会下降。 李飞飞和团队曾分析过一个典型的OLTP在线交易业务系统和传统的商业数据库,使用云原生数据库的弹性能力,成本整体降到原来的六分之一左右。 数字基础设施已成新趋势:云原生数据库如何解决中小企业上云关键问题标签:商业软件开发关系现在绑定服务器回避数字化学习
什么是云原生存储云原生是一种开发和运行软件应用程序的新范式,它融合了云计算、容器化、Serverless 和微服务等技术趋势。 云原生存储是一种旨在用于云原生环境的存储技术。 云原生存储平台可以存储管理有状态应用程序的数据,并解决 Kubernetes 或其它基于云原生环境的基础设施中一直存在的数据存储挑战问题。 分布式架构中的对象存储可以基于现代对象存储、块存储或传统磁盘驱动器提供数据存储服务。 云原生应用和传统应用并没有一个标准的划分界限,其描述的是一种技术倾向,即越符合以下特征的应用越云原生化:应用容器化服务网格化声明式 API运行可弹性扩展自动化的 DevOps故障容忍和自愈平台无关,可移植的云原生应用是一簇应用特征能力的集合,而实现了这些能力的应用在可用性、稳定性、扩展性、性能等核心能力都会有大幅的优化。 优异的能力代表了技术的方向,云原生应用正在引领各个应用领域实现云原生化,同时也在深刻改变着应用服务的方方面面。 存储作为应用运行的基石,也在服务云原生化过程中遇到了更多的需求与挑战。 云原生存储的主要特点云原生存储的关键特性如下:高可用性云原生存储必须在高需求中可用。 存储系统需要具有即使在事件失败时也能访问数据的功能——无论是在传输系统、存储介质、控制器还是其他组件中。 存储高可用性的 3 个要素:在其它存储设备上,维护数据的复制副本。 在任何故障情况下,冗余设备都会处理故障转移。 故障组件可以修复和恢复。
Kubernetes核心组件
Controller Manager主要提供了一个分发事件的能力,而不同的Controller只需要注册对应的Handler来等待接受和处理事件。 在Controller Manager的帮助下, Controller的逻辑可以做的非常纯粹,只需要实现相应的EventHandler即可,以Deployment controller为例。
Kubernetes default scheduler的特点:基于队列的调度器;一次调度一个Pod;调度时刻全局最优。
云计算批量计算面临的挑战:1、作业管理缺失;2、调度策略局限;3、领域计算框架支持不足;4、资源规划复用、异构计算支持不足
与临时存储相比,持久化存储的优势:
引入PV/SC之后带来更大的效益:
pv/pvc适合在资源管理比较严格的场景
pvc绑定pv的流程
无论在资源管控严格还是资源管控敏捷的场景,资源管理员都希望通过创建K8S的存储接口来管理容器存储资源 K8S通过存储声明(PVC)、存储类(SC)和存储插件(driver)联合工作,满足用户一键式定义,创建存储。
CSI架构:部署简单、功能强大、扩展灵活、容器存储接口的标准
无状态工作负载(deployment)更新
容器健康检查使用 liveness probe (工作负载存活探针)和 readiness probe (工作负载业务探针)。 Kubernetes支持如下三种探测机制:
弹性伸缩是根据业务需求和策略,经济地自动调整弹性计算资源的管理服务。包括 工作负载弹性收缩 和 节点弹性收缩 。
云原生应用特点:
云原生可观测性
目前,Prometheus已经成为云原生监控领域的事实标准
Kubernetes本身并没有用户管理能力,无法像操作Pod一样,通过API的方式创建/删除一个用户实例,也无法在etcd中找到用户对应的存储对象 在Kubernetes的访问控制流程中,用户模型是通过请求方的访问控制凭证(如Kubectl使用的kube-config中的证书、Pod中引入的ServerAccount)产生
认证
鉴权
Istio架构分层主要分为:控制面Istiod(Pilot Citadel Galley Sidecar-Injector)和数据面(Envoy Pilot-Agent)
Sidecar基本介绍
流量治理基本API
简化服务治理配置:熔断、降级,超时,重试,A/B测试,金丝雀发布,基于权重的流量切分,故障检测与恢复
Istio提供以下可观测能力(非侵入):
课程链接:打卡链接:
本文地址:http://www.hyyidc.com/article/15486.html
上一篇:高可用数据中心存储确保业务连续性高可用方...
下一篇:SecureFTP保护您的文件传输免受威胁secureb...