Kubernetes 是当前非常流行的容器编排框架，在其发展早期重点以微服务类应用为主。 但随着Kuberentes的用户越来越多，更多的用户希望在Kubernetes上运行BigData和AI框架，如Spark、TensorFlow等以构建统一的容器平台。但在Kubernetes运行这些高性能应用时，Kubernetes的默认调度器无法满足高性能应用的需求，例如：公平调度、优先级、队列等高级调度功能。由于Kubernetes的默认调度器是基于Pod进行调度，虽然在1.17中引入了调度框架，但仍无法满足高性能应用对作业级调度的需求。  针对云原生场景下的高性能应用场景，华为云容器团队推出了Volcano项目。Volcano是基于Kubernetes构建的一个通用批量计算系统，它弥补了Kubernetes在“高性能应用”方面的不足，支持TensorFlow、Spark、MindSpore等多个领域框架，帮助用户通过Kubernetes构建统一的容器平台。Volcano作为容器调度系统，不仅包括了作业调度，还包含了作业生命周期管理、多集群调度、命令行、数据管理、作业视图及硬件加速等功能。而在调度方面，Volcano 又对场景进行了细分、归类，并提供了相关的方案及算法；同时也为这些功能提供了调度框架，方便用户对调度器进行扩展。对于分布式计算或是并行计算来说，根据场景和作业属性的不同，也可以对其进行细分；在 《并行计算导论》 中将并行计算大致分为三类： 简单的并行简单的并行指多个子任务(tasks)之间没有通信也不需要同步，可以完全的并行的执行。比较著名的例子应该就属MapReduce了，它的两个阶段都属于这种类型：mapper任务在执行时并不会彼此通信同步运行状态；另一个常见的例子是蒙特·卡罗方法 ，各个子任务在计算随机数时也无需彼此通信、同步。由于这种并行计算有比较广泛的应用，例如 数据处理、VatR 等，针对不同的场景也产生了不同的调度框架，例如 Hadoop、DataSynapse 和 Symphony。同时，由于子任务之间无需信息和同步，当其中某几个计算节点(workers)被驱逐后，虽然作业的执行时间可能会变长，但整个作业仍可以顺利完成；而当计算节点增加时，作业的执行时间一般都会缩短。因此，这种作业也常常被称作 Elastic Job。 复杂的并行复杂的并行作业指多个子任务 (tasks) 之间需要同步信息来执行复杂的并行算法，单个子任务无法完成部分计算。最近比较有名的例子应该算是 Tensorflow 的 "ps-work模式" 和 ring all-reduce 了，各个子任务之间需要大量的数据交换和信息同步，单独的子任务无法独立完成。正是由于作业的这种属性，对作业调度平台也提出了相应的调度要求，比如 gang-scheduling、作业拓扑等。由于子任务之间需要彼此通信，因此作业在启动后无法动态扩展子任务，在没有checkpoint的情况下，任一子任务失败或驱逐，整个作业都需要重启，这种作业也常常被称作 Batch Job，传统的HPC场景多属于这种类型的并行作业，针对这种场景的调度平台为 Slurm/PBS/SGE/HTCondor 等。  流水线并行流水线并行是指作业的多个子任务之间存在依赖关系，但不需要前置任务完全结束后再开始后续的任务；比如 Hadoop 里有相应的研究：在 Map 没有完全结束的时候就部分开始 Reduce 阶段，从而提高任务的并行度，提高整体的运行性能。符合这种场景的应用相对来说比较少，一般都做为性能优化；因此没有针对这种场景的作业管理平台。需要区分一下工作流与流水线并行，工作流一般指作业之间的依赖关系，而流水线并行一般指作业内部多个任务之间的依赖。由于工作流中的作业差异比较大，很难提前开始后续步骤。 值得一提的是"二次调度"。由于简单并行的作业一般会有大量的子任务，而且每个子任务所需要的资源相对一致，子任务之间也没有通信和同步；使得资源的复用率相对比较高，因此二次调度在这种场景下能发挥比较大的作用；Hadoop的YARN，Symphony的EGO都属于这种类型。但是在面对复杂并行的作业时，二次调度就显得有也吃力；复杂并行作业一般并没有太多的子任务，子任务之间还经常需要同时启动，子任务之间的通信拓扑也可能不同 (e.g. ps/worker, mpi)，而且作业与作业之间对资源的需求差异较大，因此导致了资源的复用率较低。 虽然针对两种不同并行作业类型有不同的作业、资源管理平台，但是根本的目标都是为作业寻找最优的资源；因此，Volcano一直以支持以多种类型的作业为目标进行设计。目前，Volcano可以同时支持 Spark、TensorFlow和MPI等多种类型的作业。常见调度场景组调度 (Gang-scheduling)运行批处理作业（如Tensorflow/MPI）时，必须协调作业的所有任务才能一起启动；否则，将不会启动任何任务。如果有足够的资源并行运行作业的所有任务，则该作业将正确执行；但是，在大多数情况下，尤其是在prem环境中，情况并非如此。在最坏的情况下，由于死锁，所有作业都挂起。其中每个作业只成功启动了部分任务，并等待其余任务启动。  作业级的公平调度 (Job-based Fair-share)当运行多个弹性作业（如流媒体）时，需要公平地为每个作业分配资源，以满足多个作业竞争附加资源时的SLA/QoS要求。在最坏的情况下，单个作业可能会启动大量的pod资源利用率低， 从而阻止其他作业由于资源不足而运行。为了避免分配过小（例如，为每个作业启动一个Pod），弹性作业可以利用协同调度来定义应该启动的Pod的最小可用数量。超过指定的最小可用量的任何pod都将公平地与其他作业共享集群资源。 队列 (Queue)队列还广泛用于共享弹性工作负载和批处理工作负载的资源。队列的主要目的是：1）在不同的“租户”或资源池之间共享资源2）为不同的“租户”或资源池支持不同的调度策略或算法  这些功能可以通过层次队列进一步扩展，在层次队列中，项目被赋予额外的优先级，这将允许它们比队列中的其他项目“跳转”。在kube批处理中，队列被实现为集群范围的CRD。这允许将在不同命名空间中创建的作业放置在共享队列中。队列资源根据其队列配置（kube batch#590）按比例划分。当前不支持分层队列，但正在进行开发。 集群应该能够在不减慢任何操作的情况下处理队列中的大量作业。其他的HPC系统可以处理成百上千个作业的队列，并随着时间的推移缓慢地处理它们。如何与库伯内特斯达成这样的行为是一个悬而未决的问题。支持跨越多个集群的队列可能也很有用，在这种情况下，这是一个关于数据应该放在哪里以及etcd是否适合存储队列中的所有作业或pod的问题。 面向用户的, 跨队列的公平调度 (Namespace-based fair-share Cross Queue)在队列中，每个作业在调度循环期间有几乎相等的调度机会，这意味着拥有更多作业的用户有更大的机会安排他们的作业，这对其他用户不公平。例如，有一个队列包含少量资源，有10个pod属于UserA，1000个pod属于UserB。在这种情况下，UserA的pod被绑定到节点的概率较小。 为了平衡同一队列中用户之间的资源使用，需要更细粒度的策略。考虑到Kubernetes中的多用户模型，使用名称空间来区分不同的用户， 每个命名空间都将配置一个权重，作为控制其资源使用优先级的手段。 基于时间的公平调度 (Fairness over time)对于批处理工作负载，通常不要求在某个时间点公平地分配资源，而是要求在长期内公平地分配资源。例如，如果有用户提交大作业，则允许用户（或特定队列）在一定时间内使用整个集群的一半， 这是可以接受的，但在下一轮调度（可能是作业完成后数小时）中，应惩罚此用户（或队列）而不是其他用户（或队列）。在 HTCondor 中可以看到如何实现这种行为的好例子。 面向作业的优先级调度 (Job-based priority)Pod优先级/抢占在1.14版本中被中断，它有助于确保高优先级的pod在低优先级的pod之前绑定。不过，在job/podgroup级别的优先级上仍有一些工作要做，例如高优先级job/podgroup应该尝试以较低优先级抢占整个job/podgroup，而不是从不同job/podgroup抢占几个pod。 抢占 (Preemption & Reclaim)通过公平分享来支持借贷模型，一些作业/队列在空闲时会过度使用资源。但是，如果有任何进一步的资源请求，资源“所有者”将“收回”。资源可以在队列或作业之间共享：回收用于队列之间的资源平衡，抢占用于作业之间的资源平衡。 预留与回填 (Reservation & Backfill)当一个请求大量资源的“巨大”作业提交给kubernetes时，当有许多小作业在管道中时，该作业可能会饿死，并最终根据当前的调度策略/算法被杀死。为了避免饥饿， 应该有条件地为作业保留资源，例如超时。当资源被保留时，它们可能会处于空闲和未使用状态。为了提高资源利用率，调度程序将有条件地将“较小”作业回填到那些保留资源中。保留和回填都是根据插件的反馈触发的：volcano调度器提供了几个回调接口，供开发人员或用户决定哪些作业应该被填充或保留。  Volcano 调度框架Volcano调度器通过作业级的调度和多种插件机制来支持多种作业；Volcano的插件机制有效的支撑了针对不同场景算法的落地，从早期的gang-scheduling/co-scheduling，到后来各个级别的公平调度。下图展示了Volcano调度器的总体架构： Cache 缓存了集群中Node和Pod信息，并根据PodGroup的信息重新构建 Job (PodGroup) 和 Task (Pod) 的关系。由于在分布式系统中很难保证信息的同步，因此调度器经常以某一时间点的集群快照进行调度；并保证每个调度周期的决定是一致的。在每个调度周期中，Volcano 通过以下几个步骤派发作业： 1、在每个调度周期都会创建一个Session对象，用来存储当前调度周期的所需的数据，例如，Cache 的一个快照。当前的调度器中仅创建了一个Session，并由一个调度线程执行；后续将会根据需要创建多个Session，并为每个Session分配一个线程进行调度；并由Cache来解决调度冲突。 2、在每个调度周期中，会按顺序执行 OpenSession, 配置的多个动作(action)和CloseSession。在 OpenSession中用户可以注册自定义的插件，例如gang、 drf，这些插件为action提供了相应算法；多个action根据配置顺序执行，调用注册的插件进行调度；最后，CloseSession负责清理中间数据。action是第一级插件，定义了调度周期内需要的各个动作；默认提供 enqueue、allocate、 preempt和backfill四个action。以allocate为例，它定义了调度中资源分配过程：根据 plugin 的 JobOrderFn 对作业进行排序，根据NodeOrderFn对节点进行排序，检测节点上的资源是否满足，满足作业的分配要求(JobReady)后提交分配决定。由于action也是基于插件机制，因此用户可以重新定义自己的分配动作，例如 基于图的调度算法firmament。plugin是第二级插件，定义了action需要的各个算法；以drf插件为例，为了根据dominant resource进行作业排序，drf插件实现了 JobOrderFn函数。JobOrderFn函数根据 drf 计算每个作业的share值，share值较低代表当前作业分配的资源较少，因此会为其优先分配资源；drf插件还实现了EventHandler回调函数，当作业被分配或抢占资源后，调度器会通知drf插件来更新share值。  3、Cache 不仅提供了集群的快照，同时还提供了调度器与kube-apiserver的交互接口，调度器与kube-apiserver之间的通信也都通过Cache来完成，例如 Bind。 同时，为了支持上面这些场景，Volcano的调度器还增加了多个Pod状态以提高调度的性能:Pending: 当Pod被创建后就处于Pending状态，等待调度器对其进行调度；调度的主要目的也是为这些Pending的Pod寻找最优的资源Allocated: 当Pod被分配空闲资源，但是还没有向kube-apiserver发送调度决策时，Pod处于Allocated状态。Allocated状态仅存在于调度周期内部，用于记录Pod和资源分配情况。当作业满足启动条件时 (e.g. 满足minMember)，会向kube-apiserver提交调度决策。如果本轮调度周期内无法提交调度决策，由状态会回滚为Pending状态 Pipelined: 该状态与Allocated状态相似，区别在于处于该状态的Pod分配到的资源为正在被释放的资源 (Releasing)。该状态主要用于等待被抢占的资源释放。该状态是调度周期中的状态，不会更新到kube-apiserver以减少通信，节省kube-apiserver的qps。Binding: 当作业满足启动条件时，调度器会向kube-apiserver提交调度决策，在kube-apiserver返回最终状态之前，Pod一直处于Binding状态。该状态也保存在调度器的Cache之中，因此跨调度周期有效。Bound: 当作业的调度决策在kube-apiserver确认后，该Pod即为Bound状态。Releasing: Pod等待被删除时即为Releasing状态。Running, Failed, Succeeded, Unknown: 与Pod的现有含义一致。  状态之间根据不同的操作进行转换，见下图。 Pod的这些状态为调度器提供了更多优化的可能。例如，当进行Pod驱逐时，驱逐在Binding和Bound状态的Pod要比较驱逐Running状态的Pod的代价要小 (思考：还有其它状态的Pod可以驱逐吗？)；并且状态都是记录在Volcano调度内部，减少了与kube-apiserver的通信。但目前Volcano调度器仅使用了状态的部分功能，比如现在的preemption/reclaim仅会驱逐Running状态下的Pod；这主要是由于分布式系统中很难做到完全的状态同步，在驱逐Binding和Bound状态的Pod会有很多的状态竞争。  Volcano调度实现Volcano调度器在支持上面这些主要场景时，分别使用了action和plugin两级插件。 总体来讲，带有动作属性的功能，一般需要引入 action 插件；带有选择 (包括排序) 属性的功能，一般使用 plugin 插件。因此，这些常见场景中，fair-sharing、queue、co-scheduling都通过plugin机制来实现：都带有选择属性，比如“哪些作业应该被优先调度”；而preemption、reclaim、backfill、reserve 则通过 action 机制来实现：都带有动作属性，比如“作业A 抢占 作业B”。 这里需要注意的是，action 与 plugin 一定是一同工作的；fair-sharing 这些 plugin 是借助 allocate 发展作用，而 preemption 在创建新的 action 后，同样需要 plugin 来选择哪些作业应该被抢占。 通过job-based fairness (DRF) 和 preempt 两个功能的实现来介绍action 和 plugin 两种插件机制的使用，其它功能类似：Job-based Fairness (DRF): 目前的公平调度是基于DRF，并通过 plugin 插件来实现。在 OpenSession 中会先计算每个作业的 dominant resource和每个作业share的初始值；然后注册 JobOrderFn回调函数，JobOrderFn 中接收两个作业对象，并根据对像的 dominant resource 的 share值对作业进行排序；同时注册EventHandler, 当Pod被分配或抢占资源时，drf根据相应的作业及资源信息动态更新share值。其它插件的实现方案也基本相似，在OpenSession中注册相应的回调，例如 JobOrderFn, TaskOrderFn，调度器会根据回调函数的结果决定如何分配资源，并通过EventHandler来更新插件内的调度数。Preemption: preempt是在allocate之后的一个action，它会为“高”优先级的Pending作业选取一个或多个“低”优先级的作业进行驱逐。由于抢占的动作与分配的动作不一致，因此新创建了preempt action来处理相应的逻辑；同时，在选取高低优先级的作业时，preempt action还是依赖相应的plugin插件来实现。其它动作插件的实现方式也类似，即根据需要创建整体的流程；将带有选择属性的问题转换为算法插件。深入了解VolcanoVolcano官网：https://volcano.shGithub : https://github.com/volcano-sh/volcano

