免费私人网站建设,lnmp wordpress lamp,萍乡做网站,中铁门户网登录云原生技术
容器技术
容器与虚拟化
虚拟化#xff08;Virtualization#xff09;和容器#xff08;Container#xff09;都是系统虚拟化的实现技术#xff0c;可实现系统资源的”一虚多“共享。容器技术可以理解成一种”轻量的虚拟化“方式#xff0c;此处的”轻量“主…云原生技术
容器技术
容器与虚拟化
虚拟化Virtualization和容器Container都是系统虚拟化的实现技术可实现系统资源的”一虚多“共享。容器技术可以理解成一种”轻量的虚拟化“方式此处的”轻量“主要是相比于虚拟化技术而言的。列如虚拟化通常在Hypervisor 层实现对硬件资源的虚拟化Hypervisor为虚拟机提供了虚拟的运行平台管理虚拟机的操作系统的运行每个虚拟机都有自己的操作系统、系统库以及应用。而容器并没有Hypervisor 层每个容器是与主机共享硬件资源和操作系统的。
容器技术在操作系统层面实现了对计算机系统资源的虚拟化在操作系统中通过对CPU、内存和文件系统等资源的隔离、划分和控制实现进程之间的透明的资源使用。 容器镜像
镜像是容器运行的基础容器引擎服务可使用不同的镜像启动相应的容器。在容器出错后它能通过迅速删除容器、启动新的容器来恢复服务这都需要以容器镜像作为支撑技术的。与虚拟机所用的系统镜像不同容器镜像不仅没有Linux 系统内核同时在格式也有很大的区别。虚拟机镜像是将一个完整的系统封装成一个镜像文件而容器镜像不是一个镜像文件容器镜像是分层存储的文件系统。需要注意的是当需要修改镜像内的某个文件时只会对最上方的读写层进行改动不会覆盖下层已有文件系统的内容。
容器存储
镜像元数据
在Liunx 系统中Docker的数据默认存放在 /var/lib/docker 中 基于不同的系统又有不同的存储驱动和不同的目录结构。我们以OCI标准格式来了解镜像存储的内容如图所示 镜像每一层的 ID是该文件内容的散列校验值作为该层的唯一标识。获取镜像后会使用以下方式索引镜像 首先读取镜像的 manifests 文件根据 manifests 文件中 config 的 sha256 码得到镜像 config 文件遍历 manifests 文件里面的所有层layer根据其 sha256 码在本地查找拼出完整的镜像。
存储驱动
在理想情况下我们使用挂载卷来存储高读写的目录很少将数据直接写入容器的可写层。但是总有一些需要直接写入容器可写层的特殊需求这时候就需要存储驱动来作为容器和宿主机之间的媒介。Docker 依靠驱动技术来管理镜像与运行它们的容器间的存储和交互。
目前 Docker 支持 overaly2、aufs、fuse-overlayfs、devicemapper、btrfs、zfs、vfs等存储驱动。没有单一的存储驱动可适用所用的应用场景要根据不同的场景选择合适的存储驱动这样才能有效提高 Docker 性能
数据卷
通常有状态的容器都有数据持久化存储的需求。前一节提到过文件系统的改动都是发生在最上面的可读 写层。在容器的生命周期内它是持续的包括容器被停止后。但是当容器被删除后该数据层也随之被删除了。因此Docker 采用数据卷Volume的形式向容器提供持久化存储。数据卷是 Docker 容器数据持久化存储 的首选机制。绑定挂载Bind Mounts依赖于主机的目录结构但数据卷是由 Docker 管理。
与绑定挂载相比 数据卷有以下几个优点
与绑定挂载相比数据卷更容易备份或迁移可以使用 Docker CLI命令或 Docker API 管理数据卷数据卷在 Linux和 Windows 上均可使用数据卷可以在多个容器之间更安全地共享数据卷驱动程序允许在远程主机或云上存储数据卷、加密卷的内容或添加其它功能新数据卷的内容可以由容器预填充另外与使用容器的读写层保存数据相比数据卷通常是更好的选择。因为使用数据卷存储不会增加容器的大小并且数据卷是持久化的不会依赖于容器的生命周期。
容器网络
单从云计算的发展来看业界普遍的共识是计算虚拟化和存储虚拟化已经不断突破和成熟但网络虚拟化的发展仍相对滞后成为制约云计算发展的一大瓶颈。网络虚拟化、多租户、混合云等特性均不同程度地给云网络地安全建设提出全新的挑战。
容器技术提供了轻量级虚拟化的能力使实列资源占有大幅降低提升了分布式计算系统的性能但分布式容器系统的网络仍是较为复杂的部分。目前容器网络可以简单分为主机网络和集群网络其中主机网络以 Docker 为列主要分为 None 网络模式、Bridge 网络模式、Host 网络模式和 Container 网络模式。集群网络以 Kubernetes 为列由于Pod 作为 Kubernetes 应用运行的基本单元每个Pod 中包含一个或多个相关的容器这些容器都会运行在同一个主机中并且共享相同的网络命名空间和相同的Linux 协议栈。因而集群网络基于Pod 主要涉及以下三个通信同一个Pod内容器和容器之间的通信同一个主机内不同Pod之间的通信跨主机Pod之间的通信。
容器运行时
容器运行时负责管理容器运行的整个生命周期包括但不限于指定容器镜像格式、构建镜像、上传和拉取镜像、管理镜像、管理容器实例、运行容器等。在容器技术发展早期Docker 作为容器运行时的标准被广为使用而后Google、CoreOS、Docker等公司在2015年联合创建了开放容器标准Open Container InititiativeOCI用于推进容器标准化其主要包含两个标准分别为容器运行时的标准和容器镜像标准OCI的容器运行时主要包括runC、Rocket、Kata Containers、gVisor等。再后来随着容器编排技术的不断发展处于行业翘楚的Kubernetes推出了容器运行时接口Container Runtime InterfaceCRI用于与容器运行时进行通信进而操作容器化的应用程序当前支持的CRI运行时包括Docker、Contained、CRI-O。
容器编排
集群化、弹性和敏捷是容器应用的显著特点如何有效地对容器集群进行管理是容器技术落地应用地一个重要方面。集群管理工具编排工具能够帮助用户以集群的方式在主机上启动容器并能够实现相应的网络互联同时提供负载均衡、可扩展、容错和高可用等保障。目前来看使用率和关注度比较高的几种容器编排平台主要包括Kubernetes、Apache Mesos、Docker Swarm、OpenShift、Rancher等、目前来看Kubernetes在容器编排领域占据较大优势。许多公有云厂商也推出了各自的Kubernetes托管云平台国外公有云厂商主要以Google、Amazon、Microsoft Azure 为主国内则以阿里、腾讯、华为为主。
微服务
2014年Matrin Fowler 撰写的 Microservices 使得许多国内的先行者接触到微服务这个概念并将其引入国内Matrin Fowler对微服务的概念的定义如下微服务就是将一个完整应用中所有的模块拆分为多个不同的服务其中每个服务都可以部署、维护和发展服务之间通常通过RESTful API 通信这些服务围绕业务能力构建且每个服务均可使用不同的编程语言和不同的数据存储技术。
2015年越来越多的人通过各种渠道了解到微服务的概念并有人开始在生产环境中落地2016年—2017年微服务被越来越多的人所认可一大批公司以微服务和容器为核心开始了技术架构的全面革新于是微服务架构应运而生。
至今为止微服务发展已经经历了两代第一代是Dubbo、Spring Cloud 为代表的微服务治理框架该类框架在微服务发展的前几年一度独领风骚、甚至在部分人群中成为微服务的代名词但事实上该类框架并不能友好地解决微服务自身带来地一些问题如微服务地调用依赖、版本迭代、安全性、可观测性等第二代微服务治理框架为服务网格他的出现解决了大部分开发人员在使用Spring Cloud 时遇到地不足和痛点。
服务网格
2017年年底服务网格Service Mesh依托其非侵入式特性在微服务技术中崭新头角作为微服务间通信地基础设施层。服务网格通常通过一些轻量级网络代理实现这些代理与应用程序一起部署而无需感知应用程序本身。 可以看到 Sidecar 运行在服务旁对服务透明。由于所有通过服务地流量均会经过 Sidecar 因此 Sidecar 可实现流量控制功能如服务发现、负载均衡、智能路由、故障注入、熔断器、TLS终止等。服务网格的出现将微服务治理从自身中抽离出来这种方式极大降低了代码的耦合度使得微服务治理不在复杂。
Serverless
随着云原生技术的不断发展应用的部署模式逐渐趋向于“业务逻辑实现与基础设施分离”的设计原则Serverless无服务器架构指的是由开发者实现的服务端逻辑运行在无状态的计算容器中它由事件触发 完全被第三方管理其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless使得开发者无需直接处理服务器无论是物理机虚拟机容器等。无主机的优势会让使用者在服务器维护方面的操作开销大大减少无需为升级服务器而忧心无主机还意味着在应用程序中需要监控的度量指标也会不同。这是因为使用的大多数底层服务不会再发布 CPU、内存、磁盘大小等传统度量指标了。这让不再需要再特别关心架构的底层操作细节。Serverless使开发者避免了基础设施管理如集群配置、漏洞修补、系统维护等。
Serverless通常可分为两种实现方式即BaaSBackend as a Service后端即服务和FaaSFunctions as a Service,函数即服务其中 FaaS是Serverless的主要实现方式。简而言之FaaS即开发者编写的一段代码并定义何时以及如何调用该函数随后该函数在云厂商提供的服务端运行在此过程中开发者只需要编写并维护一段功能代码。
此外FaaS本质上是一种事件驱动并由消息触发的服务事件类型可能是一个HTTP请求也可能是一次上传或保存操作事件源与函数的关系如图所示: FaaS的典型代表为AWS Lambda为便于理解下述为一个简单的Lambda Python处理函数
import jsondef lambda_handler(event, context):
return {statusCode: 200,body: json.dumps(Hello from Lambda!)
}可以看出以上代码导入了JSON Python库并定义了一个lambda_handler函数该函数需接收两个参数分别为event和context其中event参数包含此函数收到的事件源信息参数类型通常是Python的dict类型也可以是list、str、int、float等类型而context参数包含此函数相关的运行时上下文信息。 上图大致展示了传统的服务端应用部署和FaaS应用部署当应用程序部署在物理机、虚拟机、容器中时它实际上是一个应用进程并且由许多不同的函数构成这些函数之间有着相互关联的操作一般需要长时间在操作系统中运行而FaaS通过抽离虚拟机实例、操作系统和应用程序进程改变了传统的部署模式使开发者只需关注单个函数操作剩余基础设施管理均由第三方托管平台提供当有事件触发时函数被执行开发者为使用的资源付费。
DevOps
开发运营一体化DevOps全称为 DevelopmentOperations 其代表的并非一种具体的实现技术而是一种方法论在2009年被提出。DevOps的出现主要是为了打破开发人员与运维人员之间的壁垒和鸿沟高效地组织团队通过自动化工具相互协作已完成软件生命周期管理从而更快且频繁地交付高质量、稳定的软件。
云原生倡导敏捷、容错、自动化的特点使得DevOps 成为云原生基础不可或缺地一环究其根本原因我们可以将其分为以下几点
云原生提供DevOps基础设施
容器与编排技术提供了云原生的标准运行环境及基础架构。DevOps的和核心点在于软件的持续集成、持续交付而容器作为云原生应用的标准发布促进了DevOps在云原生环境下的流行与此同时基于容器的PaaS平台如 Kubernetes 可进一步为DevOps 的落地提供土壤。
微服务架构加速DevOps的应用
微服务架构实现了云原生应用固有的特点即无状态性、弹性扩展、高内聚、低耦合。在此此架构下试想在生产环境中由于一个庞大的应用被拆分为几十个上百个服务每个服务的开发、构建、部署过程必然遵循快速发布的原则因而在敏捷性、自动化工具链上对流程提出了较高的要求。在此基础上DevOps 的自动化、协作、敏捷的文化将会在很大程度上加速微服务的开发效率、降低沟通成本、提升部署效率。
DevOps 赋能服务网格
服务网格是一套微服务治理框架主要实现各个微服务间的网络通信虽然服务网格技术本身与DevOps关系不大但由于其建立在微服务架构下因而也须与 DevOps 相融合这样才能实现微服务的持续集成和交付。
DevOps 加速 Serverless 应用迁移
Serverless 为云原生应用的最终形态即服务端托管云厂商开发者只需要维护好一段函数代码即可这一新型云计算模式背后秉承的理念实际与DevOps是相互契合的。DevOps 遵循消除 开发者与运维人员之间的壁垒而Serverless 架构的责任划分原则使得开发者人员和运维人员不在有界限。
