m0_60258751的博客

边缘计算和容器技术存在多个共同点，如分布式应用的支持以及降低延迟等，两者的结合可以为不同的业务场景提供了丰富的机遇，因此，越来越多的企业开始考虑实现边缘计算与容器技术的结合，但成功实施需要仔细考虑多个关键因素。

Kubernetes 的核心就是控制理论，Kubernetes控制器中实现的控制回路是一种闭环反馈控制系统，该类型的控制系统基于反馈回路将目标系统的当前状态与预定义的期望状态相比较，二者之间的差异作为误差信号产生一个控制输出作为控制器的输入，以减少或消除目标系统当前状态与期望状态的误差，如图1所示。（2）比较二者的差异，而后运行控制器中的必要代码操作现实中的资源对象，将资源对象的真实状态修正为Spec中定义的期望状态，例如创建或删除 Pod 对象，以及发起一个云服务 API 请求等。

在云计算数据中心运行过程中，如果对一台物理机进行检修，就需要将运行在这台物理机上的所有虚拟机迁移到另一台物理机上，此时虚拟机的网络环境也需要实时迁移，否则迁移之后的网络功能会出现问题，例如出现虚拟机中运行的网站可能无法被访问等问题。逻辑架构如图 1所示。第6个步骤非常关键，如果出现其中一个环节没有衔接好，则可能会出现：交换机不知道 MAC 地址对应的物理链路已经发生了改变，所以如果虚拟机在迁移之后本身没有向外发送任何包，那么外界访问虚拟机的包都不会转发给物理机 B，而仍然转发给物理机 A。

当某个数据中心发生故障时，容器云 PaaS 平台会采用流程驱动的方式，实现快速容灾切换，容灾切换流程如图 1 所示。（1）在集群发生故障时，容器云 PaaS 平台可以自动实现容灾切换。容器云 PaaS 平台会自动进行容器应用的健康检查，在生产数据中心的集群内的应用容器运行故障时，系统自动重启或重建容器，以保证运行容器支撑业务的总能力不变。容器云PaaS平台可以根据不同的业务重要程度、对用户影响范围、故障处理时效等因素划分的的容灾等级可以针对不同的容灾等级采用不同的容灾策略。

也就是说，一个 Kubernetes 平台编配的容器应用数量是数千到数万个，要想确保这么多容器应用正常运行，且各自运行在对应的容器主机上，并对这些容器应用的生命周期进行合理管理，就需要Kubernetes自身的架构具有一定的可靠性及比较好的容错能力。分布式架构软件的运行需要多个服务器或虚拟机，一个有效的Kubernetes部署称为一个集群，集群中有多个节点，每个节点可以是物理服务器，也可以是虚拟机，每个节点上运行的操作系统是Linux，且每个节点上都运行着数十到数百个容器。

（6）成本：公有镜像仓库通常会按照拥有的仓库数量、镜像数量、存储空间、网络带宽、网络吞吐量等来计价，若企业拥有几十万、甚至几百万个镜像，则要使用几十TB的空间来存储镜像，公有镜像仓库的价格将非常昂贵。（2）安全性：公有镜像仓库中的镜像是由各个开发者分享的，这些镜像通常以功能为目的，对镜像内的依赖包、应用版本等没有任何限制。因此，公有镜像仓库带来便捷的同时也可能存在一定的风险，大型企业在使用镜像时，应该根据不同的业务需求，采取公有镜像仓库和自建私有镜像仓库相结合的模式，保证业务的稳定性的同时降低成本。

而将这些虚拟资源进行有效的整合，从而生成一个可统一管理、灵活分配调度、动态迁移、计费度量的基础服务设施资源池，并向用户提供自动化的基础设施服务，就需要其上面的laaS管理平台。基础设施资源池作为实现融合基础设施结构的关键要素，是共享服务器、存储和网络的集合，能够根据应用程序的要求更快地进行重新配置，从而能够更容易、更快捷地支持业务需求的变化。资源管理平台对基础设施服务池的资源进行统一的管理和调度，实现laaS服务的可管、可控，其核心是对每个基础资源单位的生命周期管理能力和对资源的管理调度能力。