基于容器和无服务器平台的云原生应用在正在快速地被全球的组织所部署。虽然说云原生应用会带来易延展性、无与伦比的韧性、以及快捷的开发速度，云原生应用同样会带来挑战。云原生应用会有大量的可移动成分，并且基于那些短暂的架构组件。这就会给运营和维护产生难度;除此以外，自然还有安全隐患。云原生安全需要新的解决思路、策略和工具。这里，有五个可以帮助改善企业云原生安全的小建议。什么是云原生?云原生应用为云而创建，而且整个软件开发生命周期——开发、部署、测试和升级，都会在云环境完成。“云”的概念不局限于公有云，也可以意味着远程和本地资源都有的混合云或者超过一个云供应商的多云环境。云原生计算基金会(CNCF)认为三种工具应该用于云原生计算中：容器化、微服务结构和动态编排。容器化意味着软件和其关联依赖绑定，从而实现软件可移动、可扩展;动态编排包括了使用Kubernetes等工具管理云端容器;而微服务结构能够优化资源。容器能够被另一项云原生计算能力——无服务器功能所替代。云原生的安全挑战云原生应用给基础设施和应用安全带来了额外挑战。以下是一些关键挑战：多个需要保护的实体：DevOps团队和基础设施团队会使用微服务来运行云原生应用。在过去，多个进程或者软件功能会在一个虚拟机上运行。现在，每个进程或者能力都会被包装成分离的容器或者无服务器功能。每个实体都易于被攻破，因此需要全开发周期的防护。多样的结构：云原生系统会涉及很多公有云和私有云、云服务、以及应用结构。每个结构都有不同的隐患和安全需求。安全团队必须理解这一复杂的攻击面，并且为每个不同的结构找到解决方案。不断变化的环境：公有云和私有云环境在持续变化。快速的软件发布周期意味着微服务应用的每个组件都必须每日进行升级。另外，使用不可变性和基础设施即代码意味着应用会被持续分解并重构。安全团队会发现很难在不减缓发布周期的情况下，保护这些技术应用。如何保护云原生应用有多种保护云原生应用的方式，包括：安全左移、在函数和容器级别应用边界安全、贯彻最小角色和最低权限、保护应用依赖，以及安全共责。1. 安全左移许多企业依然在使用已有的工具，却无法处理云原生应用环境的速度、规模和动态网络。如果再加上无服务器功能，会让整个基础设施变得更抽象，让问题更严重。网络攻击者会寻找容器和无服务器代码中的隐患，以及云基础设施中的错误配置，以接入包含敏感信息的实体，再用它们提升权限，攻击其他实体。另一个问题是企业在用CI/CD工具持续开发、测试和发布应用。当使用容器部署云原生应用的时候，开发者会从本地或者公共库当中获取镜像，但一般不会检查这些镜像是否包含安全隐患。一种解决方案是给安全团队提供一些工具，阻止不受信任的镜像进入CI/CD管道，以及启用一些机制让不受信任的镜像在进入生产前就避免产生安全问题。通过在开发流程早期扫描镜像的漏洞、恶意软件成分等，开发者可以贯彻安全标准。2. 在函数和容器级别应用边界安全在无服务器应用中，系统会被分解成几个能从不同资源接受项目触发的可调用组件。这就给了攻击者更大的攻击选择，以及更多实施恶意行为的途径。一个很重要的方式是使用为云原生环境而制作的API和应用安全工具。除此以外，一个很普遍的操作是在功能级别使用边界安全——识别功能是否被一个和平时不同的来源所触发，然后监控事件触发中存在的异常情况。在容器化环境里，一个重要点是在不同级别都要实现安全——编排控制面板、物理主机、pod和容器。编排的一些最佳安全实践包括节点隔离、限制和监测容器之间的流量、以及对API服务器使用第三方认证机制。3. 最小角色与最低权限云原生资源之间会有大量频繁的交互。如果能够对每个无服务器功能或者容易都能配置一些独特的许可，就能有极大概率提升安全性。可以通过基于每个函数使用IAM，或者对容器进行颗粒度的许可，加强接入控制。花一点时间创建最小角色，或者为每个函数或容器创建一系列的许可。这就确保了即使云原生结构中有一个点失陷，其造成的危害也是最小的，并且会防止其他元件产生提权问题。4. 保护应用依赖无服务器函数和应用的代码经常从npm或者PyPI的库中获取有依赖关系的包。为了保护应用的依赖，就需要包括完整开源组件以及其漏洞数据库的自动化工具。同样，还需要能够在开发流程中触发安全行为的云原生编排工具。通过持续运作这些工具，就可以防范产线上运行的有隐患的代码包或者容器。5. 安全共责在开发者、DevOps和安全团队之间建立亲密的关系。开发者并不是安全专家，但他们可以被教导安全操作知识，从而确保他们可以安全地编写代码。安全团队应该知道应用是如何开发、测试和部署的，还有哪些工具在流程中被使用，从而安全团队能够在这些流程中有效地加入安全元素。云原生要求各种企业管理安全和开发的方式，因此尽快让不同团队减少隔阂至关重要。云原生的启用对企业来说是一个形成合作和共享文化的罕见契机。结论这篇文章提及了云原生面临的挑战，包括大量需要保护的实体，以及持续变化的环境和结构。同样，也给出了五个能够改善云原生环境的最佳实践：安全左移，在问题进入产线前进行规避。在函数和容器级别应用边界安全。对云原生应用中的实体实行最小角色和最低权限。保护好应用依赖。鼓励开发、运营和安全团队之间的安全共责。点评业务节奏加快使得无服务器应用等云原生应用会越来越多被企业所启用，云原生的安全也会更多被注意。不难发现，本文提到的五个安全建议中，软件安全相关的建议占了大部分：无论是安全左移、应用依赖的防护、还是实现DevSecOps整个安全协同，最终都离不开开发安全相关。这一点来看，DevSecOps和API安全的重要性都会随着云原生的使用进一步地提升。来源：https://netsecurity.51cto.com/art/202108/677745.htm

