K8s将集群中的机器划分为一个主节点和一群工作节点，在主节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager 和 kube-scheduler，这些进程实现了整个集群的资源管理、pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是全自动完成的。集群中的工作节点运行真正的应用程序，各自又通过若干组件的组合来实现。在节点上，K8
DevOps 是一个持续改善软件产品的过程，它通过极短的发布周期、全面自动化的集成和交付流水线，以及团队间的紧密协作来不断改善产品。DevOps 的目标是缩短将创意变成用户可以使用的产品的时间，并降低这个过程的成本。DevOps 充分利用自动化流程来加速开发和部署。如下图对比传统软件构建方法和 DevOps 方法，传统方法在上，DevOps 在下面：●半部分的传统方法，从概念构思到用户可用的时间周
云原生应用与云原生应用平台
SOA 是一种设计方法，它通过提供服务向外提供一系列功能，服务之间通过网络调用，而非采用进程内调用的方式进行通信。SOA可软件的复用性，如多个终端共享一个以应用于庞大的单块应用程序，从而提高服务。SOA 更倾向于理论和概念的层面，关于服务的粒度定在哪个层级，服务如何落地，如何保证可用性等问题有待解决。我们所知软件的运行是离不开外部环境的，对于软件所依赖的环境，SOA涉及面较少。微服务就在此情况下诞
Kubernetes 的核心就是控制理论，Kubernetes控制器中实现的控制回路是一种闭环反馈控制系统，该类型的控制系统基于反馈回路将目标系统的当前状态与预定义的期望状态相比较，二者之间的差异作为误差信号产生一个控制输出作为控制器的输入，以减少或消除目标系统当前状态与期望状态的误差，如图1所示。这种控制循环在Kubernetes上也称为调谐循环。图1反馈控制回路对Kubernetes来说，无论
网络流量控制技术确保处于同一个云计算数据中心的虚拟机能够获得可靠的网络带宽，是云计算数据中心重要的技术。在实际的运营中，虚拟机实际的控制权属于租户，网络流量控制就是保证各个租户的的利益，保证租户的访问流量保持一个稳定的状态。总体上，实现流量控制可以采用网络设备控制和物理主机控制两种方式，如图1所示。图 1网络流量控制 网络设备控制可以通过在交换机上对每个端口
容器应用应当根据应用系统的特点，综合考虑容器应用对存储类型、存储性能及数据高可用等方面的要求，选择最适合的存储资源类型。常见的存储资源应用场景包括三类：将存储挂载在外部宿主机上、将存储放置于容器内部和使用外部共享存储。下面对每种应用场景的优缺点、Volume 类型选择、适用场景进行分析和说明。一、将存储挂载在外部宿主机上（1）优点：数据不会因为容器销毁而丢失，可永久保存；存储性能与直接在物理机上使
在多中心多云环境下，可将容器云部署为多活和灾备模式，通过全局负载均衡器实现应用的多中心多活与灾备。容器应用跨数据中心的双活，是将一个应用的不同副本部署到不同的数据中心，如图 1 所示的 Database 应用。图1 Database应用双活图 1 中的方案设计的两个重要的技术点。（1）三个不同区域将有三个OpenShift集群。每个集群都有一个有状态的工作负载实例，工作负载实例是一个数据库。（2
在云计算数据中心运行过程中，如果对一台物理机进行检修，就需要将运行在这台物理机上的所有虚拟机迁移到另一台物理机上，此时虚拟机的网络环境也需要实时迁移，否则迁移之后的网络功能会出现问题，例如出现虚拟机中运行的网站可能无法被访问等问题。因此，虚拟机的实时迁移过程中对迁移网络环境有着很高的要求。为了解决这个问题，可通过网络层面解决实时迁移的问题。逻辑
通常用户在构建新的应用系统时，都会按照负载的最高峰值来进行资源配置，而系统的负载在大部分时间都处于较低的水平，于是导致了资源的浪费。但如果按照平均负载进行资源配置，一旦应用达到高峰负载时，就无法正常提供服务，影响应用系统的可用性以及用户的体验，所以，在平衡资源利用率和保障应用系统的可用性之间总是存在矛盾。云计算的弹性资源提供的特点正好可以解决目前所面临的资源利用率与应用系统可用性之间的矛盾。资源的
容器云PaaS平台可以根据不同的业务重要程度、对用户影响范围、故障处理时效等因素划分的的容灾等级可以针对不同的容灾等级采用不同的容灾策略。如果数据中心的某个主机在业务高峰时期出现了超负载或者容量不足的现象，进而产生告警，容器云 PaaS平台进行自动扩容。根据告警情况制定扩容策略，比如自定义CPU和内存的使用率、各项业务峰值、自定义时延、检测响应状态码是否正常、追加容灾服务、检测服务是否可用等等。自
laaS对众多的物理资源进行划分和重组，提供给用户。laaS具体管理的物理资源可以分为三大类：计算资源（CPU、内存）、存储资源和网络资源。从计算资源角度来讲，laaS软件管理的最小的物理单元为一个物理服务器。根据需求，可以在服务器上创建多个虚拟机，如图1所示。配置相同的物理服务器支持虚拟机动态迁移，通常一些集群还会组成更大规模的区域（Zone）。集群、区域的划分会体现在对网络和存储的不同配置上
一个Kubernetes平台可以管理几百台容器主机，以及运行在这些主机上的容器应用。如果容器主机采用裸金属服务器，则一台容器主机上运行的容器应用可以超过200个。也就是说，一个 Kubernetes 平台编配的容器应用数量是数千到数万个，要想确保这么多容器应用正常运行，且各自运行在对应的容器主机上，并对这些容器应用的生命周期进行合理管理，就需要Kubernetes自身的架构具有一定的可靠性及比较
公有镜像仓库是指暴露在互联网、可以从互联网的任意位置拉取镜像的镜像仓库，比如docker.io、quay.io等熟知的公有镜像仓库，企业可以通过公有镜像仓库优缺点对比来拉取合适的镜像。公有镜像仓库优势：（1）开放：任何人都可上传、分享镜像到公有镜像仓库中。（2）便捷高效：搜索、拉取其他开发者的镜像便捷高效。（3）成本低：企业无需购买硬件、解决方案来搭建镜像仓库，五需团队来维护。（4）免运维：只需
laas基础设施平台分为三层：基础设施资源池、资源管理平台和业务管理平台，如图1所示。基础设施资源池作为实现融合基础设施结构的关键要素，是共享服务器、存储和网络的集合，能够根据应用程序的要求更快地进行重新配置，从而能够更容易、更快捷地支持业务需求的变化。图1laaS 平台架构laaS管理平台由资源管理平台和业务服务管理平台组成。资源管理平台对基础设施服务池
镜像仓库主要功能是进行镜像存储、镜像管理和镜像分发。每一个仓库可以包含多个镜像，用标签进行区分。通常在使用镜像时，要充分考虑镜像仓库类型、仓库应用、具体应用版本三个要素。通过镜像仓库可以方便地在多个运行环境之间共享镜像，通过容器快速模拟相同的运行环境以运行应用，避免因运行环境的不同而导致应用运行异常或行为不一致。镜像中包含应用的主体，以及应用需要的运行环境、工具集等。在构建镜像时，可以指定镜像
对于Kubernetes集群，监控的内容包含以下两个方面：●基础平台服务的监控实时监控核心组件（API Server、调度器、控制器、kubelet和kube-proxy等）的健康状态，用以发现用户流量和组件的CPU、内存和网络等的使用情况之间的联系。这些数据不仅能帮助我们甄别出单个组件是否服务异常，还能帮助运维者找出性能出现瓶颈的原因，保证组件有足够的资源满足用户
微服务和微服务之间有调用关系，所有调用关系都经过API网关，最终的调用链如图1所示。基于API 网关的数据转发如图1所示，展示了4个微服务之间的3次调用，可以看出任何服务到服务之间的调用都要从调用方通过负载均衡器到API网关再到目标服务。那么如何优化部署以减少对API网关的依赖呢？答案是，使用服务网格。图1基于API网关的数据转发服务网格是一个可配置的、低延迟的网络架构，与API网关的功能有很多共
信息技术的发展，如今数据存储能力上升到了 TB、PB 级别，企业和政府部门都以各种形式存储了大量的数据，如何快速有效地处理规模大、结构复杂的数据？本文主要介绍大数据的三类应用架构MapReduce、Hadoop、Spark，进行数据处理。一、MapReduceMapReduce是大规模数据集的并行运算，是实现关联规则的挖掘算法，MapReduce 设计上具有以下主要的技术特征。（1）MapRedu
在应用运行管理的环境中，PaaS模糊了物理资源的限制，在应用看来是一个按需索取、无限可扩的虚拟平台，如图1所示。PaaS作为云应用的运行环境，云应用通过PaaS所提供的编程接口API按需获取运行所需要的各种（虚拟的）资源和能力。一般来讲，资源的获取是动态及时的。例如，平台层根据应用程序的负载起伏，动态估计所需的计算和存储资源，按照服务质量的约定（SLA）按需提供所需资源。从自动化的角度来看，Paa
微服务架构将原本一个庞大的业务系统被拆分成许多粒度很小的系统进行独立部署和维护。这必然会导致跨系统交互复杂度增加、不同服务之间依赖关系变得更加复杂，这给微服务的生命周期管理和版本变更管理带来极大的挑战。基于API网关，可以将微服务之间的直接依赖转化为对API网关的依赖，从而降低耦合关系。如图1所示，API网关是为一组微服务提供统一API访问的组件，基于不同的场景，其承担的职责从单纯请求转发到安全
Kubernetes作为一个容器云管理平台，与底层的基础架构、企业周边的公共服务形成了一个完备的生态系统。如图1所示，一个完备的Kubernetes系统在设计和实现时，需要考虑多层面的高可用性问题。图1 Kubernetes 平台的生态系统因此，解决系统性的高可用问题，需从下到上立足各个层面，找出每层的最优解决方案，最终串联组成最优的整体解决方案。1.基础架构管理数据中心规划，为了支
PaaS平台整合各种不同的软硬件资源向应用提供统一的资源和功能。通过整合，应用运行所需的各种资源和基础功能以统一的编程模型和调用接口暴露给应用使用，应用无须关注下层的细节。同时，PaaS平台根据所支持的应用类型，可以精心选择和优化所提供给应用的资源和服务，使得应用的开发和运行变得更为简单高效。如图1所示，平台即服务可能建立在多个基础设施服务之上，需要对应用
在架构设计之初，要避免单点故障，路由、防火墙、负载均衡、反向代理及监控系统等在网络和应用层面上必须全部是冗余设计，以此来保证最佳的可用性。下面介绍一些提高系统可用性的常规方法。1.服务冗余主备模式是传统的服务冗余方法之一，根据策略又可分为N+1、N+2 等模式。N+1的主备模式，即将两个设备绑成设备对儿。针对频繁变更的系统，单纯的主备模式不够用，由此建议至少部署N+2个实例。N+2的主备模式能够保
对于一个应用的需求，一般分为两个方面∶一方面是与业务相关的功能性需求；另一方面就是诸如安全性、可靠性及服务质量等非功能性的需求。应用的开发阶段主要考虑功能性要求，而运行阶段主要关注非功能要求。不同的应用在非功能性要求方面具有一定的相似性，为了支持这些非功能性要求，人们通常总结出一定的功能模块和模式。这些模块和模式是PaaS层支持应用运行的基本方式。PaaS 层的一个重要目标就是把业界在过去多年来在
Docker的网络实现基本原理是利用了Linux 的网络命令空间和虚拟网络设备，因为Linux 通过在内核中进行数据复制来实现虚拟接口之间的数据转发，即发送接口的发送缓存中的数据包将直接复制到接收接口的接收缓存中，而无须通过外部物理设备进行交换，Docker 中的网络接口默认都是虚拟接口，虚拟接口的最大优势就是转发效率极高。对于本地系统和容器内系统，虚拟接口与一个正常的以太网卡相比并无区别，只是它
云计算的环境中资源和应用规模变化大，部署过程所支持的软件系统形式多样，系统结构各不相同，因此对快速部署的要求较高。为了进一步提高云环境中虚拟机的部署速度，则需要考虑并行部署或者协同部署技术。并行部署是同时执行多个部署任务，将虚拟机同时部署到多个物理机上，如图1所示。图1并行部署系统架构并行部署可以成倍地减少部署所需时间，但存储镜像文件所在的部署服务器的读写能力或者部署系统的有限网络带宽却制约实际
在开发应用时，通常会把这些应用中共有的部分或者需要使用到的功能抽离出来作为基础服务，以供编写和运行从而降低应用创建和运维的复杂性。这一系列应用所要用到的基本功能即为平台层所提供的服务。当前，PaaS上运行的应用主要分为两类∶一类是Web服务类PaaS平台架构如图1所示；另一类是数据分析服务，其PaaS平台架构如图2 所示。前一类应用主要是通过浏览器访问、采用请求/响应模式进行交互的应用，称为事务处
DevOps团队的文化价值是实现跨职能高度协同，研发和交付一体化的思维。其整体组织和角色分析如下：1.组织组织中主要困难是跨多个职能团队协作，因此需要一种自上而下的组织模式，能够充分考虑不同团队的痛点，在多个职能团队中推行Dev0ps文化，改进企业交付流程。这种组织以业务线或者应用为中心来组建跨职能团队，打破了传统的部门墙，使得统一业务线上沟通更加便捷，而且团队中各角色目标一致。不同的企业定义的组
在DevOps中想要实现快速、高质量的业务交付，流程和规范是至关重要的。流程包含软件从需求提出到产品上线投产全套生命周期的所有环节，如需求提出、代码提交、上线流程等。规范包含敏捷需求分解规范、用户故事编写规范、需求输出表等。一、流程流程用于指导组织中各角色之间如何协作以及各环节可能使用的工具等。典型的DevOps流程如图 1所示。图1DevOps流程图在图1中的DevOps流程包括产品立项、需求分
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