在构建镜像时，可以指定镜像的镜像仓库、仓库及标签，也可以在构建完成后为镜像添加镜像仓库、仓库及标签，从而将同一个镜像推送到不同的镜像仓库中。镜像仓库在镜像共享中处于中心的位置，在镜像构建、持续集成、镜像部署、镜像发布中均与镜像仓库息息相关，如图1所示。当多个镜像基于同一个基础镜像构建时，这些镜像拥有相同的基础块文件，这些镜像在镜像仓库中共享这部分块文件。元数据是一个镜像的核心信息，包含镜像的镜像仓库、仓库、标签、校验码、文件层、镜像构建描述等信息。镜像仓库主要功能是进行镜像存储、镜像管理和镜像分发。

另外，可以对数据和日志进行分析，进行故障排除、深度诊断和性能调优等。实时监控核心组件（API Server、调度器、控制器、kubelet和kube-proxy等）的健康状态，用以发现用户流量和组件的CPU、内存和网络等的使用情况之间的联系。了解这些数据可以让我们知道租户之间是否相互干扰，还可以让我们知道是否需要对集群进行扩容或缩容，特别是对使用公有云的企业来说，这对控制成本非常有利。因此，通过一个全面的监控系统来解决集群中数据的收集、分析和执行功能，能够极大地提高应用程序和服务的可用性和性能。

云计算的环境中资源和应用规模变化大，部署过程所支持的软件系统形式多样，系统结构各不相同，因此对快速部署的要求较高。为了进一步提高云环境中虚拟机的部署速度，则需要考虑并行部署或者协同部署技术。并行部署是同时执行多个部署任务，将虚拟机同时部署到多个物理机上，如图1所示。 并行部署可以成倍地减少部署所需时间，但存储镜像文件所在的部署服务器的读写能力或者部署系统的有限网络带宽却制约实际的并行程度即部署速度。部署多个任务带宽速度会变慢，在这种情况下，协同部署技术可以用来进一步提高部署速度。协同部署技术的核心思想是将虚

在开发应用时，通常会把这些应用中共有的部分或者需要使用到的功能抽离出来作为基础服务，以供编写和运行从而降低应用创建和运维的复杂性。这一系列应用所要用到的基本功能即为平台层所提供的服务。当前，PaaS上运行的应用主要分为两类∶一类是Web服务类PaaS平台架构如图1所示；另一类是数据分析服务，其PaaS平台架构如图2 所示。前一类应用主要是通过浏览器访问、采用请求/响应模式进行交互的应用，称为事务处理类应用。事务处理类应用的要求主要包括快速响应、高可用性、大并发量等。后一类应用主要是对大量的数据进行分析处理，

云存储系统的安全需求，云安全服务的新模式，能够解决云存储系统普遍存在的云存储服务商主动窥探用户数据和云存储系统遭受攻击被动泄露用户数据等主要安全问题，可为用户提供安全可靠的云存储服务。安全云存储系统总体框架，共包含三部分，分别为云存储系统、云存储服务和云安全服务。

综合以上几点可以知道，全面有效的评估是企业进行应用迁移工作的必要步骤，是降低迁移风险、确保迁移安全、提升企业收益的必备措施，是制定应用迁移方案的必要前提，对迁移工作的平稳进行具有十分重要的意义。第三，确保迁移后的投资回报率也是迁移工作的关键问题，必须对迁移的关键开销、迁移过程的总成本、迁移后应用的运维成本、预期的云服务收益率等进行细致的评估。企业在制定应用迁移方案之前，应充分做好迁移前评估工作，包括迁移的可行性、安全性、成本风险，以及迁移后应用的可用性和合规性。

企业应用迁移过程包括制定迁移方案、选择云服务提供商、选择迁移内容、选择迁移策略及实施迁移方案，在企业应用迁移应用过程中还要采取必要措施，确保迁移过程顺利。

应用框架收到资源 offer 后，根据自己的调度策略决定如何使用这些资源，并将运行任务的决策发回给 Mesos 主节点，Mesos 主节点收到调度任务信息后，将任务发送给指定目标节点上的 Mesos 从节点，Mesos 从节点完成任务的执行，这称为第二级调度。云原生系统在应用管理方面提供应用编排及调度管理，可以管理由数十乃至数百个松散结合的容器式组件构成的应用，而这些组件遵照统一的发布规范，可以完成各组件相互间的协同合作，使既定的应用按照设计运作，按顺序在网络级别进行组织，能够按照计划运行。