【功能模块】容器模块【操作步骤&问题现象】1、主机把按要求添加映射，保存重启，但LTE0映射不进去容器2、本来主机有LTE0映射之后主机的LTE0也没了，关机等一段时间重新启动，主机的LTE0就有了【截图信息】【日志信息】（可选，上传日志内容或者附件）

对象定义你可以使用字符来定义和创建 JavaScript 对象:实例var person = {firstName:"John", lastName:"Doe", age:50, eyeColor:"blue"};定义 JavaScript 对象可以跨越多行，空格跟换行不是必须的：实例var person = {    firstName:"John",    lastName:"Doe",    age:50,    eyeColor:"blue"};对象属性可以说 "JavaScript 对象是变量的容器"。但是，我们通常认为 "JavaScript 对象是键值对的容器"。键值对通常写法为 name : value (键与值以冒号分割)。键值对在 JavaScript 对象通常称为 对象属性。Note    JavaScript 对象是属性变量的容器。对象键值对的写法类似于：PHP 中的关联数组Python 中的字典C 语言中的哈希表Java 中的哈希映射Ruby 和 Perl 中的哈希表访问对象属性你可以通过两种方式访问对象属性:实例 1person.lastName;实例 2person["lastName"];对象方法对象的方法定义了一个函数，并作为对象的属性存储。对象方法通过添加 () 调用 (作为一个函数)。该实例访问了 person 对象的 fullName() 方法:实例name = person.fullName();如果你要访问 person 对象的 fullName 属性，它将作为一个定义函数的字符串返回：实例name = person.fullName; Note    JavaScript 对象是属性和方法的容器。在随后的教程中你将学习到更多关于函数，属性和方法的知识。访问对象方法你可以使用以下语法创建对象方法：methodName : function() {    // 代码 }你可以使用以下语法访问对象方法：实例objectName.methodName()通常 fullName() 是作为 person 对象的一个方法， fullName 是作为一个属性。如果使用 fullName 属性，不添加 (), 它会返回函数的定义：实例objectName.methodName

在NFS的基础之上，为了简便运维与管理，增加了持久卷的概念。PersistentVolume（PV）：对存储资源创建和使用的抽象，使得存储作为集群中的资源管理PersistentVolumeClaim（PVC）：让用户不需要关心具体的Volume实现细节。注：图片截取自李振良老师的视频课程上图是PV、PVC的使用逻辑，通俗的理解：一个企业雇一帮人工作（nfs)，选个小组长(pv),再来个团队长（pvc），这样消费者就不会直接面对生产者，企业好管理，用户的服务也有保证。其实就是软件世界的官僚机构~PV使用方式：静态供给，需要K8s运维工程师提前创建一堆PV，供开发者使用。示例：[root@k8s-node2 /]# cat pv.yamlapiVersion: v1kind: PersistentVolumemetadata:  name: my-pvspec:  capacity:    storage: 5Gi  accessModes:    - ReadWriteMany  nfs:    path: /ifs/kubernetes    server: 192.168.0.21[root@k8s-node2 /]# cat deployment-pvc.yamlkind: DeploymentapiVersion: apps/v1metadata:  name: deployment-pvcspec:  selector:    matchLabels:      app: nginx-pvc  replicas: 2  template:    metadata:     labels:      app: nginx-pvc    spec:      containers:      - name: nginx        image: nginx        volumeMounts:         - name: wwwroot           mountPath: /usr/share/nginx/html        ports:        - containerPort: 80      volumes:       - name: wwwroot         persistentVolumeClaim:           claimName: my-pvc---apiVersion: v1kind: PersistentVolumeClaimmetadata:  name: my-pvcspec:  accessModes:   - ReadWriteMany  resources:   requests:    storage: 5Gi[root@k8s-node2 /]# 容器应用和卷需求模板写在了一个depolyment-pvc.yaml中，数据卷的定义写在了pv.yaml中。root@k8s-node2 /]# kubectl apply -f deployment-pvc.yamldeployment.apps/deployment-pvc createdpersistentvolumeclaim/my-pvc created[root@k8s-node2 /]# kubectl get pod -o wideNAME                              READY   STATUS    RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATESdeployment-pvc-84df7c6f46-b98wx   1/1     Running   0          55m   10.244.169.144   k8s-node2   <none>           <none>deployment-pvc-84df7c6f46-d787b   1/1     Running   0          55m   10.244.169.143   k8s-node2   <none>           <none>nginx-6799fc88d8-z76rk            1/1     Running   2          45h   10.244.169.142   k8s-node2   <none>           <none>[root@k8s-node2 /]# curl 10.244.169.144hello  //上一个实验中的index.html文件[root@k8s-node2 /]# cd ifs[root@k8s-node2 ifs]# cd kubernetes[root@k8s-node2 kubernetes]# echo hello world>index.html[root@k8s-node2 kubernetes]# curl 10.244.169.144    hello world[root@k8s-node2 kubernetes]#

