写在前面
嗯，报了华为云的一个《云原生入门级开发者认证》，这里整理课堂笔记记忆，感兴趣小伙伴也可去试试
- 学习的原因：
虽然考了CKA,理解了一些K8s相关的知识，但是对云原生不时都很模糊希望对云原生有一个根本的认识,云原生入门博文主要是课堂笔记借鉴需要写URL，所以改正了原创
傍晚时分，你坐在屋檐下，看着天渐渐地黑下去，心里寂寞而凄凉，感到自己的生命被剥夺了。当时我是个年轻人，但我害怕这样生活下去，衰老下去。在我看来，这是比死亡更可怕的事。--------王小波
一 云原生架构总览
云原生技术的开展
2001年，VMware发布了第一个针对x86效劳器的虚拟化产品ESX和GSX，即ESX-i的前身。2006年10月，以色列的创业公司Qumranet在完成了虚拟化Hypervisor根本功能、动态迁移以及主要的性能优化之后，正式对外宣布了KVM的降生。2009年4月，VMware推出业界首款云操作系统VMware vSphere。2006年，AWS推出首批云产品Simple Storage Service (S3)和Elastic Compute Cloud(EC2)，使企业可以利用AWS的根底设备构建自己的应用程序。2010年7月，Rackspace Hosting和NASA结合推出了一项名为OpenStack的开源云软件方案。2011年，Pivotal推出了开源版PaaS Cloud Foundry，作为Heroku PaaS的开源替代品，并于2014年底推出了Cloud Foundry Foundation。2008年，LXC（Linux Container）容器发布，这是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。LXC是Docker最初使用的详细内核功能实现。2013年，Docker发布，组合LXC，Union File System和cgroups等Linux技术创建容器化规范，docker流行一时，container逐步替代VM，云计算进入容器时代。2015年7月，Google结合Linux基金会成立了CNCF组织，kubernetes 成为CNCF管理的首个开源项目。2018年3月，Kubernetes 从CNCF毕业，成为 CNCF 第一个毕业项目。
云原生的定义
云原生定义-Pivotal早期观点
Pivotal公司的Matt Stine于2013年首次提出云原生的概念,并推出了Pivotal CloudFoundry和Spring系列开发框架,是云原生的探路者。
2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征
符合12因素应用(12 Factors Application)面向微效劳架构(Microservices)自效劳敏捷集成设备(Self Service Agile Infrastructure)基于API的协作(API-Based Collaboration)抗脆弱性(Antifragility)
云原生定义-Pivotal当前论述
Pivotal官方网站对云原生最新论述如下:
云原生是一种构建和运行应用程序的方法,它利用了云计算交付模型的优势;云原生关注如何创建和部署应用程序,而不是在何处(云计算);虽然如今公有云影响了几乎每个行业的根底设备投资思想,但类似云的交付形式并不只限于公有云环境,它适用于公有云和私有云;云原生结合了DevOps、持续交付、微效劳和容器的概念;当公司以云原生方式构建和运营应用程序时,它们可以更快地将新想法推向市场并更快地响应客户需求;
2019年，Pivotal被vmware收购，成为其子公司。
云原生定义-CNCF早期观点
云原生计算基金会(以下简称CNCF)是一个开源软件基金会,成立于2015年7月,附属于Linux基金会。致力于云原生(Cloud Native)技术的普及和可持续开展。。CNCF是GitHub上许多增长最快的项目的提供者的中立家园，其中包括Kubernetes，Prometheus和Envoy等
起初,CNCF对云原生的定义包含以下三个方面:
应用容器化(Software stack to be Containerized)面向微效劳架构(Microservices Oriented)应用支持容器的编排调度(Dynamically Orchestrated)
到2018年,随着社区对云原生理念的广泛认可和云原生生态的不时扩大,还有CNCF项目和会员的大量增加,起初的定义已经不再适用。
云原生定义-CNCF当前定义.(2018年更新后的定义论述如下:)
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、效劳网格、微效劳、不可变根底设备和声明式API。
可变效劳器根底架构:效劳器会不时更新和修改。使用此类根底架构的工程师和管理员可以通过SSH连接到他们的效劳器,手动晋级或降级软件包,逐个效劳器地调整配置文件,以及将新代码直接部署到现有效劳器上。换句话说,这些效劳器是可变的;它们可以在创建后停止更改。由可变效劳器组成的根底设备自身可称为可变传统或(贬低)手工艺。
不可变根底架构:其中效劳器在部署后永远不会被修改。假设需要以任何方式更新,修复或修改某些内容,则会根据具有相应更改的公共映像构建新效劳器以交换旧效劳器。经过验证后,它们就会投入使用,而旧的则会退役.
不可变根底架构的好处:根底架构中更高的一致性和可靠性,以及更简单,更可预测的部署过程。它可以缓解或完全防止可变根底架构中常见的问题,例如配置漂移和雪花效劳器。但是,有效地使用它通常包括全面的部署自动化,云计算环境中的快速效劳器配置,以及处置状态或短暂数据(如日志)的处置方案
云原生核心理念
总得来说有以下几大核心理念:
利用容器和效劳网格等技术,解耦软件开发,进步了业务开发部署的灵敏性和易维护性以Kubernetes为核心的多层次、丰富的开源软件栈,被各大厂商支持,用户选择多,防止厂商绑定以Kubernetes为核心的松耦合平台架构,易扩展,防止侵入式定制Kubernetes已被公认是platform for platform中心式编排,对应用和微效劳停止统一的动态管理和调度,进步工作效率和资源利用率
云原生的技术版图
底层:主要是在运行容器化效劳之前,需要为容器准备规范化的根底环境,比如用于自动化部署和配置容器运行平台和环境,代表性工具和厂商包括Ansible、Chef 、Puppe ,OpenStack等。容器镜像库。凭据管理主要用于在整个容器平台中停止秘钥管
Runtime(运行时):容器的整个运行环境,是云原生底层技术中最核心的部分它包括了运行时、存储、网络三大块,Runtime提供容器的运行环境(Docker)。存储要处置容数据器耐久化的问题。网络也是非常核心且非常复杂多变的一块内容,常见方案有Calico、Flannel ,open Switch等。
编排调度层,主要负责容器平台的编排和调度,包括效劳的发现和治理,远程调用效劳代理,微效劳治理等组件。
最上层 就是跟应用定义与开发相关的内容,主要是一些技术或工具来支撑。
横向上 云原生还包括众多的经过认证的平台供给商。应用运维层,包含了大量用于对平台停止监控(Prometheus-Nagios -Grafana 、Zabbix等) 、日志(Fluentd ,ElasticSearch ,Logstash) 、以及追踪(Jaeger)的工具。最后还有一块是关于无效劳器架构serverless的内容
容器技术-进步应用可移植性,提升业务敏捷
容器可以将应用自身及其依赖打包,使得应用可以实现“一次封装,到处运行”。容器也可以理解成一种沙盒技术,沙盒在计算机安全领域中是一种安全机制,为运行中的程序提供的隔离环境。
容器核心价值可移植性:
环境规范化,应用随处运行敏捷:创建速度快,秒级资源弹性进步消费力:消除跨效劳依赖性和抵触
主流的容器技术,如Docker,它是通过内核虚拟化技术(namespace以及cgroups等)来提供容器的资源隔离与安全保证。由于Docker通过操作系统层的虚拟化实现隔离,所以Docker容器在运行时,不需要类似虚拟机额外的操作系统开销,进步资源利用率。同时,Docker可以协助你快速地测试、快速地编码、快速地交付,并且缩短从编码到运行应用的周期,从而使得企业实现业务敏捷。
Kubernetes的声明式API-面向开发者提供全新分布式原语
针对期望状态结果给出声明,而不是过程
对于我们使用Kubernetes API对象的方式,一般会编写对应API对象的YAML文件交给Kubernetes (而不是使用一些命令来直接操作API) 。
所谓“声明式”,指的就是我只需要提交一个定义好的API对象来“声明”(这个YAML文件其实就是一种“声明”)表示所期望的最终状态是什么样子就可以了。而假设提交的是一个个命令,去指导怎么一步一步到达期望状态,这就是“命令式”了。可以说,声明式API是Kubernetes项目编排才干“赖以生存”的核心所在。
效劳网格-剥离业务代码和分布式框架
非侵入式接收应用效劳通信细粒度流量治理:灰度发布、故障注入、可观测性支持平台团队聚焦框架层的开发和调优业务团队聚焦业务自身的开发
Service Mesh -词最早由开发 Linkerd 的Buoyant公司提出,并于2016年9月29日第一次公开使用了这一术语效劳网格通过非侵入式的方式接收应用的效劳通信。对于每个业务单元/模块来说他们甚至不需要对网络通信、负载平衡等有任何的感知,。效劳网格提供细粒度流量治理,包括灰度发布、故障注入、可观测性支持等才干,挺高了业务应用的易维护性。对于企业开发者来说,效劳网格可以很好地协助他们剥离业务代码和分布式框架。
微效劳-加速企业应用架构晋级
在CNCF的定义中,微效劳也是作为一种代表性的技术,而实际上,微效劳更偏重于描绘软件架构,这种软件架构相比单体架构,更加可以发挥云原生相关的技术优势
微效劳是一种用于构建应用的架构方案,它是松懈耦合的分布式架构框架,因而一个团队的更改不会破坏整个应用。使用微效劳的好处是,开发团队可以快速构建应用的新组件,以满足不时变化的业务需求。
微效劳架构有别于更为传统的单体式方案,可将应用拆分成多个核心功能。每个功能都被称为一项效劳,可以单独构建和部署,这意味着各项效劳在工作(和呈现故障)时不会互相影响。比如你在线购物时,使用搜索栏来找产品,这个搜索功能就是一项效劳,同时你也看到了相关产品推荐,这些推荐也是来自于另外一项效劳,还有购物车等,都是一项一项的效劳
DevOps -促进开发运维一体化
DevOps=开发(Development) +运维(Operations) ,是打通开发与运维之间的壁垒,促进开发、运营和质量保证(QA)等部门之间的沟通协作,以便对产品停止小规模、快速选代式地开发和部署,快速响应客户的需求变化。它强调的是开发运维一体化,加强团队间的沟通和快速反响,到达快速交付产品和进步交付质量的目的。
云原生应用
云原生应用程序是专为云模型构建的。这些应用程序由小型专用功能团队快速构建和部署到一个平台,可提供轻松的横向扩展和硬件解耦-为组织提供跨云环境的更高灵敏性,弹性和可移植性。”- Pivotal
云原生应用是独立的小规模松懈耦合效劳的集合,旨在提供备受认可的业务价值,例如快速交融用户反响以实现持续改进。简而言之,通过云原生应用开发,可以加速构建新应用,优化现有应用并将这些应用全部组合在一起。其目的是以企业需要的速度满足应用用户的需求。” -RedHat
云原生应用理解
基于云原生的相关技术,设计运行在云上的,充沛发挥云优势的应用。一般采用容器的打包、分发、部署的形式,应用内(间)采用微效劳的架构,充沛利用云提供的组件效劳,采用DevOps的组织架构和方法,通过CI/CD工具链,实现产品和效劳的持续交付。
传统应用与云原生应用的区别
云原生应用的12-Factors要素
Heroku于2012年提出12因素,告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。
第一基准代码。一份代码库对应多份部署,所有部署的基准代码相同,但每份部署可以使用不同的版本
第二,依赖。显式声明依赖关系,通过依赖清单确切的声明所有依赖项,这一做法会统一应用到消费和开发环境。
第三,配置。在环境中存储配置,推荐将应用的配置存储于环境变量中,环境变量可以非常方便地在不同的部署间做修改,却不动一行代码。与配置文件不同,不小心把它们迁入代码库的概率微乎其微,与一些传统的处置配置问题的机制,比如Java的属性配置文件相比,环境变量、语言和统计无关。
第四,后端效劳。把后端效劳当作附加资源,每个不同的后端效劳是一份资源,例如个mysql数据库是一个资源,两个mysql数据库被当做两个不同的资源,云原生应用将这些数据库都视作附加资源,这些资源和他们附属的部署坚持松耦合。
第五,构建发布运行云原生应用,需严格区分构建、发布、运行这三个步骤。举例来说,直接修改处于运行状态的代码是非常不可取的做法,因为这些修改很难再同步回构建步骤
第六,进程。以一个或多个无状态进程运行应用,在运行环境中,应用程序通常是以个或多个进程运行的
第七,端口绑定。通过端口绑定来提供效劳。
第八,并发。通过进程模型停止扩展,在12-factor应用中,进程是一等公民。12Factor应用的进程主要借鉴于unix守护进程模型。开发人员可以运用这个模型去设计应用架构,将不同的工作分配给不同的进程类型。例如,HTTP恳求可以交给web进程来处置,而常驻的后台工作则交由worker进程负责
第九,易处置。快速启动和优雅终止和最大化强健性,这有利于快速弹性的伸缩应用迅速部署变化的代码或配置文件的部署应用。
第十,开发环境与线上环境等价,尽可能的坚持开发预发布线上环境相同。
十一,日志。把日志当做事件流,日志应该是事件流的汇总,将所有运行中的进程和后端效劳的输出流,依照时间顺序搜集起来。
十二,管理进程。后台管理任务当做一次性进程运行,一次性管理进程应该和正常的常驻进程使用同样的环境,这些管理进程和任何其他的进程一样,使用相同的代码和配置,基于某个发布版本运行,后台管理代码应该随其他应用程序代码一起发布,从而防止同步问题
云原生架构原则及常用形式
云原生架构演进原则
弹性:微效劳采用无状态设计,支持按需使用、自动水平伸缩;实例快速启动,并在不影响业务的前提下优雅中止。这一点可以充沛利用云的弹性的特征,利用云环境提供的镜像、监控、资源动态编排和调度效劳。设计应用程序时,不绑定特定根底资源使其可以自由伸展,根据需要增删实例。
分布式:更多强调解耦。应用侧,则是业务逻辑和数据解耦、业务逻辑和会话解耦,数据分布式,每个效劳拥有自己的数据库,效劳不能直接访问其他效劳的数据库,只能通过效劳接口访问其他效劳的数据。
高可用,高可用的概念范畴比较广,云原生应用的设计特征,Design For Failure,即“为失败而设计”,这里主要强调基于不可靠的根底设备资源来设计高可用系统,并且在应用实例失效的情况下,系统能快速发现并恢复。高可用的设计的主要原则有可观测、可灰度、可回滚等。实现的方式有很多种,比如,通过k8s实现POD状态的监测和维护,通过灰度发布、蓝绿部署等手腕来保证晋级、回滚时系统的高可用。
自动化:业务/效劳的颗粒度更小,交付部署更频繁,迫切需要系统可以自动化部署同时要加强对效劳以及所部署的软硬件环境的全方位监控、评估才干。
自效劳:自效劳强调效劳可被其他应用或开发者自助发现,自助按需获取,自助使用并计量,自助效劳管理。自效劳的前提是高度自治,同时,从易用性的角度,暴露友好的交互方式(Web界面、命令行、SDK…) ,使能应用开发者简单、高效地使用其提供的功能
云原生应用架构考虑:
单体架构的局限性
单体架构的问题不在于不可拆分上,在于无法隔离和自治。应用规模越大,局限性越明显
云原生架构形式:微效劳架构
微效劳架构就是其中一种实现方式。它实现了效劳彻底拆分,各效劳可以独立打包、独立部署和独立晋级,对开发者而言,摆脱开发语言的束缚。每个微效劳负责的业务比较明晰,利于后期扩展和维护。微效劳之间可以采用REST和RPC协议停止通信。同时,微效劳架构可以和其他云原生技术完美结合,充沛发挥云的优势。
微效劳独立性和敏捷性更好,架构持续演进更容易,更适宜云原生应用
云原生架构形式: Serverless架构
Serverless (无效劳器架构) 指的是由开发者实现的效劳端逻辑运行在无状态的计算容器中,它由事件触发,完全被第三方管理,Serverless是在传统容器技术和效劳网格上开展起来,更偏重让使用者只关注自己的业务逻辑即可。
Serverless方案业务价值更轻量化:
用户专注于业务创新和代码开发,代码运行环境由云平台提供,无需管理根底设备资源。更快弹性:根据恳求的并发数量自动调度资源运行函数,毫秒级弹性伸缩,高效应对业务峰值。更低本钱:根据函数调用次数、运行时长和节点转换次数计费,函数不运行时不产生费用,更加节省成
适用场景:
短时运行处置:闲时报表处置、定时日志分析、小程序后端事件驱动处置:实时图片处置、实时数据流处置、loT规则/事件处置显著波峰波谷:视频转码、视频直播、热点事件推送
Serverless与微效劳的关系:
微效劳向Serverless演进,并长期共存
华为云云原生处置方案
华为云长期投入云原生技术与产业,是全球云原生领域指导者
华为云基于擎天架构
云原生根底设备:在云原生根底设备方面,华为云基于擎天架构实现了基于应用SLA来灵敏调度算力,根据应用IO的不同,动态分配网络带宽,根据应用粒度大小,自动分配不同的存储。云原生应用与根底设备不再割裂,而是互相可感知,从而为业务提供更高性价比、资源高效的容器效劳。
极致弹性、极致性能的云原生根底设备底座
基于云原生根底设备的多云管理处置方案
基于云原生根底设备的高性能计算处置方案
基于云原生根底设备的边云协同处置方案
KubeEdge是华为捐献给CNCF的第一个开源项目,也是全球首个基于Kubernetes扩展的,提供云边协同才干的开放式边缘计算平台。KuberEdge就是依托Kubernetes的容器编排和调度才干,实现云边协同、计算下沉、海量设备接入等。
KubeEdge的边缘相当于把Node节点拉远,并停止一些优化从而实现边缘自治; Kubernetes master运行在云端,用户可以直接通过kubectl命令行在云端管理边缘节点、设备和应用,使用习惯与Kubernetes原生的完全一致,无需重新适应。边缘端部署轻量级进程,并支持边缘节点的离线运行
华为云DevSecOps让应用开发更安全…
企业级微效劳管理平台,加速微效劳应用开发和高可用运维
云原生将来开展趋势
Kubernetes编排统一化:编排对象不时扩展延伸
Kubernetes 的编排对象持扩展
以容器为根底编排对象逐步延展至虚拟机、函数等,理论上所有可编程、有API、可笼统成资源的对象,都在成为Kubernetes的编排对象。
应用侧围绕Kubernetes生态加速演
以Kubernetes为核心的云原生技术栈将推广到更多的应用场景。在大数据领域,Spark和Kubernetes的集成已经非常普遍;机器学习方面,用Kubernetes去编排机器学习的工作流以获得业界的广泛共识。
效劳治理Mesh化:加速传统应用转型
Istio、 Consul ,Linkerd是Service Mesh领域最受欢送的三大处置方案。
Mesh化是传统应用转型云原生的关键途径
效劳治理与业务逻辑解耦：将效劳通信及相关管控功能从业务程序中分别并下层到根底设备层,使其和业务系统完全解耦,使开发人员更加专注于业务本异构系统的统一治理：通过效劳网格技术将主体的效劳治理才干下沉到根底设备,可方便地实现多语言、多协议的统一流量管控、监控等需求。
传统应用架构中业务和功能耦合度较高,无法充沛发挥云的效能,传统应用中用于治理效劳的中间件效劳通常与应用强绑定部署,治理才干被植入每个应用,反复造轮子现象严重。
Mesh化加速业务逻辑与非业务逻辑的解耦。将非业务功能从客户端SDK中分别出来放入独立进程,利用Pod中容器共享资源的特性,实现用户无感知的治理接收。效劳治理的Mesh化为传统应用轻量化改造提供了前提,也为云平台沉淀通用效劳治理才干,加速中间件下沉为根底设备提供了可能。
应用效劳Serverless化:更加聚焦业务的核心价值
Serverless将进一步释放云计算的才干,将安全、可靠、可伸缩等需求交由根底设备实现,使用户仅需关注业务逻辑而无需关注详细部署和运行,极大地进步应用开发效率。同时这个方式促进了社会分工协作,云厂商可以进一步通过规模化、集约化实现计算本钱大幅优化。 |