提供应用容器框架，可以对应用提供全生命周期的托管。服务治理分布式应用服务平台提供管理控制台对每个应用发布和订阅的服务进行管理，提供精细化的路由规则控制，通过接口级、方法级，甚至参数值域级的服务路由控制，引导服务请求流量；提供必备的服务治理能力，包括服务自动注册与发现、服务鉴权、限流降级、服务分组、服务权重、服务市场等一系列服务治理能力。企业级分布式应用服务是围绕应用和微服务的PaaS平台，为企业提供高可用与分布式的支撑平台，提供分布式服务框架、服务治理、统一配置管理、分布式链路追踪、高可用及数据化运营等。.

应用的功能常常会有不同的扩展需求，某些功能可能可以通过增加小规格的实例数量实现横向扩容，而另一些功能可能需要大量的内存，本身也很难使用横向扩容。通过把这些功能拆分成独立的服务，开发人员就可以把服务放在最合适的环境中运行，以满足每个服务的扩容和资源使用的需求。通过把应用按功能拆分成小的、松耦合的服务，可以更轻松地更改单个服务而避免对整个应用程序的影响。通过把应用拆分成更小的服务，小的敏捷开发团队可以聚焦在更小的功能点上，并且快速地行动起来。在单体应用中，一个库或者模块的故障可能会导致整个应用的故障。

在微服务场景下，每个服务可以独立采用自己的技术方案或技术栈，每个微服务应用独立部署，服务之间进程隔离，每个服务都有独立的数据库，一个服务实例的失效不会导致大规模的故障。持续集成、持续部署、持续交付是自动化驱动的重要原则，以保证需求、开发、迭代和快递的部署到生产环境中，随着应用服务的增多，运维工作增加，成本增加，这就要求我们在进行服务划分的时候，优先构自动化的环境和工具，简化开发、测试、部署、运维的流程，使用自动化工具完成以上步骤。松耦合原则包含：实现的松耦合，是基本的松耦合，可以自由切换到其他服务；

JobTracker可以与负责管理数据存储的主控节点NameNode 设置在物理的主控服务器上，也可以设置在其他服务器上，如果遇到规模大、负载过重的情况下最好是分开设置。从软件系统角度看，分布式存储、并行计算是Hadoop系统的两个部分，分布式存储中Hadoop 系统提供一个大规模可扩展的分布式数据存储功能，是在本地文件系统的每个从节点基础上，实现一个逻辑上整体化的分布式文件系统HDFS，负责控制和管理整个分布式文件系统的主控节点称为NameNode，而每个具体负责数据存储的从节点称为 DataNode。.

后端开发主导，对产品经理的需求文档中的功能，将接口数据输出给前端工程师，对外提供服务的数据存储在ADS 层，后端开发工程师一般是基于ADS层的数据将数据封装成对外服务的接口，后端开发工程师一方面要和数据开发工程师沟通好ADS层数据的存储结构，另一方面需要和产品经理沟通产品的功能、性能方面的问题，以便为使用者提供更好的用户体验。模型一般分为5层，分别为ODS层（操作数据层）、DIM层（维度数据层）、DWD层（明细数据层）、DWS层（汇总数据层）、ADS层（应用数据层），这是业界对于数据分层的常用的模型。...

分布式系统还内置了对数据存储和处理的优化设置，可以选择多种数据存储形式，优化设置不仅可用于原始数据的获取，还可以应用在处理数据时产生的中间值，以及数据处理后的结果数据，主要注意：文件格式、数据压缩。这类元数据可以充分加快数据分析性能，优化执行程序。（一）和逻辑数据集相关的元数据∶这类元数据记录数据集存储的位置信息、和数据集关联的模式信息、数据集的分区和排序信息，还有数据集的格式。（四）和数据获取、转换有关的元数据∶这类元数据记录数据使用者产生的数据集、数据集的来源、产生数据集的时间、数据集的规模等信息。..