　　最近复习了一遍Spring IOC容器的初始化过程，结合书籍《Spring源码深度解析》总结了一下，IOC容器的初始化过程，大概分为以下三点：1、定位资源：　　定位相关的配置文件，扫描相关注解2、加载资源：　　将配置信息加载到内存中3、注册：　　根据载入的配置信息，初始化对象，并将其装载至容器中POM文件<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.example</groupId> <artifactId>springTest</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <!-- https://mvnrepository.com/artifact/org.springframework/spring-context --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.0.2.RELEASE</version> </dependency> </dependencies> </project>测试代码public class ServiceB { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); Object serviceA = context.getBean("serviceA"); System.out.println(serviceA); }xml配置<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:cache="http://www.springframework.org/schema/cache" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd"> <context:component-scan base-package="com.donkeys.spring"/> <bean id="serviceA" class="com.donkeys.spring.service.ServiceA"></bean> </beans>ClassPathXmlApplicationContext构造方法 public ClassPathXmlApplicationContext( String[] configLocations, boolean refresh, @Nullable ApplicationContext parent) throws BeansException { super(parent); //根据传入的配置文件名称，调用父类的setConfigLocations方法，解析配置文件路径, setConfigLocations(configLocations); //refresh = true //refresh() 方法会重启整个容器 if (refresh) { refresh(); } }　　构造方法中一共做了2件事，首先是设置配置文件的路径，然后对整个容器进行刷新。　　这里我们重点关注refresh()方法；进入refresh()方法AbstractApplicationContext类的refresh()方法@Override public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // Prepare this context for refreshing. //为刷新前做准备 prepareRefresh(); // Tell the subclass to refresh the internal bean factory. //获取IOC容器，这里就是处理资源定位以配置文件加载/注册的方法 ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // Prepare the bean factory for use in this context. prepareBeanFactory(beanFactory); try { // Allows post-processing of the bean factory in context subclasses. postProcessBeanFactory(beanFactory); // Invoke factory processors registered as beans in the context. invokeBeanFactoryPostProcessors(beanFactory); // Register bean processors that intercept bean creation. registerBeanPostProcessors(beanFactory); // Initialize message source for this context. initMessageSource(); // Initialize event multicaster for this context. initApplicationEventMulticaster(); // Initialize other special beans in specific context subclasses. onRefresh(); // Check for listener beans and register them. registerListeners(); // Instantiate all remaining (non-lazy-init) singletons. finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. finishRefresh(); } catch (BeansException ex) { if (logger.isWarnEnabled()) { logger.warn("Exception encountered during context initialization - " + "cancelling refresh attempt: " + ex); } // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } finally { // Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); } } }　　这里主要关注**obtainFreshBeanFactory()**方法/** * Tell the subclass to refresh the internal bean factory. * @return the fresh BeanFactory instance * @see #refreshBeanFactory() * @see #getBeanFactory() */ protected ConfigurableListableBeanFactory obtainFreshBeanFactory() { //刷新IOC容器 //这里使用了委派设计模式，父类定义了抽象的refreshBeanFactory方法，具体调用实现调用子类的refreshBeanFactory方法 refreshBeanFactory(); //获取一个新的容器 ConfigurableListableBeanFactory beanFactory = getBeanFactory(); if (logger.isDebugEnabled()) { logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory); } return beanFactory; }　　**obtainFreshBeanFactory()**方法总共干了2件事，　　重置容器，refreshBeanFactory()方法中会设置相关标志，清除旧的容器，同时为Spring上下文生成一个新的容器，获取一个新的容器AbstractRefreshableApplicationContext的refreshBeanFactory()方法　　下面我们进入**refreshBeanFactory()**方法/** * This implementation performs an actual refresh of this context's underlying * bean factory, shutting down the previous bean factory (if any) and * initializing a fresh bean factory for the next phase of the context's lifecycle. * 该方法会将之前的bean工厂全部关闭，并初始化一个全新的bean 工厂类 用于Spring 上下文的生命周期 * bean工厂就是IOC容器 */ @Override protected final void refreshBeanFactory() throws BeansException { //判断是否之前也有容器 //如果有就销毁掉 if (hasBeanFactory()) { destroyBeans(); closeBeanFactory(); } try { //创建一个新的工厂 DefaultListableBeanFactory beanFactory = createBeanFactory(); beanFactory.setSerializationId(getId()); customizeBeanFactory(beanFactory); //读取Bean对象的定义 //这里也是使用的委派设计模式 loadBeanDefinitions(beanFactory); synchronized (this.beanFactoryMonitor) { this.beanFactory = beanFactory; } } catch (IOException ex) { throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex); } }　　这里创建了新的容器工厂，同时将新的工厂传入了loadBeanDefinitions()方法中，下面来看一下在loadBeanDefinitions方法中具体做了什么操作。AbstractXmlApplicationContext的 loadBeanDefinitions(DefaultListableBeanFactory beanFactory)方法　　在AbstractRefreshableApplicationContext类的refreshBeanFactory方法中，调用了loadBeanDefinitions方法，但是这个方法它的一个抽象方法，具体实现应由子类去实现，我们在程序启动时，使用的ClassPathXmlApplicationContext类。根据文章开头的类图可以知道，这里会调用子类AbstractXmlApplicationContext的loadBeanDefinitions方法去完成本次加载@Override protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException { // Create a new XmlBeanDefinitionReader for the given BeanFactory. //使用默认的beanFactory去创建 XmlBeanDefinitionReader XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory); // Configure the bean definition reader with this context's // resource loading environment. //设置资源的加载环境 beanDefinitionReader.setEnvironment(this.getEnvironment()); //设置资源读取器 beanDefinitionReader.setResourceLoader(this); //设置实体解析器 beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this)); // Allow a subclass to provide custom initialization of the reader, // then proceed with actually loading the bean definitions. //初始化 bean对象定义读取器 initBeanDefinitionReader(beanDefinitionReader); //使用初始化完成的读取器，调用loadBeanDefinitions方法 loadBeanDefinitions(beanDefinitionReader); }　　总的来说，这里只干了一件事，那就是初始化配置//设置资源读取器 beanDefinitionReader.setResourceLoader(this); //初始化 bean对象定义读取器 initBeanDefinitionReader(beanDefinitionReader);　　设置资源读取器，这里设置的资源读取器就是当前这个对象本身　　通过类图我们可以发现我们这个类的顶级父类ApplicationContext，继承自DefaultResourceLoader这个类，该类实现了ResourceLoader接口，说明这个类的实例化对象本身是具有资源读取器的功能的　　初始化bean对象定义读取器，这里设置xml文件的校验方式　　下面我们继续看**loadBeanDefinitions(XmlBeanDefinitionReader reader)**方法protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException { //从子类对象中获取到资源定位 Resource[] configResources = getConfigResources(); if (configResources != null) { //XmlBeanDefinitionReader 读取器调用其父类的 reader.loadBeanDefinitions(configResources); } String[] configLocations = getConfigLocations(); if (configLocations != null) { reader.loadBeanDefinitions(configLocations); } }　　先看这一行//这行代码的具体实现是由子类完成的，通过类图可以知道AbstractXmlApplicationContext的子类为ClassPathXmlApplicationContext //这里主要将我们最开始在构造方法中设置好的配置文件进行返回 Resource[] configResources = getConfigResources();　　再看这一行//如果返回的配置文件不为空，就将返回的已经封装好的资源文件进行读取， if (configResources != null) { //XmlBeanDefinitionReader 读取器调用其父类的 reader.loadBeanDefinitions(configResources); }　　至此。资源文件定位过程已经加载完成。后续就是读取和注册。整个IOC容器加载过程中最重要的是读取过程，我们可以从刚刚的定位过程来看，虽然叫定位过程，但是其实就是一个配置文件读取器的初始化过程，这个过程会设置相关的解析策略以及校验策略。最终读取器生成后，就可以将我们早早设置好的配置文件载入然后进行读取。

