-
大家应该都看过某些明星导致社交媒体平台宕机的新闻吧?明星事件带来的突发流量触发业务扩容,以前是扩容虚机,速度慢还情有可原,现在大部分互联网平台都使用容器了,为什么扩容速度有些时候还是跟不上流量增长的节奏呢?这里主要有两个问题。01一是网口发放速度匹配容器扩容速度的问题。如果是即时按需创建容器,比如10秒内启动5000个容器实例,这要求10秒内完成端到端的网口创建、挂接和网络打通。处理流程上,容器网络控制器需要调用VPC网络API批量创建5000个网口,VPC控制面生成相应的配置,下发到各个主机节点,主机按配置创建好全部网口再挂接到节点上,进而挂接到容器上,与此同时,分布在各个主机和各类网关的数据面转发表也要同步完成刷新。传统的I层网络架构,无论是管控面还是数据面都存在瓶颈点,全流程网络打通的速度,无法匹配容器扩容速度。02再一个就是网口规模的问题,由于ENI原本是针对I层虚机或裸机的网卡扩展机制,数量受节点规格的限制,有的厂商是按照主机的flavor限定ENI的规格数量,某些厂商提供了固定的最大数量,比如8个,这些规格约束有商业成本的考虑,但根本原因还是规模目标不同。容器为了榨干节点资源,支持0.1核甚至更小的容器,单节点理论上可部署近千容器实例,也就需要近千网口,这与现有VPC网络的管控面和数据面规模有数量级差距。网络资源预热让秒级扩容成为可能如何应对发放速度不匹配问题?计算机系统结构的经典答案:加“Cache”层, 就是按预定策略在节点建立预分配ENI的warm pool,集群纳管节点时,自动创建并配置好若干个ENI放入pool中,在批量启动容器的时候只需要把已经ready的ENI从warm pool中取出挂接到容器即可。网络资源预热能够有效弥补VPC 网络资源分配性能不能匹配容器生命周期的现状。加‘Cache’的机制能够支撑容器大批量创建删除场景。Warm pool机制主要解决端到端网络打通时间长的问题。目前VPC网络单节点网卡是串行处理的,而且单个网络设备绑定时间也达到了30s-60s,不做预热的情况下容器网络端到端打通时间在一分钟以上。分钟级容器启动时间是不可接受的。Warm pool机制在裸金属节点上预挂载一定数量ENI(用户可根据服务部署并发量自定义配置),容器随时调度到预热节点上都有即时可用的ENI网卡。经过warm pool的优化,容器网络端到端打通时间缩短为1s-2s。华为云容器网络Yangtse的warm pool其实早在裸金属容器之前就已经在云容器实例CCI中得到了实践,是CCI能以30秒扩容1000容器的绝对优势领先业界的技术手段之一。突破ENI数量限制支持大规模容器扩容上文中讲到了,单服务器ENI的规格上限,限制了容器的高密度部署和大规模快速扩容,在第二代裸金属容器中,我们把容器网络组件全部卸载到了华为云擎天卡上,突破了传统架构的约束,最大ENI数量提升数十倍,单服务器可部署的容器数量也相应提升。同时,得益于擎天架构资源共池优势,裸金属容器还可以向虚拟机容器扩容,而在虚拟机容器上,容器网络Yangtse使用了Trunkport技术,结合ENI的优势,在保障性能的前提下,单台服务器理论上可为千容器同时提供直通网络能力。ELB直通容器应对海量冲击更平稳解决了速度和规模的问题后,其实还存在一个隐藏的杀手,处理不好,可能使我们新扩容出来的容器全部命丧于此。在传统的容器网络对接外部ELB方案中,外部流量会从ELB先到Kubernetes的Node Port(工作节点所在主机的端口),然后再转发给后端容器,增加的这一跳不仅带来了时延和故障几率,也影响了ELB使用时的灵活性。当应用业务流量增长触发扩容时,如果ELB直接全量发放分摊的流量请求,海量请求会迅速压垮(overload)新扩的容器,造成扩容失败。发生这种情况跟业务的处理逻辑或运行时行为相关:新扩容的后端实例需要一边处理请求一边加载热点数据到本地Cache,或者需要根据接收到的请求即时编译(JIT)和加载相应的代码模块,这都需要“慢启动”(slow-start)过程,即根据业务模型,自定义初始流量比例和阶梯递增速率,比如:15%的初始流量,每5秒增加10%。但是,当ELB挂接宿主服务器(节点)的网络端口(Node Port)时,特别是一个节点上部署多个容器时,由于存在节点二次分发,ELB无法感知到最终的后端容器,进而无法做到容器级别的流控,也难以保证稳态后的负载均衡。容器网络Yangtse实现了与华为云ELB v3独享型负载均衡实例的直通,独享型ELB v3资源独立,实例的性能不受其它实例的影响,而且流量从ELB直通至后端容器,保证转发性能和稳定性。 关于裸金属容器网络的揭秘,就到这里了。后续我们将围绕华为云云原生技术平台Vessel,逐一为您解读华为云容器的黑科技。
-
金融、电商、在线教育、游戏等时延敏感型业务对算力和网络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
-
k8s已经成为当今容器化的标准,人们在享受容器带来的高效与便利的同时,也遇到一些烦恼:客户端和容器服务器之间可能存在多种不同形式的代理服务器,那容器中如何获取到客户端真实的源ip呢?下面我们就几种场景类型如何能获取到源ip进行讨论。 原理介绍:四层转发:Nodeport:nodeport访问方式,是将容器端口映射到节点端口,如果“服务亲和”选择“集群级别”需要经过一次服务转发,无法实现获取客户端源ip,而“节点模式”不经过转发,可以获取客户端源ip。 ELB:ELB访问方式,是通过华为云ELB产品来实现负载均衡,“服务亲和”也是需要选择“节点级别”,其中“共享型”ELB需要在节点安装TOA插件,而“独享型”ELB默认透传源ip,不需要安装TOA插件。 七层转发:Ingress:应用在七层访问时,客户端源ip默认保存在HTTP头部的“X-Forwarded-For”字段,无需做其他操作。 具体操作:一、负载均衡 ( LoadBalancer )负载均衡( LoadBalancer )的Service模式下,支持容器中获取源IP需要满足以下前提条件:1. 服务亲和选择“节点级别”而不是“集群级别”。2. 在pod所在的节点安装TOA插件。(“独享型”ELB无需进行以下操作)安装TOA插件步骤如下:1) 准备编译环境:执行如下命令,安装gcc编译器。]# yum install gcc执行如下命令,安装make工具。]# yum install make2)编译内核模块a) 下载TOA内核模块源代码。]# wget https://github.com/Huawei/TCP_option_address/archive/master.zip b) 执行如下命令,进入源码目录,编译模块。]# unzip master.zip]# cd TCP_option_address-master/src/]# make编译过程未提示warning或者error,说明编译成功,检查当前目录下是否已经生成toa.ko文件。说明:如果报错提示“config_retpoline=y but not supported by the compiler, Compiler update recommended”,表明gcc版本过老,建议将gcc升级为较新版本。3)加载内核模块执行如下命令,加载内核模块。]# insmod toa.ko执行如下命令,验证模块加载情况,查看内核输出信息。]# dmesg | grep TOA若提示信息包含“TOA: toa loaded”,说明内核模块加载成功。4) 自动加载内核模块为了使TOA内核模块在系统启动时生效,可以将加载TOA内核模块的命令加到客户的启动脚本中。在“/etc/sysconfig/modules/”目录下新建toa.modules文件。该文件包含了TOA内核模块的加载脚本,请参考如下示例:#!/bin/sh/sbin/modinfo -F filename /root/toa/toa.ko > /dev/null 2>&1if [ $? -eq 0 ]; then/sbin/insmod /root/TCP_option_address-master/src/toa.kofi注意:其中“/root/TCP_option_address-master/src/toa.ko”为TOA内核模块文件的路径,客户需要将其替换为自己编译的TOA内核模块路径。执行以下命令,为toa.modules启动脚本添加可执行权限。]# chmod +x /etc/sysconfig/modules/toa.modules这种情况下可以从四层负载均衡上获取到客户端的源IP(可以通过netstat查看)。测试要点:这种情况下可以使用netstat看到客户端连接到POD的IP地址。 二、节点访问 ( NodePort )节点访问(NodePort)类型的Service的服务亲和选择“节点级别”而不是“集群级别”,即Service的 spec.externalTrafficPolicy 需要设置为 Local。图1 服务亲和选择节点级别三、七层负载均衡(Ingress)七层负载均衡的模式下,不能在四层负载均衡上获取客户端IP(不能通过netstat查看客户端IP),需要对应用服务器进行配置,然后通过七层负载均衡的http头中的x-forward-for获取。真实的来访者IP会被负载均衡放在HTTP头部的X-Forwarded-For字段,格式如下:X-Forwarded-For: 来访者真实IP, 代理服务器1-IP, 代理服务器2-IP, ...测试要点:从容器中获取http请求头”x-forward-for”,获取的IP为客户端的IP。
-
【】企业IT·开发者必看!为什么云开发是互联网大势所趋?【转载华为云社区】云开发是一个已经存在了很多年的概念,但在过去未能真正成为主流。然而,由于云和软件即服务的宏观趋势的结合,以及技术的进步,如容器技术 Docker 和 Kubernetes,云开发现在有机会最终成为基于云的应用程序的新标准开发。1.什么是云开发?云开发或基于云的开发有许多定义。广泛的定义是云开发是一种软件开发方法,它使用云环境在实际的开发阶段执行未完成的软件。这意味着你的软件在云中运行,它通常不会在你的本地计算机上运行。如果你开发的软件是在云环境中运行的,那么项目的临时环境、测试和生产环境也会在云上。其他一些人将云开发定义为使用基于浏览器和在线的 IDE。虽然基于浏览器的编辑器通常链接到云环境来执行软件,但也可以使用本地编辑器并在云中执行软件。来自 Kubernetes 和 CNCF 社区的另一个更近期的术语是“云原生开发”,但它是一个更普遍的概念,指的是“基于容器的、动态编排的、利用微服务架构的应用程序开发”。因此,它更关注开发什么,而不是如何开发。2.为什么云开发现在有了突破?·商业环境已经发生了变化。包括软件市场的一些变化可能会导致这种开发方式的复兴,甚至是最终的突破。在过去的几年里,软件世界发生了很多变化,使得云开发变得更加顺理成章和简单:使用云来运行软件已经成为常态。如今,使用云来处理生产工作负载已经成为许多公司的标准。这种转变与软件即服务销售模式的出现有关,也是云开发必不可少的第一步——只有当生产负载在云中时,将开发运行时间转移到云中才有意义。因此,云计算的广泛采用也增加了云开发的潜在用户基础。·软件变得越来越复杂随着人工智能(AI)、机器学习(ML)和微服务的兴起,软件的复杂性以及运行这些软件所需的计算资源显著增加。由于本地计算机本身的计算能力有限,它们不能够运行用户想要开发的每一个软件。在某些情况下,这甚至可能使得在开发过程中不可避免地使用云。·软件已经独立于运行环境由于使用了 Docker 和 Kubernetes 等容器技术,软件现在通常被打包在可以在任何环境下运行的容器中,无论是云还是本地环境,只要基础技术是可用的。这意味着,如果你已经在生产负载中使用了 Kubernetes,并且使用了容器,那么从本地开发切换到基于云的开发将非常简单。·一些障碍已被扫除过去的一些挑战现在得到了极大解决,这使得云开发更具可行性:网络传输如果你想在云中开发,你总是需要一个互联网连接来与云进行通信。幸运的是,在过去的几年里,人们的平均网络连接速度越来越快,而且 WiFi 无处不在。由于出于开发目的,通常只更改很小的源代码文件,因此在开发过程中不需要传输太多数据,所以现在的延迟通常是无关紧要的。部署耗时如果你不使用在线 IDE,那么你的代码需要以某种方式转移到云中,并且你的应用程序还需要更新。特别是对于容器技术,新的解决方案例如 DevSpace 可以自动将你的变更传输到云中,并且不需要重新启动容器就可以更新你的应用程序。这样可以减少部署时间ーー因为你不需要为每个小变更重新编译运行所有代码,云开发就像是本地开发。拥抱云的必要性调整遗留应用程序以便它能够在云环境中顺利运行可能 需要相当长的时间。尽管对于是否会有一个(完美的)工具可以将每个软件应用程序转换成完美的本地云应用程序仍然存在疑问,但考虑到云和 SaaS 的宏观趋势,对于越来越多的公司来说,转向云似乎是必要的。控制云访问如果每个开发人员都与云进行交互,他们就需要以某种方式访问云。集中管理和控制这种访问可能是一个巨大的挑战,特别是对于较大的团队。然而,由于公共云解决方案,创建新的基于云的开发实例非常容易。甚至可以只使用一个实例,然后在开发人员之间共享访问权。安全问题在开发过程中,在云中运行代码意味着从一开始,所有的源代码都在云中。这不一定是个问题 ーー 因为大多数公司已经在使用云中的代码库了。云成本如果你使用的是公共云,你必须为你使用的资源付费。如果你的团队中的所有开发人员都需要自己的云环境,那么计算资源的成本可能会很快变得相当高,但是现在这些成本已经能更好的降低,并且更大范围的提高开发者与软件供应商的利润增益。3.云开发的好处?总的来说,条件已经变得更好了,使用云开发比以往任何时候都更容易。现在的问题是企业IT和移动开发者为什么要这么做。无限的计算能力尽管你的计算机只能为本地开发提供有限的资源,但使用云实际上可以提供无穷无尽的计算能力。对于微服务应用程序,开发者可能需要大量的电力来启动和运行所有的服务,有时候这在本地是完全不可能的。在这种情况下,企业如果想继续有效地改进其应用程序,就只能转向云计算ーー这也是为了开发。减少准备工作不管运行环境如何,运行一个应用程序可能需要有很多步骤。但是,如果使用云开发,团队中的一个人可以设置和配置所有东西,所有其他团队成员都可以直接启动。在 Kubernetes 的世界中,这可以通过诸如 Helm DevSpace 等开源工具来实现,在这些工具中,你可以配置整个环境,然后必须将其部署到云环境中。这种可复制性是云的一个主要优势,因为硬件或操作系统之间没有差异。它也非常灵活,你可以根据个人需要进行调整。此外,公共云供应商提供了一系列工具和构建模块,你可以非常快速地开始工作。新的合作可能性和标准化由于标准化,很容易在团队中复制 bug 并相互支持。甚至可以让同事直接访问你的云环境来修复某些内容或分享你的工作成果。这可以带来更多的团队合作,形成一种新的团队合作形式,每个人都可以贡献自己的力量。从任何地方访问由于你的应用程序在开发过程中已经在云中运行,因此你不必总是使用具有非常特定设置的同一台计算机。你可以随意切换本地硬件,这样当你的计算机出现故障需要更换时就更容易了。这也支持现代的工作文化,比如在家工作或者在外工作。生活在 DevOps 文化中在云中直接开发针对云的软件非常有意义,因为在应用程序的整个生命周期中始终使用非常类似的环境。这可以减少将应用程序部署到生产环境后可能出现的错误和问题的数量。为此,基于云的开发将在你的团队中培养 DevOps 文化。开发门槛更低,效率更高提供一个数据接口容易,实现一个功能也容易,难的是解决数据的并发性,负载均衡,数据库吞吐量等难题,而这些恰恰是影响数据响应速度的关键点。而能否以快、以优、以稳制胜恰恰是当今企业发展的关键,也是大家都不可避免要面对和解决的问题。云开发为企业IT和移动开发者提供的一站式后端云服务,可以帮助他们统一构建和管理资源,免去了移动应用开发过程中繁琐的服务器、代码搭建及运维、域名注册及备案、数据接口实现等繁琐流程,让开发者可以专注于业务逻辑的实现,而无需理解后端逻辑及服务器运维知识,开发门槛更低,效率更高。
-
一、导语C++是一门被广泛使用的系统级编程语言,更是高性能后端标准开发语言;C++虽功能强大,灵活巧妙,但却属于易学难精的专家型语言,不仅新手难以驾驭,就是老司机也容易掉进各种陷阱。本文结合作者的工作经验和学习心得,对C++语言的一些高级特性,做了简单介绍;对一些常见的误解,做了解释澄清;对比较容易犯错的地方,做了归纳总结;希望借此能增进大家对C++语言了解,减少编程出错,提升工作效率。二、陷阱我的程序里用了全局变量,为何进程退出会莫名其妙的core掉?Rule:C++在不同模块(源文件)里定义的全局变量,不保证构造顺序;但保证在同一模块(源文件)里定义的全局变量,按定义的先后顺序构造,按定义的相反次序析构。我们程序在a.cpp里定义了依次全局变量X和Y;按照规则:X先构造,Y后构造;进程停止执行的时候,Y先析构,X后析构;但如果X的析构依赖于Y,那么core的事情就有可能发生。结论:如果全局变量有依赖关系,那么就把它们放在同一个源文件定义,且按正确的顺序定义,确保依赖关系正确,而不是定义在不同源文件;对于系统中的单件,单件依赖也要注意这个问题。std::sort()的比较函数有很强的约束,不能乱来相信工作5年以上至少50%的C/C++程序员都被它坑过,我已经听到过了无数个悲伤的故事,《圣斗士星矢》,《仙剑》,还有别人家的项目《天天爱消除》,都有人掉坑,程序运行几天莫名奇妙的Crash掉,一脸懵逼。如果要用,要自己提供比较函数或者函数对象,一定搞清楚什么叫“严格弱排序”,一定要满足以下3个特性:非自反性非对称性传递性尽量对索引或者指针sort,而不是针对对象本身,因为如果对象比较大,交换(复制)对象比交换指针或索引更耗费。注意操作符短路考虑游戏玩家回血回蓝(魔法)刷新给客户端的逻辑。玩家每3秒回一点血,玩家每5秒回一点蓝,回蓝回血共用一个协议通知客户端,也就是说只要有回血或者回蓝就要把新的血量和魔法值通知客户端。玩家的心跳函数heartbeat()在主逻辑线程被循环调用void GamePlayer::Heartbeat(){ if (GenHP() || GenMP()) { NotifyClientHPMP(); }}如果GenHP回血了,就返回true,否则false;不一定每次调用GenHP都会回血,取决于是否达到3秒间隔。如果GenMP回蓝了,就返回true,否则false;不一定每次调用GenMP都会回血,取决于是否达到5秒间隔。实际运行发现回血回蓝逻辑不对,Word麻,原来是操作符短路了,如果GenHP()返回true了,那GenMP()就不会被调用,就有可能失去回蓝的机会。你需要修改程序如下:void GamePlayer::Heartbeat(){ bool hp = GenHP(); bool mp = GenMP(); if (hp || mp) { NotifyClientHPMP(); }}逻辑与(&&)跟逻辑或(||)有同样的问题, if (a && b) 如果a的表达式求值为false,b表达式也不会被计算。有时候,我们会写出 if (ptr != nullptr && ptr->Do())这样的代码,这正是利用了操作符短路的语法特征。别让循环停不下来for (unsigned int i = 5; i >=0; --i){ //...}程序跑到这,WTF?根本停不下来啊?问题很简单,unsigned永远>=0,是不是心中一万只马奔腾?解决这个问题很简单,但是有时候这一类的错误却没这么明显,你需要罩子放亮点。内存拷贝小心内存越界memcpy,memset有很强的限制,仅能用于POD结构,不能作用于stl容器或者带有虚函数的类。带虚函数的类对象会有一个虚函数表的指针,memcpy将破坏该指针指向。对非POD执行memset/memcpy,免费送你四个字:自求多福注意内存重叠内存拷贝的时候,如果src和dst有重叠,需要用memmov替代memcpy。理解user stack空间很有限不能在栈上定义过大的临时对象。一般而言,用户栈只有几兆(典型大小是4M,8M),所以栈上创建的对象不能太大。用sprintf格式化字符串的时候,类型和符号要严格匹配因为sprintf的函数实现里是按格式化串从栈上取参数,任何不一致,都有可能引起不可预知的错误; /usr/include/inttypes.h里定义了跨平台的格式化符号,比如PRId64用于格式化int64_t用c标准库的安全版本(带n标识)替换非安全版本比如用strncpy替代strcpy,用snprintf替代sprintf,用strncat代替strcat,用strncmp代替strcmp,memcpy(dst, src, n)要确保[dst,dst+n]和[src, src+n]都有有效的虚拟内存地址空间。多线程环境下,要用系统调用或者库函数的安全版本代替非安全版本(_r版本),谨记strtok,gmtime等标准c函数都不是线程安全的。STL容器的遍历删除要小心迭代器失效vector,list,map,set等各有不同的写法:int main(int argc, char *argv[]){ //vector遍历删除 std::vector v(8); std::generate(v.begin(), v.end(), std::rand); std::cout << "after vector generate...\n"; std::copy(v.begin(), v.end(), std::ostream_iterator(std::cout, "\n")); for (auto x = v.begin(); x != v.end(); ) { if (*x % 2) x = v.erase(x); else ++x; } std::cout << "after vector erase...\n"; std::copy(v.begin(), v.end(), std::ostream_iterator(std::cout, "\n")); //map遍历删除 std::map m = {{1,2}, {8,4}, {5,6}, {6,7}}; for (auto x = m.begin(); x != m.end(); ) { if (x->first % 2) m.erase(x++); else ++x; } return 0;}有时候遍历删除的逻辑不是这么明显,可能循环里调了另一个函数,而该函数在某种特定的情况下才会删除当前元素,这样的话,就是很长一段时间,程序都运行得好好的,而当你正跟别人谈笑风生的时候,忽然crash,这就尴尬了。圣斗士星矢项目曾经遭遇过这个问题,基本规律是一个礼拜game server crash一次,折磨团队将近一个月。比较low的处理方式可以把待删元素放到另一个容器WaitEraseContainer里保存下来,再走一趟单独的循环,删除待删元素。当然,我们推荐在遍历的同时删除,因为这样效率更高,也显得行家里手。三、性能空间换取时间通过空间换取时间是提高性能的惯用法,bitmap,int map[]这些惯用法要了然于胸。减少拷贝 & COW了解Copy On Write。只要可能就应该减少拷贝,比如通过共享,比如通过引用指针的形式传递参数和返回值。延迟计算和预计算比如游戏服务器端玩家的战力,由属性a,b决定,也就是说属性a,b任何一个变化,都需要重算战力;但如果ModifyPropertyA(),ModifyPropertyB()之后,都重算战力却并非真正必要,因为修改属性A之后有可能马上修改B,两次重算战力,显然第一次重算的结果会很快被第二次的重算覆盖。而且很多情况下,我们可能需要在心跳里,把最新的战力值推送给客户端,这样的话,ModifyPropertyA(),ModifyPropertyB()里,我们其实只需要把战力置脏,延迟计算,这样就能避免不必要的计算。在GetFightValue()里判断FightValueDirtyFlag,如果脏,则重算,清脏标记;如果不脏,直接返回之前计算的结果。预计算的思想类似。分散计算分散计算是把任务分散,打碎,避免一次大计算量,卡住程序。哈希减少字符串比较,构建hash,可能会多费一点存储空间,但收益可观,信我。日志节制日志的开销不容忽视,要分级,可以把日志作为debug手段,但要release干净。编译器为什么不给局部变量和成员变量做默认初始化因为效率,C++被设计为系统级的编程语言,效率是优先考虑的方向,c++秉持的一个设计哲学是“不为不必要的操作付出任何额外的代价”。所以它有别于java,不给成员变量和局部变量做默认初始化,如果需要赋初值,那就由程序员自己去保证。结论:从安全的角度出发,不应使用未初始化的变量,定义变量的时候赋初值是一个好的习惯,很多错误皆因未正确初始化而起,C++11支持成员变量定义的时候直接初始化,成员变量尽量在成员初始化列表里初始化,且要按定义的顺序初始化。理解函数调用的性能开销(栈帧建立和销毁,参数传递,控制转移),性能敏感函数考虑inlineX86_64体系结构因为通用寄存器数目增加到16个,所以64位系统下参数数目不多的函数调用,将会由寄存器传递代替压栈方式传递参数,但栈帧建立、撤销和控制转移依然会对性能有所影响。递归的优点、缺点虽然递归函数能简化程序编写,但也常常带来运行速度变慢的问题,所以需要预估好递归深度,优先考虑非递归实现版本。递归函数要有退出条件且不能递归过深,不然有爆栈危险。四、数据结构和容器了解std::vector的方方面面和底层实现vector是动态扩容的,2的次方往上翻,为了确保数据保存在连续空间,每次扩充,会将原member悉数拷贝到新的内存块; 不要保存vector内对象的指针,扩容会导致其失效 ;可以通过保存其下标index替代。运行过程中需要动态增删的vector,不宜存放大的对象本身 ,因为扩容会导致所有成员拷贝构造,消耗较大,可以通过保存对象指针替代。resize()是重置大小;reserve()是预留空间,并未改变size(),可避免多次扩容; clear()并不会导致空间收缩 ,如果需要释放空间,可以跟空的vector交换,std::vector .swap(v),c++11里shrink_to_fit()也能收缩内存。理解at()和operator[]的区别 :at()会做下标越界检查,operator[]提供数组索引级的访问,在release版本下不会检查下标,VC会在Debug版本会检查;c++标准规定:operator[]不提供下标安全性检查。C++标准规定了std::vector的底层用数组实现,认清这一点并利用这一点。常用数据结构数组:内存连续,随机访问,性能高,局部性好,不支持动态扩展,最常用。链表:动态伸缩,脱离插入极快,特别是带前后驱指针,内存通常不连续(当然可以通过从固定内存池分配规避),不支持随机访问。查找:3种:bst,hashtable,基于有序数组的bsearch。二叉搜索树(RBTree),这个从begin到end有序,最坏查找速度logN,坏处内存不连续,节点有额外空间浪费;hashtable,好的hash函数不好选,搜索最坏退化成链表,难以估计捅数量,开大了浪费内存,扩容会卡一下,无序;基于有序数组的bsearch,局部性好,insert/delete慢。五、最佳实践对于在启动时加载好,运行中不变化的查询结构,可以考虑用sorted array替代map,hash表等因为有序数组支持二分查找,效率跟map差不多。对于只需要在程序启动的时候构建(排序)一次的查询结构,有序数组相比map和hash可能有更好的内存命中性(局部命中性)。运行过程中,稳定的查询结构(比如配置表,需要根据id查找配置表项,运行过程中不增删),有序数组是个不错的选择;如果不稳定,则有序数组的插入删除效率比map,hashtable差,所以选用有序数组需要注意适用场合。std::map or std::unorder_map?想清楚他们的利弊,map是用红黑树做的,unorder_map底层是hash表做的,hash表相对于红黑树有更高的查找性能。hash表的效率取决于hash算法和冲突解决方法(一般是拉链法,hash桶),以及数据分布,如果负载因子高,就会降低命中率,为了提高命中率,就需要扩容,重新hash,而重新hash是很慢的,相当于卡一下。而红黑树有更好的平均复杂度,所以如果数据量不是特别大,map是胜任的。积极的使用const理解const不仅仅是一种语法层面的保护机制,也会影响程序的编译和运行。const常量会被编码到机器指令。理解四种转型的含义和区别避免用错,尽量少用向下转型(可以通过设计加以改进)static_cast, dynamic_cast,const_cast,reinterpret_cast,傻傻分不清?C++砖家说:一句话,尽量少用转型,强制类型转换是C Style,如果你的C++代码需要类型强转,你需要去考虑是否设计有问题。理解字节对齐字节对齐能让存储器访问速度更快。字节对齐跟cpu架构相关,有些cpu访问特定类型的数据必须在一定地址对齐的储存器位置,否则会触发异常。字节对齐的另一个影响是调整结构体成员变量的定义顺序,有可能减少结构体大小,这在某些情况下,能节省内存。牢记3 rules和5 rules,当然C++11又多了&&的copy ctor和op=版本只在需要接管的时候才自定义operator=和copy constructor,如果编译器提供的默认版本工作的很好,不要去自找麻烦,自定义的版本勿忘拷贝每一个成分,如果要接管就要处理好。组合优先于继承,继承是一种最强的类间关系典型的适配器模式有类适配器和对象适配器,一般而言,建议用对象适配的方式,而非用基于继承的类适配方式。减少依赖,注意隔离最大限度的减少文件间的依赖关系,用前向声明拆解相互依赖。了解pimpl技术。头文件要自给自足,不要图省事all.h,不要包含不必要的头文件,也不要把该包含的头文件推给user去包含,一句话,头文件包含要不多不少刚刚好。严格配对打开的句柄要关闭,加锁/解锁,new/delete,new[]/delete[],malloc/free要配对,可以使用RAII技术防止资源泄露,编写符合规范的代码Valgrind对程序的内存使用方式有期望,需要干净的释放,所以规范编程才能写出valgrind干净的代码,不然再好的工具碰到不按规划写的代码也是武功尽废啊。理解多继承潜在的问题,慎用多继承多继承会存在菱形继承的问题,多个基类有相同成员变量会有问题,需要谨慎对待。有多态用法抽象基类的析构函数要加virtual关键字主要是为了基类的析构函数能得到正确的调用。virtual dtor跟普通虚函数一样,基类指针指向子类对象的时候,delete ptr,根据虚函数特征,如果析构函数是普通函数,那么就调用ptr显式(基类)类型的析构函数;如果析构函数是virtual,则会调用子类的析构函数,然后再调用基类析构函数。避免在构造函数和析构函数里调用虚函数构造函数里,对象并没有完全构建好,此时调用虚函数不一定能正确绑定,析构亦如此。从输入流获取数据,要做好数据不够的处理,要加try catch;没有被吞咽的exception,会被传播从网络数据流读取数据,从数据库恢复数据都需要注意这个问题。协议尽量不要传float,如果传float要了解NaN的概念,要做好检查,避免恶意传播可以考虑用整数替代浮点,比如万分之五(5%%),就保存5。定义宏要遵循常规要对每个变量加括弧,有时候需要加do {} while(0)或者{},以便能将一条宏当成一个语句。要理解宏在预处理阶段被替换,不用的时候要#undef,要防止污染别人的代码。了解智能指针和指针的误用理解基于引用计数法的智能指针实现方式,了解所有权转移的概念,理解shared_ptr和unique_ptr的区别和适用场景考虑用std::shared_ptr管理动态分配的对象。指针能带来弹性,但不要误用,它的弹性指一方面它能在运行时改变指向,可以用来做多态,另一方面对于不能固定大小的数组可以动态伸缩,但很多时候,我们对固定大小的array,也在init里new/malloc出来,其实没必要,而且会多占用sizeof(void*)字节,而且增加一层间接访问。size_t到底是个什么?我该用有符号还是无符号整数?size_t类型是被设计来保存系统存储器上能保存的对象的最大个数。32位系统,一个对象最小的单位是一个字节,那2的32次方内存,最多能保存的对象数目就是4G/1字节,正好一个unsigned int能保存下来(typedef unsigned int size_t)。同样,64位系统,unsigned long是8字节,所以size_t就是unsigned long的类型别名。对于像索引,位置这样的变量,是用有符号还是无符号呢?像money这样的属性呢?一句话:要讲道理,用最自然,最顺理成章的类型。比如索引不可能为负用size_t,账户可能欠钱,则money用int。比如:template <class T> class vector{ T& operator(size_t index) {}};标准库给出了最好的示范,因为如果是有符号的话,你需要这样判断if (index < 0 || index >= max_num) throw out_of_bound();而如果是无符号整数,你只需要判断 if (index >= max_num),你认可吗?整型一般用int,long就很好,用short,char需要很谨慎,要防止溢出整型包括int,short,long,long long和char,没错,char也是整型,float是实型。绝大多数情况下,用int,long就很好,long一般等于机器字长,能直接放到寄存器,硬件处理起来速度也通常更快。很多时候,我们希望用short,char达到减少结构体大小的目的。但是由于字节对齐的原因,可能并不能真正减少大小,而且1,2个字节的整型位数太少,一不小心就溢出了,需要特别注意。所以,除非在db、网络这些对存储大小非常敏感的场合,我们才需要考虑是否以short,char替代int,long。其他情况下,就相当于为省电而不开楼道的灯,省不了多少钱却冒着摔断腿的危险。局部变量更没有必要用(unsigned) short,char等,栈是自动伸缩的,它既不节省空间,还危险,还慢。六、扩展了解c++高阶特性模板和泛型编程,union,bitfield,指向成员的指针,placement new,显式析构,异常机制,nested class,local class,namespace,多继承、虚继承,volatile,extern "C"等有些高级特性只有在特定情况下才会被用到,但技多不压身,平时还是需要积累和了解,这样在需求出现时,才能从自己的知识库里拿出工具来对付它。了解C++新标准关注新技术,c++11/14/17、lambda,右值引用,move语义,多线程库等c++98/03标准到c++11标准的推出历经13年,13年来程序设计语言的思想得到了很大的发展,c++11新标准吸收了很多其他语言的新特性,虽然c++11新标准主要是靠引入新的库来支持新特征,核心语言的变化较少,但新标准还是引入了move语义等核心语法层面的修改,每个CPPer都应该了解新标准。OOD设计原则并不是胡扯设计模式六大原则(1):单一职责原则设计模式六大原则(2):里氏替换原则设计模式六大原则(3):依赖倒置原则设计模式六大原则(4):接口隔离原则设计模式六大原则(5):迪米特法则设计模式六大原则(6):开闭原则熟悉常用设计模式,活学活用,不生搬硬套神化设计模式和反设计模式,都不是科学的态度,设计模式是软件设计的经验总结,有一定的价值;GOF书上对每一个设计模式,都用专门的段落讲它的应用场景和适用性,限制和缺陷,在正确评估得失的情况下,是鼓励使用的,但显然,你首先需要准确get到她。
-
【转载华为云社区】文章链接:https://bbs.huaweicloud.com/blogs/163264当今K8s独霸天下之时,咱们站在更高的角度,好好的看看K8s的网络是以什么理念构筑的。以及一个容器集群的好保姆,是如何分别照顾 南北流量和东西流量的。1 简单介绍下Kubernetes略。。容器集群管理的事实标准了,不知道要打屁股。(ps:本章节可参考唐老师的《K8S前世今生》文章)2 世界上的集群都一个样有点标题党哈,不过我接触过的各种集群也不少,各种各样:Ø OpenStack:在一大堆物理机上面,管理(启动/停止)VM的。Ø SGE,Slurm,PBS:在一大堆电脑集群里面,管理(启动/停止)App的。Ø Yarn:在一大堆电脑集群里面,管理(启动/停止)大数据App的。Ø CloudFoundry:在一大堆电脑集群里面,管理(启动/停止)容器的Ø Kubernetes:在一大堆电脑集群里面,管理(启动/停止)容器的。它们都有一些共同特点:2.1 跨节点跑xx程序这个xx程序一定是首先单机可以运行的。比如OpenStack:单机上面可以用qemu启动VM,想跨节点管理VM,就引入了OpenStack。Kubernetes也一样:单机上面可以跑Docker容器;想跨节点管理容器,就得引入集群管理老大的概念。2.2 有一个管事的老大A)集群管理的老大,负责让手下的某个小弟干活。别管是命令式(直接下命令)的,还是申明式(发告示)的,小弟收到命令后,乖乖干活就是了。B) 同时,这个集群管理的老大,需要有脑子,不然小弟数量多了管不好。所以它需要拿笔记一记。比如OpenStack的老大得带个Mysql数据库;Kubernetes把笔记记在了ETCD里面(不过ETCD这个本子太小,记得东西不能太大,这是另话)。C) 不管哪种老大,都得有个军师。一个新活来到老大这里,那么多小弟,指派给谁不是干呀。这活实际分配给哪个小弟,这得军师说了算,所以每中集群软件都自己写了一套 Scheduler 算法,可谓程序员间浪费重复轮子之典型代表。2.3 小弟上面都有一个Agent这个小弟上面的Agent,时刻向老大汇报自己的状态:活不活着,忙还是闲,方便老大派活。同时,Agent也就是那台电脑里面的地头蛇了,帮忙老大负责各种临时事物。只是大家的取名不一样:OpenStack:取名NovaKubernetes:取名KubeletYarn:取名NodeManager2.4 老大怎么给小弟发号施令一般老大都是通过:消息队列来,给小弟发号施令的,而不是亲自上门(直连)下达命令。原因么,当然是小弟可能临时出门(故障)了呗~ 直接上门可能不通,放消息队列里面就可靠多了。等小弟出差回来,还能看到老大下达的任务令。Ø OpenStack:用 RabbitMQ 发号施令Ø Kubernetes:用 ETCD 发号施令Ø CloudFoundry:用 NATS 发号施令上面这些组件都是带消息通知的功能,区别有些有名,有些没那么出名罢了。比如我们的K8s:特别需要提一下:K8s这个老大不简单,找了个ETCD这个好帮手。这小家伙挺神,既能当笔记本记点事情(代替OpenStack中的Mysql),又能当公告牌,通知点消息(代替OpenStack中的Rabbit)。所以K8s这个容器集群管理相对OpenStack这个虚机管理不需要数据库,666~3 K8s怎么设计容器网络的呢3.1 南北流量要看到K8s诞生的时候,那时是有CloudFoundry和Docker的,且都已经比较成熟。那时作为PaaS一哥的CF对容器网络的抽象:主要考虑平台外部,怎么访问容器里面的App。而平台内部的App之间如何互相访问,几乎没有太多的设计。由上图所示,可以看到,平台外部访问,一般都是上下画的,所以也叫做南北流量。我们这么叫,也是便于程序员之间沟通和理解。Ps:PaaS的基本原型大致都这样:3.2 东西流量K8s吸取了前辈们的精华,除了平台外部访问App,还新增考虑了平台内部,App之间如何互相访问。即K8s通过增加一个负载均衡的“LB”设备,来搞定平台内部的App间互相访问。给每个App取个别名,在LB上面登记一下,就可以被内部其他App访问。由上图所示,可以看到,平台内部访问,一般都是水平画的,所以也叫做东西流量。一个完整的PaaS平台,就是需要南北流量+东西流量,全套治理的。3.3 Docker原生访问方式还记得唐老师的《Docker网络实现》章节吧,Docker容器可以通过“节点IP+节点Port”的方式访问到容器。原理的容器所在节点,设置了NAT规则。报文一到达节点,根据目的端口,转发进入容器。3.4 小结:K8s中3种访问容器的通道(1) 通过南北流量(从集群外部访问App)访问App容器(2) 通过东西流量(集群内App之间)访问App容器(3) 通过Docker原生自带的方式,访问App容器下一章节,我们简单介绍下每种方式,K8s分别怎么去实现的。4 K8s怎么实现容器访问虽然K8s上面,有多种访问App容器的方法。但是不管用什么方式访问,一个App想要能被访问,就得得到K8s的同意。K8s把这个许可证叫做“Service”:也就是不管什么南北流量、东西流量,你的App想要能被访问,就得先申请Service许可证。4.1 南北流量要实现一个App的访问通道,一定要2个东西:(1)LB负载均衡器 + (2)注册映射关系。映射关系就是:报文来了,应该转发给哪个App实例? 即:找到 “哪个App + 哪个实例”。负载均衡器呢,一般大家爱用Nginx,不过也有其他类型的实现。K8s比CF聪明的地方是,没有自己去实现LB。而只定义了App需要怎么样才能登记到LB上面。即只定规范,不限制实现(这种思路,在k8s里面好多,比如存储的CSI,运行时的CRI的,容器网络的CNI 都是这样。)Ø 4层LB最简单的4层LB实现,K8s取了个名字:LoadBalancer(1)。即定义:xx协议+xx端口 =》xx应用,具体规则自己去看资料。Ø 7层LB为了定义7层LB的规则,K8s给规范取了名字:Ingress(2)。即定义:xx网址+xx-URL路径 =》xx应用,具体规则也自己看K8s资料。南北LB都是全局级的,即:全局一个(HA多实例,咱也当一个整体)就行;不需要每个Slaver节点上一个。4.2 东西流量东西流量,也一样,需要LB+规则注入。这里,K8s设计就比较有意思。逻辑上,如上图所示。在LB部分的实现上,K8s很巧妙的要求每个节点上面都一个“小LB”。所以实现上,大致如上图所示。Ø 本地LB本地LB,要求每个节点都有。所以最开始的版本,K8s使用了Linux使用广泛的iptables来实现。后面由于iptables性能不是特别给力,又有了 IPVS 实现。然后其他各式各样的民间实现也有。Ø 本地控制器LB需要一个控制器,每个本地“小LB”带配备一个小控制器,一样的,也是每个节点一个。和小LB一一对应。K8s给它取了个名字:Kube-proxyØ 假IP地址每个K8s上的App,都可以申请“行走江湖的名号”,用来代表自己。K8s就会给你的App分配一个Service许可证,许可证上面带着“影子IP”,任何集群内部只要访问这个IP,就等于访问你的App。实现上:1. 先到K8s那登记,说我想要个“名号”2. 通过后,K8s会告知每个节点上的本地LB3. 从此以后,每个LB都认识这个“影子IP”了,访问它,就代表访问对应App。由于这个“名号”是集群颁布的,所以仅在集群内有效。K8s取名:ClusterIP(3)。关于东西流量的故事,还可以去看看唐老师之前的《网络骗子》篇。4.3 Docker原生访问方式除了上面几种访问方式,K8s也为原生的Docker访问通道留了个名字:NodePort(4)。这种方式,在《Docker网络实现》里面说过,靠主机Host转发实现。既然是主机搞定,所以这条路和本地LB实现,就合并一起搞定了。如上图,K8s下发规则的时候,顺便把这条路的规则也下发下去。ps:由于每个本地LB都收到了K8s的通告小皮鞭,所以每个K8s的节点,都开通了NodePort通道哦。即:无论哪个Slaver节点的Port都可以通往该App。4.4 小结K8s在实现容器网络的时候,造了很多概念:(1) LoadBalancer(2) Ingress(3) ClusterIP(4) NodePort本质都是一样的,就是LB+登记规范。 如果你看过《DNS篇》+《Docker网络实现》,这些就比较好理解。ps:具体本地LB怎么实现?真有兴趣可以去搜搜Kube-proxy的代码解读。我本身不是很关心,因为其实你给每个节点安装一个 Nginx 也可以做到的。5 总结K8s的网络概念,特别是Service,是K8s里面的精华,务必需要搞明白。(1) K8s南北流量,用Loadbalancer(4层)和Ingress(7层)搞定。(2) K8s的东西流量,用Service概念搞定。特别的,还给了个“行走江湖用的名号”,取名ClusterIP(一个不存在的假IP地址)。(3) 容器所在Host组网,存在Docker原生通道,K8s给重新包装了个名字:NodePort。所以只要报文到达Slaver节点,就能通到容器里面。另外,提一下一直没有说的东西(怕概念太多,影响理解):K8s的整个网络底座,是要求节点IP和容器IP是能互相连通的(即:在节点上面ping容器IP,是可以通的)。具体则是通过容器网络实现的。这个实现很多,Flannel,Calico等,本质要么隧道,要么子网(可以看看物理网络里面的《VLAN和Vxlan》篇,关于如何划分门派的篇章)。
-
在刚刚结束的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项目进展时间轴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-shVolcano简介:https://github.com/volcano-sh/volcanoVolcano设计:https://github.com/volcano-sh/volcano/tree/master/docs/designVolcano路线图:https://github.com/volcano-sh/volcano/blob/master/docs/community/roadmap.mdVolcano社区交流微信群:Volcano CN未来可期随着Volcano v1.0的发布,Volcano社区建设与上下游生态的融合必将更加紧密,基于Volcano的商业应用也将极大地促进AI、大数据、科学计算、渲染等领域充分享受到云计算带来的极大便利和极致体验,助力企业数字化转型进入新的高度。展望未来,华为云也将在云原生领域持续耕耘,持续引领创新、繁荣生态,助力各行业走向快速智能发展之路。
-
变量声明命名规范变量名由字母、$、下划线(_) 开头,紧跟着字母、数字、下划线(_)。要注意:变量名不能由数字开头,很多初学者包括我在内,会记乱了。举个合法命名的栗子let name = '余人杰'; let $id = 'hw91364016';重点:Javascript的关键字不可以用作变量名,如 if、while、class、true、false 等等。 栗子如下:let if = '余人杰';声明变量的方式可以使用var、let、const等方式进行定义。声明和赋值结合,如下:var name = '余人杰'; let id = 'hw91364016'; const PI = 3.141596;在不明确变量要赋什么值时,可以先声明变量,等执行一些逻辑后,知道具体值后再给其赋值。let name; ..... name = '余人杰';当功能复杂时,你可能需要多个变量进行存储值,你可以使用 , 同时声明多个变量。let name = '余人杰', id = 'hw91364016', age = 18;弱类型Javascript变量的特点是弱类型的,它可以保存任何类型的数据,说白了就是变量没有类型可言,但它的值有类型。变量可以更换不同类型的数据let name = '余人杰'; console.log(typeof name); // string name = 666; console.log(typeof name); // number name = null; console.log(typeof name); // object我们可以看出,Javascript的变量类型,是被所引用的值决定的。声明变量的基础知识就这些没了?当然不是,还有个很重要的,话说面试常出的变量扩展知识点-变量提升。变量提升怎么理解?pink老师划过重点说过,解析器会先解析代码,然后会将声明变量的 声明 的提升到 最前 ,这就是变量提升。使用 var, function (){} 定义的代码,声明会被提升到前面,赋值还在原位置。那记住这个有什么用呢?很大作用,有时可以拯救你的程序,你一不注意,就会因为这个常出错。比如:我们特意写个出错的程序来感受下:var name = '余人杰'; console.log(name); let else = 'if';我们在浏览器的控制台上测试下,发现报这个错 Uncaught SyntaxError: Unexpected token 'else'。细心的话,你会发现,console.log(name); 是在写在 let else = 'if'; 前面,按我们小白思维理解,应该是先打印'余人杰',但结果并非如此。 而是还没有到执行环节就报错了。如果你还不明白,我再写一个简单的代码给你理解,把解析器执行过程呈现出来给你细细品:console.log(name); var name = '余人杰'; console.log(name); // 解析器执行过程是这样的 var name; console.log(name); name = '余人杰'; console.log(name);TDZ课后,我还查阅了一些资料,还有一个由变量扩展的知识,术名叫TDZ,叫做暂时性死区。怎么理解?就是说变量虽然在作用域内存在了,但要使用时,必须在let 或者 const 声明后才可以。我们在平时编程时,多注意TDZ,养成先声明后使用的习惯,可以让程序更健壮。先声明变量,再使用多使用let/const,少使用var心得:变量声明虽然时Javascript基础中的基础,但稍不注意,就会导致整个程序出错。所以大家即使以后成了大牛,也要注意,多回顾基础,巩固根基,让路走的更远。转载链接:https://bbs.huaweicloud.com/blogs/192045
-
转载https://blog.csdn.net/weixin_38748858/article/details/103514909?utm_medium=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase云原生的解释可以说五花八门,本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。云原生起源网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念”。我搜索了英文“CloudNative”,阅读了首页的所有文章,里面没有一篇提到“Matt Stine首次提出云原生”,但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书,叫《迁移到云原生架构》,他以前确实在Pivotal公司工作,但说他“首次提出云原生(CloudNative)的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。我觉得比较接近的说法是Netflix公司首创了云原生,详见Going Cloud Native: 6 essential things you need to know。虽然那篇文章主要是讲的Netflix如何开创了微服务,但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步,各方面都不成熟,Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能,最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起,共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的,它的“Netflix OOS”系列工具至今仍被广泛使用,特别是Java社区,并被移植到其他语言。在这个过程中,也同时开创了云计算的先河,它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)。但我想说的是云计算(Cloud)和云原生(Cloud Native)还是有很大区别的。Netflix是云计算的开拓者,但并不是云原生的创造者。云原生的基石是k8s,没有k8s就没有云原生, 而k8s的1.0版诞生于2015年。云原生计算基金会(CNCF)也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行,因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。云原生计算基金会(CNCF)的定义:下面就让我们看一下CNCF给出的云原生的定义:“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。”摘要来源:CNCF Cloud Native Definition v1.0这个定义还是比较靠谱的,尽管它并不严谨,也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同,看问题的角度不同,CNCF的主要目的是培育云原生工具市场,因此它的定义带有很重的实用色彩,偏重工具方面。若是从这个角度看,这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去,其他的都没什么问题。让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石,也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器(Container)、服务网格(Service Mesh)、微服务(Microservice)、不可变基础设施(immutable infrastructure)和声明式API(declarative APIs)。其中容器(Container)是k8s的底层引擎,服务网格(Service Mesh)是建立在k8s上的针对请求的扩展功能,不可变基础设施(immutable infrastructure)是现代运维的基石,声明式API(declarative APIs)是k8s的编码方式,这些无一不是和k8s紧密相关的。但微服务(Microservice)就不同了,它其实跟云原生没什么关系,它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配,它们现在的演进轨道交织在一起密不可分。但实际上没有容器技术,微服务也可以部署在虚机上,只不过资源的利用率可能不够高。没有微服务,容器技术虽然不能大展宏图,但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼,但把微服务划归到云原生里实在是有点扩大外延,**圈地的意味。因为云原生的重点还是在基础设施,运维和运行环境以及软件的开发环境,而微服务是一个软件的架构,两者之间有明显的不同。云原生的表层含义那么到底什么是“云原生(Cloud Native)”呢?它分表层含义和深层含义。表层含义从字面上理解就比较容易了,我们管母语叫“Native Language”,也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时,大部分的程序都是从本地环境移植到云上的,它们在设计是就根本没考虑云环境的问题。云环境与本地环境的差异那么部署到云环境和部署到本地服务器有什么不同?这个才是问题的本质。你可能会说“是容器技术”,这个是现代云计算的不可或缺的支撑,但云计算开始的时候是基于虚拟化的,并没有容器技术,是在发展的过程中才有了容器技术。是“自动伸缩(auto-scaling)”吗?这是云环境的一个主要优点和特性,但它只是结果,不是本质。云技术的三大基石:基础设施即代码 (Infrastructure As Code)基础设施即代码是指把创建基础设施(包括服务器和网络环境)的命令像应用程序一样储存在源码库中,并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境,出了问题就在原来的基础之上进行修修补补,一旦需要把整个环境重新建立,很难保证与原来的一样。 当使用基础设施即代码之后,再也没有了这个担心。详情请见 InfrastructureAsCode不可变基础设施(immutable infrastructure)说道这里,我们不得不提“不可变基础设施(immutable infrastructure)“,它是基础设施即代码的升级版。有了基础设施即代码之后,随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备,并且还能预装应用程序,创建的时间还是秒级的。这时当服务器出现问题时,就没有必要去花时间查找原因了并修复了,而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的,只有创建和删除,而没有修改操作。这彻底改变了运维的方式。详情请见 What is “Immutable Infrastructure”?声明式API(declarative APIs)声明式API也是基础设施即代码的升级版。最开始时,当用软件定义基础设施时是用的过程式描述,也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态,而由系统来决定如何来创建这个环境。例如,你的描述就变成“创建一个有三个Nginx的集群”,而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时,系统能检测到差异,并自动修复,这样系统就有了自动容错的功能。上面讲了云计算环境和传统基础设施的不同,其实随着云计算的发展,传统基础设施也在不断地采纳云计算的先进技术和理念,例如虚拟化和容器技术,而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大,而通常本地私有云的版本是公有云的一个简化版。云原生应用程序的不同上面讲到了,只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢?它主要有两个部分:第一部分是服务调用。不论是微服务之间的调用,还是微服务调用数据库或前端调用后端,调用的方式都是一样的。都需要知道IP地址,端口和协议,例如“http://127.0.0.1:80”, 其中“http”是协议,“127.0.0.1”是IP地址,“80”是端口。由于程序是部署在k8s上的,k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器,并创建新的服务器,IP地址就变成了动态的,而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名,并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的,软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。第二部分是数据的持久存储。在程序运行时,经常要访问持久存储(硬盘)上的数据,例如日志,配置文件或临时共享数据。程序在容器中运行,一旦出现问题,容器会被摧毁,k8s会自动重新生成一个与原来一模一样的容器,并在上面重新部署应用程序。在集群环境下,用户感觉不到容器故障,因为系统已经自动修复了。但当容器被摧毁时,容器上的数据也一起被摧毁了,因此要保证程序运行的连续性,就要让持久存储不受容器故障的影响。如果你对它的具体设计感兴趣,请参见把应用程序迁移到k8s需要修改什么?云原生的深层含义不过云原生还有一层引申含义。当你的最终生产环境是云环境时,你的本地开发环境最好也是云环境,这虽然不是必须的,但它能保证本地环境和生产环境的一致性,减少部署时的意外,是一个很自然的选择。而要在本地使用云环境来进行开发,你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具,请继续阅读下一篇“ 云原生开发环境初探"。索引:Going Cloud Native: 6 essential things you need to knowGoto Berlin - Migrating to Microservices (Fast Delivery)CNCF Cloud Native Definition v1.0InfrastructureAsCodeWhat is “Immutable Infrastructure”?把应用程序迁移到k8s需要修改什么?云原生开发环境初探不堆砌术语,不罗列架构,不迷信权威,不盲从流行,坚持独立思考W--wangzhiqiang 发表于2020-07-30 15:10:38 2020-07-30 15:10:38 最后回复 W--wangzhiqiang 2020-07-30 15:10:381638 0
-
转载https://blog.csdn.net/weixin_38748858/article/details/103514909?utm_medium=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task--2~all~first_rank_v2~rank_v25-1.nonecase云原生的解释可以说五花八门,本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。云原生起源网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念”。我搜索了英文“CloudNative”,阅读了首页的所有文章,里面没有一篇提到“Matt Stine首次提出云原生”,但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书,叫《迁移到云原生架构》,他以前确实在Pivotal公司工作,但说他“首次提出云原生(CloudNative)的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。我觉得比较接近的说法是Netflix公司首创了云原生,详见Going Cloud Native: 6 essential things you need to know。虽然那篇文章主要是讲的Netflix如何开创了微服务,但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步,各方面都不成熟,Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能,最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起,共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的,它的“Netflix OOS”系列工具至今仍被广泛使用,特别是Java社区,并被移植到其他语言。在这个过程中,也同时开创了云计算的先河,它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)。但我想说的是云计算(Cloud)和云原生(Cloud Native)还是有很大区别的。Netflix是云计算的开拓者,但并不是云原生的创造者。云原生的基石是k8s,没有k8s就没有云原生, 而k8s的1.0版诞生于2015年。云原生计算基金会(CNCF)也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行,因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。云原生计算基金会(CNCF)的定义:下面就让我们看一下CNCF给出的云原生的定义:“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。”摘要来源:CNCF Cloud Native Definition v1.0这个定义还是比较靠谱的,尽管它并不严谨,也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同,看问题的角度不同,CNCF的主要目的是培育云原生工具市场,因此它的定义带有很重的实用色彩,偏重工具方面。若是从这个角度看,这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去,其他的都没什么问题。让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石,也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器(Container)、服务网格(Service Mesh)、微服务(Microservice)、不可变基础设施(immutable infrastructure)和声明式API(declarative APIs)。其中容器(Container)是k8s的底层引擎,服务网格(Service Mesh)是建立在k8s上的针对请求的扩展功能,不可变基础设施(immutable infrastructure)是现代运维的基石,声明式API(declarative APIs)是k8s的编码方式,这些无一不是和k8s紧密相关的。但微服务(Microservice)就不同了,它其实跟云原生没什么关系,它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配,它们现在的演进轨道交织在一起密不可分。但实际上没有容器技术,微服务也可以部署在虚机上,只不过资源的利用率可能不够高。没有微服务,容器技术虽然不能大展宏图,但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼,但把微服务划归到云原生里实在是有点扩大外延,**圈地的意味。因为云原生的重点还是在基础设施,运维和运行环境以及软件的开发环境,而微服务是一个软件的架构,两者之间有明显的不同。云原生的表层含义那么到底什么是“云原生(Cloud Native)”呢?它分表层含义和深层含义。表层含义从字面上理解就比较容易了,我们管母语叫“Native Language”,也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时,大部分的程序都是从本地环境移植到云上的,它们在设计是就根本没考虑云环境的问题。云环境与本地环境的差异那么部署到云环境和部署到本地服务器有什么不同?这个才是问题的本质。你可能会说“是容器技术”,这个是现代云计算的不可或缺的支撑,但云计算开始的时候是基于虚拟化的,并没有容器技术,是在发展的过程中才有了容器技术。是“自动伸缩(auto-scaling)”吗?这是云环境的一个主要优点和特性,但它只是结果,不是本质。云技术的三大基石:基础设施即代码 (Infrastructure As Code)基础设施即代码是指把创建基础设施(包括服务器和网络环境)的命令像应用程序一样储存在源码库中,并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境,出了问题就在原来的基础之上进行修修补补,一旦需要把整个环境重新建立,很难保证与原来的一样。 当使用基础设施即代码之后,再也没有了这个担心。详情请见 InfrastructureAsCode不可变基础设施(immutable infrastructure)说道这里,我们不得不提“不可变基础设施(immutable infrastructure)“,它是基础设施即代码的升级版。有了基础设施即代码之后,随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备,并且还能预装应用程序,创建的时间还是秒级的。这时当服务器出现问题时,就没有必要去花时间查找原因了并修复了,而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的,只有创建和删除,而没有修改操作。这彻底改变了运维的方式。详情请见 What is “Immutable Infrastructure”?声明式API(declarative APIs)声明式API也是基础设施即代码的升级版。最开始时,当用软件定义基础设施时是用的过程式描述,也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态,而由系统来决定如何来创建这个环境。例如,你的描述就变成“创建一个有三个Nginx的集群”,而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时,系统能检测到差异,并自动修复,这样系统就有了自动容错的功能。上面讲了云计算环境和传统基础设施的不同,其实随着云计算的发展,传统基础设施也在不断地采纳云计算的先进技术和理念,例如虚拟化和容器技术,而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大,而通常本地私有云的版本是公有云的一个简化版。云原生应用程序的不同上面讲到了,只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢?它主要有两个部分:第一部分是服务调用。不论是微服务之间的调用,还是微服务调用数据库或前端调用后端,调用的方式都是一样的。都需要知道IP地址,端口和协议,例如“http://127.0.0.1:80”, 其中“http”是协议,“127.0.0.1”是IP地址,“80”是端口。由于程序是部署在k8s上的,k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器,并创建新的服务器,IP地址就变成了动态的,而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名,并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的,软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。第二部分是数据的持久存储。在程序运行时,经常要访问持久存储(硬盘)上的数据,例如日志,配置文件或临时共享数据。程序在容器中运行,一旦出现问题,容器会被摧毁,k8s会自动重新生成一个与原来一模一样的容器,并在上面重新部署应用程序。在集群环境下,用户感觉不到容器故障,因为系统已经自动修复了。但当容器被摧毁时,容器上的数据也一起被摧毁了,因此要保证程序运行的连续性,就要让持久存储不受容器故障的影响。如果你对它的具体设计感兴趣,请参见把应用程序迁移到k8s需要修改什么?云原生的深层含义不过云原生还有一层引申含义。当你的最终生产环境是云环境时,你的本地开发环境最好也是云环境,这虽然不是必须的,但它能保证本地环境和生产环境的一致性,减少部署时的意外,是一个很自然的选择。而要在本地使用云环境来进行开发,你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具,请继续阅读下一篇“ 云原生开发环境初探"。索引:Going Cloud Native: 6 essential things you need to knowGoto Berlin - Migrating to Microservices (Fast Delivery)CNCF Cloud Native Definition v1.0InfrastructureAsCodeWhat is “Immutable Infrastructure”?把应用程序迁移到k8s需要修改什么?云原生开发环境初探不堆砌术语,不罗列架构,不迷信权威,不盲从流行,坚持独立思考W--wangzhiqiang 发表于2020-07-30 15:07:04 2020-07-30 15:07:04 最后回复 W--wangzhiqiang 2020-07-30 15:07:041435 0
-
摘要:KubeEdge 是首个基于 Kubernetes 扩展的,提供云边协同能力的开放式智能边缘计算平台,也是 CNCF 在智能边缘领域的首个正式项目。依托 Kubernetes 强大的容器编排和调度能力,实现云边协同、计算下沉、海量设备接入等。边缘计算场景与挑战边缘计算是一种分布式计算概念,拥有去中心化处理能力的分散型开放 IT 架构,数据由设备本身或本地计算机或服务器处理,无需传输到数据中心,也可在更靠近终端的网络边缘上提供服务。但边缘计算无法单独存在,它必定要和远程数据中心 / 云打通,以 IoT(Internet of Things,物联网)场景为例,边缘设备除了拥有传感器收集周边环境的数据外,还会从云端接收控制指令,因此边缘计算与云计算二者是相依而生、协同运作的。据2020边缘计算状态报告显示,到2022年,75%的数据将通过边缘分析和处理。这种数据处理的流动性,将伴随有4大边缘技术演进方向:人工智能的实用性增强,从云端渗透到边缘物联网设备的数量呈指数级增长5G时代的快速到来边缘计算中心逐步克服分布式设施复杂性和单位成本经济性的问题结合边缘计算的场景与技术演进方向,可以总结出当前边缘计算领域面临的几个挑战:云边协同:逐步从云端渗透到边缘的AI/安全等业务,在云和边的智能协同、弹性迁移;网络:边缘网络的可靠性和带宽限制;设备管理:呈指数级增长的物联网设备,边缘节点与边缘设备的管理;扩展:高度分布和大规模的可扩展性;异构:边缘异构硬件和通信协议。Kubernetes构建边缘计算平台的优势与挑战Kubernetes 已经成为云原生的事实标准,并且能够在任何基础设施上提供一致的云上体验。我们经常能够看到“容器 + Kubernetes”的组合在 DevOps 发挥 10X 效率。基于Kubernetes的技术架构与生态优势,近几年也有越来越多的将Kubernetes 运行在数据中心外(边缘)的需求。基于Kubernetes构建的边缘计算平台,将会具备众多天然的优势:(1)容器化应用封装:容器的轻量化和可移植性非常适合边缘计算的场景,边缘容器应用Build一次,可以运行在任何边缘节点上。(2)通用的应用抽象定义:Kubernetes的应用定义已成为云原生业界的事实标准,被广泛接受。通过原生的Kubernetes应用API,用户可以将云上与边缘的应用统一管理。例如用户可以使用熟悉的 kubectl 或者 helm chart管理云上与边缘的应用。(3)平台易扩展性:Kubernetes 已经被证明具备良好的可扩展性,基于CRD可以自定义API,如边缘设备管理;基于CRI、CNI、CSI等插件可以扩展各种边缘自定义插件。(4)强大的技术生态圈:围绕 Kubernetes 已经形成了一个强大的云原生技术生态圈,诸如:监控、日志、CI、存储、网络都能找到现成的工具链。然而 Kubernetes 毕竟原生是为云数据中心设计的,要将Kubernetes 的能力扩展到边缘,必须解决以下问题:(1)边缘设备资源有限:很多设备边缘的资源规格有限,特别是 CPU 处理能力较弱,内存资源较少,因此无法部署完整的 Kubernetes。(2)边缘网络的不稳定性:Kubernetes依赖数据中心稳定的网络,边缘场景下网络通常又是不稳定的。(3)边缘节点离线自治:Kubernetes依赖 list/watch 机制,不支持离线运行,而边缘节点的离线又是常态,例如:设备离线重启。(4)海量边缘设备管理:如何使用Kubernetes管理指数级增长的海量边缘设备以及产生的数据。另外,关于如何在边缘使用 Kubernetes,Kubernetes IoT/Edge WG 组织的一个调查显示,30% 的用户希望在边缘部署完整的 Kubernetes 集群,而 70% 的用户希望在云端部署 Kubernetes 的管理面并且在边缘节点上只部署 Kubernetes 的 agent。边缘容器开源现状Kubernetes社区很早就已经关注到边缘计算场景,早在2018年社区就已经成立专门的Edge工作组来研讨边缘相关场景。而2018年底,华为在业界首次开源Kubernetes边缘项目KubeEdge,将华为云智能边缘平台产品IEF(Intelligent EdgeFabric)核心代码开源,并于19年初捐献给CNCF基金会,成为CNCF迄今为止唯一边缘计算官方项目。随后,Rancher、阿里云也陆续跟进,开源了K3s、OpenYurt等项目,边缘容器这个领域真正进入到快速发展期。下面,我们对这三个代表性的K8s@Edge的项目进行一些简要分析。KubeEdge架构分析KubeEdge 是华为云于2018年11月开源,2019年3月捐献给 CNCF 的开源项目。KubeEdge 是首个基于 Kubernetes 扩展的,提供云边协同能力的开放式智能边缘计算平台,也是 CNCF 在智能边缘领域的首个正式项目。KubeEdge 的名字来源于 Kube + Edge,顾名思义就是依托 Kubernetes 强大的容器编排和调度能力,实现云边协同、计算下沉、海量设备接入等。KubeEdge架构上分为云、边、端三个层次。云端中心管控边缘节点与设备,边缘节点实现边缘自治,云上管控边缘节点的架构也符合Kubernetes IoT/Edge WG 调查结果中大多数用户的诉求。KubeEdge完整的打通了边缘计算中云、边、设备协同的场景,整体架构如下图。针对边缘特定的场景,KubeEdge 重点解决的问题是:云边协同:KubeEdge 通过 Kubernetes 标准 API 在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下发,提升边缘的运维效率;在边缘AI场景下,云端训练好的模型可以直接下发到边缘节点,进行推理等,实现边缘AI的云边一体化。边缘自治:KubeEdge 通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储,这样节点在离线情况下即使重启也不会丢失管理元数据,并保持对本节点设备和应用的管理能力。极致轻量:KubeEdge 则是保留了 Kubernetes 管理面,对Kubernetes的节点端组件进行重组,达到极致轻量的目的,节点组件可以运行在内存256M的边缘节点上。海量边缘设备管理:KubeEdge了可插拔式的设备统一管理框架,在云端基于Kubernetes的CRD能力,自定义了设备管理的API,完全符合Kubernetes的原生标准,用户可以在云端通过API来管理海量边缘设备;在边缘可根据不同的协议或实际需求开发设备接入驱动,当前已经支持和计划支持的协议有:MQTT,BlueTooth,OPC UA,Modbus 等,随着越来越多社区合作伙伴的加入,KubeEdge 未来会支持更多的设备通信协议。K3s架构分析K3s 是 Rancher于2019年2月开源的一个自己裁剪的 Kubernetes 发行版,K3S 名字来源于 K8s – 5,这里的“5”指的是 K3S 比 Kubernetes 更轻量使得它能更好地适配 CI,ARM,边缘技术,物联网和测试这 5 个场景。K3S 是 CNCF 官方认证的 Kubernetes 发行版,开源时间较 KubeEdge 稍晚。K3S 专为在资源有限的环境中运行 Kubernetes 的研发和运维人员设计,目的是为了在 x86、ARM64 和 ARMv7D 架构的边缘节点上运行小型的 Kubernetes 集群。K3S 的整体架构如下所示:K3S 就是基于一个特定版本 Kubernetes(例如:1.17)直接做了代码修改。K3S 分 Server 和 Agent,Server 就是 Kubernetes 管理面组件 + SQLite 和 Tunnel Proxy,Agent 即 Kubernetes 的数据面 + Tunnel Proxy。为了减少运行 Kubernetes 所需的资源,K3S 对原生 Kubernetes 代码做了以下几个方面的修改:删除旧的、非必须的代码。K3S 不包括任何非默认的、Alpha 或者过时的 Kubernetes 功能。除此之外,K3S 还删除了所有非默认的 Admission Controller,in-tree 的 cloud provider 和存储插件;整合打包进程。为了节省内存,K3S 将原本以多进程方式运行的 Kubernetes 管理面和数据面的多个进程分别合并成一个来运行;使用 Containderd 替换 Docker,显著减少运行时占用空间;引入 SQLite 代替 etcd 作为管理面数据存储,并用 SQLite 实现了 list/watch 接口;将所有Kubernetes原生进程打包在同一个进程中。K3s项目本质上是一个K8s的“轻量化”版本,而不是一个真正意义上的“边缘”版本。从架构上看,K3s 的所有组件(包括 Server 和 Agent)都运行在边缘侧,这意味着 K3S 并不是一个去中心化的部署模型,每个边缘都需要额外部署 Kubernetes 管理面,因此不涉及云边协同。也缺乏针对边缘网络不稳定性的边缘自治能力,也不涉及边缘设备的管理。此外,如果 K3s 要落到生产,在 K3s 之上应该还有一个云上的统一集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等,遗憾的是 Rancher 尚未开源这部分能力。OpenYurt架构分析OpenYurt是阿里云于2020年5月开源的云原生边缘计算项目,跟KubeEdge架构基本相似,OpenYurt也是依托原生Kubernetes的容器编排及调度能力,提供云边协同能力的边缘计算平台。OpenYurt 也是依托 Kubernetes 强大的容器应用编排能力,实现云-边一体化的应用分发、管控的诉求,也是从云端集中管控边缘节点,OpenYurt 的整体架构如下所示:项目目前还未发布0.1版本,从已开源部分可以看出,OpenYurt架构与KubeEdge类似,也是打通了云边协同的场景。提供的能力也与KubeEdge类似,包括边缘自治、云边协同、单元化管理能力(未开源)等。OpenYurt并未对Kubernetes进行改造,而是通过Addon(插件化)的形式提供边缘计算所需要的管控能力,边缘端的YurtHub,作为节点上的临时配置中心,在网络连接中断的情况下,持续为节点上所有设备和客户业务提供数据配置服务。这种简化的架构,重点在于解决“离线自治”问题,且比较有利于保留现有K8s的完整功能,但由于未对Kubelet进行修改,因此OpenYurt无法运行在资源有限的边缘设备中;物联网场景中的对于边缘设备的管理,OpenYurt也不涉及;并且一些边缘场景下涉及到Kubelet原生不支持的高级特性比如离线自愈、自调度等无法实现。边缘容器总结与展望对比三个开源项目, K3s 最让人印象深刻的特点在于其对 Kubernetes 进行了轻量化、部署便捷化做的尝试,通过剪裁了 Kubernetes 一些不常用功能并且合并多个组件到一个进程运行的方式,使得一些资源较充足的边缘节点上能够很方便的获得与Kubernetes一致的体验。但是从测试数据看K3s 的资源消耗还是很高,而且动辄几百 MB 的内存也不是大多数设备边缘节点所能提供的,而且目前只适合运行在边缘,不具备云边协同、边缘自治等边缘计算领域的核心诉求。OpenYurt通过非侵入的插件化形式在原生Kubernetes的基础上提供边缘计算能力,虽然提供了云边协同、边缘自治等能力,但是未做轻量化改造,只能运行在资源充足的边缘节点,无法运行在大量资源有限的边缘节点上,并且也未提供边缘计算中海量边缘设备管理的能力。KubeEdge是一个从云到边缘再到设备的完整边缘云平台,100% 兼容Kubernetes的原生API,基于Kubernetes解决了边缘计算领域的核心诉求,包括云边协同、边缘网络不稳定、边缘自治、边缘轻量化、海量边缘设备管理以及异构扩展等问题。未来边缘容器技术仍将聚焦于解决边缘计算领域所面临的云边协同、网络、设备管理、扩展及异构等挑战,KubeEdge 已经是 CNCF正式项目,未来将持续与社区合作伙伴一起制定云和边缘计算协同的标准,解决边缘计算领域的难题,结束边缘计算没有统一标准和参考架构的混沌状态,共同推动边缘计算的产业发展。转载自:华为云开发者论坛
-
【转载华为云社区】当今K8s独霸天下之时,咱们站在更高的角度,好好的看看K8s的网络是以什么理念构筑的。以及一个容器集群的好保姆,是如何分别照顾 南北流量和东西流量的。1 简单介绍下Kubernetes略。。容器集群管理的事实标准了,不知道要打屁股。(ps:本章节可参考唐老师的《K8S前世今生》文章)2 世界上的集群都一个样有点标题党哈,不过我接触过的各种集群也不少,各种各样:Ø OpenStack:在一大堆物理机上面,管理(启动/停止)VM的。Ø SGE,Slurm,PBS:在一大堆电脑集群里面,管理(启动/停止)App的。Ø Yarn:在一大堆电脑集群里面,管理(启动/停止)大数据App的。Ø CloudFoundry:在一大堆电脑集群里面,管理(启动/停止)容器的Ø Kubernetes:在一大堆电脑集群里面,管理(启动/停止)容器的。它们都有一些共同特点:2.1 跨节点跑xx程序这个xx程序一定是首先单机可以运行的。比如OpenStack:单机上面可以用qemu启动VM,想跨节点管理VM,就引入了OpenStack。Kubernetes也一样:单机上面可以跑Docker容器;想跨节点管理容器,就得引入集群管理老大的概念。2.2 有一个管事的老大A)集群管理的老大,负责让手下的某个小弟干活。别管是命令式(直接下命令)的,还是申明式(发告示)的,小弟收到命令后,乖乖干活就是了。B) 同时,这个集群管理的老大,需要有脑子,不然小弟数量多了管不好。所以它需要拿笔记一记。比如OpenStack的老大得带个Mysql数据库;Kubernetes把笔记记在了ETCD里面(不过ETCD这个本子太小,记得东西不能太大,这是另话)。C) 不管哪种老大,都得有个军师。一个新活来到老大这里,那么多小弟,指派给谁不是干呀。这活实际分配给哪个小弟,这得军师说了算,所以每中集群软件都自己写了一套 Scheduler 算法,可谓程序员间浪费重复轮子之典型代表。2.3 小弟上面都有一个Agent这个小弟上面的Agent,时刻向老大汇报自己的状态:活不活着,忙还是闲,方便老大派活。同时,Agent也就是那台电脑里面的地头蛇了,帮忙老大负责各种临时事物。只是大家的取名不一样:OpenStack:取名NovaKubernetes:取名KubeletYarn:取名NodeManager2.4 老大怎么给小弟发号施令一般老大都是通过:消息队列来,给小弟发号施令的,而不是亲自上门(直连)下达命令。原因么,当然是小弟可能临时出门(故障)了呗~ 直接上门可能不通,放消息队列里面就可靠多了。等小弟出差回来,还能看到老大下达的任务令。Ø OpenStack:用 RabbitMQ 发号施令Ø Kubernetes:用 ETCD 发号施令Ø CloudFoundry:用 NATS 发号施令上面这些组件都是带消息通知的功能,区别有些有名,有些没那么出名罢了。比如我们的K8s:特别需要提一下:K8s这个老大不简单,找了个ETCD这个好帮手。这小家伙挺神,既能当笔记本记点事情(代替OpenStack中的Mysql),又能当公告牌,通知点消息(代替OpenStack中的Rabbit)。所以K8s这个容器集群管理相对OpenStack这个虚机管理不需要数据库,666~3 K8s怎么设计容器网络的呢3.1 南北流量要看到K8s诞生的时候,那时是有CloudFoundry和Docker的,且都已经比较成熟。那时作为PaaS一哥的CF对容器网络的抽象:主要考虑平台外部,怎么访问容器里面的App。而平台内部的App之间如何互相访问,几乎没有太多的设计。由上图所示,可以看到,平台外部访问,一般都是上下画的,所以也叫做南北流量。我们这么叫,也是便于程序员之间沟通和理解。Ps:PaaS的基本原型大致都这样:3.2 东西流量K8s吸取了前辈们的精华,除了平台外部访问App,还新增考虑了平台内部,App之间如何互相访问。即K8s通过增加一个负载均衡的“LB”设备,来搞定平台内部的App间互相访问。给每个App取个别名,在LB上面登记一下,就可以被内部其他App访问。由上图所示,可以看到,平台内部访问,一般都是水平画的,所以也叫做东西流量。一个完整的PaaS平台,就是需要南北流量+东西流量,全套治理的。3.3 Docker原生访问方式还记得唐老师的《Docker网络实现》章节吧,Docker容器可以通过“节点IP+节点Port”的方式访问到容器。原理的容器所在节点,设置了NAT规则。报文一到达节点,根据目的端口,转发进入容器。3.4 小结:K8s中3种访问容器的通道(1) 通过南北流量(从集群外部访问App)访问App容器(2) 通过东西流量(集群内App之间)访问App容器(3) 通过Docker原生自带的方式,访问App容器下一章节,我们简单介绍下每种方式,K8s分别怎么去实现的。4 K8s怎么实现容器访问虽然K8s上面,有多种访问App容器的方法。但是不管用什么方式访问,一个App想要能被访问,就得得到K8s的同意。K8s把这个许可证叫做“Service”:也就是不管什么南北流量、东西流量,你的App想要能被访问,就得先申请Service许可证。4.1 南北流量要实现一个App的访问通道,一定要2个东西:(1)LB负载均衡器 + (2)注册映射关系。映射关系就是:报文来了,应该转发给哪个App实例? 即:找到 “哪个App + 哪个实例”。负载均衡器呢,一般大家爱用Nginx,不过也有其他类型的实现。K8s比CF聪明的地方是,没有自己去实现LB。而只定义了App需要怎么样才能登记到LB上面。即只定规范,不限制实现(这种思路,在k8s里面好多,比如存储的CSI,运行时的CRI的,容器网络的CNI 都是这样。)Ø 4层LB最简单的4层LB实现,K8s取了个名字:LoadBalancer(1)。即定义:xx协议+xx端口 =》xx应用,具体规则自己去看资料。Ø 7层LB为了定义7层LB的规则,K8s给规范取了名字:Ingress(2)。即定义:xx网址+xx-URL路径 =》xx应用,具体规则也自己看K8s资料。南北LB都是全局级的,即:全局一个(HA多实例,咱也当一个整体)就行;不需要每个Slaver节点上一个。4.2 东西流量东西流量,也一样,需要LB+规则注入。这里,K8s设计就比较有意思。逻辑上,如上图所示。在LB部分的实现上,K8s很巧妙的要求每个节点上面都一个“小LB”。所以实现上,大致如上图所示。Ø 本地LB本地LB,要求每个节点都有。所以最开始的版本,K8s使用了Linux使用广泛的iptables来实现。后面由于iptables性能不是特别给力,又有了 IPVS 实现。然后其他各式各样的民间实现也有。Ø 本地控制器LB需要一个控制器,每个本地“小LB”带配备一个小控制器,一样的,也是每个节点一个。和小LB一一对应。K8s给它取了个名字:Kube-proxyØ 假IP地址每个K8s上的App,都可以申请“行走江湖的名号”,用来代表自己。K8s就会给你的App分配一个Service许可证,许可证上面带着“影子IP”,任何集群内部只要访问这个IP,就等于访问你的App。实现上:1. 先到K8s那登记,说我想要个“名号”2. 通过后,K8s会告知每个节点上的本地LB3. 从此以后,每个LB都认识这个“影子IP”了,访问它,就代表访问对应App。由于这个“名号”是集群颁布的,所以仅在集群内有效。K8s取名:ClusterIP(3)。关于东西流量的故事,还可以去看看唐老师之前的《网络骗子》篇。4.3 Docker原生访问方式除了上面几种访问方式,K8s也为原生的Docker访问通道留了个名字:NodePort(4)。这种方式,在《Docker网络实现》里面说过,靠主机Host转发实现。既然是主机搞定,所以这条路和本地LB实现,就合并一起搞定了。如上图,K8s下发规则的时候,顺便把这条路的规则也下发下去。ps:由于每个本地LB都收到了K8s的通告小皮鞭,所以每个K8s的节点,都开通了NodePort通道哦。即:无论哪个Slaver节点的Port都可以通往该App。4.4 小结K8s在实现容器网络的时候,造了很多概念:(1) LoadBalancer(2) Ingress(3) ClusterIP(4) NodePort本质都是一样的,就是LB+登记规范。 如果你看过《DNS篇》+《Docker网络实现》,这些就比较好理解。ps:具体本地LB怎么实现?真有兴趣可以去搜搜Kube-proxy的代码解读。我本身不是很关心,因为其实你给每个节点安装一个 Nginx 也可以做到的。5 总结K8s的网络概念,特别是Service,是K8s里面的精华,务必需要搞明白。(1) K8s南北流量,用Loadbalancer(4层)和Ingress(7层)搞定。(2) K8s的东西流量,用Service概念搞定。特别的,还给了个“行走江湖用的名号”,取名ClusterIP(一个不存在的假IP地址)。(3) 容器所在Host组网,存在Docker原生通道,K8s给重新包装了个名字:NodePort。所以只要报文到达Slaver节点,就能通到容器里面。另外,提一下一直没有说的东西(怕概念太多,影响理解):K8s的整个网络底座,是要求节点IP和容器IP是能互相连通的(即:在节点上面ping容器IP,是可以通的)。具体则是通过容器网络实现的。这个实现很多,Flannel,Calico等,本质要么隧道,要么子网(可以看看物理网络里面的《VLAN和Vxlan》篇,关于如何划分门派的篇章)。
-
【转载华为云社区】华为鲲鹏服务器安装docker-compose前一久天参加了华为举办的云南省大学生自主创新大赛·鲲鹏赛道要求充分理解和认知鲲鹏云服务,且将云服务应用到参赛作品中且解决具体的系统问题华为鲲鹏服务器华为鲲鹏服务器采用华为自研cpu ARMv8架构,提供 Windows 和多个Linux 系统,作为服务器使用我一直使用Centos系统本次使用 CentOS 7.6 64bit with ARMdocker 作为官方的编排工具,是非常重要的,它可以让用户通过编写一个简单的模板文件,快速地创建和管理基于docker容器的应用集群。Compose 定位是“定义和运行多个docker容器的应用”。Compose中有两个重要的概念:项目(project):由一组关联的应用容器组成的一个完整业务单元,在docker-compose.yml文件中定义。服务(service):一个应用的容器,实际上可以包括若干运行相同镜像的容器实例。Compose 的默认管理对象是项目,通过子命令对项目中的一组容器进行便捷地生命周期管理。实验了好多次发现:不要用python2来安装docker-compose,得下载python3还有一点,在开始前找到对应的ARM架构的yum源换一个(我已经找到标记好了),因为自带的源安装会有问题得通过备份换源解决1234567891011121314151617181920212223242526272829#!/bin/bash# 更新yummv /etc/yum .repos.d /CentOS-Base .repo /etc/yum .repos.d /CentOS-Base .repo.backupwget http: //mirrors .aliyun.com /repo/Centos-altarch-7 .repo -O /etc/yum .repos.d /CentOS-Base .repoyum makecache# 安装dockercurl -fsSL https: //get .daocloud.io /docker | bash -s docker --mirror Aliyun # 配置dockermkdir -p /etc/docker tee /etc/docker/daemon .json <<- 'EOF'{ "registry-mirrors" : [ "http://*********" ], "log-driver" : "json-file" , "log-opts" : { "max-size" : "50m" , "max-file" : "3" }}EOF systemctl daemon-reloadsystemctl restart docker # docker-composeyum install -y libffi libffi-devel openssl-devel python3 python3-pip python3-devel pip3 install -i https: //pypi .tuna.tsinghua.edu.cn /simple docker-compose查看安装是否成功:1docker-compose - vDocker Compose 常用命令build:构建或者重新构建项目中的服务容器1$ docker-compose build [options] [service...]start: 启动已经存在的服务容器1$ docker-compose start [service...]stop: 停止已经处于运行状态的容器,但不删除它。通过docker-compose start 可以再次启动这些容器。1$ docker-compose stop [options] [service...]up: 它将尝试自动完成包括构建镜像,(重新)创建服务,启动服务,并关联服务相关容器的一系列操作。链接的服务都将会被自动启动,除非已经处于运行状态。1234567$ docker-compose up [options] [service...] options: -d 在后台运行服务容器 --no-deps 不启动服务所链接的容器 --force-recreate 强制重新创建容器,不能与 --no-recreate同时使用 --no-recreate 如果容器已经存在了,则不重新构建,不能与--force-recreate同时使用rm: 删除所有(停止状态的)服务容器。推荐先执行docker-compose stop 命令来停止容器。12345$ docker-compose rm [options] [service...] options: -f,--force 强制直接删除,包括非停止状态的容器。一般尽量不要使用该选项。 - v 删除容器所挂载的数据卷。kill:通过发送 SIGKILL 信号来停止指定服务的容器docker-compose kill eureka1$ docker-compose kill eurekascale:设置指定服务运行容器的个数,以 service=num 形式指定1$ docker-compose scale web=5 db=3将启动5个容器运行web服务,3个容器运行db服务。一般情况下,当指定数目多于该服务当前实际运行容器,将新创建并启动容器;反之,将停止容器。
-
【转载华为云】产品信息请点击:https://www.huaweicloud.com/product/cce.html体验云原生之旅:https://activity.huaweicloud.com/cloudnative.html?ggw_hd1.导言当今全球正处于一个数字化颠覆的时代,对于企业而言,积极拥抱数字化转型能够带来业务和管理上的双重提升。华为云容器CCE敏捷版,为企业提供数字化新基建的云原生技术平台,帮助您实现业务敏捷上线、业务战略快速落地。1、企业对数字化转型的需求搭建企业的数据底座:全量数据进湖,实时计算,实时分析,发挥数据的“魔力”提升业务快速上线能力:借助ServiceMesh服务网格强大商用能力,实现业务快速上线高效可靠的运维能力:提供可靠的容器镜像构建和部署,可以快速上线、扩缩容、回滚构建企业微服务架构:基于Istio的非侵入微服务治理能力,进行微服务改造2、云容器技术对企业的价值降低基础设施成本:资源的细粒度管理,可以大幅提升资源利用率,减少基础设施成本缩短应用上线周期:统一应用打包标准,快速在研发/测试/生产环境间分发、部署、上线快速构建跨云业务:标准的运行环境和API,在不同的容器平台上能无缝迁移、统一管理提升应用运维效率:完善的应用生命周期管理能力和自动扩缩容机制,提升运维效率30%+2.华为云容器CCE敏捷版介绍华为云容器CCE敏捷版(简称:CCE敏捷版),是基础设施解耦的企业级、轻量化、智能化的云原生平台,面向混合云形态下,企业业务云原生化转型升级场景,提供云原生业务基础,帮助企业快速转型升级。*部署方式:适用于客户本地机房、公有云、混合云、多云等环境CCE敏捷版的优势:组织匹配、精细控制的租户权限模型完善的租户权限模型(组织-用户),匹配企业研发组织模型、跨集群实现资源、业务的灵活隔离基于角色访问权限控制(RBAC),精细的控制每个租户的资源权限;支持跨云多集群的多租户级别的RBAC管控支持对接多种用户系统(LDAP、SAML、OpenID、华为云IAM等),免除多套租户系统的维护负担支持资源使用计量计费,适合企业内部结算场景云原生、高性能、安全的容器网络方案高性能自研插件:多种UnderLay模式网络,容器网络性能接近主机网络与主流厂商的ELB对接,动态为容器提供对外访问能力(华为云、阿里云、F5、Nginx等)网络QOS:精细化实现流量控制,避免网络堵塞精细化的网络策略:灵活实现组织、项目、Pod三级网络隔离支持容器网络固定IP、源地址保留全面兼容社区生态及华为云商业软件Everest容器存储管理,支持多云存储网关丰富的存储方案:全面支持云容器存储标准,原生支持业界主流存储方案及华为商业存储方案支持AI容器:kubeflow、gpu、Atlas服务器/昇腾芯片支持大数据容器:spark、flink支持基因容器:KubeGene/GCS支持Volcano批量计算引擎面向各类业务场景,兼容各类基础设施兼容物理机与虚拟机:支持直接部署在物理机或业界主流IaaS虚拟化之上与主流云厂商的计算能力对接,动态增删节点,自动弹性伸缩集群(华为云、阿里云、openstack、vsphere等)多异构计算支持:GPU、鲲鹏服务器、昇腾芯片,支持全栈国产化兼容多种操作系统:支持业界主流的操作系统,如CentOS,RedHat,Ubuntu等支持多集群的创建和管理; 支持5000节点规模集群; 支持非高可用集群(单master节点)支持混合云场景:支持线上线下集群统一管控;支持跨云故障检测,应用迁移生态丰富、精细化的运维能力,专业的运维保障全面兼容Prometheus生态:云原生标准监控采集和日志采集接口,支持自定义扩展,全面涵盖集群、容器、应用各层次的监控、日志、告警、调用链等。监控告警信息持久化运维管理RBAC:支持租户的运**限管理,根据角色精细化控制用户的运维管理权限专业运维支持:提供7*24小时运维支持,技术专家现场咨询、培训、维护,为用户提供专业的运维保障。原生服务网格Istio,实现非侵入式云原生应用发布和治理精细化应用发布:金丝雀、蓝/绿发布,提高版本迭代速度,降低业务风险服务级流量治理:一键使能Istio服务网格,非侵入式流量治理策略配置,轻松管理运行态应用智能化、自动化:全面应用流量健康诊断,智能化提供精准治理策略,轻松高效构建应用SLA能力多云/混合云网络流量管理:灵活应对业务流量突发,业务可靠和容灾等问题容器化DevOps解决方案开箱即用,内置标准化流程模板简化使用支持alpha-beta-gamma多环境端到端敏捷交付开放式架构,易于与企业已有系统集成镜像P2P加速,解决各类行业场景问题,支持1W节点分钟级镜像分发3.华为云容器发展历程华为云的业界影响和贡献:CNCF初创成员和白金会员,10多个maintainer席位,K8s累计贡献全球TOP4 /国内TOP1OCI(Open Container Initiative)初创成员,社区累计贡献排名全球TOP3/国内TOP1Istio社区贡献排名全球TOP3/国内TOP1华为主导开源的项目:KubeEdge,Volcano,KubeGene,CNI-Genie华为云产品CCE通过全球首批 “Kubernetes软件一致性认证”华为云全球首批通过了Kubernetes认证的服务提供商, KCSP(Kubernetes Certified Service Provider)4.华为云容器业务全景图 基于华为自身实践与社区的贡献积累,华为云自上线之初,就持续利用云原生技术为用户提供标准化、可移植的领先云原生服务。目前,华为云容器及相关服务已覆盖CNCF技术全景图中的七大类别,华为云容器业务全景图如下:华为云提供高性能、高可用、高安全的企业级容器服务,通过CNCF官方认证的两种Kubernetes服务供用户选择。核心的商业产品包括云容器引擎 CCE和云容器实例 CCI,以及与这两个服务配套的镜像仓库、交付流水线、服务网络、智能运维等服务。在核心产品之上,构建了三大水平解决方案,分别是:裸金属容器解决方案、容器混合云解决方案和批量计算解决方案。 云容器引擎(Cloud Container Engine,简称CCE)提供高度可扩展的、高性能的企业级Kubernetes集群,支持运行Docker容器。提供了Kubernetes集群管理、容器应用全生命周期管理、应用服务网格、Helm应用模板、插件管理、应用调度、监控与运维等容器全栈能力,为您提供一站式容器平台服务。借助云容器引擎,您可以在华为云上轻松部署、管理和扩展容器化应用程序。5.典型应用场景场景一:企业业务云原生转型-企业级、轻量化、智能化 企业有数字化转型诉求,希望建设容器平台,实现降本增效目标。价值:CCE敏捷版使您能够在本地IDC构建更可靠、更高效、更安全的Kubernetes集群,帮助用户轻松创建和管理多样化的容器工作负载,并提供容器故障自愈、监控日志采集、自动弹性扩容等高效运维能力,企业级服务网格Istio以及容器化Devops方案。场景二:微服务治理-开箱即用、无缝对接、一站式监测伴随着互联网技术的不断发展,各大企业的系统越来越复杂,传统的系统架构越来越不能满足业务的需求,取而代之的是微服务架构。微服务是将复杂的应用切分为若干服务,每个服务均可以独立开发、部署和伸缩;微服务和容器组合使用,可进一步简化微服务的交付,提升应用的可靠性和可伸缩性。随着微服务的大量应用,其构成的分布式应用架构在运维、调试、和安全管理等维度变得更加复杂,在管理微服务时,往往需要在业务代码中添加微服务治理相关的代码,导致开发人员不能专注于业务开发,还需要考虑微服务治理的解决方案,并且将解决方案融合到其业务系统中。价值:CCE敏捷版深度集成应用服务网格,提供开箱即用的应用服务网格流量治理能力,用户无需修改代码,即可实现灰度发布、流量治理和流量监控能力。场景三:DevOps交付-一站式交付、效率提升80%当前IT行业发展日益快速,面对海量需求必须具备快速集成的能力。经过快速持续集成,才能保证不间断的补全用户体验,提升服务质量,为业务创新提供源源不断的动力。大量交付实践表明,不仅传统企业,甚至互联网企业都可能在持续集成方面存在研发效率低、工具落后、发布频率低等方面的问题,需要通过持续交付提高效率,降低发布风险。价值:CCE敏捷版搭配容器镜像服务提供DevOps持续交付能力,能够基于代码源自动完成代码编译、镜像构建、灰度发布、容器化部署,实现一站式容器化交付流程,并可对接已有CI/CD,完成传统应用的容器化改造和部署。场景四:高性能批量计算-高效调度、异构算力、效率提升30%对于AI、大数据、基因测序、视频处理等行业的用户,其业务特点是数据量大,并且需要大量的计算资源。价值:支持普通业务和AI和大数据业务混合调度,实现底层平台统一。大数据计算业界趋势从存算合一走到存算分离,性价比提升40%,以某行信用卡中心批处理出报告为例,时间从3天缩短到1天。计算由容器承载,原生K8s不支持成组、队列优先级等AI&大数据批处理场景,通过Volcano智能调度,提升30% AI、大数据、基因测序的速度。 场景五:跨云部署-流量自动分发、降低成本多云部署、容灾备份为保证业务高可用,需要将业务同时部署在多个云的容器服务上,在某个云出现事故时,通过统一流量分发的机制,自动的将业务流量切换到其他云上。流量分发、弹性伸缩大型企业客户需要将业务同时部署在不同地域的云机房中,并能自动弹性扩容和缩容,以节约成本。业务上云、数据库托管对于金融、安全等行业用户,业务数据的敏感性要求将数据业务保留在本地的IDC中而将一般业务部署在云上,并需要进行统一管理。开发与部署分离出于IP安全的考虑,用户希望将生产环境部署在公有云上,而将开发环境部署在本地的IDC。价值:云容器引擎利用容器环境无关的特性,将私有云和公有云容器服务实现网络互通和统一管理。应用和数据可独立部署在本地IDC,也可部署在云端,实现本地和云端的无缝迁移,并可统一运维多个云端资源,从而实现资源的灵活使用以及业务容灾等目的。
-
【转载华为云社区】产品信息请点击:https://www.huaweicloud.com/product/cce.html体验云原生之旅:https://activity.huaweicloud.com/cloudnative.html?ggw_hd1.导言当今全球正处于一个数字化颠覆的时代,对于企业而言,积极拥抱数字化转型能够带来业务和管理上的双重提升。华为云容器CCE敏捷版,为企业提供数字化新基建的云原生技术平台,帮助您实现业务敏捷上线、业务战略快速落地。1、企业对数字化转型的需求搭建企业的数据底座:全量数据进湖,实时计算,实时分析,发挥数据的“魔力”提升业务快速上线能力:借助ServiceMesh服务网格强大商用能力,实现业务快速上线高效可靠的运维能力:提供可靠的容器镜像构建和部署,可以快速上线、扩缩容、回滚构建企业微服务架构:基于Istio的非侵入微服务治理能力,进行微服务改造2、云容器技术对企业的价值降低基础设施成本:资源的细粒度管理,可以大幅提升资源利用率,减少基础设施成本缩短应用上线周期:统一应用打包标准,快速在研发/测试/生产环境间分发、部署、上线快速构建跨云业务:标准的运行环境和API,在不同的容器平台上能无缝迁移、统一管理提升应用运维效率:完善的应用生命周期管理能力和自动扩缩容机制,提升运维效率30%+2.华为云容器CCE敏捷版介绍华为云容器CCE敏捷版(简称:CCE敏捷版),是基础设施解耦的企业级、轻量化、智能化的云原生平台,面向混合云形态下,企业业务云原生化转型升级场景,提供云原生业务基础,帮助企业快速转型升级。*部署方式:适用于客户本地机房、公有云、混合云、多云等环境CCE敏捷版的优势:组织匹配、精细控制的租户权限模型完善的租户权限模型(组织-用户),匹配企业研发组织模型、跨集群实现资源、业务的灵活隔离基于角色访问权限控制(RBAC),精细的控制每个租户的资源权限;支持跨云多集群的多租户级别的RBAC管控支持对接多种用户系统(LDAP、SAML、OpenID、华为云IAM等),免除多套租户系统的维护负担支持资源使用计量计费,适合企业内部结算场景云原生、高性能、安全的容器网络方案高性能自研插件:多种UnderLay模式网络,容器网络性能接近主机网络与主流厂商的ELB对接,动态为容器提供对外访问能力(华为云、阿里云、F5、Nginx等)网络QOS:精细化实现流量控制,避免网络堵塞精细化的网络策略:灵活实现组织、项目、Pod三级网络隔离支持容器网络固定IP、源地址保留全面兼容社区生态及华为云商业软件Everest容器存储管理,支持多云存储网关丰富的存储方案:全面支持云容器存储标准,原生支持业界主流存储方案及华为商业存储方案支持AI容器:kubeflow、gpu、Atlas服务器/昇腾芯片支持大数据容器:spark、flink支持基因容器:KubeGene/GCS支持Volcano批量计算引擎面向各类业务场景,兼容各类基础设施兼容物理机与虚拟机:支持直接部署在物理机或业界主流IaaS虚拟化之上与主流云厂商的计算能力对接,动态增删节点,自动弹性伸缩集群(华为云、阿里云、openstack、vsphere等)多异构计算支持:GPU、鲲鹏服务器、昇腾芯片,支持全栈国产化兼容多种操作系统:支持业界主流的操作系统,如CentOS,RedHat,Ubuntu等支持多集群的创建和管理; 支持5000节点规模集群; 支持非高可用集群(单master节点)支持混合云场景:支持线上线下集群统一管控;支持跨云故障检测,应用迁移生态丰富、精细化的运维能力,专业的运维保障全面兼容Prometheus生态:云原生标准监控采集和日志采集接口,支持自定义扩展,全面涵盖集群、容器、应用各层次的监控、日志、告警、调用链等。监控告警信息持久化运维管理RBAC:支持租户的运**限管理,根据角色精细化控制用户的运维管理权限专业运维支持:提供7*24小时运维支持,技术专家现场咨询、培训、维护,为用户提供专业的运维保障。原生服务网格Istio,实现非侵入式云原生应用发布和治理精细化应用发布:金丝雀、蓝/绿发布,提高版本迭代速度,降低业务风险服务级流量治理:一键使能Istio服务网格,非侵入式流量治理策略配置,轻松管理运行态应用智能化、自动化:全面应用流量健康诊断,智能化提供精准治理策略,轻松高效构建应用SLA能力多云/混合云网络流量管理:灵活应对业务流量突发,业务可靠和容灾等问题容器化DevOps解决方案开箱即用,内置标准化流程模板简化使用支持alpha-beta-gamma多环境端到端敏捷交付开放式架构,易于与企业已有系统集成镜像P2P加速,解决各类行业场景问题,支持1W节点分钟级镜像分发3.华为云容器发展历程华为云的业界影响和贡献:CNCF初创成员和白金会员,10多个maintainer席位,K8s累计贡献全球TOP4 /国内TOP1OCI(Open Container Initiative)初创成员,社区累计贡献排名全球TOP3/国内TOP1Istio社区贡献排名全球TOP3/国内TOP1华为主导开源的项目:KubeEdge,Volcano,KubeGene,CNI-Genie华为云产品CCE通过全球首批 “Kubernetes软件一致性认证”华为云全球首批通过了Kubernetes认证的服务提供商, KCSP(Kubernetes Certified Service Provider)4.华为云容器业务全景图 基于华为自身实践与社区的贡献积累,华为云自上线之初,就持续利用云原生技术为用户提供标准化、可移植的领先云原生服务。目前,华为云容器及相关服务已覆盖CNCF技术全景图中的七大类别,华为云容器业务全景图如下:华为云提供高性能、高可用、高安全的企业级容器服务,通过CNCF官方认证的两种Kubernetes服务供用户选择。核心的商业产品包括云容器引擎 CCE和云容器实例 CCI,以及与这两个服务配套的镜像仓库、交付流水线、服务网络、智能运维等服务。在核心产品之上,构建了三大水平解决方案,分别是:裸金属容器解决方案、容器混合云解决方案和批量计算解决方案。 云容器引擎(Cloud Container Engine,简称CCE)提供高度可扩展的、高性能的企业级Kubernetes集群,支持运行Docker容器。提供了Kubernetes集群管理、容器应用全生命周期管理、应用服务网格、Helm应用模板、插件管理、应用调度、监控与运维等容器全栈能力,为您提供一站式容器平台服务。借助云容器引擎,您可以在华为云上轻松部署、管理和扩展容器化应用程序。5.典型应用场景场景一:企业业务云原生转型-企业级、轻量化、智能化 企业有数字化转型诉求,希望建设容器平台,实现降本增效目标。价值:CCE敏捷版使您能够在本地IDC构建更可靠、更高效、更安全的Kubernetes集群,帮助用户轻松创建和管理多样化的容器工作负载,并提供容器故障自愈、监控日志采集、自动弹性扩容等高效运维能力,企业级服务网格Istio以及容器化Devops方案。场景二:微服务治理-开箱即用、无缝对接、一站式监测伴随着互联网技术的不断发展,各大企业的系统越来越复杂,传统的系统架构越来越不能满足业务的需求,取而代之的是微服务架构。微服务是将复杂的应用切分为若干服务,每个服务均可以独立开发、部署和伸缩;微服务和容器组合使用,可进一步简化微服务的交付,提升应用的可靠性和可伸缩性。随着微服务的大量应用,其构成的分布式应用架构在运维、调试、和安全管理等维度变得更加复杂,在管理微服务时,往往需要在业务代码中添加微服务治理相关的代码,导致开发人员不能专注于业务开发,还需要考虑微服务治理的解决方案,并且将解决方案融合到其业务系统中。价值:CCE敏捷版深度集成应用服务网格,提供开箱即用的应用服务网格流量治理能力,用户无需修改代码,即可实现灰度发布、流量治理和流量监控能力。场景三:DevOps交付-一站式交付、效率提升80%当前IT行业发展日益快速,面对海量需求必须具备快速集成的能力。经过快速持续集成,才能保证不间断的补全用户体验,提升服务质量,为业务创新提供源源不断的动力。大量交付实践表明,不仅传统企业,甚至互联网企业都可能在持续集成方面存在研发效率低、工具落后、发布频率低等方面的问题,需要通过持续交付提高效率,降低发布风险。DevOps持续交付场景价值:CCE敏捷版搭配容器镜像服务提供DevOps持续交付能力,能够基于代码源自动完成代码编译、镜像构建、灰度发布、容器化部署,实现一站式容器化交付流程,并可对接已有CI/CD,完成传统应用的容器化改造和部署。场景四:高性能批量计算-高效调度、异构算力、效率提升30%对于AI、大数据、基因测序、视频处理等行业的用户,其业务特点是数据量大,并且需要大量的计算资源。价值:支持普通业务和AI和大数据业务混合调度,实现底层平台统一。大数据计算业界趋势从存算合一走到存算分离,性价比提升40%,以某行信用卡中心批处理出报告为例,时间从3天缩短到1天。计算由容器承载,原生K8s不支持成组、队列优先级等AI&大数据批处理场景,通过Volcano智能调度,提升30% AI、大数据、基因测序的速度。 场景五:跨云部署-流量自动分发、降低成本多云部署、容灾备份为保证业务高可用,需要将业务同时部署在多个云的容器服务上,在某个云出现事故时,通过统一流量分发的机制,自动的将业务流量切换到其他云上。流量分发、弹性伸缩大型企业客户需要将业务同时部署在不同地域的云机房中,并能自动弹性扩容和缩容,以节约成本。业务上云、数据库托管对于金融、安全等行业用户,业务数据的敏感性要求将数据业务保留在本地的IDC中而将一般业务部署在云上,并需要进行统一管理。开发与部署分离出于IP安全的考虑,用户希望将生产环境部署在公有云上,而将开发环境部署在本地的IDC。价值:云容器引擎利用容器环境无关的特性,将私有云和公有云容器服务实现网络互通和统一管理。应用和数据可独立部署在本地IDC,也可部署在云端,实现本地和云端的无缝迁移,并可统一运维多个云端资源,从而实现资源的灵活使用以及业务容灾等目的。
推荐直播
-
手把手教你实现mini版TinyVue组件库
2024/04/17 周三 16:30-18:00
阿健 华为云前端开发DTSE 技术布道师
在前端Web开发过程中,跨版本兼容性问题是一个普遍存在的挑战。为了解决这些痛点,OpenTiny推出跨端、跨框架、跨版本组件库TinyVue。本期直播聚焦于华为云的前端开源组件库TinyVue,通过mini版TinyVue的代码实践与大家共同深入解读Vue2/Vue3不同版本间的差异。这对于提升用户体验,减低维护成本,提升开发者技术洞察有重要意义。
回顾中 -
如何快速入驻O3使能伙伴服务作业平台
2024/04/18 周四 16:00-16:40
红喜 O3伙伴服务工作台技术总架构师
本期邀请O3伙伴服务工作台技术总架构师,讲解O3伙伴服务工作台的设计理念,及演示工作台关键能力与价值点,带你2步快速入驻工作台。O3伙伴服务工作台,具备在线Online、开放Open、协同Orchestration的特征,作为伙伴服务的统一入口,支持伙伴以租户方式入驻,涵盖伙伴工程师、管理者等多角色,是一个以伙伴服务领域全旅程作业为中心,整合华为服务各专业领域能力,开放共享的一站式作业平台。
去报名
热门标签