不仅如此，ApplicationMaster的加入使得用户可以将自己的编程模型运行于Hadoop 集群上，加强了系统的兼容性和可用性，HDFS和MapReduce是Hadoop生态系统中的核心组件，提供基本的大数据存储和处理能力，以上述两个核心组件为基础，Hadoop 社区陆续开发出一系列子系统完成其他大数据管理需求，这些子系统和HDFS、MapReduce一起共同构成了Hadoop生态系统。Hadoop 生态系统是开源社区对大数据挑战的解决方案，为大数据管理系统的后续发展奠定了良好的基础。...

通常将大数据应用开发分为五个步骤：获取、存储、处理、访问以及编制，获取是指获取一些辅助数据，例如来自CRM、生产数据（ODS）的数据，并将其加载入分布式系统（如Hadoop）为下一环节处理做准备。清洗完数据后，还要将数据进行统一ID编号，在处理数据前需要对点击数据做进一步的处理和分析，包括对数据以每天或每小时为单位进行汇总，这能更快地进行之后的查询操作。由于每一个数据处理步骤的数据集都有不同的目的，选择数据存储的时候要确保数据的形式及模型和数据相匹配。原始数据的存储是将文本格式的数据存储到分布式系统中。..

云计算与大数据密切相关，大数据是计算密集型操作的对象，需要消耗巨大的存储空间，云计算的主要目标是在集中管理下使用巨大的计算和存储资源，用微粒度计算能力提供大数据应用，云计算的发展为大数据的存储和处理提供了解决方案，大数据的出现也加速了云计算的发展，基于云计算的分布式存储技术可以有效地管理大数据，借助云计算的并行计算能力可以提高大数据采集和分析的效率。数据的可靠性和完整性决定了数据的质量，需要对数据进行甄别，对这些质量不一的数据进行统一的加工处理，并对数据的真实性加以判别。...

主节点即中央控制节点是K8s 集群的管理节点，管理集群当中数据的接口、状态监测和回滚、状态更新、调度等功能，kubectl是K8s的命令行工具集，用于通过命令行与API server进行交互，而对K8s进行操作，实现在集群中进行各种资源的管理控制等操作，通过节点控制器来与工作节点交互。（3）kube-proxy代理对抽象的应用地址的访问，服务提供了一种访问一群pod的途径， kube-proxy负责为服务提供集群内部的服务发现和应用的负载均衡（通常利用iptables规则），实现服务到pod的路由和转发。.

DevOps 是一个持续改善软件产品的过程，它通过极短的发布周期、全面自动化的集成和交付流水线，以及团队间的紧密协作来不断改善产品。这并非意味着版本总是可以这么快地发布，适当的质量保障（QA，Quality Assurance）需要投入时间，而 DevOps 提供了在必要时能快速行动的能力，展示了持续集成、持续交付及基础设施即服务这些技术如何被整合在一起以实现快速的发布周期。上图的流水线的关键部分是，从开发人员提交补丁到生产环境中的服务部署这些自动化步骤，最终以完全自动化的方式串联成的一个链条。...

在云原生中，laC 和 GitOps 是非常好的解决方法，每个应用有一个 laC 仓库，保存应用镜像及所有相关的配置信息，GitOps 自动检测 IaC 的变化，自动翻译为符合 0AM 规范的配置，然后推到对应的环境上。● 运维侧∶需要结合云原生的自动化运维体系，在问题自动定位、容灾切流、自动恢复、热修复、APM，并结合传统的 Metrics、Tracing、Logging 的基础之上，构建成熟的故障发现、定位、处理的稳定性体系。在企业应用上云后，使用的资源种类越来越多，操作和维护成本也变得越来越高。...

以Docker为代表的容器技术成熟标志是带动一个生态系统的发展，如下图，可以看出，容器技术的生态系统自下而上分别覆盖了IaaS层和PaaS层所涉及的各类问题，包括资源调度、编排、部署、监控、配置管理、存储网络管理、安全、容器化应用支撑平台等。容器庞大生态体系，在生产使用中面对更复杂的需求，例如众多跨主机的容器协同工作，需要支持各种类型的工作负载，多人协作的持续集成、持续交付平台，生产环境中容器相关的网络、存储、集群、高可用等问题层出穷，所以，从容器到容器云的进化应运而生。...