【功能模块】容器编译【操作步骤&问题现象】1、根据AR-CORE-220E开发指南容器制作步骤编译出容器；2、安装到AR-CORE-220E设备上；3、使用container status查看容器状态，此时容器ip是ipv6地址；4、等待几分钟后，再次查看，容器ip仍旧是ipv6地址【截图信息】【日志信息】（可选，上传日志内容或者附件）

2021年4月1日北京超图软件股份有限公司资深产品经理周世杰老师做客华为云云市场直播间，给大家带来了《场景+应用，带你硬核解析云原生GIS》的主题分享。其实在之前我是不太了解什么是GIS的，非常感谢这次的科普直播，让我不仅了解到了GIS技术，还了解到了相关的产品案例，大有裨益，本文就带大家一起梳理一下直播的内容。GIS是Geographic Information System的简称，即地理信息系统，那云原生GIS又是什么？云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生GIS是面向环境设计的，基于微服务架构思想的，以容器位部署载体的，可自动化编排、运维管理的，更弹性、更稳定、更新更实时的GIS软件体系架构。也就是以云原生的方式构建和运行的 GIS 应用。云原生GIS有什么优势？1）更稳定：服务可自动恢复 ；故障可自动转移；保证服务永久在线。2）更便捷： 内置存储资源池：Redis、MySQL、MongoDB、HDFS 、 Elasticsearch、HBase、PostGIS、PostgreSQL内置计算资源池：Spark、Hadoop YARN内置流数据环境：Kafka集群3）更弹性：资源更集约计算更高效 云原生GIS的典型应用场景：1）GIS服务数量多云原生设计的初衷就是为了解决大数据时代所带来的数据量 不断增大引起的数据发布不成功、数据加载困难等问题。当用户有成百上千的服务实例时，如果发布在一个iServer或 iServer集群中，服务器的承受力问题和服务崩溃、重启所带来的种种，都是亟待解决的问题。这种情况使用云原生GIS，对服务按 照数据源类型、服务类型、访问频率等进行分类调度到不同的节点， 就可以化解上述问题。2）数据种类多，体积大数据种类多，发布出来的服务数量也会很多，造成的问题跟上述第一个场景一样。 数据的体积比较大的情况下，查询、分析、加载等过程都会 比较耗资源，如果采用传统方式发布，不仅访问该服务会比较慢， 而且也会拖慢其他服务。所以当数据种类多、体积大或服务类型复杂时，都适用于云原生GIS环境，对这类服务进行独立调度和横向伸缩。3）局部平滑升级、故障恢复困难云原生的优势就是更新快、升级快，可以快速更新单个微服务，而不会影响其他功能。 在项目生产过程中，有需要上线一些新功能时，如果采用传统方式往往需要做大量手工配置工作，且存在风险。而在云原生GIS中，用户只需要使用新镜像，就可以滚动更新该服务，从而便捷、平滑稳定的升级新功能。再配合灰度发布让服务上线更加严谨。4）关注微服务、创新随着应用程序的功能日益丰富和强大，微服务应运而生，成为新型软件架构。 云原生GIS是由多个功能小而专注、独立部署的微服务组合出的大型GIS应用程序。各个微服务的开发彼此独立，可以根据功能需求每个微服务使用最适合的技术栈或开发语言。当用户考虑升级整体技术栈时，可以考虑云原生创新应用。5）对高可用关注度高云原生GIS的部署是多节点集群方式搭建，一个节点故障，服务会自动转移到其他存活的节点；如果其中一个服务异常，系统会自动重建一个新的服务来替代异常的服务，因为是基于容器技术，替代过程可以达到秒级替代；基于微服务的横向扩展能力，保证了服务高效稳定。6）机器/VM比较多云原生GIS环境下，所有服务都是由Kubernetes统一管理调 度，用户需要做的就是把这些机器加入Kubernetes集群即可。 云原生GIS会全面监控物理机、容器等资源使用情况，并把服务部署调度到当前最优的机器来运行。 后续有采购新机器，只需要“一键”加入Kubernetes集群即可。 当有机器从Kubernetes中移除后，它上面的服务会自动迁移到其他机器，不需要人工干预。 云原生GIS环境搭建需要的包-华为云：直播链接：https://bbs.huaweicloud.com/live/marketplace_live/202104011900.html超图云GIS管理服务器平台：https://marketplace.huaweicloud.com/contents/1bdc29fb-2828-4aa3-b799-acb09538c1a8?marketplace_live_20210401

