### 概述  上图即为整个CM的配置逻辑。下面将介绍如何使用拖拽式的画布配置CM通讯。 ------------ ## 场景一：配置一对通讯的收发节点 ### 一、创建拖拽式工程  *图1.1*  *图1.2* 1）按照图1.1的操作即可创建拖拽式工程。 2）展开工程即可看到如图1.2所示，将画布分为四个部分，分别为：应用设计、系统设计、软件部署、服务实例。进入到各个画布即可创建和设计该画布内的autosar元素。 ------------ ### 二、DataType画布  *图2.1*  *图2.2* 1）在该画布内可设计数据结构。如图2.1中1部分所示，可自定义一些基本数据类型。通过第2部分创建结构体（Structure）和结构体内的元素（Element）。第3部分为快捷创建方式，如果工程内已经导入平台提供的基础数据的arxml文件，那么可通过该部分快速地在结构体内创建基础数据类型（会对平台基础数据进行引用）。第4部分可创建枚举类型数据。 2）如对图中MyStructure内的element并未引用任何值。按图2.2操作所示即可完成引用。 ------------ ### 三、ServiceInterface画布  *图3.1*  *图3.2* 1）该画布可完成ServiceInterface的创建，通过属性栏可完成对ServiceInterface的shortName和NameSpace的设定。如图所示，可完成对ServiceInterface的通讯方式的设定，包括：event、field、method。通讯方式中需要设定所传输的数据类型，也就是在DataType中设定的。 ------------ ### 四、SwComponent画布  *图4.1* 1）该画布可创建SwComponent，并在上面创建P/Rport。 2）通过属性栏设定port所引用的ServiceInterface，如果Pport和Rport之间所引用的ServiceInterface相同，则会在两者之间出现连线。 3）当Pport和Rport所引用的ServiceInterface都为空时，采用contract创建两个port之间的连线的时候。会出现弹窗，选择serviceInterface，并设置到两个port上。 4）当Pport上已经设置了serviceInterface，再用contract连接Pport和Rport时，会直接将ServiceInterface设置到Rport上。 5）如图，设定了两个SwC，一个作为服务端（Server）提供Pport，一个作为接收端（Client）提供Rport。分别作为通讯节点的发端和收端。 ------------ ### 五、MachineDesign画布  *图5.1* 1）通过该画布可以创建MachineDesign（Connector、Discovery）和EthernetPhysicalChannel（Endpoint）。并且在Endpoint上完成对ipV4、mask和MulticastIp的设定（单播地址和多播地址）。 ------------ ### 六、ModeDeclarationGroup画布（为SM部分，与CM无关）  *图6.1* 1）通过该画布可完成SM部分的设计，状态的定义，状态之间的转移、依赖和冲突关系。 ------------ ### 七、Machine Manifest画布  *图7.1* 1）在该画布可新建machine，并弹窗选择machineDesign 2）将ModeDeclarationGroup部署到machine上（SM部分） ------------ ### 八、Executable画布  *图8.1* 1）该画布可创建ProcessDesign、Executable、SwComponent和CompositionSwC。并设定Executable与SwC（SwComponent、CompositionSwC）之间的关系；设定ProcessDesign与Executable之间的关系；设定CompositionSwC与SwComponent之间的关系。 2）如图中所示，我们创建了两个ProcessDesign，其中ProcessDesign1代表服务端（发送端），ProcessDesign2代表客户端（接收端）。 ------------ ### 九、ProcessToMachineMapping画布  *图9.1*  *图9.2* 1）如图9.1，在该画布会显示出之前创建的Machine和Process，也可在该画布中创建Process。 2）如图9.2，将Process拖拽到Machine中，意味着将Process部署到Machine中。 ------------ ### 十、Instance画布（DdsDeployment、SomeipDeployment）  *图10.1*  *图10.2*  *图10.3*  *图10.4*  *图10.5*  *图10.6*  *图10.7* 1）如图10.1和10.2所示，通过该画布可创建Dployment（Dds、Someip）。通过上图的操作步骤：新建Deployment；设定Deployment所引用的ServiceInterface；根据ServiceInterface来Synchronize Deployment进而自动生成Deployment下面的子元素。也可手动的通过右边的工具栏创建Deployment下面的子元素。 2）如图10.3所示，在该画布可创建Pinstance和Rinstance。创建的时候会出现弹窗，在其中需要完成Id、Deployment、connector、ProcessDesign和Port的设定，通过这些的选择也就是完成了InstanceToPortMapping和InstanceToMachineMapping的创建和关系设定。值得注意的是Pinstance需要选择Pport，Rinstance需要选择Rport。 3）如图10.4所示，当所创建的Pinstance和Rinstance的InstanceId、DomainId（SomeIpInstance不需要）、Deployment相同时，两者之间会出现连线，表示这两个instance具备通讯的能力。 4）如图10.5所示，也可对instance进行End2EndEventProtectProps和End2EndMethodProtectProps的配置，两者分别保证Event和Method的通讯质量。 5）如图10.6所示，SomeIp画布中可进行SdConfig的创建和参数的设置。 6）如图10.7所示，由于这两张画布的内容比较多，可通过勾选的方式，选择展示哪些内容。