这时容器进程就会觉得自己是各自PIDnamespace里的第1号进程，只能看到各自mountnamespace里挂载的目录和文件，只能访问各自networknamespace里的网络设备，就像运行在一个个隔离的「容器」里面，但其实这只是一个被逻辑构建出来的「虚拟沙箱」。然后在这些虚拟的硬件上安装一个新的操作系统GuestOS，这样用户的应用就可以运行在这台虚拟机中，该应用只能看到GuestOS的文件和目录，以及这台虚拟机里的虚拟设备，从而实现了将不同的应用进程相互隔离。...

在前文中我们有提到Docker镜像技术，应用的分发、部署与管理变得非常便捷。那么，Docker的网络功能又如何满足各种场景的需求？今天我们就来了解Docker的网络架构。Docker网络架构在1.7版本中的代表是libnetwork，也就是Docker的网络库使得网络代码被抽离出来。在1.9版本中出现了docker network，支持子命令和跨主机网络，这允许用户可以根据他们应用的拓扑结构创建虚拟网络并将容器接入其所对应的网络，接下来，网络模式的驱动逐渐被抽象变成了统一接口。容器网络模型CNM（Conta

在昨天的文章里面我们讲了Docker的镜像是一系列的只读层组成的。在启动一个容器的时候，Docker 加载镜像的所有只读层，并在最上层加入一个读写层。这使得Docker可以提高镜像构建、存储和分发的效率，节省了时间和存储空间，同样也存在一些问题：文件在宿主机上形式复杂，不能快速的访问容器中的文件，造成多个容器之间的数据无法共享，如果进行删除容器造作，容器的数据会丢失。数据卷volume机制就可以很好的解决这些问题，究竟什么是Docker的数据卷volume呢？数据卷volume容器中的特殊目录或者特定文件，

我们知道使用libcontainer可以迅速构建应用的运行环境。容器迁移时候需要把运行环境进行全部打包，这个时候libcontainer就出现短板，因此Docke镜像技术是Docker管理文件系统和运行环境一个完善。Docker镜像的只读形式，在启动Docker容器中，文件系统结构和内容都包含在其中，Docker镜像是启动Docker容器的基础。Docker镜像的文件内容和配置文件组成了Docker容器的静态文件系统运行环境—— rootfs。简单的理解为：Docker镜像是Docker 容器的静态视角，D

容器安全是Docker社区极为关注的一个问题，Docker是否能提供安全的环境，尤其是在公有云环境中，这直接关系到Docker是否可以大规模用于生产环境。容器安全的安全机制有哪些？包括Docker daemon在以TCP形式提供服务的同时使用传输层安全协议在构建使用镜像时会验证镜像的签名证书;通过cgroups及namespaces 来对容器进行资源限制和隔离;提供自定义容器能力（ capability）的接口;通过定义seccomp profile 限制容器内进程系统调用的范围等。这将在很大程度上提高Do

Serverless架构是云的自然延伸，我们回顾一下云计算IaaS和PaaS的发展，2006年AWS推出EC2（Elastic Compute Cloud），作为第一代IaaS（Infrastructure as a Service），用户可以通过AWS快速的申请到计算资源，并在上面部署自己的互联网服务。IaaS从本质上讲是服务器租赁并提供基础设施外包服务。PaaS（Platform as a Service）是构建在IaaS之上的一种平台服务，提供操作系统安装、监控和服务发现等功能，用户只需要部署自己的应

服务网格技术Istio作为云原生（Cloud Native）应用的体系结构模式，解决了开发人员和运营商在微服务架构在网络和管理上面临的挑战。什么是服务网格技术Istio？Istio在希腊语中的意思是“启航”，而Kubernetes在希腊语中可以翻译为“舵手”或“驾驶员”。所以从一开始lstio就期望与Kubernetes很好地配合，高效地运行分布式微服务架构，并提供安全、连接和监控微服务的统一方法。云原生容器技术（linuxContainer）和微服务（Microservice）应用的出现，推动了服务网格发

云原生是什么？云原生关键技术有哪些？

什么是容器技术？容器技术的特点以及应用场景有哪些？