【功能模块】把第三方库打包进容器【操作步骤&问题现象】1，用build_sdk_base.sh制作了基础镜像2，自己编译出来了第三方的库(.so和.a)，不是按照文档脚本制作，库是测试可用的，库没有问题3，修改了createdeb文件，把所有的库都打包成deb文件执行命令：./Todeb  库文件夹 库名目的：库文件夹里面的DEBIAN文件和第三方库（.so或.a）打包成deb文件，然后分别放到sdk和ova文件夹下（问题1：必须把deb文件放到这两个文件夹下吗，制作sdk，应该和ova没有关系吧）4，用build_sdk.sh制作出编译镜像，并安装（问题2：这一步后，第三方库应该也已经被打包进编译镜像了吧，但是怎么确定打包的.so成功被打包进镜像了，目前/usr/loca/lib和/usr/lib下都没有）5，在制作出的编译环境里面执行build_ova.sh制作出容器，这一步执行过程在附件日志（问题3：安装到核心板上，没有找到第三方库，目前/usr/loca/lib和/usr/lib下都没有，应该在哪里）问题4：上面的第3步，是否可用把所有的.so和.a文件都放到一个文件夹中，一次性打包成.deb，还是必须是分开制作成.deb，然后都放到sdk目录下？问题5：请帮忙看下附件日志，还有一些警告，请问哪些警告可以忽略，哪些不能忽略，必须解决？问题6：第1步制作的交叉编译环境，应该就是华为提供的交叉编译镜像吧？root@2b2df3265563:/data/502H/eciot-ova# cat Todeb #!/bin/bash if [ $# != 1 ];then echo "Usage: $0 appdir package architecture version email description " exit fi DIR=$1 PACKAGE=$1 if [[ ! -d $DIR ]]; then mkdir $DIR fi cp ./my_lib/${PACKAGE} $DIR/ ARCH=arm64 VERSION=1.0 INSTALLED_SIZE=`du -s $DIR | awk '{print $1}'` EMAIL=guoyanzhang@orena.com.cn DESC=orena cd $DIR if [[ ! -d "DEBIAN" ]]; then mkdir DEBIAN fi #md5sum `find . -type f` > DEBIAN/md5sums echo "Package: $PACKAGE" > DEBIAN/control echo "Version: $VERSION" >> DEBIAN/control echo "Architecture: $ARCH" >> DEBIAN/control echo "Depends: " >> DEBIAN/control echo "Installed-Size: $INSTALLED_SIZE " >> DEBIAN/control echo "Priority: optional" >> DEBIAN/control echo "Maintainer: $EMAIL" >> DEBIAN/control echo "Description: $DESC" >> DEBIAN/control chmod 755 -R DEBIAN #dpkg -b . ../${PACKAGE}_${VERSION}_${ARCH}.deb cd .. pwd debName=${PACKAGE}_${VERSION}_${ARCH}.deb dpkg -b $DIR ./${debName} echo ${debName} cp ./${debName} ./custom_deb/ova/${ARCH} mv ./${debName} ./custom_deb/sdk/【截图信息】五【日志信息】（可选，上传日志内容或者附件）无

