容器

Hello World

深耕批发，没有比中国更好的中央，也没有比当初更好的工夫。1996 年，国内批发巨头沃尔玛进入中国，在深圳开设了第一家山姆会员商店。25 年后的明天，山姆会员商店领有 数百万付费会员，成为 国内遥遥领先的会员制商店。 当位于深圳的山姆会员商店间断 10 余年成为沃尔玛寰球销售第一的门店，沃尔玛又一次亮出了优良的业绩。为什么可能在极度竞争的中国批发市场放弃强劲增长？2020 年寰球批发行业调研报告作出了如下总结：在沃尔玛，各种各样的先进技术被广泛应用以进步工作效率。沃尔玛的管理者认为，先进的科技在批发市场将有助于沃尔玛博得竞争 。 01. 「顾客至上，服务第一」腾讯云 Serverless 解决方案顾客至上是批发行业的服务主旨。然而消费者对购物体验的要求越来越高，业务迭代速度越来越快。山姆会员商店要放弃前瞻性，线上销售渠道必须疾速迭代翻新，一直为消费者发明新的购物体验。 难点1 ：利用公布频率高山姆会员商店业务迭代快、利用公布频率高，根本放弃在一周一迭代。难点2：保障用户最佳体验版本升级的根本要求是：对用户无感知，在降级过程中利用的无损公布。难点3: 资源耗费大批发行业线上流量微小，一个利用可能须要上千台服务器，采纳蓝绿部署时，如果在线上公布，须要再备份一千台服务器，对资源耗费造成极大的损失。 （山姆会员商店蓝绿公布架构图） 典型的开发流程从开发测试到集成测试，到预发测试，再到公布上线，每个研发阶段都有对应的环境做撑持，而每个环境都会耗费资源和老本，来放弃服务在线。传统的版本灰度公布模式面临环境多、资源耗费多、老本低等窘境。 （环境多、资源耗费大） 腾讯云山姆会员商店我的项目负责人李逸期在智慧批发深耕多年，从 0 到 1 搭建了山姆会员商店 APP 的技术架构。秉承沃尔玛公司用科技助力市场的策略，李逸期对以赋能业务为指标的技术创新，放弃着极致化的谋求。多种计划比照后，山姆会员商店抉择了腾讯云云函数 SCF ( Serverless Cloud Function ) 默认别名灰度公布策略。 云函数 SCF 默认别名灰度公布默认别名是配置云函数的 $default（默认流量）别名，别名中固定有 2 个云函数版本：一个为 $latest 版本，一个为最初一次函数公布的版本。部署时配置的 traffic 参数为 $latest 版本流量占比，默认另一部分流量切到以后云函数最初一次公布的版本。每次上线一个新性能，执行 sls deploy 会部署到 $latest 版本上。版本公布时先切局部流量在 $latest 版本上进行察看，稳固后逐渐将流量切到 $latest 版本。当流量切到 100% 时，固化以后版本，并将流量全副切到固化后的版本。 （云函数默认别名灰度公布图） 劣势 1 ：危险管制保障用户体验首先，管制变更的危险，一旦发现新版本有异样，随时能够调整流量比例进行回滚；其次，客户端和云函数一起进行灰度，即便须要做一些破坏性变更，例如协定变更时，也不必放心线上版本是否兼容新的协定。劣势 2 ：疾速验证适应高频迭代Serverless 模式下，环境隔离、可间接公布，晋升高频部署时的研发效率，适宜做产品个性的疾速验证。劣势 3 ：弹性扩缩容节约老本Serverless 在没有访问量时主动缩容，能够极大节约部署多环境的老本。 当遇到更加简单的版本公布策略时，云函数自定义别名能够提供更灵便的版本切换形式。自定义别名的配置形式绝对于默认别名更简单，实用于对灰度公布能力要求较高的业务场景。 （云函数自定义别名灰度公布图） 02.批发电商场景中 Serverless 利用1. 电商大促等波峰波谷型业务每年双 11、618 等电商大促期间，批发行业线上渠道面临历史级别的流量挑战，中大型电商平台的峰值调用量可达上千万/分钟，面临高于日常 10-20 倍的流量压力。日常经营流动中，例如精品秒杀、限时抢购等，电商平台也同样面临大流量高并发、波峰波谷用户流量显著分化的典型场景。云函数 SCF 提供弹性、可扩大的基础设施和护航服务，帮忙电商客户把握业务增长的时机，从容应对挑战。 ...

容器技术扭转了利用交付、运行的形式，简直各种Linux环境下的应用程序都能够应用容器来运行。但是否能在容器环境里运行数据库利用，以及数据库利用是否适宜在容器里运行，始终都是大家很关注的问题，明天咱们就来深入分析一下容器环境运行MySQL数据库的事。 在容器中运行数据库，能帮忙用户进步服务器利用效率，升高基础架构老本，更疾速地部署、更便捷地治理数据库服务。 依据云监控供应商Datadog的调查报告， Postgres、MongoDB和MySQL等数据库技术都位于容器上运行的十大技术之中——并且使用量还在增长。 MySQL容器化须要容器存储的无力反对数据库实际上由两大组件组成：读取、写入和查问数据的利用，以及数据存储，咱们通常称之为数据卷。MySQL等数据库利用所需的计算资源齐全能够通过容器技术提供，是否能流畅运行MySQL数据库的关键在于容器存储计划。国内大多数用户在抉择容器存储时，通常有以下几种计划： 新版本的Kubernetes能够反对块设施挂载至容器外部（该块设施能够来自服务器的物理磁盘，也能够来自传统的SAN阵列）通过Ceph提供的CSI插件应用CephRBD或者CephFS应用YRCloudFile提供的容器存储大多数客户对容器存储的以下几点尤为关注：数据可靠性 是否能通过容器编排平台疾速实现存储资源的生命周期治理（创立、扩容、删除和回收等）MySQL在容器化环境中的容灾备份MySQL容器故障后，在新节点重新启动，其数据是否能快速访问MySQL应用容器存储的理论性能如何，是否能满足业务需要对于用户关注的上述个性，咱们在之前的文章中都有过介绍，在当前的文章里也会进一步形容。本文针对用户最关注的，MySQL基于不同存储的理论性能进行了理论测试和比照。 MySQL存储引擎和数据写入策略在介绍理论测试性能之前，有必要介绍一下MySQL数据库的存储引擎，以及相干的写入策略，这对于数据库的理论使用性能有十分要害的影响。 MySQL存储引擎 MySQL数据库提供插件式的存储引擎，这个存储引擎提供了一系列规范的治理和数据读写服务的反对，不同的存储引擎有不同的特点，存储引擎对于业务开发人员而言是通明的。其中，InnoDB是驰名的第三方存储引擎，后被Oracle收买，是MySQL数据库OLTP（Online Transaction Processing，在线事务处理）利用中应用最广的存储引擎，也是5.5.8版本后，MySQL默认的存储引擎，以下的测试就基于InnoDB存储引擎进行。 InnoDB刷数据策略 InnoDB中有一项设置——innodb_flush_method，这项设置负责管制InnoDB刷数据时所应用的零碎调用。所谓刷数据，行将缓存在内存中或长期磁盘存储区域中的数据写入特定的日志及数据文件（log，如ib_logfile和数据库data file），实现长久化。 刷数据动作可能是因为内存区域已满并且零碎须要开释一些空间而触发，或是因为事务实现更改的commit操作而触发，或者由须要终结所有未实现工作的敞开操作而触发。 innodb_flush_method的值对应着不同的零碎调用，从而会触发不同的零碎行为，常常应用的值包含： fsync：InnoDB应用fsync()零碎调用将MySQL的数据和日志文件都刷到长久化存储中，fsync是InnoDB的模式设置。O_DIRECT：InnoDB应用O_DIRECT标识关上MySQL的数据文件，意味着MySQL数据将绕过pagecache，间接写入磁盘，并应用fsync()零碎调用将MySQL数据和日志文件的元数据信息更新刷入磁盘。O_DIRECT_NO_FSYNC：只应用O_DIRECT形式，绕过pagecache，将数据间接写入磁盘，并在写操作时跳过fsync()更新日志的元数据信息。在8.0.14版本之后， MySQL会在创立文件、减少文件长度以及敞开文件时主动调用fsync()来更新MySQL文件在文件系统中的元数据信息。YRCloudFile能够反对这种刷数据形式，即能够很好地确保每个数据都间接落盘，同时缩小频繁调用fsync带来的开销，极大晋升性能。 sysbench性能比照测试 在上面进行的性能比照的测试中，咱们在MySQL容器中应用了以下几种存储计划进行比照： 将本地物理SSD盘挂载到MySQL容器中将基于RoCE（RDMA over Converged Ethernet）的YRCloudFile集群中的PV挂载到MySQL容器中将基于TCP的YRCloudFile集群中的PV挂载到MySQL容器中将CephRDB的PV挂载到MySQL容器中将CephFS的PV挂载到容器中除物理SSD盘外，YRCloudFile和Ceph集群都采纳以下四台雷同的物理服务器进行搭建： CPU：Intel 4112 * 2内存：64GB系统盘：240GB * 2元数据盘：960GB SSD * 2（CephRBD时不须要元数据盘）缓存盘：960GB SSD * 2数据盘：4TB SATA * 2管理网络：1Gb * 2存储网络：10Gb * 2MySQL版本为8.0.14，应用InnoDB作为存储引擎，innodb_flush_method设为O_DIRECT_NO_FSYNC ；Ceph版本为mimic，Ceph基于filestore；sysbench版本为1.0.17，基于50个表，每个表中蕴含100万条数据的数据库进行oltp_write_only和oltp_read_write测试。 测试后果如下： 从测试后果看： 间接应用物理SSD时，因为是进行本地SSD读写，延时很低；且MySQL利用为了确保其操作的程序性，次要是采纳无限线程低并发进行程序追加写，延时性能决定了单个MySQL的整体性能，因而无论YRCloudFile还是Ceph存储集群对单个MySQL实例而言，会受到延时影响，性能不如本地SSD盘。另一方面，咱们看到基于RoCE的YRCloudFile的性能曾经靠近本地SSD盘，基于TCP的YRCloudFile集群所提供的性能略低于RoCE的性能。基于RoCE的YRCloudFile性能高于基于TCP的YRCloudFile性能，是CephRBD或CephFS性能的将近一倍。这是因为：1）YRCloudFile集群的元数据保留在本地SSD，绝对于CephFS的元数据保留在RADOS中而言，其元数据读延时显著低于CephFS；2）基于RDMA的YRCloudFile绕过了零碎内核，间接拜访集群中的磁盘数据，进一步升高了提早。兴许有读者会问，从单个MySQL实例的测试性能看，YRCloudFile分布式存储系统的劣势如何体现呢？通过应用YRCloudFile，能够充分发挥集群中所有磁盘的性能，使整个集群反对更多的MySQL实例，而单块SSD盘的性能能够撑持的MySQL实例就无限得多了。此外，YRCloudFile也正在通过硬件offload，NVMe优化等形式，进一步缩短集群IO的延时，使集群IO的延时尽可能靠近本地SSD的延时，从而使单MySQL实例的性能更加靠近应用本地SSD运行MySQL的性能。 在这篇文章中，咱们介绍了如何通过设置MySQL InnoDB的innodb_flush_method参数，应用YRCloudFile获得最佳的MySQL运行性能，并比照了在等同环境下，应用SSD、CephRBD、CephFS所取得的性能。在后续文章里，咱们还会分享更多基于YRCloudFile运行各种中间件利用的最佳实际，以及相干的技术细节。

Operator Framework是由CoreOS开发，后被RedHat收买的一个开源工具包，它能够无效的、自动化的和可扩大的形式治理 Kubernetes原生应用程序。该框架下蕴含Operator SDK，可帮助开发人员利用本人的专业知识来疏导和构建Operator，而无需理解 Kubernetes API复杂性。明天咱们就学习它，用于创立一个基于Ansible的Operator利用（之前小白在《Loki Operator扼要教程》中也简略聊到过），它能够利用现有 Ansible playbook和模块来部署和治理Kubernetes资源作为对立应用程序的生命周期，而无需编写任何Go代码。 装置Homebrew装置 (MacOS)如果你应用的是Homebrew，你能够用以下命令装置SDK CLI工具。 $ brew install operator-sdk二进制装置$ export ARCH=$(case $(uname -m) in x86_64) echo -n amd64 ;; aarch64) echo -n arm64 ;; *) echo -n $(uname -m) ;; esac)$ export OS=$(uname | awk '{print tolower($0)}')$ export OPERATOR_SDK_DL_URL=https://github.com/operator-framework/operator-sdk/releases/download/v1.10.0#下载operator-sdk$ curl -LO ${OPERATOR_SDK_DL_URL}/operator-sdk_${OS}_${ARCH}$ chmod +x operator-sdk_${OS}_${ARCH} && sudo mv operator-sdk_${OS}_${ARCH} /usr/local/bin/operator-sdk编译装置$ git clone https://github.com/operator-framework/operator-sdk$ cd operator-sdk$ git checkout master$ make install初始化1. 初始化我的项目 应用operator-sdk命令来疾速初始化这个我的项目的空间。 ...

OpenStack 与 Kubernetes 的共存OpenStack是面向资源层的IaaS云平台管理软件，能够帮忙用户构建和治理公有云和私有云。 目前，OpenStack依然是开源IaaS畛域的支流平台，有超过80%的中国企业正在应用OpenStack。然而随着K8s的日益遍及，有很多OpenStack用户开始关注云原生。有一些用户也尝试将工作负载从Openstack迁徙到云原生环境中。 OpenStack + Kubernetes 是目前绝对风行的云利用解决方案栈。对于那些部署了OpenStack，同时又在尝试应用Kubernetes的用户，为了帮忙他们更好地同时治理OpenStack和K8s，咱们倡议用户以K8s作为底座，OpenStack由K8s对立部署和治理，以及对立编排。各种租户子网（跨K8s和OpenStack）可能动静定义和连贯/断开，用以反对动态变化的租户需要。 在这种场景下，OpenStack VMs 和 Kubernetes Pods 的网络互通成为了一个亟待解决的问题。同时, OpenStack 所提供的网络隔离性能也应该在与 Kubernetes 连贯的过程中失效: 属于一个 VPC 的 VMs 理所应当地不能拜访另外一个 VPC 的 VMs 以及 Pods/Svcs。 面对这样的需要，灵雀云Kube-OVN团队工程师与Intel的OpenStack专家独特拟定了相应的计划。在计划里，Kube-OVN 须要提供的基本功能如下:  提供 Kubernetes Pods 和 OpenStack VMs 之间的路由替换, 实现网络互通； 为 Kubernetes 提供和 OpenStack 雷同的网络隔离标准, 保障 VPC 之间的网络隔离。目前有两类实现计划, 一种是基于 ovn-ic 的计划, 以松耦合的形式提供路由替换和网络隔离；另一种是基于同一个 ovn 底座的计划, 这是一种紧耦合的计划。计划前置要求： Kube-OVN降级到 V 1.7版本以上； OpenStack usurri +. 必须基于 ovn 部署。计划一：基于 ovn-ic: 组网形式一: ovn-ic 是 ovn 提供的一个 inter-connection 工具, 用于在不同的 ovn 控制器之间替换路由，可靠性和性能由 ovn 保障。如图所示，ovn-ic 作为中间人, 相互交换 OpenStack OVN 和 Kubernetes Kube-OVN 的路由信息。这样设计的益处是部署简略, OpenStack 和 Kubernetes 绝对独立，相互之间不会影响。同时也有一些弊病：OpenStack 和 Kubernetes 别离部署, 资源利用率独立计算；而且OpenStack 的网络隔离个性无奈展示。 ...

摘要：Docker为什么火，靠的就是Docker镜像。他打包了应用程序的所有依赖，彻底解决了环境的一致性问题，从新定义了软件的交付形式，进步了生产效率。本文分享自华为云社区《意识容器，咱们从它的历史开始聊起》，作者：技术火炬手。 对于容器的历史、倒退以及技术实质，在互联网上曾经有十分多的文章了。这里旨在联合本身的工作教训和了解，通过一系列的文章，讲清楚这项技术。 容器的历史和倒退1、前世讲到容器，就不得不提LXC（Linux Container），他是Docker的前生，或者说Docker是LXC的使用者。残缺的LXC能力在2008年合入Linux主线，所以容器的概念在2008年就根本定型了，并不是前面Docker造出来的。对于LXC的介绍很多，大体都会说“LXC是Linux内核提供的容器技术，能提供轻量级的虚拟化能力，能隔离过程和资源”，但总结起来，无外乎就两大知识点Cgroups（Linux Control Group）和Linux Namespace。搞清楚他俩，容器技术就根本把握了。 Cgroups：重点在“限度”。限度资源的应用，包含CPU、内存、磁盘的应用，体现出对资源的治理能力。Namespace：重点在“隔离”。隔离过程看到的Linux视图。说大白话就是，容器和容器之间不要相互影响，容器和宿主机之间不要相互影响。2、少年期起步艰巨2009年，Cloud Foundry基于LXC实现了对容器的操作，该我的项目取名为Warden。2010年，dotCloud公司同样基于LXC技术，应用Go语言实现了一款容器引擎，也就是当初的Docker。那时，dotCloud公司还是个小公司，出世低微的Docker没什么热度，活得相当艰巨。 3、 成长为巨无霸2013年，dotCloud公司决定将Docker开源。开源后，我的项目忽然就火了。从大的说，火的起因就是Docker的这句口号“Build once，Run AnyWhere”。呵呵，是不是似曾相识？对的，和Java的Write Once，Run AnyWhere一个情理。对于一个程序员来说，程序写完后打包成镜像就能够随处部署和运行，开发、测试和生产环境完全一致，这是如许大一个引诱。程序员再也不必去定位因环境差别导致的各种坑爹问题。 Docker开源我的项目的异样火爆，间接驱动dotCloud公司在2013年更名为Docker公司。Docker也疾速成长，干掉了CoreOS公司的rkt容器和Google的lmctfy容器，间接变成了容器的事实标准。也就有了起初人一提到容器就认为是Docker。 总结起来，Docker为什么火，靠的就是Docker镜像。他打包了应用程序的所有依赖，彻底解决了环境的一致性问题，从新定义了软件的交付形式，进步了生产效率。 4、 被列强鲸吞Docker在容器畛域疾速成长，野心天然也变大了。2014年推出了容器云产品Swarm（K8s的同类产品），想扩张事业幅员。同时Docker在开源社区领有相对话语权，相当强势。这种走本人的路，让他人无路可走的行为，让容器畛域的其余大厂玩家很是不爽，为了不让Docker一家独大，决定要干他。 2015年6月，在Google、Redhat等大厂的“运作”下，Linux基金会成立了OCI（Open Container Initiative）组织，旨在围绕容器格局和运行时制订一个凋谢的工业化规范，也就是咱们常说的OCI规范。同时，Docker公司将Libcontainer模块捐给CNCF社区，作为OCI规范的实现，这就是当初的RunC我的项目。说白了，就是当初这块儿有个规范了，大家一起玩儿，不被某个特定我的项目的绑定。 讲到Docker，就得说说Google家的Kubernetes，他作为容器云平台的事实标准，现在已被宽泛应用，俨然已成为大厂标配。Kubernetes原生反对Docker，让Docker的市场占有率始终居高不下。如图是2019年容器运行时的市场占有率。 但在2020年，Kubernetes忽然发表在1.20版本当前，也就是2021年当前，不再反对Docker作为默认的容器运行时，将在代码骨干中去除dockershim。 如图所示，K8s本身定义了规范的容器运行时接口CRI（Container Runtime Interface），目标是能对接任何实现了CRI接口的容器运行时。在初期，Docker是容器运行时不容置疑的王者，K8s便内置了对Docker的反对，通过dockershim来实现规范CRI接口到Docker接口的适配，以此取得更多的用户。随着开源的容器运行时Containerd（实现了CRI接口，同样由Docker捐给CNCF）的成熟，K8s不再保护dockershim，仅负责保护规范的CRI，解除与某特定容器运行时的绑定。当然，也不是K8s不反对Docker了，只是dockershim谁保护的问题。 随着K8s态度的变动，预计将会有越来越多的开发者抉择间接与开源的Containerd对接，Docker公司和Docker开源我的项目（现已改名为moby）将来将会产生什么样的变动，谁也说不好。 讲到这里，不晓得大家有没有留神到，Docker公司其实是募捐了Containerd和runC。这俩到底是啥货色。简略的说，runC是OCI规范的实现，也叫OCI运行时，是真正负责操作容器的。Containerd对外提供接口，治理、管制着runC。所以下面的图，真正应该长这样。 Docker公司是一个典型的小公司因一个爆款我的项目火起来的案例，不论是技术层面、公司经营层面以及如何跟大厂缠斗，不论是好的方面还是坏的方面，都值得咱们去学习和理解其背地的故事。 什么是容器按国际惯例，在介绍一个新概念的时候，都得从大家相熟的货色说起。幸好容器这个概念还算好了解，喝水的杯子，洗脚的桶，养鱼的缸都是容器。容器技术外面的“容器”也是相似概念，只是装的货色不同罢了，他装的是应用软件自身以及软件运行起来须要的依赖。用鱼缸来类比，鱼缸这个容器外面装的应用软件就是鱼，装的依赖就是鱼食和水。这样大家就能了解docker的logo了。大海就是宿主机，docker就是那条鲸鱼，鲸鱼背上的集装箱就是容器，咱们的应用程序就装在集装箱外面。 在讲容器的时候肯定绕不开容器镜像，这里先简略的把容器镜像了解为是一个压缩包。压缩包里蕴含利用的可执行程序以及程序依赖的文件（例如：配置文件和须要调用的动静库等），接下来通过实际操作来看看容器到底是个啥。 一、宿主机视角看容器：1、首先，咱们启动容器。 docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done"这是Docker的规范命令。意思是应用euleros_arm:2.0SP8SPC306镜像（镜像名:版本号）创立一个新的名字为"aimar-1-container"的容器，并在容器中执行shell命令：每秒打印一次“aimar-1-container”。 参数阐明：-d：应用后盾运行模式启动容器，并返回容器ID。--name：为容器指定一个名字。 docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done"207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c从输入中，咱们看到一串长字符207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c。他就是容器ID，能惟一标识一个容器。当然在应用的时候，不须要应用全id，间接应用缩写id即可（全id的前几位）。例如下图中，通过docker ps查问到的容器id为207b7c0cbd81 aimar-1-container容器启动胜利后，咱们在宿主机上应用ps进行查看。这时能够发现方才启动的容器就是个过程，PID为12280。 咱们尝试着再启动2个容器，并再次在宿主机进行查看，你会发现又新增了2个过程，PID别离为20049和21097。 所以，咱们能够失去一个论断。从宿主机的视角看，容器就是过程。 2、接下来，咱们进入这个容器。 ...

随着企业上云步调的放慢，以容器、微服务及动静编排为代表的云原生技术为企业的业务翻新带来了弱小的推动力。然而，在容器应用环境中，因为共享操作系统内核，容器仅为运行在宿主机上的若干过程，其安全性特地是隔离性与传统虚拟机相比存在肯定的差距。在利用容器和K8S过程中，近几年陆续爆出大量的基于容器平台的安全隐患，如何保障容器平安，已成为企业最关怀的问题。 7月9日，腾讯平安正式公布腾讯云容器平安服务产品TCSS（Tencent Container Security Service），腾讯云容器平安服务为企业提供容器资产治理、镜像平安、运行时入侵检测等平安服务，保障容器从镜像生成、存储到运行时的全生命周期，帮忙企业构建容器平安防护体系。 （TCSS帮忙打造原生牢靠的容器利用平安体系） 01云原生时代容器现状容器是云原生的基石之一，作为一种计算单元，在云原生环境中间接运行于主机内核之上，具备系统资源占用少、可大规模自动化部署以及弹性扩容能力强等劣势。另外容器化使开发过程中疾速集成和疾速部署成为可能，极大地晋升了利用开发和程序运行的效率。 为此，越来越多的企业抉择在生产环境中应用容器架构，依据《中国云原生用户调查报告2020》（下文简称《报告》）显示，曾经有6成以上的用户在生产环境中使用了容器技术，其中43％的用户曾经将容器技术利用到非核心生产环境。 然而因为本身隔离性差，存活工夫短等特色，容器也成为易受网络攻击的对象。Tripwire 2019年对311位IT平安业余人员进行了调研，发现60%的组织都遭逢过容器安全事故，《报告》数据也显示63％的用户认为容器平安是紧迫需要。 02常见的容器平安危险场景逃逸危险 容器共享宿主机操作系统内核，隔离性方面存在缺点，将会造成容器逃逸。容器逃逸也是容器特有的平安问题，会间接影响到底层基础设施的安全性，次要分为三类：第一类是配置不当引起的逃逸，比方容许挂载敏感目录；第二类是容器自身设计的BUG，比方runC容器逃逸破绽；第三类是内核破绽引起的逃逸，比方dirtycow。 镜像危险 镜像是容器的动态表现形式，容器运行时的平安取决于镜像的平安。局部官网路径或者开源社区下载的容器镜像可能会蕴含各类第三方库文件和零碎利用，而这些库和利用可能存在破绽、木马或者后门，因此存在较大的平安危险。 同时，容器镜像在存储和应用的过程中，可能被篡改，如被植入恶意程序或被批改。一旦应用被歹意篡改的镜像创立容器后，将会影响容器和应用程序的平安。 运行环境危险 作为容器的载体和编排管理软件，主机和容器编排平台等运行环境也是容器平安的重要因素之一。若宿主机存在破绽或配置不标准、容器软件的相干环境配置不标准或编排利用配置不标准，都将影响整个容器环境的安全性。 例如2018年特斯拉在亚马逊上的K8s集群被入侵，起因为集群控制台没有设置密码保护，攻击者入侵后在一个pod中找到AWS的拜访凭证，并凭借这些凭证信息获取到特斯拉敏感信息。 03腾讯TCSS解决方案护航云容器平安为了解决容器平安问题，腾讯平安联合二十多年的网络安全实践经验，推出了笼罩容器资产治理、镜像平安及运行时入侵检测等性能的腾讯云容器平安服务产品（TCSS），通过资产治理、镜像平安、运行时平安、平安基线四大外围能力来保障容器的全生命周期平安，帮忙企业疾速构建容器平安防护体系。 资产治理 TCSS容器平安服务提供自动化、细粒度资产盘点性能，可疾速盘点出运行环境中的容器、镜像、镜像仓库、主机等要害资产信息，帮忙企业实现资产可视化。目前，TCSS资产治理模块已反对9种资产信息统计。 （外围产品性能：资产治理） 镜像平安 TCSS容器平安服务针对镜像、镜像仓库提供“一键检测“或“定时扫描”，反对安全漏洞、木马病毒、敏感信息等多维度平安扫描。在敏感信息方面，可检测包含root启动、代码透露、认证信息透露等敏感信息透露事件，避免敏感信息透露。 （外围产品性能：镜像平安） 由腾讯自主研发的容器平安杀毒引擎和破绽引擎，基于腾讯弱小的平安数据根底，可共享腾讯管家病毒库和破绽库，同时与传统杀毒软件放弃歹意样本替换单干，带来弱小的平安数据检测反对。其中，安全漏洞数据库蕴含了所有CVE破绽库、开源和商业情报库、腾讯平安实验室破绽库；木马病毒检测基于腾讯云全国百亿级样本，笼罩海量病毒、木马、僵尸网络等恶意代码样本。 腾讯自研TAV引擎，高效查杀二进制木马病毒，通过多个国内第三方测评机构认证，病毒检出率达100%。弱小的根底能力和全面的单干生态，保障TCSS一直进化，继续提供镜像平安反对。 运行时平安 为了保障容器运行时安全性，实现入侵行为的即时告警与响应，须要对容器运行时的各项指标进行实时监控。腾讯云容器平安服务运行时平安检测性能包含容器逃逸、反弹Shell、异样过程、文件篡改、高危零碎调用等多维度的入侵检测引擎。 其中，异样过程、文件篡改、高危零碎调用属于高级进攻性能，通过丰盛的零碎规定和用户自定义检测规定，实时监控过程异样启动行为、违反安全策略的文件异样拜访行为及容器内发动的可能引起平安危险的linux零碎调用行为，并实时告警告诉或拦挡。 （外围产品性能：运行时平安） 平安基线 基于TCSS所提供的平安基线性能，可定期对容器、镜像、主机、Kubernetes编排环境进行平安基线检测，帮忙容器环境合规化，防止因配置缺点引发的平安问题，缩小攻击面。 目前反对“容器、镜像、主机、K8S”四种维度检测，帮忙客户查看因为容器运行环境配置不当而引发的平安问题。 04三大劣势助力云原生时代的根底平安TCSS容器平安服务采纳超交融架构，反对繁难装置，轻量部署，助力客户罢黜对容器平安的担心，专一于本身外围业务。 TCSS严格限度 Agent 资源占用，负载过高时被动降级保证系统失常运行，失常负载时耗费极低。实测表明，CPU资源占用不到5%、30M内存。TCSS兼容CentOS、Debian、RedHat等支流操作系统，可一键部署，实现主动在线降级，一经装置，终生免保护，令客户全程无忧。 TCSS失去腾讯云弱小的情报和威逼感知能力赋能。腾讯领有寰球最大、笼罩最全的黑灰产大数据库，TCSS容器平安服务应用腾讯平安数据库对容器环境发现的恶意程序样本进行关联剖析，基于威逼情报感知容器环境威逼行为。超过3500人的腾讯平安专家团队专一于腾讯云平安建设，带来切实的实力保障。 传统平安体系在私有云上适应性差，无奈无效检测新威逼模式，短少自动化响应处理伎俩。目前，腾讯TCSS曾经在多个行业开展了利用，帮忙客户克服了云上资产品种多、数量大、不易盘点的问题，大大晋升了客户的云上平安程度和平安经营管理效率。 在云原生环境下，企业通过微服务来交付利用零碎的比例在减少，容器平安曾经成为了云平安不可或缺的局部。将来，腾讯平安将持续欠缺容器平安一站式解决方案，推动行业构建云原生平安生态，为客户的利用平安提供更全面的爱护。 点击腾讯云容器平安服务内测，预约申请腾讯云容器平安服务内测。

摘要：云原生技术和云市场一直成熟，多云、多集群部署曾经成为常态，将来将是编程式多云治理服务的时代。本文分享自华为云社区《华为云MCP多云跨云的容器治理与实际》，原文作者：技术火炬手。 在华为开发者大会（Cloud）2021上，华为云CTO张宇昕发表多云容器编排我的项目Karmada正式开源。4月26日，华为云原生开源负责人王泽锋与华为云高级工程师徐中虎发表了《华为云MCP多云跨云的容器治理与实际》主题演讲，分享了华为云MCP的的倒退状况与Karmada我的项目的外围黑科技。 演讲次要蕴含五个方面的内容： 1）云原生多云现状及挑战2）华为云MCP历程3）Karmada我的项目4）多集群服务治理5）小结与瞻望 云原生多云现状及挑战 依据最新的调查报告显示，超过93%的企业正同时应用多个云厂商的服务。云原生技术和云市场一直成熟，多云、多集群部署曾经成为常态，将来将是编程式多云治理服务的时代。而业务部署到多云或多集群，它其实是分几个阶段的: 典型阶段1：多云多地部署，对立治理运维，缩小重复劳动 第一个阶段，咱们认为是多地部署对立运维治理，能够了解为是多个互操作的孤岛，互操作意味着在不同的环境，不同的云上，所用软件的技术站是一套标准化的，在进行私有云、私有云1、私有云2相互切换时，操作命令所输出的命令申请都是一样的，但其之间没有任何业务相关性或业务相关性十分弱，此时去做对立的利用交付，比方部署运维，要么手动执行反复的命令或者脚本化，或者最简略的用一套CI/CD的零碎堆上去即可。因为在这个阶段大部分的业务相对来说比拟固定，部署在哪个私有云、哪个数据中心，哪个机房，不须要太多的动态性和变动性。 典型阶段2：多云对立资源池，应答业务压力稳定 第二个阶段为对立资源池，则会对资源池的动态性有肯定的诉求。一般来说，在此处咱们所认为的利用交付并不是一个简略的CI/CD，因为咱们心愿动态性之后，流量也可能随之迁徙。在这种状况下，下面的利用交付就须要具备主动调度的能力，流量能够依据实例数的散布状况本人去获取。当然也会有其余状况，比方用一些简略的脚本化来解决你的流量，也能够认为达到了第二个阶段。当然现实的状态下，咱们认为这些应该是全自动化的。 典型阶段3：多云协同，对立利用平台，业务跨云部署 第三个阶段是咱们认为以后可预见到的一个多云和多集群的最终状态，也是咱们所认为一个现实中的状态。其实不管用集群、Kubernetes或以前的虚拟机，从整个云计算的倒退历史来看，其实始终在一直的冲破边界，或者说从新去定义边界。比方最早的时候装一些新的利用、部署新的服务，须要一台物理服务器，而边界十分不灵便，当起初有了虚机、容器，颗粒度变小了，但在跨机器跨环境的拜访状态下，又产生了很多新的挑战，所以Kubernetes的呈现其实在产生了这么多细腻度的容器之后，从新画一个大的集群作为边界。 而多云其实是在这些一直演进的边界根底上，当在倒退到肯定的阶段受到数据中心或云的限度，能够用多云的技术来冲破云的边界，冲破集群的边界，真正的做到业务的利用能够自在的在集群、在云之间灵便的部署和迁徙。 但其实在云原生话题下，多云依然存在十分多的挑战，起因有以下几点： 集群繁多：繁琐反复的集群配置、云厂商的集群治理差别、碎片化的API拜访入口业务扩散：利用在各集群的差异化配置、业务跨云拜访、集群间的利用同步集群的边界限度：资源调度受限于集群、利用可用性受限于集群、弹性伸缩受限于集群厂商绑定：业务部署的“黏性”、短少主动的故障迁徙、短少中立的开源多集群编排我的项目华为云MCP历程在Kubernetes外面，多集群的概念呈现十分早，华为也是作为最早的发动的单位之一，2015年咱们在社区提出了 Federation的概念，Federation的v1版本是在2016年启动开发，在2017年将其独立，作为Kubernetes的独立子项目来研发。2017年中, 咱们启动了Federation v2的开发。商业化的话，其实华为是在2018年中启动整个商业化的大平台，并且在年底提供了商用的能力，但咱们在长期服务于客户的过程中也发现一些问题，因而在2020年，咱们启动了全新的引擎Karmada。 Karmada是基于 Kubernetes Federation v1 和 v2 开发，它能够跨多个 Kubernetes 集群和云运行云原生应用程序，而无需对应用程序进行更改。通过间接应用 Kubernetes 原生 API 并提供高级调度性能，Karmada 能够实现真正的开放式多云 Kubernetes。 Karmada我的项目 上图为咱们认为应该在开源社区所要出现的多云多集群的技术站视角，图中灰色框也是Karmada要笼罩的所有的能力范畴。从数据面、存储以及运维相干的维度来看，咱们向上要去解决容器网络的多云多集群，服务发现的多云多集群甚至流量治理，原数据的长久化，这些将会Karmada我的项目在社区里所要涵盖的范畴。 在起步阶段，咱们次要会关注几个方面，一是兼容K8s原生API，这个个性其实是原来Federation的v2一个略微比拟大的妨碍，因为大家都习惯去应用k8s的API而不是新的API，所以咱们在做全新的Karmada我的项目时，间接采纳原生的API来提供多集群的利用部署的能力。 在集群同步方面，咱们会反对多种网络模式，包含管制面在私有云，子集群在公有云或者是反过来，甚至是边缘的场景，也都能够用Karmada这个我的项目去笼罩，并且咱们会内置开箱即用的能力来实现最低老本的适配。 Karmada架构图下面有一个对立的管制面，咱们其实有一个独立的API-server来出Kubernetes原生API也会出Karmada提供的额定策略API的能力，来做辅助的高级调度的外围性能。在集群同步方面，咱们有核心式的 Controller和 Agent两种模式，别离对应于管制面和子集群在公私有云或倒置的状况。 另外一类是大边缘的场景，它在云边的网络环境下，须要治理一个边缘的集群，所以咱们会联合KubeEdge在整个网络环境下的优化来提供针对边缘的集群治理能力。 Karmada我的项目外围价值： K8s原生API兼容，丰盛云原生生态内嵌策略，开箱即用丰盛的多集群调度反对集群资源空间隔离多种模式集群同步，屏蔽地区、网络限度多集群利用部署1）零革新 — 应用K8s原生API部署一个多集群利用 示例策略：为所有deployment配置多AZ的HA部署计划 应用规范的K8s API定义部署利用kubectl create -f nginx-deployment.yaml2）Propagation Policy: 可重用的利用多集群调度策略 resourceSelector 反对关联多种资源类型反对应用 name 或 labelSelector 进行对象筛选placement clusterAffinity: 定义偏向调度的指标集群反对通过 names 或 labelselector 筛选clusterTolerations: 相似单集群中Pod tolerations和 node taintsspreadConstraints: ...

前言最近看到很多的平安小白在询问如何去学习平安，如何去动手浸透测试等问题。忽然有感而发，想起来本人过后从小白一步一步走向黑客大佬的成长之路。随着因特网的倒退和网络经济的衰亡, 越来越多的企业将服务或交易平台放到了互联网上, 而且这些网络应用服务和企业的营收关联得也更严密, 甚至与企业的命运休戚相关, 但这些裸露在网上的资源往往防御能力比拟单薄, 加大硬件的投入并不能显著改善企业的平安程度， 在如此的瓶颈之下，企业对懂浸透测试的浸透平安工程师需要也越来越迫切，于是浸透平安工程师的薪水也水涨船高。一、浸透测试是什么？浸透测试 (Penetration Test, 简称 Pen Test) 是通过模仿歹意Hacker的攻打办法，来评估计算机网络系统安全的一种评估办法。这个过程包含对系统的任何弱点、技术缺点或破绽的被动剖析，这个剖析是从一个攻击者可能存在的地位来进行的，并且从这个地位有条件被动利用安全漏洞。这里须要留神，外围是测试，不是攻打也不是进攻。它是一个过程，不是一个工具，也不是一个技巧或知识点。想要了解浸透测试，就须要从“过程”的角度去开展一个维度，再从一个维度向其余维度去扩大。 作为领有着10年教训的浸透平安测试工程师，一路也是从小白历经磨难成长起来的我，给当初的老手小白一些倡议。浸透平安的范畴其实要学习的货色很宽泛的，比方系统安全、挪动平安、无线平安、web平安等很多方向。作为小白呢，这里倡议大家能够从web平安动手，web平安畛域相对来说比拟好入门，对于小白来说呢，入门是相对来说敌对一些的。我刚开始的时候也是从web平安开始动手的，web平安的常识有哪些呢，我给大家简略的梳理一下常识轮廓。 二、Web平安根底要学习那些常识呢？1.对于零碎的操作，比方window零碎、linux零碎、还有黑客最火的kali零碎 2.数据库的学习（针对于web破绽中的SQL注入）例如：MySQL数据库的基本操作 3.进行web平安浸透，就肯定要理解web破绽的原理，web常见的破绽有SQL注入、xss破绽、csrf、ssrf、文件上传、任意文件下载、弱口令、逻辑破绽等，尤其是owasp top 10破绽的原理、判断办法、利用手法、理解防火墙绕过办法，理解CDN技术、负载平衡技术、DNS技术、MVC框架、要理解支流服务器软件的个性破绽、Linux、URL编码、常见加密解密技术、目录爆破、子域名爆破、后盾爆破、ssl等等 4.各种的搜索引擎的应用技巧：Google、FOFA、shodan、zoomeye等搜索引擎的应用技巧来进行资产的收集，在做后期的浸透信息收集的时候，是十分重要的。 5.在进行学习web浸透之前呢，须要简略理解一下上面语言HTML5、css3、PHP ，这些语言对于理解web安全漏洞有很大的帮忙的 6.要把握根本的几种黑客工具的应用：AWVS、appscan、nmap、burpsuite、sqlmap、xray、Metasploit、浏览器代理、各种语言的小马大马、蚁剑等工具的应用 7.对于一些网站的根底框架要有肯定的理解：TP、DZ、WP、织梦、帝国、structs、ecshop、等常见的网站框架要理解 8.Linux浸透进阶常识：Linux下手动查杀木马过程-应用rootkit暗藏形迹的审计办法，次要有模仿木马程序病原体并让木马程序主动运行的代码审计，木马父过程实时监控木马的原理及进攻办法，创立一个让root用户都删除不了的木马程序的原理及进攻办法，深刻解说如何不让木马程序和外网数据被动通信，应用rootkit把木马程序的父过程和木马文件暗藏的审计办法，应用rkhunter Rootkit猎手来查看rootkit，还有Linux下的手工提权原理-劫持账号和明码审计及进攻办法-Tripwire查看文件。 9.还有无线平安和一些免杀shell技巧的技术 以上9个知识点给大家大略介绍了一下web平安浸透概念，上面给大家看一下我总结的比拟全面的web浸透的思维导图，大家能够具体的看一下具体web浸透测试具体须要那些技术知识点。 总结以上的web浸透平安相干的知识点，给大家介绍了一下如何去学习那些常识，这个世界充斥了待解决的迷人问题，做一个黑客有很多乐趣，然而须要颇费气力能力取得这些乐趣。这些能源须要动机。卓越的运动员从健壮体格、挑战自我身材极限中吸取能源。相似的，作为黑客，你必须从解决问题、磨难技术、锤炼智力中取得根本的快感。心愿各位从事浸透平安的小白们，早日进阶黑客大佬。 关注'小神'不迷路每天继续为大家更新不一样的技术干货

本文我来分享下与咱们（搞容器化/K8S 从业者）非亲非故的一个根底我的项目 runc 是如何自 2016 年公布了 v1.0.0-rc1 到当初历经 5 年短跑，从 rc1 始终到 rc95 ，现在终于正式公布 v1.0 版本的过程，及这两头的故事。大家好，我是张晋涛。 在 2018 年 11 月底时，我写了一篇文章 《runc 1.0-rc6 公布之际》 , 那应该是我第一次公开介绍 runc。如果你还不理解 runc 是什么，以及如何应用它，请参考我那篇文章。本文中不再对其概念和用法等进行阐明。 在 2019 年 3 月底时，我写了另一篇文章 《runc 1.0-rc7 公布之际》，介绍 runc 1.0-rc7 公布的起因，及那个版本中最次要的修复 CVE-2019-5736 。其中也介绍了对于 runc/Docker 等对于 Linux 内核兼容性的问题，感兴趣的小伙伴能够看看。 关注我的敌人们，应该也在 K8S 生态周报 中屡次看到过我对 runc 的介绍，包含其个性及安全漏洞等方面。 在 2015 年 6 月， Docker ，CoreOS 和其余一些公司独特成立了 OCI （凋谢容器打算） 组织，其最次要的内容有两个： 容器运行时标准容器镜像标准Docker 将其运行时捐献给了 OCI ，作为容器运行时标准的根底实现，托管在了 https://github.com/opencontai... 也就是当初大家看到的 runc 了。 ...

作者｜ 修冶背 景微服务在最近几年大行其道，很多公司的研发人员都在思考微服务架构，同时，随着 Docker 容器技术和自动化运维等相干技术倒退，微服务变得更容易治理，这给了微服务架构良好的倒退机会。在做微服务的路上，拆分服务是个很热的话题。咱们应该依照什么准则将现有的业务进行拆分？是否拆分得越细就越好？接下来一起谈谈服务拆分的策略和保持的准则。 拆分目标是什么？在介绍如何拆分之前，咱们须要理解下拆分的目标是什么，这样才不会在后续的拆分过程中忘了最后的目标。拆分的实质是为了将简单的问题简单化，那么咱们在单体架构阶段遇到了哪些复杂性问题呢？首先来回忆下当初为什么选用了单体架构，在电商我的项目刚启动的时候，咱们只心愿能尽快地将我的项目搭建起来，不便将产品更早的投放市场进行疾速验证。在开发初期，这种架构的确给开发和运维带来了很大的便捷，次要体现在： 开发简略间接，代码和我的项目集中式治理。排查问题时只须要排查这个利用就能够了，更有针对性。只须要保护一个工程，节俭保护零碎运行的人力老本。然而随着性能越来越多，开发团队的规模越来越大，单体架构的缺点缓缓体现进去，次要有以下几个方面：在技术层面，数据库的连接数成为应用服务器扩容的瓶颈，因为连贯 MySQL 的客户端数量是有限度的。除此之外，单体架构减少了研发的老本克制了研发效率的晋升。比方公司的垂直电商零碎团队会被按业务线拆分为不同的组。当如此多的小团队独特保护一套代码和一个零碎时，在配合的过程中就会呈现问题。不同的团队之间沟通少，如果一个团队须要一个发送短信的性能，那么有的研发同学会认为最快的形式不是询问其余团队是否有现成的，而是本人写一套，然而这种想法是不适合的，会造成性能服务的反复开发。因为代码部署在一起，每个人都向同一个代码库提交代码，代码抵触无奈防止；同时性能之间耦合重大，可能你只是更改了很小的逻辑却导致其它性能不可用，从而在测试时须要对整体性能回归，缩短了交付工夫。模块之间相互依赖，一个小团队中的成员犯了一个谬误，就可能会影响到其它团队保护的服务，对于整体零碎稳定性影响很大。最初，单体架构对于零碎的运维也会有很大的影响。设想一下，在我的项目初期你的代码可能只有几千行，构建一次只须要一分钟，那么你能够很麻利灵便地频繁上线变更修复问题。然而当你的零碎裁减到几十万行甚至上百万行代码的时候，一次构建的过程包含编译、单元测试、打包和上传到正式环境，破费的工夫可能达到十几分钟，并且任何小的批改，都须要构建整个我的项目，上线变更的过程十分不灵便。而这些问题都能够通过微服务化拆分来解决。为了不便你更好的了解这块，在此附上一份表格（内容起源：《继续演进的 Cloud Native：云原生架构下微服务最佳》一书），能够更直观地帮忙你意识拆分的目标。 拆分机会应该如何决策？产品初期，应该以单体架构优先。因为面对一个新的畛域，对业务的了解很难在开始阶段就比拟清晰，往往是通过一段时间之后，能力逐渐稳固，如果拆分过早，导致边界拆分不合理或者拆的过细，反而会影响生产力。很多时候，从一个已有的单体架构中逐渐划分服务，要比一开始就构建微服务简略得多。同时公司的产品并没有被市场验证过，有可能会失败，所以这个投入的危险也会比拟高。另外，在资源受限的状况下，采纳微服务架构很多劣势无奈体现，性能上的劣势反而会比拟显著。如下图所示。当业务复杂度达到肯定水平后，微服务架构耗费的老本才会体现劣势，并不是所有的场景都适宜采纳微服务架构，服务的划分应逐渐进行，继续演进。产品初期，业务复杂度不高的时候，应该尽量采纳单体架构。 随着公司的商业模式逐步失去验证，且产品取得了市场的认可，为了能放慢产品的迭代效率疾速占领市场，公司开始引进更多的开发同学，这时零碎的复杂度会变得越来越高，就呈现单体利用和团队规模之间呈现矛盾，研发效率不升反降。上图中的交叉点表明，业务曾经达到了肯定的复杂度，单体利用曾经无奈满足业务增长的需要，研发效率开始降落，而这时就是须要思考进行服务拆分的机会点。这个点须要架构师去衡量。笔者所在的公司，是当团队规模达到百人的时候，才思考进行服务化。当咱们分明了什么时候进行拆分，就能够间接落地了吗？不是的，微服务拆分的落地还要提前准备好配套的基础设施，如服务形容、注册核心、服务框架、服务监控、服务追踪、服务治理等几大根本组件，以上每个组件缺一不可，每个组件开展又包含很多技术门槛，比方，容器技术、继续部署、DevOps 等相干概念，以及人才的储备和观点的变动。微服务不仅仅是技术的降级，更是开发方式、组织架构、开发观点的转变。 至此，何时进行微服务的拆分，整体总结如下： 业务规模：业务模式失去市场的验证，须要进一步加快脚步疾速占领市场，这时业务的规模变得越来越大，按产品生命周期来划分（导入期、成长期、成熟期、衰退期）这时个别在成长期阶段。如果是导入期，尽量采纳单体架构。团队规模：个别是团队达到百人的时候。技术储备：畛域驱动设计、注册核心、配置核心、日志零碎、继续交付、监控零碎、分布式定时工作、CAP 实践、分布式调用链、API 网关等等。人才储备：精通微服务落地教训的架构师及相应开发同学。研发效率：研发效率大幅降落，具体问题加入下面拆分目标里提到的。拆分时应该坚守哪些领导准则？1. 繁多服务外部性能高内聚低耦合 也就是说每个服务只实现本人职责内的工作，对于不是本人职责的性能交给其它服务来实现。2. 闭包准则（ CCP ）微服务的闭包准则就是当咱们须要扭转一个微服务的时候，所有依赖都在这个微服务的组件内，不须要批改其余微服务。3. 服务自治、接口隔离准则尽量打消对其余服务的强依赖，这样能够升高沟通老本，晋升服务稳定性。服务通过规范的接口隔离，暗藏外部实现细节。这使得服务能够独立开发、测试、部署、运行，以服务为单位继续交付。4. 继续演进准则在服务拆分的初期，你其实很难确定服务到底要拆成什么样。从微服务这几个字来看，服务的粒度貌似应该足够小，然而服务多了也会带来问题，服务数量快速增长会带来架构复杂度急剧升高，开发、测试、运维等环节很难疾速适应，会导致故障率大幅减少，可用性升高，非必要状况，应逐渐划分，继续演进，防止服务数量的爆炸性增长，这等同于灰度公布的成果，先拿出几个不太重要的性能拆分出一个服务做试验，如果呈现故障，则能够缩小故障的影响范畴。5. 拆分的过程尽量避免影响产品的日常性能迭代也就是说要一边做产品性能迭代，一边实现服务化拆分。比方优先剥离比拟独立的边界服务（ 如短信服务等 ），从非核心的服务登程缩小拆分对现有业务的影响，也给团队一个练习、试错的机会。同时当两个服务存在依赖关系时优先拆分被依赖的服务。6. 服务接口的定义要具备可扩展性服务拆分之后，因为服务是以独立过程的形式部署，所以服务之间通信就不再是过程外部的办法调用而是跨过程的网络通信了。在这种通信模型下服务接口的定义要具备可扩展性，否则在服务变更时会造成意想不到的谬误。比方微服务的接口因为降级把之前的三个参数改成了四个，上线后导致调用方大量报错，举荐做法服务接口的参数类型最好是封装类，这样如果减少参数就不用变更接口的签名，而只须要在类中增加字段就能够了7. 防止环形依赖与双向依赖尽量不要有服务之间的环形依赖或双向依赖，起因是存在这种状况阐明咱们的性能边界没有化分分明或者有通用的性能没有下沉下来。 8. 阶段性合并随着你对业务畛域了解的逐步深刻或者业务自身逻辑产生了比拟大的变动，亦或者之前的拆分没有思考的很分明，导致拆分后的服务边界变得越来越凌乱，这时就要从新梳理畛域边界，一直纠正拆分的合理性。 拆分的粒度是不是越细越好？目前很多传统的单体利用再向微服务架构进行降级革新，如果拆分粒度太细会减少运维复杂度，粒度过大又起不到成果，那么革新过程中如何均衡拆分粒度呢？ 1. 弓箭原理均衡拆分粒度能够从两方面进行衡量，一是业务倒退的复杂度，二是团队规模的人数。如上图，它就像弓箭一样，只有当业务复杂度和团队人数足够大的时候，射出的服务拆分粒度这把剑才会飞的更远，施展出最大的威力。比如说电商的商品服务，当咱们把商品从大的单体里拆分进去的时候，就商品服务自身来讲，逻辑并没有足够简单到 2 ~ 3 集体没法保护的境地，这时咱们没有必要持续将商品服务拆的更细，然而随着业务的倒退，商品的业务逻辑变的越来越简单，可能同时服务公司的多个平台，此时你会发现商品服务自身面临的问题跟单体架构阶段面临的问题根本一样，这个阶段就须要咱们将商品拆成更细粒度的服务，比方，库存服务、价格服务、类目服务、商品根底信息服务等等。 尽管业务复杂度曾经满足了，如果公司此时没有足够的人力（招聘不及时或员工异动比拟多），服务最好也不要拆分，拆分会因为人力的有余导致更多的问题，如研发效率大幅降落（一个开发负责与其不匹配数量的服务）。这里引申另外一个问题，一个微服务到底须要几个开发保护是比拟感性的？我援用下李云华老师在"从零开始学架构“ 中的一段经典阐述，能够解决此问题。2. 三个火枪手准则为什么说是三个人调配一个服务是比拟感性的？而不是 4 个，也不是 2 个呢？首先，从零碎规模来讲，3 集体负责开发一个零碎，零碎的复杂度刚好达到每个人都能全面了解整个零碎，又可能进行分工的粒度；如果是 2 集体开发一个零碎，零碎的复杂度不够，开发人员可能感觉无奈体现本人的技术实力；如果是 4 个甚至更多人开发一个零碎，零碎复杂度又会无奈让开发人员对系统的细节都理解很深。其次，从团队治理来说，3 集体能够造成一个稳固的备份，即便 1 集体休假或者调配到其余零碎，残余 2 集体还能够撑持；如果是 2 集体，抽调 1 个后残余的 1 集体压力很大；如果是 1 集体，这就是单点了，团队没有备份，某些状况下是很危险的，如果这个人休假了，零碎出问题了怎么办？最初，从技术晋升的角度来讲，3 集体的技术小组既可能造成无效的探讨，又可能疾速达成一致意见；如果是 2 集体，可能会呈现相互保持本人的意见，或者 2 集体教训都有余导致设计缺点；如果是 1 集体，因为没有人跟他进行技术探讨，很可能陷入思维盲区导致重大问题；如果是 4 集体或者更多，可能有的参加的人员并没有认真参加，只是实现工作而已。“三个火枪手”的准则次要利用于微服务设计和开发阶段，如果微服务通过一段时间倒退后曾经比较稳定，处于保护期了，毋庸太多的开发，那么均匀 1 集体保护 1 个微服务甚至几个微服务都能够。当然思考到人员备份问题，每个微服务最好都安顿 2 集体保护，每个人都能够保护多个微服务。综上所诉，拆分粒度不是越细越好，粒度须要合乎弓箭原理及三个火枪手准则。 ...

作者｜易立 阿里云容器服务负责人 背景云原生是云计算倒退的必然产物，而云原生的继续成长也绝非偶尔。2021年，云原生出现怎么的风貌、又带来了哪些新变动？阿里云容器服务研发总监易立近日在阿里云开发者大会发表了《云原生利用新边界》的演讲，并示意，云原生为开发者提供了三方面便当：利用基础设施“零”保护、利用架构现代化“零”阻力、数字与物理世界“零”边界。 云原生：因云而生云原生是因云而生的技术，它根植于开发者，并提供最大云价值。 在 CNCF 2020 开发者现状报告中，当初寰球有超过 470 万开发者在应用云原生技术，占全副后端开发者的 36%。开发者曾经成为云原生改革最次要的推动力量。 利用基础设施“零”保护容器、Serverless 等云原生技术继续推动计算界面上移，复杂性下沉，让开发者能够关注于业务翻新而非基础设施，这样能够极大晋升研发效率。 阿里云为开发者提供了全国最丰盛的云原生产品，帮忙企业专一于业务翻新、而非基础设施建设。企业能够通过容器服务, 函数计算，服务网格，实现利用架构的互联网化，在此之上，云原生数据库、云原生 AI，云原生大数据等产品更能够帮忙企业减速业务流程的数字化与智能化。 利用架构现代化“零”阻力越来越多的企业心愿通过利用现代化革新，比方微服务化、Mesh 化，带来新的的收益，更好地满足业务倒退的需要。不过新技术也会给现有利用架构带来很大的冲击。利用云原生技术，能够循序渐进将现有利用架构平滑降级。 在对现有利用进行现代化革新时, 开发者须要把一个单体应用程序分拆为分布式的微服务架构, Spring Cloud / Dubbo 等微服务架构都是以 SDK 代码库的形式把服务治理逻辑构建在应用程序之中。但这种架构存在几个问题： 侵入性：在微服务框架中，服务治理能力的实现和生命周期与业务逻辑耦合在一起的。服务治理能力的变更和加强须要利用的从新构建和部署，导致降级和保护老本晋升。实现绑定：因为微服务框架代码库通常由特定语言实现，难以反对多语言（polyglot）异构零碎之间的集成为挑战。因而，社区提出 Service Mesh（服务网格）架构 —— 将利用的业务逻辑与服务治理能力解耦。服务治理的能力运行在一个独立的 Sidecar 过程之中，独立部署。通过网络拦挡来实现对利用通明的服务发现、流量治理、可观测性、平安等能力。解决了上述侵入性、绑定的问题，具体劣势如下： 复杂性下沉：服务治理实现下沉到基础设施，能够独立演进。使得开发人员能够更加聚焦于业务利用自身。零侵入：无需代码革新既能够实现零信赖平安，可观测性等高阶能力。多语言反对：能够通明反对多种编程语言和编程框架。那么，微服务与服务网格是否非此即彼，鱼与熊掌不可得兼？在进行服务网格革新的同时，如何与现有微服务架构兼容并存？随着社区的致力，服务网格和微服务能够很好地联合在一起, 撑持企业微服务架构平滑演进。 阿里云提供的托管服务网格 ASM 反对 Dubbo 通信协议, 通过申明式形式反对灰度公布、金丝雀公布、无损下线等能力。利用阿里开源的 Nacos 服务注册核心，能够对立反对 Mesh 利用和微服务利用的服务注册与发现。Nacos 2.0 性能晋升 10 倍, 无效地反对大规模服务网格利用落地。Apache Dubbo 3.0 也在摸索 Proxyless 式，也就是采纳无代理形式反对服务网格; 在 Proxyless 模式下无需 Sidecar 即可间接通过服务网格的 UDPA 协定实现对 Dubbo 利用的流量治理。这种形式能够进一步网络提早，缩小资源开销。服务网格也增强了对虚拟机利用部署的反对，助力遗留利用的平滑降级。 以东风日产汽车为例，介绍企业的服务网格化迁徙之路。首先，它的数据服务采纳 Python / Java 等不同语言开发，Java 利用应用 Dubbo 微服务框架，Python 应用 REST/HTTP 进行服务调用，不足对立的服务治理能力；其次，虚拟机、容器化部署等多种形式并存，心愿全面迁徙到容器架构。 ...

地理信息系统（Geographic Information System，GIS）又称为“地学信息系统”或“资源与环境信息系统”，是以天文空间数据为根底，采纳天文模型分析方法，适时地提供多种空间的和动静的地理信息，在计算机硬、软件系统反对下，对整个或局部地球表层（包含大气层）空间中的无关地理分布数据进行采集、贮存、治理、运算、剖析、显示和形容的技术零碎。 简略说，没有地理信息系统，大家甚至都没法找到左近的人，也无奈搜到左近好吃的餐馆。 国家十四五倒退大纲中，要将二维的地理信息逐渐向三维进行降级，为国土资源利用、林业、水利、交通、电力、救灾等国计民生的重要行业倒退和决策提供高水平反对（例如，通过三维实景建模，能够清晰地模拟出江河水位每贬低一厘米，将对多少区域造成理论威逼，从而精准地施行防洪策略），这将推动整个地理信息行业向着更业余和更高标准倒退。 大规模地理信息的描述和获取，从最后靠测绘人员用脚丈量土地，随后应用卫星或飞机进行遥测，近些年随着无人机、高空高精度、高分辨率拍摄设施的疾速倒退，地理信息外业数据采集模式更加多元，这带来的是数据量的爆发性增长。中等规模城市单次采集的地理信息数据可达5-600TB，一线城市数据量甚至能够达到 1-2PB，单张高精度图片的大小达到 400MB。 采集到数据之后，须要在内业环境中应用业余软件（例如瞰景的 Smart3D、Bentley 的 ContextCapture 等）对数百 TB 原始数据（包含图片、视频、点云）进行解决（例如空三计算、标注等操作）。这些业余软件都是由大量高性能计算节点组成分布式的集群进行工作，这个集群须要从共享的数据源中获取原始数据。这样的架构是不是意味着，只有将数据实现多机共享，有足够的计算资源，就能疾速实现地理信息绘制作业呢？答案当然是否定的。 那么，大规模的地理信息绘制应该抉择什么样的存储进行撑持呢？咱们从 ArcGIS 装置手册中，找到了对存储的倡议和要求：（https://enterprise.arcgis.com...） 抉择文件存储设备 (NAS/SAN) 时，实时一致性和性能是须要思考的两大根本要求。在抉择文件存储设备之前，请务必理解服务器目录和配置存储。 实时一致性抉择一种存储设备，一旦操作和相应的写入实现，就能够立刻从计算集群中的任何节点读取文件。应用 NFS 时，必须设置相应配置以确保各个节点可能读取统一的数据，并防止应用过期的数据缓存。性能抉择性能优异的存储设备，能力缩小随机 I/O 和小文件带来的影响。不同存储设备在面对不同特点的 I/O 时，读写性能有很大差别。小 I/O 的性能十分重要，因为 ArcGIS Enterprise 的 I/O 操作（例如 ArcGIS 与配置仓库、缓存包切片等进行交互的操作）就是大量的随机小 I/O。这通常意味着已针对大 I/O 程序读取和写入（通常产生在图像和视频中）进行了优化的设施不适宜与 ArcGIS Enterprise 组件一起应用。如果抉择的文件存储不能很好地解决小的随机 I/O，用户可能会遇到响应工夫显著减少甚至我的项目绘制失败的状况。可见，存储集群的性能，尤其是随机小 I/O 的性能，是 GIS 软件的一个硬性要求。在和用户理论生产对接中，咱们发现，数据共享存储面临两个重要挑战： 共享存储中小 I/O 读写性能，制约了实景建模等我的项目的绘制进度。一般的数据共享存储（例如 NAS 阵列、或一般的分布式文件存储）无奈撑持大规模的Smart3D 或 ContextCapture 计算集群进行并发解决。在一个理论我的项目中，用户基于原有的一套分布式存储，应用瞰景 Smart3D 进行实景建模，单套存储软件只能撑持 60 台计算节点，无论从存储的应用效率、还是计算效力利用率的角度上看，都难以达到用户的预期。焱融科技工程师，基于同样的服务器，搭建了 YRCloudFile 存储集群，应用 YRCloudFile Windows 客户端，最大撑持到了 600 台计算节点的规模，将原来 3 天实现的绘制工作，缩短到 2 小时实现。 ...

2021 年 6 月 16 日，在由中国科学院《互联网周刊》、中国社会科学院信息化钻研核心、eNet研究院、德本征询（智库）主办的2021 第三届翻新倒退论坛暨《2021企业翻新倒退白皮书（报告）》发布会上，BoCloud博云凭借在云计算 PaaS 畛域当先的自主创新能力、自主研发的 PaaS 系列产品和服务的创新能力、PaaS 平台解决方案的翻新建设能力、获评 “ 2021 云计算 PaaS 翻新领导者 ”。 围绕企业数字化转型 IT 架构麻利化转型需要，博云打造了以容器云+DevOps平台+微服务平台为外围的 PaaS平台产品体系，实现了从业务开发、集成、部署及运维的全链条撑持，反对利用全生命周期治理，帮忙上百家传统企业，实现了云原生架构设计从理念到落地的改革。 近期，博云先后入选国内外权威行业报告，在赛迪参谋公布的《2020－2021 年中国PaaS市场钻研报告》中，博云位居挑战者象限，是创新型PaaS厂商的领导者。 在 IDC 最新公布的中国容器软件市场报告中，博云稳居中国容器市场份额TOP5，是进入前五的惟一创新型厂商！ 数据起源：IDC《PRC SDC Software Market Overview, 2020H2》 数字经济时代，企业对 PaaS 的依赖性和需要明显增加，企业亟需构建面向云原生利用的利用容器化、微服务化、开发运维一体化等为特色的新型 IT 架构。 博云将继续专一 PaaS 畛域，“做深做厚” PaaS 平台，助力企业构建新一代 IT 架构，减速实现数字化转型。 点击BoCloud博云理解更多解决方案

转载请注明出处：葡萄城官网，葡萄城为开发者提供业余的开发工具、解决方案和服务，赋能开发者。大家在工作中或者或多或少都接触过Docker，那你晓得Docker以及容器化背地的原理到底是什么吗？ 容器化技术满天下，那为什么只有Docker被大家所熟知呢？ 后Docker时代，到底谁才是云原生时代的王者？ 咱们置信本系列文章能帮您解答这些纳闷。 被“厌弃”的物理服务器在云时代以前，开发者如需构建一个线上的站点，必须本人保护物理服务器。然而随着业务倒退，大体量服务器逐步增多，随之而来的是硬件、场地和保护老本的一直进步。对于面向C端的站点来说，网络热点事件具备随机性，流量的变动并不可控，难免会遭逢站内流量暴涨的状况。此时如果没有备用服务器，突发的大流量很可能会冲垮整个站点。但在没有突发事件的时候，备用服务器的洽购和保护老本又让人不可疏忽。 （运维的传统艺能：上线拜祖，图片来自网络）哪里有问题，哪里就有商机。有人想到，如果买一批服务器放在外网，安顿专人治理，而后依照用户的须要租赁进来，不正好解决了这个问题吗？ 于是，一场云计算的好戏，正式演出。 虚拟机还是“超重”了云计算时代的大幕拉开，大厂先后登台，让咱们先简略做一下回顾。 2006年，亚马逊成立aws，从云端存储业务开始。2008年，云计算初创。2009年，阿里云成立。目前最新的数据表明，2020年度IaaS市场份额考察，阿里云位居寰球第三，亚太第一；前两名别离是亚马逊和微软，市场份额达9.5%，超过谷歌的6.1%，亚马逊40.8%，微软17%。国内市场份额40% ，第二是华为云，占18%。2010年，OpenStack由NASA公布。OpenStack是一个IaaS架构，能够用其架构来搭建本人的公有云，让任何人都能够自行创立和提供云计算服务。比照而言，AWS和aliyun都是自研架构，OpenStack是开源的。所以公司如果须要，齐全能够接入OpenStack搭建本人的公有云。（当然前提须要有OpenStack外围开发能力）。2010-2013年之间，云计算的寰球份额被aws和OpenStack瓜分。这时的云计算技术，实质都是虚拟化技术，将硬件资源作为基础设施提供给用户，简称IaaS。简略了解，IaaS就是将一个很大的服务器，通过虚拟化技术拆分成多个小的虚构服务器，提供服务，相似于在本机装了虚拟机。 （云计算主力玩家的进场工夫，图片来自网络） 然而，IaaS时代的虚拟机还是太过于轻便了。每一台虚拟机都须要耗费CPU、内存等计算资源能力撑持利用的运行。即使利用再小，零碎的开销都是固定的老本。如何为IaaS减肥，让虚拟机零碎的开销降到最低？ 2013年开始，云计算正式进入了PaaS时代。PaaS时代，云计算所销售的单元，从虚拟机变成了利用运行平台。于是，云厂商提供的服务更多，资源利用率也更高了。 什么是PaaS？咱们用一个艰深的例子来解释。如果咱们当初是一个烧饼店老板，采纳IaaS模式意味着咱们须要用他人厨房、锅炉、煤气，本人和面做馅料，做烧饼。如果是PaaS，咱们烧饼的面粉、馅料和调料都是他人提供好了，咱们只须要把饼烤熟。 云厂商该如何构建一套好用的PaaS服务呢？借力开源我的项目，成为各厂商的共识。 Cloud Foundry开启PaaS开源时代PaaS的外围是平台。最早呈现在开发者视线中的PaaS开源我的项目中，vmware创建的Cloud Foundry是知名度最高的。与IaaS提供云上虚拟机的服务形式不同，基于Cloud Foundry的云计算可能提供利用托管的性能。开发者只须要通过一条简略的命令比方：cf push "我的利用"，就能够将我的项目打成一个压缩包，上传到Cloud Foundry服务器。而Cloud foundry会开启本人的调度器，在一群云主机中找到满足用户需要的主机（零碎版本、性能、个数），而后通过容器化技术，在主机上创立一个容器，在容器中下载压缩包，解压并运行，最终成为一个对外提供服务的利用。 此外，Cloud Foundry平台对这些利用我的项目提供散发，灾备，监控，重启等等服务（这也是咱们提供给用户的外围服务）。这种托管服务解放了开发者的生产力，让他们不必再关怀利用的运维情况，而是分心开发本人的利用。而这就是PaaS的“初心”，平台即服务。 （Cloud Foundry提供的服务） 这里就会有同学问了，容器是什么？容器是用来解决多个利用资源抵触与隔离性问题的技术。Linux上的namespace机制和cgroups命令都能用做资源隔离和限度，这些都是容器技术。 容器技术并不是Docker创立的，在Docker衰亡之前，就曾经被其余公司商用了，然而为什么当初一谈起容器，所有人第一工夫想到的就是Docker呢？这就要提到Cloud Foundry的死亡。 从Cloud Foundry到DockerCloud Foundry仿佛曾经和咱们当初应用的云性能区别不大，但2021年的现实情况却是Cloud Foundry曾经死了。 咱们看过互联网上很多文章，再联合咱们活字格私有云开发的教训，咱们认为这个我的项目的致命缺点集中它的打包机制上。 Cloud Foundry最外围的组件就是利用的打包和散发机制，也是开发者打交道最多的性能。Cloud Foundry为每一种支流的语言都定义了一套打包的形式，这些形式之间毫无章法。但就是这个打包性能，成了Cloud Foundry的软肋，始终为用户所诟病。开发者不得不为每一种语言，每一种框架，甚至是每个版本利用保护一个打好的包，还有可能呈现本机运行胜利，打了个包上传上去之后就无奈运行的状况。状况最重大的时候，开发者在调试云平台零碎上花的工夫都曾经比开发一个新软件的工夫要长了。 原本是为赋能开发者的而生的技术，Cloud Foundry却对开发者如此不敌对。当开发者的埋怨积攒到肯定水平，想要在PaaS浪潮地方站稳脚跟的Cloud Foundry被后起之秀Docker“红牌罚出局”也就牵强附会了。 最后，Docker是一个过后还叫dotCloud的公司（2010年由所罗门海克斯创立，Y Combinator孵化）开发的容器我的项目。在Cloud Foundry困于打包问题时，Docker正在轻轻积蓄力量，在开源后的短短几个月内就迅速崛起，成为一个不容忽视的PaaS技术计划，吸引了云服务开发者的眼球。 滑稽的是，在Docker刚开源的时候，Cloud Foundry的首席产品经理 James Bayer就在社区做了一次具体的比照，通知用户Docker和Cloud Foundry一样，都是应用了Namespace和Cgroups技术的沙箱而已，没什么值得关注的。 事实上，Docker也的确就和他所说的一样，采纳了这个“传统”的技术计划，然而Docker与Cloud Foundry相比，做了一点小小的翻新，体现了所罗门海克斯的远见。从2010他就开始思考利用打包的一致性与复用性问题，并提出了翻新的解决方案，最终对Cloud Foundry造成了毁灭性的打击。这个解决方案就是Docker镜像。 （Docker，图片来自官网） 刚开源的Docker迅速爆火，憨态可掬的小鲸鱼，对用户敌对的文档，三分钟部署一个Nginx集群的宣传语，以及Docker Image这个 “微不足道的翻新”，让Docker席卷整个PaaS畛域。 Docker的制胜法宝：镜像Docker胜利的要害，在于Docker镜像简直完满地解决了Cloud Foundry在打包方面的软肋。 所谓的镜像，其实也是一个压缩包，然而比起Cloud Foundry那种执行文件+启动脚本的打包后果，镜像提供给用户的是一套残缺的运行环境，每一个镜像都能够指定操作系统版本，外部能够构建程序执行的文件构造，并且一份镜像能够齐全共享在多处应用。 此外，Docker还给开发者提供了一套欠缺的镜像制作流程，这套流程与编程语言和框架无关。开发者只须要依照该流程，定制对应程序所须要的运行的操作系统环境即可。 总之，Docker 镜像完满解决了两个问题： 1.本地环境和服务器环境的差别2.同一份镜像能够让所有的机器进行复用 ...

Kubernetes 官网发布公告，发表自 v1.20 起放弃对 Docker 的反对。目前，Kubelet 中的 Docker 反对性能现已弃用，并将在之后的版本中被删除。 再来看上面这张图（起源网络） 从上图中能够看出 docker 对容器的治理和操作根本都是通过 containerd 实现的。所以，如果大家想从 docker 迁徙进去，那么 Containerd 是一个十分不错的先择。 明天，民工哥就和大家来聊一聊这个开源技术 Containerd。 Containerd 概述 很早之前的 Docker Engine 中就有了containerd，只不过当初是将 containerd 从 Docker Engine 里分离出来，作为一个独立的开源我的项目，指标是提供一个更加凋谢、稳固的容器运行基础设施。分离出来的 containerd 将具备更多的性能，涵盖整个容器运行时治理的所有需要，提供更弱小的反对。 简略的来说，containerd 是一个工业级规范的容器运行时，它强调简略性、健壮性和可移植性。containerd能够在宿主机中治理残缺的容器生命周期，包含容器镜像的传输和存储、容器的执行和治理、存储和网络等。 地址：https://github.com/containerd... containerd 架构 其中，grpc 模块向下层提供服务接口，metrics 则提供监控数据(cgroup 相干数据)，两者均向下层提供服务。containerd 蕴含一个守护过程，该过程通过本地 UNIX 套接字裸露 grpc 接口。 storage 局部负责镜像的存储、治理、拉取等 metadata 治理容器及镜像的元数据，通过bootio存储在磁盘上 task -- 治理容器的逻辑构造，与 low-level 交互 event -- 对容器操作的事件，下层通过订阅能够晓得产生了什么事件 Runtimes -- low-level runtime（对接 runc） Containerd 能做什么？？治理容器的生命周期(从创立容器到销毁容器)拉取/推送容器镜像存储管理(治理镜像及容器数据的存储)调用 runC 运行容器(与 runC 等容器运行时交互)治理容器网络接口及网络从 k8s 的角度看，抉择 containerd作为运行时的组件，它调用链更短，组件更少，更稳固，占用节点资源更少。 ...

摘要：CCE Turbo是华为云推出的一款革命性容器集群。5月31日，在华为云Techwave云基础设施技术专题日上，华为云容器批量计算首席架构师马达对CCE Turbo的技术底细进行了深度解读，CCE Turbo是华为云推出的一款革命性容器集群，在华为开发者大会（Cloud）2021上正式公布，通过计算、网络、调度的全方位减速，为企业应用翻新提速。 软硬协同，为计算减速为了解决集群服务器性能无奈齐全施展的问题，华为云基于擎天架构的软硬协同能力，推出了业界独家的容器卸载技术，并利用到CCE Turbo，让集群资源100%用于业务解决。同时，通过对引擎进行瘦身、优化外部执行逻辑及外围模块重写，如基于Rust语言重写了 shimv2 和 agent，缩小了过程数量、通过代码优化缩小内存耗费，晋升容器启动性能和Cgroup治理能力，同时联合擎天卡的高能性解决能力，将集群整体性能晋升40%，资源应用老本节俭30%。 Trunkport，为网络减速网络连通速度、转发效率始终是业务应答大流量时所面临的挑战，华为云基于云原生2.0“IN Cloud”理念，打造了全新的云原生网络，利用Trunkport技术为网络全面减速。 Trunkport技术使得容器可直通VPC网络，将原有的“容器网络 + 虚拟机网络“的两层模型变为一层，网络资源连通工夫缩短一半，无效撑持业务30秒内扩容1000容器实例，轻松应答流量浪涌，同时也将网络通信时延升高了40%，让利用拜访更晦涩； CCE Turbo还率先在业界实现了为容器配置独立平安组和QoS，相比目前其它厂商容器与集群节点共享平安组的计划，不仅加强了容器通信安全性，还晋升了大流量的转发效率。此外，CCE Turbo还基于CRD机制扩大了Kubernetes对象，用于实现各种简单平安隔离诉求，并进一步简化容器平安组的配置。 Volcano，调度减速企业外围业务全面云原生化后，如何晋升调度效率、晋升集群利用率，是困扰很多企业的难题。CCE Turbo基于Volcano实现了三大外围调度能力： 在线离线混合调度：CCE Turbo将企业离线和在线业务在同一集群中混合部署，相比之前不同业务分集群部署，极大的升高了运维工作量，同时，依据在线、离线业务的不同需要进行灵便调度，如：当在线业务访问量低时，CCE Turbo可将闲暇资源用来运行离线计算业务（如离线剖析、模型训练等），而当业务顶峰降临前，会主动开释离线业务占用的资源，保障在线业务对资源的诉求；利用感知智能调度：为了进一步晋升混合部署后的集群利用率，通过感知利用模型（如web类利用、Tensorflow的PS和worker、Spark的Driver和executor等），针对不同利用模型对资源的诉求、利用负载状况，通过资源按需抢占、分时复用等机制，缩小集群资源的闲暇比例；并通过感知工作间拓扑构造，将各任务调度到最佳节点上，缩小因网络瓶颈、数据跨节点传输等带来的工夫损耗，进而能够将集群利用率晋升2倍；大规模散布式调度：为了保障业务混合部署后，海量工作并发调度的难题，CCE Turbo推出了分布式架构的任务调度器，晋升吞吐能力，并通过调度算法剪枝，缩小寻址深度和广度，同时联合调度决策复用机制，可将调度寻址工夫缩短10倍以上，实现每秒1万容器的大规模并发调度。CCE Turbo为VIPKID音视频业务全面提速VIPKID作为CCE Turbo的晚期用户，已充沛享受到CCE Turbo三大减速为业务带来的价值，本次专题日上，VIPKID后端研发高级专家慈轶恒在分享中示意，“应用CCE Turbo后，VIPKID音视频业务在各方面的指标都失去了不同水平的优化，等同规格集群性能较之前晋升了40%，业务交互时延升高了40%，使得用户体验进一步晋升，整个业务老本节俭43%左右，很好的管制了业务高速增长期的IT老本增长速度。” 作为最早一批投身云原生技术的厂商，华为云是云原生计算基金会（CNCF）在亚洲惟一的初创成员，社区代码奉献和Maintainer席位数均位居亚洲第一，并奉献首个云原生智能边缘我的项目KubeEdge和批量计算我的项目Volcano，在华为开发者大会 2021（Cloud）上，华为云还联结多家企业开源了云原生多云容器编排我的项目 Karmada，继续引领云原生技术倒退方向；在产品翻新方面，华为云自2016年起相继在业内首发一系列云原生产品与解决方案，在Forrester的产品能力评估中，间断两年取得满分，且容器软件市场排名已位居中国第一；在凋敝产业方面，华为云不仅联结中国信通院公布了云原生2.0白皮书，全面诠释云原生2.0核心理念，还与CNCF、中国信通院联结构建了全球化的云原生交流平台——创原会，华为云将联结各行业云原生精英一起，独特摸索前沿云原生技术、共享产业落地实际，用云原生技术全面赋能企业数字化转型。 点击关注，第一工夫理解华为云陈腐技术~

容器在近些年变得煊赫一时，提到容器就不能不提到镜像，如果说容器是云计算时代的核心内容之一，那么镜像就是容器这个外围的灵魂。所以镜像的平安也就显得尤为重要。然而从上面的几组数据能够看到：镜像的平安问题却不那么令人乐观。 1) Linux OS的破绽呈逐年上涨趋势从2008年的不到300+，回升至2018年的2000+。而且近两年呈指数级回升趋势。 2) 高危破绽数量呈逐年上涨趋势从2014年的不到2000+，回升至2018年的4000+。 3) Docker 镜像普遍存在破绽最受欢迎的镜像比方nginx，ubuntu，java等普遍存在破绽，且多达数十个。 4) 40%的受访者示意，没有在CI阶段采取任何平安伎俩。因而，保障镜像平安，不仅是保障云平台平安的重要一环，更是DevSecOps治理体系中一个重要的话题。 一、镜像的特点镜像的实质、镜像的起源以及镜像的制作独特造就了镜像的以下几个特点: 复杂性镜像内容的复杂性(既包含一些OS的各种库、包，又蕴含一些Python或者Ruby等文件)、起源的复杂性(官网的、集体的)、Dockerfile 命令的复杂性(ADD和COPY的区别应用，CMD和ENTRYPOINT的区别应用，命令程序不同造就不同的镜像)使得镜像自身就变得非常复杂，如果思考平安因素，那就更加简单了。 便捷性镜像的制作是十分不便的，只有会写Dockerfile，就能制作出镜像，或者也可将既有容器制作成一个镜像。而且镜像的应用也是十分不便的，一个命令(docker run)就能将一个动态的镜像转变为一个动静的容器，恰好是这种便捷性造成了镜像的另外一个特点，也就是上面的凌乱性。 凌乱性人人可制作镜像，人人可治理镜像，也就使得镜像的品种、数量都是异样宏大的，而且针对某个特定性能的镜像可达几十个，甚至上百个，既有官网的，又有集体的，既有共有仓库的，又有公有仓库的。没有一个卓有成效的规范去标准的治理这些镜像，就使得镜像参差不齐，选用时较为艰难。 上述的特点也就使得镜像的平安变成了一个简单且容易被疏忽的点。然而再简单，也有伎俩去实现这个简单的工作，也就是上面要讲的镜像扫描。 二、镜像扫描在SDLC中的地位镜像扫描是保障镜像平安的一个强有力伎俩，其通常产生在软件开发生命周期(SDLC: Software Development Life Cycle)的构建阶段，如下所示： 现有的镜像扫描大都是依赖于镜像仓库提供的扫描性能(内置镜像扫描工具)，个别流程如下： 开发人员提交代码变更；触发一个构建流程；进行镜像构建(docker build)；镜像镜像推送(docker push);进行镜像扫描(利用镜像仓库内置扫描工具进行);进行镜像部署(docker run)。这种流程有诸多弊病： 扫描滞后镜像的扫描依赖于镜像仓库自带的镜像扫描性能，只有镜像推送至镜像仓库才会进行镜像扫描，这种滞后的扫描会导致仓库中保留有破绽的镜像。在DevSecOps中，心愿做到的是：镜像仓库中存储的是平安的、可随时部署的镜像。 不能无效的终止CI/CD流程成熟的DevSecOps CI/CD 应该是：当检测到镜像是不平安的，那么就应该立刻终止CI/CD流程，避免不平安的镜像被部署到环境中。这种依赖于镜像仓库自带扫描性能的滞后镜像扫描，没有方法做到这一点，因为镜像推送之后的扫描，和镜像的部署是同时进行的。 浪费资源镜像是要占据肯定的磁盘空间的(有些镜像大小上百M，甚至上G)，在镜像仓库中保留有大量有破绽的镜像，就会占据大量的磁盘空间，使仓库的应用成本上升。 三、镜像扫描前置基于扫描滞后的有余，镜像扫描的前置就显得尤为重要了，将镜像扫描的操作前置(如下图绿色虚线方框所示)： 让其位于镜像构建之后，镜像推送之前，这样一旦一个镜像扫描完结，如果其后果是平安的，那么就顺利进行后续的操作(推送至镜像仓库并进行镜像部署)；如果扫描后果是不平安的，那么就立刻终止该CI/CD流程，并告诉相应的人员。这样就避免了不平安镜像推送至镜像仓库。保障镜像仓库中存储的镜像都是平安的，而且节俭了磁盘空间。同时，前置扫描对镜像的操作空间会变得更大，比方能够对镜像做一些黑白名单、RBAC(Role Based Access Control)权限管制等。 对于前置的镜像扫描操作，就须要借助一些现有的镜像扫描工具来帮忙咱们实现这个操作。这些工具既有大家耳熟能详的Clair，也有一些新贵比方Anchore，Trivy等，对于这些工具的具体应用和比照，会在前期有有一篇专门的文章来剖析。 镜像扫描只是帮忙咱们，发现镜像问题，而后解决镜像问题，这只是镜像问题的医治伎俩，然而对于镜像问题，最好是要做到避免问题产生，也就是在构建镜像的时候，尽可能的依据一些最佳实际来构建一些尽量平安的镜像，这也就是咱们接下来要讲的镜像平安的一些最佳实际。这样通过预防为主，防治联合(防：依据最佳实际构建平安镜像；治：嵌入CI/CD中的前置镜像扫描)的办法来确保镜像的平安。 四、容器镜像平安最佳实际4.1 尽量抉择轻量的根底镜像每个镜像都有一个根底镜像，也就是在 Dockerfile中的 FROM 中指定的镜像，个别这个根底镜像就是一个Linux发行版，比方alpine，ubuntu等。在为一个新我的项目选取根底镜像的时候，应该思考这个我的项目的运行是否须要一个全量的操作系统(蕴含各种库)，如果说alpine就能能满足要求，就不要抉择ubuntu这个绝对宏大的操作系统，作为新我的项目的根底镜像。不同量级的操作系统，除了有镜像大小的区别，更重要的是，操作系统蕴含的文件系统越多，攻击面也就越大，蕴含的破绽也就越多。 用Anchore对 openjdk:8-jdk-alpine和openjdk:8-jdk进行扫描，结果显示openjdk:8-jdk有128个破绽，而openjdk:8-jdk-alpine却只有48个。而且openjdk:8-jdk-alpine的镜像大小仅为openjdk:8-jdk的三分之一不到。 4.2 增加非root用户，以最小受权用户运行容器容器是和宿主机共享内核的，如果以root用户启动容器，也就意味着容器是有root权限去操作宿主机，这样就使得宿主机的受攻击面增大，潜在威逼系数进步。因而，应该指定一个非root的特定用户，而后以此特定用户来启动容器。如果是通过Dockerfile的形式来构建镜像，能够在Dockerfile中增加如下代码，来增加一个位于特定group的特定用户，并以此特定用户来启动容器： FROM your_base_imageRUN groupadd -r devsecops && useradd -r -g devops devsecopsUSER devsecops......(your other dockerfile steps)4.3 不要将敏感信息暴漏在镜像中不要将token，明码，ssh key等敏感信息，存储在镜像中，一旦镜像被推送至公共镜像仓库，那么就会造成上述敏感信息的透露。后果将是灾难性的。如果在镜像中必须要用到一些敏感信息，能够采纳docker提供的secret性能，或者通过多阶段构建来实现。具体的应用能够参考docker官网。 ...

简介：【零起点入门系列教程】将会带给大家从业务视角登程由浅入深地学习用宜搭实现利用搭建。即使是没有任何代码根底的老手只有跟着系列课程，从0开始缓缓修炼，也能找到胜利搭建利用的乐趣。明天第三讲，分步教学，疾速创立一个简略的审批流程。【零起点入门系列教程】将会带给大家从业务视角登程由浅入深地学习用宜搭实现利用搭建。即使是没有任何代码根底的老手只有跟着系列课程，从0开始缓缓修炼，也能找到胜利搭建利用的乐趣。明天第三讲，创立简略的在线审批流程。 剖析表单创立在线审批流程，咱们同样依照第二讲《把一张纸单变成在线表单》的思路，首先还是剖析表单： 表单局部，出差打算须要展现差旅具体打算；须要更多的组件库审批有分支条件在线下的纸质审批里，审批周期长，找人麻烦，审批进度不通明。而通过宜搭实现业务在线化，审批实时在线解决工作，一键催办；智能抓取组织架构关系，不再须要人找人；审批进度清清楚楚。 首先应用以下组件，实现对出差单的纸单转化。 纸单组件名用处出差地<span>国家地区组件</span>组件默认单选，开启多选模式后能够抉择多个国家/地区同行人<span>成员组件</span>开启多选模式，能够抉择多个部门行程打算<span>子表单组件</span>一种高级的容器组件，能够在其外部增加多个组件，并且反复屡次其中子表单组件，须要特地阐明一下：子表单特地实用于铺排填写出差日程、教育信息，反复一组要填写的内容。 子表单只须要设置一组内容，在最终成果里，主动呈现“新增一项”，就能够插入下一组内容了。一组内容的显示能够平铺也能够表格横铺。* 平铺形式* 表格形式1. 1. 显示序号：只在PC表格形式下无效，是否显示后面的序号。 2. 主题：只在PC表格形式下无效，分为斑马纹、分割线和边框线。 3. 显示表头：只在PC表格形式下无效，是否暗藏显示表。### 剖析审批流#### ①  串行审批串行审批就是每一个审批环节的人审批通过后，才会进入到下一个环节。#### ②  条件触发流程条件审批在审批工作流中也比拟常见，设计上就是某个审批环节要由谁/或哪个角色审批，须要取决于条件判断。 例如金额低于1万元由财务总监审批通过后即完结，金额在1万元以上则由副总裁审批通过后即完结。 联合以上的内容，咱们看下出差表单，判断一下，这个属于条件审批。审批条件是7天（含），被拆分为2种条件，小于等于7天的由主管审批，大于7天的减少总经理审批。###  流程设置#### ①  审批条件#### ②  审批节点在用户提交流程或者审批人解决流程时通过一些公式校验判断用户是否能执行此操作。* 审批人类型1. 1. 固定人员 2. 角色：能够了解为具备雷同性能人员的汇合。 3. 接口人：能够了解为具备雷同性能的人员汇合，或者了解为指定一个部门对应的负者人（阐明：同一个人能够是多个部门的负责人，同一个部门也能够有多个负责人） * 审批策略1. 1. 或签：一人批准通过即可审批通过； 2. 会签：全副人都批准通过才可审批通过。 1. 1. 审批动作 配置结束之后能够点击右上角的公布，这样的流程规定就配置结束了，最初别忘记上线该利用将利用公布到钉钉工作台中，点击拜访来测试整个流程是否跑通。\>>>>点击收看视频版课程> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

Serverless是目前比拟热门的技术话题，各大云平台以及互联网大厂外部都在踊跃建设Serverless产品。本文将介绍美团Serverless产品在落地过程中的一些实践经验，其中包含技术选型的考量、零碎的具体设计、零碎稳定性优化、产品的周边生态建设以及在美团的落地状况。尽管各个公司的背景不尽相同，但总有一些能够互相借鉴的思路或办法，心愿能给大家带来一些启发或者帮忙。1 背景Serverless一词于2012年被提出，2014年因为亚马逊的AWS Lambda无服务器计算服务的衰亡，而被大家宽泛认知。Serverless通常被直译成“无服务器”，无服务器计算是能够让用户在不思考服务器的状况下构建并运行应用程序。应用无服务器计算，应用程序仍在服务器上运行，但所有服务器管理工作均由Serverless平台负责。如机器申请、代码公布、机器宕机、实例扩缩容、机房容灾等都由平台帮忙主动实现，业务开发只需思考业务逻辑的实现即可。 回顾计算行业的倒退历程，基础设施从物理机到虚拟机，再从虚拟机到容器；服务架构从传统单体利用架构到SOA架构，再从SOA架构到微服务架构。从基础设施和服务架构两条主线来看整体技术发展趋势，大家可能会发现，不论是基础设施还是服务架构，都是从大往小或者由巨到微的方向上演进，这种演变的实质准则无非是解决资源老本或者研发效率的问题。当然，Serverless也不例外，它也是用来解决这两个方面的问题： 资源利用率：Serverless产品反对疾速弹性伸缩能力，可能帮忙业务晋升资源利用率，在业务流量顶峰时，业务的计算能力、容量主动扩容，承载更多的用户申请，而在业务流量下降时，所应用的资源也会同时膨胀，防止资源节约。研发运维效率：在Serverless上开发人员个别只须要填写代码门路或者上传代码包，平台可能帮忙实现构建、部署的工作。开发人员不间接面对机器，对于机器的治理，机器是否失常以及流量高下峰的是否须要扩缩容等问题，这些通通不须要去思考，由Serverless产品帮忙研发人员去实现。这样就能使他们从繁琐的运维工作中解放出来，从DevOps转向NoOps，更加专一于业务逻辑的实现。尽管AWS在2014年就推出了第一个Serverless产品Lambda，但Serverless技术在国内的利用始终不温不火。不过近两三年，在容器、Kubernetes以及云原生等技术的推动下，Serverless技术迅速倒退，国内各大互联网公司都在踊跃建设Serverless相干产品，摸索Serverless技术的落地。在这种背景下，美团也于2019年初开始了Serverless平台的建设，外部项目名称为Nest。 截止到目前，Nest平台曾经过两年的建设，回顾整体的建设过程，次要经验了以下三个阶段： 疾速验证，落地MVP版本：咱们通过技术选型、产品与架构设计、开发迭代，疾速落地了Serverless产品的根本的能力，如构建、公布、弹性伸缩、对接触发祥、执行函数等。上线后，咱们推动了一些业务的试点接入，帮忙验证打磨产品。优化核心技术，保障业务稳定性：有了后期的试点业务验证，咱们很快发现产品的存在的一些稳定性相干的问题，次要有弹性伸缩的稳定性、冷启动的速度、零碎与业务的可用性、容器的稳定性。针对这些问题咱们对各个问题波及的技术点做了专项的优化改良。欠缺技术生态，落实收益：优化了核心技术点后，产品逐步成熟稳固，但仍然面临生态性问题，如研发工具欠缺，上下游产品没有买通、平台凋谢能力有余等问题，影响或妨碍了产品的推广应用。因而，咱们持续欠缺产品的技术生态，扫清业务接入应用阻碍，落实产品的业务收益。2 疾速验证，落地MVP版本2.1 技术选型建设Nest平台，首要解决的就是技术选型问题，Nest次要波及三个关键点的选型：演进路线、基础设施、开发语言。 2.1.1 演进路线起初Serverless服务次要蕴含FaaS（Function as a Service）和BaaS（Backend as a Service），近几年Serverless的产品畛域有所扩张，它还蕴含面向利用的Serverless服务。 FaaS：是运行在一个无状态的计算容器中的函数服务，函数通常是事件驱动、生命周期很短（甚至只有一次调用）、齐全由第三方治理的。业界相干FaaS产品有AWS的Lambda、阿里云的函数计算等。BaaS：是建设在云服务生态之上的后端服务。业界相干BaaS产品包含AWS的S3、DynamoDB等。面向利用的Serverless服务：如Knative，它提供了从代码包到镜像的构建、部署，以及弹性伸缩等全面的服务托管能力，私有云产品有Google Cloud Run（基于Knative）、阿里云的SAE（Serverless Application Engine）。 在美团外部，BaaS产品其实就是外部的中间件以及底层服务等，它们通过多年的倒退，曾经十分丰盛且成熟了。因而，在美团的Serverless产品演进次要在函数计算服务和面向利用的Serverless服务两个方向上。那到底该如何演进呢？过后次要思考到在业界FaaS函数计算服务绝对于面向利用的Serverless服务来说，更加成熟且确定。因而，咱们决定“先建设FaaS函数计算服务，再建设面向利用的Serverless服务”这样一条演进路线。 2.1.2 基础设施因为弹性伸缩是Serverless平台必备的能力，因而Serverless必然波及到底层资源的调度和治理。这也是为什么以后业界有很多开源的Serverless产品（如OpenFaaS、Fission、Nuclio、Knative等）是基于Kubernetes来实现的，因为这种选型可能充分利用Kubernetes的基础设施的治理能力。在美团外部基础设施产品是Hulk，尽管Hulk是基于Kubernetes封装后的产品，但Hulk在落地之初思考到落地难度以及各种起因，最终未依照原生的形式来应用Kubernetes，并且在容器层采纳的也是富容器模式。 在这种历史背景下，咱们在做基础设施选型时就面临两种选项：一是应用公司的Hulk来作为Nest的基础设施（非原生Kubernetes），二是采纳原生Kubernetes基础设施。咱们思考到以后业界应用原生Kubernetes是支流趋势并且应用原生Kubernetes还能充分利用Kubernetes原生能力，能够缩小反复开发。因而，最终考量的后果是咱们采纳了原生Kubernetes作为咱们的基础设施。 2.1.3 开发语言因为在云原生畛域的支流语言是Golang，并且Kubernetes的生态中，Golang是相对的主导语言。但在美团，Java才是应用最宽泛的语言，相比Golang，Java在公司外部生态比拟好。因而，在语言的选型上咱们抉择了Java语言。在Nest产品开发之初，Kubernetes社区的Java客户端还不够欠缺，但随着我的项目的推动，社区的Java客户端也逐步丰盛了起来，目前曾经齐全够用了。另外，咱们也在应用过程中，也奉献了一些Pull Request，反哺了社区。 2.2 架构设计基于以上的演进路线、基础设施、开发语言的选型，咱们进行了Nest产品的架构设计。 在整体的架构上，流量由EventTrigger（事件触发源，如Nginx、利用网关、定时工作、音讯队列、RPC调用等）触发到Nest平台，Nest平台内会依据流量的特色路由到具体函数实例，触发函数执行，而函数外部代码逻辑能够调用公司内的各个BaaS服务，最终实现函数的执行，返回后果。 在技术实现上，Nest平台应用Kubernetes作为根底底座并适当参考了一些Knative的优良设计，在其架构外部次要由以下几个外围局部组成： 事件网关：外围能力是负责对接内部事件源的流量，而后路由到函数实例上；另外，网关还负责统计各个函数的进出流量信息，为弹性伸缩模块提供伸缩决策的数据撑持。弹性伸缩：外围能力是负责函数实例的弹性伸缩，伸缩次要依据函数运行的流量数据以及实例阈值配置计算函数指标实例个数，而后借助Kubernetes的资源控制能力，调整函数实例的个数。控制器：外围能力是负责Kubernetes CRD（Custom Resource Definition）的管制逻辑实现。函数实例：函数的运行实例。当事件网关流量触发过去，会在函数实例内执行相应的函数代码逻辑。治理平台：面向用户应用的平台，负责函数的构建、版本、公布以及一些函数元信息的治理等。 2.3 流程设计在具体的CI/CD流程上，Nest又与传统的模式有何区别呢？为了阐明这个问题，咱们先来看一看在Nest平台上函数的整体生命周期怎么的？具体有以下四个阶段：构建、版本、部署、伸缩。 构建：开发的代码和配置通过构建生成镜像或可执行文件。版本：构建生成的镜像或可执行文件加上公布配置造成一个不可变的版本。部署：将版本公布，即实现部署。伸缩：依据函数实例的流量以及负载等信息，来进行实例的弹性扩缩容。就这四个阶段来看，Nest与传统的CI/CD流程本质区别在于部署和伸缩：传统的部署是感知机器的，个别是将代码包公布到确定的机器上，但Serverless是要向用户屏蔽机器的（在部署时，可能函数的实例数还是0）；另外，传统的模式个别是不具备动静扩缩容的，而Serverless则不同，Serverless平台会依据业务的本身流量须要，进行动静扩缩容。后续章节会具体解说弹性伸缩，因而这里咱们只探讨部署的设计。 部署的外围点在于如何向用户屏蔽机器？对于这个问题，咱们形象了机器，提出了分组的概念，分组是由SET（单元化架构的标识，机器上会带有该标识）、泳道（测试环境隔离标识，机器上会带有该标识）、区域（上海、北京等）三个信息组成。用户部署只需在相应的分组上进行操作，而不必波及到具体机器。可能做到这些的背地，是由Nest平台帮忙用户治理了机器资源，每次部署会依据分组信息来实时初始化相应的机器实例。 2.4 函数触发函数的执行是由事件触发的。实现函数的触发，须要实现以下四个流程： 流量引入：向事件源注册事件网关的信息，将流量引入到事件网关。如针对MQ事件源，通过注册MQ的生产组，引入MQ的流量到事件网关。流量适配：事件网关对事件源进入的流量进行适配对接。函数发现：对函数元数据（函数实例信息、配置信息等）的获取过程，相似微服务的服务发现过程。事件网关承受的事件流量须要发送到具体的函数实例，这就须要对函数进行发现。这里发现本质是获取Kubernetes中的内置资源或者CRD资源中存储的信息。函数路由：事件流量的路由过程，路由到特定的函数实例上。这里为了反对传统路由逻辑（如SET、泳道、区域路由等）以及版本路由能力，咱们采纳了多层路由，第一层路由到分组（SET、泳道、区域路由），第二层路由到具体版本。同版本内的实例，通过负载均衡器抉择出具体实例。另外，通过该版本路由，咱们很轻松的反对了金丝雀、蓝绿公布。 2.5 函数执行函数不同于传统的服务，传统的服务是个可执行的程序，但函数不同，函数是代码片段，本身是不能独自执行的。那流量触发到函数实例后，函数是如何执行的呢？ 函数的执行的首要问题是函数的运行环境：因为Nest平台是基于Kubernetes实现的，因而函数肯定是运行在Kubernetes的Pod（实例）内，Pod外部是容器，容器的外部是运行时，运行时是函数流量接管的入口，最终也是由运行时来触发函数的执行。所有看起来是那么的顺利成章，但咱们在落地时是还是遇到了一些艰难，最次要的艰难是让开发同学能够在函数内无缝的应用公司内的组件，如OCTO（服务框架）、Celler（缓存零碎）、DB等。 在美团的技术体系中，因为多年的技术积淀，很难在一个纯正的容器（没有任何其余依赖）中运行公司的业务逻辑。因为公司的容器中积淀了很多环境或服务治理等能力，如服务治理的Agent服务以及实例环境配置、网络配置等。 因而，为了业务在函数内无缝的应用公司内的组件，咱们复用公司的容器体系来升高业务编写函数的老本。但复用公司的容器体系也没那么简略，因为在公司内没有人试过这条路，Nest是公司第一个基于原生Kubernetes建设的平台，“第一个吃螃蟹的人”总会遇到一些坑。对于这些坑，咱们只能在推动过程中“逢山开路，遇水搭桥”，遇到一个解决一个。总结下来，其中最外围的是在容器的启动环节买通的CMDB等技术体系，让运行函数的容器与开发同学平时申请的机器用起来没有任何区别。 2.6 弹性伸缩弹性伸缩的外围问题次要有三个：什么时候伸缩，伸缩多少，伸缩的速度快不快？也就是伸缩机会、伸缩算法、伸缩速度的问题。 伸缩机会：依据流量Metrics实时计算函数冀望实例数，进⾏扩缩。流量的Metrics数据来自于事件网关，这里次要统计函数的并发度指标，弹性伸缩组件每秒中会被动从事件网关获取一次Metrics数据。伸缩算法：并发度/单实例阈值=冀望实例数。依据收集的Metrics数据以及业务配置的阈值，通过算法计算出冀望的实例数，而后通过Kubernetes接口设置具体实例数。整个算法看起来尽管简略，但十分稳固、鲁棒性好。伸缩速度：次要取决于冷启动工夫，在下个章节会具体解说这块内容。除了根本的扩缩容能力，咱们还反对了伸缩到0，反对配置最大、最小实例数（最小实例即预留实例）。伸缩到0的具体实现是，咱们在事件网关外部减少了激活器模块，当函数无实例时，会将函数的申请流量缓存在激活器外部，而后立刻通过流量的Metrics去驱动弹性伸缩组件进行扩容，等扩容的实例启动实现后，激活器再将缓存的申请重试到扩容的实例上触发函数执行。 3 优化核心技术，保障业务稳定性3.1 弹性伸缩优化下面提到的伸缩机会、伸缩算法、伸缩速度这三要素都是现实状况下的模型，尤其是伸缩速度，以后技术基本做不到毫秒级别的扩缩容。因而，在线上理论场景中，弹性伸缩会存在一些不合乎预期的状况，比方实例伸缩比拟频繁或者扩容来不及，导致服务不太稳固的问题。 针对实例伸缩比拟频繁问题，咱们在弹性伸缩组件内保护了统计数据的滑动窗⼝，通过计算均值来平滑指标，还通过延时缩容，实时扩容来缓解频繁扩缩问题。另外，咱们减少了基于QPS指标的伸缩策略，因为QPS指标绝对并发度指标会更加稳固。针对扩容来不及问题，咱们采取提前扩容的伎俩，当达到实例阈值的70%就扩容，可能比拟好的缓解这个问题。除此之外，咱们还反对了多指标混合伸缩（并发度、QPS、CPU、Memory），定时伸缩等策略，满足各种业务需要。下图展现的是线上弹性伸缩的实在案例（其配置的最小实例数为4，单实例阈值100，阈值使用率0.7），其中上半局部是业务每秒的申请数，下半局部是扩缩实例的决策图，能够看到在成功率100%的状况下，业务完满应答流量顶峰。 3.2 冷启动优化冷启动是指在函数调用链路中蕴含了资源调度、镜像/代码下载、启动容器、运行时初始化、用户代码初始化等环节。当冷启动实现后，函数实例就绪，后续申请就能间接被函数执行。冷启动在Serverless畛域至关重要，它的耗时决定了弹性伸缩的速度。 所谓“天下文治，无坚不破，唯快不破”，这句话在Serverless畛域也同样受用。试想如果拉起一个实例足够快，快到毫秒级别，那简直所有的函数实例都能够缩容到0，等有流量时，再扩容实例解决申请，这对于存在高下峰流量的业务将极大的节俭机器资源老本。当然，现实很饱满，事实很骨感。做到毫秒级别简直不可能。但只有冷启动工夫越来越短，老本天然就会越来越低，另外，极短的冷启动工夫对伸缩时函数的可用性以及稳定性都有莫大的益处。 冷启动优化是个循序渐进的过程，咱们对冷启动优化次要经验了三个阶段：镜像启动优化、资源池优化、外围门路优化。 镜像启动优化：咱们对镜像启动过程中的耗时环节（启动容器和运行时初始化）进行了针对性优化，次要对容器IO限速、一些非凡Agent启动耗时、启动盘与数据盘数据拷贝等关键点的优化，最终将启动过程中的零碎耗时从42s优化到12s左右。 资源池优化：镜像启动耗时优化到12s，根本曾经快达到瓶颈点，再持续优化空间不大。因而，咱们想是否绕开镜像启动的耗时环节？最终，咱们采纳了一个比较简单思路“空间换工夫”，用资源池计划：缓存一些已启动的实例，当须要扩容时，间接从资源池获取实例，绕开镜像启动容器的环节，最终成果很显著，将启动的零碎耗时从12s优化到3s。这里须要阐明的是资源池本身也是通过Kubernetes的Depolyment进行治理，池中实例被取走会立刻主动补充。 外围门路优化：在资源池优化的根底上，咱们再次精益求精，针对启动流程中的下载与解压代码两个耗时环节进行优化，过程中咱们采纳了高性能的压缩解压算法（LZ4与Zstd）以及并行下载和解压技术，成果十分好。另外，咱们还反对了通用逻辑（中间件、依赖包等）下沉，通过预加载的形式，最终将函数端到端的启动耗时优化到2s，这就意味着扩容一个函数实例只须要2s（蕴含函数启动）。如果排除掉函数本身的初始化启动耗时，平台侧的耗时已在毫秒级别。3.3 高可用保障说到高可用，对于个别的平台，指的就是平台本身的高可用，但Nest平台有所不同，Nest的高可用还蕴含托管在Nest平台上的函数。因而，Nest的高可用保障须要从平台和业务函数两个方面着手。 ...

【前言】本文介绍了Kubernetes基于Centos7构建根底环境，作者：姜新灿（同创永益架构总监）。 环境筹备 筹备一台虚拟机,本教程是以vagrant+vbox进行构建，默认用户名明码均为vagrant,上面开始设置系 统，大家也能够自行装置零碎。 一、 敞开防火墙、并设置开机不启动防火墙 二、 开启近程拜访 三、 永恒敞开selinux 批改/etc/sysconfig/selinux文件设置 四、 禁用swap替换分区 关上/etc/fstab正文掉swap 五、 装置wget 提醒Complete!则装置胜利 六、 更改零碎默认镜像源为阿里镜像源 切换到/etc/yum.repos.d/下查看以后镜像源切换到/etc/yum.repos.d/目录下创立backup文件夹，并将上述镜像源挪动到backup文件夹下拉取阿里云镜像源，看见saved则拉取胜利查看目录构造执行yum clean all清空镜像源缓存执行yum makecache从新加载缓存，看到Metadata Cache Created则加载胜利七、 查看服务器IP地址（非必须） 我集体的是在eth1下，对应的是192.168.1.40 八、 自定义服务器域名（非必须） 也能够手动批改vi /etc/hostname(须要重启) 九、 增加hosts自定义域名映射（非必须） 批改hosts配置查看hosts配置十、 同步阿里云工夫（墙裂倡议） 装置ntp，提醒Complete!则装置胜利查看以后零碎工夫、并设置以后工夫为上海设置ntp，同步阿里云工夫，执行vi /etc/ntp.conf找到server四行代码正文掉，在其上面减少server http://aliyun.com iburst，而后通过sudo systemctl start ntpd启动服务，稍等一会执行ntpq -p查看是否同步，如果呈现后面的*则，同步 胜利 systemctl start ntpd 启动ntp systemctl restart ntpd 重启ntp systemctl enable ntpd.service 开机启动 ntpdc -c loopinfo 查看与工夫同步服务器的时间差 十一、 降级内核

作者 | 杨丽起源 | 雷锋网（ID：leiphone-sz） Serverless 其实离咱们并没有那么边远。如果你是一名互联网研发人员，那么极有可能理解并利用过 Serverless 这套技术体系。纵观 Serverless 过来十年，它其实因云而生，也在同时扭转云的计算形式。如果套用技术成熟度曲线来形容的话，那么它曾经走过了萌芽期、认知幻灭期，开始朝着成熟稳固的方向倒退。将来，市场对 Serverless 的接受程度将越来越高。 不要诧异，阿里云团队在真正开始构建 Serverless 产品体系的最开始的一两年里，也曾遭逢外部的一些争议。而今，单从阿里团体外部的很多业务线来看，曾经在朝着 Serverless 化的方向倒退了。 日前，阿里云凭借函数计算产品能力寰球第一的劣势，入选 Forrester 2021 年第一季度 FaaS 平台评估报告，成为比肩亚马逊成为寰球前三的 FaaS 领导者。这也是首次有国内科技公司进入 FaaS 领导者象限。 在与雷锋网的访谈中，阿里云 Serverless 负责人不瞋阐释了 Serverless 的演进历程、引入 Serverless 面临的难点与挑战、以及无关云原生的趋势预判。 “肯定要想明确做这件事的终局是什么，包含产品体系的定位，对开发者、对服务商的价值等等这些问题。这要求咱们一直通过实际和意识的深入，让这些问题的答复可能逐步清晰起来。这也是咱们这么多年实际积攒的贵重教训。”不瞋指出。 只管企业的实际还存在种种纳闷和挑战，但 Serverless 实际上离咱们并没有那么边远。举一个最近的例子，新冠疫情让近程办公、在线教育、在线游戏的利用需要短期内减少。业务规模的爆发式增长，对每一个需要的响应须要更加及时，这对利用架构的弹性，对底层计算的速度，对研发效率的晋升等，都要求业务减速向新技术架构演进。 而不瞋的现实就是，帮忙更宽泛的客户实现向新技术架构的平滑迁徙，让 Serverless 渗透到所有的云利用中。 不瞋作为阿里云 Serverless 产品体系的负责人，也是国内 Serverless 的晚期实践者。以下将出现是对这次访谈的残缺总结。 Serverless 的定义在探讨之前，咱们先明确 Serverless 的定义，确保大家对 Serverless 的认知是统一的。 当初 Serverless 越来越热，无论是工业界还是学术界，都将 Serverless 视为云计算倒退的下一阶段。Serverless 有很多种表述，其中伯克利大学的定义绝对谨严一些。 注：2019 年 2 月，加州大学伯克利分校发表的《Cloud Programming Simplified: A Berkerley View on Serverless Computing》论文，曾在业界引发诸多探讨和关注。大抵来讲，Serverless 理论对应的是一整套的产品体系，而不是独自一两个产品；同时，这些产品/服务之间还具备以下特色：服务之间彼此配合、全托管、用户通过 API 调用就可实现整个性能或利用的开发而无需关注底层基础设施。 ...

起源 | 阿里巴巴云原生公众号 敬爱的各位开发者，大家好： 当你写下“Hello World”的那一刻，一个 0 与 1 交错的精彩世界给出了邀请函。年青的你跳上了世界的肩膀看到了将来的模样，沿途的灯塔都是如此迷人，未知的雨林更是万物成长。登程吗？就当初！第一站？@2050！ 2050，是王坚博士发动的一场属于寰球年青人的科技团圆 Party，这里平等自在、翻新凋谢、生动有趣、暮气沉沉！ 王坚博士说，没有年青人，就不会有阿里云。年青人心中的将来肯定就是世界的将来。2050 是年青人的热带雨林，万物皆可成长。 王坚人称“博士”，他是阿里巴巴团体技术委员会主席，阿里云创始人，云栖小镇及雪浪小镇创立者、城市大脑发起人……放下这些光环，现在他是 2050 大会的第一位志愿者。 2050 – 年青人因科技而团圆，已于 2019 年隆重揭幕，往年将于 4 月 23 - 25 日在杭州 · 云栖小镇举办 2050@2020&2021（去年和往年一并举办）。如何在云栖小镇 HIGH 三天？2050有十大容器出现大家发明进去的各种流动。 青年团圆——年青就要最认真见面 新生论坛——年青就要最大声分享 摸索空间——年青就要最靠近挑战 热带雨林——每个年青人都是新物种 星空露营——享受俯视星空 青春舞台——科技就像音乐 思维约会——分享工夫是真挚 热力静止——年青生机的散发 留鸟打算——致力让年青人见上另一位年青人 2050 青年——致敬为 2050 付出致力的年青人 会场路线图 住宿攻略 获取 PASS 门票：_https://getmypass.2050.org.cn...自愿者指南详情：_https://2050.org.cn/survival/...如果你刚好也会前来参加本次的 2050 大会， 请记得，来阿里巴巴云原生发动的“云原生开源团圆”，一起来畅聊云原生开源合作中所遇到的困惑和挑战。 云原生，为云而生，构筑数字世界新将来，正在帮忙千万企业打造出反对海量业务的技术根基。开源，自诞生以来曾经扭转了技术革新的产生和合作形式，也在继续改写软件商业生态的游戏规则。开源减速云原生化，有数社区开发者在其中汇聚成了一股重要推动力。 云原生 Kubernetes 已成为相对支流，落地中你遇到哪些困惑和挑战？你感觉 2050年的开源将是什么样子？云原生和开源又将会碰撞出什么火花？敬爱的正在扭转世界的你，窥探将来的明码或者就藏在这次云原生开源团圆中，咱们邀请你说出你的故事～ 咱们团圆的具体工夫是 4 月 23 号下午 2 点开始，地址：2050 · 博悟馆 4 层。 ...

Redash商业版减少容器报表性能，极大地丰盛了报表内容和模式。 容器报表应用形式是，在报表编辑界面咱们能够增加容器报表，容器报表只能抉择已公布的报表能力实现增加，增加实现后则该容器是否已公布不影响应用。根本设置中能够设置容器的题目，外部部件的间距，部件圆角弧度等，能够暗藏报表的筛选区或部件的另存菜单。同时容器反对多报表性能，最多能够增加6张报表进行切换。 容器设置 容器报表应用常见用处是，报表中可能有一组或者多组视图属于同一系列，为了更好的划分报表内容的区域和栏目，咱们能够应用容器报表。 容器报表中的参数能够作为该容器的部件参数，影响该容器内一个或者多个视图，这样既能够做到不同部件之间参数互不烦扰，又能够达到雷同参数管制多个选定视图的目标。 容器报表案例

近日，国内当先的数字化钻研与咨询机构爱剖析公布了《2021爱剖析 · 产业数字化厂商全景报告》（以下简称报告），BoCloud博云作为国内 PaaS 及 CMP 畛域翻新赛道的领跑者，凭借成熟的解决方案和丰盛的实践经验，胜利入选银行数字化、证券数字化及IT 基础设施与云服务三大利用场景的代表厂商名单。 报告中指出，数字化转型是一个简单的过程，须要技术与业务场景深度交融，随着政府与企业对于数字化转型的一直深入，国内将涌现一批优良的数字化厂商服务于甲方用户。爱剖析基于对国内产业数字化厂商的调研，精确定义了 29 个产业数字化利用场景，涵盖金融等泛滥畛域，绘制出中国的产业数字化利用全景地图，遴选出在这些数字化利用场景中具备成熟解决方案和落地能力的厂商，为具备数字化转型需要或正在进行数字化建设的甲方企业，提供中立的选型倡议。 场景一：银行数字化 报告指出，数字化时代下，利用交付、IT运维等是银行业 IT 团队的外围业务，银行业金融机构迫切需要构建撑持这些外围业务的麻利中台体系，晋升 IT团队的业务撑持能力。 博云以麻利化利用治理为外围的 PaaS 产品体系，通过将容器云、微服务平台和 DevOps平台深度整合与集成，提供企业应用一站式全生命周期治理能力，能够减速利用疾速迭代、晋升利用交付效力、促成团队麻利化转型、推动银行业务翻新。 例如，作为国内某大型股份制商业银行分布式外围金融云平台建设的实施者，博云通过帮忙该行构建基于轻量级容器技术的 DevOps 分布式外围平台，为银行业务互联网化提供 IT 撑持，实现我的项目研发迭代缩短到周期，零碎疾速弹性伸缩能力可承当 10 亿级高并发场景，无效晋升零碎响应速度和吞吐量，分布式架构解决利用容量瓶颈，硬件老本缩小 85%，零碎每年节约 90% 保护老本。 场景二：证券数字化 报告指出，国内证券行业数字化利用程度较低，因而买通数据，并联合业务场景，进步业务效率是证券行业亟待解决的问题。 博云打造了基于 PaaS 平台的证券行业解决方案，从基础设施转型、开发运维一体化转型、敏态利用架构转型三个维度，解决证券业机构业务需要疾速响应、大规模团队并行研发、运维撑持高效智能的需要，实现企业从技术到业务的数字化、智能化和麻利化转型。目前，博云已为国内证券行业 TOP10 中的 6 家，TOP20 中的 9 家证券机构提供了数字化转型解决方案。 场景三：IT基础设施和云服务 报告指出，企业想在新形势下获取业务增长的新动能，亟需通过采纳云服务重塑企业业务流程和模式，这导致企业上云需要大幅减少。 目前，是否上云曾经不再是问题，如何上云才是亟待解决的问题，多云策略已成为企业上云的必然选择，然而异构云服务使得企业云环境的复杂化成为不可漠视的趋势。 博云通过以多云治理 CMP 为外围的资源管理产品体系，解决企业多云环境和异构 IT 资源的对立治理，以业务和治理维度提供对多云资源的精密经营和运维监控，优化云收入，升高云老本，使企业能够更多关注本身业务倒退。 在“十四五”布局的疏导和推动下，我国产业数字化畛域将迎来高速倒退。作为企业IT数字化转型的同行者，博云将以市场当先的咨询服务、产品技术和成熟案例劣势，继续助力数字技术与产业场景的交融和重构，助力企业在数字经济时代怀才不遇。

简介： 在《一文读懂 K8s 长久化存储流程》一文咱们重点介绍了 K8s 外部的存储流程，以及 PV、PVC、StorageClass、Kubelet 等之间的调用关系。接下来本文将将重点放在 CSI（Container Storage Interface）容器存储接口上，探索什么是 CSI 及其外部工作原理。头图.png 作者 | 惠志起源 | 阿里巴巴云原生公众号 导读：在《一文读懂 K8s 长久化存储流程》一文咱们重点介绍了 K8s 外部的存储流程，以及 PV、PVC、StorageClass、Kubelet 等之间的调用关系。接下来本文将将重点放在 CSI（Container Storage Interface）容器存储接口上，探索什么是 CSI 及其外部工作原理。背景K8s 原生反对一些存储类型的 PV，如 iSCSI、NFS、CephFS 等等（详见链接），这些 in-tree 类型的存储代码放在 Kubernetes 代码仓库中。这里带来的问题是 K8s 代码与三方存储厂商的代码强耦合： 更改 in-tree 类型的存储代码，用户必须更新 K8s 组件，老本较高in-tree 存储代码中的 bug 会引发 K8s 组件不稳固K8s 社区须要负责保护及测试 in-tree 类型的存储性能in-tree 存储插件享有与 K8s 外围组件等同的特权，存在安全隐患三方存储开发者必须遵循 K8s 社区的规定开发 in-tree 类型存储代码CSI 容器存储接口标准的呈现解决了上述问题，将三方存储代码与 K8s 代码解耦，使得三方存储厂商研发人员只需实现 CSI 接口（无需关注容器平台是 K8s 还是 Swarm 等）。 ...

简介：4月17日杭州，云原生基金会CNCF和阿里巴巴联结主办的「KubeMeet 开发者沙龙·云原生利用治理专场」来啦！这里有Kubernetes 生态开发者都在关注的开源我的项目，以及阿里巴巴、携程、第四范式的一线云原生落地实际。连忙报名吧！ KubeMeet是由云原生基金会 CNCF 与阿里巴巴联结主办的、面向一线开发者的技术交流活动，内容聚焦云原生&Kubernetes方向，旨在通过热门的开源技术、云原生在企业的利用实际案例、架构设计思维等，帮忙开发者学习云原生技术、交换实际中的问题和痛点，推动云原生和Kubernetes在国内的规模化利用落地。 随同着 Kubernetes 生态逐步完善，越来越多的大型互联网终端企业开始退出到云原生梯队中，云原生利用治理与交付正在成为 Kubernetes 之上重要的价值聚焦点。4月17日，KubeMeet 将来到杭州，分享云原生规范利用模型技术上的落地与思考、云原生利用部署开源实际等话题，帮忙开发者应答云原生利用治理痛点。 流动工夫 & 地点 流动工夫：2021年4月17日 13:30-17:00 流动地点：杭州·乐佳国内大厦1-3-7 特洛伊星 （杭州市余杭区良睦路999号） 流动工夫 & 地点 报名形式：https://www.huodongxing.com/event/8591638698100 讲师介绍王仁达（花名: 封崇） 阿里云高级技术专家，次要负责云原生利用治理和云资源管理相干工作，致力于晋升客户上云效率，推动云原生利用治理实现自研、开源、商用三位一体技术对立。 马浩 第四范式-机器学习平台资深工程师 , 专一机器学习平台利用,模型,workflow,metadata等组件和模块的构建和优化。 王思宇（花名：酒祝） 阿里云技术专家、OpenKruise 作者&负责人，Kubernetes/OAM 社区贡献者，长期从事云原生、容器、调度等畛域研发；阿里巴巴百万容器调度系统核心研发成员，多年撑持阿里双十一超大规模容器集群教训。 施燕 携程 资深软件工程师，现就职于携程技术保障核心PaaS 团队，资深软件工程师，携程云原生公布架构师。先后负责 K8s 容器平台的研发和优化工作（存储、调度）、资源利用率晋升、弹性扩缩容，实现以 K8s 为核心的云原生 PaaS 平台的研发。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

作者 | 惠志起源 | 阿里巴巴云原生公众号 导读：在《一文读懂 K8s 长久化存储流程》一文咱们重点介绍了 K8s 外部的存储流程，以及 PV、PVC、StorageClass、Kubelet 等之间的调用关系。接下来本文将将重点放在 CSI（Container Storage Interface）容器存储接口上，探索什么是 CSI 及其外部工作原理。背景K8s 原生反对一些存储类型的 PV，如 iSCSI、NFS、CephFS 等等（详见链接），这些 in-tree 类型的存储代码放在 Kubernetes 代码仓库中。这里带来的问题是 K8s 代码与三方存储厂商的代码强耦合： 更改 in-tree 类型的存储代码，用户必须更新 K8s 组件，老本较高in-tree 存储代码中的 bug 会引发 K8s 组件不稳固K8s 社区须要负责保护及测试 in-tree 类型的存储性能in-tree 存储插件享有与 K8s 外围组件等同的特权，存在安全隐患三方存储开发者必须遵循 K8s 社区的规定开发 in-tree 类型存储代码CSI 容器存储接口标准的呈现解决了上述问题，将三方存储代码与 K8s 代码解耦，使得三方存储厂商研发人员只需实现 CSI 接口（无需关注容器平台是 K8s 还是 Swarm 等）。 CSI 外围流程介绍在具体介绍 CSI 组件及其接口之前，咱们先对 K8s 中 CSI 存储流程进行一个介绍。《一文读懂 K8s 长久化存储流程》一文介绍了 K8s 中的 Pod 在挂载存储卷时需经验三个的阶段：Provision/Delete（创盘/删盘）、Attach/Detach（挂接/摘除）和 Mount/Unmount（挂载/卸载），上面以图文的形式解说 K8s 在这三个阶段应用 CSI 的流程。 ...

简介：Knative 提供了基于流量的主动扩缩容能力，能够依据利用的申请量，在顶峰时主动扩容实例数；当申请量减少当前，主动缩容实例，做到自动化地节俭资源老本。此外，Knative 还提供了基于流量的灰度公布能力，能够将流量的百分比进行灰度公布。 作者 | 李鹏（元毅） 起源 | Serverless 公众号 一、KnativeKnative 提供了基于流量的主动扩缩容能力，能够依据利用的申请量，在顶峰时主动扩容实例数；当申请量减少当前，主动缩容实例，做到自动化地节俭资源老本。此外，Knative 还提供了基于流量的灰度公布能力，能够将流量的百分比进行灰度公布。 在介绍 Knative 灰度公布和主动弹性之前，先带大家理解一下 ASK Knative 中的流量申请机制。 如上图所示，整体的流量申请机制分为以下局部： 左侧是 Knative Service 的版本信息，能够对流量设置百分比；上面是路由策略，在路由策略里，通过 Ingress controller 将相应的路由规定设置到阿里云 SLB；右侧是对应创立的服务版本 Revision，在版本里对应有 Deployment 的资源，当流量通过 SLB 进来之后，间接依据相应的转发规定，转到后端服务器 Pod 上。除了流量申请机制外，上图还展现了相应的弹性策略，如 KPA、HPA 等。 二、Service 生命周期Service 是间接面向开发者操作的资源对象，蕴含两局部的资源：Route 和 Configuration。 如上图所示，用户能够通过配置 Configuration 外面的信息，设置相应的镜像、内容以及环境变量信息。 1. Configuration Configuration 是： 治理容器冀望的状态；相似版本控制器，每次更新 Configuration 都会创立新的版本（Revision）。如上图所示，与 Knative Service 相比拟，Configuration 和它的配置很靠近，Configuration 里配置的就是容器冀望的资源信息。 2. Route Route 能够： 管制流量散发到不同的版本（Revision）；反对依照百分比进行流量散发。如上图所示，一个 Route 资源，上面包含一个 traffic 信息，traffic 外面能够设置对应的版本和每个版本对应的流量比例。 ...

转自@twt社区，作者：谢文博。 优化首先须要建设起一个指标，到底优化要达到一个什么样的指标，冀望满足什么样的需要，解决业务减少过程中产生的什么问题。监控平台的建设是为Kubernetes集群及运行的业务零碎得出零碎的真实性能，有了现有零碎以后的真实性能就能够设定正当的优化指标，根本基线指标能力正当评估以后Kubernetes容器及业务零碎的性能。本文介绍了如何建设无效的监控平台。 1. 监控平台建设 所有的优化指标都是建设在对系统的充沛理解上的，惯例基于Kubernetes的监控计划有以下大略有３种，咱们就采纳比拟支流的计划，也升高部署老本和前期集成复杂度。 支流也是咱们选取的计划是Prometheus +Grafana +cAdvisor +(要部署：Prometheus-operator, met-ric-server)，通过Prometheus提供相干数据，Prometheus定期获取数据并用Grafana展现，异样告警应用AlertManager进行告警。理论部署过程中施行也能够思考应用Kube-prometheus我的项目（参见正文1）整体部署节俭大量工作，以下是官网架构图，波及到组件如下: Prometheus OperatorPrometheusAlertmanagerPrometheus node-exporterPrometheus Adapter for KubernetesMetrics APIskube-state-metricsGrafana 上图中的Service和ServiceMonitor都是Kubernetes的资源，一个ServiceMonitor能够通过labelSelector的形式去匹配一类Service，Prometheus也能够通过labelSelector去匹配多个ServiceMonitor。 次要监控范畴分为：资源监控，性能监控，工作监控，事件告警监控等，因为本篇次要讲的是性能优化，所以侧重点放在性能监控上，然而优化是全方位的工作所以也会波及到资源，衰弱度，事件，日志等，另外就针对每种监控类型的告警治理。 *正文1：我的项目地址如下，就部署形式可参见我的项目介绍在此就不赘述：https://github.com/coreos/kube-prometheus2.数据采集 各维度的数据采集次要通过以下形式： 部署cAdvisor（参见正文2）采集容器相干的性能指标数据，并通过metrics接口用Prometheus抓取;也可依据需要可将各种监控，日志采集的Agent部署在独立的容器中，追随Pod 中的容器一起启动监督采集各种数据，具体可依据理论需要；通过Prometheus-node-exporter采集主机的性能指标数据，并通过裸露的metrics接口用Prometheus抓取通过exporter采集利用的网络性能(Http、Tcp等)数据，并通过裸露的metrics接口用Prometheus抓取通过kube-state-metrics采集k8S资源对象的状态指标数据，并通过裸露的metrics接口用Prometheus抓取通过etcd、kubelet、kube-apiserver、kube-controller-manager、kube-scheduler本身裸露的metrics获取节点上与k8S集群相干的一些特色指标数据。*正文2：node-exporter：负责采集主机的信息和操作系统的信息，以容器的形式运行在监控主机上。cAdvisor：负责采集容器的信息，以容器的形式运行在监控主机上。3. 资源监控說明 资源监控次要分为这几大类：如：CPU，内存，网络，磁盘等信息的监控（其它还有对GPU等监控），另外就是对各种组件服务的资源应用状况，自定义告警阈值等（简略的告警获能够沿用外部已有的，简单的告警指标需本人依据集群和业务特色通过获取参数进行计算或撰写PromQL获取），建设全方位的监控指标（次要监控指标项可参见Kube-prometheus部署后的相干信息，在此就不赘述），次要监控项如下； 容器 CPU，Mem，Disk, Network等资源占用等状况；Node、Pod相干的性能指标数据；容器内过程本人被动裸露的各项指标数据；各个组件的性能指标波及组件如：ECTD,API Server, Controller Manager, Scheduler, Kubelet等；4. 次要指标监控 次要的监控指标，是根据Google提出的四个指标：提早（Latency）、流量（Traffic）、谬误数（Errors）、饱和度（Saturation）。实际操作中能够应用USE或RED（详见正文3和4）办法作为掂量办法，USE用于资源，RED用于服务，它们在不同的监控场景有不同维度形容，相结合可能形容大部分监控场景指标，正当的应用以下监控指标，有助用户判断以后K8S集群的理论运行状况，可依据指标变动重复优化各个参数和服务，使其达到更加的状态，更具体的监控指标信息，可参见Kube-prometheus相干监控信息。 4.1 Cadvisor指标采集 cAdvisor（详见参考1）提供的Container指标最终是底层Linux cgroup提供的。就像Node指标一样，然而咱们最关怀的是CPU/内存/网络/磁盘。 1．CPU（利用率） 对于Container CPU利用率，K8S提供了每个容器的多个指标： .#过来10秒容器CPU的均匀负载 container_cpu_load_average_10s .#累计用户耗费CPU工夫（即不在内核中破费的工夫） container_cpu_user_seconds_total .#累计零碎CPU耗费的工夫（即在内核中破费的工夫） container_cpu_system_seconds_total .#累计CPU耗费工夫 container_cpu_usage_seconds_total .#容器的CPU份额 container_spec_cpu_quota .#容器的CPU配额 container_spec_cpu_shares .#查问展现每个容器正在应用的CPU sum（ rate（container_cpu_usage_seconds_total [5m]）） by（container_name） .# 过来10秒内容器CPU的均匀负载值 container_cpu_load_average_10s{container="",id="/",image="",name="",namespace="",pod=""} .#累计零碎CPU耗费工夫 sum(rate(container_cpu_usage_seconds_total{name=~".+"}[1m])) by (name) * 100 ...

作者| 李鹏（元毅）起源 | 阿里巴巴云原生公众号 KnativeKnative 提供了基于流量的主动扩缩容能力，能够依据利用的申请量，在顶峰时主动扩容实例数；当申请量减少当前，主动缩容实例，做到自动化地节俭资源老本。此外，Knative 还提供了基于流量的灰度公布能力，能够将流量的百分比进行灰度公布。 在介绍 Knative 灰度公布和主动弹性之前，先带大家理解一下 ASK Knative 中的流量申请机制。 如上图所示，整体的流量申请机制分为以下局部： 左侧是 Knative Service 的版本信息，能够对流量设置百分比；上面是路由策略，在路由策略里，通过 Ingress controller 将相应的路由规定设置到阿里云 SLB；右侧是对应创立的服务版本 Revision，在版本里对应有 Deployment 的资源，当流量通过 SLB 进来之后，间接依据相应的转发规定，转到后端服务器 Pod 上。除了流量申请机制外，上图还展现了相应的弹性策略，如 KPA、HPA 等。 Service 生命周期Service 是间接面向开发者操作的资源对象，蕴含两局部的资源：Route 和 Configuration。 如上图所示，用户能够通过配置 Configuration 外面的信息，设置相应的镜像、内容以及环境变量信息。 1. Configuration Configuration 是： 治理容器冀望的状态；相似版本控制器，每次更新 Configuration 都会创立新的版本（Revision）。如上图所示，与 Knative Service 相比拟，Configuration 和它的配置很靠近，Configuration 里配置的就是容器冀望的资源信息。 2. Route Route 能够： 管制流量散发到不同的版本（Revision）；反对依照百分比进行流量散发。如上图所示，一个 Route 资源，上面包含一个 traffic 信息，traffic 外面能够设置对应的版本和每个版本对应的流量比例。 3. Revision 一个 Configuration 的快照；版本追踪、回滚。Knative Service 中版本治理的资源：Revision，它是 Configuration 的快照，每次更新 Configuration 就会创立一个新的 Revision，能够通过 Revision 实现版本追踪、灰度公布以及回滚。在 Revision 资源外面，能够间接地看到配置的镜像信息。 ...

作者 |陈博起源 | 阿里巴巴云原生公众号 近日阿里巴巴开源了其云原生容器镜像减速技术，它推出的 overlaybd 镜像格局，相比于传统的分层 tar 包文件格式，实现了基于网络的按需读取，从而使得容器能够疾速启动。 该技术计划本来是阿里云外部 DADI 我的项目的一部分， DADI 是 Data Accelerator for Disaggregated Infrastructure 的缩写，旨在为计算存储拆散架构提供各种可能的数据拜访减速技术。镜像减速是 DADI 架构在容器及云原生畛域的一次突破性尝试，该技术自 2019 年投产以来，已在线上部署了大量机器，累计启动容器次数超过 10 亿，反对了阿里巴巴团体及阿里云的多个业务线，极大进步了利用的公布和扩容效率。2020 年，团队在国内顶级会议发表了论文"DADI: Block-Level Image Service for Agile and Elastic Application Deployment. USENIX ATC'20"[1]，并随后启动了开源我的项目，打算将技术该奉献给社区，通过建设规范并打造生态，吸引更多的开发者投入到容器及云原生性能优化这个畛域上来。 背景简介随着 Kubernetes 和云原生的大暴发，容器在企业外部的大规模利用曾经越来越宽泛。部署启动快是容器的外围劣势之一，这个启动快是指本地镜像实例化的工夫十分短，即“热启动”工夫短。然而对于“冷启动”，即在本地无镜像的状况下，须要先从 Registry 下载镜像能力创立容器。业务的镜像通过长期保护和更新，无论是镜像层数还是整体大小都会达到一个较大的量级，比方可能达到数百 MB 或者几个 GB。因而生产环境中，容器的冷启动往往耗时数分钟，并且随规模扩大会导致 Registry 因集群内网络拥挤而无奈疾速地下载镜像。 例如，在之前某年的双十一流动中，阿里外部一个利用因为容量有余触发紧急扩容，但因并发量过大，整体扩容耗时较长，这期间对局部用户的应用体验造成了影响。而到了 2019 年，随着 DADI 的部署上线，新镜像格局的容器在“镜像拉取+容器启动”上消耗的总工夫比一般容器缩短了 5 倍，且 p99 长尾工夫更是比后者快了 17 倍。 如何解决存储在远端的镜像数据，这是解决容器冷启动慢这个问题的外围点。历史上业界对这一问题做出的尝试有：应用块存储或者NAS保留容器镜像，实现按需读取；应用基于网络的散发技术（如 p2p），将镜像从多个源头下载、或者提前预热到主机上，避免出现网络单点瓶颈。近年来，针对新镜像格局的探讨也逐步被提上议题，依据 Harter 等人的钻研表明，拉取镜像占用了容器启动工夫的 76%，而只有 6.4% 的工夫用来读取数据。因而，反对 On-demand Read 技术的镜像，曾经成为默认的潮流风向。Google 提出的 stargz 格局，其全称是 Seekable tar.gz，顾名思义，能够有选择地从存档中搜查并提取特定的文件，无需扫描或者解压整个镜像。stargz 旨在进步镜像拉取的性能，其提早拉取技术（lazy-pull）不会拉取整个镜像文件，实现了按需读取。为了进一步提高运行时效率，stargz 又推出了一个 containerd 的 snapshotter 插件，在存储层面对 I/O 做了进一步优化。 ...

简介：一起由离线包重构引起的“白屏”期待景象的排查和解决案例 ——本文选自《阿里云SRE技术期刊》2021年02月刊 挪动端的混合架构模式给 App 开发带来了簇新的空间，通过 H5 构建的业务模块能够实现高效疾速的版本迭代，满足多样化的业务需要。为了补救 H5 技术的局部性能有余，mPaaS 客户端框架为开发者提供了“离线”机制。 开发者在接入 mPaaS H5 容器后，配合 mPaaS 挪动公布服务，能够让客户端不便地从本地加载 H5 业务包，极大地晋升了 H5 利用的加载效率。须要留神的是，这套离线机制的接入过程必须要严格依照文档来进行，一些轻微的谬误可能导致离线机制失败，给 H5 利用的加载性能带来影响。 这篇文章将和大家分享一起由离线包重构引起的“白屏”期待景象的排查和解决案例。 1. 问题背景咱们（阿里云金融线 SRE 团队）接到客户的反馈：开发者对所有线上离线包进行了一轮的整合和重构，发版后发现 H5 利用的加载性能呈现较大的进化：在网络好的状况下会有一个短暂的“白屏”等待时间，在网络较差的状况下，甚至齐全无奈实现页面的加载。更具体的信息包含： 1) 前一天早晨在生产环境进行离线包版本更新，发现公布白名单内的用户拜访离线包呈现性能进化 2) iOS 和 Android 双端均存在这个问题 3) 白名单内共有 20 多个外部用户，非内部用户，对外业务没有理论影响 4) 非白名单内用户拜访的还是老版本的离线包，没有呈现问题 5) 开发侧的变更内容包含： a) 全量离线包更新，更新数量大略是60个左右 b) 旧离线包的架构是 1 个公共资源包 + N 个一般资源包 c) 新离线包的架构是 3 个公共资源包 + N 个一般资源包 2. 剖析与排查依据症状 “网络好的状况下会有一个短暂的“白屏”等待时间，网络较差的状况下，甚至齐全无奈实现页面的加载”，咱们首先狐疑的是离线包的“离线”机制失败了，流量 fallback 到了线上资源。揣测“白屏”等待时间是 Web 资源网络下载和加载慢导致的，如下图所示： 要验证这个揣测，咱们须要通过抓取 HTTP 层面的报文来确认这个问题，抓包办法可参考文后材料理解详情[1]。从网络包中咱们察看到，每次关上 H5 利用，均存在不同水平的资源文件拉取行为，这些 Web 资源大的有几十 MB，通过网络加载速度较慢，如下图所示： ...

作者 | 悟鹏起源 | 阿里巴巴云原生公众号 《Kubernetes 稳定性保障手册》系列文章： Kubernetes 稳定性保障手册 -- 极简版Kubernetes 稳定性保障手册 -- 日志专题Kubernetes 稳定性保障手册 -- 可观测性专题（本文）随同大家对稳定性器重水平的一直晋升、社区可观测性我的项目的炽热，可观测性成为了一个很热门的话题，站在不同的角度会产生不同的了解。 咱们从软件开发的生命周期登程，尝试造成对可观测性的一个宏观了解，并从 SRE 和 Serverless 两个角度具化可观测性的了解以及实际。 目标加强认知，通过全局把握来晋升竞争力通过正当的设计和实际，为将来带来可能性指标针对可观测性的了解达成统一针对可观测性的倒退方向达成统一什么是可观测性？从 wikipedia: Observability 可了解到 可观测性 的定义： In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.Consider a physical system modeled in state-space representation. A system is said to be observable if, for any possible evolution of state and control vectors, the current state can be estimated using only the information from outputs (physically, this generally corresponds to information obtained by sensors). In other words, one can determine the behavior of the entire system from the system's outputs. On the other hand, if the system is not observable, there are state trajectories that are not distinguishable by only measuring the outputs. ...

背景应用sealos+NFS部署一个带有长久化存储的k8s1.18.17，并在其之上部署kubesphere。 sealos 简介https://github.com/fanux/sealos一条命令离线装置kubernetes，超全版本，反对国产化，生产环境中稳如老狗，99年证书，0依赖，去haproxy keepalived，v1.20反对containerd！ NFS 简介没啥好说的 kubesphere 简介https://kubesphere.com.cn/KubeSphere 是在 Kubernetes 之上构建的面向云原生利用的分布式操作系统，齐全开源，反对多云与多集群治理，提供全栈的 IT 自动化运维能力，简化企业的 DevOps 工作流。它的架构能够十分不便地使第三方利用与云原生生态组件进行即插即用 (plug-and-play) 的集成。 作为全栈的多租户容器平台，KubeSphere 提供了运维敌对的向导式操作界面，帮忙企业疾速构建一个弱小和功能丰富的容器云平台。KubeSphere 为用户提供构建企业级 Kubernetes 环境所需的多项性能，例如多云与多集群治理、Kubernetes 资源管理、DevOps、利用生命周期治理、微服务治理（服务网格）、日志查问与收集、服务与网络、多租户治理、监控告警、事件与审计查问、存储管理、拜访权限管制、GPU 反对、网络策略、镜像仓库治理以及平安治理等。 总之是kubernetes图形界面就是了。 应用sealos部署k8s1.18.17筹备3个master节点，N个node节点。零碎初始化不讲了，工夫要同步，/var/lib/docker倡议独自挂盘，主机名记得批改，上面简略介绍下怎么批量批改主机名。 Ansible批改主机名首先编辑 hosts，将你想要设置的主机名写在ip前面 [m]172.26.140.151 hostname=k8sm1172.26.140.145 hostname=k8sm2172.26.140.216 hostname=k8sm3[n]172.26.140.202 hostname=k8sn1172.26.140.185 hostname=k8sn2172.26.140.156 hostname=k8sn3剧本如下 ---- hosts: n gather_facts: no tasks: - name: change name raw: "echo {{hostname|quote}} > /etc/hostname" - name: shell: hostname {{hostname|quote}}运行 ansible-playbook main.yaml装置k8ssealos init --passwd '123456' --master 172.26.140.151 --master 172.26.140.145 --master 172.26.140.216 --node 172.26.140.202 --node 172.26.140.185 --user root --pkg-url /root/kube1.18.17.tar.gz --version v1.18.17过个几分钟就会输入： ...

作者 | 肖长军（穹谷）起源 | 阿里巴巴云原生公众号 混沌工程随着云原生的倒退逐步进入大家的视线，通过混沌工程能够很好地发现和解决在云原生化过程中的高可用问题。阿里巴巴在 2019 年开源了底层的混沌工程工具 - chaosblade，今年年初再次开源混沌工程控制台 chaosblade-box，ChaosBlade 品牌进一步降级。本文次要围绕云原生面临的高可用挑战和混沌工程时机，具体介绍开源控制台的设计、个性和实际和将来布局，旨在帮忙企业更好的理解控制台并通过其来实现混沌工程落地，解决云原生零碎下高可用问题。 去年年底 AWS 和 Google 都呈现了比较严重的服务故障：AWS 故障是因为解决数据流服务 kinesis 呈现问题，导致很多云服务不可用；Google 故障是因为登录服务的扩容配额问题导致多服务不可用。从中能够发现，他们都存在因服务依赖不合理，导致一个服务故障影响多个服务不可用，短少应急预案，整个故障复原工夫比拟长，监控告警零碎不欠缺等问题，Google 故障产生几十分钟后才感知故障的产生，AWS 的 CloudWatch 处于不可用的状态。故障不可避免，所有的所有时时刻刻存在着失败的危险。 尤其随着麻利开发、DevOps、微服务、云原生架构和治理的呈现，利用的交付能力大大晋升，但零碎的复杂度也日益减少，在业务疾速迭代的同时，如何保障业务继续的高可用性和稳定性面临着很大的挑战。混沌工程通过被动注入故障的形式，提前发现零碎的薄弱点，推动架构的改良，最终实现业务韧性。 打不倒我的必使我弱小，建设韧性架构是混沌工程的指标。韧性架构蕴含两局部，一部分是韧性零碎，比方具备冗余性、扩展性、降级熔断、故障隔离等，防止级联故障，构建容灾容错的韧性零碎。另一部分是韧性组织，蕴含高效交付、故障预案、应急响应等组织协同建设。高度韧性的零碎也会呈现预期之外的故障，所以韧性的组织能补救韧性零碎缺失的局部，通过混沌工程构建极致的韧性架构。 常见的云原生高可用架构架构基本上是基于多可用区，或者是跨地区级的容灾架构，业务利用采纳微服务架构下集群部署，中间件具备容错容灾能力等等。从底层设施到下层业务，都存在潜在的故障危险，比方机房断网、整个可用区不可用、集群宕机、中间件节点 crash 等。从可用区到集群、主机，再到细粒度的申请，故障影响的爆炸半径逐步减小，这也是混沌工程准则中十分重要的一点 -- 管制爆炸半径。管制爆炸半径的形式个别有两种：一是环境隔离，通过隔离试验的机房、集群等来管制影响面；二是基于试验工具或平台本身的场景控制能力，比方 chaosblade 试验工具，通过试验参数来管制试验粒度，比方微服务调用提早，能够管制到单个服务接口、版本，甚至一次申请。上面咱们来介绍一下 chaosblade 混沌试验工具。 Chaosblade 是一款遵循混沌试验模型的混沌试验执行工具，具备场景丰盛度高、简略易用等特点，而且扩大场景也特地不便，开源不久便被退出到 CNCF Landspace 中，成为支流的一款混沌工具。chaosblade 是个间接下载解压即可应用的工具，不须要装置，它反对的调用形式蕴含 CLI 形式，间接执行 blade 命令，这里举个做网络屏蔽的例子：咱们增加 -h 参数就能够看到十分欠缺的命令提醒，比方要一个 9520 端口调用做网络丢包，它的演练指标是 network；它的 action 是丢包；它的 matcher 就是调用近程的一个服务端口 9520。执行胜利后会返回试验后果，每一个试验场景咱们都会作为一个对象，它会返回一个试验对象的 UID，此 UID 用于后续的试验治理，比方销毁、查问试验都是通过此 UID 来做的。要销毁试验，也就是复原试验，间接执行 blade destroy 命令就能够。 Chaosblade 反对多平台、多语言环境，蕴含 Linux、Kubernetes、Docker 平台，以及 Java、NodeJS、C++、Golang 语言利用。共波及 200 多个场景、3000 多个参数，为用户提供丰盛的场景和试验参数管制。应用 blade -h 命令能够查看具体的应用文档，蕴含案例和场景、参数介绍。上面咱们重点介绍一下 chaosblade 对应用服务场景的反对。 ...

作者 | 敖小剑 阿里云高级技术专家、Dapr Maintainer Dapr 是 2019 年 10 月微软开源的分布式运行时，在往年 2 月份刚刚公布了 v1.0 正式版本。尽管推出至今不过一年半工夫，但 Dapr 发展势头非常迅猛，目前曾经在 GitHub 上播种了 1.2w 星。阿里是 Dapr 开源我的项目的深度参与者和晚期采纳者，率先进行了生产落地，团体外部有十几个利用在应用 Dapr；目前已有 2 位 Dapr成员，是Dapr 我的项目中除微软之外代码奉献最多的公司。 尽管 Dapr 在国外有很高的关注度，但在国内知名度非常低，而且现有的大量 Dapr 材料也偏新闻资讯和简略介绍，不足对 Dapr 的深度解读。在 Dapr v1.0 公布之际，我心愿能够通过这篇文章帮忙大家对 Dapr 造成一个精确的认知：把握 Dapr 我的项目的倒退脉络，理解其外围价值和愿景，领悟 Dapr 我的项目背地的“道之所在”—— 云原生。 回顾：Service Mesh 原理和方向1. Service Mesh 的定义首先，让咱们先疾速回顾一下“Service Mesh”的定义，这是 Dapr 故事的开始。 以下内容摘录自我在 2017 年 10 月 QCon 上海做的演讲 "Service Mesh：下一代微服务"： Service Mesh 是一个基础设施层，用于解决服务间通信。古代云原生利用有着简单的服务拓扑，服务网格负责在这些拓扑中实现申请的牢靠传递。 在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序通明。 在 Service Mesh 的定义中，简短地形容了 Service Mesh 的要害特色： ...

近期，在面试 iOS 工程师的过程中，当我问到候选人小伙伴都理解哪些 iOS 容器类型时，大多数小伙伴能给出的回答就是 NSArray、NSDictionary 和 NSSet 以及对应的可变类型，有些优良的小伙伴可能说出 NSCache，还能对它的原理娓娓而谈，这是十分棒的。然而总体而言，高阶容器的遍及在技术同学中还是比拟少。本文，咱们就来具体聊聊咱们对 iOS 高阶容器类型的深入研究后果，并探讨其应用场景。 在进行具体分析之前，咱们先简略理解一下 iOS 的容器有哪些。 iOS 提供了三种次要的容器类型，它们别离是 Array、Set 和 Dictionary，用来存储一组值： Array：存储一组有序的值Set：存储一组无序的、不反复的值Dictionary：存储一组无序的键-值映射 这些都是咱们平时用到的根底容器。除此之外，iOS 提供了很多高阶容器类型，他们别离是： NSCountedSetNSIndexSet && NSMutableIndexSetNSOrderedSet && NSMutableOrderedSetNSPointerArrayNSMapTableNSHashTableNSCache明天，咱们将对这些高阶容器进行具体介绍。 NSCountedSetNSCountedSet 是与 NSMutableSet 用法相似的无序汇合，能够增加、移除元素，判断元素是否存在及保障元素唯一性。不同的是： 一个元素能够增加屡次能够获取元素的数量构想咱们要做一个淘宝购物车的性能，购物车中统计每一个商品的数量，还能够对数量进行减少和缩小。依照常规，传统的做法是应用字典： @property (nonatomic, strong) NSMutableDictinary *itemCountDic;获取数量： NSNumber *num = [self.itemCountDic objectForKey:item]; if (num == nil) { return 0; } return num.integerValue;数量+1： NSNumber *num = [self.itemCountDic objectForKey:item]; if (num == nil) { [self.itemCountDic setObject:@1 forKey:item]; } else { [self.itemCountDic setObject:@(num.integerValue+1) forKey:item]; }数量-1： ...

简介：咱们都晓得，服务网格(ServiceMesh)能够为运行其上的微服务提供无侵入式的流量治理能力。通过配置VirtualService和DestinationRule，即可实现流量治理、超时重试、流量复制、限流、熔断等性能，而无需批改微服务代码。 本文所述的实际是依据申请Header实现全链路A/B测试。1 背景介绍咱们都晓得，服务网格(ServiceMesh)能够为运行其上的微服务提供无侵入式的流量治理能力。通过配置VirtualService和DestinationRule，即可实现流量治理、超时重试、流量复制、限流、熔断等性能，而无需批改微服务代码。 流量治理的前提是一个服务存在多个版本，咱们能够按部署多版本的目标进行分类，简述如下，以不便了解余文。 traffic routing：依据申请信息(Header/Cookie/Query Params)，将申请流量路由到指定服务(Service)的指定版本(Deployment)的端点上(Pod[])。就是咱们所说的A/B测试(A/B Testing)。traffic shifting：通过灰度/金丝雀(Canary)公布，将申请流量无差别地按比例路由到指定服务(Service)的各个版本(Deployment[])的端点上(Pod[])。traffic switching/mirroring：通过蓝绿(Blue/Green)公布，依据申请信息按比例进行流量切换，以及进行流量复制。本文所述的实际是依据申请Header实现全链路A/B测试。 1.1 性能简述从Istio社区的文档，咱们很容易找到对于如何依据申请Header将流量路由到一个服务的特定版本的文档和示例。然而这个示例只能在全链路的第一个服务上失效。 举例来说，一个申请要拜访A-B-C三个服务，这三个服务都有en版本和fr版本。咱们期待： header值为user:en的申请，全链路路由为A1-B1-C1header值为user:fr的申请，全链路路由为A2-B2-C2相应的VirtualService配置如下所示： http:- name: A|B|C-route match: - headers: user: exact: en route: - destination: host: A|B|C-svc subset: v1- route: - destination: host: A|B|C-svc subset: v2咱们通过实测能够发现，只有A这个服务的路由是合乎咱们预期的。B和C无奈做到依据Header值路由到指定版本。 这是为什么呢？对于服务网格其上的微服务来说，这个header是凭空出现的，也就是微服务代码无感知。因而，当A服务申请B服务时，不会透传这个header；也就是说，当A申请B时，这个header曾经失落了。这时，这个匹配header进行路由的VirtualService配置曾经毫无意义。 要解决这个问题，从微服务方的业务角度看，只能批改代码(枚举业务关注的全副header并透传)。但这是一种侵入式的批改，而且无奈灵便地反对新呈现的header。 从服务网格的基础设施角度看，任何header都是没有业务意义且要被透传的kv pair。只有做到这点，服务网格能力实现无差别地透传用户自定义的header，从而反对无侵入式全链路A/B Test性能。 那么该怎么实现呢？ 1.2 社区现状后面曾经阐明，在header无奈透传的状况下，单纯地配置VirtualService的header匹配是无奈实现这个性能的。 然而，在VirtualService中是否存在其余配置，能够实现header透传呢？如果存在，那么单纯应用VirtualService，代价是最小的。 通过各种尝试(包含精心配置header相干的set/add)，我发现无奈实现。起因是VirtualService对header的干涉产生在inbound阶段，而透传是须要在outbound阶段干涉header的。而微服务workload没有能力对凭空出现的header值进行透传，因而在路由到下一个服务时，这个header就会失落。 因而，咱们能够得出一个论断：无奈单纯应用VirtualService实现无侵入式全链路A/B Test，进一步地说，社区提供的现有配置都无奈做到间接应用就能反对这个性能。 那么，就只剩下EnvoyFilter这个更高级的配置了。这是咱们一开始很不心愿的论断。起因有两个： EnvoyFilter的配置太过简单，个别用户很难在服务网格中疾速学习和应用，即使咱们提供示例，一旦需要稍有变动，示例对批改EnvoyFilter的参考价值甚微。就算应用EnvoyFilter，目前Envoy内置的filter也没有间接反对这个性能的，须要借助Lua或者WebAssembly(WASM)进行开发。1.3 实现计划接下来进入技术选型。我用一句话来概括： Lua的长处是玲珑，毛病是性能不现实WASM的长处是性能好，毛病是开发和散发相比Lua要艰难。WASM的实现支流是C++和Rust，其余语言的实现尚不成熟或者存在性能问题。本文应用的是Rust。咱们应用Rust开发一个WASM，在outbound阶段，获取用户在EnvoyFilter中定义的header并向后传递。 WASM包的散发应用Kubernetes的configmap存储，Pod通过annotation中的定义获取WASM配置并加载。(为什么应用这种散发模式，前面会讲。) 2 技术实现本节所述的相干代码： https://github.com/AliyunContainerService/rust-wasm-4-envoy/tree/master/propagate-headers-filter2.1 应用RUST实现WASM1 定义依赖WASM工程的外围依赖crates只有一个，就是proxy-wasm，这是应用Rust开发WASM的根底包。此外，还有用于反序列化的包serde\_json和用于打印日志的包log。Cargo.toml定义如下： [dependencies]proxy-wasm = "0.1.3"serde_json = "1.0.62"log = "0.4.14"2 定义构建WASM的最终构建模式是兼容c的动态链接库，Cargo.toml定义如下： ...

简介：微服务和容器化带来了将应用程序分解成可重复使用的小型单元的诉求，这些单元通常作为独自的过程运行，或者在独自的容器运行。 Kubernetes的Pod模型容许用户创立一个部署单元，该单元能够打包多个容器作为应用程序的单个实例。 Knative 用户以后同样存在将多个容器部署到一个Pod中对诉求。反对多个容器的能力将有利于把更宽泛的工作负载部署到Knative Serving模型中。因而 Knative 从 0.16.0 版本开始提供多个容器的能力。导读微服务和容器化带来了将应用程序分解成可重复使用的小型单元的诉求，这些单元通常作为独自的过程运行，或者在独自的容器运行。 Kubernetes的Pod模型容许用户创立一个部署单元，该单元能够打包多个容器作为应用程序的单个实例。 Knative 用户以后同样存在将多个容器部署到一个Pod中对诉求。反对多个容器的能力将有利于把更宽泛的工作负载部署到Knative Serving模型中。因而 Knative 从 0.16.0 版本开始提供多个容器的能力。 多容器反对单容器介绍Knative 0.16.0之前的版本，仅反对设置一个业务容器，也就是在Knative Service中只能设置一个容器。在服务创立的过程中，会默认在POD中加上一个 QUEUE 容器，该容器次要用户接管入口流量，用于基于流量的KPA指标收集。典型的一个Knative Service 如下： apiVersion: serving.knative.dev/v1kind: Servicemetadata: name: helloworld-gospec: template: spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56 env: - name: TARGET value: "Knative"创立实现运行中POD示意图如下： 如果咱们想要加上一个自定义的SideCar容器(个别用于网络互通，文件下载拷贝等辅助性能)，是没有方法去反对的，也就限度了理论的应用场景。 多容器介绍Knative 从 0.16.0 版本开始也反对了多容器（没什么好说的，k8s pod人造的个性必须要反对） 那么如何应用多容器呢？很简略，其实就是在containers属性中配置多个即可，示例如下： apiVersion: serving.knative.dev/v1kind: Servicemetadata: name: multi-container namespace: defaultspec: template: spec: containers: - image: docker.io/savita3020/servingcontainer ports: - containerPort: 8881 - image: docker.io/savita3020/sidecarcontainer开启多容器个性阿里云 Knative v0.18.3 曾经默认开启。社区 Knative 0.16.0 默认未开启, 从0.17.0 开始默认开启，执行上面操作可查看是否开启： $ kubectl -n knative-serving get configmap config-features -oyaml ...... multi-container: "enabled" ......多容器实际前提条件创立Kubernetes托管版集群一键部署Knative创立服务接下来咱们创立多容器的一个服务，该服务包含两个容器： ...

作者 | 王思宇（酒祝）起源 | 阿里巴巴云原生公众号 前言OpenKruise 是阿里云开源的云原生利用自动化治理套件，也是以后托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 我的项目。它来自阿里巴巴多年来容器化、云原生的技术积淀，是阿里外部生产环境大规模利用的基于 Kubernetes 之上的规范扩大组件，也是紧贴上游社区规范、适应互联网规模化场景的技术理念与最佳实际。 OpenKruise 在 2021.3.4 公布了最新的 v0.8.0 版本（ChangeLog），其中一个次要变动是新增了 镜像预热 能力。本文由《通过 OpenKruise 实现大规模集群 镜像预热&部署公布减速实际》分享整顿为文字，为大家介绍咱们所提供的镜像预热能力的需要起源、实现形式以及应用场景。 背景：为什么镜像预热能力是必要的“镜像” 也算是 Docker 为容器畛域带来的一大翻新。在 Docker 之前，尽管 Linux 曾经提供了 cgroup 隔离，只管阿里巴巴从 2011 年曾经逐步基于 LXC 开始容器化，但都不足镜像这种对运行环境的封装。不过呢，只管镜像为咱们带来了诸多益处，但不可否认在理论场景中咱们也面临各种各样拉镜像带来的问题，其中最常见的一点就是拉镜像的耗时。 咱们过来听到过很多用户对容器化的期待和意识，比方 “极致弹性”、“秒级扩容”、“高效公布” 等等，但联合 Kubernetes 中一个规范的 Pod 创立过程来看，和用户的冀望还是有肯定差距的（假如 Pod 中蕴含 sidecar、app 两个容器）： 失常来说，对于小规模集群中调度、调配/挂载近程盘、调配网络等操作耗时较小，对于大规模集群须要做肯定优化，但都还在可控的范畴内。然而对于拉镜像的耗时，在大规模弹性的集群中则尤为辣手，即便采纳了 P2P 等技术手段来优化，对于一个较大的业务镜像还是可能须要较长的工夫来拉取，与用户所冀望的扩容、公布速度不符。 而咱们如果能做到将 sidecar 容器的镜像、以及业务容器的根底镜像提前在节点上拉取好，则 Pod 创立过程能够大幅缩短，其中拉镜像的耗时甚至能优化 70% 以上： 而 Kubernetes 本身是没有提供任何面向镜像的操作能力的，围绕 Kubernetes 的生态来看，目前也没有比拟成熟的规模化镜像预热产品。这是咱们在 OpenKruise 中提供镜像预热的起因，并且这套镜像预热能力曾经在阿里巴巴外部的云原生环境大面积落地，在后文的实际中也会简略介绍咱们的根本用法。 ...

简介：浅谈专有云MQ存储空间的清理机制 在近⼀年的项⽬保障过程中，对专有云MQ产品的存储⽔位清理模式⼀直存疑，总想一探到底但又苦于工作忙碌、精力有限，直到最近⼀次项⽬保障过程中再次出现了相似的问题，⼤家对MQ Broker的⽔位清理机制依然⽐较含糊，于是便有了这篇⽂章。心愿能通过这篇⽂章将MQ Broker的音讯清理机制讲清楚。 ⾸先，咱们先来看⼀张MQ的音讯保留工夫和Broker磁盘存储空间的⽔位趋势图（该图来源于铜雀，⽬前已更名为SRE技术保障平台）。通过该趋势图，能够看到红线左侧的音讯保留工夫（上⽅蓝⾊趋势线）和Broker磁盘存储空间（下⽅绿⾊区域）呈现出规律性的稳定。⽽红线右侧局部，随着音讯量的疾速减少（通过Broker磁盘存储空间疾速上涨得出），开始⼀段时间音讯保留工夫还呈规律性稳定，但靠近最右侧时，能够看到音讯保留工夫的稳定频率放慢了，⽽且音讯保留工夫疾速降落。那么MQ对音讯的清理机制到底是什么呢？ 图1：音讯保留工夫&磁盘空间占比趋势图 在介绍清理机制前，先来温习⼀下MQ的音讯是如何进⾏存储的。 图2：commitlog Producer发送的所有音讯都寄存在Broker节点的 /home/admin/store/commitlog ⽬录下（专有云场景），每个commitlog的⼤⼩固定为1G。随着工夫的推移，当Broker接管的音讯量越来越多时，就会在该⽬录下⽣成多个⼤⼩为1G的commitlog⽂件。 ps: 特地申明，尽管该⽬录叫commitlog，但⽬录中存储的⽂件并不是程序⽇志，⽽是MQ Broker⽤来存储音讯的⽂件载体，在MQ产品中这种⽂件载体叫做commitlog。之所以这⾥做特地阐明，是因为历史上呈现过因为误认为此⽬录下存储的是程序⽇志，为了开释磁盘存储空间将⽬录下的commitlog删除导致MQ音讯失落的故障。这是⾎的教训！这个⽬录下的⽂件不要碰，不要碰，不要碰。 commitlog⽬录下的⽂件让MQ⾃行保护清理便可。那MQ⾃身是依据什么规定来进⾏清理的呢？先来看⼀下MQ⾥⾯⼏个⽐较要害的阈值： 72⼩时，MQ默认的音讯保留工夫。从图1能够看出每次音讯保留工夫稳定下降时，均会迫近到该值。凌晨4点，MQ默认的音讯清理触发工夫。从图1能够看出每次音讯保留工夫降落均在凌晨4点产生。75%，MQ默认的开始触发清理磁盘存储空间的阈值。85%，MQ内置的开始强制清理磁盘存储空间的阈值。90%，MQ内置的Broker开始禁写的磁盘存储空间的阈值。MQ会在两个机会对commitlog进⾏清理，⼀是前文提到的每天凌晨4点；另⼀个是音讯写⼊时。通过以下表格能够更加分明的看出具体的清理策略。 清理模式 一般清理，这种清理模式只将72⼩时之前的commitlog清理掉，MQ在保障存储72⼩时音讯的前提下，尽量升高磁盘空间使⽤率。强制清理，这种清理模式只在Broker存储空间⾼于85%的状况下触发，此时MQ在对commitlog进⾏清理时，将不再思考72⼩时的音讯保留工夫，⽽是要尽可能保障可能接管新的MQ音讯进来，因而会强制对 commitlog进⾏清理（因为如果不清理，磁盘空间使⽤率进⼀步上涨到90%后，Broker便会⾃动禁写，新的音讯便⽆法写入）。当然也不会⼀次性将所有的commitlog清理掉，⽽是只批量清理⼀局部（代码中设置⼀个broker⼀次最多清理10个commitlog⽂件）。咱们回过头来再看⼀下这个趋势图。 图3：音讯保留工夫&磁盘空间占比趋势图 图中1,2,3,4,5,6 处，Broker的存储空间均未超过75%，在每⽇凌晨4点触发了定时清理，将72⼩时之前的音讯清理掉。能够看到在清理实现后，音讯的保留工夫都回落到了72⼩时左右。图中7处，Broker的存储空间使⽤率第⼀次达到了75%，但低于85%，触发了音讯写⼊时的一般清理，此时清理的还是72⼩时之前的音讯，能够看到音讯保留工夫在清理实现后回落到72⼩时左右，但存储空间使⽤率降落的⾮常⼩，阐明⽬前Broker中存储的音讯⼤局部都是72⼩时以内产⽣的。图中8处，随着音讯的发送（音讯写⼊速度⽐较快），存储空间使⽤率第⼆次达到了75%，仍低于85%，此时一般清理依然是清理72⼩时之前的音讯数据，能够看到磁盘空间使⽤率并没有显著降落。阐明此时音讯的写⼊速度曾经⾼于commitlog的清理速度。8之后发⽣的事件，因为此时音讯写⼊速度⾼于commitlog清理速度，尽管音讯写⼊时会触发清理动作，但此时Broker中的音讯都是72⼩时以内发送的，没有清理掉任何commitlog，磁盘⽔位并没有升高。随着音讯的一直写⼊，Broker的存储⽔位一直升⾼，音讯的保留工夫根本维持不变。8之后的之后，当Broker的存储⽔位达到85%，此时Broker为了后续还能持续提供服务，会开启强制清理，此时MQ不再思考72⼩时的音讯保留工夫，⽽是优先保障后续音讯的顺利写⼊，于是会将72⼩时以内的音讯也进⾏清理。整体体现为Broker的存储⽔位达到85%时，根本不会上涨（只有在音讯写⼊量特地⼤时，音讯写⼊速度远远⼤于commitlog清理速度，才会持续上涨），但因为清理了72⼩时以内的音讯，会使Broker的音讯保留工夫开始升高，开始低于72⼩时，并随着后续清理动作一直升高。如上所述，音讯写⼊量特地⼤，音讯写⼊速度远⾼于commitlog的清理速度，Broker的存储⽔位在达到85%后还会持续升⾼，直至达到90%时，Broker为了爱护⾃身服务可⽤性，会⾃动开启禁写，此时发送到该Broker的音讯会被回绝掉。Broker的存储⽔位不会进⼀步回升，⽽且此时Broker会开启强制清理，对72⼩时以内的音讯进⾏清理，以便使Broker的存储⽔位降到90%以下，使Broker能够从新对外提供服务。 ps：理论在MQ的代码实现层⾯，为了保障音讯写⼊Broker的性能，并不是每次写⼊音讯时都进⾏存储 空间检查和commitlog清理，⽽是通过定时工作来执⾏（该定时工作每10s执⾏⼀次）。 上述介绍的⼏个清理阈值中，有些是可调的，有些是内置在代码中不可调的。⽐如“凌晨4点”，“72⼩时”，“75%”，这3个参数是⽤户能够调整的MQ配置，“85%”，“90%”是写死在代码中的，是⽆法调整的。 查看Broker配置信息的⽅式如下，在Broker的docker中执⾏ sh /home/admin/rmq/bin/mqadmin getBrokerConfig -b ${IP}:10911deleteWhen，对应“凌晨4点”fileReservedTime，对应“72⼩时”diskMaxUsedSpaceRatio，对应“75%”在调整配置时，deleteWhen通常选在客户MQ业务的低峰期进⾏，尽量避免commitlog清理对⽣产业务的影响。当Broker存储⽔位呈现疾速上涨时，为防止存储⽔位达到90%，呈现禁写影响⽣产业务的状况，须要同时调整fileReservedTime和diskMaxUsedSpaceRatio的默认设置，通过调整这两个参数独特作⽤保障Broker的存储空间能够及时失去清理（还有⼀种降⽔位的⽅式——敞开MQ音讯轨迹）。当然这所有参数的调整都须要通过与产研的沟通与确认。 以上就是对MQ Broker音讯清理机制的分析，心愿通过这篇⽂章可能让大家了解并把握其清理机制，可能解决理论工作中遇到的MQ Broker存储⽔位疾速上涨的问题。 咱们是阿里云智能寰球技术服务-SRE团队，咱们致力成为一个以技术为根底、面向服务、保障业务零碎高可用的工程师团队；提供业余、体系化的SRE服务，帮忙广大客户更好地应用云、基于云构建更加稳固牢靠的业务零碎，晋升业务稳定性。咱们冀望可能分享更多帮忙企业客户上云、用好云，让客户云上业务运行更加稳固牢靠的技术，您可用钉钉扫描下方二维码，退出阿里云SRE技术学院钉钉圈子，和更多云上人交换对于云平台的那些事。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：云原生利用平台2月产品性能上新汇总，总有你想要的理解更多产品新性能信息 容器和中间件洽购季产品新老客户折扣失效日期为2021年3月1日--3月31日，老客户满减代金券失效日期为2020年3月17日--19日。满减代金券不可与产品折扣同时应用，每个账户限用一张满减代金券，最高减500元。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

作者 | Shuai Chang  阿里云云原生 Serverless 团队高级技术专家起源 | 阿里巴巴云原生公众号 体验文档：镜像拉取减速文档 FaaS 和容器容器镜像因其颠覆式翻新成为云原生时代利用部署格局的事实标准。头部云厂商 FaaS (Function-as-a-Service) 服务如阿里云函数计算、AWS Lambda 也相继在 2020 年反对应用容器镜像部署函数，全面拥抱容器生态。自公布以来，开发者陆续将机器学习、音视频解决、事件驱动离线数据处理、前端自动化等多个场景应用镜像疾速无服务器化，提高效率、降低成本。然而，冷启动始终是 Serverless 无奈绕开的问题。容器镜像须要将数据通过网络近程下载并解压，对于 GB 级别的镜像，拉取工夫可能高达分钟级别，主观上放大了冷启动副作用，妨碍实时利用的 Serverless 演进。 函数计算镜像减速性能传统的镜像拉取减速强调"开发者负责"，如精简镜像，正当调配镜像层，multi-stage 构建，应用工具（如 docker-slim）去除不须要的数据，遵循构建最佳实际等。这些工作不仅减轻了用户累赘，减速成果无限，且有运行时稳定性危险。阿里团体超大规模和场景高度简单的容器环境，对镜像存储、减速技术有深厚的积攒，杰出地承当了 3 年双十一、双十二、春节等大促秒杀场景的严苛的挑战。阿里云 Serverless 同容器镜像、存储等服务深度单干，将外部翻新在函数计算输入：杭州、北京、上海、美东、美西正式公布了镜像减速性能。该性能将本来属于开发者的镜像优化累赘转由函数计算承当，进一步帮忙开发者进步生产效率，专一业务翻新。 1. 减速成果咱们在抉择了外部生产环境和开源社区的工作负载，笼罩机器学习、人工智能、前端自动化、Web 利用等 7 种镜像大小、IO 拜访模式、启动命令的不同组合作为 benchmark，部署在 FC 北京区域。如下图所示，函数计算开启镜像减速性能后减速广泛超过 50%，对于机器学习场景中常见的臃肿镜像（如多个团队共享根底镜像, ml-small-import, ml-large-import, ai-cat-or-dog）减速成果更为显著（约 70%-86%），镜像越大优化空间往往越高。 2. 应用形式镜像减速能够通过控制台、CLI 工具或是 FC SDK 开启，具体步骤参考镜像拉取减速文档。 形式一：在函数计算控制台函数配置下抉择“开启镜像减速”。  形式二：应用 Funcraft 工具部署。在已有的 CustomContainerConfig 配置下增加 AccelerationType: Default 如需敞开则配置 AccelerationType： CustomContainerConfig: Image: registry-vpc.cn-beijing.aliyuncs.com/fc-demo/python-flask:v0.1 AccelerationType: Default3. 性能特点FC 镜像减速具备以下特点： ...

作者 | 顾荣  南京大学PASALab, Fluid我的项目co-founder起源 | 阿里巴巴云原生公众号 导读：为了解决大数据、AI 等数据密集型利用在云原生场景下，面临的异构数据源拜访简单、存算拆散 I/O 速度慢、场景感知弱调度低效等痛点问题，南京大学PASALab、阿里巴巴、Alluxio 在 2020 年 6 月份联结发动了开源我的项目 Fluid。Fluid 是云原生环境下数据密集型利用的高效撑持平台，我的项目自开源公布以来吸引了泛滥相干方向领域专家和工程师的关注，在大家的踊跃反馈下社区一直演进。近期 Fluid 0.5 版本正式公布，在该版本中，Fluid 次要新增改善以下三个方面内容： 丰盛数据集的操作性能，反对在线弹性扩缩容、元数据备份和复原。反对多样环境配置部署，满足用户的个性化部署配置需要。新增数据缓存引擎实现，减少用户在私有云上的引擎抉择。Fluid 开源我的项目地址：https://github.com/fluid-cloudnative/fluid 这三大次要性能的开发需要来自泛滥社区用户的理论生产反馈，此外 Fluid v0.5 还进行了一些 bug 修复和文档更新，欢送应用体验 Fluid v0.5！ Fluidv0.5 下载链接：https://github.com/fluid-cloudnative/fluid/releases 下文是本次新版本公布性能的进一步介绍。 丰盛数据集的操作性能在本版本中 Fluid 重点丰盛了外围形象对象 —— Dataset（数据集）的相干操作性能，从而使数据密集型利用可能更好地利用云原生提供的弹性、可观测性等根底性能，并加强了用户对数据集治理的灵活性。 1. 数据集在线弹性缓存扩缩容这是社区用户始终期待的性能！在 Fluid v0.5 之前，如果用户想要调整数据集的缓存能力，须要以全副卸载缓存引擎再重部署的形式实现。这种形式耗时耗力，还必须思考数据缓存全副失落的昂扬代价。因而，在新版本中，咱们为数据集提供了对缓存弹性扩缩容的反对，用户能够依据本人的场景需要，以不停机形式 on-the-fly 地按需减少某数据集的缓存容量以减速数据拜访（扩容）或缩小某个不频繁应用的数据集的缓存容量（缩容），从而实现更加精密的弹性资源分配，进步资源利用率。Fluid 内置的控制器会依据策略抉择适合的扩缩容节点，例如在缩容时会联合节点上运行工作状况和节点缓存比例作为筛选条件。 执行弹性数据集的缓存能力弹性扩缩容，用户只需运行如下命令： kubectl scale alluxioruntimes.data.fluid.io {datasetName} --replicas={num}其中 datasetName 对应于数据集的名称，replicas 指定缓存节点的数目。 无关数据集手动扩缩容及其成果的演示视频：http://cloud.video.taobao.com/play/u/2987821887/p/1/e/6/t/1/302459823704.mp4 更多对于数据集手动扩缩容的操作细节，请参考 Github 上的示例文档。 2. 元数据的备份与复原该性能加强了 Fluid 数据集元数据管理的灵活性。先前的 Fluid v0.4 曾经反对将数据集的元数据（例如，文件系统 inode tree）加载至本地，并且会记录数据集的一些要害统计信息（例如，数据量大小和文件数量）。然而，一旦用户销毁本地数据集，这些元数据信息也都将失落，从新构建数据集时需再次从底层存储系统获取。 ...

简介：杭州开课啦教育科技有限公司是一家致力于为中小学生提供学习辅导的在线教育公司，目前公司后端服务基础设施次要依靠于阿里云原生，其中蕴含计算、网络、存储以及 Kubernetes 服务。 曾凡维  杭州开课啦教育科技有限公司高级开发工程师 起源 | 阿里巴巴云原生公众号 杭州开课啦教育科技有限公司是一家致力于为中小学生提供学习辅导的在线教育公司，目前公司后端服务基础设施次要依靠于阿里云原生，其中蕴含计算、网络、存储以及 Kubernetes 服务。 技术选型背景2020 年是开课啦公司发展壮大的一年，整个公司团队由原来的几百人裁减至当初的几千人，在集中应用的时候基本上会有几千人同时在经营后盾进行操作，公司原有的外部后盾经营零碎是用 PHP 搭建起来的，性能跟业务上已逐步不能满足公司的需要布局，加上目前开课啦公司开发部曾经做了微服务拆分，主体对外服务是 java 语言的 Dubbo 集群，后盾零碎须要无缝对接 java 的 Dubbo 服务，所以 PHP 曾经逐步不能满足开课啦公司的需要。 过后本人也调研过 PHP 的 Dubbo 我的项目，因为我的项目已根本无人更新保护所以 pass 掉，前面本人对简洁高性能的 go 语言感兴趣，而后就关注到了 Dubbo-go 我的项目，通过一段时间的调研之后发现 Dubbo Go 合乎咱们的业务须要，并且社区十分的沉闷，前面便决定选用 Dubbo-go 作为后盾的 pc 业务框架。 可能也有同学会问为什么不应用跨言反对水平更好的 gRPC 呢，因为很多公司最开始的 RPC 服务集群都是基于 Dubbo 生态构建的，如果换框架老本太大，所以根本不会思考，gRPC 尽管跨语言反对水平更好然而很多货色都须要本人造轮子，比方服务注册，服务发现，日志监控等。 过后在决定选用 Dubbo-go 的时候开发外部也有一些拥护的声音的，为什么不间接转 java，转 java 的话就没有跨语言通信的问题了，转 java 的问题在于入门老本高，而且对于整个公司的技术栈来说，放弃语言的多样性，能力更加从容的应答将来的业务变动，Go 自身是一个不弱于 Java 的高性能语言，非常适合微服务架构。 面临的挑战确定了框架选型后，我接到的首要任务便是要搭建出一套可疾速创立业务我的项目的脚手架，开发出基于 HTTP 协定的 RPC 代理服务，部署须要接入公司的容器化部署平台，一切都是从零开始，在网上基本上找不到能够借鉴的材料。 首先是要进行 Dubbo-go 我的项目的架构的布局，确定我的项目目录构造，通过参考 Dubbo-go Demo 以及其它的 Go 我的项目最终确定了我的项目的目录构造，以下目录构造可作为参考。 ...

简介：本文对过来十年 CBU 在研发形式和技术架构上的摸索做一个简要的回顾总结，以及对将来的瞻望。作者：远岩，高级开发工程师。2019年毕业退出阿里巴巴，次要负责 CBU APP 端前台场景工程体系及服务端 Serverless 化建设。 前言CBU作为团体内最早成立的几个BU之一，有着多年丰盛的业务积淀，而CBU的技术也随同着业务一起一直地演进和成长着。从PC时代的WebX到现在的Serverless，CBU的研发体系经验了屡次改革，在不同的阶段中有着不同的特点。笔者所在的团队近年来始终在负责前台场景研发体系降级相干的工作，在这期间也对过往模式的演变进行了大量的回顾和剖析，心愿可能通过本文对过来十年中CBU在研发形式和技术架构上的尝试和摸索做一个简要的回顾和总结，从新扫视咱们所走过的路，同时也对将来的方向做一些探讨和瞻望。 青铜时代（2010～2013）10年前的互联网，挪动终端还没有衰亡，绝大多数的产品都是为PC用户所服务的。在这种背景下，采纳B/S构造是一种毋庸置疑的抉择，因而当咱们回顾这个时代的技术时，最先能想到的天然是那些和WEB、浏览器关系最亲密的关键词：比方WebX、jQuery、Velocity等等。 在这个阶段，业务流量并不微小，零碎的性能瓶颈根本集中在数据库的读写上，大部分的利用依然采纳单体式的架构，从前台页面到后盾逻辑都封装在同一个利用中，而在利用外部，往往是采纳MVC的分层思维对不同性能的模块进行划分。彼时CBU的前台利用架构也根本是这个思路，页面通过Velocity模板进行开发，后盾业务逻辑则封装成利用中单例的Service实现，两头通过一个相似Controller的粘合层进行连贯，将后端的数据字段转换成前端模版中所应用的变量： 这种模式的长处是，因为所有的模块都在同一个利用中，十分便于集中管理，当一个开发同学十分相熟整个利用构造时，他便能够十分疾速地实现一整个需要的开发。但毛病也同样显著：随着业务的倒退，前台逻辑变得越来越简单，需要必须要拆解成前后端拆散的形式，让专人做专事，而前台代码被耦合在利用中，使得前后端拆散开发变得异样艰难；除此之外，前台逻辑的变动往往是十分频繁的，如果每次批改一个页面元素都要公布整个利用，不仅研发效率会非常低下，还会影响线上业务的稳定性。 为了解决上述问题，过后CBU的同学们充分利用了Java的动静类加载机制以及Groovy脚本语言，以一种非凡的形式实现了前后端拆散开发和疾速迭代，这里咱们以商品详情场景为例解释一下其机制和原理。 首先，一张页面被拆分成若干个组件，每个组件都会对应一个bundle，这个bundle中蕴含了前台的vm模板，js代码，以及一个Groovy脚本。在理论研发时，须要先通过一个映射表达式申明该组件所须要生产的后盾模型或字段，而后通过Groovy脚本（相当于Controller层）将其转换为vm模板中的变量，接着便能够开发前台的vm模板和js逻辑。开发结束后，通过一个定制的公布零碎，便能够把对应的bundle公布到前台利用中，由利用外部的JVM动静加载Groovy脚本以及vm模板，实现需要性能的上线。下图便是一个应用这套研发体系开发需要的理论例子： 这套研发体系通过JVM动静加载的能力，将面向前台的View层和Controller层逻辑抽离进去，使其可能进行独立开发和动静公布，从而实现了前后台逻辑之间的解耦，晋升研发效率。只有后盾逻辑没有大的变更，很多需要都能够通过bundle疾速开发上线。不过在理论运行时，所有的逻辑依然是在同一个利用中执行的，这在肯定水平上会带来一些安全隐患。除此之外，这套研发体系也是十分定制化的，bundle的公布零碎实现十分惨重，并且对应的前台利用有强绑定关系，这就意味着很难将它疾速地复制到另一个业务场景中复用（CBU最终只有商品和店铺两个业务落地了相似的模式）。 只管存在着肯定的问题，但即使以当初的眼光来扫视，也不得不抵赖这套研发体系有着十分超前的设计思路。尤其是通过引入bundle这一概念，使业务迭代开发变得非常聚焦。在本文的后续章节中咱们会看到这一思路最终将随同着云原生技术反动，再一次回到咱们的视线当中。 蒸汽时代（2014～2018）这一阶段，互联网行业的状态产生了十分微小的变动。随着智能手机的风行和遍及，挪动互联网迅速崛起，各种各样的业务都开始向挪动端发力。团体动员ALL IN无线的战斗，大量的业务和产品须要疾速向挪动端迁徙。同时，随着智能手机市场的一直下沉，加上其“随时随地”都能应用的个性，互联网业务此时所须要应答的流量挑战和PC时代将不再是同一个数量级。 在技术侧咱们也能看到与上述景象所匹配的改革。一方面，因为流量的激增和零碎复杂度的减少，传统的单体式利用无奈再撑持业务的倒退，随着Docker这一关键技术的呈现，服务端利用的分布式拆分和微服务化成为不可阻挡的趋势。另一方面，因为挪动端崛起，前台展现冲破了PC键鼠交互以及浏览器能力的限度，用户对于产品体验和交互的要求势必会变得更高，这促使研发人员进一步细分化为负责底层业务逻辑的服务端研发和负责前台展示交互的前端、客户端研发：React的呈现敲响了传统WEB技术的丧钟，开发独立APP成为拓展业务的不二抉择，前端技术和客户端技术在这一阶段开始飞速发展。 这样的背景下，单体式利用和MVC架构逐步死去，前后端拆散的架构模式和Restful API登上历史舞台，每个细分畛域的技术栈都在飞速成长，大型软件的开发流程从此将会面对更加简单的合作和研发模式。 回到CBU自身，这一阶段技术上最重要的工作就是将本来PC上的业务疾速地迁徙到无线终端下来，因而成立了专门的无线团队，开始重点打造手机阿里APP。整体思路十分简单明了，原有的业务体系和逻辑放弃不变，进行微服务化革新，以RPC模式对外提供外围业务能力；架构上增设无线服务层，面向APP进行业务逻辑的适配和封装，通过团体对立对外网关提供Restful API给客户端及前端开发人员应用。这样就能够在根本不影响已有业务体系的条件下，让APP上的业务疾速跑起来。无线服务端在这里所表演的角色十分相似MVC架构模式中的Controller层：通过RPC与底层根底业务交互，而后叠加面向无线侧的非凡业务逻辑，最终对数据结构进行肯定的解决和封装，通过团体对外的无线网关透出给前台客户端应用： 在此模式下，无线服务端和客户端研发人员扮演着非常重要的角色，他们的研发和合作模式将最终决定APP的迭代速度以及品质。接踵而至的新挑战督促着CBU的工程师们对已有的研发体系进行全面的降级，而最终他们给出了非常精彩的答案：轻服务和场景搭建两大技术应运而生，接下来咱们会看到，这两者联合所产生的微妙化学反应，将会给前台场景的研发模式带来一次重大的冲破。 轻服务平台如上文所述，在ALL IN 无线的时代，无线服务端的研发同学们须要在已有的根底业务接口上进行大量的革新和封装，为无线APP端提供服务接口。而在微服务架构下，服务端要对外透出接口，个别须要在利用内编写RPC服务，而后通过团体的无线网关将对应的RPC服务裸露成团体APP能够调用的HTTP接口：这种形式下一个服务从开发到上线往往须要数天工夫。而为了保障客户端性能的疾速迭代，防止业务受到发版节奏的影响，很多简略逻辑往往会被上行至服务端解决，这就对无线服务端的迭代速度和灵活性提出了一个十分高的要求。既有的技术生产力不能满足业务诉求，那就势必要进行翻新，于是便诞生了可能撑持疾速麻利开发的轻服务平台，代号为MBOX。以明天的视角来看，这一平台践行的便是当下十分炽热的Serverless理念，并为服务端同学提供了FaaS（Function as a Service，函数即服务）的能力。 MBOX平台仍然采纳了动静类加载机制来实现代码的热更新，并联合字节码技术提供了一个JVM内的“平安容器”，把Java语言的动态化个性使用到了极致，其架构理念和实现原理如下图所示： 通过配套的研发平台和公布零碎，开发者能够将本人编写的一个类动静加载进线上利用的MBOX容器中，并创立一个单例对象；各种常见中间件如RPC和缓存能力，都能够通过注解进行申明注入并应用；而服务一经公布，便能够通过指定的Gateway拜访到。这种无需配置、开箱即用、疾速上线的轻服务迭代形式，十分实用于过后无线服务端所面对的开发场景：对现有的业务RPC服务进行组合编排，再加上一些面向APP端的简略解决逻辑，应用MBOX便能够在几小时内实现从开发到上线的整个流程，生产力失去了极大的晋升。 场景搭建早在PC时代CBU就曾经建设了页面搭建相干的技术产品，而在无线端，这一命题实现起来却要简单许多。首先，客户端的页面并非像前端一样，由规范的浏览器所承载，iOS和Andorid双端从底层的零碎机制到下层的组件实现都齐全不同，要想实现对立的页面搭建，势必须要抹平这层差别。其次，场景搭建并不是简略的堆砌组件，还须要思考每个组件背地的数据源：来自各种利用的服务接口必须和组件解耦，而不能在组件外部通过Native逻辑实现，否则将会导致组件齐全丢失复用性，并且使业务迭代更加依赖发版。 为解决上述问题，各端的工程师付出了诸多致力。首先是制订多端差别的抹温和交融计划，该计划从各端组件化渲染计划进行形象，对立了一套绝对形象、可扩大的协定，蕴含页面协定、布局协定和组件协定三大部分。页面协定指定了以后页面的根本信息、页面主体构造、埋点信息、渲染形式；布局协定指定了该布局下所有组件的布局形式，同时以布局容器可反对组件abtest、组件分流、组件个性化等投放形式；组件协定细化到组件的根底属性、渲染形式，除此之外，还会定义组件的数据绑定行为、数据申请形式、数据取数形式，从而将组件UI和数据解耦，晋升组件复用性和可维护性。 Android、iOS双端别离面向这套标准协议，对端上的多种渲染计划和Native能力进行封装，提供了对立的搭建容器实现，抹平了多端渲染的差别。 在此基础上，前台的开发/经营就能够通过搭建和配置化的形式，构建出前台页面的渲染协定（页面协定+布局协定+组件协定），该协定最终被上行至服务端的“渲染网关”节点，由其来收口所有搭建场景中协定的下发。除了协定下发之外，渲染网关还收口了所有组件的取数逻辑，通过一个通用的数据网关接口来对立前台组件的取数形式，让整个搭建体系变得更加简洁和规范。 构建残缺的场景搭建体系是一项盛大的工程，其中蕴含着有数研发人员的智慧结晶，受限于篇幅本文不再过多开展，想要理解更多的敌人能够参考咱们之前的系列文章： 《CBU场景经营建设实际与摸索》《CBU端容器标准化计划》麻利研发体系在场景搭建体系中，渲染网关对外封装了对立的取数接口，前台的组件将会通过这个接口间接生产后盾的服务端数据源，也就是一套重后端的计划（次要逻辑在服务端实现），因而在理论落地当中，往往须要为每个组件独立开发一个专属的数据源，这些数据源根本是对已有的RPC服务进行简略调用，而后封装一些前台相干的逻辑，因而应用轻服务来解决再适合不过了。于是两者互相联合造成了一套十分麻利的研发体系：前端开发者开发UI组件，后盾开发者通过MBOX编写一个轻服务，疾速适配生成数据源，两者通过搭建进行简略的配置化绑定，一个页面就实现了，非常高效。正是这样麻利的研发体系，帮忙CBU疾速地开辟了无线战场。 营销会场类页面是利用这一研发体系的典型场景，咱们以某行业导购会场为例来体验其研发流程： 在这种研发体系下，前端和客户端研发人员能够专一于开发本人的组件，而服务端研发人员则能够应用轻服务的形式疾速为对应组件适配封装对应的数据源接口（或者是编写传统的RPC服务），得益于搭建平台对组件和数据源的规范形象，单方的研发流程能够相互解耦，让整个研发体验变得更加专一和高效。而采纳这种前后端拆散的模式之后，各端的技术能力和架构将失去更加聚焦的打磨，因而咱们在之后将看到前台组件和后盾数据源的研发模式都会呈现新的冲破。 总之，新的研发体系大大晋升了前台场景的研发效力，这离不开背地的两大关键技术冲破 —— 场景搭建体系和轻服务平台。而在此之中，又蕴含着有数工程师智慧和汗水的结晶，是他们面对未知时的勇气和保持摸索的激情成就了这些平凡的技术产品，并为CBU研发体系的演进之路立起了一座新的里程碑。 向开辟路线的先驱者们致敬。 摩登时代（2019～2020）故事还在持续。最近两年，挪动互联网曾经进入下半场，随着工夫的推移，既有业务模式演变的越来越简单，同时也越来越成熟，而在此基础上，又有着诸多新的赛道被开辟，越来越多的竞争对手走上了跑道。咱们看到了航母级APP在一次次的打磨和历练中完工并启航远征，各种新的业务场景像停靠在甲板上的一架架舰载机，随时筹备以极快的速度腾飞。总的来说，已有业务实现了横蛮成长，逐步步入须要更多精细化打磨的阶段，而更多新兴的业务场景则须要通过借助既有的积淀，用比以前更快的速度跑起来。 而在技术侧，职能细分化使得各端的技术栈在过来几年里都失去了相当大的冲破：在前台展现方面，无论是前端还是客户端，组件化研发都曾经成为根本共识，并且技术计划也高度成熟，甚至呈现一些可能依据UI智能还原生成组件的技术。而在后端和运维方面，随着Kubernetes一统容器编排，云原生理念被迅速引爆，大量的底层运维和中间件能力被再一次下沉，以FaaS为代表的Serverless技术手段带来了生产力的极大晋升，让下层人员可能更加关注业务逻辑。对于大部分的一般业务场景，前后端技术都曾经实现了肯定水平的凋谢化：前端能够通过Serverless能力来疾速编写服务端接口，后端也能够通过低代码和可视化计划开发前端组件，这都象征着对应技术栈的高度成熟化。 在上一个阶段中，咱们通过搭建体系+轻服务的形式，打造出了一套可能麻利迭代的高效研发体系，帮忙CBU疾速实现了无线业务的布局，但在“横蛮成长”过后，也开始逐步暴露出一些问题，其中最为重要的是以下几点： FaaS服务带来了十分快的迭代速度，也造成了服务的疾速收缩，导致整体业务逻辑十分的扩散，同时也进一步加剧了零碎的复杂度。轻服务平台的底层架构依然是基于JVM实现，无奈实现精细化的资源隔离和弹性伸缩，随着应用范畴的不断扩大，性能和稳定性问题日益凸显。现有的研发体系尽管灵便度很高，然而有肯定的上手和学习老本，并且各个平台之间的割裂感非常明显，仅仅是通过一些约定连贯在一起。针对于以上问题，咱们进行了大量的探讨和剖析（具体可见前文《CBU Serverless 研发体系 FY20 S2 建设总结》)，并贴合理论业务诉求和业界技术的倒退状况，制订出了以下的策略： 依照畛域驱动设计的思路，对服务进行分层，从而无效梳理整体系统结构，同时对各类数据源进行标准化的定义和形容，制订对立标准来治理复杂度。轻服务平台底层架构进行降级，对接团体Serverless基建，全面拥抱云原生，开释技术红利。以搭建体系为外围，对现有的工程能力和研发平台进行系统化整合，打造一套面向前台场景的标准化解决方案，让后续相似场景的研发变得易了解、易上手、易保护。上面笔者将别离为大家介绍每一个策略的具体实现计划。 MBOX + FunctionCompute：打造真正的云原生FaaS解决方案前文提到过，CBU在很早的时候就开始大规模利用落地轻服务平台MBOX，通过几年的积淀，这种FaaS模式的服务曾经简直浸透进咱们的每一条业务线，带来了显著的研发提效，MBOX这一技术产品也在通过屡次打磨后变得越来越成熟。 与此同时，咱们也始终在关注着业界和团体内对于Serverless架构的最新落地计划，冀望可能将Runtime层的实现从JVM容器降级为真正的Serverless容器，实现更平安的资源隔离和弹性伸缩能力。这个财年，咱们和阿里云函数计算（Function Compute，下文简称FC）团队的同学并开展了单干，通过近一个季度的打磨和试错，实现了MBOX平台与FC函数运行时的整合，为服务端的研发同学打造出了一套将大量历史教训和最新技术计划相结合的规范FaaS解决方案。 在这套计划中，最大的改革来自中间件能力的下沉，得益于各种中间件能力的sidecar化，下层的业务利用能够变得非常轻量，从而具备了疾速部署和弹性伸缩的条件。在此基础之上，FC团队联合团体的基建，提供了成熟的函数运行时容器，反对函数级别的资源隔离和弹性伸缩，实现真正的Serverless能力。最终，咱们将通过多年积淀的MBOX编码方式和新的中间件调用形式进行了高度整合和优化，面向研发人员提供一套十分高效的业务FaaS编程框架和配套的预览调试插件，真正做到开箱即用的研发体验。整体计划架构如下图所示： 和传统的利用相比，这套函数利用计划非常轻量，能够实现疾速迭代，同时还能够享受Serverless的红利，无需关怀资源运维。而相比于原有的MBOX轻服务计划，又有着更高的扩展性和安全性。 建设规范化的数据源体系在前后端拆散的研发模式下，通常将为前台组件提供数据的服务接口统称为“数据源”，在之前的研发体系中，任何模式的服务接口都能够注册成为组件的数据源，并没有任何的标准或者规范，最终随着工夫的流逝，体系中的数据源数量飞速增长，难以保护。通过剖析后，咱们认为呈现这种景象的次要起因有以下几点： ...

大家好，我是张晋涛。 我将在这篇文章中深刻 Docker 的源码，与你聊聊镜像构建的原理。 Docker 架构这里咱们先从宏观上对 Docker 有个大略的意识，它整体上是个 C/S 架构；咱们平时应用的 docker 命令就是它的 CLI 客户端，而它的服务端是 dockerd 在 Linux 零碎中，通常咱们是应用 systemd 进行治理，所以咱们能够应用 systemctl start docker 来启动服务。（然而请留神，dockerd 是否能运行与 systemd 并无任何关系，你能够像平时执行一个一般的二进制程序一样，间接通过 dockerd 来启动服务，留神须要 root 权限） 实际上也就是 (图片起源：docker overview) docker CLI 与 dockerd 的交互是通过 REST API 来实现的，当咱们执行 docker version 的时候过滤 API 能够看到如下输入： ➜ ~ docker version |grep API API version: 1.41 API version: 1.41 (minimum version 1.12)下面一行是 docker CLI 的 API 版本，上面则代表了 dockerd 的 API 版本，它的前面还有个括号，是因为 Docker 具备了很良好的兼容性，这里示意它最小可兼容的 API 版本是 1.12 。 ...

没有容器前部署十分慢。须要筹备物理主机、操作系统和装置应用程序的各种依赖老本十分高。资源节约。一台服务器可能只提供了很小的一部分服务难于迁徙和扩大。有了容器后对软件和其依赖的标准化打包利用之间互相隔离共享同一个os kernel能够运行在很多支流操作系统上

CICD系列之一：装置gitlab 筹备主机：10.0.0.14 1. 敞开防火墙和SELINUXsystemctl stop firewalld systemctl disable firewalld sed -i 's/enforcing/disabled/' /etc/selinux/config setenforce 0 2. 装置docker3. 装置docker-compose下载适宜你以后linux版本的docker-compose组件sudo curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose 减少执行权限sudo chmod +x /usr/local/bin/docker-compose 查看docker-compose版本docker-compose --version 4. 搭建gitlab 公有仓库(应用内建的postgresql和redis)mkdir -p /home/disk1/gitlabmkdir -p /home/disk1/gitlab/{config,data,logs}cd /home/disk1/gitlab && vi docker-compose.yml version: '3'services: gitlab: container_name: gitlab image: 'twang2218/gitlab-ce-zh:11.1.4' restart: unless-stopped hostname: 'dev-poc' environment: TZ: 'Asia/Shanghai' GITLAB_OMNIBUS_CONFIG: | external_url 'http://dev-poc:10101' gitlab_rails['time_zone'] = 'Asia/Shanghai' gitlab_rails['gitlab_shell_ssh_port'] = 22 ports: - '10101:10101' - '443:443' - '2222:22' volumes: - ./config:/etc/gitlab - ./data:/var/opt/gitlab - ./logs:/var/log/gitlab 5. 本地域名echo "10.0.0.14 dev-poc" >> /etc/hosts ...

曾凡维  杭州开课啦教育科技有限公司高级开发工程师起源 | 阿里巴巴云原生公众号 杭州开课啦教育科技有限公司是一家致力于为中小学生提供学习辅导的在线教育公司，目前公司后端服务基础设施次要依靠于阿里云原生，其中蕴含计算、网络、存储以及 Kubernetes 服务。 技术选型背景2020 年是开课啦公司发展壮大的一年，整个公司团队由原来的几百人裁减至当初的几千人，在集中应用的时候基本上会有几千人同时在经营后盾进行操作，公司原有的外部后盾经营零碎是用 PHP 搭建起来的，性能跟业务上已逐步不能满足公司的需要布局，加上目前开课啦公司开发部曾经做了微服务拆分，主体对外服务是 java 语言的 Dubbo 集群，后盾零碎须要无缝对接 java 的 Dubbo 服务，所以 PHP 曾经逐步不能满足开课啦公司的需要。 过后本人也调研过 PHP 的 Dubbo 我的项目，因为我的项目已根本无人更新保护所以 pass 掉，前面本人对简洁高性能的 go 语言感兴趣，而后就关注到了 Dubbo-go 我的项目，通过一段时间的调研之后发现 Dubbo Go 合乎咱们的业务须要，并且社区十分的沉闷，前面便决定选用 Dubbo-go 作为后盾的 pc 业务框架。 可能也有同学会问为什么不应用跨言反对水平更好的 gRPC 呢，因为很多公司最开始的 RPC 服务集群都是基于 Dubbo 生态构建的，如果换框架老本太大，所以根本不会思考，gRPC 尽管跨语言反对水平更好然而很多货色都须要本人造轮子，比方服务注册，服务发现，日志监控等。 过后在决定选用 Dubbo-go 的时候开发外部也有一些拥护的声音的，为什么不间接转 java，转 java 的话就没有跨语言通信的问题了，转 java 的问题在于入门老本高，而且对于整个公司的技术栈来说，放弃语言的多样性，能力更加从容的应答将来的业务变动，Go 自身是一个不弱于 Java 的高性能语言，非常适合微服务架构。 面临的挑战确定了框架选型后，我接到的首要任务便是要搭建出一套可疾速创立业务我的项目的脚手架，开发出基于 HTTP 协定的 RPC 代理服务，部署须要接入公司的容器化部署平台，一切都是从零开始，在网上基本上找不到能够借鉴的材料。 首先是要进行 Dubbo-go 我的项目的架构的布局，确定我的项目目录构造，通过参考 Dubbo-go Demo 以及其它的 Go 我的项目最终确定了我的项目的目录构造，以下目录构造可作为参考。 ...

作者 | 王夕宁  阿里云高级技术专家起源 | 阿里巴巴云原生公众号 本文将介绍如何应用 ORAS 客户端将具备容许的媒体类型的 Wasm 模块推送到 ACR 注册库（一个 OCI 兼容的注册库）中，而后通过 ASM 控制器将 Wasm Filter 部署到指定工作负载对应的 Pod 中。Wasm Filter 部署中的所有步骤都应用申明形式，也就是说能够创立一个自定义资源 CRD 来形容 Wasm Filter 的部署。一旦该 CRD 创立之后，ASM 控制器能够将 Wasm 模块加载到数据立体层中的相应 Envoy 代理中，同时在管制立体层中也会创立相应的 Istio EnvoyFilter 自定义资源。 Envoy Filter 介绍首先回顾一下 EnvoyProxy 的实现机制。Envoy 的外围是一个 L3/L4 网络代理，并反对 L7 代理，通过提供可插入 filter chain 机制容许开发人员编写 filter 来执行不同的工作，譬如咱们罕用到的 HTTP connection manager，将原始字节转换为 HTTP 级别的音讯和事件，还解决所有 HTTP 连贯和申请共有的性能包含拜访日志、tracing 等。 上图能够看到：Downstream 作为连贯到 Envoy 并发送申请以及接管响应的客户端局部， 监听器 Listener 组件用于绑定到 IP 地址/端口并接管来自 Downstream 上游的连贯。通过配置 Listener，用户能够启用通过代理的流量治理能力，而后应用多个 Filter 加强数据流，多个 Filter 形成了一个 Filter Chain。能够看到通过这些 Filter chain 解决之后， 会把申请映射到相应的 Cluster（此处的 Cluster 集群是指 Envoy 连贯到的逻辑上雷同的一组上游主机，与下文中提交的 Kubernetes 集群没有关系），而 Cluster 的作用是负责连贯到一组上游节点服务, 并应用关联的负载平衡策略转发这些申请。 ...

一、背景最近公司上线办公网零信赖平安网关零碎，由我负责部署上线，在部署的时候同时也在想如何保障稳定性，以及后续部署的简便性； 想起了k8s微服务的成熟计划，不仅能够主动重启还能够监控容器运行状态，也能够集成自动化部署，于是找了一些材料将之前接触过的rancher用了起来，首先要做的就是简化装置形式，上面是我的一些过程，同时也能够给大家提供参考。 二、操作步骤让Rancher能拜访GitLab在流水线增加我的项目在仓库增加必备文件CICD主动部署调试三、gitlab增加oauth受权在进入集群的命名空间中，能够在菜单栏点击工具-流水线，而后就能够看到如下图所示的界面接下来关上gitlab，而后关上设置页面http://xx.xx.xx.xx/admin/applications/4，如下图所示 在上图中将所需信息填写进去，而后点击保留 保留之后，gitlab会生成Application Id和Secret,咱们将它复制进去， 复制进去之后，切回rancher零碎中，将其一一填写进来，如下图所示 点击实现后，会有一个弹窗进行受权，受权实现后rancher就能够拜访到gitlab仓库了。 四、在rancher中增加代码仓库在确保rancher能够拜访gitlab仓库之后，在rancher菜单栏点击工具-流水线，将须要自动化部署的我的项目启用并保留，如下图所示 保留之后，回到CICD列表中，能够看到两个曾经启用的我的项目，如下图所示 五、增加部署必备个文件接下来就能够开始在代码中启用CICD自动化部署了，须要在我的项目根目录增加三个文件，别离是: .rancher-pipeline.ymlDockerfiledeployment.yaml5.1 设置公布流程主动部署首先须要确定部署流程，次要用到文件.rancher-pipeline.yml，这里我是golang 的我的项目，应用了三个流程。 首先编译我的项目；接着构建镜像推送到rancher的镜像仓库中，最初应用容器编排文件公布我的项目，配置代码外围关注点如下图红色区域所示 stages:- name: Build steps: - runScriptConfig: image: golang:1.16 shellScript: |- go env -w GO111MODULE=on && go env -w GOPROXY=https://goproxy.cn,direct go mod tidy pwd go build -o ./bin/funfecenter- name: Publish steps: - publishImageConfig: dockerfilePath: ./Dockerfile buildContext: . tag: funfecenter:${CICD_EXECUTION_SEQUENCE}- name: Deploy steps: - applyYamlConfig: path: ./deployment.yamltimeout: 60notification: {}5.2 构建镜像在上一步中曾经将我的项目编译好，接着就须要将编译好的可执行文件放入到镜像中，这里起作用的次要是Dockerfile文件，配置代码比较简单，如下所示 FROM golang:1.16EXPOSE 1333COPY ./bin/funfecenter /data/funfecenter/centerCOPY ./init/ /COPY script.py /root/RUN apt update -yRUN apt install -y python3#CMD ["python3","/root/script.py"]CMD ["/data/funfecenter/center"]5.3 容器编排上一步曾经将须要运行的镜像推送到rancher的镜像仓库之后，接下来就须要构建pod来运行容器，这里发挥作用的次要是deployment.yaml 文件。 ...

作者：申屠鹏会 近年来，容器化曾经是业界的共识了，不仅能够缩小运维的老本，也有助于进行产品的疾速迭代，同时，本地也能够利用容器，搭建出和生产简直一样的环境，很不便的进行开发demo或者进行小性能的测试部署。接下来，我将从产品的需要剖析，设计，业务编码，集成测试，到正式上线，利用声网弱小的SDK，全程用容器化的思维，实现一个一对一课堂软件的开发。（因为资源关系，开发时候的容器环境只用Docker，而非K8s）。 我的项目介绍疫情以来，传统的一对一家教曾经很难实现了，利用网络进行视频教学逐步成为支流，然而现有的腾讯会议，ZOOM，小鱼会议等平台，侧重点还是多人视频会议的场景，对于一对一辅导教学还是有所欠缺的。因而，心愿开发一个可能反对学生和老师实时音频互动，实时文字沟通，白板，课堂回放，作业安排，批改，屏幕共享的1对1课堂教学软件。 需要剖析个别通过我的项目介绍，能够大抵晓得是一个怎么样的产品。如：产品的状态是什么，用户是什么，次要性能是什么。那么在需要分析阶段，就要细化，归类，取舍。在个别的互联网公司，常常有的还有需要评审，有了需要，能不能实现，能不能按时实现，都是须要思考的。然而当初咱们本人做demo的化，最简略的还是画一个思维导图，把性能分成几个模块，列一下优先级就行了。接下来就是对我的项目介绍的需要剖析。首先，咱们明确产品的状态，对于教学软件来说，最不便的就是Web端了，只有关上浏览器，装备一个有摄像头的电脑就能够开始学习，手机总归小了一点。而后依据介绍，一对一的教学意味着还有用户治理的性能。除此之外，最重要的就是课堂性能了，老师可能在课堂给学生讲课，录视频，共享桌面等性能，同时还须要和学生进行沟通，安排作业，因而还须要音讯告诉等性能。 那么通过以上剖析，咱们先做一个思维导图，重点是性能分类。如下 通过剖析总结，发现总共分为四个模块，别离是课堂治理，用户治理，白板性能，实时音视频，依据需要剖析，就能够开始进行下一步的技术选型了。 技术选型当初的技术有很多，光编程语言就有几十种，每种语言都有本人的框架，通信协议也有各种RPC，那么技术选型其实就是从宽泛的技术海中选取最适宜本人需要的技术，须要留神的是，技术选型从来不是以技术稳固或者技术先进为规范的，而是应该找最适宜的。由此，咱们开始进行技术的选型。通常我会从底层开始选取，上面我制作了一个表格，以供参考。 备选技术实现性能理由Ｇｏｌａｎｇ后端语言可能很不便的编译成可执行文件，而后打包成容器服务html等Ｗｅｂ前端页面不采纳vue等框架的起因是为了疾速开发体验Ｍｙｓｑｌ后端数据库开源收费，够用就行Ｒｅｄｉｓ缓存，用户鉴权等性能 Agora SDK实时音视频互动业界最晦涩最弱小的音视频ＳＤＫ腾讯云后端服务器提供容器部署，网关等服务。第三方白板白板性能 有了大抵的技术选型之后，接下去就是进行架构设计。 架构设计因为性能较少，服务大抵分成了Ｒｅｄｉｓ缓存，Ｍｙｓｑｌ数据库，后端服务，前端服务，以及网关五个服务。架构图画的比拟丑，如下： 声网有个更好看的图片，我也放上来： 比照着看的化，声网的更加细化，尤其ＡｇｏｒａＥｄｕ云服务提供了不少性能，但咱们本人开发的时候，用本人的服务器，那须要干的事件还是有点多的。在本人设计的架构图里，所有Ａｇｏｒａ的SDK会被打包进前端服务里，用户治理等模块会属于后端服务，两者都是容器化的服务，之间通过ｈｔｔｐｓ的接口进行拜访。而Ｍｙｓｑｌ和Ｒｅｄｉｓ则提供了数据库的性能。网关层则是一个鉴权，限流和HTTPS加密的服务。接下去就是实战局部了。实战我会偷点懒，会把CI/CD的省略，我会在本地编程测试实现之后再打包镜像到服务器的Ｄｏｃｋｅｒ，如果工程量大的时候还是倡议大家用继续部署的形式来做。 环境筹备只管从这开始曾经是实战局部了，然而“磨刀不误砍柴工”，咱们能够先筹备好所需的环境。 所需的开发环境： 操作系统：macos或者windows 10 编程环境：Golang 软件：Docker 有了最根底的几个之后，能够开启一些服务了。 数据库 Docker run -d -p 3306:3306 --name mysql mysql:5.7 缓存 Docker run -d -p 6379:6379 --name redis redis:4.0 查看环境是否都失常： 环境就绪后，那么接下去就是开发了。 编码开发在编码过程中，咱们能够先编写后端的服务，而后有接口提供了，再编写前端的，如此交替式编程，疾速实现一个Demo。 首先咱们创立两个空文件夹，一个作为后端服务，一个作为前端服务。而后关上前端服务，新建一个Html。 为了不便起见，咱们用CDN的形式引入Agora的SDK。 <script src="https://cdn.agora.io/sdk/release/AgoraRTCSDK-3.2.1.js"></script> Agora提供了一个实现音视频通话的调用过程，强烈建议浏览一下： 从上往下，以老师学生为例，业务逻辑能够是这样的： 老师通过AgoraRTC.createClient和Client.init创立本地客户端，而后通过Client.join退出频道。这时候能够了解为创立了一个课堂。接着通过创立本地流-播放本地流-公布本地流的过程，发送音视频数据。 那么学生端的操作就是通过订阅远端流，承受音频数据，而后进行播放。 如果要来到课堂的话，那就是通过Client.leave来到频道。 Agora的SDK能够替咱们做这些工作，是不是十分弱小？ 获取SDK的权限咱们先到agora.io上注册一下咱们的我的项目，随后会展现一些示例代码，如图： 咱们抉择Web端，依照申请调用的门路，咱们须要先初始化一个客户端对象，而后填入我的项目的APP ID和Token。同时，对于一对一视频场景，mode设置为rtc。 能够看到咱们须要传入一个APPID和一个Token还有频道。这些就由咱们的后端提供。 具体逻辑为，用户登录之后，停留在课堂治理界面。而后新建课堂，输出频道号，而后点击建设的时候，后盾返回APPID和Token，同时将课堂号存入数据库。 Agora很贴心的列出了简直所有波及的API，如下： 部署测试代码编写实现后，就能够打包成镜像，而后部署到服务器上，再配置一个反向代理，就能给敌人分享拜访啦，接下来咱们对前端和后端别离进行打包。 对于前端来说，咱们没有用框架，因而咱们能够间接用一个nginx镜像，将其中的index替换成咱们我的项目的index.html即可。 对于后端来说，Go能够通过：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go不便的编译成可执行文件。咱们只须要From一个空镜像，copy编译好的可执行文件即可。 后端Dockerfile： 非常简单，只须要将编译好的可执行文件main 用copy命令复制到容器外部某个目录，而后等容器起来的时候运行 ./main运行即可。 ...

作者 | 悟鹏、陶醉起源 | 阿里巴巴云原生公众号 《Kubernetes 稳定性保障手册》系列文章： Kubernetes 稳定性保障手册 -- 极简版Kubernetes 稳定性保障手册 -- 日志专题（本文）不管对于软件的用户还是开发者，日志都是很重要的信息源。日志能够用来表征软件的运行状态，在软件运行不合乎预期时提供丰盛的信息，也能够用在开发阶段调试软件，不便定位问题。 软件的生命周期波及到 开发 和 运行 两个阶段，日志的生成是在软件的开发阶段，日志的应用集中在软件的运行阶段。在开发阶段规范化日志，有助于运行阶段通过标准化办法剖析日志、配置日志监控和告警。在运行阶段通过标准化办法应用日志，有助于低成本把握程序的运行态行为，及时感知异样，促成开发阶段的迭代效率。 在软件的生命周期中，运行阶段时长占比会远大于开发阶段，即对日志的应用时长会远大于开发阶段写日志逻辑的时长。在开发阶段利用良好的日志标准，会对软件生命周期的失常运行和疾速迭代带来很大帮忙： 复杂度剖析程序中的元素能够形象为两局部：本身逻辑，依赖。两类元素之间的交互为：本身逻辑闭环，本身逻辑与依赖交互。 从长期角度来看，交互环节出问题的概率会比本身逻辑出问题的概率高，因而要重点关注交互环节的日志逻辑。 同时，对日志的治理须要意识到 _谁会应用这些日志，_通常有 4 类角色： 用户维护者平安人员审计人员用户从黑盒角度应用软件，通过日志理解软件以后的运行状态，关注重点是软件失常的状态。 维护者从白盒角度应用软件，开发角色通过日志调试软件，SRE 角色通过日志及时感知软件的异样状态，并通过日志上下文剖析异样起因。 平安人员通过剖析日志，理解歹意登录、异样删除等危险。 审计人员通过审计日志、利用日志，确认业务、架构的合规性。 根据上述不同的应用场景，咱们能够梳理出几类日志类别，进一步加强开发和运行阶段对日志的了解： 开发阶段最佳实际了解了日志使用者关注的重点后，开发阶段写日志时，举荐应用如下最佳实际： 应用 structured logs 不应用 format strings应用 info 和 error 表征日志级别 info 又可细化为多个级别，0~10，信息的重要性顺次升高 (也能够参考《Kubernetes: sig-instrumentation/logging.md》 0：用户想要看到的信息1：维护者关注的白盒行为信息10： 维护者调试用的信息应用具备过滤器能力的 log lib，通过 logger 主动过滤敏感信息 参见 《KEP: Kubernetes system components logs sanitization》日志通过 stdout/stderr 输入，敞开不必要的文本日志 防止额定的磁盘占用、IO 耗费、日志清理工作的保护等对于 golang，能够思考应用 klog 作为 logger 实现。 ...

拉取镜像docker pull season/fastdfs:1.2 启动Trackerdocker run -ti -d --name trakcer -v /opt/fastdfs/tracker_data:/fastdfs/tracker/data --net=host season/fastdfs:1.2 tracker启动Storage留神替换{ipaddress} docker run -ti -d --name storage -v /opt/fastdfs/storage_data:/fastdfs/storage/data -v /opt/fastdfs/store_path:/fastdfs/store_path --net=host -e TRACKER_SERVER:{ipaddress}:22122 season/fastdfs:1.2 storage批改配置文件vim的目录为cp后的目录，如我的目录为/usr/local/fastdfs/conf将配置文件中上面的参数替换为本人相应的ip即可 docker cp storage:/fdfs_conf/. /usr/local/fastdfs/confvim tracker.confbind_addr=${ipaddress}vim storage.conftracker_server=${ipaddress}:22122vim client.conftracker_server=${ipaddress}:22122//将批改完的配置文件cp回镜像中docker cp /usr/local/fastdfs/conf/. storage:/fdfs_conf//重启storage服务docker restart storage配置Nginx在storage服务中将nginx.conf和mod_fastdfs.conf挂载进去 //nginx.conf配置文件中增加location /group1/M00 { #root /fastdfs/store_path/data; ngx_fastdfs_module;}//在server外面配置跨域配置跨域 在server外面add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';//mod_fastdfs.conf中增加url_have_group_name=true启动Nginx留神：启动nginx时须要将上一步挂载进去的nginx.conf和mod_fastdfs.conf映射门路，所以须要依据本人的门路来写，同时记得替换{ipaddress}参数 docker run -id --name fastdfs_nginx --restart=always -v /opt/fastdfs/store_path:/fastdfs/store_path -v /usr/local/fastdfs/nginx_conf/nginx.conf:/etc/nginx/conf/nginx.conf -v /usr/local/fastdfs/nginx_conf/mod_fastdfs.conf:/etc/fdfs/mod_fastdfs.conf -p 8888:80 -e GROUP_NAME=group1 -e TRACKER_SERVER={ipaddress}:22122 -e STORAGE_SERVER_PORT=23000 season/fastdfs:1.2 nginx配置防火墙firewall-cmd --zone=public --add-port=22122/tcp --permanentfirewall-cmd --zone=public --add-port=8888/tcp --permanentfirewall-cmd --zone=public --add-port=23000/tcp --permanentfirewall-cmd --reload

因为k8s打算在v1.20后弃用docker（指容器运行时，而非docker容器），故打算采纳containerd作为容器运行时。 一、装置containerd和crictl1.1 名词解释runc：依据OCI标准来生成和运行容器的命令行工具。containerd：容器运行时crictl：k8s的命令行工具 1.2 装置步骤 # 1. 装置 runccurl -OL https://github.com/opencontainers/runc/releases/download/v1.0.0-rc92/runc.amd64mv runc.amd64 /usr/local/bin/runc && chmod +x /usr/local/bin/runc# 2. 装置 containerdcurl -OL https://github.com/containerd/containerd/releases/download/v1.4.3/containerd-1.4.3-linux-amd64.tar.gztar -zxvf containerd-1.4.3-linux-amd64.tar.gz -C /usr/localcurl -o /etc/systemd/system/containerd.service https://raw.githubusercontent.com/containerd/cri/master/contrib/systemd-units/containerd.service# 3. 配置 containerdmkdir -p /etc/containerdcat > /etc/containerd/config.toml << EOF[plugins] [plugins."io.containerd.grpc.v1.cri"] sandbox_image = "kubesphere/pause:3.2" [plugins."io.containerd.grpc.v1.cri".registry] [plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://registry-1.docker.io"] ## 这里可替换成dockerhub的镜像加速器EOFsystemctl enable containerd && systemctl restart containerd# 4. 装置 crictlVERSION="v1.19.0"curl -OL https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-amd64.tar.gzsudo tar zxvf crictl-$VERSION-linux-amd64.tar.gz -C /usr/local/binrm -f crictl-$VERSION-linux-amd64.tar.gz# 5. 配置crictlcat > /etc/crictl.yaml << EOFruntime-endpoint: unix:///run/containerd/containerd.sockimage-endpoint: unix:///run/containerd/containerd.socktimeout: 2debug: falsepull-image-on-create: falseEOF二、部署k8s和kubesphere# 1. 下载kubekey## 这里临时应用kubekey v1.1.0-alpha.1部署kubernetes集群，该版本为预览版，反对多container-runtime也会蕴含在后续的正式版本中。curl -OL https://github.com/kubesphere/kubekey/releases/download/v1.1.0-alpha.1/kubekey-v1.1.0-alpha.1-linux-amd64.tar.gztar -zxvf kubekey-v1.1.0-alpha.1-linux-amd64.tar.gz# 2. 创立配置文件 ./kk create config # 默认在同级目录下生成 config-sample.yaml # 3. 依据实在环境信息批改配置文件vi config-sample.yaml apiVersion: kubekey.kubesphere.io/v1alpha1kind: Clustermetadata: name: samplespec: hosts: - {name: node1, address: 192.168.6.3, internalAddress: 192.168.6.3, password: xxx} - {name: node2, address: 192.168.6.4, internalAddress: 192.168.6.4, password: xxx} roleGroups: etcd: - node1 master: - node1 worker: - node1 - node2 controlPlaneEndpoint: domain: lb.kubesphere.local address: "" port: 6443 kubernetes: version: v1.17.9 imageRepo: kubesphere clusterName: cluster.local containerManager: containerd ## 这里填入之前部署的container-runtime：containerd / crio / isula network: plugin: calico kubePodsCIDR: 10.233.64.0/18 kubeServiceCIDR: 10.233.0.0/18 registry: registryMirrors: [] insecureRegistries: [] addons: []# 4. 部署集群./kk create cluster -f config-sample.yaml --with-kubesphere# 5. 期待集群部署实现注：kubesphere默认账号密码是admin/P@88w0rd ...

作者 | 陈涛（毕衫）起源|阿里巴巴云原生公众号 一、人造云原生的 Serverless1. 云原生时代随着 2013 年以 Docker 为代表的容器技术、CNCF 基金会以及 K8s 的倒退等，云原生开始被宽广开发者所熟知。云原生时代之前还有两个阶段：一是自建 IDC 机房，二是简略地把原有的利用搬迁到云上。自建 IDC 机房很难取得高可用、高可扩大以及运维提效等能力；而第二个阶段就是云计算时代，相比 IDC 有了肯定的提高，但大部分还是在绝对原始地用云，很难用好云，这个阶段的资源曾经靠近有限，然而基于虚拟机及各种自建服务的形式还有待改善。 云原生时代指的是在设计利用的时候，就思考到未来利用会运行在云的环境里，充分利用了云资源的长处，比方云服务的弹性、分布式的劣势。如上图所示，云原生能够分为几局部： 一是云原生技术，包含容器、K8s、微服务、DevOps。而这些技术只是一个工具，要想真正地用好这些技术，还须要一些最佳的实际和组合，也就是云原生架构。 云原生架构是基于云原生技术的一种架构准则和设计模式的汇合，是一些领导准则，比方要求做好可观测，只有在做好可观测的前提下能力做好后续的弹性，包含高可用相干的建设及基础设施的下沉，心愿对非业务代码的局部进行最大化的剥离，在这样的技术和架构设计的领导下，就能够设计出云原生利用。 云原生利用具备轻量、麻利、高度自动化等方面的特点，能够充分发挥云的劣势，在古代数字化转型的时代，更好地适应业务的倒退变动。 2. Serverless 人造云原生 为什么说 Serverless 是人造云原生的呢？尽管 Serverless 呈现的工夫比云原生更早一些，咱们向前追溯，AWS 率先推出初代 Serverless 产品——Lambda，其按申请计费和极致伸缩的特点，十分合乎云原生的定义，比方基础设施下沉。在 Lambda 里，不须要治理服务器，它会依据申请去伸缩服务器，实现了高度自动化；它还以函数的模式来组织代码，函数绝对于利用来说要更轻量，交付速度也更快。然而这种模式的毛病就是革新老本高，因为很多利用原来是一个微小的单体或者微服务利用，很难革新成函数模式。 3. 意识 SAEServerless 理念及相干产品的推出曾经走过差不多 7 个年头，在这个过程中云原生的技术也在一直成熟，包含Docker、 K8s 等。阿里云在 2018 年的时候就开始思考另一种 Serverless 状态，即 Serverless application，也就是 SAE 这款产品，其于 18 年 9 月上线，19 年商业化，至今也走过了 3 个年头。 SAE 的特点： 不可变基础设施、可观测、主动复原基于 K8s 底座，背地代表的是镜像之类的不可变基础设施以及可观测、主动复原，如果检测到申请失败，会主动切流或重启实例。 免运维、极致弹性、极致老本托管服务器资源，不须要用户本人运维服务器，同时也相应地具备极致弹性和极致老本的能力。 易上手、0 革新、一体化如上图，最上层为客户感知层，是 aPaaS 产品状态，是一个利用 PaaS，通过三年多的实际，最终达到让用户真正易上手、0 革新的成果，而且做了很多一体化的集成。 ...

装置Rancher1、装置docker-ce略… 2、装置rancherPS：因为端口2380抵触，注册核心（sericecomb）与rancher集群需部署在不同服务器，或批改端口 容器形式启动 docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /data1/srv/rancher:/var/lib/rancher/ rancher/rancher:stableordocker run -d --restart=unless-stopped -p 8080:8080 rancher/server运行rancher/rancher:stable无奈启动，始终重启中的状态，查看日志： [root@Bluse]# docker logs 81616bc88b42ERROR: Rancher must be ran with the --privileged flag when running outside of KubernetesERROR: Rancher must be ran with the --privileged flag when running outside of KubernetesERROR: Rancher must be ran with the --privileged flag when running outside of Kubernetes应用docker run命令装置 Rancher 2.5.x 时，须要增加--privileged标记变量，启用特权模式装置 Rancher   ...

1. 依赖工具装置yum install -y yum-utils device-mapper-persistent-data lvm22. 增加源yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repoyum makecache fast3. yum装置docker-ceyum list docker-ce.x86_64 --showduplicates | sort -ryum install -y docker-cesystemctl enable docker && systemctl start docker查看版本进行确认 docker version 4. 配置镜像减速通过批改daemon配置文件/etc/docker/daemon.json来应用加速器 mkdir -p /etc/dockertee /etc/docker/daemon.json <<-'EOF'{ "registry-mirrors": ["https://5f9e1jti.mirror.aliyuncs.com"]}EOFsystemctl daemon-reloadsystemctl restart docker

作者 | 于雨起源|阿里巴巴云原生公众号 本文源自 2020 年 12 月 20 日作者在云原生社区 meetup 第二期北京站演讲 《Apache Dubbo-go 在云原生时代的实际与摸索》的局部内容，如果对演讲残缺内容感兴趣请拜访：https://www.bilibili.com/video/av245840877自从以 2013 年开源的 docker 为代表的的容器技术和以 2014 年开源的 K8s 为代表的容器编排技术登上舞台之后，相干技术从业人员从认知和体感上承受，云原生时代真的到来了。 当然也有很多资深技术人员认为，云原生时代要从 2010s 时以 OpenStack 为代表的虚机编排时代开始。当然，也有人说其实云原生技术诞生很早，能够从巨型机时代在巨型机上虚构出若干小型机开始追溯。 在云原生时代，不变镜像作为核心技术的 docker 定义了不可变的单服务部署状态，对立了容器编排状态的 k8s 则定义了不变的 service 接口，二者联合定义了服务可依赖的不可变的基础设施。有了这种齐备的不变的根底设置，就能够定义不可变的中间件新形态 -- 云原生中间件。 云原生时代的中间件，蕴含了不可变的缓存、通信、音讯、事件(event) 等根底通信设施，利用只需通过本地代理即可调用所需的服务，无需关怀服务能力起源。 微服务框架从最早的单体利用时代到分布式技术时代，风行的是微服务技术。微服务时代各大公司都积淀出了具备代表性的一些服务通信框架，如 Google 的 gRPC，阿里的 Dubbo 和 HSF，百度的 bRPC 等等。多个服务通信框架之间的竞争，基本上是在大公司之间进行角力。 站在使用者的角度，当然期待一个网络框架在进化过程中可能放弃向前兼容性，多个框架之间放弃互通性。 1. 服务框架的向后兼容性通信框架的根底是通信协议和序列化协定，其中很重要的问题就是新版本协定对旧版本的向后兼容性。在一个组织中个别都应用对立的通信框架，但事实中可能因为各种起因，同一个框架的序列化协定或者通信协议的向后兼容能力差，会导致应用不同版本通信框架的各个服务之间的异构化。如采纳了 pb v2 和 pb v3 的通信框架不兼容，不遑多让的 Thrift 0.8.x 与 Thrift 0.9.x 之间也不兼容。 不过 Protobuf v3 或者 Protobuf v2 的各个子版本之间的向前和先后兼容性还是不错的，但还是有一些弱鸡公司的外部序列化协定无论是否采纳 TLV 模式，其协定各个版本的之间还是无奈兼容，进而导致各个子版本的服务框架互相异构，最终导致应用了不同版本的服务框架的业务背上大量包袱无奈疾速演进，有些新版本的业务中存在各种神逻辑可能不是为了兼容旧版本的业务逻辑，而是为了兼容旧版本框架的通信协议。 ...

作者 | 张翼飞  阿里云技术专家起源|阿里巴巴云原生公众号 导读：家喻户晓，Kubernetes 是云原生畛域的基石，作为容器编排的基础设施，被广泛应用在 Serverless 畛域。弹性能力是 Serverless 畛域的外围竞争力，本次分享将重点介绍基于 Kubernetes 的 Serverless 服务中，如何优化 Pod 创立效率，晋升弹性效率。Serverless 计算简介 在进入主题之前，先简略回顾下 Serverless 计算的定义。 从维基百科能够理解到，Serverless 计算是云计算的一种状态，由云厂商治理服务器，向用户动态分配机器资源，基于理论应用的资源量计费。 用户构建和运行服务时，不必思考服务器，升高了用户治理服务器的累赘。在业务高峰期通过平台的弹性能力主动扩容实例，在业务低峰期主动缩容实例，升高资源老本。 Serverless 计算平台 下述是以后常见的 Serverless 计算产品的架构。  整个产品架构通常会有管控立体和数据立体两层，管控立体服务开发者，治理利用生命周期，满足开发者对利用治理的需要，数据立体服务利用的拜访方，如开发者业务的用户，满足利用的流量治理和拜访诉求。 管控立体通常采纳 Kubernetes 做资源管理和调度，master 通常是 3 节点，满足对高可用的需要，节点通过内网 SLB 拜访 K8s master。 在节点层面，通常会有两种类型的节点： 一种是运行 kubelet 的节点，如裸金属服务器、虚拟机等，这类节点上会运行平安容器作为 Pod 运行时，每个 Pod 领有独立的 kernel，升高共享宿主机 kernel 带来的平安危险。同时会通过云产品 VPC 网络或其余网络技术，在数据链路层隔离租户的网络拜访。通过 平安容器+二层网络隔离，单个节点上能够提供牢靠的多租运行环境。还有一种是虚构节点，通过 VirtualKubelet 连接 K8s 和弹性实例。弹性实例是云产品中相似虚拟机的一种轻量资源状态，提供有限资源池的容器组服务，该容器组的概念对应 K8s 中的 Pod 概念。AWS 提供有 Fargate 弹性实例，阿里云提供有 ECI 弹性实例。Serverless 产品会提供基于 K8s 的 PaaS 层，负责向开发者提供部署、开发等相干的服务，屏蔽 K8s 相干的概念，升高开发者开发、运维利用的老本。 在数据立体，用户可通过 SLB 实现对利用实例的拜访。PaaS 层也通常会在该立体提供诸如流量灰度、A/B 测试等流量治理服务，满足开发者对流量治理的需要。 ...

起源|阿里巴巴云原生公众号 2020 年，云原生曾经走进企业的实在业务场景，开启大规模落地，实现从技术价值到业务价值的微小转变。不论是云原生架构所带来的分布式、可扩大和灵便等个性，还是通过数据库、大数据、中间件、函数计算、容器服务等凋谢规范的云原生产品服务，无效升高企业上云的门槛，取得技术价值红利。2020 年的云原生能够说是整个云计算生态中倒退最迅速的一条主线脉络，而也正是随同着这样的倒退劲头，云原生在 2020 年一直拓展着其技术生态与利用场景。 Kubernetes 成为企业基础设施的规范形象，被越来越多企业和社区所认可，开发者、架构师应该如何更好施展其价值？被越来越多人提及的云原生架构，对于企业的业务架构、技术架构到底带来了什么样的影响？正如 2020 年阿里巴巴 双11 的大规模落地实际，云原生在越来越多业务场景开始落地实际，又哪些可供借鉴学习的最佳实际？ 为了让更多的开发者、架构师获取云原生所带来的技术红利与泛滥企业的实践经验，阿里巴巴云原生推出《云原生技术以及架构实际年货小红书》。 「年货亮点集锦」这其中包含阿里云云原生各路技术专家大神所撰写的共计 70 余万字、200 多篇的实际内容，全面内容涵盖 Spring Cloud Alibaba、K8s 等技术的一线实际案例。 CNCF TOC 张磊等诸多行业大咖所录制的超过 30 小时的云原生技术、Serverless、微服务实际教程。 此外，还有阿里云原生团队过来一年所筹备的各类专项电子书，如名列阿里云开发者社区下载量前茅的《云原生架构白皮书》、全面解析双十一技术实际的《阿里巴巴云原生大规模实际》多本精彩电子书。 「全书内容领先看」 「立刻下载」别再犹豫！满满干货，立刻支付！点击立刻下载年货小红书

Kubernetes 是以后寰球最风行的容器服务平台，在 Kubernetes 集群中，Dubbo 利用的部署形式往往须要借助第三方注册核心实现服务发现。Dubbo 与 Kubernetes 的调度体系的联合，能够让本来须要治理两套平台的运维老本大大减低，而且 Dubbo 适配了 Kubernetes 原生服务也能够让框架自身更加融入云原生体系。基于 Dubbo 3.0 的全新利用级服务发现模型能够更容易对齐 Kubernetes 的服务模型。Kubernetes Native Service 在 Kubernetes 中，Pod 是能够在 Kubernetes 中创立和治理的、最小的可部署的计算单元。通常一个 Pod 由一个或多个容器组成，利用则部署在容器内。 对于一组具备雷同性能的 Pod，Kubernetes 通过 Service 的概念定义了这样一组 Pod 的策略的形象，也即是 Kubernetes Service。这些被 Kubernetes Service 标记的 Pod 个别都是通过 Label Selector 决定的。 在 Kubernetes Service 内，服务节点被称为 Endpoint，这些 Endpoint 也就是对应提供服务的利用单元，通常一对一对应了 Pod。 因而，咱们能够将微服务中的利用自身应用 Service 来进行调度，而微服务间的调用通过 Service 的一系列机制来实现服务发现，进而将微服务整合进 Kubernetes Service 的体系中。 Dubbo 利用级服务发现在 Dubbo 体系结构内，为了更好地合乎 Java 开发人员的编程习惯，Dubbo 底层以接口粒度作为注册对象。然而这个模型对当初支流的 Spring Cloud 注册模型和 Kubernetes Service 注册模型有很大的区别。 ...

摘要: 高性能计算（HPC）在各个领域都有宽泛的利用。本文通过典型的HPC利用WRF，介绍了HPC利用在Kubernetes+Volcano上运行形式。Kubernetes曾经成为云原生利用编排、治理的事实标准，越来越多的利用抉择向K8S迁徙。HPC作为传统的分布式计算模式，在很多畛域都有着宽泛的利用，很多用户都心愿能将HPC利用迁徙到容器中运行，通过Kubernetes弱小的性能来进行作业管理。Volcano作为CNCF首个面向批量计算的散布式调度零碎，也反对MPI作业的调度，本文以传统的HPC利用WRF为例，探讨Volcano是如何反对HPC利用的。 HPC简介HPC是High Performance Computing（高性能计算）的缩写。平时提到的HPC，个别指代高性能计算机群（HPCC），它将大量的计算机软件/硬件整合起来，将大的计算作业分解成一个个小局部，通过并行计算的形式加以解决。HPC高性能计算在CAE仿真、动漫渲染、物理化学、石油勘探、生命科学、气象环境等畛域有宽泛的利用。 一般来说，高性能计算集群（HPCC）蕴含如下局部： • PBS：Protable Batch System，资源管理器，负责管理集群中所有节点的资源。除了PBS意外，罕用的资源管理零碎还有Slurm，LSF等 • Maui：第三方任务调度器，反对资源预留，反对各种简单的优先级策略，反对抢占机制等。资源管理器中内置了默认的工作调取器，但性能往往比较简单 • OpenMPI：下层通信环境，兼顾通信库，编译，分布式启动工作的性能 上述三局部中，PBS和Maui对于用户来说是齐全通明的，用户只须要依照PBS提供的形式提交作业即可，不须要理解外部细节。而OpenMPI则须要用户进行相干理解，来编写可能并行计算的利用。 上面以mpirun -np 4 ./mpi_hello_world为例介绍mpi作业是如何运行的： • 调用openmpi或者其余mpi的库来编写源代码，例子里就是输入hello world字符串了 • 应用反对MPI的编译器来编译出可执行程序mpi_hello_world • 将mpi_hello_world散发到各个节点，也能够通过共享文件系统来实现对mpi_hello_world的拜访 • 运行mpirun来并行执行mpi_hello_world WRF简介WRF是Weather Research and Forecasting Model（天气钻研和预报模型）的简称，是一种比拟常见的HPC利用。WRF是一种中尺度数值天气预报零碎，设计用于大气钻研和业务预报利用，能够依据理论的大气条件或理想化的条件进行模仿。 因为WRF蕴含多个模块，因而解决流程可能不尽相同，这里仅以WPS和WRF这两个模块为例介绍一下残缺的WRF流程： 该解决流程包含4局部： • 内部数据源 • 前解决零碎（WPS） • 外围模拟系统（WRF） • 后处理零碎 内部数据源蕴含动态天文数据，网络数据等。动态天文数据能够了解为某区域内的地理信息，例如山川，河流，湖泊，森林等等。网络数据是某区域内的气象环境数据，例如气温，风速风向，空气湿度，降雨量等等。 前解决零碎（WPS，WRF Pre-processing System）前解决零碎用于载入天文和气象数据，对气象数据进行插值，为WRF提供输出数据。该局部蕴含3个程序： • geogrid.exe：定义模型投影、区域范畴，嵌套关系，对地表参数进行插值，解决地形材料和网格数据 • ungrib.exe：从grib数据中提取所须要的气象参数 • metgrid.exe：将气象参数插值到模仿区域 通过这3个程序处理后，生成能够用来进行气象模仿的数据。这3个处理程序目前不反对mpi并行运算。 外围模拟系统（WRF）外围模拟系统对前解决系统生成的气象信息进行模仿和预报，是WRF的外围模块。该局部蕴含2个程序： • real.exe：初始化理论气象数据 • wrf.exe：模仿及预报后果 real.exe和wrf.exe能够通过mpi并行运算来晋升计算速度，例如 上图中wrfinput_d0X和wrfbdy_d0X为real.exe的运算后果，wrf.exe以该后果为输出进行模仿演算，生成最终的气象模仿后果wrfout_dxx_yyyy-mm-dd_hh:mm:ss，并由后处理零碎进行验证展现。 后处理零碎后处理零碎用来验证和显示外围模拟系统的计算结果。次要由各种第三方图像和验证工具组成。下图展现了Conus 2.5km算例中各个地区相对湿度的模仿预报后果： Conus 2.5km是指美国外乡气象数据，分辨率为2.5km（将整个区域分成一个个2.5km2.5km2.5km的方格，每个方格中的气象信息被认为是完全一致的）。 ...

10人将获赠CNCF商店$100美元礼券！ 你填了吗？ 问卷链接（https://www.wjx.cn/jq/9714648...） 客座文章作者：G-research 计算平台工程经理 Jamie Poole。博文最后在G-research 的博客上发表 在过来的几年中，咱们曾经将越来越多的工作负载迁徙到 Linux 上的容器中。一种对咱们来说十分重要的非凡类型的工作负载是运行到实现的批处理作业。咱们的大部分业务应用大型计算网格来执行分布式数据迷信和数值解决——在大型、嘈杂的真实世界数据集中寻找模式。直到最近，咱们次要是应用运行在 Windows 上的HTCondor来实现这一点。 迁徙到 Linux 和容器，咱们有机会从新评估咱们想要如何去做这件事。咱们尝试在 Condor 和 Linux 上运行容器化作业，但在去了一遍巴塞罗那的 KubeCon，并与其余一些钻研机构进行了交谈后，咱们感觉应用 Kubernetes 能够做得更好。咱们曾经在 Kubernetes 上运行了许多服务，因而领有一个具备 Kubernetes 所带来的所有操作和性能劣势的逻辑计算平台是很有吸引力的。 很显著，原味的 Kubernetes 不能满足咱们的用例。咱们有一个大型的、固定的 on-prem 计算池，Condor 模型的长处之一是，你能够提交比你的基础设施一次解决的更多的作业，多余的作业在内部排队，并应用偏心共享零碎进行优先级排序。咱们曾经晓得 Kubernetes 是容器编排的最佳种类，但在适度供给时，它不足对作业进行排队或偏心调度的能力。如果咱们可能启用这些额定的个性，咱们是否可能将 Kubernetes 也用于批处理作业基础架构，并为所有计算提供一个繁多的逻辑平台？ 咱们开始了一个外部试验，命名为 Armada。咱们有一些要害的架构准则要恪守： 编写一些软件来增加排队和偏心共享，而不须要批改 Kubernetes 自身。让 Kubernetes 来做节点调度和容器生命周期治理的艰辛工作。反对多个集群，这样咱们就能够超过单个 Kubernetes 集群的限度，并取得多个集群的操作劣势。咱们的指标是运行一个由数千台服务器组成的机队。应用基于拉的模型来取得工作，让咱们更容易扩充规模此外，咱们从一开始就心愿它是开源的。咱们曾经从开源技术中受害越来越多，尤其是 Kubernetes 自身。咱们认为，如果咱们可能生产出一些货色来解决咱们的问题，那么它很可能会对其他人有用，这可能是一个很好的机会来回馈咱们正在从中受害的生态系统。咱们没有太多建设绿地开源我的项目的教训，所以简略地在 GitHub 上开始，以确保咱们可能分享它。 咱们很快就产生了一个概念验证，并有了一个应用程序，咱们能够在 AWS 中应用它来证实 Kubernetes 可能在多个集群（每个集群有数百个节点）上运行数万个作业。重要的是，咱们可能证实，只有咱们在内部解决排队，Kubernetes 不须要进行任何非凡的调优，就能够解决数千个容器的启动和进行。 那么它是如何工作的呢？ Armada 的设计很简略。有一个地方服务器组件，用于存储要为不同用户或我的项目运行的作业队列。它负责保护整个零碎的状态。它有一个 API，容许客户端以 Kubernetes pod 标准的模式提交作业，还能够监督作业的进度或勾销作业。 在这上面，咱们有一个 executor 组件，它能够部署到任何给定的 Kubernetes 集群中，容许查看集群并发现有多少资源（例如 CPU/GPU/内存）可用。它定期与服务器组件分割并租用要运行的作业，而后在本地创立 pod，将进度报告给服务器组件。作业实现后，将清理 pod，并为下一个作业提供空间。 ...

该文章是基于阿里云商业化产品 EDAS 3.0的微服务实际，如果您的团队具备较强的微服务测试能力，那么心愿咱们在微服务测试方面的实际和背地的思考，能够为您提供一些参考。 前言随着云原生时代的到来，越来越多的利用生在云上，长在云上，且随着越来越多的企业开始上云，云原生也是企业落地微服务的最佳伴侣。但云上利用易测性受到了很大的挑战，如何进步云上利用易测性，加强DevOps能力，是微服务测试要解决的外围问题。在具体讲述微服务测试之前，先给大家讲一个场景。 上图是一个典型的企业微服务利用架构图，为了思考安全性，云上利用通常部署在云上虚构局域网内，对立通过网关对外裸露服务。对于负责 Product Service 利用的同学来说，我只想测试一下该利用对应的服务是否可用，他会怎么做呢？ 计划一：进入该利用部署所在的机器（ECS）或者容器（Pod），通过 curl 命令验证该服务是否可用。计划二：将该利用裸露给公网拜访，通过本地命令行工具或者 Postman 工具验证该服务是否可用。计划三：拉一条网络专线，买通云上专有网络VPC与办公网网络，通过本地命令行工具或者 Postman 工具验证该服务是否可用。从以上场景，咱们能够总结出云上微服务测试几点问题： 云上网络拓扑简单裸露公网拜访，会呈现黑客攻击，引发平安危险拉一条网络专线，浪费资源老本明明只想要一个简略的测试能力，老本缺如此之高。上述场景还仅仅是一个简略的调试性能，如果是压测、自动化回归、巡检等其余测试及稳定性保障伎俩，不仅仅要解决上述场景遇到的问题，还须要自建工具，脑补一下，都感觉老本太高，因而，咱们须要微服务测试来帮忙咱们解决这些问题，进一步减速软件交付效率。 为什么咱们须要微服务测试产品能力提供测试、压测、自动化回归、巡检等能力，造成一个微服务测试解决方案： 试想一下，研发同学提交代码并部署，能够应用测试工具，验证服务逻辑正确性；能够应用压测工具，验证服务性能指标；验证通过后，开始进行冒烟测试，能够应用自动化回归工具，编写冒烟用例；冒烟通过后，开始进行历史性能回归，能够应用自动化回归工具，编写回归用例；回归通过后，提交测试验收，测试只须要验证新性能，新性能验证通过后，即可提交公布。公布后，进行线上环境验证，须要回归历史性能主流程，能够应用自动化回归工具，编写主流程回归用例，新性能手工验证；主流程回归通过且新性能验证通过，代表公布实现；研发同学，能够应用巡检工具，配置线上巡检；一旦巡检告警，即可先于用户发现问题，并解决问题。咱们是将阿里巴巴积淀的测试解决方案产品化输入，帮忙云上业务实现高质量地实现疾速交付。 易用且平安开箱即用，无需关注专有网络VPC下的网络拓扑；安全可靠，领有在办公网下的测试体验。试想一下，企业为了平安隔离，研发环境、测试环境、预发环境、生产环境部署在不同的专有网络VPC内，如果用户自建测试工具，须要解决测试工具到不同环境的网络互通问题，企业IT人员明明只想要一个简略的测试工具，却因为上云之后，要解决简单的云上网络拓扑，远远没有完结，为了可能在办公网应用该测试工具，还须要保障该测试工具可能被办公网拜访，此时又面临着网络安全的考验。咱们心愿有一个可能开箱即用且安全可靠的计划，可能让上云的企业IT人员领有在办公网测试体验的测试工具。 低成本弹性拉起测试机/施压机，用完销毁，可能大幅度降低构建测试工具须要的机器资源及人力老本。 试想一下，企业上云是为了降低成本，利用托管极大地升高了资源老本和运维老本，但测试老本并没有升高。企业IT人员自建测试工具须要筹备测试机/施压机，该局部机器长期占用且存在闲置，资源老本开销大，尤其是在性能压测场景，资源老本开销会更大。除了资源老本外，企业IT人员还须要研发测试工具，人力老本及工夫老本十分高，基本上每个企业都须要一套测试工具。咱们心愿有一个低成本的计划，不仅进步企业的资源利用率，同时升高企业IT人员开发和保护测试工具的老本。 微服务生态云上已提供了大量的微服务产品，解决了微服务利用的托管、治理、诊断，微服务测试补齐微服务能力。 试想一下，如何测试一个微服务接口，须要理解接口入参和出参，如果是研发同学-服务提供者，可能比拟相熟该接口，如果是测试同学，甚至是其余研发同学，可能就须要文档，甚至是口口相传，微服务治理曾经可视化利用的服务契约信息，联合服务契约信息，只需依照测试须要，抉择利用->框架->服务->办法，配置测试参数，即可进行测试，升高了服务契约同步的老本。 联合上述4点，测试同学只需负责用例编写+测试验收，接口调试、接口性能水位、用例自动化均可赋能给研发同学，就像晚期DevOps一样，升高研发运维之间的反馈回路，进步软件交付效率，DevTest，升高研发测试之间的反馈回路，在保障交付品质的前提下，进一步晋升软件交付效率，同时被动创立巡检工作，定时监控线上服务可用率，先于用户发现问题，解决问题。 EDAS3.0 微服务测试实际前提条件：微服务利用已接入EDAS3.0上面咱们来体验一下，EDAS上如何应用微服务测试的能力。 服务测试登录EDAS控制台，在页面左上角抉择地区；左侧导航栏抉择：微服务治理 -> Spring Cloud -> 服务测试 -> 查问服务；单击某个服务的详情 -> 展现元数据列表；单击某个办法的测试 -> 进入测试页面（已帮忙用户填充参数模板）；点击执行即可。 服务压测登录EDAS控制台，在页面左上角抉择地区；左侧导航栏抉择：微服务治理 -> Spring Cloud -> 服务压测 -> 创立场景；抉择须要压测的利用 -> 抉择框架 -> 抉择服务 -> 抉择办法；填写压测参数，点击确认；进入压测场景列表页，点击详情；进入压测详情页，点击启动，期待施压机准备就绪；点击详情，进入压测性能数据报告页，实时查看性能数据； 自动化回归登录EDAS控制台，在页面左上角抉择地区；左侧导航栏抉择：微服务治理 -> Spring Cloud -> 自动化回归 -> 创立用例；增加步骤抉择利用 -> 抉择框架 -> 抉择服务 -> 抉择办法；填写参数；断言/出参提取；能够增加多个步骤；保留用例；点击执行；通过执行历史，查看用例是否通过； ...

作者 | 张裕编辑 | 雅纯起源|阿里巴巴云原生公众号 什么是云原生 DevOps点击查看视频：https://v.qq.com/x/page/u3220cutt7v.html 咱们先通过下面一个简短视频和上面两张图，来理解什么是云原生 DevOps，它和 DevOps 有什么不同。 上图是一个大排档，图中的大厨在十分致力的去切、炒、制作各种美食，并将它卖出去。从原材料的洽购到加工到销售到售后，都是一两个人实现。这是十分典型的 DevOps 场景，团队搞定端到端的所有的事件。这种状况，当厨师程度比拟高、销售能力比拟强的时候，能够做到高效率、低节约。但存在的问题是，想要规模化会很难。因为它的流程都是非规范的，须要厨师有很强的集体能力。 咱们再看下面这张南京大排档的图，尽管名字里有大排档，但它显然不是咱们下面说的大排档。咱们轻易走进任何一家南京大排档，都能够发现，南京大排档的厨师，能够专一在为客户提供更好的菜品上，研发试验新菜品，并通过小批量的用户来尝试和推广。无论是用户量减少或缩小，都能很快的去适应。店铺扩张也能够很快。这种咱们能够了解为云原生 DevOps。 那到底什么是云原生 DevOps 呢？咱们认为：云原生 DevOps 是充分利用云原生基础设施，基于微服务/无服务架构体系和开源规范，语言和框架无关，具备继续交付和智能自运维能力，从而做到比传统 DevOps 更高的服务质量、更低的开发运维老本，让研发专一于业务的疾速迭代。 如上图所示，云原生 DevOps 基于 2 个准则：合乎凋谢规范、语言和框架无关；有 2 个根底：微服务/无服务架构、Serverless 基础设施 BaaS/FaaS；提供 2 个能力：智能自运维、继续交付。  2 个准则：合乎凋谢规范、语言和框架无关。相比于针对某个特定语言、特定框架，在技术升级或迭代时能够有更高的弹性、更好的倒退和生命力，造成更好的生态。2 个根底：基于微服务和无服务架构，能够让 DevOps 成为可能；基于 Serverless 的基础设施，是面向资源和需要，以达到更好的弹性。在这 2 个准则和 2 个根底之上，做到 2 个能力：继续交付和智能自运维。阿里巴巴云原生 DevOps 降级案例咱们先来看一个阿里某团队云原生 DevOps 转型的案例。 案例背景：阿里某海内电商团队面临海内市场站点多、建站老本高、需要变动快、交付慢、运维老本低等挑战，如何平滑地降级到云原生 DevOps 来解决这些问题，以晋升业务交付效率呢？咱们是这么做的。 1. 架构降级 - 服务治理 sidecar 和 mesh 化 第一步是架构降级，首先将服务治理的代码下沉到利用之外的 sidecar 局部，同时用服务网格来承载了如环境路由之类的能力。如上图所示，每个绿点代表一个服务利用代码，每一个橘点代表一个服务治理代码，这些代码以二方包的模式存在这个容器中。随着服务治理体系的建设，这外面就蕴含了十分多的货色，如日志采集、监控埋点、运维干涉等等，咱们把这种容器称之为富容器。它的问题很显著：即使是日志采集的降级或调整，咱们都须要把利用从新降级、构建和部署一遍。然而这个其实与利用自身是没有任何关系的。同时，因为关注点不拆散，日志采集的一个 bug，都会影响到利用自身。 本着让利用能更专一于利用自身的目标，咱们做的第一件事就是把所有服务治理的代码从利用容器中剥离进去，放到了 sidecar 外面，这样服务治理和利用的代码就存在两个容器里了。同时咱们又把原来服务治理的一些事件，比方测试路由、链路追踪等交给了 Mesh sidecar 。这样利用就瘦身了，利用只须要关怀利用代码的自身。 ...

一、背景 咱们晓得，容器运行起来的工夫是十分快的，然而如果节点上容器的镜像不存在，那么在运行容器时要先拉取镜像，拉取镜像在容器启动的过程中占用的工夫比拟长，这个过程要将容器所有的镜像层都拉取到本地磁盘中。据统计，拉镜像操作要占用容器启动工夫的76%。这在容器数量少的状况下问题不大，但容器数量比拟多并且都是冷启动的时候会十分的慢。 如何解决容器冷启动过程中拉取镜像慢这个问题？有这样的一种解决思路：在容器启动过程中，容器要用的镜像通过高速网络按需从镜像仓库中读取，而不是将镜像所有的层都拉下来。Stargz-snapshotter是containerd上面的一个子项目，以Proxy Plugin的形式扩大containerd的性能，是Containerd的一个remote-snapshotter实现。 版本变迁 二、应用 Stargz-snapshotter在kuberentes中应用比较简单：应用Containerd作为kuberentes的CRI运行时。在本地起一个stargz-snapshotter的服务，作为containerd的一个remote snapshotter。 镜像转换 在应用前须要将咱们的一般的镜像转换成stargz-snapshotter能够辨认的镜像，应用ctr-remote工具进行转换，上面示例是将本地一个centos镜像进行转换，转换实现后推送到镜像仓库中： $ ctr-remote image optimize --plain-http --entrypoint='[ "sleep" ]' --args='[ "3000" ]' centos:7 centos:7-eg复制代码 比照 应用crictl工具在本地拉取转换前和转换后的镜像，做一下比照，通过lazy的形式拉取镜像的速度更快： 失常拉取镜像$ time crictl pull centos:7Image is up to date for sha256:ef8f4eaacef5da519df36f0462e280c77f8125870dbb77e85c898c87fdbbea27real  0m5.967suser  0m0.009ssys  0m0.012s 拉取优化后的镜像$ time crictl pull centos:7-egImage is up to date for sha256:36edf0c0bb4daca572ba284057960f1441b14e0d21d5e497cb47646a22f653d6real  0m0.624suser  0m0.012ssys  0m0.010s复制代码 查看镜像层 应用crictl创立一个pod，进入容器中，查看/.stargz-snapshotter/目录下各个镜像层在本地缓存的状况： $ cat /.stargz-snapshotter/*{"digest":"sha256:857949cb596c96cc9e91156bf7587a105a2e1bc1e6db1b9507596a24a80f351a","size":80005845,"fetchedSize":3055845,"fetchedPercent":3.819527185794988}{"digest":"sha256:8c57b1a6bef1480562bc27d145f6d371955e1f1901ebdea590f38bfedd6e17d0","size":33614550,"fetchedSize":64550,"fetchedPercent":0.19202993941611593}复制代码 三、原理 上图是stargz-snapshotter的实现概览，通常的咱们在拉取镜像时，要将镜像的每一层拉取下来，而应用stargz-snapshotter后containerd不再是拉取镜像的层，而是为存储在镜像仓库中镜像的每一层在容器运行节点上创立一个目录，通过近程挂载的形式挂到各个目录上。容器启动前再将各个目录做overlay挂载，为容器提供一个rootfs。当须要读取某个文件时，通过网络读取镜像仓库中镜像层中的文件。 上面再看一下镜像层是怎么近程挂载和如何从镜像层中按需读取文件的。 用户态文件系统 Stargz-snapshotter应用FUSE实现了用户态的文件系统。FUSE（Filesystem in userspace）框架是一个内核模块，可能让用户在用户空间实现文件系统并且挂载到某个目录，就像在内核实现文件系统一样。 如上图所示，stargz-snapshotter是一个实现了用户态文件系统的程序（golang语言，应用go-fuse作为实现的依赖）。当有拉取镜像的操作产生时，stargz-snapshotter会为镜像的每一层在${stargz-root}/snapshotter/snapshots/下创立一个目录，执行实现一个文件系统的逻辑，并将这个文件系统挂载到刚创立的目录上，例如图中的/dcos/snapshotter/snapshots/1。当有用户读取目录下的文件时，申请的流向是这样的： ...

作者 | 张杰（冰羽）起源|阿里巴巴云原生公众号 简介OpenYurt 是由阿里云开源的基于原生 Kubernetes 构建的、业内首个对于 Kubernetes 非侵入式的边缘计算我的项目，指标是扩大 Kubernetes 以无缝反对边缘计算场景。它提供了残缺的 Kubernetes API 兼容性；反对所有 Kubernetes 工作负载、服务、运营商、CNI 插件和 CSI 插件；提供良好的节点自治能力，即便边缘节点与云端断网，在边缘节点中运行的应用程序也不会受影响。OpenYurt 能够轻松部署在任何 Kubernetes 集群服务中，让弱小的云原生能力扩大到边缘。 OpenYurt v0.3.0 重磅公布北京工夫 2020 年 11 月 8 号，Openyurt 公布 v0.3.0 版本，首次提出节点池和单元化部署概念，新增云端 Yurt-App-Manager 组件，全面晋升在边缘场景下的利用部署效率，升高边缘节点和利用运维的复杂度。全面优化 yurthub、yurt-tunnel 外围组件的性能，yurtctl 提供 kubeadm 的 provider，能够疾速不便地将由 kubeadm 创立的 Kubernetes 集群转换成 Openyurt 集群。 1. Yurt-App-Manger 为边缘利用运维而生通过与社区同学的宽泛探讨，OpenYurt 提供 OpenYurt Yurt-App-Manager 组件。Yurt-App-Manager 是 Kubernetes 的一个规范扩大，它能够配合 Kubernetes 应用，提供 NodePool 和 UnitedDeployment 两种控制器，从主机维度和利用维度来提供边缘场景下节点和利用的运维能力。 1）节点池：NodePool在边缘场景下，边缘节点通常具备很强的区域性、地域性、或者其余逻辑上的分组个性（比方雷同 CPU 架构、同一个运营商、云提供商），不同分组的节点间往往存在网络不互通、资源不共享、资源异构、利用独立等显著的隔离属性，这也是 NodePool 的由来。 ...

简介趣店的容器化过程经验过三个里程碑：docker、单集群脚本化治理、多集群平台化治理。为了兼顾日常业务的需要开发，每一个里程均是由小局部人主导推动，由点及面地进行推广，并通过在小范畴的试错中寻找最适宜趣店业务场景的容器化计划。容器化为趣店的服务隔离及服务器统一化治理提供了根底条件，并且通过容器化迁徙为趣店每月节俭至多10万元服务器费用。（因为迁徙工作以PHP服务作为试点，因而本文中的案例亦是以PHP为主）趣店容器进化史疾速预览图 Docker作为容器化推动的第一阶段，此阶段由开发主导，推广开发及测试环境容器化应用，并进行小局部服务线上容器化试用。Docker入门容器化推动初期，此时咱们外部对于容器较为理解的人员并不多，开发不晓得应该如何应用容器，运维对于如何保护容器下的服务也没有教训，因而在这个阶段咱们着重对整体开发人员及运维人员进行高级容器入门分享，分享次要包含以下几个方面：Docker环境搭建次要用于疏导开发人员搭建本地Docker开发环境，进行初步的容器概念建模。Docker命令解析docker命令解析分享材料 该分享次要解说Docker的罕用指令、拆解容器的部署流程并简要介绍通过Swarm进行集群部署的形式。Dockerfile最佳实际参考《Best practices for writing Dockerfiles》，分享如何以更优雅的形式编写Dockerfile。Docker编排咱们的局部开发人员尝试更深层次地利用容器化，例如基于docker-compose推广docker在本地开发环境落地。这一推广对于微服务一类单个我的项目依靠于多个服务的开发环境部署提供了极大的便当，同时也在开发环境的应用中进一步深入大家对容器的了解。在这一阶段开发了繁难的K8s编排脚本，对新上线的小服务尝试应用K8s部署服务。单集群脚本化治理思考到容器化仍处于尝试阶段且须要进行定制化脚本开发，因而第二阶段仍是以开发作为主导。本阶段开始对次要服务的小流量环境进行容器化迁徙，通过开发更欠缺的K8s编排脚本以优化服务的继续集成与部署。容器化服务迁徙随着全员对容器认知程度的进步，在这一阶段咱们的小局部开发开始尝试进行线上小流量环境的迁徙，迁徙过程也曾遇到一些问题。坑CoreDNS负载异样导致局部申请谬误景象：在这一阶段的迁徙过程中因为K8s的CoreDNS负载异样，咱们已迁徙服务曾呈现短暂的不可用（因服务分区部署的关系咱们及时将部署于K8s服务的服务流量摘除）解决方案：容器化迁徙是各方（运维、开发、K8s服务提供商）的磨合阶段，在这一阶段应提前准备及演练运行于K8s的服务异常情况下的流量切换计划。因为业务服务对K8s根底服务的强依赖关系，根底服务的监控、异样转移均需提前欠缺及演练。 镜像治理镜像治理作为容器化迁徙不可或缺的一部分，自建的镜像仓库可能更好的保障外部服务镜像的安全性（镜像可能蕴含服务源码），且部署于内网的镜像仓库可能极大进步部署速度。为简化镜像的治理与保护，咱们在内网部署开源的Harbor服务治理外部镜像。CI/CD在这一阶段咱们通过自研的脚本（集成编排文件生成、镜像构建、部署）及Jenkins实现服务的CI/CD。因为这一阶段的CI/CD流程仍是试验阶段并无非常欠缺，这里临时不开展叙述，较为欠缺的流程可参考下一阶段迁徙的CI/CD。日志收集编排日志编排日志目前咱们没有特意收集，大部分状况下还是部署或者调度呈现问题的时候由运维进入集群内通过Kubectl查看日志状况。容器日志因为大部分服务的日志都是往指定目录输入，目前并没有很好的利用容器的规范输入作为容器外部服务日志输入的对立进口，所以容器日志以后仍处于待开掘阶段。服务日志 NginxPHP除去惯例的Nginx access_log，咱们在迁徙过程中还须要重点关注Nginx error_log及PHP error_log，极少局部申请可能会因迁徙过程中的操作不当而引发异样，此时可通过排查服务的谬误日志及时发现并修复问题。业务日志因为咱们的业务日志输入并无对立标准，因而无奈通过惯例的容器规范输入采集日志，而是通过Volume的形式将Pod的输入日志挂载至节点主机目录，再通过节点主机的Filebeat + Kafka将日志对立收集至日志服务器。监控宿主机资源监控（Master、Node）主机的资源监控包含：CPU、内存、磁盘、网卡流量等等，尽可能具体地收集主机监控信息对于异常情况下的问题排查有着极大的帮忙。根底组件监控（如：CoreDNS）围绕于集群服务的各种根底组件：kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy、CoreDNS等等，也须要纳入监控范畴，防止因为单个根底组件的异样影响整个集群外部业务服务的稳定性。Pod NginxPHP-FPMPod部署了可用于输入Nginx-FPM和PHP实时状态的Exporter，通过惯例的Prometheus + Grafana计划实现K8s服务的监控。网络拓扑NodePortServicePod在这一阶段思考到现有服务是逐渐迁徙，为放弃原有线上灰度测试计划的可用性，并未应用惯例的Ingress作为内部流量的入口。多集群平台化治理最终阶段咱们基于开源平台进行二次定制化开发，由运维、开发独特主导。这一阶段的次要工作是通过定制化开发买通 开发-测试-审批-线上部署 的残缺流程，并对现有的线上服务全量迁徙至K8s集群。开源平台选型Wayne（360）Rancher（Rancher Labs）KubeSphere（青云）tke（腾讯）K8s多集群治理平台比照 在最开始的开源平台选型阶段咱们综合比照了目前较为支流的4大开源平台：Wayne、Rancher、KubeSphere、tke，因为咱们现有业务均为多区部署因而平台是否反对多集群治理成为咱们最重要的考查因素。各项因素综合比照后最终咱们选用Wayne作为根底进行二次定制化开发。然而因为咱们基于Wayne开发的版本360团队有较长时间未更新保护，导致最新版须要修复大量bug后能力失常应用。阐明：此比照截止工夫为2019年12月，此期间各平台可能有新的性能迭代 网络拓扑IngressServicePod因为咱们的服务大部分为微服务，持续应用Nodeport的形式每个我的项目均须要占用大量的集群端口号，因而在全量服务迁徙阶段咱们调整为应用惯例的Ingress作为内部流量的入口。CI/CD在这一阶段咱们进一步对CI/CD流程进行了欠缺，镜像通过CI Runner的形式主动构建，缩小上线过程的等待时间，并通过界面化的形式实现多集群部署，买通从镜像构建、审批、部署上线的残缺流程。镜像构建流程镜像构建流程 由上图能够看出，通过Gitlab的CI流程咱们欠缺了代码合并后主动构建镜像并推送镜像至镜像仓库的流程。在K8s接口化的服务端咱们已提前配置好每个服务的Deployment根底模板，构建胜利后调用接口写入对应版本信息即可生成待发布的Deployment模版。代码上线流程代码上线流程 因为咱们的代码上线过程须要监测每次上线是否会对线上数据造成稳定，因而上线环节全程由开发手动在平台化后盾操作没有实现全流程自动化。配置上线流程ENV上线流程 配置上线则绝对简略大部分配置变更后只须要重启Pod即可，因而这一部分做了自动化解决。平台化服务迁徙平台化服务迁徙对于运维的工作量较大，因为各服务配置差别较大，运维须要依据每个服务的不同配置Deployment根底模板。而咱们数百个微服务因为种种历史起因没有放弃环境对立，运维梳理环境迁徙服务的过程中容易疏漏一些轻微的环境配置差别，有些差别可能又是在小局部场景下才会触发异样，因而也列出来便于大家避坑。坑Pod可用连接数有余预期景象：在线上压测过程发现部署于K8s中的服务当单Pod QPS达到1万左右开始呈现TCP连贯异样，无奈持续增压。解决方案：单Pod可用的连接数极大的依赖于节点服务器，单Pod无奈撑持更大连接数时需思考调优各节点服务器的内核参数，如调整最大关上文件限度（包含用户级别与零碎级别）、最大追踪TCP连接数、零碎TIME_WAIT数量等。 单行大日志景象：Filebeat采集的日志中呈现局部业务日志失落。解决方案：因为Kafka对单条音讯大小的限度，如果单行日志过大会导致日志无奈被采集，此时应标准业务日志的输入，避免出现单行大日志。 上传文件/POST大小限度景象：流量从物理机器迁徙至K8s后局部服务申请呈现 HTTP Code 413 或上游服务接管到的申请数据为空。解决方案：Nginx及PHP-FPM层面对上传文件大小、POST body大小均有限度，因而须要将限度大小配置值调整至与原物理机器统一。 服务内存大小限度景象：服务从物理机器迁徙至K8s后局部打算工作无奈失常执行，局部后盾异步导出队列执行异样。解决方案：通常状况下咱们会应用一台物理服务器同时部署服务喝执行打算工作，而大部分打算工作、队列可能须要应用大量的内存用于统计之类的逻辑，此时应调整K8s打算工作及队列Pod的内存下限限度，同时可能还须要批改PHP的内存大小限度，并视打算工作状况调整最大执行工夫防止因打算工作超时触发失败重试。 局部节点资源负载异样景象：单K8s集群中呈现小局部节点资源负载较高，而其余节点较为闲暇。解决方案：此时可通过K8s的反亲和性配置将重资源的Pod扩散部署在各节点服务器中，防止小局部节点服务器同时部署重资源Pod呈现资源争抢。 根底镜像调优实践与实际（单服务容器 VS 多服务容器）对于单Pod是部署单服务还是多服务应视业务状况而定。例如，对于须要提供界面的PHP服务咱们举荐应用多服务的形式，依赖Supervisor将Nginx、PHP-FPM部署于同一个Pod中，这样能够升高Nginx需同时解决FastCGI申请及动态资源申请带来的K8s部署模板配置复杂度。然而单Pod部署多服务的场景需额定留神对各服务的可用性监控，避免出现其中的某个服务异样而K8s无奈探测的状况。可配置 NginxPHP-FPM根底镜像的可配置对于容器化迁徙至关重要，咱们倡议用尽可能少的根底镜像通过可配置的形式实现对各种不同服务部署环境的兼容，升高服务环境差别带来的根底镜像保护老本。例如将Nginx、PHP-FPM的上传文件大小限度、内存大小限度等参数通过环境变量的形式，利用Entrypoint机制在启动Supervisor前先执行shell实现对环境配置的定制化替换。运行模式可切换 PHP-FPMCLI（队列/打算工作）Swoole因为PHP服务通常以多种形式联合应用，因而通过环境变量配置的形式，咱们的根底镜像亦反对多种运行模式按需切换，进步根底镜像的可复用性。PHP7根底镜像示例 Dockerfile示例FROM php:7.0-fpm-stretchLABEL maintainer="zhoushangzhi <zhoushangzhi@qudian.com>"COPY sources-aliyun-0.list /etc/apt/sources.list.d/sources-aliyun-0.listRUN mv /etc/apt/sources.list /etc/apt/sources.list.bak \ && touch /etc/apt/sources.list \ && apt-get update \ && apt-get install -y --no-install-recommends apt-utils \ libcurl4-gnutls-dev \ libxslt-dev \ libmagickwand-dev \ gnupg \ ca-certificates \ && apt-get install -y nscd \ supervisor \ procps \ libpng-dev \ libgettextpo-dev \ libmcrypt-dev \ libxml2-dev \ libfreetype6 \ libfreetype6-dev \ libpng16-16 \ libjpeg62-turbo \ libjpeg62-turbo-dev \ libmemcachedutil2 \ libmemcached-dev \ zlib1g \ zlib1g-dev \ $PHPIZE_DEPS \ wget \ unzip \ vim \ git \ && wget -O - https://openresty.org/package/pubkey.gpg | apt-key add - \ && apt-get -y install --no-install-recommends software-properties-common \ && add-apt-repository -y "deb http://openresty.org/package/debian $(lsb_release -sc) openresty" \ && apt-get update \ && apt-get -y install --no-install-recommends openresty \ && mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini" \ && docker-php-ext-configure gd \ --with-gd \ --with-freetype-dir=/usr/include/ \ --with-png-dir=/usr/include/ \ --with-gettext=/usr/include/ \ --with-mcrypt=/usr/include/ \ --with-jpeg-dir=/usr/include/ && \ NPROC=4 \ && docker-php-ext-install -j${NPROC} mysqli \ pdo_mysql \ bcmath \ calendar \ exif \ gd \ gettext \ mcrypt \ pcntl \ shmop \ sockets \ sysvmsg \ sysvsem \ sysvshm \ opcache \ zip \ wddx \ xsl \ && pecl install msgpack imagick \ && cd /tmp \ && wget https://github.com/igbinary/igbinary/archive/2.0.4.zip \ && unzip 2.0.4.zip \ && cd igbinary-2.0.4 \ && phpize && ./configure --with-php-config=php-config \ && make && make install \ && echo "extension=igbinary.so" > /usr/local/etc/php/conf.d/igbinary.ini \ && cd /tmp \ && wget https://github.com/php-memcached-dev/php-memcached/archive/php7.zip \ && unzip php7.zip \ && cd php-memcached-php7 \ && phpize \ && ./configure --prefix=/usr \ --enable-memcached-sasl \ --with-php-config=php-config \ --enable-memcached-igbinary \ --enable-memcached-json \ --enable-memcached-msgpack \ && make \ && make INSTALL_ROOT="" install \ && install -d "/etc/php7/conf.d" \ && echo "extension=memcached.so" > /usr/local/etc/php/conf.d/memcached.ini \ && cd /tmp \ && wget https://github.com/phpredis/phpredis/archive/3.1.2.zip \ && unzip 3.1.2.zip \ && cd phpredis-3.1.2 \ && phpize \ && ./configure --enable-redis-igbinary --with-php-config=php-config \ && make \ && make install \ && echo "extension=redis.so" > /usr/local/etc/php/conf.d/redis.ini \ && cd /tmp \ && wget https://github.com/swoole/swoole-src/archive/v2.0.6.tar.gz \ && tar zxvf v2.0.6.tar.gz \ && cd swoole-src-2.0.6 \ && phpize \ && ./configure \ && make \ && make install \ && echo "extension=swoole.so" > /usr/local/etc/php/conf.d/swoole.ini \ && docker-php-ext-enable igbinary redis msgpack imagick \ && rm -rf /tmp/* \ && rm -rf /var/lib/apt/lists/* \ && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeCOPY nscd.conf /etc/nscd.confCOPY ./openresty /templatesCOPY ./supervisor/conf.d/ /etc/supervisor/conf.d/# add php-fpm-exporterCOPY ./bin/php-fpm_exporter_1.1.0_linux_amd64 /usr/local/bin/php-fpm-exporter# nginx rootENV INDEX_PATH=public# nginx model, fpm/upstreamENV MODE=fpm# nginx upstream portENV NGINX_UPSTREAM_PORT=12151# nginx fpm passENV NGINX_FPM_PASS=localhost# nginx upstream urlENV NGINX_UPSTREAM_URL=localhost# nginx worker numENV NGINX_WORKER_NUM=4# fpm max childrenENV FPM_MAX_CHILDREN=100# fpm start serverENV FPM_START_SERVERS=20# fpm max spare serverENV FPM_MAX_SPARE_SERVERS=60# fpm min spare serverENV FPM_MIN_SPARE_SERVERS=20# fpm max requestENV FPM_MAX_REQUESTS=1000# wether auto start nscdENV NSCD_START=true# wether auto start nginxENV NGINX_START=true# wether use supervisor to start init commandENV SUPERVISOR_START=true# exec before startENV POST_START=""# wether auto start nscdENV INIT_CMD_START=true# init commandENV INIT_CMD="php-fpm --nodaemonize"# init command process num, only use supervisor start avaliableENV INIT_CMD_PROCESS_NUM=1# wether auto start exporterENV EXPORTER_START=true# exporter listen address,see more:https://github.com/hipages/php-fpm_exporterENV PHP_FPM_WEB_LISTEN_ADDRESS=0.0.0.0:9146# php log 二级模块目录ENV PHP_LOG_SUB_MODULE="/"# php-fpm memory limitENV FPM_MEMORY_LIMIT=32M# php-cli memory limitENV PHP_MEMORY_LIMIT=128M# php upload_max_filesizeENV PHP_UPLOAD_MAX_FILESIZE=2M# php post_max_sizeENV PHP_POST_MAX_SIZE=8M # php error_log fileENV PHP_ERROR_LOGFILE=/tmp/php-error.log# nginx_client_max_body_sizeENV CLIENT_MAX_BODY_SIZE=20M# nginx_client_max_buffer_sizeENV CLIENT_BODY_BUFFER_SIZE=1MWORKDIR /home/apple/webEXPOSE 80COPY entrypoint.sh /usr/local/bin/CMD ["/bin/bash", "/usr/local/bin/entrypoint.sh"]Entrypoint示例#!/bin/bashecho "replacing config"set -xe \ && mkdir -p /etc/nginx/conf.d/ \ && mkdir -p /var/run/nscd/ \ && mkdir -p /var/log/nginx/ \ && if [ "fpm" = "$MODE" ]; then cp /templates/fpm.conf.template /etc/nginx/conf.d/default.conf; else cp /templates/upstream.conf.template /etc/nginx/conf.d/default.conf; fi \ && cp /templates/prometheus.lua /usr/local/openresty/site/lualib/prometheus.lua \ && cp /templates/nginx.conf /usr/local/openresty/nginx/conf/nginx.conf \ && sed -i "s|__CLIENT_MAX_BODY_SIZE__|$CLIENT_MAX_BODY_SIZE|" /usr/local/openresty/nginx/conf/nginx.conf \ && sed -i "s|__CLIENT_BODY_BUFFER_SIZE__|$CLIENT_BODY_BUFFER_SIZE|" /usr/local/openresty/nginx/conf/nginx.conf \ && sed -i "s|__NGINX_INDEX_PATH__|$INDEX_PATH|" /etc/nginx/conf.d/default.conf \ && sed -i "s|__NGINX_UPSTREAM_PORT__|$NGINX_UPSTREAM_PORT|" /etc/nginx/conf.d/default.conf \ && sed -i "s|__NGINX_FPM_PASS__|$NGINX_FPM_PASS|" /etc/nginx/conf.d/default.conf \ && sed -i "s|__NGINX_UPSTREAM_URL__|$NGINX_UPSTREAM_URL|" /etc/nginx/conf.d/default.conf \ && sed -i "s|__NGINX_WORKER_NUM__|$NGINX_WORKER_NUM|" /usr/local/openresty/nginx/conf/nginx.conf \ && sed -i "s|;pm.status_path = /status|pm.status_path = /status|" /usr/local/etc/php-fpm.d/www.conf\ && sed -i "s|pm.max_children = 5|pm.max_children = $FPM_MAX_CHILDREN|i" /usr/local/etc/php-fpm.d/www.conf \ && sed -i "s|pm.start_servers = 2|pm.start_servers = $FPM_START_SERVERS|i" /usr/local/etc/php-fpm.d/www.conf \ && sed -i "s|pm.max_spare_servers = 3|pm.max_spare_servers = $FPM_MAX_SPARE_SERVERS|i" /usr/local/etc/php-fpm.d/www.conf \ && sed -i "s|pm.min_spare_servers = 1|pm.min_spare_servers = $FPM_MIN_SPARE_SERVERS|i" /usr/local/etc/php-fpm.d/www.conf \ && sed -i "s|;pm.max_requests = 500|pm.max_requests = $FPM_MAX_REQUESTS|i" /usr/local/etc/php-fpm.d/www.conf \ && sed -i "s|;php_admin_value\[memory_limit\] = 32M|php_admin_value\[memory_limit\] = $FPM_MEMORY_LIMIT|i" /usr/local/etc/php-fpm.d/www.conf \ && sed -i "s|memory_limit = 128M|memory_limit = $PHP_MEMORY_LIMIT|i" /usr/local/etc/php/php.ini \ && sed -i "s|upload_max_filesize = 2M|upload_max_filesize = $PHP_UPLOAD_MAX_FILESIZE|i" /usr/local/etc/php/php.ini \ && sed -i "s|post_max_size = 8M|post_max_size = $PHP_POST_MAX_SIZE|i" /usr/local/etc/php/php.ini \ && sed -i "s|;error_log = php_errors.log|error_log = $PHP_ERROR_LOGFILE|i" /usr/local/etc/php/php.ini \ && sed -i "s|expose_php = On|expose_php = Off|i" /usr/local/etc/php/php.ini \ && sed -i "s|__INIT_CMD__|$INIT_CMD|" /etc/supervisor/conf.d/php.conf \ && sed -i "s|__INIT_CMD_PROCESS_NUM__|$INIT_CMD_PROCESS_NUM|" /etc/supervisor/conf.d/php.conf if [[ $HOSTNAME =~ "cron" ]]; then JOBNAME=${HOSTNAME%-*} JOBNAME=${JOBNAME%-*} mkdir -p /data/logs/laifenqi/$JOBNAME/php rm -rf /home/apple/web${PHP_LOG_SUB_MODULE}storage/logs ln -s /data/logs/laifenqi/$JOBNAME/php /home/apple/web${PHP_LOG_SUB_MODULE}storage/logs chmod 777 /data/logs/laifenqi/$JOBNAME/*else mkdir -p /data/logs/laifenqi/$HOSTNAME/nginx mkdir -p /data/logs/laifenqi/$HOSTNAME/php rm -rf /home/apple/web${PHP_LOG_SUB_MODULE}storage/logs ln -s /data/logs/laifenqi/$HOSTNAME/php /home/apple/web${PHP_LOG_SUB_MODULE}storage/logs chmod 777 /data/logs/laifenqi/$HOSTNAME/*fiif [ "true" != "$NSCD_START" ]; then sed -i "s|autostart=true|autostart=false|" /etc/supervisor/conf.d/nscd.conffiif [ "true" != "$NGINX_START" ]; then sed -i "s|autostart=true|autostart=false|" /etc/supervisor/conf.d/nginx.conffiif [ "true" != "$EXPORTER_START" ] || [ "fpm" != "$MODE" ]; then sed -i "s|autostart=true|autostart=false|" /etc/supervisor/conf.d/exporter.conffiif [ "true" != "$INIT_CMD_START" ]; then sed -i "s|autostart=true|autostart=false|" /etc/supervisor/conf.d/php.conffiif [ -n "$POST_START" ]; then sh -c "$POST_START"fiif [ "true" != "$SUPERVISOR_START" ]; then $INIT_CMDelse supervisord -n -y 0fi通过下面的示例能够看出为了实现可配置咱们应用了大量的环境变量，联合Entrypoint的替换脚本进步根底镜像的兼容性。结语以上是咱们趣店容器化历程的一些教训分享，整个容器化遵循循序渐进的准则，在大面积推广前需对开发及运维（甚至测试）人员进行常识遍及，防止在只有多数人把握容器、K8s等常识体系的状况下强行线上推广。当然容器化并不是一味治百病的药，咱们目前仍然有小局部服务因为一些考量因素部署在物理服务器。容器化是为了进步各方的效率，切不可为了容器化而容器化。 ...

1、k8s 测试之 Ingresshttps://blog.csdn.net/weixin_...

背景在TKE的集群中创立工作负载并把某一个对应的cos桶的根目录挂载到/data目录，在镜像构建的时候有把/data目录设置权限为755，然而运行容器后胜利挂载cos桶的根目录到/data/目录，发现用非root账号却无法访问/data上面的文件，镜像的启动用户是非root用户，查看容器内/data目录权限变成了700。 为什么设置的目录权限是755，挂载到COS后就变成了700权限呢？ 起因剖析测试启动2个nginx工作负载，一个负载将目录/etc/nginx/conf.d挂载到cos桶上，另一个工作负载失常运行不挂载，而后发现的确挂载cos后，默认会把目录权限变成700。 TKE中应用cos实质上是应用的Cosfs，腾讯云官网文档 COSFS 工具应用外面能够查到这样一个参数-oallow_other 。如果要容许其余用户拜访挂在文件夹, 能够在容许COSFS的时候指定该参数。 COSFS 工具：https://cloud.tencent.com/document/product/436/6883?from=10680解决方案TKE中如何配置-oallow_other参数？ 在应用cos桶进行挂载的时候在pv创立界面是能够进行参数设置的，然而因为咱们习惯在控制台间接创立pvc关联pv，而后pv会主动创立导致很多人没有去关注这个cos的参数。 形式一：手动创立通过编写yaml文件来创立pv,pvc 以下内容起源：https://github.com/TencentCloud/kubernetes-csi-tencentcloud/blob/master/docs/README_COSFS.mdpv-cos.yaml(须要关注volumeAttributes 下的additional_args 属性增加了-oallow_other) apiVersion: v1kind: PersistentVolumemetadata: name: "pv-cos"spec: accessModes: - ReadWriteMany capacity: storage: 1Gi csi: driver: com.tencent.cloud.csi.cosfs # Specify a unique volumeHandle like bucket name.(this value must different from other pv's volumeHandle) volumeHandle: xxx volumeAttributes: # Replaced by the url of your region. url: "http://cos.ap-guangzhou.myqcloud.com" # Replaced by the bucket name you want to use. bucket: "testbucket-1010101010" # You can specify sub-directory of bucket in cosfs command in here. # path: "/my-dir" # You can specify any other options used by the cosfs command in here. additional_args: "-oallow_other" nodePublishSecretRef: # Replaced by the name and namespace of your secret. name: cos-secret namespace: kube-systempvc-cos.yaml(存储大小自行批改) ...

近日有媒体报道称 本月初 美国阿雷西博（Arecibo）望远镜 产生坍塌后 “中国天眼”成为世界射电天文学畛域内 “惟一重要的仪器” 明年起 FAST将面向国内天文学家凋谢应用 彰显中国成为寰球科研核心的愿景 “中国天眼”FAST 全称是“500米口径球面射电望远镜”  这样说，你可能无奈了解 它到底有多大 举个例子吧 如果把FAST设想成一口大锅 要是把它装满矿泉水 每个中国人能分到20瓶 全世界每个人能分到4瓶 要是用它来装米饭 够全世界所有人吃一整天的 自往年1月验收以来 设施运行稳固牢靠 多项基于天眼的研究成果 发表在世界顶级迷信期刊上 其中一篇对于疾速射电暴（FRB）的论文  被《天然》认可为年度十大迷信发现之一 姜鹏 中国天眼（FAST）总工程师 他有过这样的期待： “如果FAST能有一些重要的迷信发现 心愿大家还能记住 这个大略100号人左右的团队 用了20多年的青春 最初铸就了中国利器” FAST是一个500米口径的钢梁 架在了50根微小的钢柱子上 一个6670根钢索编织的索网挂在环梁上 下面铺着4450块反射面单元 上面有2225根下拉索 固定在高空上的触动器 “中国在制作方面 有很多其余国家不太容易比较的方面 有中国人的智慧在这外面 也有中国人的勤奋在外面 很多因素联合成这样的一个产品 或者说大安装 常常有外国友人来看了一圈 说，只有中国能做得了FAST” 这个世界上跨度最大 精度最高、工作形式最非凡的索网工程 是怎么实现的？ “中国天眼”是怎么缓缓睁开的？ 12月17日 嫦娥五号返回器带着月壤胜利返回地球 时隔44年 人类再次从月球带回了岩石和土壤样本 我国成为继美国、苏联之后 第三个实现月球采样返回的国家 嫦娥五号工作发明了五项中国首次：1.在地外天体的采样与封装，2.地外天体上的点火腾飞、精准入轨，3.月球轨道无人交会对接和样品转移，4.携带月球样品以近第二宇宙速度再入返回， 5.建设我国月球样品的 存储、剖析和钻研零碎。 是我国航天事业倒退中里程碑式的新逾越， 标记着我国具备了地月往返能力，实现了“绕、落、回”三步走布局完满收官，为我国将来月球与行星探测奠定了坚实基础。 ...

现在云原生技术能够说是互联网最火的概念之一，作为云原生技术的重要基石 -- “容器” 技术，想必从业者早有学习并大量的使用在工作和日常开发中。 如果有人问你 “什么是容器？”， 你的答案是什么？ 容器就是 Docker 吗？它和虚拟化技术有什么区别和分割？它的实现原理又是什么？ 这篇文章次要通过 容器和虚拟化技术的比照，容器和 Linux Namespace 的关系，以及 Namespace 的初体验 三个模块让大家更理解什么是容器，以及容器实现的底层技术撑持 -- Liunx Namespace。 容器和虚拟化有 Linux 学习教训的同学，想必有应用 VMware 和 VirtualBox 这种软件来装置 Linux 虚拟机的经验。个别是这样的流程，咱们先在 windows 机器上装置 VMware 或者 VirtualBox 这类 Hypervisor 虚拟化软件，而后应用这类虚拟化软件将 Linux 的某种发行版镜像装置成为一个Linux 虚拟机，这样咱们就领有了一个 Linux 操作系统。 这种虚拟化软件是一种运行在根底物理服务器和操作系统之间的两头软件层，可容许多个操作系统和利用共享硬件，通过这种形式咱们失去的虚拟机软硬件、内核一应俱全，能够说是性能齐备的操作系统，它和宿主机隔离，咱们在操作系统里能够放心大胆的做任何的批改，而不必放心对宿主机造成侵害，这中资源的隔离型和性能的相似性，和容器表象上能够说是特地的类似。 刚开始接触 Linux 容器的我，习惯性的拿容器和虚拟机比照，认为容器就是一种轻量级的虚拟化技术，只是少了硬件资源的虚拟化，外加运行应用程序所必须的最小的文件系统。不晓得有多少人也曾有过和我一样的了解，不得不说这种了解的确对刚接触容器时，了解容器有不少的帮忙，然而这种说法却是不妥的，因为容器的实现机制和 Hypervisor 这种虚拟化技术是有实质却别的。 容器和 Namespace容器实质上只是 Linux 上运行的非凡的过程，之所以说非凡，是因为它和操作系统上的其余过程环境进行了隔离，就像一个集装箱一样，站在容器外面，只能看到它自身。容器技术的根底是 Linux namespace 和 cgroups 内核个性。 隔离的个性确保了不同容器过程互不烦扰，领有各自独立的运行环境。咱们晓得，在操作系统上 PID 这种货色是惟一的，咱们无奈领有一个 PID = 1 的过程 A， 同时领有一个 PID = 1 的过程 B；端口号也是惟一的，咱们无奈让多个过程同时监听同一个端口（fork 子过程的非凡形式除外）。咱们也无奈让操作系统 hostname 为 server1, 同时让 hostname 为 server2。然而咱们能够在容器 A 里存在一个过程他的 PID = 1， 同时容器 B 里也存在一个过程他的 PID 也等于 1，这就是容器隔离性的体现，它本人就是本人的全世界，开拓任意的空间（本人的文件系统），领有本人的网络设备，领有本人的 hostname。 ...

明天给大家介绍一下 Rainbond 的一个小技巧——端口别名。 端口别名，顾名思义，是给组件端口定义一个别名。 端口别名的设置当进入到端口治理页面，点击应用别名，即可设置端口的别名，如下图所示： 端口别名的作用定义好端口别名后，Rainbond 会为该别名生成两个对外环境变量：端口别名_HOST 和 端口别名_PORT。比方，端口别名是 MYSQL，则对应的环境变量就是 MYSQL_HOST 和 MYSQL_HOST。 不晓得大家发现没有，这两个环境变量，其实就是该端口的拜访形式，拜访形式=端口别名_HOST:端口别名_PORT。比方：端口别名是 MYSQL，对应的拜访形式就是 MYSQL_HOST:MYSQL_PORT，即 127.0.0.1:3306。 还有一个很重要的点就是，不论组件所属利用的治理模式怎么变，端口别名_HOST 都能够感知到。 也就是说，只有须要拜访该端口的组件依赖上该组件，则能够很不便地晓得其拜访形式；不论利用的治理模式怎么变动，这个拜访的形式会作出相应的变动，始终放弃是正确的。 Spring 组件连贯 MySQL为了做更进一步的阐明，咱们以 Spring 组件连贯 MySQL 为例，看看 Spring 是如何不便地获取 MySQL 的拜访形式。 相熟 Spring 的同学可能晓得，其配置文件能够是这样子的： spring.jpa.hibernate.ddl-auto=updatespring.datasource.url=jdbc:mysql://${MYSQL_HOST:localhost}:${MYSQL_PORT:localhost}/db_examplespring.datasource.username=springuserspring.datasource.password=ThePassword可能有些同学不相熟 Spring，不过没有关系。咱们只须要晓得，Spring 会用环境变量去渲染配置文件里的变量。 只有 Spring 组件依赖了 MySQL 组件，Rainbond 则会把 MySQL 组件的对外环境变量注入到 Spring 组件里。 换句话说，Spring 组件依赖了 MySQL 之后，就会主动地失去环境变量 MYSQL_HOST 和 MYSQL_HOST。如果 MYSQL_HOST=127.0.0.1, MYSQL_PORT=3306, 经 Spring 渲染后，数据库的链接地址则变成了 spring.datasource.url=jdbc:mysql://127.0.0。1:3306/db_example，从而能够正确的拜访 MySQL 组件。 总结端口别名 是 Rainbond 组件间的通信里的一个十分不便的性能，通过为端口设置别名，能够很不便地获取到该端口的拜访形式。 ...

摘要：华为云提出“云原生 IN 基础设施”的交融架构，通过三大翻新降级，将云原生推动到了2.0时代。面对数字时代简单零碎的不确定性，传统的IT利用架构研发交付周期长、保护老本高、翻新降级难，烟囱式架构，开放性差、组件复用度低，这些都成为了企业新业务疾速倒退的瓶颈，而云原生以其麻利、凋谢、标准化的特点迅速成为企业构建面向未来的利用架构的首选。 Gartner 在报告中预测，到 2020 年将有 50%的传统老旧利用被以云原生化的形式革新，到 2022年将有 75%的全球化企业将在生产中应用云原生的容器化利用。 通过多年的倒退，云原生已从最后的石破天惊到 “小众”风行，再到明天成为企业数字化转型的首选。华为云作为云原生产业的领导者和踊跃实践者，随同着云原生的倒退一路走来，在每一个阶段，华为云为云原生产业凋敝作出了继续的外围奉献。 继续技术奉献，减速社区我的项目能力欠缺：云原生计算基金会成立初期，社区倒退的重点是补齐云原生我的项目在存储、网络等方面能力的有余、对接支流硬件厂商、云厂商的基础设施资源等，华为云踊跃投入，为社区奉献130+外围个性和4万+PR，成为亚洲排名第一的贡献者； 丰盛行业实际，推动云原生产业成熟：随着云原生在以互联网、金融、政府为代表的各行业的广泛应用，以Kubernetes为外围的云原生产业生态逐步形成。在此期间，华为云通过内外部继续一直的翻新与实际，打造了丰盛的云原生解决方案，为10多个行业近万客户提供优质的云原生服务。在IDC公布的2019年中国容器软件市场份额排名中，华为云已位居中国厂商第一。同时，基于丰盛的实际积攒，华为云向CNCF募捐了首个云原生边缘计算我的项目KubeEdge和首个云原生批量计算我的项目Volcano，减速了云原生向其它产业的浸透和交融，推动了云原生产业的成熟。 三大翻新降级，开启云原生2.0时代：然而，以后云原生技术与云基础设施只是简略叠加的“云原生ON基础设施”架构，在这种架构下，计算、网络、存储等基础设施无奈感知利用在高可用、高性能、主动弹性等方面的诉求，也无奈满足跨集群、跨区域、跨云的全局化业务场景，因而企业业务与利用无奈实现真正的“云原生化”， 针对以上问题，华为云开创性地提出“云原生 IN 基础设施”的交融架构，整合架构通过三大翻新降级，将云原生推动到了2.0时代： 重定义基础设施：基于擎天架构实现了以利用为核心的资源调度，并且联合软硬协同技术，为企业提供极致性能、极优老本、极佳体验的云原生基础设施。 新赋能泛在利用：基于云原生集群联邦、边云协同等技术打造了多云与边云协同治理平台，可能帮忙企业构建高效、牢靠、跨云的对立业务平台，提供多云统一的治理体验。 再降级利用架构：云原生基础设施针对企业各类业务的诉求，打造欠缺的云原生利用生态，对立企业应用架构和全流程生命周期治理，反对130+云原生利用。 同时，华为云在云原生产业方面的投入进一步加码，通过举办"创原会·云原生技术精英沙龙"，汇聚各行业云原生技术精英，并与云原生产业及标准化组织一起，独特推动云原生技术和产业的成熟与标准化建设。 云原生2.0时代，华为云将继续致力让云原生技术联合各行业场景进行穿插翻新，通过"技术+产业"的双轮驱动，减速云原生全面落地，帮忙更多的企业实现数字化转型与业务翻新降级。 本文分享自华为云社区《开创性提出“云原生 IN 基础设施”，华为云引领云原生2.0时代》，原文作者：技术火炬手。点击关注，第一工夫理解华为云陈腐技术~

摘要：容器技术起源于Linux，是一种内核虚拟化技术，提供轻量级的虚拟化，以便隔离过程和资源。只管容器技术曾经呈现很久，却是随着Docker的呈现而变得广为人知。容器技术起源于Linux，是一种内核虚拟化技术，提供轻量级的虚拟化，以便隔离过程和资源。只管容器技术曾经呈现很久，却是随着Docker的呈现而变得广为人知。Docker是第一个使容器能在不同机器之间移植的零碎。它不仅简化了打包利用的流程，也简化了打包利用的库和依赖，甚至整个操作系统的文件系统能被打包成一个简略的可移植的包，这个包能够被用来在任何其余运行Docker的机器上应用。 容器和虚拟机具备类似的资源隔离和调配形式，容器虚拟化了操作系统而不是硬件，更加便携和高效。 图1 容器 vs 虚拟机 相比于应用虚拟机，容器有如下长处： 更高效的利用系统资源因为容器不须要进行硬件虚构以及运行残缺操作系统等额定开销，容器对系统资源的利用率更高。无论是利用执行速度、内存损耗或者文件存储速度，都要比传统虚拟机技术更高效。因而，相比虚拟机技术，一个雷同配置的主机，往往能够运行更多数量的利用。 更疾速的启动工夫传统的虚拟机技术启动应用服务往往须要数分钟，而Docker容器利用，因为间接运行于宿主内核，无需启动残缺的操作系统，因而能够做到秒级、甚至毫秒级的启动工夫，大大节约了开发、测试、部署的工夫。 统一的运行环境开发过程中一个常见的问题是环境一致性问题。因为开发环境、测试环境、生产环境不统一，导致有些问题并未在开发过程中被发现。而Docker的镜像提供了除内核外残缺的运行时环境，确保了利用运行环境一致性。 更轻松的迁徙因为Docker确保了执行环境的一致性，使得利用的迁徙更加容易。Docker能够在很多平台上运行，无论是物理机、虚拟机，其运行后果是统一的。因而能够很轻易的将在一个平台上运行的利用，迁徙到另一个平台上，而不必放心运行环境的变动导致利用无奈失常运行的状况。 更轻松的保护和扩大Docker应用的分层存储以及镜像的技术，使得利用重复部分的复用更为容易，也使得利用的保护更新更加简略，基于根底镜像进一步扩大镜像也变得非常简单。此外，Docker团队同各个开源我的项目团队一起保护了少量高质量的官网镜像，既能够间接在生产环境应用，又能够作为根底进一步定制，大大的升高了应用服务的镜像制作老本。 Docker容器典型应用流程Docker容器有如下三个次要概念： 镜像：Docker镜像里蕴含了已打包的应用程序及其所依赖的环境。它蕴含应用程序可用的文件系统和其余元数据，如镜像运行时的可执行文件门路。镜像仓库：Docker镜像仓库用于寄存Docker镜像，以及促成不同人和不同电脑之间共享这些镜像。当编译镜像时，要么能够在编译它的电脑上运行，要么能够先上传镜像到一个镜像仓库，而后下载到另外一台电脑上并运行它。某些仓库是公开的，容许所有人从中拉取镜像，同时也有一些是公有的，仅局部人和机器可接入。容器：Docker容器通常是一个Linux容器，它基于Docker镜像被创立。一个运行中的容器是一个运行在Docker主机上的过程，但它和主机，以及所有运行在主机上的其余过程都是隔离的。这个过程也是资源受限的，意味着它只能拜访和应用调配给它的资源（CPU、内存等）。典型的应用流程如图2所示： 图2 Docker容器典型应用流程 （1）首先开发者在开发环境机器上开发利用并制作镜像。 Docker执行命令，构建镜像并存储在机器上。 （2）开发者发送上传镜像命令。 Docker收到命令后，将本地镜像上传到镜像仓库。 （3）开发者向生产环境机器发送运行镜像命令。 生产环境机器收到命令后，Docker会从镜像仓库拉取镜像到机器上，而后基于镜像运行容器。 应用示例上面应用Docker将基于Nginx镜像打包一个容器镜像，并基于容器镜像运行利用，而后推送到容器镜像仓库。 装置Docker Docker简直反对在所有操作系统上装置，用户能够依据须要抉择要装置的Docker版本。 在Linux操作系统下，能够应用如下命令疾速装置Docker。 curl -fsSL get.docker.com -o get-docker.shsh get-docker.sh阐明： CentOS 8.0操作系统应用上述脚本装置Docker会呈现问题，倡议应用如下命令装置较低版本Docker。 wget -O /etc/yum.repos.d/docker-ce.repo https://repo.huaweicloud.com/... sudo sed -i 's+download.docker.com+http://repo.huaweicloud.com/d...' /etc/yum.repos.d/docker-ce.repo yum install docker-ce-18.06.3.ce -y systemctl restart docker Docker打包镜像 Docker提供了一种便捷的形容利用打包的形式，叫做Dockerfile，如下所示： # 应用官网提供的Nginx镜像作为根底镜像FROM nginx:alpine# 执行一条命令批改Nginx镜像index.html的内容RUN echo "hello world" > /usr/share/nginx/html/index.html# 容许外界拜访容器的80端口EXPOSE 80执行docker build命令打包镜像。 docker build -t hello . ...

摘要：华为云推出云原生基础设施全栈解决方案，引领云原生进入Cloud Native 2.0时代。随着企业IT优化向数字化转型演变，企业IT投资重心逐渐向云原生利用歪斜。云原生能带来诸多劣势，它能大大改善利用开发运维迭代的效率，帮忙企业业务翻新迭代，它能改良资源弹性治理和迁徙的效率，帮忙企业降本增效。云原生已成为云计算重心，是企业IT数字化转型的要害。云原生以“利用使能”+“混合云”为外围，帮忙企业本地部署与云端交融，打造企业急切须要的混合云架构。企业IT数字化策略也逐步从从“Cloud First”逐渐转向“Cloud Native First”。 2020年，各家私有云厂商都推出了容器相干服务，做到极致的如AWS这样的云厂商甚至推出了三四个容器相干服务，在本地部署市场中，红帽的容器服务OpenShift和Rancher都获得了较高的认可度，阿里云更是将外围零碎实现整体上云，以容器产品为根底，打造阿里云云原生利用平台家族。许多企业都开始在本人的IT架构中融入容器元素，容器技术以及以容器技术为外围的云原生技术正在以不可阻挡之势向咱们走来。 为满足客户业务将来演进，华为云公布云原生基础设施全栈解决方案，引领云原生进入Cloud Native 2.0时代。全栈解决方案以华为云擎天软硬一体化架构为基础设施，联合云原生技术平台 Vessel、批量计算引擎Volcano、边缘容器KubeEdge三大平台，通过九大技术产品利用到裸金属、VR/AR、微服务、边缘、大数据/AI等垂直场景中。 华为云 云原生基础设施全栈解决方案 云原生基础设施全栈解决方案的推出，可能在四个方面助力企业在云原生技术趋势下倒退： 降本增效方面，华为云第二代“零损耗”裸金属容器解决方案，引入容器全卸载、网络硬件直通、动静ENI（弹性网络接口）等新个性，相比第一代裸金属容器，老本降落30%、网络性能晋升40%。 跨云治理方面，服务网格帮忙利用疾速实现现代化，及在跨云治理在在利用跨云迁徙方面的利用。 对立计算方面，容器批量计算平台的外围调度引擎Volcano提供多种高级调度策略可能很好的在微服务、大数据、AI等技术产品上利用。 云边协同方面，AI能力延长到边缘，海量设施对立监控、治理 华为云云原生基础设施全栈解决方案整体由四个架构组成：“软硬协同”的华为云擎天架构、“为云原生量身打造”的利用定义基础设施、“跨域调度，云边协同”的人造多云架构和“凋谢规范，行业翻新”的凋谢利用生态。 计划的公布让云原生不再仅仅是运行在基础设施上，而是与基础设施深度融为一体，使得云原生技术能力上实现三大降级：利用定义基础设施，利用不再与基础设施不再割裂，而是互相可感知；人造多云的架构，能够实现利用跨云灵便调度；丰盛的云原生利用生态，让企业能够疾速构建更多的创新型业务。 ▶ 利用定义基础设施华为云提出了利用定义基础设施的概念，并基于擎天架构实现了以利用为核心的资源调度，并且联合软硬协同技术，为企业提供极致性能、极优老本、极佳体验的云原生基础设施。 利用定义网络云原生网络以利用为核心，人造反对根底网络、服务调用、QoS、NetworkPolicy等能力，实现无损耗的原生高性能。 劣势1：以容器为一等公民，间接为容器调配原生网络资源ENI，人造与虚拟化网络/主机网络互通，性能无损耗；可依照容器规格动态分配网络收发队列数量，更好地匹配利用诉求； 劣势2：人造反对KubeProxy负载平衡能力，无额定资源消耗与性能损耗； 劣势3：进一步通过eBPF或擎天硬件能力实现网络减速； 利用定义存储云原生存储以利用为核心，人造实现“超交融”架构，存储追随容器按需疾速调配、流动、弹性，实现高性能、高牢靠 劣势1：去除传统挂卷形式，采纳container-store形式实现面向Pod集群的容器存储能力，缩小容器存储的粒度 劣势2：数据面的容器感知能力，基于感知容器数据卷实现容器粒度的治理、剖析、爱护、迁徙 劣势3：存储本身容器化，随利用容器一起公布。人造的解决了云原生利用业务变动不可预期，弹性要求高的问题 利用定义算力“Volcano+”最强算力调度平台，晋升资源利用率50%。 Region-less全域调度：依据利用依据混合云+边缘云全网资源状况进行对立调度。算力智能调度：反对依据利用、节点、网络流量实时利用率，利用的SLA、网络、存储要求、进行智能调度决策，进行动静超分和分时复用，保障利用SLA满足要求。算力智能布局：反对依据租户业务的历史运行状况进行深度学习，进行预测，提前进行资源弹性筹备。算力智能调优：反对在离线业务混部，依据利用SLA状况进行保障、反对利用热迁徙及智能弹性。▶ 人造多云架构随着业务的疾速倒退，企业基础设施广泛面临多集群、多区域以及全球化等大规模多云、跨云治理的挑战。Kubernetes的单数据中心架构，注定了其无奈间接解决业务多云场景的问题。华为云基于云原生集群联邦、边云协同等技术打造了多云与边云协同治理平台，可能帮忙企业构建高效、牢靠、跨云的对立业务平台，提供多云统一的治理体验。 利用的多云治理，实现了原生反对多云环境，从计算、网络、存储、运维等方面构建全方位一致性服务体验： 跨云利用对立调度：实现跨云场景下全局资源调配；跨云利用调度及多集群一致性交付与配置，实现跨云负载分担及容灾切换；跨云云原生存储：云原生跨云存储解决方案，反对多云对立存储池治理，反对跨云存储数据迁徙、灾备能力；跨云云原生网络：基于跨云利用自适应提供灵便网络模型和利用级SLA保障；多云大规模（10w+）组网和秒级网络发放性能；基于eBPF/XDP的数据面，反对高性能SLB和Network Policy；反对TCP连贯级网络观测能力, 秒级网络故障定界能力；跨云利用智能治理：跨云利用全域服务网格，10万+大规模微服务实例治理；跨云利用一致性运维：多云对立运维核心，实现跨云故障一键式定位；跨云利用镜像一致性散发：多云对立利用容器镜像治理，实现跨云秒级散发。▶ 凋谢利用生态 华为云云原生基础设施针对企业各类业务的诉求，在利用生态方面依靠K8s标准化平台构筑企业应用对立目录，能力共享打造了云原生利用核心；依靠Operator Framework技术构筑利用管控核心，笼罩“开发->接入->运维”全流程的OSC 利用管控核心和加强Operator全生命周期治理，按需开明，开箱即用的凋谢利用生态体系。目前，已反对130+云原生利用，不仅蕴含微服务架构的无状态利用，还减少了分布式中间件、AI、大数据等有状态利用，以及边缘、5G、区块链等新型利用，帮忙企业“自选式”构筑云原生业务架构，实现业务“all in container”。 华为云除了在技术和产品上不断创新之外，还踊跃推动云原生生态和产业的倒退，联合各场景优良实际，减速云原生技术在各行业的落地，推动云原生生态与标准化建设。作为云原生技术与产品领导者，华为在中国容器软件市场份额中国厂商排名第一，寰球厂商排名第二。并且，华为是容器开源社区次要贡献者和容器生态领导者，CNCF 基金会的初创会员和白金会员，Kubernetes社区奉献亚洲第一，寰球第五。在业界首发多个重量级服务，包含第一代裸金属容器、“零损耗”第二代裸金属容器、Serverless容器、应用服务网格、鲲鹏容器等，构建私有云上Kubernetes最佳实际。 如果你想理解更多的对于华为云云原生技术，那就快来#华为云1024程序员节，向云而生# 直播盛典：邀请华为云云原生开源负责人、华为云DevCloud首席技术布道师等10+大咖现身，分析云原生的行业趋势，倾授云原生实战秘籍。点击观看直播。 干货直通车：大佬级别专家手把手教学，教训和技术分享必不可少，还有在线互动答疑，带你揭晓大厂最深层代码技术，点击查看各技术会场，开掘更多干货！ 备注：本文整顿自华为云容器基础设施架构师k82cn在1024程序员节流动上的直播。 点击关注，第一工夫理解华为云陈腐技术~

摘要：聊云原生之前，咱们无妨从容器技术说起。近年来，云原生（Cloud Native）堪称是 IT 界最火的概念之一，且随着云计算遍及过程的一直加深，有愈演愈烈的趋势。明天再谈云原生曾经不是少数几个大企业的专属，越来越多的企业正在拥抱它，享受它带来的红利。 说到云原生，咱们就不得不先理解一下容器技术。作为一种先进的虚拟化技术，容器技术堪称是撑起了云原生生态的半壁江山，未然成为了云原生时代软件开发和运维的规范基础设施。在聊云原生之前，咱们无妨从容器技术说起。 回顾云原生倒退 整个云原生的生态蓬勃发展，也从Kubernetes我的项目自身倒退到了现在内容丰盛的巨大幅员。底层有泛滥的容器运行时、容器存储、容器网络以及硬件加速器计划能够抉择；面向用户层面，K8s的北向能够运行、对接各种业界支流的数据库、中间件等。目前已有超过90个厂商提供了认证的K8s的云服务或者发行版，并提供了丰盛的周边软件、服务的配套反对。 2015年Kubernetes 1.0版本公布，标记着K8s曾经生产可用，泛滥企业曾经开始尝试在生产环境应用Kubernetes。同年，专门负责以K8s容器为代表的云原生开源我的项目与技术的推广与治理的CNCF云原生计算基金会成立，华为云是CNCF的初创会员之一。 短短两年后，K8s已实现了对各类容器平台的标准化对立。在2017年，各支流云厂商均已推出了Kubernetes Service，K8s成为了Container Service的代名词。同年底，容器技术的先行者Docker公司也发表在其企业版产品Docker EE中反对Kubernetes。至此，容器生态对立到了Kubernetes平台之上。 到2020年，K8s行将要公布1.19版本，间隔2015年的1.0曾经有19个大版本公布，各项性能个性和接口API都曾经趋于稳定，K8s曾经进入了成熟期。将来社区将会如何倒退？是否K8s的倒退将会放缓了呢？恰恰相反，华为云云原生团队认为，K8s将会进入更高速倒退的阶段，K8s将会与云计算的利用、平台、设施各层次进行更深刻的联合。 各类现代化的利用都将会运行在K8s之上，不仅仅是以后以互联网App、WebService为代表的无状态利用，而新型的诸如大数据、AI、分布式数据中间件等等有状态利用，以及新型的边缘利用也将会广泛运行在K8s之上，从而K8s将实现对各类现有平台的归一化，成为一个对立的利用运行的根底平台。而为了更好地撑持现代化利用以及对立的根底技术平台，上层的各类设施包含虚拟化计算/网络/存储、裸金属服务器以及专用芯片如AI、高性能网络、高性能存储等等都会与K8s更严密的配合，通过软硬一体化的计划来为下层利用提供更高性能、更稳固牢靠、更高效的基础设施。与“利用、平台、设施”三个层面的协同，意味着K8s将真正成为“云的OS” – Cloud OS。 从行业来看，各类企业目前处于以5G、AI、边缘、VR、万物互联等等为代表的新技术暴发的时代，亟需优化企业业务运行效率，放慢业务创新能力。在这个背景下，企业内的IT基础设施技术平台亟需标准化的对立治理。 而Kubernetes灵便的架构能力，使得K8s为代表的云原生技术成为这个“标准化企业IT对立治理平台”的最佳载体。首先，通过K8s南向与资源层的各类标准化接口，企业可能轻松实现基础设施资源的对立治理，其次，通过K8s的北向标准化利用API与CRD扩大能力，企业可能不便地对立治理下层各类业务，实现业务架构的对立，最初，通过K8s社区以Operator、Helm为代表的各类利用治理规范，企业可能构筑对立的IT应用服务目录，实现利用的共享，构筑对立的IT利用治理平台。 因而，在将来，企业内现存的各类根底软件平台，典型的包含以DevOps继续交付、微服务化开发为代表的利用与微服务平台，以AI、大数据、批量计算为代表的数据平台，以及面向5G、物联网、视频等场景的边缘平台，都将会对立到基于K8s的“云原生架构的技术平台”之上。从而，企业基于云原生技术平台将会真正实现对企业内各类业务的对立治理。 华为云保持构建标准化、开源、凋谢的云原生技术平台而华为云最早于2018年起即察看到了这一技术趋势，在容器全栈产品中构建了Vessel云原生技术平台，次要包含了以容器引擎iSula、容器网络Yangtse、容器存储Everest为代表的面向对立资源层的云原生基础设施组件，以及利用调度Volcano、云边协同框架KubeEdge、利用网格Terrace、监控与治理Glacier为代表的面向对立应用层的云原生利用平台组件。并且，向下与华为云擎天软硬一体化架构相结合，面向各行业用户，提供企业级高牢靠、高性能，凋谢、易用的云原生技术平台。 华为云保持构建标准化、开源、凋谢的云原生技术平台，不仅深度参加社区内包含K8s、Istio、Federation等外围我的项目，而且将本身产品的外围能力对外开放。华为云别离于2018年、2019年开源了KubeEdge边缘计算我的项目、Volcano批量计算我的项目，并募捐给了CNCF基金会，失去了社区的积极响应。这两个我的项目目前都在国内外多个企业理论生产环境失去了利用。 目前KubeEdge也行将进入CNCF incubator孵化阶段。在基础设施层，华为云在运行时、网络、存储、异构设施等方面都宽泛参加或凋谢了多个开源我的项目，将华为云在基础设施层的丰盛积攒与社区共享，独特促成Kubernetes以及CNCF云原生社区的疾速翻新与倒退。 云原生核心技术劣势云曾经能够为咱们提供稳固能够唾手可得的基础设施，然而业务上云成了一个难题，Kubernetes的呈现与其说是从最后的容器编排解决方案，倒不如说是为了解决利用上云（即云原生利用）这个难题。包含微服务和FaaS/Serverless架构，都能够作为云原生利用的架构。 那么云原生到底为什么这么受欢迎呢？总得来说有以下几大劣势： 利用容器和服务网格等技术，解耦软件开发，进步了业务开发部署的灵活性和易维护性以Kubernetes为外围的多层次、丰盛的开源软件栈，被各大厂商反对，用户抉择多，防止厂商绑定以K8s为外围的松耦合平台架构，易扩大，防止侵入式定制 - K8s已被公认是platform for platform通过核心编排过程动静治理和调度利用/微服务，进步工作效率和资源利用率上面以两个云原生的代表技术为例，来帮忙大家加深了解。 云原生代表技术：Kubernetes的申明式API – 面向开发者提供全新分布式原语 Kubernetes的最大亮点之一必然是它的申明式API设计，所谓的申明式就是通知kubernetes你要什么，而不是通知它怎么做命令。日常业务开发过程中，尽管惯例的资源根本满足需要，然而这些惯例的资源大多仅仅是代表绝对底层、通用的概念的对象， 某些状况下咱们总是想依据业务定制咱们的资源类型，并且利用kubernetes的申明式API，对资源的增删改查进行监听并作出具体的业务性能。 有了自定义资源定义API，开发者将不须要逐个进行 Deployment、Service、ConfigMap 等步骤， 而是创立并关联一些用于表述整个应用程序或者软件服务的对象。API对象彼此互补、可组合。除此，还能应用自定义的高阶对象，并在这些高阶对象的根底上创立底层对象。 云原生代表技术：服务网格 – 剥离业务代码和分布式框架 服务网格通过非侵入式的形式接管利用的服务通信。对于每个业务单元/模块来说，他们甚至不须要对网络通信、负载平衡等有任何的感知。 服务网格提供细粒度流量治理，包含灰度公布、故障注入、可观测性反对等能力，挺高了业务利用的易维护性。对于企业开发者来说，服务网格能够很好地帮忙他们剥离业务代码和分布式框架，平台团队聚焦框架层的开发和调优，业务团队聚焦业务自身的开发。 三大翻新正式开启CloudNative 2.0时代以后Cloud Native 1.0时代，尽管云原生在肯定水平上放慢了利用开发、简化了运维，但因为云原生技术聚焦在应用层，以后与云基础设施只是简略叠加的“云原生ON基础设施”架构。此时就会为企业带来繁多的利用生态、单数据中心架构和利用于资源割裂都已成为以后企业大规模落地云原生仍面临挑战。 为此，华为云推出的云原生基础设施解决方案，提出“云原生 IN 基础设施”的交融架构，将云原生推动到Cloud Native 2.0，构建以利用为核心的云原生基础设施的时代。 重定义基础设施：华为云基于擎天架构实现了以利用为核心的资源调度，并且联合软硬协同技术，为企业提供极致性能、极致老本、极致体验的云原生基础设施。新赋能泛在利用：华为云基于云原生集群联邦、边云协同等技术打造了多云与边云协同治理平台，可能帮忙企业构建高效、牢靠、跨云的对立业务平台，提供多云统一的治理体验。针对边缘场景，华为云边缘IEF提供了边云协同计算框架、离线自治、网络防抖动与故障自愈等技术，帮忙企业将业务延长至边缘，构筑云原生边云业务平台。再降级利用架构：华为云保持构建凋谢、标准化的利用生态，其中，基于云原生Operator框架实现了各类分布式中间件的标准化生命周期治理，为企业应用构建对立的散发、上线、运维平台；基于Istio打造的应用服务网格降级了企业的服务治理模式，实现业务的非侵入式微服务治理，打造对立的利用治理架构；Volcano批量计算引擎为企业各类AI、大数据、离线与实时计算类业务提供高效的调度能力，帮忙企业疾速构建智能化数据计算业务，打造对立的利用计算平台。CNCF新星我的项目边缘计算是对于云计算的补充和拓展，致力于让计算和连贯物离得更近，去构建万物互联的根底。基于云原生技术构建边缘计算平台，会带来联接广泛性、数据带宽优化、边缘业务离线自治、进步安全性、爱护隐衷四个方面的核心技术价值。然而，K8S技术在利用过程中却面临着边缘资源受限、网络不畅、如何离线自治、设施接入和治理的问题。 无论从边缘利用的散发,边缘利用的可靠性还是边云协同的机制上,云原生边缘计算有利于让边缘也具备像云一样的“弹性”,让利用能够“顺滑”的部署到边缘,放弃利用在边缘与云端的一致性。 通过更优的架构和技术实现，完满应答以后遇到的挑战。华为云推出了业界首个云原生边缘计算我的项目，且反对Apache 2.0协定的KubeEdge，基于Kubernetes的架构体系并针对边缘场景提供了诸如离线运行能力、边云协同能力等多种非凡能力的反对，将云原生的生态和开发体验延长到边缘，面向开发者提供对立的开发、部署、治理视图，屏蔽边缘和云端的差别。 KubeEdge通过Kubernetes构建，100%兼容K8s API、云边协同、边缘离线自治、极致轻量、海量设施反对等六大能力将Kubernetes的能力拓展到边缘。从18年11月份发表开源，19年3月成为CNCF官网我的项目，20年升级为CNCF孵化我的项目。社区贡献者超460人，社区成员单位超35家。作为CNCF首个云原生边缘计算我的项目，同时成为K8s IoT edge WG和Akraino社区边缘服务参考架构。 ...

QKE（QingCloud KubeSphere Engine）全新降级到 3.0 版本，新增“多集群治理”性能，可帮忙企业实现集群的灵便增减、跨集群的利用部署以及全生命周期治理，从而晋升企业 IT 资源利用率和利用管理效率，放慢云原生生产落地和数字化转型，发明更多经济价值。同时推出新品促销流动（详见文末），企业可能以超低老本部署容器混合云。 视频演示：在多集群中创立利用 为什么须要多集群随着企业业务的多样化倒退，精细化部署决定了在混合云环境中，多集群的存在是一种常态。概括起来，采纳多集群部署业务有以下劣势： 高可用 能够将业务负载散布在多个集群上，如云灾备、多活。当一个集群产生故障无奈解决申请时，拜访流量切换到衰弱的集群，以实现业务高可用。 低提早 在多个区域部署集群，将用户申请转向间隔最近的集群解决，以此来最大限度缩小网络带来的提早。 故障隔离 当集群产生诸如断电、网络故障、资源有余引起的连锁反应等，应用多个集群能够将故障隔离在特定的集群，防止向其余集群扩散。 业务隔离 多集群能够在物理上实现资源彻底隔离，安全性和可靠性相比软件层隔离更高。例如企业外部不同部门部署各自独立的集群，应用多个集群来别离部署开发、测试以及生成环境等。 为什么须要容器多集群在 Kubernetes 成为事实标准之前，混合云架构次要着力在 IaaS 层实现。企业架构师致力于将异构环境，包含不同厂商的云、虚拟机、裸金属环境等，接入同一套软件平台，进行对立治理。这样接入带来的问题是： 架构简单 不同厂商的云、虚拟机、裸金属环境有不同的 API，接入老本极高，接入后造成宏大简单的 IT 架构，且短少资源调度规范，难以实现对立治理。 生态关闭 不同厂商有各自的API 规范，无奈超越商业层面进行对立，进而无奈造成生态，导致系统可扩展性差，这无疑是被繁多厂商以另一种模式绑定。 云计算诞生之初，工程师们的愿景是像应用水和电一样不便的应用计算资源，但很长一段时间，这些计算资源因为简单的架构以及被服务商的技术绑定，并没有真的如所愿一样不便，但通过 Kubernetes 技术理念——对立凋谢的技术架构，以及多集群治理框架，咱们看到水和电如期而至的愿景终于得以实现。 多集群治理，容器混合云的最初一公里尽管 Kubernetes 从概念层面解决了混合云多集群治理的问题，但间隔企业生产落地，还有“最初一公里”的间隔，在混合云和容器云理论应用过程中会遇到很多问题，比方： 集群之间互相独立，不足对立的视角治理在部署一个利用须要到不同的集群中别离部署，操作门路长，效率绝对低下Kubernetes 运维监控曾经很简单，如何在多集群架构中高效治理利用和资源，是一项挑战容器混合云真的不应该如此简单，否则难以使用在生产环境中，DevOps 也难以落地。 QKE 3.0，多集群加持，买通容器混合云最初一公里多集群治理，从底层基础设施的角度看，就是要保障多个集群的灵便增减和资源调度；从服务下层利用的角度看，则是要简略实现利用的跨集群部署，以及面向利用的全生命周期运维治理。这所有都能够通过 QKE 3.0 实现。 QKE（QingCloud KubeSphere Engine），KubeSphere 是一款基于 Kubernetes 构建的企业级容器平台，QKE 在 QingCloud 私有云上交付 KubeSphere 容器平台全能力，并可对立治理跨云、跨基础设施的 Kubernetes 集群，通过极简的人机交互实现 CI / CD、微服务、以及集群运维治理，帮忙用户更敏捷地构建云原生利用与对立治理利用的全生命周期。 基于租户的多集群对立治理 通过对立的租户管理体系， QKE 3.0 能够实现繁多租户聚合治理多集群，也可将某一租户和某一集群进行一对一治理，既适应大大型企业的统一化治理诉求，也能够针对企业用户多分支机构这种场景做灵便治理配置。 反对 Solo 和 Federation 两种集群管理模式 从对立运维化治理的场景登程，为更好的解决企业 IT 运维人员治理多个 K8s 集群的困扰，QKE 多集群反对 solo 模式，也就是将不同集群放到一个治理立体之下进行对立治理，集群间互不影响。 ...

容器化治理演进演进过程swarm单集群，共享宿主机端口，服务发版有肯定工夫服务不可用。 k8s 原生控制器多集群反对，反对简略的公布策略 次要为黑盒操作，即以批改 k8s 原生资源配置为主，无奈实现灰度公布，蓝绿公布等高级性能。 随着容器化的继续进行，越来越多的业务跑到 k8s 集群上，目前已有 6 个不同集群对外提供服务。 目前 k8s 社区非常沉闷，为了稳定性和安全性，版本升级较频繁，目前由 1.10,1.14,1.15,1.16 多个版本的集群并存。此外，阿里云、公有云并行存在，基础设施不同。多集群，私有云、多版本，集群差别较大，对立治理逻辑简单，保护艰难。 服务状态次要靠同步查问，难以渐进式管制公布过程。用户体验不够敌对，查看状态须要手动刷新。 边界不清晰， 管理系统(chons)关注点太多，越来越简单，不好保护。 封装不够欠缺，裸露了较多 k8s 外部细节给前端、以及用户，减少其认知老本。 扩大不不便，每裸露一个配置项，都须要新加接口，老本高。 组件控制器k8s 是一个平凡的我的项目，为很多服务治理过程中罕用的资源做了高度形象，并且 k8s 零碎高度通用、高度灵便，可能实现服务治理和保护的多种多样的需要。因而同时 k8s 零碎也是一个较简单的零碎。除了 k8s 专家，不论是开发和运维同学，拿到 k8s 的资源配置文件都显得过于简单，搞得人一头雾水。 解决简单计算机系统的问题的一个通用的办法就是利用分层的思维，在简单零碎之上再形象出一层，分层治理： 高级编程语言在汇编语言之上操作系统在驱动之上网络七层模型层层形象依照这个思路，为了依靠 k8s 生态为公司服务治理平台继续赋能，以及更好地解决多集群精细化治理的问题，咱们在 k8s 原生资源之上形象出组件层，并采纳 k8s CRD operator 的模式开发了组件控制器，每个控制器独立治理每个集群的服务： 屏蔽 Deployment, StatefulSet, Service, Ingress 等外部实现细节，升高研发人员心智累赘集群治理与下层业务调度解耦靠近 k8s 原生资源的保障集群生命周期治理靠近 k8s 原生资源的体验 设计思路组件是一等公民deployment 由 deployment controller 管制；service 由 service controller 管制；组件(component) 由 component controller 管制。 ...

作为一个程序员，如果不晓得如何进行近程服务器的文件上传与下载，切实是一件难堪的事件。关上百度，搜寻「近程服务器 上传下载」，你能失去 63,100,000 个搜搜后果，形形色色的操作形式的让人目迷五色。 那么，明天咱们聊聊如何实现近程服务器的文件上传与下载。通常而言，咱们会抉择 ftp、scp 以及 sftp 进行文件传输。但 ftp 基于 TCP 来传输文件，明文传输用户信息和数据，存在肯定的平安危险。所以咱们更偏向于抉择基于 SSH 来加密传输的 scp 和 sftp，但联合速度、安全性和性能的要求，这两种协定各有优劣。接下来，咱们做个简略比拟，兴许会让你的日常抉择更加高效。 什么是 scp？scp 是一种基于 SSH 的协定，次要用在网络上的主机之间提供文件传输。应用 scp，咱们能够在主机之间疾速传输文件以及根本文件属性，例如拜访权限和通过 FTP 无奈可用的工夫戳。scp 协定应用 RCP 传输文件和 SSH 以提供身份验证和加密。 如何通过 scp 进行文件上传与下载？先介绍咱们最常见的，在 linux 中能够应用 scp 进行文件上传和下载。 文件上传：scp localfile user@host:/dirpath即 SCP 文件门路近程主机用户名@ip：/寄存文件的门路，比方 scp hello.txt user@ip:/home/user/dirpath 从本地上传目录到近程主机 : scp -r localdir user@host:/dirpath即 scp -r 本地目录门路近程主机用户名@ip：/寄存文件门路 从近程主机下载货色到本地电脑拷贝文件命令 scp user@host:/path/file /localpath即 scp用户名@IP:/文件门路 /本地文件门路 如果拷目录就 scp -r user@host:/dirpath /localpath即 scp -r 用户名@IP:/目录门路 /本地文件门路 什么是 sftp？sftp 同样是基于 SSH 的文件传输协定，但性能更弱小。相较于 scp，更像是近程文件治理协定，sftp 容许对近程文件（查看目录，删除文件和目录等）进行一系列操作。 如何通过 sftp 进行文件上传与下载而 sftp 下，咱们能够通过 linux 命令行，应用 SFTP 命令进行间接操作： ...

本文依据美团基础架构部王国梁在KubeCon 2020云原生开源峰会Cloud Native + Open Source Virtual Summit China 2020上的演讲内容整顿而成。一、背景与现状Kubernetes是让容器利用进入大规模工业生产环境的开源零碎，也是集群调度畛域的事实标准，目前已被业界宽泛承受并失去了大规模的利用。Kubernetes曾经成为美团云基础设施的治理引擎，它带来的不仅仅是高效的资源管理，同时也大幅升高了老本，而且为美团云原生架构的推动打下了松软的根底，反对了Serverless、云原生分布式数据库等一些平台实现容器化和云原生化的建设。 从2013年开始，美团就以虚拟化技术为外围构建了云基础设施平台；2016年，开始摸索容器技术并在外部进行落地，在原有OpenStack的资源管理能力之上构建了Hulk1.0容器平台；2018年，美团开始打造以Kubernetes技术为根底的Hulk2.0平台；2019年年底，咱们根本实现了美团云基础设施的容器化革新；2020年，咱们深信Kubernetes才是将来的云基础设施规范，又开始摸索云原生架构落地和演进。 以后，咱们构建了以Kubernetes、Docker等技术为代表的云基础设施，反对整个美团的服务和利用治理，容器化率达到98%以上，目前已有数十个大小Kubernetes集群，数万的治理节点以及几十万的Pod。不过出于容灾思考，咱们最大单集群设置为5K个节点。 下图是以后咱们基于Kubrnetes引擎的调度零碎架构，构建了以Kubernetes为外围的对立的资源管理零碎，服务于各个PaaS平台和业务。除了间接反对Hulk容器化之外，也间接反对了Serverless、Blade等平台，实现了PaaS平台的容器化和云原生化。 二、OpenStack到Kubernetes转变的阻碍和收益对于一个技术栈比拟成熟的公司而言，整个基础设施的转变并不是一帆风顺的，在OpenStack云平台期间，咱们面临的次要问题包含以下几个方面： 架构简单，运维和保护比拟艰难：OpenStack的整个架构中计算资源的治理模块是十分宏大和简单，问题排查和可靠性始终是很大的问题。环境不统一问题突出：环境不统一问题是容器镜像呈现之前业界的通用问题，不利于业务的疾速上线和稳定性。虚拟化自身资源占用多：虚拟化自身大略占用10%的宿主机资源耗费，在集群规模足够大的时候，这是一块十分大的资源节约。资源交付和回收周期长，不易灵便调配：一方面是整个虚拟机创立流程简短；另一方面各种初始化和配置资源筹备耗时长且容易出错，所以就导致整个机器资源从申请到交付周期长，疾速的资源调配是个难题。高下峰显著，资源节约重大：随着挪动互联网的高速倒退，公司业务呈现高下峰的工夫越来越多，为了保障服务稳固不得不依照最高的资源需要来筹备资源，这就导致低峰时资源闲暇重大，进而造成节约。2.1 容器化的过程和阻碍为了解决虚拟机存在的问题，美团开始摸索更加轻量级的容器技术的落地，也就是Hulk1.0我的项目。不过基于过后的资源环境和架构，Hulk1.0是以原有的OpenStack为根底资源管理层实现的容器平台，OpenStack提供底层的宿主机的资源管理能力，解决了业务对弹性资源的需要，并且整个资源交付周期从分钟级别升高到了秒级。 然而，随着Hulk1.0的推广和落地，也暴露出一些新的问题： 稳定性差：因为复用了OpenStack的底层资源管理能力，整个扩容过程包含两层的资源调度，且数据同步流程简单，机房的隔离性也比拟差，经常出现一个机房呈现问题，其余机房的扩缩容也受到影响。能力欠缺：因为波及的零碎多，并且是跨部门合作，故障节点的迁徙和恢复能力不易实现，资源类型也比拟繁多，整个故障排查和沟通效率低下。扩展性差：Hulk1.0的管制层面对底层资源的治理能力受限，无奈依据场景和需要疾速扩大。性能：业务对于扩缩容和弹性资源的交付速度需要进一步提高，且容器技术的弱隔离性导致业务的服务受到的烦扰增多，负面反馈减少。 上述的问题通过一段时间的优化和改善，始终不能彻底解决。在这种状况下，咱们不得不从新思考整个容器平台的架构合理性，而此时Kubernetes已逐渐被业界认可和利用，它清晰的架构和先进的设计思路让咱们看到了心愿。所以咱们基于Kubernetes构建了新的容器平台，在新的平台中Hulk齐全基于原生的Kubernetes API，通过Hulk API来对接外部的公布部署零碎，这样两层API将整个架构解耦开来，畛域明确，利用治理和资源管理能够独立迭代，Kubernetes弱小的编排和资源管理能力凸显。 容器化的外围思路是让Kubernetes做好资源层面的治理，而通过下层的管制层解决对美团利用管理系统和运维零碎的依赖问题，放弃Kubernetes的原生兼容性，缩小后续的保护老本，并实现了疾速收敛资源管理的需要。同时，也缩小了用户基于新平台的资源申请的学习老本，这点十分重要，也是后续咱们能疾速大规模迁徙基础设施资源的“根底”。 2.2 容器化过程的挑战和应答策略2.2.1 简单灵便、动静和可配置的调度策略 美团产品泛滥，业务线和利用特点形形色色，所以相应的，咱们对于资源类型和调度策略的需要也是十分多。例如，有些业务须要特定的资源类型（SSD、高内存、高IO等等），有些业务须要特定的打散策略（例如机房、服务依赖等），所以如何很好地应答这些多样化的需要，就是一个很大的问题。 为了解决这些问题，咱们为扩容链路减少了策略引擎，业务能够对本人的利用APPKEY自定义录入策略需要，同时基于大数据分析的服务画像，也会依据业务特点和公司的利用管理策略为业务策略举荐，最终这些策略会保留到策略核心。在扩容过程中，咱们会主动为利用的实例打上对应的需要标签，并最终在Kubenretes中失效，实现预期的资源交付。 2.2.2 精细化的资源调度和经营 精细化的资源调度和经营，之所以做精细化经营次要是出于两点思考：业务的资源需要场景简单，以及资源有余的状况较多。 咱们依靠公有云和私有云资源，部署多个Kubenretes集群，这些集群有些是承载通用业务，有些是为特定利用专有的集群，在集群维度对云端资源进行调配，包含机房的划分、机型的辨别等。在集群之下，咱们又依据不同的业务须要，建设不同业务类型的专区，以便做到资源池的隔离来应答业务的须要。更细的维度，咱们针对利用层面的资源需要、容灾需要以及稳定性等做集群层的资源调度，最初基于底层不同硬件以及软件，实现CPU、MEM和磁盘等更细粒度的资源隔离和调度。 2.2.3 利用稳定性的晋升和治理 不论是VM，还是最后的容器平台，在利用稳定性方面始终都存在问题。为此，咱们须要在保障利用的SLA上做出更多的致力。 2.2.3.1 容器复用 在生产环境中，宿主机的产生重启是一种十分常见的场景，可能是被动重启也可能是被动，但用户角度来看，宿主机重启意味着用户的一些零碎数据就可能失落，代价还是比拟高的。咱们须要防止容器的迁徙或重建，间接重启复原。但咱们都晓得，在Kubernetes中，对于Pod中的容器的重启策略有以下几种：Always、OnFailure和Never，宿主机重启后容器会从新被创立。 为了解决这个问题，咱们为容器的重启策略类型减少了Reuse策略。流程如下： kubelet在SyncPod时，重启策略如果是Reuse则会获取对应Pod已退出状态的App容器，如果存在则拉起最新的App容器（可能有多个），如果不存在则间接新建。更新App容器映射的pauseID为新的pause容器ID，这样就建设了Pod下新的pause容器和原先App容器的映射。从新拉起App容器即可实现Pod状态同步，最终即便宿主机重启或内核降级，容器数据也不会失落。2.2.3.2 Numa感知与绑定 用户的另一个痛点与容器性能和稳定性相干。咱们一直收到业务反馈，同样配置的容器性能存在不小的差别，次要体现为局部容器申请提早很高，通过咱们测试和深入分析发现：这些容器存在跨Numa Node拜访CPU，在咱们将容器的CPU应用限度在同一个Numa Node后问题隐没。所以，对于一些提早敏感型的业务，咱们要保障利用性能体现的一致性和稳定性，须要做到在调度侧感知Numa Node的应用状况。 为了解决这个问题，咱们在Node层采集了Numa Node的分配情况，在调度器层减少了对Numa Node的感知和调度，并保障资源应用的均衡性。对于一些强制须要绑定Node的敏感型利用，如果找不到适合的Node则扩容失败；对于一些不须要绑定Numa Node的利用，则能够抉择尽量满足的策略。 2.2.3.3 其余稳定性优化 在调度层面，咱们为调度器减少了负载感知和基于服务画像利用特色的打散和优选策略。在故障容器发现和解决上，基于特色库落地的告警自愈组件，可能秒级发现-剖析-解决告警。对于一些有非凡资源需要，例如高IO、高内存等利用采纳专区隔离，防止对其余利用造成影响。2.2.4 平台型业务容器化 置信做过ToB业务的同学应该都理解，任何产品都存在大客户计划，那么对于美团这样的公司，外部也会存在这种状况。平台型业务的容器化有个特点是：实例数多，以千或万计，所以资源老本就比拟高；业务位置比拟高，个别都是十分外围的业务，对性能和稳定性要求很高。所以，如果想要通过“一招鲜”的形式解决此类业务的问题，就有些不切实际。 这里，咱们以MySQL平台为例，数据库业务对于稳定性、性能和可靠性要求十分高，业务本人又次要以物理机为主，所以老本压力十分大。针对数据库的容器化，咱们次要是从宿主机端的资源分配定制和优化为切入口。 针对CPU资源分配，采纳独占CPU汇合的形式，防止Pod之间产生争抢。通过容许自定义SWAP大小来应答短暂的高流量，并敞开Numa Node和PageCache来晋升稳定性。在磁盘调配中采纳Pod独占磁盘进行IOPS的隔离，以及通过预调配和格式化磁盘来晋升扩容的速度，晋升资源交付效率。调度反对独有的打散策略和缩容确认，躲避缩容危险。 最终，咱们将数据库的交付效率晋升了60倍，并且在大多数状况下性能比之前的物理机器还要好。 ...

这是一篇容器常识的梳理不是教程什么是容器在IT畛域，容器能够了解为集装箱，而不是一种瓶子。Linux Container是一种内核轻量级的操作系统层虚拟化技术。 Linux Container由以下两个机制来保障实现的 namespace 命名空间，做隔离作用Cgroup 负责资源管理管制作用容器3大特点轻量霎时+挪动弹性伸缩容器标准化OCI（open container initiative）凋谢容器协定 容器运行时规范（runtime spec）容器镜像规范（image spec）容器的次要利用场景容器技术次要解决了paas（plantform as a service）的层的技术实现 场景如下： 挺高原有利用的安全性和可移植性通过docker减速自动化部署微服务，防止“天堂式矩阵依赖”IT基础设施优化，充分利用基础设施，节俭资金为什么要应用容器？容器使软件具备了超强的可移植能力 docker是一种容器引擎docker因为太过出名简直就成为了容器的代名词。docker是容器的一种 其余容器引擎： k8s:Kubernetes镜像仓库中镜像拉取下来，进行运行就成为了容器。容器能够增加其余镜像或者文件，打包成新的镜像。 dockerfile文件形容一个镜像是如何被构建进去的 镜像运行起来就是容器容器技术的思考形式是：将环境一起打包镜像防止部署时的环境问题dockerfile记录镜像的制作步骤镜像 容器 仓库 的概念能够类比代码 过程 github援用文献https://www.cnblogs.com/qcloud1001/p/9273549.html

这是一篇容器常识的梳理不是教程什么是容器在IT畛域，容器能够了解为集装箱，而不是一种瓶子。Linux Container是一种内核轻量级的操作系统层虚拟化技术。 Linux Container由以下两个机制来保障实现的 namespace 命名空间，做隔离作用Cgroup 负责资源管理管制作用容器3大特点轻量霎时+挪动弹性伸缩容器标准化OCI（open container initiative）凋谢容器协定 容器运行时规范（runtime spec）容器镜像规范（image spec）容器的次要利用场景容器技术次要解决了paas（plantform as a service）的层的技术实现 场景如下： 挺高原有利用的安全性和可移植性通过docker减速自动化部署微服务，防止“天堂式矩阵依赖”IT基础设施优化，充分利用基础设施，节俭资金为什么要应用容器？容器使软件具备了超强的可移植能力 docker是一种容器引擎docker因为太过出名简直就成为了容器的代名词。docker是容器的一种 其余容器引擎： k8s:Kubernetes镜像仓库中镜像拉取下来，进行运行就成为了容器。容器能够增加其余镜像或者文件，打包成新的镜像。 dockerfile文件形容一个镜像是如何被构建进去的 镜像运行起来就是容器容器技术的思考形式是：将环境一起打包镜像防止部署时的环境问题dockerfile记录镜像的制作步骤镜像 容器 仓库 的概念能够类比代码 过程 github援用文献https://www.cnblogs.com/qcloud1001/p/9273549.html

原文链接如下：https://www.toutiao.com/i6805...近几年来，Docker 在企业环境的利用端具备很大的后劲，在这一点上我想大家是引人注目的，无状态的服务采纳容器化曾经是一种大趋势，那么问题来了，作为系统核心的数据库是否须要容器化？ 针对数据库是否适宜容器化这个问题，不同的人可能会给出不同的答案，在答复此问题之前咱们先看下容器化部署数据库和惯例数据库部署上的一些比拟。 Docker不适宜部署数据库的7大起因1、数据安全问题不要将数据贮存在容器中，这也是 Docker 官网容器应用技巧中的一条。容器随时能够进行、或者删除。当容器被rm掉，容器里的数据将会失落。为了防止数据失落，用户能够应用数据卷挂载来存储数据。然而容器的 Volumes 设计是围绕 Union FS 镜像层提供长久存储，数据安全不足保障。如果容器忽然解体，数据库未失常敞开，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件伤害也比拟大。 即便你要把 Docker 数据放在主机来存储 ，它仍然不能保障不丢数据。Docker volumes 的设计围绕 Union FS 镜像层提供长久存储，但它依然不足保障。 应用以后的存储驱动程序，Docker 依然存在不牢靠的危险。如果容器解体并数据库未正确敞开，则可能会损坏数据。 2、性能问题大家都晓得，MySQL 属于关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，导致IO瓶颈，大大降低 MySQL 的读写性能。 在一次Docker利用的十大难点专场上，某国有银行的一位架构师也曾提出过：“数据库的性能瓶颈个别呈现在IO下面，如果按 Docker 的思路，那么多个docker最终IO申请又会呈现在存储下面。当初互联网的数据库多是share nothing的架构，可能这也是不思考迁徙到 Docker 的一个因素吧”。 针对性能问题有些同学可能也有绝对应的计划来解决： (1)数据库程序与数据拆散 如果应用Docker 跑 MySQL，数据库程序与数据须要进行拆散，将数据寄存到共享存储，程序放到容器里。如果容器有异样或 MySQL 服务异样，主动启动一个全新的容器。另外，倡议不要把数据寄存到宿主机里，宿主机和容器共享卷组，对宿主机损坏的影响比拟大。 (2)跑轻量级或分布式数据库 Docker 里部署轻量级或分布式数据库，Docker 自身就举荐服务挂掉，主动启动新容器，而不是持续重启容器服务。 (3)合理布局利用 对于IO要求比拟高的利用或者服务，将数据库部署在物理机或者KVM中比拟适合。目前TX云的TDSQL和阿里的Oceanbase都是间接部署在物理机器，而非Docker 。 3、网络问题要了解 Docker 网络，您必须对网络虚拟化有深刻的理解。也必须筹备应酬好意外状况。你可能须要在没有反对或没有额定工具的状况下，进行 bug 修复。 咱们晓得：数据库须要专用的和长久的吞吐量，以实现更高的负载。咱们还晓得容器是虚拟机管理程序和主机虚拟机背地的一个隔离层。然而网络对于数据库复制是至关重要的，其中须要主从数据库间 24/7 的稳固连贯。未解决的 Docker 网络问题在1.9版本仍然没有失去解决。 把这些问题放在一起，容器化使数据库容器很难治理。我晓得你是一个顶级的工程师，什么问题都能够失去解决。然而，你须要花多少工夫解决 Docker 网络问题？将数据库放在专用环境不会更好吗？节省时间来专一于真正重要的业务指标。 4、状态在 Docker 中打包无状态服务是很酷的，能够实现编排容器并解决单点故障问题。然而数据库呢？将数据库放在同一个环境中，它将会是有状态的，并使系统故障的范畴更大。下次您的应用程序实例或应用程序解体，可能会影响数据库。 知识点在 Docker 中程度伸缩只能用于无状态计算服务，而不是数据库。 Docker 疾速扩大的一个重要特色就是无状态，具备数据状态的都不适宜间接放在 Docker 外面，如果 Docker 中装置数据库，存储服务须要独自提供。 ...

原文链接如下：https://www.toutiao.com/i6805...近几年来，Docker 在企业环境的利用端具备很大的后劲，在这一点上我想大家是引人注目的，无状态的服务采纳容器化曾经是一种大趋势，那么问题来了，作为系统核心的数据库是否须要容器化？ 针对数据库是否适宜容器化这个问题，不同的人可能会给出不同的答案，在答复此问题之前咱们先看下容器化部署数据库和惯例数据库部署上的一些比拟。 Docker不适宜部署数据库的7大起因1、数据安全问题不要将数据贮存在容器中，这也是 Docker 官网容器应用技巧中的一条。容器随时能够进行、或者删除。当容器被rm掉，容器里的数据将会失落。为了防止数据失落，用户能够应用数据卷挂载来存储数据。然而容器的 Volumes 设计是围绕 Union FS 镜像层提供长久存储，数据安全不足保障。如果容器忽然解体，数据库未失常敞开，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件伤害也比拟大。 即便你要把 Docker 数据放在主机来存储 ，它仍然不能保障不丢数据。Docker volumes 的设计围绕 Union FS 镜像层提供长久存储，但它依然不足保障。 应用以后的存储驱动程序，Docker 依然存在不牢靠的危险。如果容器解体并数据库未正确敞开，则可能会损坏数据。 2、性能问题大家都晓得，MySQL 属于关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，导致IO瓶颈，大大降低 MySQL 的读写性能。 在一次Docker利用的十大难点专场上，某国有银行的一位架构师也曾提出过：“数据库的性能瓶颈个别呈现在IO下面，如果按 Docker 的思路，那么多个docker最终IO申请又会呈现在存储下面。当初互联网的数据库多是share nothing的架构，可能这也是不思考迁徙到 Docker 的一个因素吧”。 针对性能问题有些同学可能也有绝对应的计划来解决： (1)数据库程序与数据拆散 如果应用Docker 跑 MySQL，数据库程序与数据须要进行拆散，将数据寄存到共享存储，程序放到容器里。如果容器有异样或 MySQL 服务异样，主动启动一个全新的容器。另外，倡议不要把数据寄存到宿主机里，宿主机和容器共享卷组，对宿主机损坏的影响比拟大。 (2)跑轻量级或分布式数据库 Docker 里部署轻量级或分布式数据库，Docker 自身就举荐服务挂掉，主动启动新容器，而不是持续重启容器服务。 (3)合理布局利用 对于IO要求比拟高的利用或者服务，将数据库部署在物理机或者KVM中比拟适合。目前TX云的TDSQL和阿里的Oceanbase都是间接部署在物理机器，而非Docker 。 3、网络问题要了解 Docker 网络，您必须对网络虚拟化有深刻的理解。也必须筹备应酬好意外状况。你可能须要在没有反对或没有额定工具的状况下，进行 bug 修复。 咱们晓得：数据库须要专用的和长久的吞吐量，以实现更高的负载。咱们还晓得容器是虚拟机管理程序和主机虚拟机背地的一个隔离层。然而网络对于数据库复制是至关重要的，其中须要主从数据库间 24/7 的稳固连贯。未解决的 Docker 网络问题在1.9版本仍然没有失去解决。 把这些问题放在一起，容器化使数据库容器很难治理。我晓得你是一个顶级的工程师，什么问题都能够失去解决。然而，你须要花多少工夫解决 Docker 网络问题？将数据库放在专用环境不会更好吗？节省时间来专一于真正重要的业务指标。 4、状态在 Docker 中打包无状态服务是很酷的，能够实现编排容器并解决单点故障问题。然而数据库呢？将数据库放在同一个环境中，它将会是有状态的，并使系统故障的范畴更大。下次您的应用程序实例或应用程序解体，可能会影响数据库。 知识点在 Docker 中程度伸缩只能用于无状态计算服务，而不是数据库。 Docker 疾速扩大的一个重要特色就是无状态，具备数据状态的都不适宜间接放在 Docker 外面，如果 Docker 中装置数据库，存储服务须要独自提供。 ...

在刚刚完结的CLOUD NATIVE+ OPEN SOURCE Virtual Summit China 2020上，由华为云云原生团队主导的容器批量计算我的项目Volcano正式公布1.0版本，标记着Volcano我的项目曾经开始走向成熟与稳固。 Volcano我的项目介绍Volcano是基于Kubernetes的云原生批量计算引擎，基于华为云在AI、大数据畛域的深厚业务积攒，补齐了Kubernetes在面向AI、大数据、高性能计算等批量计算任务调度、编排等场景下的短板，向下反对鲲鹏、昇腾、X86等多元算力，向上使能TensorFlow、Spark、华为MindSpore等支流行业计算框架，让数据科学家和算法工程师充沛享受到云原生技术所带来的高效计算与极致体验。 Volcano架构示意图 随着Kubernetes作为AI、大数据和高性能批量计算的下一代基础设施的趋势逐步清晰，越来越多的企业对Kubernetes在深度学习、科学计算、高性能渲染等方面提出了更高的要求。 然而Kubernetes作为普适的容器化解决方案，仍与业务诉求存在肯定差距，次要体现在： K8s的原生调度性能无奈满足计算要求K8s作业管理能力无奈满足AI训练的简单诉求数据管理方面，短少计算侧数据缓存能力，数据地位感知等性能资源管理方面短少分时共享，利用率低硬件异构能力弱Volcano的诞生正是基于这些痛点，在调度、作业管理、数据管理、资源管理四个方面进行了重点优化。 加强了任务调度能力，如偏心的调度（fair-share）、组调度（gang-scheduling）进一步优化了作业管理能力,如multiple pod template能力、更灵便的error handling机制减少计算侧数据缓存，晋升数据的传输与读取效率引入多维度的综合评分机制，实现资源更高效的治理和调配多元算力反对：反对x86、鲲鹏和昇腾等算力 Volcano v1.0新个性介绍Volcano v1.0的外围概念和要害个性，次要蕴含以下要点： Queue、PodGroup、Volcano Job等外围概念均已实现反对Binpack、Conformance、DRF、Gang、Preempt、Reclaim、Priority、Proportion等多种调度策略反对Rest API、CLI等多种交互方式实现与Spark、Argo、MPI、Flink、Mxnet、Paddlepaddle、Tensorflow、MindSpore等支流高性能计算框架的无缝对接反对Job的全生命周期治理和动静扩缩容反对GPU异构与共享齐备的golangCI-lint check、e2e以建设加强代码品质和稳定性除以上个性外，Volcano始终保持与Kubernetes社区、Golang最新版本保持一致。 Volcano社区和生态建设停顿通过一年多的倒退，Volcano的社区和生态建设曾经步入快车道。截至目前，社区和生态建设获得了以下问题： 社区贡献者80+社区奉献参加组织15+，包含华为、百度、腾讯、AWS、IBM、 Oracle等取得Star 1100+，Fork 220+代码库7个，Release 6个Issue 320+，PR 590+已实现对Spark、Argo、MPI、Flink、Mxnet、Paddlepaddle、Tensorflow、MindSpore、Cromwell等10+支流计算框架的反对华为云CCE（云容器引擎）、CCI（云容器实例）、ModelArts等多个云服务已将Volcano集成为基础设施底座并商用，服务畛域已涵盖AI、大数据利用、基因计算、批处理等场景，并实现与华为鲲鹏、昇腾处理器深度交融，最快每秒1000个容器的调度发放，成为高性能、极致性价比的批量计算解决方案。深刻理解Volcano如果想更加深刻理解Volcano，能够参考以下资源： Volcano官网： https://volcano.sh/ Github： https://github.com/volcano-sh Volcano简介： https://github.com/volcano-sh... Volcano设计： https://github.com/volcano-sh... Volcano路线图： https://github.com/volcano-sh... Volcano社区交换微信群： Volcano CN 将来可期随着Volcano v1.0的公布，Volcano社区建设与上下游生态的交融必将更加严密，基于Volcano的商业利用也将极大地促成AI、大数据、科学计算、渲染等畛域充沛享受到云计算带来的极大便当和极致体验，助力企业数字化转型进入新的高度。 展望未来，华为云也将在云原生畛域继续耕耘，继续引领翻新、凋敝生态，助力各行业走向疾速智能倒退之路。 点击关注，第一工夫理解华为云陈腐技术~

近日，寰球权威的信息技术钻研和剖析公司 Gartner 公布了《Hype Cycle for ICT in China, 2020》报告即“2020中国 ICT 技术成熟度曲线报告”，其中容器即服务（ CaaS ）为新兴技术热点，获得了飞速成长，且市场对容器技术的关注与趣味仍在急剧回升中。BoCloud博云作为国内容器云畛域（ CaaS ）的领军企业入选该报告，被评为 CaaS 容器云“代表性厂商”（ Sample Vendor ）。 技术成熟度曲线是 Gartner 为企业提供的评估新技术成熟度的典型工具。新兴技术是反对企业数字化转型的要害翻新引擎，中国 ICT 技术成熟度曲线是企业用户和技术厂商提供评估新技术成熟度的典型工具，也是评估新兴数字化技术趋势、技术后劲和商业后劲提供重要依据。 Gartner 容器平台是中国ICT市场热点 Gartner 指出，对于企业而言，2020年数字化转型依然是高度优先事项。企业正在经验从技术导向向服务导向的转变，其中以容器、DevOps、多云平台为代表的现代化基础设施平台是这些企业须要重点关注的三大方向之一。报告中显示，CaaS（容器即服务）作为新兴技术热点，获得了飞速成长，因为人们对容器运行时的采纳越来越多，市场对容器技术的关注与趣味仍在急剧回升中。 Gartner 指出，云原生应用程序须要高度的基础设施自动化、专业化的操作能力，但这对于企业 IT 并不容易实现。而 CaaS 容器云能够让企业 IT 更便捷地应用容器性能，为企业 IT 在生产力和敏捷性带来了不言而喻的劣势，包含减速和简化应用程序生命周期能力、实现不同环境间的工作负载可移植性、进步资源利用率等。 在中国外乡 CaaS 容器云市场上，以后容器技术收益正当，市场潜力笼罩了5%-20%的指标受众，技术成熟度凸显。Gartner 指出，以 BoCloud 博云为代表的国内容器服务提供商是强有力的外乡竞争者。 博云 深耕容器畛域，把握底层外围能力 近年来，容器技术凭借轻量化和标准化的显著个性，逐步成为云计算畛域基础设施云化的改革技术。作为云原生（ cloud native ）生态的基石，容器技术未然成为云原生时代的规范基础设施。 作为国内最早瞄准容器畛域为企业级用户提供容器云服务的提供商之一，博云基于 kubernetes 自主研发的 BeyondContainer 容器云平台，始终保持聚焦平台底层能力的晋升，依据用户理论需要，对容器网络、负载平衡能力、胖容器等容器底层核心技术进行了改良与加强，确保能满足用户 IT 麻利化的需要。 自研容器网络 网络对于容器云平台的稳定性、扩展性影响十分大。随着容器云平台在企业的大量落地，企业亟需缓解在落地公有容器云平台时遇到的网络阻力。博云 BeyondFabric 容器网络是基于OpenVswitch (OVS) 自研的 Kubernetes CNI 插件，能够实现内外网互通、治理业务网络拆散、灵便的网络隔离机制、易于运维治理和调试等性能。 ...

云原生技术岂但能够最大化云的弹性，帮忙企业实现降本提效，而且还有着更多翻新的设想空间。云原生将和 AI、边缘计算、秘密计算等新技术相结合，进入新的进化阶段，为数字经济构建智能、互联、信赖三位一体的翻新基础设施。 首届 KubeCon 2020 线上峰会圆满结束，阿里云作为 CNCF 最重要的云原生布道搭档，此次携 37 位云原生专家与宽广开发者分享了 27 场演讲，云原生话题丰盛度在本场流动中位居首位。作为峰会的压轴主题演讲，CNCF 理事会成员、阿里云容器服务负责人易立发表演讲《云原生，数字经济技术创新基石》 ，重点介绍了阿里云如何通过开源云原生技术与凋谢云原生产品，帮忙企业晋升面向疫情的应变能力，拥抱数字经济倒退的新机遇。与此同时，与大家分享了阿里云对云原生技术普惠和云原生操作系统的思考，并详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 等四款企业级容器新品。 相干文章举荐： 提前剧透｜KubeCon 2020 峰会上阿里云要展现什么大杀器？疫情以后，云原生为数字经济按下快进键2020 年，疫情突发之后，政府、企业和学校对在线合作的需要猛增。 “下班用钉钉，上学云课堂，出门衰弱码，订菜送到家”成了咱们日常生活的一部分，数字经济发展势头空前低落。这背地是一系列云计算、云原生技术撑持的业务翻新，云原生正在买通数字化落地的“最初一公里”。 钉钉扛住了有史以来最大的流量洪峰。春节后第一天停工，钉钉霎时迎来了近程办公流量顶峰：阿里云 2 小时内撑持了钉钉业务 1 万台云主机的扩容需要。基于云服务器和容器化的利用部署计划，让利用公布扩容效率大大晋升，为全国用户提供线上工作的晦涩体验。 希沃课堂顺利积攒超过 30 万老师开设 200 万节课程。面对指数级增长的流量，希沃课堂通过容器服务 ACK 高效治理神龙裸金属服务器和 Serverless 弹性容器实例，整个平台兼具高性能、高弹性、低成本、免保护的劣势。整体业务性能晋升 30%，运维老本升高 50%，给全国老师和学生提供了更好服务。 支付宝 3 天实现三省精准防控全笼罩。支付宝减速研发全国对立的疫情防控衰弱信息码，短短 3 天工夫，浙江、四川、海南三省陆续实现衰弱码全笼罩。云原生大数据平台提供了弱小的数据对立、会集和计算能力。基于云原生利用架构的码引擎零碎反对了业务需要的疾速迭代，具备弹性、韧性和平安的特点，安稳撑持每日亿次调用，成为宽广市民日常非亲非故的“衰弱通行证”。 盒马全程保障疫情期间居民日常供给。这背地是盒马整个数字化的供应链体系施展了重要作用。基于阿里云边缘容器服务 ACK@Edge 底座，盒马团队疾速构建了人、货、场数字化全链路交融，云、边、端一体化协同的天眼 AI 零碎。联合了云原生技术体系良好的资源调度和利用治理能力，与边缘计算就近拜访，实时处理的劣势，轻松实现全方位的降本提效，门店计算资源老本节俭 50%，新店开服效率晋升 70%。 三位一体 阿里云打下数字时代新基建的“底色”云原生架构与技术肯定是凋谢的，须要全行业独特定义与建设。阿里巴巴作为云原生畛域的先行者、实践者，基于本身累积多年的最佳实际，继续对社区赋能，为企业提供普惠的云原生产品服务，与开发者共建云原生生态，帮忙更多用户分享时代技术红利。 阿里巴巴致力于为数字经济构建智能、互联、信赖三位一体的翻新基础设施，引领云原生进化新阶段。反观阿里云容器服务团队近期在 AI、边缘、秘密计算三个畛域的开源新动静，与智能、互联、信赖的方向一一对应。 1. AI-智能企业在 IT 转型的大潮中对数字化和智能化的诉求越来越强烈，最突出的需要是如何能疾速、精准地从海量业务数据中开掘出新的商业机会和模式翻新，能力更好应答多变、不确定性的业务挑战。 阿里云提供云原生 AI 解决方案从底层异构计算资源，到下层计算框架进行全栈优化。次要个性有对立资源管理、高效共享隔离、对立调度器架构、分布式数据缓存、全生命周期赋能。同时阿里云也将这些成绩分享到社区，目前已有来自苹果、IBM、微博等贡献者和咱们在开源社区单干共建。 2. 边缘-互联阿里云公布边缘容器服务 ACK@Edge，短短一年内，曾经利用于音视频直播、云游戏、工业互联网、交通物流、城市大脑等利用场景中，并服务于盒马、优酷、阿里视频云和泛滥互联网、新批发企业。近期，阿里巴巴正式对外发表将其外围能力开源，并向社区奉献残缺的云原生边缘计算我的项目——OpenYurt。它深度开掘了“边缘计算+云原生落地施行”诉求。 Kubernetes 有弱小的容器编排、资源调度能力，但在边缘 / IoT 场景中，对低功耗、异构资源适配、云边网络协同等方面有独特的需要。OpenYurt 主打“云边一体化”概念，通过对原生 Kubernetes 进行扩大的形式反对边缘计算场景需要。将来，OpenYurt 将采纳开源社区开发模式，逐渐将产品残缺能力开源，并继续推动 K8s 上游社区兼顾边缘计算的需要。 ...

云原生技术岂但能够最大化云的弹性，帮忙企业实现降本提效，而且还有着更多翻新的设想空间。云原生将和 AI、边缘计算、秘密计算等新技术相结合，进入新的进化阶段，为数字经济构建智能、互联、信赖三位一体的翻新基础设施。 首届 KubeCon 2020 线上峰会圆满结束，阿里云作为 CNCF 最重要的云原生布道搭档，此次携 37 位云原生专家与宽广开发者分享了 27 场演讲，云原生话题丰盛度在本场流动中位居首位。作为峰会的压轴主题演讲，CNCF 理事会成员、阿里云容器服务负责人易立发表演讲《云原生，数字经济技术创新基石》 ，重点介绍了阿里云如何通过开源云原生技术与凋谢云原生产品，帮忙企业晋升面向疫情的应变能力，拥抱数字经济倒退的新机遇。与此同时，与大家分享了阿里云对云原生技术普惠和云原生操作系统的思考，并详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 等四款企业级容器新品。 相干文章举荐： 提前剧透｜KubeCon 2020 峰会上阿里云要展现什么大杀器？疫情以后，云原生为数字经济按下快进键2020 年，疫情突发之后，政府、企业和学校对在线合作的需要猛增。 “下班用钉钉，上学云课堂，出门衰弱码，订菜送到家”成了咱们日常生活的一部分，数字经济发展势头空前低落。这背地是一系列云计算、云原生技术撑持的业务翻新，云原生正在买通数字化落地的“最初一公里”。 钉钉扛住了有史以来最大的流量洪峰。春节后第一天停工，钉钉霎时迎来了近程办公流量顶峰：阿里云 2 小时内撑持了钉钉业务 1 万台云主机的扩容需要。基于云服务器和容器化的利用部署计划，让利用公布扩容效率大大晋升，为全国用户提供线上工作的晦涩体验。 希沃课堂顺利积攒超过 30 万老师开设 200 万节课程。面对指数级增长的流量，希沃课堂通过容器服务 ACK 高效治理神龙裸金属服务器和 Serverless 弹性容器实例，整个平台兼具高性能、高弹性、低成本、免保护的劣势。整体业务性能晋升 30%，运维老本升高 50%，给全国老师和学生提供了更好服务。 支付宝 3 天实现三省精准防控全笼罩。支付宝减速研发全国对立的疫情防控衰弱信息码，短短 3 天工夫，浙江、四川、海南三省陆续实现衰弱码全笼罩。云原生大数据平台提供了弱小的数据对立、会集和计算能力。基于云原生利用架构的码引擎零碎反对了业务需要的疾速迭代，具备弹性、韧性和平安的特点，安稳撑持每日亿次调用，成为宽广市民日常非亲非故的“衰弱通行证”。 盒马全程保障疫情期间居民日常供给。这背地是盒马整个数字化的供应链体系施展了重要作用。基于阿里云边缘容器服务 ACK@Edge 底座，盒马团队疾速构建了人、货、场数字化全链路交融，云、边、端一体化协同的天眼 AI 零碎。联合了云原生技术体系良好的资源调度和利用治理能力，与边缘计算就近拜访，实时处理的劣势，轻松实现全方位的降本提效，门店计算资源老本节俭 50%，新店开服效率晋升 70%。 三位一体 阿里云打下数字时代新基建的“底色”云原生架构与技术肯定是凋谢的，须要全行业独特定义与建设。阿里巴巴作为云原生畛域的先行者、实践者，基于本身累积多年的最佳实际，继续对社区赋能，为企业提供普惠的云原生产品服务，与开发者共建云原生生态，帮忙更多用户分享时代技术红利。 阿里巴巴致力于为数字经济构建智能、互联、信赖三位一体的翻新基础设施，引领云原生进化新阶段。反观阿里云容器服务团队近期在 AI、边缘、秘密计算三个畛域的开源新动静，与智能、互联、信赖的方向一一对应。 1. AI-智能企业在 IT 转型的大潮中对数字化和智能化的诉求越来越强烈，最突出的需要是如何能疾速、精准地从海量业务数据中开掘出新的商业机会和模式翻新，能力更好应答多变、不确定性的业务挑战。 阿里云提供云原生 AI 解决方案从底层异构计算资源，到下层计算框架进行全栈优化。次要个性有对立资源管理、高效共享隔离、对立调度器架构、分布式数据缓存、全生命周期赋能。同时阿里云也将这些成绩分享到社区，目前已有来自苹果、IBM、微博等贡献者和咱们在开源社区单干共建。 2. 边缘-互联阿里云公布边缘容器服务 ACK@Edge，短短一年内，曾经利用于音视频直播、云游戏、工业互联网、交通物流、城市大脑等利用场景中，并服务于盒马、优酷、阿里视频云和泛滥互联网、新批发企业。近期，阿里巴巴正式对外发表将其外围能力开源，并向社区奉献残缺的云原生边缘计算我的项目——OpenYurt。它深度开掘了“边缘计算+云原生落地施行”诉求。 Kubernetes 有弱小的容器编排、资源调度能力，但在边缘 / IoT 场景中，对低功耗、异构资源适配、云边网络协同等方面有独特的需要。OpenYurt 主打“云边一体化”概念，通过对原生 Kubernetes 进行扩大的形式反对边缘计算场景需要。将来，OpenYurt 将采纳开源社区开发模式，逐渐将产品残缺能力开源，并继续推动 K8s 上游社区兼顾边缘计算的需要。 ...

Kata Containers 开源我的项目于2017年底正式启动，其指标是将虚拟机（VM）的平安劣势与容器的高速及可管理性相结合，为用户带来杰出的容器解决方案。该我的项目在过来两年获得了哪些停顿？下一版本的路线图蕴含什么个性？首先让咱们疾速回顾一下 Kata Containers 我的项目的奋进之路…  缘起：Kata Containers2013 年，Docker 问世，容器成为热门新事物，寰球的开发者为之着迷。也难怪，容器以规范格局封装，将运行于规范操作系统环境上的利用打包，使应用程序可从一个计算环境疾速牢靠的切换至另一个计算环境，这对于那些想要疾速构建、测试和部署软件的开发者而言至关重要。容器具备轻量化、低开销的个性，简直能够立刻被调度和启动，可在任何环境中运行，为微服务提供便当，扩大资源等（以上仅列举了一些风行的劣势）。 只管有许多技术劣势，但容器有一个毛病 - 容器与宿主机共享内核，这可能会引发重大的安全漏洞问题。实践上，如果您在单个主机上部署了多个容器，一旦其中某个容器被恶意代码利用，因为共享namespace，该主机上的其余所有容器也容易受到攻打，在这种状况下，可能会对云基础设施整体形成重大的平安威逼。如果您是云供应商，平安威逼可能会扩大到云端客户的数据和业务，这是相对要防止的。 图1. 传统容器：次要通过共享内核的 Cgroup 和 Namespace 来达到容器隔离和资源限度的目标 因而，许多负责大规模容器运行的运维人员将容器“嵌套”在虚拟机中，从逻辑上将其与运行在同一主机上的其余过程隔离开，但在虚拟机中运行容器会丢失容器的速度和敏捷性劣势。Intel 和 Hyper.sh（已退出蚂蚁团体）的开发人员意识到了这个问题，同时开始独立研发解决方案，两家公司都心愿容器能够解脱传统虚机的所有包袱，换言之，就是开发“面向云原生的虚拟化”技术： 来自 Intel 开源技术核心的工程师在 Intel Clear Containers 我的项目中使用 Intel Virtualization Technology（Intel VT）技术来强化性能和平安隔离；与此同时，Hyper.sh 的工程师采纳类似的策略启动了开源我的项目 runV，将容器放在一个平安“沙箱”中，通过反对多种 CPU 架构和管理程序，侧重于开发技术中立的解决方案；2017年，两家公司将我的项目合并，互为补充，创立了开源我的项目 Kata Containers。Intel 和 Hyper.sh 联结开发者社区，心愿在各方的共同努力下，兼顾性能和兼容性，在为终端用户提供杰出利用体验的同时，减速开发新的性能个性以满足将来新兴用例的需要。Kata Containers 成为 OpenStack 基金会（OSF）除 OpenStack 之外的首个托管我的项目，该我的项目于2017年12月在北美 KubeCon 上正式公开亮相，社区座右铭是“快如容器，稳似虚机”。 其实质是，通过 Kata Containers 让每个容器/pod 采纳其独自的内核，运行在一个轻量级的虚拟机中。因为每个容器/pod 当初都运行在专属虚拟机中，恶意代码无奈再利用共享内核来拜访邻近的容器，因而，容器即服务(CaaS)供应商可能更平安的提供在裸金属上运行容器的服务。因为容器之间的硬件隔离，Kata Containers 容许互不信赖的租户，甚至生产利用及未经认证的生产应用程序都能在同一集群内平安运行。 图2. Kata Containers: 每个容器/pod 被隔离在各自的轻量级虚拟机中 因而，Kata Containers 与容器一样轻便快捷，并且可与容器生态系统无缝集成（包含风行的编排工具，如 Docker 和 Kubernetes），同时还具备虚拟机的平安劣势。 社区停顿Kata Containers 我的项目成立的第一年，社区次要致力于合并 Intel 及 Hyper.sh 的代码，并在寰球的行业流动中介绍该我的项目独特的硬件隔离计划，这是其余容器运行时所不足的性能，同时也邀请了大量的社区开发者独特推动该我的项目。 Kata Containers 社区现在曾经领有泛滥的贡献者和支持者，包含来自九州云、阿里巴巴、AMD、AWS、百度、Canonical、中国移动、CityNetwork、戴尔易安信、易捷行云、战火通信、谷歌、华为、IBM、微软、红帽、SUSE、腾讯、同方有云、中兴、英伟达、Mirantis、NetApp、PackageCloud、Packet、Vexxhost 等许多有影响力公司的开发者。随着社区的一直壮大，该我的项目正在稳步发展中。 社区成就包含： ...

摘要：业界通用的第一代裸金属容器尽管能为业务提供短缺的CPU资源，但如何提供与算力匹配的高性能、低开销、疾速弹性扩缩的网络资源，对现有的容器网络技术提出了一系列挑战。金融、电商、在线教育、游戏等时延敏感型业务对算力和网络IO提出了极致的性能诉求，要求运行环境可能最大限度的提供计算和网络资源。 业界通用的第一代裸金属容器尽管能为业务提供短缺的CPU资源，但如何提供与算力匹配的高性能、低开销、疾速弹性扩缩的网络资源，对现有的容器网络技术提出了一系列挑战。 近一年多来，支流私有云容器服务和各家Kubernetes商业发行版都在容器网络方面加大投入，咱们发现，这些商用加强个性和开源翻新计划，尽管场景或指标有差异，但简直都把“卸载”（Offloading)和“减速”（Acceleration)作为技术主线。 华为云基于擎天架构实现的容器网络，开创性的采纳了软硬协同、卸载、Kubernetes Service下沉、高密直通等技术，构建了业内当先的容器网络计划，成为华为云构建寰球独家零损耗裸金属容器的杀手锏之一。 硬件直通 网络性能零损耗要彻底解决容器的互通性问题，必须赋予容器与节点等同的互通能力，这是容器网络的一次重大演进，即把容器网络与底层网络拉平，被Kubernetes社区称为VPC-Native的CNI。 容器网络Yangtse就是采纳VPC-Native组网，这种组网被称作ENI(Elastic Network Interface)模式，容器间接挂载具备VPC子网地址的ENI，具备齐全VPC网络互通能力，即容器地址属于VPC子网，容器独占对应的ENI网口，容器实例能够在集群VPC网络和与之相连的其余VPC网络中进行原生路由，并且能够间接应用VPC原生的网络能力如 network policy、ELB、EIP、NAT等。 同时基于华为云擎天架构的软硬协同能力，将治理和转发逻辑下沉到擎天卡上，实现容器网络主机资源0占用。 数据面转发能力卸载至擎天卡后，还大大提高包转发率和升高时延，采纳VF直通容器，实现零损耗的网络转发性能，容器内网卡与裸金属服务器主网卡性能持平 动静队列 高算力主动匹配高IO以后容器网络计划中，无论是宽泛采纳的Calico路由或VPC路由模式的veth/ipvlan组网，还是新兴的VPC-Native弹性网卡(ENI)组网，都没有针对不同的容器规格提供差别化的网口规格。 内核单队列虚构网络设备veth/ipvlan或是固定队列的ENI网口，转发能力是受限的，起因在于网络报文的转发逻辑是在内核软中断中解决的。 当网络设备的收发队列有报文达到须要转发时，会触发相应的软中断，内核通过中断负载平衡机制将不同网口队列的中断分发给不同的CPU核并行处理，从而晋升转发性能。 不言而喻，单队列或固定队列网口是无奈灵便满足HPC等计算与IO双密集的容器负载，使得网络IO成为瓶颈点，拉长了工作负载运行工夫，进步了客户老本。 而容器网络Yangtse反对网口动静多队列，可能依据容器负载的规格，比方：16核的容器负载，容器网络会主动调配16队列的直通ENI，实现计算与IO的主动匹配，提供最优的整体性能，达成了货真价实的高性能弹性计算。 Service卸载 一跳中转性能倍增Kubernetes原生的Kube-proxy提供了集群内Service负载平衡能力，iptables/netfilter被誉为Linux内核的瑞士**，也是Kube-proxy的第一个实现计划。 随着Kubernetes生产集群的规模越来越大，Service数量和后端数量也会同步增长，iptables的规定数是服务数与后端数的乘积，当规定数超过5000后，规定刷新性能和新建连贯速率（线性查表）都会显著好转，CPU、内存占用会急剧回升。 容器网络Yangtse将Kube-proxy下沉至擎天卡，形象出Internal LB的概念，利用流表的卸载能力实现Service拜访一跳中转，不仅晋升了Service性能，而且开释了裸金属服务器的计算资源，缩小了资源损耗。 综上所述，华为云在容器网络方面曾经做出大量创新性的摸索，并逐渐利用到产品中晋升产品的商业价值，或奉献给社区，以促成云原生技术倒退。 除了文中提到的三点外，容器网络Yangtse为反对大规模容器部署和疾速扩容，还提供了更多的黑科技，咱们将在下一篇文章中为您具体介绍。 申请第二代裸金属容器：https://www.huaweicloud.com/product/cce.html 点击关注，第一工夫理解华为云陈腐技术~

1、在k8s中部署利用流程制作镜像（个别通过Dockerfile）1、hub.docker.com（规范镜像）2、满足个性化定制化需要（标准化、调优参数等）控制器治理Pod裸露应用服务对外公布利用治理日志/集群监控2、应用Deployment部署Java利用[root@k8s-m ~]# docker run -d --name=web -p 80:80 e a=test nginx[root@k8s-m ~]# kubectl create --help[root@k8s-m ~]# kubectl create deployment --help[root@k8s-m ~]# docker pull yejf/java-demo[root@k8s-m ~]# kubectl create deployment web --image=yejf/java-demo:latest[root@k8s-m ~]# kubectl get podNAME READY STATUS RESTARTS AGEnginx-f89759699-bxftk 1/1 Running 0 17hweb-7757ff5c-pt6jd 1/1 Running 0 83s[root@k8s-m ~]# kubectl get deploy,podsNAME READY UP-TO-DATE AVAILABLE AGEdeployment.apps/nginx 1/1 1 1 2d16hdeployment.apps/web 1/1 1 1 2m53sNAME READY STATUS RESTARTS AGEpod/nginx-f89759699-bxftk 1/1 Running 0 17hpod/web-7757ff5c-pt6jd 1/1 Running 0 2m53s[root@k8s-m ~]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-f89759699-bxftk 1/1 Running 0 17h 10.244.215.77 k8s-n1 <none> <none>web-7757ff5c-pt6jd 1/1 Running 0 5m55s 10.244.111.205 k8s-n2 <none> <none>[root@k8s-m ~]#[root@k8s-m ~]# kubectl expose deployment web --port=80 --target-port=8080 --name=web --type=NodePort[root@k8s-m ~]# kubectl get serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d17hnginx NodePort 10.100.4.40 <none> 80:30026/TCP 2d16hweb NodePort 10.104.68.193 <none> 80:32583/TCP 47s[root@k8s-m ~]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d17hnginx NodePort 10.100.4.40 <none> 80:30026/TCP 2d16hweb NodePort 10.104.68.193 <none> 80:32583/TCP 51shttp://192.168.X.63:32853 ...

导语： 几年前，当博云启动自研容器网络研发的时候，除了技术选型的思考，咱们对于先做 Underlay 还是 Overlay 网络也有过深度的探讨。过后的开源社区以及支流容器厂商，少数还是以 Overlay 网络计划为主，但在咱们对泛滥客户真正需要的深刻理解之后，发现局部客户对容器内外网络直通有着十分强烈的需要。思虑再三，咱们决定还是先做 Underlay 网络（起初又做了Overlay）。随着行业与公司本身的倒退，咱们建设施行的我的项目越来越多，这让咱们对容器网络的思考也越来越深刻，从而观点也越来越清晰： 内外直通的Underlay网络才是容器网络的正确打开方式。 01 从需要登程，思考容器网络计划 如上图所示，这是目前企业微服务容器化部署的典型场景，也是驱动咱们做 Underlay网络的间接起因： 服务部署在Kubernetes集群外部（如图：服务1、服务2）；数据库、注册核心、Redis、MQ等组件部署在集群之外；局部服务也可能部署在集群之外, 比方容器平台试用阶段（如图：服务3）这些服务和组件，须要能间接互联互通。 如若须要满足以上需要，最简略无效的计划就是间接把 Kubernetes 内外网络买通，也就是采纳 Underlay 网络模式。 当然，如上需要也有别的方法能够解决。比方，细化剖析服务和组件间的流量，采纳ingress、egress，包含改写利用代码等形式，在特定状况下，这也是能够用的。然而，一方面，这些都是特定场景下的特定解决方案，不足肯定的通用性；另一方面，容易呈现配置简单、引入额定危险、出错难以定位等问题。远远没有通过Underlay网络间接将内外网买通这么简略无效。 还有另外的方法就是将所有服务和组件都放入Kubernetes集群外部，然而这种计划仍是针对特定场景的非通用计划，很难保障企业所有的利用都在一个Kubernetes集群里。 同样，对于容器内外网络间接互联互通的需要场景还有： 特定用处的Kubernetes集群对外提供服务。比方专门用作提供PaaS中间件服务的Kubernetes集群、专门用作CI/CD服务的Kubernetes集群、专门用作提供大数据服务的Kubernetes集群等；跨多集群的服务/组件互联互通；为了在试点阶段升高危险，局部服务跑在集群内、局部服务跑在集群外等场景。02 与虚拟机比照，从容器实质思考容器网络计划 在容器的利用实际过程中，除了利用场景，咱们也从底层基础设施的角度对容器进行了继续的思考。 从基础设施的角度看容器：容器和虚拟机的实质都是一样的，是下层利用的承载基础设施。 因而，从底层角度看，对容器网络的需要跟虚拟机是统一的。那么，虚拟机网络的落地模式是怎么的呢? 如上图右侧局部所示，IaaS层的落地网络计划能够认为是有行业标准的，不论是基于VMware 还是 OpenStack，根本都是采纳OVS（或相似OVS）的二层 Underlay 网络计划。 因而，从基础设施的角度往上看，容器网络采纳跟 IaaS 相似的计划，行将虚拟机和容器放到同一个网络层面上，是最正当的抉择。 PS：在私有云上，虚拟机都在VPC里，因而目前私有云的容器网络计划，也是次要采纳将容器和虚拟机放到同一个VPC中，能够间接互联互通的计划。这也是对上述判断的典型证实。 同时，对于局部客户反馈的 Unberlay 网络占用 IP 地址过多的问题，从虚拟机和容器的比照角度，也能够取得正当的解释：如果应用虚拟机部署，占用 IP 地址数量与容器 Underlay 网络是一样的。IP 地址的数量是由利用数量决定的，应用容器并没有引入多余 IP 地址占用。另外，Ipv6曾经开始规模落地，在Ipv6时代，IP 地址数量将不会是问题。 03 技术计划选型 容器典型的开源 Unberlay 网络选型计划有 Calico 和 MACVLAN，这两个计划的问题也比拟显著： Calico：须要在数据中心路由器（或三层交换机）关上 BGP 路由协定，而 BGP 是广域网的路由协定，个别在数据中心外部不会启动，低端三层交换机/路由器对齐的反对状况也有危险。 MACVLAN：几年前有局部客户采纳此容器网络计划，MACVLAN最大的问题就是社区活跃度曾经很低，一些问题长期没有在社区中解决。同时，面向未来的扩展性也比拟差。 以上也是博云基于 OVS 自研 Underlay（也反对Overlay）网络的起因。 ...

作者 | 王庆璨（阿里云技术专家）、张凯（阿里云高级技术专家） 导读：阿里云容器服务团队联合多年 Kubernetes 产品与客户反对教训，对 Kube-scheduler 进行了大量优化和扩大，逐渐使其在不同场景下仍然能稳固、高效地调度各种类型的简单工作负载。《进击的 Kubernetes 调度零碎》系列文章将把咱们的教训、技术思考和实现细节全面地展示给 Kubernetes 用户和开发者，冀望帮忙大家更好地理解 Kubernetes 调度零碎的弱小能力和将来倒退方向。本文为该系列文章的第二篇。 前言什么是 Coscheduling 和 Gang scheduling。Wikipedia 对 Coscheduling 的定义是“在并发零碎中将多个相关联的过程调度到不同处理器上同时运行的策略”。在 Coscheduling 的场景中，最次要的准则是保障所有相关联的过程可能同时启动。避免局部过程的异样，导致整个关联过程组的阻塞。这种导致阻塞的局部异样过程，称之为“碎片（fragement）”。 在 Coscheduling 的具体实现过程中，依据是否容许“碎片”存在，能够细分为 Explicit Coscheduling，Local Coscheduling 和 Implicit Coscheduling。 其中 Explicit Coscheduling 就是大家常听到的 Gang Scheduling。Gang Scheduling 要求齐全不容许有“碎片”存在， 也就是“All or Nothing”。 咱们将上述定义的概念对应到 Kubernetes 中，就能够了解 Kubernetes 调度零碎反对批工作 Coscheduling 的含意了。 一个批工作（关联过程组）包含了 N 个 Pod（过程），Kubernetes 调度器负责将这 N 个 Pod 调度到 M 个节点（处理器）上同时运行。如果这个批工作须要局部 Pod 同时启动即可运行，咱们称需启动 Pod 的最小数量为 min-available。特地地，当 min-available=N 时，批工作要求满足 Gang Scheduling。 ...

数字化时代，数字经济带来的微小劣势，让企业一直向数字化转型迈进，企业在IT基础设施建设、混合多云治理等畛域面临迫切的转型与降级，并在这一过程中遇到较多问题与难题。作为国内撑持企业数字化转型的云计算PaaS技术中台及多云治理服务商，博云时刻关注并深刻理解企业IT建设的需要。 本周起，BoCloud博云将在微信公众号开明【你问我答】小栏目，咱们将收集和整顿企业在IT建设所遇到的问题与难题，由博云产品与技术团队进行针对性答复，每周五通过【你问我答】栏目进行公布，心愿能为企业IT建设提供思路与办法。无论您是哪个行业的IT建设者，如果您有在容器云平台建设、微服务架构转型、DevOps平台建设、多云治理平台建设等技术方面所遇到的问题，欢迎您间接评论留言发问。 以下是本周问题精选： 01 网友1：容器平台、微服务平台、devops平台在布局建设的时候如何能有序整合起来？ 博云产品团队：容器平台、微服务平台、DevOps平台目前是IT零碎布局建设的重点，三个平台之间某些性能有重合的中央，比方容器平台自身有CI/CD的性能，那在建设的时候如何能对立进行标准， 各个平台独自建设时候的侧重点别离是什么，如何划分各平台的边界，以及如何将三个平台无缝对接起来？咱们倡议： 1. 容器平台与服务治理在以下维度雷同，须要从统一化进行治理： ①利用治理；②服务治理；③实例治理；④聚合治理；采纳对立权限核心治理，数据权限与操作权限灵便设置，以用户+权限定义产品状态和治理领域。平台治理重点在于资源管理，租户治理重点在于利用治理和服务治理能力。 2. 在建设DevOps的过程中，须要联合企业本身开发运维的流程，与容器云与微服务治理平台的联合的过程中，更多的思考整体DevOps过程中须要实现的场景，而不是仅仅思考CI/CD。 02 网友2：在公有云中，在容器环境下平安区域怎么划分，是否设置DMZ区域？ 博云产品团队：能够思考部署多个容器集群来设置不同区域。测试环境、生产环境齐全隔离的状况下，可思考建设DMZ区以实现可能须要的镜像流转等场景。 03 网友3：团体容器云如何建设？产品选型及规范上有哪些倡议？ 咱们团体是一家大型地方企业，属下业务板块泛滥，有金融板块（银行、证券、保险等）、地产板块、交通物流板块、工业板块等，金融板块IT比拟独立。团体在落实数字化转型中，提出两平台一体系的建设：云平台、大数据平台、数据治理体系。云平台建设是根底，是团体数字化转型的底座，云平台建设重点是PaaS平台。依照团体信息化的特点及现状，总部综合管控零碎、上司公司业务零碎等根本采纳购买第三方的成熟产品套件，这块齐全云化，不太事实，须要第三方厂家产品反对。 对于容器云建设，这个在传统行业也刚刚起步，在容器云建设大家意识不对立： 第一，齐全自研不太事实，资源配置有余； 第二，采纳容器云平台，行业的软件提供商在反对容器开发上产品不多。 基于这样的场景，团体容器云如何建设？采纳k8s+docker是否可能满足将来的云化需要？行业内的PaaS平台不足统一标准，各厂家产品的组件化提供形式不太成熟（组件化输入为能力，移植到自有的PaaS平台）。在产品选型及规范上有什么好的倡议？传统的利用是否有必要向容器云分拆成微服务？ 博云产品团队：在思考第三方容器云平台的选型上，这个问题有很多简单的影响因素，包含技术和非技术的，不同的组织状况不尽相同。咱们更倡议在如下维度进行考查： 1.容器云的生产案例利用有哪些，平台生产级能力是否通过了长期有效验证，第三方团队的定制化能力，第三方团队技术赋能和为贵司团队造就的能力。2.在技术方面，开源贡献度如何，底层掌控力是否足够强。 联合您企业的现状，在考查PaaS平台时，咱们倡议除了关注容器云平台之外，也倡议关注考查PaaS平台中是否有微服务治理平台及微服务拆分征询的教训与能力。 容器云平台可重点考查是否具备多集群、多租户体系、对立认证能力、CICD能力、容器化及非容器化全生命周期对立治理的能力、中间件集成能力、网络计划是否合乎贵司组网、平安计划、DevOps能力、利用容器化施行能力，与贵司已有零碎对接整合的能力、与基础设施的交融能力等。 微服务治理平台可重点考查反对的微服务架构是否与贵司采纳的架构统一，组件的性能如何，全链路调用链分析能力。 PaaS云平台既要与底层基础设施交互，又要反对顶层利用，涉及面和覆盖面都十分广，因而建设过程中与单位外部已有设施、流程等进行联合时须要进行综合思考，上述内容仅作抛砖引玉的参考。 04 网友4：金融行业对网络监管、网络隔离要求严格，而容器提倡扁平化，如何思考网络安全、隔离？ 博云产品团队：借助网络命名空间，各个容器汇合都能取得本人所要绑定的 IP 和端口范畴，因而能使节点上的容器集网络互相分隔开；利用路由器或防火墙的办法来管制进口流量的容器平台，以便利用 IP 白名单来进行管制（例如管制数据库拜访）。 SDN思路，基于2层网络计划，集群内外网络买通，实现容器重启IP地址不变，指定IP地址公布服务，管制立体数据立体拆散，网络隔离等。 05 网友5：传统架构模式和云与docker模式联合后如何解决网络和SDN的问题？ 博云产品团队：能够应用二层网络解决与SDN网络对接的问题。咱们曾经和多家客户进行过深刻沟通，市面上支流的CNI插件对客户需要的反对并不现实，难以同时满足各种网络需要，集中体现在内外网互通、治理业务网络拆散、灵便的网络隔离机制、易于运维治理和调试等问题上，咱们本人基于openVswitch(OVS)自研一个Kubernetes CNI插件来解决这些痛点问题。 抉择OVS的起因是，在支流的二层网络计划bridge、macvlan、OVS中，OVS的性能更加丰盛，同时在支流的云技术平台中有着大量的利用，禁受了足够的考验。咱们的计划具备简略易用、反对underlay模式、反对固定IP地址、性能损耗低等个性，重点解决微服务上云过程中集群内外相互间接通信的问题，能够让企业落地容器云平台的复杂度大大降低。业务迁徙到容器云后简直感知不到基础设施从虚拟化到容器化变更带来的变动。这种部署模式能够很好的反对中间件和数据库在Kubernetes集群外部署，利用跑在Kubernetes集群内，或者微服务零碎注册核心在虚拟机环境下部署但微服务跨集群内外部署，等须要Kubernetes内外间接互通的场景。 具体能够参考： 容器网络插件那么多，博云为什么基于OVS深度自研？ 为什么咱们要自主开发一个稳固牢靠的容器网络 点击BoCloud博云_以翻新云技术 为效率而进化，获取更多产品及案例信息。

这是Jerry 2020年的第69篇文章，也是汪子熙公众号总共第251篇原创文章。 本文不含惊悚内容的图片，请大家释怀浏览。 医学界的虚拟化技术解救了Jerry的生命，所以有了这篇文章。 计算机世界的虚拟机和容器这些虚拟化技术，曾经间接或间接地影响着咱们相当一部分人的日常生活。普通人每日滑开手机，从BAT，TMDJ等国内互联网巨头的App上获取海量信息。普通人同时也是互联网上海量信息的生产者，即所谓的UGC(User Generated Content，用户生成内容)场景。普通人早已习惯了这所有，比方在微信上发一个朋友圈，点击发送之后被其余微信好友看见，咱们感觉这一切都是天经地义，理所当然的事件，殊不知像微信这种用户数量用亿作为单位来掂量的国民级挪动利用，背地不晓得凝聚了多少优良程序员的心血。 国内互联网巨头的解决方案和产品，其背地的架构和基础设施都离不开云计算。而云计算和虚拟化技术(Virtualization)更加密不可分。在Monolithic(单体式)架构的On-Premises时代，产品的部署是一件绝对轻松愉快的事件，比方Jerry在做微信和SAP Commerce集成的时候，把Commerce的安装包拷贝到一个目录下，而后顺次执行几个脚本，再去咖啡机边上转一圈，回来就实现Commerce开发环境下的部署了。到了基于微服务架构的云原生利用时代，云产品架构的复杂性，使得通过人工形式去部署产品成为了一项不可能实现的工作，自动化部署势在必行。而自动化部署，来到了虚拟化技术就只是空谈而已。 我的虚拟化技术学习之路 Jerry对于虚拟化技术只学到了一些皮毛，最开始应用虚拟机的场景是，我想在Windows 7下重温一些只能运行在纯DOS零碎的经典软件，比方光彩的《三国志IV》和《三国志V》. 而后是因为工作须要，学习了容器技术，把握了把常见的利用类型打成Docker镜像并运行的办法。起初公司组织了容器编排零碎，即Kubernetes的外部培训，我也从三位培训老师那里，理解到了虚拟机和容器技术的差别。培训老师通知咱们，虚拟机和容器的目标相似，都致力于对应用程序及其关联性进行隔离，从而构建起一套可能不依赖于具体环境而运行的利用单元。虚拟机是在物理服务器的下层用软件来模仿特定的硬件零碎，其技术外围是Hypervisor，位于硬件和零碎之间，是创立虚拟机必须的一个局部。虚拟机软件应用Hypervisor作为中间层，当宿主操作系统启动虚拟机时，通过Hypervisor给虚拟机分配内存，CPU，网络和磁盘等资源，并加载虚构的操作系统，因此须要耗费宿主机大量的物理资源。 另一方面，一台宿主机上运行的多个容器化利用共享这台宿主机操作系统的内核，因此不须要虚拟机技术中的Hypervisor中间层。同虚拟机技术相比，容器更加轻量化，启动速度更快。 当组成一个利用的容器数量冲破了人工所能治理的极限之后，就须要Kubernetes这种容器编排平台。有了Kubernetes的根底后，下一步就是学习SAP本人的产品，构建于Kubernetes之上的SAP Cloud Platform Extension Factory(基于开源我的项目Kyma). 沿着虚拟机->容器->Kubernetes->Kyma这条路线走过去，我的一些学习笔记： 站在伟人肩膀上的牛顿：Kubernetes和SAP Kyma在Kubernetes上运行SAP UI5利用(上）在Kubernetes上运行SAP UI5利用(下）基于SAP Kyma的订单编排加强介绍高射炮打蚊子，杀鸡用绝世好剑：在SAP Kyma上运行UI5利用第三方利用如何在SAP Kyma上进行服务注册WordPress，SAP Kyma和微信三者的集成从ABAP Netweaver的SICF到SAP Kyma的Lambda Function周伯通的空明拳，米诺斯的星尘傀儡线，SAP Kyma的Serverless在SAP云平台上部署和运行Docker利用Windows环境下，如何在Docker里运行SAP UI5利用SAP ABAP Netweaver容器化, 不可能实现的工作吗？国内程序员里相熟云计算虚拟化技术的同仁不可胜数，然而相熟颅内虚拟化技术的程序员想必不多，Jerry就是其中之一，只因it's online within my brain ever since this May!!! 尽管虚拟机和容器内都仿佛能像物理服务器一样地运行应用程序，然而这一切都是镜花水月：虚拟机和容器运行时均无奈脱离宿主机而独自存在。一旦宿主机出故障宕机，运行在之上的虚拟机和容器也难逃厄运。 人工硬脑膜，和硬脑膜的区别，在于后者是咱们每个人从亲妈那里继承来的原生(native)脑膜，而前者是人工合成，作为原僵硬脑膜的补充，无奈脱离后者而独自工作。 Jerry之前的文章 有感而发 - 突飞猛进的SAP开发技术和手术形式 已经提到，硬脑膜是人类颅内组织的最初一道防线，而后向外顺次是骨膜和头皮。 科学家们为了测量成年人硬脑膜的面积，先将硬脑膜剪为12块，即双箍、双顶、双挽、双额及小脑区等区域，再将其平摊在复印机上复印后，用定积分法计算结果，论断是成年男性硬脑膜的均匀面积为0.08平方米，女性为0.076平方米，大概相当于体表皮肤面积的1/22. 硬脑膜的厚度并非一张纸那样平均，而是随着膜区地位不同而有所变动，均匀厚度约为0.7到1毫米。 硬脑膜到底有多硬？每平方毫米的硬脑膜，能接受37千克左右的抗张力强度。人类通过漫长的进化史，失去了这道人造的爱护大脑的松软屏障。然而，如果颅内组织本身出了问题，这道爱护屏障的坚硬也会给神经外科医生带来一些麻烦。为了可能进入颅内切除病变组织，神经外科医生不得不借助各种器械，在松软的硬脑膜上钻孔。医院用的开颅钻头们有国内生产的，也有国外进口的，都是大家伙： 另一方面，神经外科医生们钻开硬脑膜，关上颅内切除完病灶后，手术也还远远不算完。有一种疾病叫做细菌性脑膜炎，由流感嗜血杆菌B型、脑膜炎奈瑟菌和肺炎链球菌这三种病菌，通过咳嗽或者打喷嚏进行流传。人在患感冒时容易被这三种病菌传染，病菌进入颅内引起颅内感化。既然硬脑膜完整无缺时，尚且有病菌侵入的危险，更不用说做了开颅手术后留下这么大的窟窿，如果不采取任何修复措施，术后感化的危险极大。这时就轮到人工硬脑膜上场了，目标就是填补开颅钻生成的窟窿。 人工硬脑膜作为原僵硬脑膜的补充，二者的关系就如同虚拟机/容器之于宿主操作系统一样：前者不能脱离后者而独自存在。 ...