>摘要：云原生浪潮下，容器技术是串联起整个云原生世界的关键一环。本文分享自华为云社区[《左手自研，右手开源，技术揭秘华为云如何领跑容器市场》](https://bbs.huaweicloud.com/blogs/281793?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：华为云社区精选。  近日，IDC 发布的《PRC SDC Market Overview and Analysis, 2020H2/2020》报告显示，华为云**以24.3%的市场份额，斩获中国容器软件市场第一**。 下面，我们从技术角度分析，华为云为什么能领跑容器软件市场。 # 容器如何成为宠儿？ 容器是什么？ 从字面上看，这是一个用于盛放某种东西的器具，实际也是如此，容器技术可以将软件的程序代码和依赖项打包起来，让其与实际运行的环境隔离，哪里需要搬哪里，比如在数据中心、个人电脑上部署运行。 这个概念有点像老大哥虚拟机，但是两者的相似点仅仅在于：提供独立的环境运行软件。在[基因、容器和上帝](https://bbs.huaweicloud.com/blogs/114535) 中，作者从哲学化的视角谈了程序员创造的虚拟世界，也点出了两者的异曲同工之妙：Docker容器技术和VM虚拟机从技术原理上看，是完全不同的路线，连实现思路都不一样。但是，它们所达成的效果或者说是目标确是惊人的一致：即模拟一台看着像物理机一样的东西。 虽然如此，但两者内在逻辑差别很大。容器可以在操作系统级别进行虚拟化，一个操作系统内核上可以运行多个容器，而虚拟机只是硬件层面的虚拟化。相比较VM，容器更轻巧、启动速度更快、占用的内存微乎其微，[容器与Docker](https://bbs.huaweicloud.com/blogs/203431)详细对比了虚拟机和容器的优缺点。 随着用户对云端应用开发、部署和运维的效率愈加重视，间接促成了容器的盛行。 不过，容器在云服务领域“发光发热“离不开一个关键技术：**Docker**。  Docker是目前应用最多的容器引擎技术，它的logo是一只蓝色的鲸鱼驮着一堆小方块。开发者通过docker可以为任何应用创建容器：应用的流程、库和依赖，甚至整个操作系统的文件系统能被打包成一个简单的可移植的包，这个包就像是鲸鱼背上蓝色的小方块，它可以在任何运行Docker的机器上使用，从根本上解决了开发运行环境不一致的问题，让容器真正实现了一次构建，随处运行。 当应用程序被分解为多个小组件或服务，每个组件或服务都放置在一个容器中，每个容器可能还运行在不同的计算机中，此时就需要对容器进行有序的编排和管理。就像电脑上的操作系统，它可以管理所有应用程序，并规划哪个应用程序何时使用电脑的CPU和其他硬件资源。 脱胎于Google内部集群管理系统Borg的kubernetes逐渐成为业界标准，它可以通过API的方式将多个不同的计算机作为一个资源池进行管理，类似某种集群操作系统，管理整个集群中的容器化应用程序。[ Docker与Kubernetes的兴起](https://bbs.huaweicloud.com/blogs/138949)这篇文章就具体谈到了kubernetes（k8s）如何从三足鼎立的局面中PK掉其他两个对手，在混战中取得胜利。 至此，属于容器的黄金时代大幕正式拉开。 Gartner预测，到2023年，70%的组织将在生产中运行三个或更多容器化应用程序。容器、Kubernetes和微服务应用模式是企业IT创新和数字化转型的三大驱动力。 华为很早就投入了容器的怀抱中，由于一直使用虚拟机封装应用程序，每次启动虚拟机花费了大量的时间，这给管理及部署基于虚机应用程序的高成本和低效率带来了挑战。所以在2015年的时候，华为决定利用Kubernetes技术对自身IT系统进行容器化改造。华为在通过自身的容器化改造实践受益的同时，又将遇到的实际问题不断贡献给社区，与社区成员一同推动Kubernetes的发展。 2018年4月，华为云获得了CNCF基金会的顶级席位——CNCF技术监督委员会席位，全球共9席，华为是亚洲首家进入者。 同时，随着越来越多的企业业务选择容器化，在集群的规模、性能、实时监控与弹性扩缩容等方面都提出了新的要求，当开源社区方案难以解决这些问题的时候，就非常考验各大云服务供应商的技术能力。 # 万丈高楼平地起，建设好云原生基础设施 在[为什么说容器的崛起预示着云原生时代到来？](https://bbs.huaweicloud.com/blogs/200395)中，华为云云原生团队认为，各类现代化的应用都将会运行在K8s之上，不仅仅是当前以互联网App、WebService为代表的无状态应用，还有新型的诸如大数据、AI、分布式数据中间件等等有状态应用，以及边缘应用也将会普遍运行在K8s之上，K8s将完成对各类现有平台的归一化，成为一个统一的应用运行的基础平台。 华为云最早于2018年洞察到了这一技术趋势，在容器全栈产品中构建了Vessel云原生技术平台，主要包括了以**容器引擎iSula、容器网络Yangtse、容器存储Everest**为代表的面向统一资源层的云原生基础设施组件。  下面，我们将逐一为大家揭开华为云的容器技术面纱。 # 容器引擎iSula 基于docker和kubernetes，首先Docker并不是万能药，它在某些场景下也存在不足，比如： - 在资源敏感环境，或需要部署高密度容器节点时，容器对基础设施的资源占用会急剧升高； - 当大规模应用拉起或遇到突发流量时，并发速度可能成为瓶颈。 当主流的 Docker 等容器引擎在特定用例下力不从心时，一些针对某种用例进行过专门优化的容器引擎技术开始崛起。比如说，以 Kata Container 为代表的专门针对容器隔离性不够严格而设计的安全容器技术；以 iSula 为代表的针对资源受限的边缘计算和 IoT 环境设计的轻量级容器技术。 可以看出，iSula是与Docker相对的一种容器引擎，它一方面完全兼容现有容器生态，另一方面相比Docker内存占用下降68%、启动时间缩短35%。 比如相比Golang编写的Docker，iSula使用C/C++实现，具有轻、灵、巧、快的特点，不受硬件规格和架构的限制，底噪开销更小。在严苛的资源要求环境下，轻量模式下的 iSulad 本身占用资源极低（ 15M） 。  2017 年，iSula 技术团队成功将 Kata Containers 集成到 iSula 容器平台，并于 18 年初应用于华为云容器服务，**推出基于iSulad 容器引擎和 Kata Containers 的商用容器服务——华为云容器实例 CCI（Cloud Container Instance），这也是业界首个 Serverless 架构的云容器服务**。 那么，基于iSulad 容器引擎和 Kata Containers 如何打造安全、高性能的CCI？且看 [基于 Kata Containers 与 iSulad 的云容器实践解析](https://bbs.huaweicloud.com/blogs/147030)进一步分析，文中提到真正的 Serverless 容器服务中，集群管理由云服务提供商承担，客户只需要关注每个应用的容器实例即可。在这种情况下，云服务提供商需要考虑如何在统一管理面下保证每个用户的安全。 CCI 服务所属的 Kubernetes 集群直接部署在裸金属服务器之上，底层是 Kata Containers，中间靠 iSula 容器平台连接。其中，依靠 Kata Containers 的强隔离特性，多个租户之间的容器运行环境强隔离，不同租户之间的容器不感知、不可见，做到在同一台裸金属服务器上混合部署而安全无虞。 安全之外，在算力方面，CCI基于iSula提供的GPU直通功能，可以直接在容器中使用各种GPU进行AI计算。再加上CCI无需购买和管理弹性服务器，可直接在华为云上运行容器和pod，也无需创建集群，管理master和work节点，非常适用于批量计算，高性能计算，突发扩容，以及CI/CD测试。 在此，华为云社区推荐一些有趣的案例，可以帮助大家快速上手CCI，比如[云容器实例CCI - 使用Tensorflow训练神经网络](https://support.huaweicloud.com/bestpractice-cci/cci_04_0008.html#toTop) 和[云容器实例CCI – 经典2048数字合成游戏部署指南](https://bbs.huaweicloud.com/forum/thread-17431-1-1.html) ，通过这些简单的实操和小游戏，能够对Serverless 架构的云容器服务有更直观的认识。 # 容器网络Yangtse 大家应该都看过某些明星导致社交媒体平台宕机的新闻，明星事件带来的突发流量触发业务扩容，以前是扩容虚拟机，速度慢还情有可原，现在大部分互联网平台都使用容器了，为什么扩容速度还是跟不上流量增长的节奏呢？ 首先，Kubernetes本身并不负责网络通信，它提供了容器网络接口CNI负责具体的网络通信，开源的CNI插件非常多，像Flannel、Calico等。包括华为云容器引擎CCE也专门为Kubernetes定制了CNI插件，使得Kubernetes可以使用华为云VPC网络。 尽管如此，多个容器集群的网络通信（容器连接到其他容器、主机和外部网络的机制）始终是个复杂的问题。比如大规模节点管理场景下网络性能的瓶颈；网口发放速度如何匹配容器扩容速度等等。最终，对对底层虚拟化网络提出了**密度更高，规模更大，发放更快，调整更频繁**的要求。 容器网络Yangtse深度融合华为云虚拟私有云（VPC）原生网络能力，它采用的VPC-Native组网被称作ENI(Elastic Network Interface)模式，容器直接挂载具有VPC子网地址的ENI，具备完全VPC网络互通能力。容器实例可以在集群VPC网络和与之相连的其他VPC网络中进行原生路由，并且直接使用VPC原生的网络能力如 network policy、ELB、EIP、NAT等。换言之，就是容器地址属于VPC子网，容器独占对应的ENI网口，解决了容器的互通性问题。 而且Yangtse基于华为云擎天架构的软硬协同能力，会把治理和转发逻辑下沉到擎天卡上，实现容器网络主机资源0占用。数据显示，通过硬件直通方式及动态网络队列，网络整体性能提升40%，单容器PPS提升2倍；基于warm pool的能力，1-2秒内完成ENI的发放和网络端到端打通。 至于具体如何实现，大体上可以总结为三点： 1、warm pool 机制可以解决网络资源预热的问题。如果不做预热，容器网络端到端打通时间在一分钟以上，分钟级容器启动时间是不可接受的。 Warm pool机制在裸金属节点上预挂载一定数量ENI（用户可根据服务部署并发量自定义配置），容器随时调度到预热节点上都有即时可用的ENI网卡。经过warm pool的优化，容器网络端到端打通时间缩短为1s-2s。 2、得益于擎天架构的优势，裸金属容器还可以向虚拟机容器扩容，而在虚拟机容器上，容器网络Yangtse使用了Trunkport技术，结合ENI的优势，在保障性能的前提下，单台服务器理论上可为千容器同时提供直通网络能力。 3、当应用业务流量增长触发扩容时，如果ELB直接全量发放分摊的流量请求，海量请求会迅速压垮（overload）新扩的容器，造成扩容失败。 所以新扩容的后端实例需要“慢启动”的过程，但一个节点部署多个容器时，节点的二次分发让ELB无法感知到最终的后端容器，进而无法做到容器级别的流控，也难以保证稳态后的负载均衡。容器网络Yangtse实现了与华为云ELB v3独享型负载均衡实例的直通。 具体技术详解，可以阅读[华为云第二代裸金属容器技术系列：应对海量并发的网络黑科技](https://bbs.huaweicloud.com/blogs/194532) 。 目前，Yangtse已经为华为云CCE/CCI/IEF等容器服务提供了统一的容器网络方案，覆盖虚机、裸金属、Serverless和边缘节点等各种容器运行环境。 其中**最值得注意的是CCE，它是一种托管的Kubernetes服务，可进一步简化基于容器的应用程序部署和管理，深度整合华为云的计算、存储、网络和安全等技术构建高可用Kubernetes集群**。 在CCE中，用户可以直接使用华为云高性能的弹性云服务器、裸金属服务器、GPU加速云服务器等多种异构基础设施，也可以根据业务需要在云容器引擎中快速创建CCE集群、鲲鹏集群、CCE Turbo集群，并通过云容器引擎对创建的集群进行统一管理。 以今年在HDC重磅发布的云容器集群CCE Turbo为例，它主要针对企业大规模业务生产中的高性能、低成本诉求，在计算、网络和调度上全方位加速， [新一代容器解决方案：云容器引擎CCE Turbo集群](https://bbs.huaweicloud.com/blogs/198569)就总结了它在这三个方面的新突破。 >在计算加速方面，业界独家实现容器100%卸载，服务器资源和性能双零损耗。 >在网络加速方面，采用独创的容器直通网络，让两层网络变成一层，端到端连通时间缩短一半，有效支撑业务秒级扩容千容器。 >在调度加速方面，通过感知AI、大数据、WEB业务的不同特征，以及应用模型、网络拓扑等，实现业务混合部署、智能调度，还自动优化任务调度策略，实现1万容器/秒的大规模并发调度能力。 再就是容器存储Everest， 每个POD使用独立VF，读写时延降低50%；将Posix组件卸载，单进程节省30M内存；NAS卷直挂POD容器内，提高请求处理效率30%。 # “查漏补缺”Kuberentes，开源技术解决特殊场景难题 基础设施之外，华为云先后将Vessel的核心组件Volcano和KubeEdge开源，并贡献给云原生计算基金会CNCF，成为社区首个容器智能边缘项目和容器批量计算项目。 # Volcano——批量计算 当有更多的用户希望在Kubernetes上运行大数据、 AI和HPC应用，而它默认调度器又无法满足包括公平调度、优先级、队列等高级调度功能时，就需要一些新的技术解决方案登场了。 考虑到AI、大数据等业务的需求，华为云在Kubernetes调度上做了一个感知上层业务的调度——Volavano，它是基于Kubernetes构建的一个通用批量计算系统，[Volcano架构设计与原理解读](https://bbs.huaweicloud.com/blogs/239645)就Volcano产生的背景、架构设计与原理进行深度解读，用数据证明了Volavano为分布式训练、大数据、HPC场景带来了效率的提高。 [Volcano火山：容器与批量计算的碰撞](https://bbs.huaweicloud.com/blogs/205045)则从并行计算开始说起，详细解释了Volcano的调度框架、调度实现原理。作为调度系统，Volcano通过**作业级的调度**和**多种插件机制**来支持多种作业，其中作业级的调度支持以多种类型的作业为目标进行设计，比如基于时间的、跨队列的等等。Volcano的插件机制有效的支撑了针对不同场景算法的落地，从早期的gang-scheduling/co-scheduling，到后来各个级别的公平调度。  图：总体架构 在华为云今年刚推出的CCE Turbo容器集群中，就采取了多项Volcano关键调度技术，如基于共享资源视图的多调度器、决策复用、应用模型感知、数据位置亲和调度、网络拓扑调度等，从而实现1万容器/秒的大规模并发调度能力。 # KubeEdge——边缘计算 容器天然的轻量化和可移植性，非常适合边缘计算的场景。理想情况下，在边缘部署复杂的应用，Kubernetes 是个很好的选择，现实真相是要想在边缘部署 Kubernetes集群，各种问题层出。 比如很多设备边缘的资源规格有限，特别是 CPU 处理能力较弱，因此无法部署完整的 Kubernetes；Kubernetes 依赖 list/watch 机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备休眠重启；边缘业务通常在私有网络中，无公网IP，云边跨越公网导致延迟高。 为了解决这些问题，KubeEdge应运而生。KubeEdge即Kube+Edge，顾名思义就是依托K8S的容器编排和调度能力，实现云边协同、计算下沉、海量设备的平滑接入。 其架构主要包含三部分，分别是云端、边缘侧和终端。云端负责应用和配置的下发，边缘侧则负责运行边缘应用和管理接入设备。 [KubeEdge架构解读：云原生的边缘计算平台](https://bbs.huaweicloud.com/blogs/241350)从KubeEdge架构设计理念、KubeEdge代码目录概览、KubeEdge集群部署三方面带大家认识KubeEdge。  关于KubeEdge和Volcano的更多技术硬实力体现和落地案例，可以阅读专题[【技术补给站】第5期：从架构和实践，剖析KubeEdge+Volcano技术硬实力](https://bbs.huaweicloud.com/blogs/240234)，在此不再赘述。 # 解决多云容器集群管理，新秀Karmada崛起 批量计算和边缘计算的问题解决后，伴随云原生技术和市场的不断成熟，很多企业都是多云或者混合云的部署，一方面可以避免被单供应商锁定降低风险，另一方面也可以是出于成本的考量。 但是多集群同时也带来了巨大的复杂性，包括如何让应用面向多集群部署分发，并做到多集群之间灵活切换。在今年的HDC上，华为云宣布了**多云容器编排项目Karmada正式开源**，Karmada项目由华为、工商银行、小红书、中国一汽等8家企业联合发起，它可以构建无极可扩展的容器资源池，让开发者像使用单个K8s集群一样使用多云集群。 Karmada是一个 Kubernetes 管理系统，基于 [Kubernetes Federation v1](https://github.com/kubernetes-retired/federation) 和[ v2](https://github.com/kubernetes-sigs/kubefed) 开发，它可以跨多个 Kubernetes 集群和云运行云原生应用程序，直接使用 Kubernetes 原生 API 并提供高级调度功能，实现真正的开放式多云 Kubernetes。 [华为云MCP多云跨云的容器治理与实践](https://bbs.huaweicloud.com/blogs/281796)为我们梳理了Karmada项目诞生的前因后果，以及整个项目的核心价值，比如对K8s原生API兼容 、丰富的多集群调度支持、开箱即用等等。  Karmada的架构设计图 从架构图可以看到，整个控制面板可以分为四大块：提供原生API入口，存放用户yaml和Karmada资源对象的Karmda API Server，和配套存储ETCD；以及资源控制器Karmda Controller Manager、多集群调度器 Karmda Sheduler。其中，最关键的就是API Server，让用户既有的资源配置（yaml）可以借助K8s原生API进行部署。 综上，Karmada 旨在为多云和混合云场景下的多集群应用程序管理提供 turnkey 自动化，其关键功能包括集中式多云管理、高可用性、故障恢复和流量调度。 今年的HDC期间，在线教育平台VIPKID的后端研发高级专家分享了使用 Karmada实现从天到秒的跨云迁移实践。在剖析VIPKID的多场景云原生落地实践后，他对多集群管理提出了一些思考，如下图所示，理想的多集群管理方式是： - 集中管理，但要原生； - 应用在不同集群的差异化管理； - 集群故障自动转移。  对比了多家方案后，VIPKID选择了开源的方案 Karmada。作者表示Karmada的整个设计结构就是按原生k8s开发标准开发的，唯一差别之处是需要管理多个集群不同的 workload信息，所以改写了调度器和控制器，在它们下面对接了多个集群管理起来。这样最大的好处是看起来在控制一个集群，但最终的效果是在控制多个集群。 具体案例情况参见[Karmada | VIPKID在线教育平台从天到秒的跨云迁移实践](https://bbs.huaweicloud.com/blogs/281788)，文章内有现场demo演示用Karmada实现多集群管理。 另一个经典案例是[工商银行多k8s集群管理及容灾实践](https://bbs.huaweicloud.com/blogs/281790)。工商银行的应用平台云容器规模超20万，业务容器占到55,000个左右，整体的一些核心业务都已入容器云内部，包括个人金融体系的账户，快捷支付、线上渠道等。当越来越多的核心业务应用入云之后，最大的挑战是容灾以及高可用。 但既有的运管平台并不能解决这些问题，比如没有整体的跨集群自动伸缩能力、集群对上层用户不透明、没有跨集群的自动调度和迁移等等。对此，他们根据业务场景调研了一些多集群管理平台，最终也选择了社区支持的开源项目Karmada。 Karmada以类k8s的形式部署，对他们来说，改造成本是比较小的，只需在上面部署一个管理集群即可。而且Karmada仅管理资源在集群间的调度，子集群内分配高度自治。在实践中，Karmada的资源调度、容灾、集群管理和资源管理的优势突出。 截止到现在，工行在测试环境中已经用Karmada对存量集群进行一些纳管，未来规划的关键的点是如何和整体云平台进行集成。 项目地址 ：GitHub - karmada-io/karmada: Open, Multi-Cloud, Multi-Cluster Kubernetes Orchestration 总结 围绕Docker和kubernetes，华为云在技术层面做了诸多的优化和新的探索尝试，除此之外，华为云还有端到端的容器运维管理体系，涵盖资源编排、容器应用持续交付、应用生命周期管理、镜像安全扫描以及日常运维监控等。 云原生浪潮下，容器技术是串联起整个云原生世界的关键一环，它的市场之争，正是山雨欲来风满楼，想要占得高地，技术实力、开源生态、合作伙伴，缺一不可。

>摘要：云原生ADN网络的未来，是公有云Internet接入降成本的手段，以及对自建光纤骨干网的补充，有力地支撑 “东数西算”国家新基建布局。本文分享自华为云社区[《华为云顾炯炯：应用传送网络(ADN)，重新定义云原生时代的媒体网络》](https://bbs.huaweicloud.com/blogs/301210?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：技术火炬手。 伴随媒体内容逐渐的丰富多彩、引人入胜，媒体内容的生产制作从本地工作室上移至云端成为了必然趋势。媒体内容从生产到消费的全流程，离不开媒体内容的生产者、云端数字内容制作基础设施、平台系统和媒体内容消费者。**而连接这些角色的背后，是一张高质量的精品媒体网络**。 9月24日，华为云举办了主题为“数字内容云上生产，共创影视产业新高地”的主题论坛，**华为云首席架构师顾炯炯**为大家带来了今年华为云在云原生媒体及网络领域的重磅级创新服务：**应用传送网络（Application Delivery Network），简称ADN服务**。 # 云原生应用传送网络ADN: 多级QoS、高可靠、高弹性的媒体服务网络基石 ADN为云原生媒体服务，乃至更广义的云上互联网应用提供了多级QoS，高可靠，高弹性的网络基石，相比基于“尽力而为”传送IP网络路由机制的Internet互联网， ADN 网络是一张叠加在Internet互联网，以及华为云遍及全球的云端及分布式边缘基础设施和专线网络之上的overlay网络。 该网络彻底解决了互联网缺乏QoS保障，局部路由拥塞收敛慢，以及专线成本高，覆盖区域受限的问题，具备软件定义的可编程能力，无需升级改动存量运营商网络，即可支持分钟级新增路由节点及路由变更，使得媒体网络具备了云的“弹性敏捷”的核心特征。从而为媒体业务提供了兼具互联网全域覆盖、低成本及专线的确定性QoS保障优势的基础网络传送服务，并且可支持应用驱动的SLA与QoS。  # 云原生应用传送网络（ADN）架构：应用驱动、软件定义、敏捷智能 整体来看，云原生应用传送网络ADN与内容传送网络CDN的命名相对应，CDN的定位是通过检测Web与视频内容的热点部分，以及进一步通过热点内容的缓存及存储实现带宽成本的降低，以及用户接入时延体验的提升。 ADN的适用范围则相比CDN更为广泛，几乎可覆盖所有分布式互联网应用，突破CDN无法加速动态生产Web内容的Web网页的局限，这也正是ADN名称的来由。  # 1. ADN网络的3层架构：物理层、逻辑层、应用层 ADN的整体技术架构划分为3层，物理层、逻辑层，以及应用层，物理层对应华为云存量的全球云骨干网及各电信运营商的Internet互联网，而ADN网络的核心正是叠加在这2张物理承载网络之上的一张统一的逻辑Overlay网络，也即逻辑层ADN网络内任意2个节点之间的路由，对应物理层节点之间的直达Internet或专线物理路由，或者通过若干跳ADN节点中继转发的多段Internet路由及物理专线路由的拼接组合。 ADN网络内特定任意2节点之间最优路由之所以可能对应非直达的、多段迂回转发的物理路由，原因在于传统物理路由机制，如OSPF、BGP等，采用的是邻居发现算法，因此在遇到部分物理节点拥塞的情况下，无法实现物理层路由的及时快速调整，此时基于ADN Overlay转发节点的物理路由组合，则可能规避该局部拥塞点，给出更优的路径选择。 ADN的应用层即包括上文提到的云原生媒体服务，也即媒体生产、媒体分发，以及媒体应用，也包括运行在云上的泛互联网App，比如游戏、文娱，办公，甚至通过REST API远程交互协同的各类分布式应用，逻辑层的ADN应用传送网络服务通过契约化定义的AND API，与应用层的云原生媒体服务及互联网App进行交互，输入参数包括由应用层指定的ADN路由的起始、终结节点，以及希望起始到终结节点之间路由必须满足的应用层、传输层、网络层的QoS/SLA指标，而API的返回输出参数，则包括含了从ADN起点到终点之间的路由节点的最终序列。 # 2. ADN网络的三大核心技术特征 **广覆盖、高敏捷、全互联的网络拓扑**。 通过无所不在、彼此互联互通，超过2500个ADN节点的全球广泛覆盖，ADN网络实现了最终用户的一跳入网；同时，通过支持ADN节点的分布式容器化部署，实现了分钟级节点增删与网络拓扑更新的高弹性、高敏捷；通过逻辑、物理分层解耦，通过任意ADN节点之间基于Full Mesh的点到点测量，为任意2个ADN节点之间动态最优路径的选择提供了依据和保障。 **多目标驱动智能路由，多样化接入协议传输**。 支持分钟级端到端路由图优化算法，实现智能路由计算；支持单流分多流、多流合并单流，具备多优先级路径的实时选择能力；具备抗弱网协议增强、具备高可靠的传输能力，实现智能拥塞控制；通过华为自研设计的nStack协议栈，DPDK／用户态驱动转发的技术，实现近线速的Overlay转发能力； 提供了TCP/UDP/域名解析，以及SDK模式等灵活多样化的ADN网络接入协议选项。 **应用驱动、软件定义的SLA，租户和业务感知的流量调度**。 在ADN的API定义中，通过应用驱动、软件定义的网络层/传输层/应用层QoS/SLA指标，比如网络层的时延、丢包，以及媒体应用层的抖动、音视频MOS等，描述上层应用App希望ADN网络达成的质量保障水平及目标；在应用感知方面，基于云服务类型感知的网络流量预测，及基于AI、大数据统计的租户应用流量画像 ADN网络进一步支持业务流量的分时错峰调度，以及跨端边云的应用与数据迁移同步能力。 # ADN服务的核心价值：应用和媒体加速、极致敏捷可靠的云接入与云互联 ### 总体而言，ADN服务的最终客户价值体现在2方面：面向互联网应用、媒体内容体验提升与保障的全路径网络加速的能力；面向云租户提供极致敏捷可靠的云接入、云互联服务。 ADN服务支撑企业租户以最优的性价比及敏捷可靠性，从本地IDC数据中心或办公地点接入最近的云数据中心Region或边缘站点，以及解决不同云服务区域之间，云服务区域与边缘站点之间，不同终端用户/边缘站点之间的互联网加速能力问题。 # 1. 应用及媒体传输全路径加速方面，ADN实现了同等于专线的QoS质量，但比专线便宜50% 基于ADN网络的测试统计结果来看，对于大于1000公里的长距离连接，ADN网络相比原生Internet物理网络的平均优化幅度达到20%到40%以上，比如“约翰内斯堡 — 新加坡”，以及“墨西哥城 —上海”的远程连接场景，优化路径分别调整为“约翰内斯堡—香港—新加坡”，以及“墨西哥城—硅谷—上海”， 优化幅度分别达到了42.5%和36.7%，而丢包率方面，ADN即便在基于Internet物理承载的前提下，依然可消除长途Internet网络连接，特别是TCP/HTTP连接协议下，由于丢包所带来的吞吐率的影响，基本可达到与物理专线所持平的零丢包率水平（带宽非瓶颈前提下）。而“墨西哥—昆明”的缺省Internet路由路径，在ADN网络的优化作用下，将其路由调整为“墨西哥—上海—昆明”，从而有效绕过了“墨西哥—昆明”之间缺省Internet物理路由的局部拥塞点，将丢包率从15%降到0，而“东京—北京”的缺省 Internet路径，也动态调整为“东京—郑州—北京”，从而将42%丢包率降低到0。 而通过ADN内部的多路径实时冗余能力、网络与华为云自建的物理HBN（华为骨干网络）之间多平面实时冗余的能力，以及ADN故障后切换到Internet的韧性保护的能力，更是进一步将华为云的广域连接可靠性、鲁棒性提升了1个数量级。 # 2. 网络弹性与敏捷能力方面，ADN通过云原生技术突破了传统广域网在物理设备及地理区域方面制约，使得网络拓扑变化及路由收敛从天级缩短到分钟级 ADN网络的接入及转发节点，可灵活部署在电信运营商城域网，被多租户共享接入；或者部署在企业内部网络，为单个租户提供独占服务；ADN通过基于CCE集群容器及IEF边缘容器部署模式，实现了分钟级的网络拓扑变更，以及转发节点容量的自动按需弹性伸缩；ADN的多目标线性规划的高性能路由算法，则支持分钟级的路由收敛及最优/次优路径选择。 # 3. 公有云结构化降成本方面，ADN通过将中心Region的EIP卸载到边缘站点及CDN，将公有云网络接入成本降低40%以上 通过将面向云服务、云主机、云容器的弹性IP从中心Region下沉到边缘节点，ADN使得云租户可从各运营商的城域网经由静态BGP就近接入到分布式边缘站点，再通过分布式边缘站点经由物理专线连接到主Region服务区的云服务、云主机、云容器实例，由于动态BGP与静态BGP在国内定价差价达近10倍，加之ADN接入节点与CDN共享上下行带宽，使得CDN非忙时阶段的闲置带宽资源得以更为充分的利用，从而进一步大幅降低了租户的总体弹性IP接入成本，使得公有云的网络接入总成本降低达40%以上。 # 展望 云原生ADN网络的未来，其对于华为云的意义将远不止于一张敏捷、弹性、智能的全球精品媒体网络，是公有云Internet接入降成本的手段，以及对自建光纤骨干网的补充。 随着ADN网络建设的日益完备，及其在云网协同方面的运营与运维数据的极大丰富与积累，必将推动其成长为华为分布式云原生架构的“大动脉”与“高速公路”, 使得跨越不同Region云服务区，跨越云边端、跨越遍布全球的华为云、伙伴云及HCS的统一资源调度与统一应用编排部署成为可能，从而有力地支撑 “**东数西算**”**国家新基建布局**，以及**华为云**“**全球一朵云**”、“**全球一张网**” 战略的达成。

XML 文档形成了一种树结构，它从"根部"开始，然后扩展到"枝叶"。一个 XML 文档实例XML 文档使用简单的具有自我描述性的语法：1234567<?xml version="1.0" encoding="UTF-8"?><note><to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body></note>第一行是 XML 声明。它定义 XML 的版本（1.0）和所使用的编码（UTF-8 : 万国码, 可显示各种语言）。下一行描述文档的根元素（像在说："本文档是一个便签"）：<note>接下来 4 行描述根的 4 个子元素（to, from, heading 以及 body）：1234<to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body>最后一行定义根元素的结尾：</note>您可以假设，从这个实例中，XML 文档包含了一张 Jani 写给 Tove 的便签。XML 具有出色的自我描述性，您同意吗？XML 文档形成一种树结构XML 文档必须包含根元素。该元素是所有其他元素的父元素。XML 文档中的元素形成了一棵文档树。这棵树从根部开始，并扩展到树的最底端。所有的元素都可以有子元素：12345<root><child><subchild>.....</subchild></child></root>父、子以及同胞等术语用于描述元素之间的关系。父元素拥有子元素。相同层级上的子元素成为同胞（兄弟或姐妹）。所有的元素都可以有文本内容和属性（类似 HTML 中）。实例：上图表示下面的 XML 中的一本书：XML定义：用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。XML发展史？简单提一下Markup Language历史：1969：GML（Generalized Markup Language）--(IBMResearch)1968: SGML（Standard Generalized Markup Language）--(ISO)1989：HTML（Hypertext Markup Language）--TimBerners Lee作为SGML的一个实例，它的DTD（一种规则）作为标准被固定下来，因此Html不能定义其他符号化语言的源语言。而XML就可以哦，所以就出现了XML。1998/2：XML（Extensible markup Language）W3C(World WideWeb Consortium)SGML的子集XML（定义数据和元数据），XSL（style sheet 描述，就像CSS于html）SGMLvsXMLvs HTML：SGML：长时间存放电子文件。      使用费用高，大都在MainFrame平台。XML：网页文件语言、数据交换语言、数据处理语言、文件整合语言。应用范围几乎没有限制。HTML：网页呈现语言、超文本语言。 XML包括：文件内容：结构定义：ＤＴＤ（Document TypeDefinitied）XMLSchema(DTD+Datatype)显示：XSLXSLT+XHTML+Xpath+（Xlink） 从html到XML：比较：HTML：html只能提供数据显示功能。浏览器提供单一语言机制。网页搜索不精确。扩充困难。网页逻辑关系，网页分级认证不易建立。web资源受限制，无法让其他应用使用。XML：开放平台。可以做任何程序的输入数据。XML改变了浏览器内部的结构。XML具体应用：XML的一个最主要的应用就是作为系统的配置文件，很多系统的配置文件都是用XML，Spring中application中XML，Hibernate中XML，在这里主要说说ASP.NET中的XML。1、配置文件中。 世间所有的相遇都是久别的重逢，我们曾建无数次的与XML擦肩而过，机房收费系统的配置文件，新闻发布系统的配置文件，以及我们建立每一个应用程序下的配置文件，配置文件的后缀名为.config，而我们的XML文件为.xml后缀，为什么vs中没有直接用Web.xml而是用的Web.config?我想可能是微软想把一个东西封装成知己的，就像箱子里是同样的苹果，我想变成我的，我就要弄好一个包装，并且贴上我的标签，告诉别人，这是我特有的。但事实上呢，网上有这样的回答：config是配置，.xml是软件内置的网页文件。表象：前者:用在web.config或者app.config之类.<appSettings>是系统约定的节点,约定在这个节点下的所有<add />节点会被System.Configuration.ConfigurationManager.AppSetting读到.后者:完全的自定义接点,appSettings表示什么意思,add表示什么意思将在自己写的xml解析方法里指定和使用.简单来说：简单来说,config是xml的一个子集。通常的xml都是只定义基本语法,至于节点的层次,节点格式,节点的含义,节点怎么被解析都是你自己定义.使得你的xml文件能和你的xml解析方法对应。而web.config,app.config这类,是Microsoft和软件作者已经定义好了节点意义，你只需要遵守他的格式和规则，就能达到配置作用。通俗讲：打个可能不太好的比方：xml文件本身是扑克牌.config是斗地主。你用config，就不需要自己制定规则，按照它的规则打就行。很方便，但是你不能违反他的规则。而你自己写xml，还要先制定好规则，规则怎么定都随便你，然后按照这个规则出牌.当然，这些都有一个大前提，都满足xml节点规范，你不能制定扑克牌的规则中放入几个麻将牌....2、ASP.NET控件与XML。在学习ASP.NET的视频的时候，用到很多控件，例如LIstBox，DropDownList常用控件，DataList，GridView等数据控件，ADO.NETDataSet操作XML文件，以及前两篇博客提到的导航控件menu和treeview在进行数据源绑定的时候都可以绑定XML文件。本文全面的初识了XML，让大家从各个方面了解到了XML的定义、XML的发展史、和html的比较等一些知识，希望对大家的学习有所帮助。实例中的根元素是 <bookstore>。文档中的所有 <book> 元素都被包含在 <bookstore> 中。<book> 元素有 4 个子元素：<title>、<author>、<year>、<price>。以上就是简单了解XML 树结构的详细内容

操作前提：获取OC,cloudscope登录信息获取oc域名和账号获取cloudscope域名和op_cdk_sso账号密码步骤一：找到虚拟机入口登录oc页面，选择ServiceOM，点击虚拟机步骤二：获取CDKmaster虚拟机IP在虚拟机页面搜索关键字EICommon-region-master获取到的虚拟机Ip即为CDK master节点ip地址{CDKMasterIP}，步骤三：在cdk中找到dwscontroller服务使用op_cdk_sso用户登录cloudscope页面1）运维服务-->auotodepoy-cdk2）进入HCS802服务管理-->服务升级，HCS03及以上 变更管理--》服务升级3）下拉条件：红色框起来的部分第一行的三个需要选择对应的region第二行：选择ei-dbs-xxx等ei开头的选择dws步骤四：获取Controller的mysql数据库连接信息db.urldb.username db.password在页面进入升级，在搜索框中搜索“db.”获取界面后台mysql数据库连接信息:db.password :获取db节点密码的密文，在步骤七使用AESTool.jar解密db.username :用户    db.driver:驱动，后面不用db.url:连接，获取ip，端口步骤五：登录步骤二获取的ip对应主机 虚拟机密码从华为云账号一览表获取 步骤六：登录运维容器在终端使用root用户登录cdk master节点后，执行以下命令可以进入dws-maintain容器：HCS 811以下：kubectl get pod -n dws-maintain   --查有两个容器，是负载集群，都可以登录kubectl exec -ti {pod name} bash -n dws-maintain    -- pod为查询的容器名HCS 811--HCS 821：kubectl get pod -n  ecf  --查有两个容器，是负载集群，都可以登录kubectl exec -ti {pod name} bash -n ecf    -- pod为查询的容器名cd opsTool    --cd到脚本目录下步骤七：解密步骤四获取的密码密文进入dws-maintain容器后，执行以下命令，解密dws密码：java -jar AESTool.jar2 { dbPasswordEncrypt}步骤八：执行connectTool.sh脚本登录节点进入dws-maintain容器后，可以执行以下命令登录dws实例节点，其中user字段在630及之前版本为root，在930及之后版本为ecf，若需要输入密码，则粘贴步骤七中密码即可：sh connectTool.sh -u{user} -drms -h{db ip} -p7306 -n {instance name} –tStandalone 参数说明：-u   用户名 对应db.username-d   数据库 对应db.url 中“jdbc:mariadb://170.75.4.205:7306/rms?autoReconnect=true”红色部分-h   连接ip  对应db.url 中“jdbc:mariadb://170.75.4.205:7306/rms?autoReconnect=true”红色部分 -p   端口   对应db.url 中“jdbc:mariadb://170.75.4.205:7306/rms?autoReconnect=true”红色部分-n   实例名称 对应mysql库中rds_instance.name       或者虚拟机—实例名     serviceOM 裸金属服务--》裸金属实例名称     oc资源监控---》数仓集群—》实例名称

1.1 Tomcat简介Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。1.2 物理机调优方法1.2.1 Tomcat参数调优目的：通过修改tomcat的配置文件，可以有效提高tomcat性能方法：按照如下所示信息，配置/home/apache-tomcat-9.0.20/conf/server.xml的各个参数。<Connector  executor="tomcatThreadPool"    port="10000" protocol="HTTP/1.1"    acceptCount="10000"    maxConnections="10000"    connectionTimeout="20000"    compression="off"    compressionMinSize="2048"    URIEncoding="utf-8"    tcpNoDelay="true"    enableLookups="false"    useURIValidationHack="false"    disableUploadTimeout="false"    connectionUploadTimeout="150000"    keepAliveTimeout="12000"    maxKeepAliveRequests="1000"redirectPort="8443" /> 1.2.2 Tomcat 亲和性设置Tomcat支持cpu绑核，利用cpu亲和性设置，可以使用taskset或numctl工具进行绑核操作方法：taskset -c N ./startup.sh或numactl -C N ./startup.shN表示要指定核的序号，例如 将tomcat进程绑定到0-3core上：taskset -c 0-3  ./startup.sh1.2.3 容器场景调优方法容器与物理机共享网口，在物理机上执行绑核脚本。以4core的http短连接场景的绑核脚本为例，脚本内容如下，如果要修改绑核脚本，只需修改要绑定的网口名eth1，以及要绑定的core，然后在关闭irqbalance.service的情况下使用脚本即可：#!/bin/bashcnt=2eth1=enp3s0ethtool -L $eth1 combined $cntirq1=`cat /proc/interrupts| grep -E ${eth1} | head -1 | awk -F ':' '{print $1}'`irq1=`echo $irq1`i=0while(( $i < 1))do    for cpunum in 2 3    do        echo $cpunum "->" $irq1        echo  $cpunum > /proc/irq/$irq1/smp_affinity_list        let "irq1++"    done   let "i++"done脚本中参数及命令说明参数及命令名称参数及命令解释cnt 网口队列数eth1使用的网口名irq1网口eth1对应的中断号cpunum分配给网口eth1用于处理网卡中断的核ethtool -L $eth1 combined $cnt设置网口队列长度为核数cat /proc/interrupts | grep $eth1 | awk -F ':' '{print $1}'查询网口中断数echo $cpunum > /proc/irq/$irq/smp_affinity_list根据中断号，将每个中断各绑定在一个核上此脚本只是容器场景下网卡调优方法1.3 虚拟机调优方法虚拟机采用网卡直通的模式，每个虚拟机配置一个虚拟网口，在虚拟机内部执行绑核脚本。以4core的http短连接场景的绑核脚本为例，脚本内容如下，若要修改绑核脚本，只需修改要绑定的网口eth1，以及要绑定的core，在关闭irqbalance.service的情况下使用脚本即可。#!/bin/bashcnt=2eth1=enp5s0ethtool -L $eth1 combined $cntirq1=`cat /proc/interrupts| grep -E ${eth1} | head -1 | awk -F ':' '{print $1}'`irq1=`echo $irq1`i=0while(( $i < 2))do    for cpunum in  3    do        echo $cpunum "->" $irq1        echo  $cpunum > /proc/irq/$irq1/smp_affinity_list        let "irq1++"    done  let "i++"done脚本中参数名称及解释参数名称参数解释cnt网口队列数eth1实际使用的网口名irq1网口eth1对应的中断号cpunum分配给网口eth1用于处理网卡中断的核此脚本只是虚拟机场景下的网卡调优，虚拟机场景下的亲和性设置与物理机一致.

1.简述登录DWS服务容器，首先登录COP--》CDK中EI集群的master节点，然后使用k8s命令登录对应的容器2.DWS管控面涉及的服务或容器有命名空间（namespace）为 dwsdms-collectiondms-monitoringdwscontroller命名空间（namespace）为 ecfdbseventdbsinsightDbsmonitorecfclustermanager命名空间（namespace）为 dws-maintaindwsmaintaintool3.登录管控面CDK集群Master节点步骤1 登录ManageOne运维面OC。步骤2 选择该Region的ServiceOM。步骤3 进入计算资源->虚拟机->搜索EICommon。找到EICommon-Region-Master-01机器的地址。步骤4 使用ssh登录opsadmin用户到该机器，并切换到root。root密码为统一密码表查到的。802的默认密码：x86：XXXXXarm：XXXX803的默认密码：XXXX4.登录运维容器密文解密，mysql登录，节点登录步骤1 使用root用户登录Master节点之后(参考（三）)，输入kubectl get pod –n dws-maintain。查看运维容器命名空间下的容器。步骤2 输入kubectl exec –ti {容器名} –n dws-maintain bash。进入容器。5.登录dwscontroller容器定位管控面问题查看服务日志步骤1 使用root用户登录Master节点之后，输入kubectl get pod –n dws。查看运维容器命名空间下的容器。选择dwscontroller前缀步骤2 输入kubectl exec –ti {容器名} –n dws bash。进入容器6.登录dms-monitoring，dms-collection容器定位监控面板问题查看日志步骤1 使用root用户登录Master节点之后，输入kubectl get pod –n dws。查看dws命名空间下的容器。选择dms-monitoring，dms-collection对应的前缀步骤2 输入kubectl exec –ti {容器名} –n dws bash。进入容器7.登录dbsevent，dbsinsight，dbsmonitor，ecfclustermanager容器   定位ecf集群，DWS集群状态，事件管理问题查看日志步骤1 使用root用户登录Master节点之后，输入kubectl get pod –n ecf。查看ecf命名空间下的容器。选择对应容器前缀步骤2 输入kubectl exec –ti {容器名} –n ecf bash。进入容器

## 一、K8S是什么？ ### 1.1 概述 K8S全名Kubernetes。因k与s之间有8个字符，故缩写为K8S。 K8S是一个可自动实施 Linux 容器管理的可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 ## 二、为什么需要K8S？ 要了解这个问题，需要回顾一下应用程序的部署方式。 ### 2.1 传统部署 传统部署直接在物理服务器上运行应用程序。存在缺陷： + 无法为服务器中的应用程序定义资源边界，导致资源分配出现问题（一个程序占用大部分资源，其它程序性能下降）。 + 若将应用程序运行在不同物理服务器上，一方面导致资源浪费，另一方面提高成本。 ### 2.2 虚拟化部署 虚拟化技术允许我们在单个的物理服务器上运行多个虚拟机（VM），应用程序在VM之间完全隔离。 每个VM是一个完整的计算机，在虚拟化硬件上运行包括自己的操作系统在内的所有组件。VM共享主机硬件资源。 但因为VM需要运行硬件虚拟副本和完整的操作系统副本，会占用大量的系统资源。 ### 2.3 容器部署 容器将应用程序软件代码和所需的所有组件打包在一起，使得容器内的用意可以在任何基础架构上一致的运行。 + **隔离性**：容器同样可以虚拟化基础计算机，应用程序可在不同容器间实现进程级隔离。 + **轻量性**：每个容器共享物理服务器的OS内核，二进制文件和库，但具有自己的文件系统、CPU、内存、进程空间等。这样的共享可以大大减少重现操作系统代码的需求。因此容器非常轻量，容量小且启动快。 + **可移植**：容器与基础架构分离，可以实现跨云和OS发行版本进行移植。 **K8S**即是在大规模服务器环境中，负责部署和管理容器组，用于解决容器的复制，扩展，健康，启动，负载均衡等问题。只需告诉 Kubernetes 您希望在哪里运行软件，该平台就会负责执行部署和管理容器所需的几乎一切工作。 ## 三、K8S有哪些组件？ 我们会在一组用于**运行容器化应用**的节点计算机（Node）的上部署K8S，这一组节点计算机即称为K8S集群。正常运行的K8S集群包含以下组件。 ### 3.1 集群相关术语 + **控制平面（Control Plane）：**控制 Kubernetes 节点的进程的集合。所有任务分配都来自于此。 + **节点（Node）：**这些机器负责执行由控制平面分配的请求任务。 + **容器集（Pod）：**部署到单个节点上且包含一个或多个容器的容器组。容器集是最小、最简单的 Kubernetes 对象。 + **服务（Service）：**一种将运行于一组容器集上的应用开放为网络服务的方法。它将工作定义与容器集分离。 + **卷（Volume）：**一个包含数据的目录，可供容器集内的容器访问。Kubernetes 卷与所在的容器集具有相同的生命周期。卷的生命周期要长于容器集内运行的所有容器的生命周期，并且在容器重新启动时会保留相应的数据。 + **命名空间（Namespace）：**一个虚拟集群。命名空间允许 Kubernetes 管理同一物理集群中的多个集群（针对多个团队或项目）。 ### 3.2 控制平面组件 控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件。控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会**在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器**。 + **kube-apiserver**：该组件开放 Kubernetes API。API服务器是K8S控制平面的前端。 + **etcd**：etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库 + **kube-scheduler**：该组件负责监视新创建的、为指定运行节点（node）的Pods,并选择节点让Pod在上面运行。 + **kube-controller-manager**：运行控制器进程的控制平面组件。多中控制器被编译到一个可执行文件，并在一个进程中进行运行。 + **cloud-controller-manager**：云控制器管理器是指嵌入特定云的控制逻辑的 [控制平面](https://kubernetes.io/zh/docs/reference/glossary/?all=true#term-control-plane)组件。 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 ### 3.3 Node组件 节点组件在每个节点上运行，维护运行的Pod并提供Kubernetes 运行环境。 + **Kubelet**：每个节点上运行的代理。它保证容器都运行在Pod中。 + **kube-proxy**：kube-proxy 是集群中每个节点上运行的网络代理， 实现 Kubernetes [服务（Service）](https://kubernetes.io/zh/docs/concepts/services-networking/service/) 概念的一部分。它维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。 ### 3.4 容器运行时 容器运行环境是负责运行容器的软件。支持包括像Docker，iSula以及任何实现k8s CRI的容器运行环境。 ### 3.5 其它可用插件 插件并非严格意义上的必须组件。仅列举以下常用的两种。 + **DNS：**几乎所有 Kubernetes 集群都应该有集群DNS。 + **Web界面**：Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。

hi， 大家好，如今几乎所有大厂都将容器和K8s列入未来的战略重心，K8s可能将成为下一代分布式操作系统，今天分享一篇很经典云原生文章（万字雄文），希望可以帮大家彻底了解到底什么是云原生。本文是一篇云原生的关键知识科普，希望给大家提供一扇云原生的“窗户”，传达三个目标：1、透过窗户看到一棵大树代表：云原生的蓝图全貌；2、树上会有很多核心树干代表：云原生的关键技术；3、希望树干上能摘到果实代表：云原生对我的启发。开始阅读文章前，请角色切换：设想你作为一位中小型 IT 公司 CTO，面对云原生技术决策，你需要回答两个问题：    1、为什么需要上云？    2、上云有何弊端？作为一家公司的技术决策者，必须理解上云的利与弊，并结合公司各阶段发展目标给出最适合的技术方案。    3、 云原生-概述    3.1 云原生-定义云原生的定义，业界也是“百家争鸣”各持观点，从技术视角理解云原生会相对清晰。云原生的关键技术包括：• 微服务架构：服务与服务之间通过高内聚低耦合的方式交互；• 容器：作为微服务的最佳载体，提供了一个自包含的打包方式；• 容器编排：解决了微服务在生产环境的部署问题；• 服务网络：作为基础设施，解决了服务之间的通信；• 不可变基础：设施提升发布效率，方便快速扩展；• 声明式 API:让系统更加健壮；命令式 API：可以直接发出让服务器执行的命令，例如：“运行容器”、”停止容器”等；声明式 API：可以声明期望的状态，系统将不断地调整实际状态，直到与期望状态保持一致。• DevOps：缩短研发周期，增加部署频率，更安全地方便：Culture ：达成共识Automation：基础设施自动化Measurement：可度量Sharing：你中有我，我中有你【私人观点】云原生的定义：应用因云而生，即云原生。应用原生被设计为在云上以最佳方式运行，充分发挥云的优势，是上云的最短路径。   3.2 云原生-技术生态   3.3 云原生-关键技术云原生关键技术包括：微服务，容器，容器编排，服务网络，不可变基础，声明式 API。   3.3.1 微服务微服务是一种用于构建应用的架构方案。将一个复杂的应用拆分成多个独立自治的服务，服务与服务间通过“高内聚低耦合”的形式交互。微服务典型架构包括：服务重构：单体改造成符合业务的微服务架构；服务注册与发现：微服务模块间的服务生命周期管理；服务网关：身份认证、路由服务、限流防刷、日志统计；服务通信：通信技术方案如，RPC vs REST vs 异步消息；可靠性：服务优雅降级，容灾，熔断，多副本。  3.3.2 容器容器是一种打包应用的方式，可以打包应用中的所有软件和软件所依赖的环境，并可实现跨平台部署。容器关键技术：namespac 视图隔离，cgroups 资源隔离 ，Union File System 联合文件系统。容器优势：更高效的利用资源；更快速的启动时间；一致性的运行环境。  3.3.3 容器编排容器编排包括：自动化管理和协调容器的系统，专注于容器的生命周期管理和调度。核心功能：容器调度：依据策略完成容器与母机绑定；资源管理：CPU、MEM、GPU、Ports、Device；服务管理：负载均衡、健康检查。  3.3.4 服务网格服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。Service Mesh 应对云原生应用的复杂服务拓扑，提供可靠的通信传递；通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，且对应用程序透明。Service Mesh 特点：应用程序间通讯的中间层；轻量级网络代理，应用程序无感知；解耦应用的重试、监控、追踪、服务发现。Service Mesh 主流组件：Istio、MOSN（Modular Open Smart Network）Linkerd。  3.3.5 不可变基础设施不可变基础设施（Immutable Infrastructure）（宠物 VS 牲畜）任何基础设施实例（服务器、容器等各种软硬件）一旦创建之后便成为一种只读状态，不可对其进行任何更改；如果需要修改或升级实例，唯一方式是创建一批新实例以替换。不可变基础设施的优势提升发布应用效率；没有雪花服务器；快速水平扩展。  3.3.6 声明式 API命令式 API：可直接发出让服务器执行的命令，例如：“运行容器”、“停止容器”等；声明式 API：可声明期望的状态，系统将不断地调整实际状态，直到与期望状态保持一致。为什么声明式使系统更加健壮？可以类比理解成自动化工程学的闭环自适应模型。  3.3.7 DevOpsDevOps 目标 ：缩短开发周期，增加部署频率，更可靠地发布。从历史上开发和运维相对孤立到开发和运维之间建立合作，可以增加信任，更快速地发布新版本。DevOps 是一组过程，方法和系统的统称包括：Culture：文化是 DevOps 中的第一成功要素。由于目标不同，开发和运维形成一堵墙，DevOps 通过建立开发和运维之间合作和沟通的文化来消除墙。Automation：自动化软件的开发和交付，通常包含持续集成，持续交付和持续部署，云原生时代还包括基础架构的自动化，即 IaC(Infrastructureas code)。Measurement：度量尤其重要，通过客观的测量来确定正在发生的事情的真实性，验证是否按预期进行改变。并为不同职能部门达成一致建立客观基础。Sharing：开发和运维团队之间长期存在摩擦的主要原因是缺乏共同的基础。开发参与运维值班，参与软件的部署和发布，运维参与架构设计。    4 容器-Docker   4.1 Docker 概述为什么学习容器技术?云时代从业者：Docker 已成云平台运行分布式、微服务化应用的行业标准。作为有技术追求的程序员，有必要理解云原生的关键技术：容器。Docker 核心概念：镜像、容器、仓库。镜像(Image)：一个只读模板；由一堆只读层（read-only layer）重叠；统一文件系统（UnionFileSystem）整合成统一视角。容器(Container)：通过镜像创建的相互隔离的运行实例；容器与镜像区别：最上面那一层可读可写层；运行态容器定义：一个可读写的统一文件系统，加上隔离的进程空间，以及包含在其中的应用进程。仓库（Repository）：集中存放镜像文件的地方；Docker Registry 可包含多个仓库（Repository），每个仓库可包含多个标签（Tag），每个标签对应一个镜像。   4.2 Docker 关键技术   4.2.1 Namespace 视图隔离Linux namespace 是一种内核级别的环境隔离机制，使得其中的进程好像拥有独立的系统环境。Network namespace 在 Linux 中创建相互隔离的网络视图，每个网络名字空间都有自己独立的网络配置，包括：网络设备、路由表、IPTables 规则，路由表、网络协议栈等。（默认操作是主机默认网络名字空间）  4.2.2 control groups（资源隔离）Linux Control Group 是内核用于限制进程组资源使用的功能。资源包括：CPU，内存，磁盘 IO 等。  4.2.3 Union File System（联合文件系统）Union File System， 联合文件系统：将多个不同位置的目录联合挂载(union mount)到同一个目录下。Docker 利用联合挂载能力，将容器镜像里的多层内容呈现为统一的 rootfs(根文件系统)；Rootfs 打包整个操作系统的文件和目录，是应用运行所需要的最完整的“依赖库”。   4.3 Docker-网络技术Bridge 模式：Docker0 充当网桥，在默认情况下，被限制在 Network Namespace 里的容器进程，是通过 Veth Pair 设备 +宿主机网桥的方式，实现跟同其他容器的数据交换。一旦一张虚拟网卡被“插”在网桥上，它就会变成该网桥的“从设备”。从设备会被“剥夺”调用网络协议栈处理数据包的资格，从而“降级”成为网桥上的一个端口。而这个端口唯一的作用，就是接收流入的数据包，然后把这些数据包全部交给对应的网桥，由网桥完成转发或者丢弃。Veth 提供一种连接两个 network namespace 的方法。Veth 是 Linux 中一种虚拟以太设备，总是成对出现常被称为 Veth pair。可以实现点对点的虚拟连接，可看成一条连接两张网卡的网线。一端网卡在容器的 Network Namespace 上，另一端网卡在宿主机 Network Namespace 上。任何一张网卡发送的数据包，都可以对端的网卡上收到。在物理网络中，如果需要连接多个主机，会用交换机。在 Linux 中，能够起到虚拟交换机作用的网络设备，是网桥（Bridge）。它是一个工作在数据链路层的设备，主要功能是根据 MAC 地址学习来将数据包转发到网桥的不同端口（Port）上。Bridge 网桥类似交换机，两个以上 namespace 接入同一个二层网络。veth pair 一端虚拟网卡加入到 namespace，另一端到网桥上。路由 routing是通过互联的网络把信息从源地址传输到目的地址的活动，发生在 OSI 模型的第三层（网络层）。Linux 内核提供 IPForwarding 功能，实现不同子网接口间转发 IP 数据包。路由器工作原理：路由器上有多个网络接口，每个网络接口处于不同的三层子网上。根据内部路由转发表将从一个网络接口中收到的数据包转发到另一个网络接口，实现不同三层子网间互通。    5 容器编排-Kubernetes   5.1 概述&架构&核心组件我认为 Kubernetes 最大成功：让容器应用进入大规模工业生产。Kubernetes 的提供特性，几乎覆盖一个分布式系统在生产环境运行的所有关键事项。包括：Automated rollouts and rollbacks(自动化上线和回滚)使用 Kubernetes 描述已部署容器的所需状态，受控的速率将实际状态更改为期望状态。Self-healing(自我修复)Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。Service discovery and load balancing(服务发现与负载均衡)Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而实现部署稳定。Storage orchestration(存储编排)Kubernetes 允许你自动挂载选择的存储系统，例如本地存储、公厂商等。Automatic bin packing(自动装箱)Kubernetes 允许指定每个容器所需 CPU 和内存（RAM）。当容器指定资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。Secret and configuration management(安全和配置管理)Kubernetes 允许存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。你可在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。API Service: Kubernetes 各组件通信中枢。资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；为 Pod， Deployment， Service 等各种对象提供 Restful 接口；与 etcd 交互的唯一组件。Scheduler：负责资源调度，按照预定调度策略将 Pod 调度到相应的机器。Predicates(断言)：淘汰制Priorities（优先级）：权重计算总分。Controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。etcd：分布式的 K-V 存储，独立于 Kubernetes 的开源组件。主要存储关键的原数据，支持水平扩容保障元数据的高可用性；基于Raft 算法实现强一致性，独特的watch 机制是 Kubernetes 设计的关键。kubelet ：负责维护 Pod 的生命周期，同时负责 Volume（CVI）和网络（CNI）的管理。kube-proxy：负责为 Service 提供 cluster 内部的服务发现和负载均衡kube-proxy 通过在节点上添加 iptables 规则以及从中移除这些规则来管理此端口重新映射过程。控制器模式的设计思想：容器类比集装箱，集装箱固然好用，但是如果它各面光秃秃的，吊车还怎么把它吊起来摆放好呢？Pod 对象其实就是容器的升级版，对容器进行组合，添加更多属性和字段。就好比在集装箱上安装了吊环，Kubernetes 这台“吊车”可以更轻松操作容器。然而Kubernetes 操作这些“集装箱”的逻辑都是由控制器完成的。Kubernetes 通过“控制器模式” 的设计思想，来统一编排各种对象和资源。   5.2 部署&资源控制&存储Kubernetes-集群部署架构所有组件通过 kubelet staticpod 的方式启动保证宿主机各组件的高可用，systemd 提供 kubelet 的高可用；每个 Master 的使用 hostNetwork 网络，controller-manager 和 scheduler 通过 localhost 连接到本节点 apiserver；controller-manager 和 scheduler 的高可用通过自身提供的 leader 选举功能（--leader-elect=true）；apiserver 高可用，可通过经典的 haporxy+keepalived 保证，集群对外暴露 VIP;外部访问通过 TLS 证书，在 LB 节点做 TLS Termination，LB 出来 http 请求到对应 apiserver 实例。apiserver 到 kubelet、kube-proxy 类似。    5.3 Kubernetes-网络技术     3.3.1 对外服务Service是一个逻辑概念，一组提供相同功能 Pods 的逻辑集合，并提供四层负载统一入口和定义访问策略。交互流程：Service 可通过标签选取后端服务。匹配标签的 Pod IP 和端口列表组成 endpoints，有 kube-proxy 负责均衡到对应 endpoint。为什么需要 service？对外提供入口（容器如何被外部访问）；克服 Pod 动态性（Pod IP 不一定可以稳定依赖）；服务发现和稳定的服务（ Pod 服务发现、负载、高可用）。Service Type 四种方式Cluster IP：配置 endpoint 列表；NodePort：默认端口范围：30000-32767，通过 nodeIP：nodePort 访问 ；LoadBalancer：适用于公有云，云厂商实现负载，配置 LoadBalance 到 podIP ；ExternalName：服务通过 DNS CNAME 记录方式转发到指定的域名。Service Type 为 Cluster IP：Kubernetes 的默认服务，配置 endpoint 列表，可以通过 proxy 模式来访问该对应服务；类似通过 Nginx 实现集群的 VIP。Service Type 为 Node Port：在集群所有节点上开放特定端口，任何发送到该端口流量借助 Service 的 Iptables 规则链发送到后端 Pod。注意事项：每个服务对应一个端口，端口范围只有 30000–32767；需要感知和发现节点变化，流量转发增加 SNAT 流程，Iptables 规则会成倍增长。适用场景：服务高可用性要求不高或成本不敏感，例如：样例服务或临时服务。Service Type 为 Load Balancer：对公网暴露服务建议采用此方式，Service 没有对其行为做任何规范，依赖云厂商 LB 具体实现（云厂商收费服务）如：腾讯公有云：CLB。Service Type 为 External Name ：DNS 作为服务发现机制，在集群内提供服务名到 Cluster IP 的解析。CoreDNS ：DNS 服务，CNCF 第 04 个毕业项目，KUBERNETES 的 1.11 版本已支持。CoreDNS 实现的高性能、插件式、易扩展的 DNS 服务端，支持自定义 DNS 记录及配置 upstream DNS Server，可以统一管理 Kubernetes 基于服务的内部 DNS。Ingress Controller：定义入流量规则，可做七层 HTTP 负载君合。Egress Controller：定义出流量规则。交互流程：通过与 Kubernetes API 交互，动态感知集群 Ingress 规则，按照自定义的规则生成（负载均衡器）配置文件，并通过 reload 来重新加载。   5.3.2 Underlay 与 Overlay 网络Underlay 网络模式: 底层承载网络，是网络通信的基础。优势：复用基建，网络扁平，性能优势；劣势：协作复杂，安全问题，管理成本。很多场景下业务方希望容器、物理机和虚拟机可以在同一个扁平面中直接通过 IP 进行通信，通过 Floating-IP 网络实现。Floating-IP 模式将宿主机网络同一网段的 IP 直接配置到容器中。这种模式为了保证容器与宿主机的交换机二层连通，需要在物理机上搭一个虚拟网桥。具体选择哪种网桥，主流有：Linux bridge、MacVlan、SRIOV 三种模式。BridgeBridge：设备内核最早实现的网桥，性能与 OVS 相当，可以使用到所有场景；MacVlan：一个简化版的 bridge 设备，为了隔离需要内核，实现时不允许 MacVlan 容器访问其宿主机 IP 和 ServiceCluster IP；SR-IOV 技术：一种基于硬件的虚拟化解决方案，可提高性能和可伸缩性；SR-IOV 标准允许在虚拟机之间高效共享 PCIe（快速外设组件互连）设备，并且它是在硬件中实现的，可以获得能够与本机性能媲美的 I/O 性能。Overlay 网络：是一种建立在另一网络之上的计算机网络。优势：独立自治，快速扩展，网络策略；劣势：复杂层级，性能损失，定制成本。Kubernetes 相当于云原生的操作系统。有人会问，凭什么云原生的操作系统这杆大旗？主要原因是：Kubernetes 解决了一个分布式操作系统最核心的计算、存储、网络三种资源。CNI 容器网络统一标准：CNCF 项目，为 Linux 容器提供配置网络接口的标准和以该标准扩展插件提供基础函数库；CNI 命令行调用规范，其插件在主机上直接切换进入容器网络命名空间，为容器创建网络设备，配置 IP，路由信息。CNI 规范内容：输入：ADD/DEL 控制指令，CNI 目录，容器 ID，网络命名空间，网卡名称。配置文件：标准部分：cniVersion，Name，Type，IPAM。输出：设备列表、IP 资源列表、DNS 信息。插件应用如：Bridge：Linux 网桥 CNI 实现，采用网卡对链接网桥和容器；Host-device：将主机设备直接移动到容器命名空间中；PTP：创建虚拟网卡对，采用路由方式实现对外互联；MacVlan：网卡多 Mac 地址虚拟技术完整支持 vlan；Vlan：Vlan 设备 CNI 实现，允许容器和主机分属不同 LAN；IPVlan：网卡上基于 IP 实现流量转发。   5.3.3 Overlay 网络-Flannel 方案CoreOS（被 Red Hat 收购）为 Kubernetes 专门定制设计的 overlay 网络方案。03 层网络方案实现：在每台主机部署 flanneld 进程实现网段分配，路由控制，采用多种转发机制实现流量跨机交互。Flannel 职责子网管理：每个主机分配唯一的子网；互联方式：为同 Overlay 平面容器分配唯一 IP。Etcd 存储：容器之间路由映射；SubNetManager：子网资源划分、IP 资源申请释放的接口定义；Backend：针对网络互联方式的接口定义。UDP，UDP 封包转发，建议仅调试使用；VxLAN(建议)，使用内核 vxlan 特性实现封包转发；Host-GW，主机 2 层互联情况下较高性能互联方式；IPIP，使用 IPIP 隧道完成封包和转发；IPSec，使用 IPSecurity 实现加密封包转发；AliVPC，对接阿里云 VPC 路由表实现网络互联；AWSVPC，对接 Amazon VPC 路由表实现网络互联。Flannel 的单机互联方案：子网分配：充当虚拟交换机/网关角色，连接所有本机容器，完成虚拟子网构建；Bridge：通过 NAT 借助主机网络实现外部服务访问；Veth pair：一端设置到容器网络 namespace，一端链接 bridge 实现容器接入网络；对外访问：为每个节点分配独立不冲突的 24 位子网。Overlay 解决方案：跨 Node 的 Pod 之间通信通过 Node 之间的 Overlay 隧道。职责：路由控制，数据转发。主要流程：本节点设置：设备创建、本地路由创建、回写本地信息；监听其他节点信息：更新 ARP 信息、更新 FDB、更新路由信息。   5.3.4 Overlay 网络-Calico 方案Calico 项目：是纯三层的虚拟网络解决方案，旨在简化、扩展和保护云网络的容器方案。Calico 优势：可扩展性：采用 IP 路由支持大规模网络。扩展便利，容错性高；网络安全：支持 Kubernetes 网络策略，支持自定义网络策略；广泛集成：集成 Kubernetes ，Mesos，支持 OpenStack，AWS，GCE，Azure。Calico 不足：BGP 支持问题：需要网路设备支持 BGP 协议，否则需要追加 IPIP 隧道；规划 2 层直连：需要节点做良好的规划实现 2 层网络直接互联；大规模配置复杂：网络规划，手动部署 Route Reflector，增加 API 代理。关键组件：BGP Client：和其他节点互联，发布当前节点路由并学习其他节点路由；Confd：同步节点配置信息启动 BGPClient；Felix：负责虚拟设备监控，ACL 控制、状态同步的 agent；Calico：CNI 插件，负责容器设备创建；Calico-IPAM：CNI 插件，负责容器网段管理与 IP 地址管理；RouteReflector：对接 BGPclient 实现路由中转；Etcd/Kube-apiserver：Calico 数据存储；typha：应对大规模节点接入时作为数据缓存 proxy；RouteReflector 安装：集群超过100 个节点时强烈建议启用，通过 RR 中转全局路由信息。Calico 单机互联方案：Veth-pair：一端设置到容器，一端放置在主机上，为容器提供网络出入口；路由策略：针对 IP 和设备设置路由条目，在主机上实现互联。Calico 跨机互联方案：同网段/BGP 支持：主机之间通过 2 层直连或者网络支持路由转发至目标主机；跨网段 IPIP 互联：网络设备不支持 BGP 协议情况下，采用 IPIP 隧道实现跨网段互联；跨网段 VxLAN 互联（Cannel）：集成 flannel，底层通过 VxLAN 实现跨机转发。*注：文章源自：https://blog.csdn.net/lianhunqianr1/article/details/118037321未完：一文带你理解云原生|云原生全景指南（下）———————————————————————————————————————————————【  AOC社区 】AOC (Agile Open Container)集成了华为网络云化平台，以及从网络运维中抽象总结出的业务框架，以Yang模型为基础，提供了对网络的开放可编程能力。社区为大家提供了关于数通网络开放可编程一站式学习、体验、认证、交流的平台。以视频为载体构建了在线学习AOC的整个学习、认证体系。另外还提供了SDK、demo样例、以及API手册、开发指导等文档的下载，方便大家进行新项目的开发。

获奖名单公布十年树木abcabc胡琦恭喜以上开发者，之前未填写获奖信息的开发者，请与11月5日16：00前完成获奖信息填写。为保证您顺利领取活动奖品，请您提前填写奖品收货信息，如您没有填写，视为放弃奖励。收货信息请【点击此处填写】活动奖励a. 奖励一：参与互动用户每人获得圆梦积分3分b. 奖励二：在所有参与互动用户中抽取3个幸运奖，奖品为《ModelArts人工智能应用开发指南》书籍1本。专家简介王泽锋华为云 云原生开源负责人华为云云原生开源负责人，Kubernetes社区Maintainer，KubeEdge和Volcano项目联合创始人，CNCF技术监督委员会贡献者。对云原生技术和开源生态有深入的见解。 直播简介     云原生已是大势所趋，但是对于企业客户而言，出于数据主权和安全隐私的考虑，企业客户会考虑使用多云混合云方式开展业务，然而不同云环境的基础设施能力、安全架构的差异会造成企业IT架构和运维体系的割裂，加大多云混合云实施的复杂性，提高了运维成本。华为云正式向CNCF捐赠Karmada项目，帮助企业构建多云混合云容器平台。 直播亮点1、了解业界云原生多云混合云的挑战和应对措施2、了解Karmada在多云混合云场景下的管理优势和核心特性原理3、了解如何参与Karmada社区项目 直播时间9月25日  11:00活动时间9月22日—10月7日互动方式直播前您可以在本帖留下您感兴趣的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流，我们会在全部活动结束后对参与互动的用户进行抽奖。活动规则本次活动结束后，将由华为云工作人员将符合抽奖条件的用户名单导入至巨公摇号平台（https://www.jugong.wang/random-portal/）内，抽取各奖项，并截屏公示抽奖过程。如您不同意此抽奖规则，请勿参加本次活动。 Tips1、请务必使用个人账号参与活动（IAM、企业账号等账号参与无效）。2、所有获得华为电子产品奖项的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。3、收货信息填写说明：1）为保证您顺利领取活动奖品，请您提前填写奖品收货信息，如您没有填写，视为放弃奖励。收货信息请【点击此处填写】2）填写时间截至2021年10月25日23:59。3）在HC2021开发者社区系列活动中完成一次填写即可。我们最终将会按照您填写的信息发放奖励。4、活动规则请戳https://bbs.huaweicloud.com/forum/thread-154048-1-1.html

通过Docker运行TensorFlow　　该方式的优点是不用操心软件依赖问题。方法　　首先，安装Docker，一旦Docker已经启动运行，可以通过命令启动一个容器:$ docker run -it b.gcr.io/tensorflow/tensorflow　　该命令将启动一个已经安装好的TensorFlow及相关依赖的容器。其它镜像 　　默认的 Docker 镜像只包含启动和运行 TensorFlow 所需依赖库的一个最小集. 我们额外提供了 下面的容器, 该容器同样可以通过上述 docker run 命令安装:　　b.gcr.io/tensorflow/tensorflow-full: 镜像中的 TensorFlow 是从源代码完整安装的, 包含了编译和运行 TensorFlow 所需的全部工具。　　在该镜像上, 可以直接使用源代码进行实验, 而不需要再安装上述的任何依赖.

活动时间：2021年9月16日~2021年10月20日 参与方式：完成下列实验，并在本帖中回复实验完成截图，即可视为完成任务，我们在活动结束后统一核对完成情况。 使用ModelArts实现花卉图像分类基于ModelArts JupyterLab在线调优钢筋检测基于IoT平台构建智慧路灯应用基于CCE进行云原生应用部署与运维管理基于容器实现一分钟自动化部署基于Spark实现车主驾驶行为分析MapReduce服务初体验使用华为云DevCloud实现20分钟一行代码上云基于DevCloud进行黑白棋实时对战游戏开发使用Python爬虫抓取图片和文字实验活动奖励：完成1个沙箱体验即可获得10积分（技能提升直通车中沙箱和微认证积分总和最高可获得100积分）活动规则：请严格按照实验要求体验，并回复沙箱实验截图Tips：1、请务必使用个人账号参与活动（IAM、企业账号等账号参与无效）。2、所有获得华为电子产品奖项的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。3、收货信息填写说明：1）为保证您顺利领取活动奖品，请您提前填写奖品收货信息，如您没有填写，视为放弃奖励。收货信息请【点击此处填写】2）填写时间截至2021年10月25日23:59。3）在HC2021开发者社区系列活动中完成一次填写即可。我们最终将会按照您填写的信息发放奖励。4、活动规则请戳https://bbs.huaweicloud.com/forum/thread-154048-1-1.html

Volcano是一个基于Kubernetes的云原生批量计算平台，也是CNCF的首个批量计算项目。Volcano 主要用于AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。它提供高性能计算任务调度，异构设备管理，任务运行时管理等能力。本篇文章将从Volcano架构、Volcano核心概念及功能、Volcano Code Tour、平台组件安装部署等方面来带大家认识Volcano。  Volcano架构 1、Volcano全景Volcano是基于Kubernetes的高性能批量计算平台，目前支持几乎所有的主流计算框架，包括MindSpore、TensorFlow、Kubeflow、MPI、PyTorch、飞浆、Spark、HOROVOD 等。Volcano支持的部分计算框架  计算框架遇到的问题：1）1:1的operator部署运维复杂2）不同框架对作业管理、并行计算等要求不同3）计算密集高，资源需求波动大，需要高级调度能力 Volcano面向主流计算框架提供：1）统一容器基础设施，提高资源利用率2）通用作业管理、队列Fair-share, Gang, bin-pack等高级调度算法3）简化运维管理 2、Volcano整体架构Volcano利用声明式的CRD定义我们的API，主要有3个核心的API，Volcano Job、PodGroup、Queue。Volcano Job 是对高性能任务的通用定义，PodGroup提供了Job中Task的管理能力，Queue 为任务的分类提供了基础。Volcano的架构 Volcano 核心组件主要包含三个：Admission、ControllerManager、Scheduler 。Admission对Volcano CRD API提供校验能力；ControllerManager负责对Volcano CRD进行资源管理;Scheduler对任务提供丰富的调度能力。 3、Volcano工作流程从零开始运行Volcano作业：1）用户创建一个 Volcano 作业2）Volcano Admission 拦截作业的创建请求，并进行合法性校验3）Kubernetes 持久化存储 Volcano Job 到 ETCD4）ControllerManager 通过 List-Watch 机制观察到Job 资源的创建，创建任务（Pod）5）Scheduler 负责任务的调度，绑定 Node6）Kubelet Watch 到 Pod的创建，接管 Pod 的运行7）ControllerManager 监控所有任务的运行状态，保证所有的任务在期望的状态下运行  Volcano核心概念及功能1、Volcano核心概念1）Queue：Queue的概念源于 Yarn，它是Cluster 级别的资源对象，可为其声明资源配额，也可由多namespace 共享，并且提供 soft isolation2）PodGroup：PodGroup是任务的分组，它与 queue 绑定，占用队列的资源。它与 Volcano Job 是一对一的关系；也可为其声明 Scheduling 条件3）Volcano Job：它是批量计算作业的定义，支持定义作业所属队列、生命周期策略、所包含的任务模板以及持久卷等信息 2、作业管理插件 svc：提供不同类型任务之间互访能力env：任务索引，例如 Tensorflow Worker indexssh：ssh 秘钥对创建及挂载，主要供 MPI 作业使用  3、Scheduler架构Scheduler支持动态配置和加载。 4、核心调度算法1）Gang Scheduling2）Fair Share3）Preempt & Reclaim4）Reserve & Backfill5）Topology Aware Scheduling6）GPU Sharing Volcano Code Tourcmd目录是Volcano所有组件启动的入口；config 是Volcano的配置；defs 是安装时的配置；docs 是Volcano的设计文档；example 提供了简单的例子，hack 提供安装时的脚本；installer 提供安装的模板。 pkg 是最重要的目录，里面包含了 api、controller、scheduler 、webhook 等代码。test 提供了e2e测试用例, vendor是依赖库。  安装部署1、Volcano InstallVolcano安装部署有多种方式：若已存在K8S集群，建议通过 Helm方式安装部署，该方式支持自定义安装配置；开发者建议通过Development Yaml方式部署。 对于开发者，Volcano已内置一键式安装部署脚本，路径为 volcano. sh/volcano/hack/local-up-volcano. sh。运行该脚本时，默认会使用kind创建 Docker in Docker的模拟集群，并安装部署Volcano。 2、Volcano 组件正确安装部署后，将生成4个组件，分别为：Volcano-admission、Volcano-admission-init、Volcano-controllers、 Volcano-scheduler ,其中admission-init以作业的方式生成证书。 

KubeEdge即Kube+Edge，顾名思义就是依托K8s的容器编排能力和调度能力，实现云边协同、计算下沉、海量设备的平滑接入。本篇文章将从KubeEdge架构设计理念、KubeEdge代码目录概览、KubeEdge集群部署三方面带大家认识KubeEdge。 KubeEdge架构设计理念 1、Kubernetes的架构这里是一个经典的K8s架构，K8s相信大家已经了解比较多了，它主要是分为控制面和数据面，而现在K8s的生态已经非常火爆了，关于应用管理和容器管理已经形成了一套标准，这里列举了它的一些优势：只有API server可以访问etcd组件通过 API Server 访问集群状态API采用声明式设计API对象彼此互补、可组合优先使用事件监听而不是轮询… 2、基于Kubernetes构建边缘计算的优势与痛点 核心优势主要有4方面： 容器化应用封装现在已经成为应用交付的一个趋势，我可以把我的应用打包到容器里，我只打包一次，可以跑在各种地方，这种如果应用到我们IOT领域，我们传统有很多IOT嵌入式设备，它其实很多硬件和软件强相关的，如果换一个硬件，可能软件就要更改，如果说我这个容器化封装以后，设备可支持容器runtime,我可以将容器跑在任何IOT设备上。通用应用抽象定义：K8s的API，包括development、pod现在其实在业内已经形成一套标准，大家都比较了解和认可，其实我们基于这些应用做这个平台，大家也更能容易接受。 松耦合架构：它的可扩展性比较好，比如我们基于K8s之上可以通过CRD来定义一些API，像我们通过设备管理CRD来定义一些IOT里device的一些API，到时候我们可以直接通过K8s的一些方式来管理这些设备；还有一些可扩展，比如它的CIA可以对接各种runtime,我们有些边缘节点它的资源非常有限，我们就可以对接一些轻量化的runtime。 其关键痛点有：1）资源有限网关设备，128MB内存K8s集群需要至少1G内存  2）网络不畅边缘位于私有网络，无公网IP云边跨越公网，带宽有限，延迟高K8s的List-watch需要数据中心网络  3）边缘如何离线自治网络不稳，随时可能离线边缘业务离线可工作边缘离线可故障恢复 4）设备接入和管理缺少边缘设备抽象缺少边缘设备接入协议支持  3、KubeEdge 架构与核心理念我们这个架构主要是分了云、边、端三部分，云上边就是我们的控制面，边就是我们的边缘节点，端就是跑了我们的一些端侧设备，云上左边是一个K8s的master，是没有做过改动的原生的K8s控制面，后边我们加了我们的一个组件叫CloudCore，它云上的组件主要是会拿一些K8s控制面上的东西，通过EdgeController和DeviceController做一些处理，然后通过下边的Cloud Hub，Cloud Hub主要是跟边端通信的，边端有个EdgeHub和Cloud Hub通信，然后把数据拿下来。边端是主要做了一个应用管理和设备管理的能力，应用管理左边会有一个Edged，右边有DeviceTwin、EventBus,分别是应用管理和设备管理，左边有个DataStore，就是我们说的本地自治的能力，比如说我们这应用或者设备的元素从云上分发下来，我们是先把它存到一个数据库里，然后再到它的Edged或者设备里边，这样就能保证云边网络断开或者边缘节点重启了以后我应用的Edged它可以从数据库里把应用源数据拿出来，这样就能保证在故障的情况下业务可以正常恢复。 核心理念：1）云边可靠协同双向多路复用消息通道，支持边缘节点位于私有网络Websocket + 消息封装，大幅减少通信压力，高时延下仍可正常工作云边消息校验，网络不稳定时不丢数据  2）边缘离线自治 节点元数据持久化，实现节点级离线自治节点故障恢复无需List-watch，降低网络压力，快速ready  3）边缘极致轻量重组Kubelet功能模块，极致轻量化（~70mb内存占用）支持CRI集成Containerd、CRI-O，优化runtime资源消耗  4）边缘设备管理云端通过Kubernetes API管理边缘Device 4、KubeEdge 社区生态KubeEdge致力于将Kubernetes的能力拓展到边缘业界首个边缘容器平台项目Apache 2.0协议2019年3月捐给CNCF基金会2020年9月晋级为孵化级托管项目K8s IoT Edge WG参考架构基于Kubernetes构建，100%兼容K8s API11个特性版本，最新版本为v1.6.0（截止2021年3月）3600+ Star，900+ Fork，550+贡献者目前成立3个社区SIG: SIG Device IoT、SIG MEC、SIG AI参与社区贡献的企业包括：中国联通，ARM，中国移动，谐云，中国电信，时速云，JD.com，浙大SEL实验室，EMQ，InfoBlox，Inovex，Midokura等  KubeEdge代码目录概览 ADOPTERS就是我们社区的一些采纳者,比如说你用了KubeEdge，并且想成为参与者，建议者，你可以提一个PR，把你们写到这个ADOPTER里面去，下面的这些就是代码目录，主要就是cloud（云端）、edge（边缘端）、mappers（接入设备的mapper端），还有OWNERS是我们项目的一些matiner，主要负责核代码，比如你对我们社区贡献比较多，我们可以把你加到OWNERS，帮我们核代码和检视代码。 KubeEdge集群部署1、KubeEdge 集群部署工具—— keadm这个是借鉴了K8s的Kubeadm，可以一键部署KubeEdge集群，在部署KubeEdge集群时，要先装一个K8s的master，这个master用任何符合K8s的标准都可以，这个 keadm是基于K8s之上部署KubeEdge系统。 子命令参数：init：部署云端组件join：部署边缘端组件gettoken：从云端获取边缘端启动凭据reset：重置KubeEdge集群的云端和边缘端 2、KubeEdge 部署 —— 云端在已经装好的master上装我们的云端，用 init即可：重要参数：--kube-config：连接K8s Master的凭据--advertise-address：签发到边缘证书里的IP地址 3、KubeEdge 部署 —— 边缘端边缘端主要用我们的join命令：重要参数：--token：边缘端启动时访问云端的凭据--cloudcore-ipport：边缘端访问的云端IP地址

随着云原生技术的普及，使用Kubernetes部署应用已经成为常态，越来越多的企业已经步入多集群时代。随着集群数量的增长，对集群的运维、管理带来了新的挑战：集群繁多的重复劳动：运维工程师需要应对繁琐的集群配置、不同云厂商集群间的管理差异以及碎片化的API访问入口等问题；业务过度分散的维护难题：应用在各集群的差异化配置繁琐；业务跨云访问以及集群间的应用同步难以管理。集群的边界限制：应用的可用性受限于集群；资源调度、弹性伸缩受限于集群。厂商绑定：业务部署的黏性问题，缺少自动化故障迁移；缺少中立的开源多云容器编排项目。 Karmada结合了华为云多云容器平台MCP以及Kubernetes Federation核心实践，并融入了众多新技术：包括Kubernetes原生API支持、多层级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务发现等，并且提供原生Kubernetes平滑演进路径，让基于Karmada的多云方案无缝融入云原生技术生态，为企业提供从单集群到多云架构的平滑演进方案。Karmada项目全景上图为Karmada在开源社区技术全景，区别于kubefed只做多集群应用分发的局限，Karmada将以模块化的方式提供应用多集群部署、高可用调度、故障迁移、多集群服务发现和流量治理、多云集群生命周期管理等能力集，并面向多种典型的用户场景预置策略集，让用户可以结合企业实际情况自由定制适合自身的多云平台。 2、Karmada关键1）Kubernetes 原生 API兼容既有应用配置及基础设施无需改造，由单集群架构平滑升级到多集群（多云）架构，无缝集成Kubernetes现有工具链生态2）开箱即用面向多场景的内置策略集，包括两地三中心、同城双活、异地容灾等支持应用的跨集群上的自动伸缩、故障迁移和负载均衡3）集中式管理提供地域无关的集中式集群管理支持公有云、私有云或边缘集群4）丰富的多集群调度策略多集群亲和性调度、应用跨集群拆分、资源重新平衡多维度多层次的高可用部署：区域/可用区/集群/供应商等5）开放中立由多家互联网、金融、制造业、电信、云服务厂商共同发起以 CNCF 的开放治理为目标 3、Karmada架构设计Karmada 控制平面由以下几个组件组成：API 服务器（Karmada API Server）控制管理器（Karmada Controller Manager ）调度器 (Karmada Scheduler)Karmada通过独立的API 服务器（Karmada API Server）提供与其他组件进行通信的 REST 接口，包含Kubernetes原生API及Karmada扩展API，而Karmada 控制管理器根据用户创建的 API 对象执行操作, Karmada 调度器则实现应用在多集群中的调度。Karmada 控制器运行各种控制器，控制器监视Karmada 的对象，然后与底层集群的 API 服务器通信，对Kubernetes资源进行全生命周期管理。集群控制器：聚焦集群管理，将 Kubernetes 集群附加到 Karmada，通过创建集群对象管理集群的生命周期。策略控制器：实现PropagationPolicy对象的生命周期。根据 PropagationPolicy中的resourceSelector 匹配对应Kubernetes资源对象，并为创建ResourceBinding以进行应用多集群调度。绑定控制器：实现 ResourceBinding 对象的生命周期，根据调度器的角度结果，为每个调度到目标集群的对应资源创建Work 对象；执行控制器：负责work对象与成员集群中实际资源对象的状态同步。 4、未来展望Karmada计划在今年Q4完成整体技术栈的能力开发，发布1.0版本，并捐赠CNCF。 小红书技术部负责人张雷表示：“小红书一直努力为云原生产业发展贡献自己的力量，希望通过Karmada项目，把小红书构建多云业务的实践经验贡献给社区，让更多企业能享受云原生技术的红利。”CNCF总经理Priyanka Sharma也对Karmada项目的开源作出了回应：“华为一直是云原生社区与开发者生态的重要参与者，此次发布的Karmada对所有企业构建多云业务架构至关重要，希望未来CNCF与华为云继续密切合作，持续帮助广大云原生开发者。” 未来，我们也希望越来越多的开发者能加入Karmada社区，共建多云生态！关于 Karmada 的更多技术细节，请查看项目仓库 https://github.com/karmada-io/karmada扫码添加小助手，发送“karmada”加群社区专家入驻，技术问题随时答疑