给容器内应用程序传递参数的实现方式:1. 将配置文件直接打包到镜像中，不推荐使用，因为变更配置不够灵活，配置过程也繁琐。2. 使用环境变量来给Pod应用传参修改配置。3.挂载存储卷: 我们可将配置信息直接放到存储卷中，自动挂载存储卷到配置文件目录，来实现给Pod中应用提供不同的配置。4. 使用configMap存储参数。configMap的作用:　　一个configMap资源其实就是一系列配置信息的集合，存放在etcd中；它是K8s中的标准组件,通过两种方式实现给Pod传递配置参数:　　A. 将环境变量直接定义在configMap中，Pod启动时,通过env来引用configMap中定义的环境变量。　　B. 将一个完整配置文件封装到configMap中,然后通过共享卷的方式挂载到Pod中,读取配置文件实现给应用传参。应用示例：首先定义一个configmap的资源文件。vi configmap-demo.yamlapiVersion: v1kind: ConfigMapmetadata:   name: configmap-demo   data:     abc: "123"        #键值key-value的方式设置参数     cde: "456"     redis.properties: | #”|“代表多行数据     port: 6379     host: 192.168.31.10再定义一个使用configmap的测试容器的yaml文件。vi configmap-demo-pod.yamlapiVersion: v1kind: Podmetadata:   name: configmap-demo-podspec:   containers:   - name: demo   image: nginx   env:   - name: ABCD   valueFrom:   configMapKeyRef:   name: configmap-demo   key: abc   - name: CDEF   valueFrom:   configMapKeyRef:   name: configmap-demo   key: cde   volumeMounts:   - name: config   mountPath: "/config"   readOnly: truevolumes:- name: configconfigMap:  name: configmap-demo  items:  - key: "redis.properties"  path: "redis.properties"[k8s-master~]#kubectl apply -f configmap-demo.yaml[k8s-master~]#kubectl apply -f configmap-demo-pod.yaml[k8s-master~]#kubectl exec -it configmap-demo-pod --bash 进入容器bashroot@configmap-demo-pod:/#echo $abc123root@configmap-demo-pod:/#cat /config/redis.properties port: 6379 host: 192.168.31.10

【功能模块】容器安装签名【操作步骤&问题现象】边缘计算网关二次开发指南(AR-CORE系列)文档里面“通过OpenPGP生成签名文件”这一章节的运行环境是什么？是容器交叉编译环境吗？1，如果不是，那请问运行环境是什么？2，如果是，那请问这个生成的签名文件，是容器安装和app安装同时使用的吗？3，如果是，那请问我把“通过OpenPGP生成签名文件”第3步生成的公钥文件放到容器内，安装说找不到签名文件？【截图信息】无【日志信息】（可选，上传日志内容或者附件）无

重启策略:Always:当容器终止退出后,总是重启容器,是默认策略。OnFailure:当容器异常退出(退出状态码非0)时,才重启容器。Never:当容器终止退出,从不重启容器。健康检查，有以下3种类型:livenessProbe (存活检查) :如果检查失败,将杀死容器,根据Pod的重启策略来操作。readinessProbe (就绪检查) :如果检查失败, Kubernetes会把Pod从service endpoints中剔除。startupProbe (启动检查)：判断容器是否成功启动。支持以下三种检查方法:httpGet:发送HTTP请求,返回200-400范围状态码为成功。exec:执行Shell命令返回状态码是0为成功。tcpSocket:发起TCP Socket建立成功。

【摘要】 十年磨一剑，云原生从最初的默默无闻到企业数字化转型的核心支撑，华为云作为CNCF的创始成员，一直在为社区贡献力量。随着技术和业务的演进，云原生2．0时代的新价值——“云上内生的云能力”成企业所需，看华为云云原生基础设施如何开启云原生2．0时代。文章简介什么是云原生都0202年了，如果你还不懂云原生，那真的out了。带你读懂容器技术，“容器”和“虚拟机”别再分不清容器这个词，当你第一眼看它或许脑子里是这东西：瓶瓶罐罐、装水、装其他东西的玩意。不管是什么，总的来说，容器给人第一印象就是——“装”。一文读懂k8s多集群技术发展史 一文带你了解Kubernetes多集群技术发展的历史、现状与未来。浅谈服务化和微服务化微服务是近期非常热门的话题，芸芸众生言必谈微服务。伯克利：serverless是下一代计算范式Serverless技术正是云厂商的基于规模经济的一个选择。Service Mesh：下一代微服务？微服务方兴未艾如火如荼之际，在 Spring Cloud 等经典框架之外，Service Mesh 技术正在悄然兴起。云原生系列技术：DevOps技术云计算和容器技术的快速普及，DevOps越来越被重视，甚至成为保证公司生产力的最佳之选。详解华为云容器全新解决方案华为云新一代容器基础设施“军舰”，来了！大数据容器化，头部玩家尝到了甜头？大数据容器化，大势所趋。头部玩家在进行大数据容器化后，尝到了甜头。从Vessel到二代裸金属容器，云原生新一波技术浪潮涌向何处云原生大势，深度解读华为云四大容器解决方案如何加速技术产业融合。云原生2.0时代：华为云开启应用定义基础设施新时代云原生以“应用使能”+“混合云”为核心，帮助企业本地部署与云端融合，打造企业急迫需要的混合云架构。为什么说容器的崛起预示着云原生时代到来？说到云原生，我们就不得不先了解一下容器技术。【容器】容器多云/混合云，云时代灾备新利器华为容器多云/混合云解决方案基于社区的集群联邦技术，提供了跨云的多集群统一管理、应用在多集群的统一部署和流量分发，并可以结合Istio技术，实现应用流量的全局治理。【KubeEdge】解读KubeEdge：云原生的边缘计算平台KubeEdge即Kube+Edge，顾名思义就是依托K8S的容器编排和调度能力，实现云边协同、计算下沉、海量设备的平滑接入。【Istio】万字解读:Service   Mesh服务网格新生代--Istio一文带你了解关于Istio技术的介绍、架构和展望。【Volcano】Volcano火山：容器与批量计算的碰撞 Volcano是基于K8s构建的一个通用批量计算系统，弥补了K8s在“高性能应用”方面的不足，支持TensorFlow、Spark、MindSpore等多个领域框架，帮助用户通过K8s构建统一的容器平台。【鲲鹏容器】华为云鲲鹏容器发布，极致释放多元算力在云+AI+5G的时代，昇腾+鲲鹏是企业创新的最佳算力选择。【AI容器】华为云AI容器：零基础搭建AI计算平台，提升计算效率 50%华为云 AI 容器为客户提供更高性价比算力，更简化了平台运维，提升 AI 计算效率 50%，加速 AI 计算在各行业的落地和发展。【裸金属容器】华为云重磅发布全球首个双零损耗裸金属容器 全球独家双零损耗裸金属容器——华为云第二代裸金属容器，首次在业内实现资源和性能的零损耗，让容器全面释放裸金属服务器的潜力，加速云原生创新升级。【裸金属容器】华为云第二代裸金属容器：应对海量并发的网络黑科技因突发流量触发业务扩容，以前是扩容虚机速度慢，现在大部分互联网平台都使用容器了，为什么扩容速度有些时候还是跟不上流量增长的节奏？【数据库】云原生数据库三驾马车之TaurusDBTaurus其设计思想是Log-as-database以最小化网络IO，采用计算存储分离的架构。【DevCloud】华为云DevCloud,云原生架构下的DevOps实践云原生架构与DevOps的落地与转型是一个量变到质变过程。【云容器引擎】带你了解云容器引擎CCE的权限管理借助云容器引擎，您可以在华为云上轻松部署、管理和扩展容器化应用程序，快速高效的将微服务部署在云端。【容器】容器化之路：谁偷走了我的构建时间 什么是镜像？什么是镜像构建？什么是storage-driver？【Docker网络】《跟唐老师学习云网络》   - Docker网络实现带你详细理解Docker容器是如何实现Docker网络，以及解析一个容器是如何与本机、本机中的容器、其他Host、其他Host中的容器 等场景下分别是如何进行通信的详细原理。【Kubernetes】盘点Kubernetes网络问题的4种解决方案现在的开源世界里，有很多开源组件可以帮助我们打通Docker容器和容器之间的网络，实现K8s要求的网络模型。当然每种方案都有自己适合的场景，我们要根据自己的实际需要进行选择。【云容器引擎】微服务应用在CCE上的初探借助云容器引擎，在华为云上轻松部署、管理和扩展容器化应用程序，来为企业释放更多精力，CCE提供一整套完整的最佳容器解决方案，赋能企业专注业务开发。【Kubernetes】企业落地Kubernetes的问题与对策随着Kubernetes的全面成熟与大规模应用，如何落地Kubernetes是企业实施云战略需要考虑的迫切问题。【微服务】如何应对企业级微服务开发？最优解在这里…从服务管理中心、通信处理两个模块来介绍华为开源微服务框架 SeviceComb 如何帮助企业应用快速具备高性能的通信能力以及高可靠的服务管理能力。【Service】在K8S大规模场景下Service性能如何优化？ K8s 原生的 Service 负载均衡基于 Iptables 实现，其规则链会随 Service 的数量呈线性增长，在大规模场景下对 Service 性能影响严重。【安全容器】容器与虚拟化的结合：浅谈“安全容器”技术发展趋势无论公有云还是私有云厂商，都认识到了将虚拟化的隔离性和容器的高效运维特性相结合，是云原生平台发展的必然趋势。【Kubernetes】Kubernetes的拐点助推器：左手开源，右手边缘计算据2020边缘计算状态报告显示，到2022年，75%的数据将通过边缘分析和处理。这种数据处理的流动性，将伴随有4大边缘技术演进方向。本合集为《大厂内参》005期，欢迎大家持续关注。大厂内参根据开发者普遍关注的热门技术领域，汇编实践精华内容。从业务场景选型，应用案例分析，到前瞻趋势预测。以专题的形式，深度解读华为云核心技术，分享一线工程师的实战经验。【第一期】敏捷&Devops：80+篇实践干货分享，深度解读敏捷&DevOps如何革新软件开发【第二期】数据库：从数据库科普到核心技术解读、上云案例分享，全方位剖析云数据库【第三期】云服务器：选型解读+案例分享：云服务器“软硬技术”全公开【第四期】人工智能：海量实战经验教你零门槛进场AI开发，无成本负担玩转AI应用【第五期】云原生：读懂云原生2.0，看它如何重塑业务开发架构【第六期】云安全：Get防范云安全的必杀技，学会构建云上完整安全体系【第七期】物联网：“端边云”IoT全栈技术大揭秘，开发实战指南带你轻松上手IoT【第八期】数据仓库：8大场景系列玩转数仓运维，做个不秃头的DBA

  云原生2.0时代已经到来IDC发布《IDC FutureScape: 全球云计算2020 年预测——中国启示》显示，云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。为进一步推进云原生技术的普及，帮助广大技术爱好者快速掌握云原生相关技能，让学员具备云原生系统基础管理动手能力，华为云学院联合CNCF、华为云云原生团队重磅推出《华为云云原生王者之路集训营》系列课程。继《黄金系列》课程之后，在30000+黄金课程学员的呼声和期待下，华为云学院宣布：云原生王者之路《钻石系列》课程预备上线，钻石集训营正式开始啦！   黄金课程学员学习心得学员A：作为云原生基础教学，云原生黄金课程能够让人快速了解概念，具备初步动手能力，沙箱实验很棒，可以实践锻炼，学以致用！学员B：从基础的微服务K8S等理论知识，到K8S集群管理、服务管理等进阶知识，我学到很多，期待钻石进阶课程。学员C：这次学习让我了解了什么是云原生，跟随云原生大佬学习k8s，入股不亏，钻石课程快来吧！  钻石系列课程简介钻石系列课程由华为云云原生核心团队11名大咖讲师倾心打造，在黄金系列课程的基础上，对云原生技术底层原理进行深度剖析，包括Kubernetes的运行时、调度、网络、存储、运维等核心技术原理和主流方案架构，Istio的控制面、数据面、流量治理、传统微服务框架接入等技术原理和方案架构，同时精选多个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。钻石集训营将以直播课程与专家答疑同步的方式，带着大家进行在线学习，帮助大家在云原生技术进阶之路上学的更轻松！   集训营特邀专家大咖阵容本阶段钻石系列课程由11位华为云云原生领域大咖专家倾力打造，全面深入地对云原生的知识体系剖析，详细课程内容，请查看课程详情。  集训营面向对象1.计算机、软件工程等专业的大学生2.涉及Kubernetes、Istio等技术的应用开发者3.其他的云原生技术兴趣爱好者  集训营直播安排直播课程期间，每晚19-20点专家讲师进行课程直播与在线答疑，次日10点可在华为云学院解锁直播课程回看。  集训营亮点4大任务：课程学习+实战演练+认证实践+结业考核5大亮点：1.黄金-钻石-王者系统化课程，带你进阶化提升2.精选典型应用场景，理论实践相结合，多阶考核与测验3.华为云云原生团队核心架构师授课带学、答疑解惑4.云原生专属学习圈，每日打卡，教辅相伴，升阶无忧5.学练考一站式，课程、实验、微认证等多元化学习体验   集训营丰富好礼参与课程学习打卡，赢价值200USD HCIA职业认证考试券、华为手环B6、筋膜枪、富士INSTAX 一次成像相机、雷柏机械键盘、华为手环4e、微认证代金券、沙箱实验点折扣券等超丰富奖品！训练营学员还可享有CKA/CKAD/CKS认证套购8.5折，单独购买9折优惠！  报名时间及方式登录“华为云学院”,从 “云原生王者之路钻石集训营”活动页进入，点击“立即报名”即可报名成功。添加小助手微信HWcloudedu，备注“云原生”加学习群，心动不如行动，快去报名吧！ 课程详情请扫描下方二维码了解，参与日期截止至8月12日，课程免费向开发者开放，名额有限，招满即止，还等什么，马上占位吧！