1、简介Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引；也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。Solr可以支持在arm环境下运行，无需重新编译。但需要配合Tomcat 8以上版本使用。可以从官网下载最新的Solr包进行解压缩、配置、运行。2、环境类别版本配置备注ARM测试服务器CentOS7.4arm通用计算增强型 | rc3.xlarge.4 | 4vCPUs | 14GB华为云公测可申请ARM服务器3、Tomcat安装（详细见tomcat指导安装文档）4、Solr安装（arm服务器）4.1.下载安装包wget http://mirror.bit.edu.cn/apache/lucene/solr/8.1.1/solr-8.1.1.zip4.2.解压缩包unzip solr-8.1.1.zip4.3.复制文件夹到目录1.拷贝solr-8.1.1/server/solr-webapp/webapp目录到tomcat/webapp/,改名叫solrcp -r solr-8.1.1/server/solr-webapp/webapp tomcat8/webapps/solr2.拷贝solr-8.1.1/server/lib/ext下的jar包到tomcat下的webapps/solr/WEB-INF/lib路径下cp solr-8.1.1/server/lib/ext/*.jar tomcat8/webapps/solr/WEB-INF/lib/3. 拷贝solr-8.1.1/dist 下的solr-dataimporthandler-8.1.1.jar、solr-dataimporthandler-extras-8.1.1.jar 包到tomcat下的webapps/solr/WEB-INF/lib路径cp solr-8.1.1/dist/solr-dataimporthandler*.jar   tomcat8/webapps/solr/WEB-INF/lib4.拷贝solr-8.1.1/server/lib下的metrics开头的5个jar到tomcat下的webapps/solr/WEB-INF/lib路径下（metrics-core-3.2.2.jar、metrics-ganglia-3.2.2.jar、metrics-graphite-3.2.2.jar、metrics-jetty9-3.2.2.jar、metrics-jvm-3.2.2.jar）5.新建一个文件夹solr-home，并将solr-8.1.1/server/路径下solr文件夹中的内容拷贝过来mkdir solr-homecp -r solr-8.1.1/server/solr/* solr-home  （复制到刚刚新建的solr-home里）4.4.环境配置1.进入tomcat8下的webapps/solr/WEB-INF下修改web.xmlcd tomcat8/webapps/solr/WEB-INFvi web.xml2. //记得打开此处的注释（如果没有手动输入）<env-entry>    <env-entry-name>solr/home</env-entry-name>  <env-entry-value>/usr/local/solr/solr-home</env-entry-value>//自己solr-home的位置    <env-entry-type>java.lang.String</env-entry-type></env-entry> //中间省略...//下面这段注释掉<!--  <security-constraint>    <web-resource-collection>        <web-resource-name>Disable TRACE</web-resource-name>        <url-pattern>/</url-pattern>        <http-method>TRACE</http-method>      </web-resource-collection>    <auth-constraint/>  </security-constraint>  <security-constraint>      <web-resource-collection>        <web-resource-name>Enable everything but   TRACE</web-resource-name>        <url-pattern>/</url-pattern>        <http-method-omission>TRACE</http-method-omission>      </web-resource-collection>  </security-constraint>  -->5、测试5.1.测试执行1.运行tomcat2.访问http://ip:port/solr/index.html（ip端口根据tomcat配置来填） 6、参考信息     solr安装指导： https://blog.csdn.net/qq_40524941/article/details/815122937、FAQ     待补充

你们要的【7天玩转容器之基础入门课】课件在这里，拿走不谢！课程内容涵盖热门的Docker+Kubernetes精编前沿技术，覆盖CKA考纲80%以上内容。资深专家带路，理论+实践双管齐下，助你系统学习、玩转容器，攻克CKA！时间课程主题材料下载Day1容器基础知识介绍点此下载Day2Kubernetes基础知识介绍点此下载Day3Kubernetes pod调度原理分析点此下载Day4Kubernetes应用生命周期原理分析点此下载Day5Kubernetes网络管理原理分析点此下载Day6Kubernetes存储管理原理分析点此下载Day7Kubernetes安全原理分析点此下载

本期【云享专家·微话题】由云享专家Tsjsdbd与大家一起讨论“容器与虚机，谁将主宰云世界”，希望大家能够畅所欲言。如果大家有其他任何与PaaS相关的问题，也可以在本帖回复直接咨询云享专家Tsjsdbd。 =======【云享专家·微话题】容器与虚机，谁将主宰云世界？=======如今Docker容器技术已经比较普及，在各个领域都开始发挥出价值。并且容器与虚拟机十分和谐的共存，两者各自具有不同的特征和相应适合的应用场景。然而，渐渐地你会发现在各个云基础设所涉及的领地，容器正在以它的角度重建这个世界，容器存储，容器网络，容器调度都全部长出自己的枝干。在实际的领域，容器也开始崭露头角，HPC，基因测序，边缘云，微服务等等。相信有一天，容器会与虚机平起平坐，然后在那之后，迅速超越，成为云计算的中流砥柱。Container will Rebuild the World。每个人对“容器与虚机”都有不一样的理解，今天我们就“容器与虚机”一起来讨论，希望看到大家精彩的评论：1、讲讲你在容器使用过程中存在的问题？2、讲讲容器技术如何在各个技术领域渐露头角？3、容器一直被诟病的薄弱点安全相关进展？4、你觉得容器是否和虚机的各自发展前景？微话题活动：参与本次微话题讨论，有机会获得优质评论奖活动时间：2018年7月16日-7月27日参与方式：直接在本帖回复你关于以上4个问题的理解或评论获奖方式：活动结束后，将由云享专家Tsjsdbd选取出3名优质评论奖，各送出《Docker 容器与容器云》书籍1本。优质评论：建赟：1、讲讲你在容器使用过程中存在的问题？                 在容器使用过程中存在的问题有：a、安装非常缓慢，而且经常安装失败。b、Docker所有的镜像都依赖于基础镜像，而这些基础镜像都在国外的docker hub上，镜像pull非常慢。c、默认的dockerhub所有镜像都是公开的，私有仓库价格是非常贵的，而且速度还很慢。d、要在VM上使用docker，需要对网络、存储等做一些特殊的处理。e、使用docker的出发点是降低运维成本，提升效率，但是管理上的成本相反却会上升，需要专业的公司来处理。f、容器的性能。 g、容器的安全。 h、网络的问题。i、容器型运维人员短缺2、讲讲容器技术如何在各个技术领域渐露头角？                 容器带来了之前技术所没有的几个新特点。a、与之前的方法相比，Docker让容器部署和使用起来更容易、更安全。b、由于Docker与其他容器领域的巨擘进行了合作，包括Canonical、谷歌、红帽和Parallels，共同开发其关键的开源组件libcontainer，它为容器带来了迫切需要的标准化。c、容器易于部署到云端。3、容器一直被诟病的薄弱点安全相关进展？       对docker容器安全质疑最大的一点就是其隔离的彻底性，将docker生命周期拆为两个大阶段，非生产环境阶段和生产环境阶段，这两个阶段安全控制的目标如下：非生产环境中保证镜像安全可信，生产环境中保证镜像正确的运行。4、你觉得容器是否和虚机的各自发展前景？       说docker代替vm来说还为时过早，长期来看docker会在更多的场景上逐步替代vm的功能，vm技术也会在很长的时间内继续发挥着重要的作用，也许将来两种技术会进行融合，vm技术拥有docker的一些特性，同时docker也会克服自身的一些缺点，变得更加易用。ecstatic：1、讲讲你在容器使用过程中存在的问题？      a.项目中docker容器中生成的日志文件名称乱码      b.怎样才能在容器中使用iptables呢      c.容易安装失败      d.kubernetes，mesos框架用不明白2、讲讲容器技术如何在各个技术领域渐露头角？     容器技术最早可以追溯到1979年UNIX系统中的chroot，最初是为了方便切换root目录，为每个进程提供了文件系统资源的隔离，这也是OS虚拟化思想的起源。      2013年Docker诞生，Docker最早是dotCloud（Docker公司的前身，是一家PaaS公司）内部的项目，和Warden类似，Docker最初也用了LXC，后来才自己写了 libcontainer 替换了 LXC。和其它容器技术不同的是，Docker 围绕容器构建了一套完整的生态，包括容器镜像标准、容器Registry、REST API、CLI、容器集群管理工具Docker Swarm等；      2016年微软公司发布基于Windows 的容器技术Hyper-V Container，Hyper-V Container原理和Linux下的容器技术类似,可以保证在某个容器里运行的进程与外界是隔离的，兼顾虚拟机的安全性和容器的轻量级。     为什么要关注Docker或者容器技术呢？容器可以提供隔离性，可以为各种测试提供一个良好的沙盒环境。并且，容器本身就是具有“标准性”的特征，非常适合为服务创建构建块。加速本地开发和构建流程，使其更加高效、更加轻量化。本地开发人员可以构建运行并分享Docker容器。容器可以在开发环境中构建，然后轻松的提交到测试环境，最终 进入生产环境。能够让独立服务或者应用程序在不同的环境中，得到相同的运行结果。用Docker创建隔离的环境来进行测试。eg ：JenkinsCIDocker可以让开发者在本机上构建一个复杂的程序或者架构来进行测试，而不是一开始就在生产环境部署、测试。构建一个多用户的平台及服务基础设施。为开发、测试提供一个轻量级的独立沙盒环境，或者将独立的沙盒环境用于技术教学，eg：unix shell 的使用。提供软件及服务应用程序高性能、超大规模的宿主机部署。3、容器一直被诟病的薄弱点安全相关进展？      Docker中可能会出现的安全问题     内核漏洞（Kernel exploits）    容器是基于内核的虚拟化，主机（host）和主机上的所有容器共享一套内核。如果某个容器的操作造成了内核崩溃，那么反过来整台机器上的容器都会受到影响。     拒绝服务攻击（Denial-of-service attacks）    所有的容器都共享了内核资源，如果一个容器独占了某一个资源（内存、CPU、各种ID），可能会造成其他容器因为资源匮乏无法工作（形成DoS攻击）。     容器突破（Container breakouts）    Linux的namespace机制是容器的核心之一，它允许容器内部拥有一个PID=1的进程而在容器外部这个进程号又是不一样的（比如1234）。现在问题在于如果一个PID=1的进程突破了namespace的限制，那么他将会在主机上获得root权限。      有毒镜像（Poisoned images）     主要是考虑到镜像本身的安全性，没太多好说的。      密钥获取（Compromising secrets）     容器中的应用可能会获取一些容器外部的服务，这些服务之间可能会有密钥（secret key）等，如果因为密钥保存不当，那么这些服务对于攻击者来说就是可获取的了，这就会造成很多隐患。特别的，这样的问题如果出现在微服务架构中就特别严重。       安全方案             主机级别的隔离     主机级别的隔离（Segregate Containers by Host）即将不同用户的容器放在不同的机器上、将那些存放了敏感数据的容器 和普通的容器隔离开来、将哪些直接暴露给终端用户的容器（web容器）隔离开来。      主机级别的隔离的好处是可以防止容器突破攻击、DoS攻击，但是这样的隔离会付出成本甚至性能的代价的。              限制容器的网络        容器应向外暴露尽可能少的端口，此外，对于容器之间的通信，最好是需要通信的容器才是连通的。        移除SUID和SGID的二进制位        限制内存        限制CPU        限制重启        限制文件系统4、你觉得容器是否和虚机的各自发展前景？      随着容器生态圈的继续扩大，容器技术正在与越来越多的行业搭界，不论是过去八竿子打不着的大数据、物联网领域，还是已经闹得沸沸腾腾的微服务、虚拟化，一个更加广阔的后容器技术时代正在到来，他们都将会有更大的发展前景。小修：1、讲讲你在容器使用过程中存在的问题？1. 在docker容器中vi指令找不到2.docker容器启动后没有ifconfig和ping3.Docker客户端和服务器端版本不一致，在某些操作过中会出现错误4.对于基于busybox, alpine等镜像的容器，在执行命令时可能会出现错误5.容器启动后自动退出、或进入“restarting”状态2、讲讲容器技术如何在各个技术领域渐露头角？容器技术已经引起了业内的广泛关注，有充分的证据表明，容器技术能够大大提升工作效率。　　现在，虚拟化技术已经成为一种被大家广泛认可的服务器资源共享方式，它可以在按需构建操作系统实例的过程当中为系统管理员提供极大的灵活性。由于hypervisor虚拟化技术仍然存在一些性能和资源使用效率方面的问题，因此出现了一种称为容器（Container）的新型虚拟化技术来帮助解决这些问题。起初，大家普遍认为基于hypervisor的方式可以在最大程度上提供灵活性。所有虚拟机实例都能够运行任何其所支持的操作系统，而不受其他实例的影响。然而，现在越来越多的用户发现hypervisor提供这样一种广泛支持的特性其实是在给自己制造麻烦。对于hypervisor环境来说，每个虚拟机实例都需要运行客户端操作系统的完整副本以及其中包含的大量应用程序。从实际运行的角度来说，由此产生的沉重负载将会影响其工作效率及性能表现。　　首先，每种操作系统和应用程序堆栈都需要使用DRAM。对于多个运行简单应用程序的小型虚拟机实例来说，这种方式可能产生很大的系统开销，降低性能表现。加载并卸载这些堆栈镜像需要花费很长时间，并且还会增加容器技术服务器的网络连接数量。对于极端情况来说，如果用户在上午9点同时启动上千台虚拟桌面，还有可能导致网络风暴的发生。部署虚拟服务器的目的之一在于快速创建新的虚拟机实例。然而从网络存储当中复制镜像需要花费大量时间，这些操作会延长启动过程，无疑会限制系统灵活性。　　因此我们可以选择使用容器技术。只需要通过简单的观察我们便能够发现容器技术的出现是为了解决多操作系统/应用程序堆栈的问题：在单台服务器当中为所有虚拟机实例使用相同的操作系统对于大部分数据中心来说都不算是真正的限制。流程管理（Orchestration）可以轻松处理这种变化许多应用程序堆栈都是相同的（如LAMP）对于大规模集群来说，在本地硬盘当中存储操作系统副本将会使得更新过程变得更为复杂最为重要的是，容器技术可以同时将操作系统镜像和应用程序加载到内存当中。还可以从网络磁盘进行加载，因为同时启动几十台镜像不会对网络和存储带来很大负载。之后的镜像创建过程只需要指向通用镜像，大大减少了所需内存。　　容器技术能够在同一台服务器上创建相比于之前两倍的虚拟机实例数量，因此无疑将会降低系统总投入。但是必须认真进行规划，因为双倍的实例数量同样意味着对于运行这些实例的服务器带来了双倍的I/O负载。　　我们需要了解除了避免可能发生的启动风暴之外，容器技术是否还有任何其他性能方面的优势。能否改进IOPS？能够提升网络连接效率并且降低容器间的延迟，解决伴随实例数量增加而产生的问题？美国某传统服务器大厂商的某实验室完成了至今为止大部分权威实验，其研究结果表明容器技术相比于hypervisor，容器技术的许多关键指标都有重大改进。在进行的所有测试当中，容器技术几乎拥有和本地平台一样的运行速度，尽管网络延迟测试还没有完成。　　上述厂商的研究表明容器技术在多个领域当中都比hypervisor拥有更好的性能表现。容器技术的运行速度几乎是hypervisor的两倍，在评分当中非常接近于本地操作系统。在和KVM的对比当中，容器技术在硬盘随机读取(84,000 vs 48,000 IOPS)和写入(110,000 vs 60,000 IOPS )方面拥有非常优秀的表现，如果使用本地固态硬盘可以实现更好的SQL性能表现。高性能计算(HPC)社区也在转而使用虚拟化和容器技术。一项由巴西天主教大学进行的研究已经取得了一定成果。“如果可以降低基本的系统开销（比如CPU、内存、硬盘和网络），那么HPC无疑会选择使用虚拟化系统，”研究人员表示。“从这个角度来说，我们发现所有基于容器的系统在CPU、内存、硬盘和网络方面都拥有接近于本地操作系统的性能表现。”美国某虚拟化公司V***re也针对容器技术进行了一系列评测对比。容器技术研究结果印证了容器技术拥有接近本地系统的性能表现，尽管其并没有像IBM实验室那样针对VMware的hypervisor发布非常详细的测试报告。而这项报告的容器技术结果有可能促使VMware做出调整，以降低hypervisor的系统开销。VMware的报告当中没有提及硬盘I/O问题。　　为了扩展适用范围，容器技术仍然需要在安全方面不断改进。但是现在，我们可以看到的是这种方式可以解决hypervisor虚拟化当中的大多数性能问题。再加上更加轻松和快捷的部署方式，容器技术将会在不久的将来占据虚拟化市场3、容器一直被诟病的薄弱点安全相关进展？容器安全需要自下而上全面考虑安全风险，从内核，OS ，OS层的网络、软件版本、Selinux策略，Docker版本，Docker的优化配置以及使用方式，image中所依赖的base 以及软件包，容器间的网络隔离。真的是每一处都需要去考虑，任何一个环节的小问题，都有可能造成事故。感觉Docker 安全是个全方位的问题，任何一点疏漏都会带来灾难性后果。有些问题不是Docker本身能解决的，需要多方配合。Docker在这个方面做了哪些工作？4、你觉得容器是否和虚机的各自发展前景？容器实例与主机共享操作系统内核，通过内核提供的运行时隔离能力为服务提供独立的用户域、文件系统、网络以及进程运行空间。虚拟机的每个实例自带操作系统，因而是一种硬件级的虚拟化隔离。容器通常是专用于运行特定服务的，它的镜像通常只包含运行该服务所需的上下文内容，许多广泛使用的镜像都只有几十MB，甚至几MB大小。虚拟机则需要提供包括内核在内的通用进程运行环境，它的镜像偏向于大而完整的全功能集合，即使一个最小精简镜像的体积也有几百MB。容器的使用方式倾向于开箱即用，镜像提供的是一个“不可变的基础设施环境”。虚拟机则倾向于让用户根据所用的系统，自定义初始化操作，使用Ansible、Puppet这样的配置工具来进行基础设施的管理。容器在启动速度和运行性能上更有优势，虚拟机在安全性上更有优势。如果从这些十分清晰的定义来看，近一年来开源界出现的一些虚拟化“边界破坏者”们已经完全无视了这些规则。它们要么是运行在虚拟机中的操作系统，却有着容器一样的使用体验，要么是基于容器技术的运行时隔离，却应该当成虚拟机使用。因此，尽管这些技术的实现细节上差异巨大，但它们都有一个共同特征：携带着容器和虚拟机各一部分的基因，具备两者优势的结合。

云原生的概念自2013年一经提出，就备受关注和推崇在IT圈儿混的，对云原生技术想必都不陌生特别是对容器、服务网格、微服务、Serverless 等云原生代表技术，或多或少都有一定了解很多企业甚至已利用云原生技术成功实现了业务上云的转型 那么问题来了从邂逅云原生到相识相知携手踏上新征程，你/公司是怎么做到的，都经历了些啥？520秀完恩爱，是时候秀秀你与云原生的那些事儿了！华为云容器团队现面向广大程序猿征集你与云原生的故事、技术心得、上云实践/案例等参与即有机会获得华为手环、云原生专业书籍、京东E卡等多重好礼哦分享创造更大价值，你还在等什么，赶紧参与吧~ 活动具体内容&规则如下：1. 征文时间：2019年5月27日-7月31日2. 参与对象：华为云容器服务用户、云原生技术爱好者3. 参与方式：点击进入“云原生研究所”- 选择“云原生生态”分类，即可发布参赛文章帖啦，记得将帖子标题及链接回复在本帖下哦（用于参赛统计和奖品发放，一定要回复到本帖下，否则可能无法参与评选）4. 内容要求：分享你/公司与云原生的故事、技术心得、上云实践/案例……只要与云原生相关内容皆可，500字以上，不限题材，自由发挥。比如，可以谈谈你对云原生技术的理解，聊聊你个人or公司在使用华为云容器服务过程中的心得体会。当然，如果能分享一些容器给公司业务带来的变化就更好啦~>举个栗子：-标题：我与容器的不解之缘-正文：坐标深圳，XX公司程序猿一枚，一直有关注容器技术……公司去年开始使用华为云容器服务CCE，逐步将应用进行容器化改造……大幅度降低了成本，提高了运维效率，还让我得到了晋升的机会……5. 评选规则：>评选标准：1）可学习参考性  2）内容真实性  3）内容完整性>评选方式：活动结束后，华为云容器服务专家评审团将对参赛文章进行评审，并于1周内公布结果。6. 活动奖励：一等奖：1名   华为手环+云原生专业书籍二等奖：3名   云原生专业书籍 三等奖：6名   50元京东E卡7. 注意事项：1）按参与方式参与，其他方式无效；2）请勿大篇幅抄袭其他用户的文章，一经发现，取消参赛、获奖资格；3）禁止恶意刷数据等作弊行为，如有发现，取消参赛、获奖资格；4）遵守华为云社区常规活动规则https://bbs.huaweicloud.com/forum/thread-5766-1-1.html5）本活动最终解释权归华为云容器团队所有。激扬文字，创造更大价值，点击参与吧~

本文不做深入的技术讨论，仅从 Knative 的基本概念及诞生背景入手，让读者对 Knative 的产生初步了解。下一篇开始将对 Knative 的核心组件：Build、Serving、Event 进行深入解读，并结合我们在日常工作中的案例，让大家对 Knative 从技术到应用有一个全方位的了解。Knative 是什么？2018 年 7 月，Google 在 Google Cloud Next 2018 上发布了Knative，将其定位为基于 Kubernetes 的 Serverless 解决方案，旨在标准化 Serverless，简化其学习成本。自开源以来，Knative 项目备受关注，在 github 上已经获得 1000+ 的 start， Pivotal、IBM、Red Hat 等公司也纷纷成为其重要的合作伙伴。传统 Serverless 之殇既然 Knative 的定位是 Serverless 解决方案，那我们不不妨看看 Knative 之前的 Serverless 解决方案是什么样子。提到 Serverless，开发者往往可以想到一张经典的图片，它描述了传统互联应用架构与 Serverless 架构的不同点，Serverless 架构让开发者在构建应用的过程中无需关心计算资源的获取和运维，由服务提供商按需分配计算资源并保证应用执行的 SLA，商业策略上也不同于传统资源的计费模式，按照调用次数进行计费，避免了资源冗余造成的浪费，有效节省应用成本。Serverless 大体上可以分为两种类型：“Backend as a Service” 和 “Functions as a Service”。BaaS(Backend as a Service) 后端即服务，服务商为客户 (开发者) 提供整合云后端的服务，如提供文件存储、数据存储、推送服务、身份验证服务等功能，以帮助开发者快速开发应用。FaaS(Function as a Service) 函数即服务，服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护基础架构。按照此模型构建应用程序是实现“无服务器”体系结构的一种方式，通常在构建微服务应用程序时使用。传统的互联网 APP 主要采用 B/S 架构，服务器端需长期维持业务进程来处理客户端请求，并调用代码逻辑完成请求响应流程。而在 Serverless 架构中，应用的业务逻辑将基于 FAAS 架构拆分成多个相互独立的功能组件，并以 API 的形式向外提供服务；同时，不同功能组件间的代码将存储在云服务厂商的函数服务（Function Service）上，如：Amazon Lambda，Azure Function，Google Cloud Functions 等，业务代码仅在被调用时运行，在响应结束时释放资源。然而，传统的 Serverless 解决方案却一直叫好不叫座，这与其自身的问题是分不开的：1.厂商绑定Serverless 只提供了应用本身部署和运行的便利性，但应用依赖的其它服务，比如 API 网关、数据库、消息、缓存管理组件等，会因为选用了某个厂商的 Serverless 平台，而必须使用该厂商提供的配套服务，比如使用 AWS Lambda 就必须配套使用 AWS 的 DB, S3 等产品，这样用户就被该厂商绑定，不能进行随意的迁移或者迁移成本非常高。在 Baas 行业内，一个比较典型的事件是：2016 年 1 月 19 日，Facebook 关闭曾经花巨额资金收购的 Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。2.没有行业标准因为对 Serverless 缺乏统一认知以及相应的标准，Serverless 应用无法适应所有的云平台，只适合简单的应用开发，无法推动形成大型成功案例。Knative：Serverless 大规模商业化实施的基石Knative 提供了一组标准中间件，专注于在云原生平台上构建和运行应用的通用任务，比如源码到容器的构建、将服务绑定到事件生态系统（通过事件触发工作负载的执行）、管理部署期间的路由和流量以及工作负载的自动扩展。该框架为用户提供了“部署任何负载都需要的熟悉的、惯用的语言支持以及标准化的模式，这些负载包括传统的应用，也包括函数或容器应用”。相对于传统的 Serverless 解决方案，Knative 的优良性得到开发者和企业认可，这也是其短时间内得到业内各大厂商追捧的主要原因。细数一下 Knative 的优势，包括：便利性：Knative 以 Kubernetes 和 istio 作为其底层框架，因此无论是线上还是线下，任何 Kubernetes 集群，无论是云上 Kubernetes 服务还是自建 Kubernetes 集群，都能通过安装 istio 和 knative 插件快速的搭建 serverless 平台；标准化：Knative 联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨平台，同时让函数和具体的调用方能够解耦；服务间解耦：使用 Knative 使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通；成熟的生态：Knative 基于 Kubernetes 体系构建，与 kubernetes 生态结合更紧密；自动伸缩：监控应用的请求，并自动扩缩容, 得益于 Istio 能力加持，天生支持蓝绿发布、回滚功能，方便应用发布流程。应用监控：支持日志的收集、查找和分析，并支持 VAmetrics 数据展示、调用关系 tracing；目前，Knative 已经发布到 0.5 版本，每一次更新都离客户的最终诉求近了一步，加上 Google, IBM ，Pivotal，Redhat 这样的豪华社区阵营支持，Knative 的未来必定是一片坦途，相信在很短的时间内，我们就能看到基于 Knative 的成功商业化案例。

《直播回看》栏目会将“华为云开发者者联盟”移动端课程平台的精品音视频直播课，定期进行展播，支持各位伙伴进行回看学习本期推荐： 直播回看 | 容器-容器应用之基于AOS进行全自动化的云上编排【主讲人介绍】主讲人：Jiang Shuhang华为云应用服务产品经理，负责华为云应用产品的规划、设计和运营工作，多年来一直从事华为容器类云计算产品的规划与研发工作，在云计算行业及容器技术领域有丰富的从业经验。【课程大纲】课程主要介绍华为云应用编排服务AOS，如何通过图形化的设计器，为用户提供直观、便捷的容器全栈应用的自动化编排。课程中将通过一个电商网站的示例，展示如何通过设计器完成一个容器应用系统的设计及如何完成一键上云的过程。通过学习本课，用户应当具备通过华为云应用编排服务，实现自身容器应用系统在华为云的自动化上线。【课程链接】可扫描下方二维码进入“华为云开发者联盟“移动端直播间收听课程

《直播回看》栏目会将“华为云开发者者联盟”移动端课程平台的精品音视频直播课，定期进行展播，支持各位伙伴进行回看学习本期推荐： 容器-容器进阶之Istio流量治理与全景监控实践【主讲人介绍】主讲人：Aaron Chen华为云Istio服务工程师，对Istio本身具有深入研究，参与并推动多个Istio服务特性设计与研发。【课程大纲】课程围绕流量治理，及全景监控能力为中心进行讲解。介绍了负载均衡算法与会话保持的基础知识以及故障注入的应用场景和实现机制。对华为云istio服务流量治理中的故障注入，负载均衡配置等功能及应用性能监控，拓扑图，调用链等使用进行展示。学习完本课后，用户应当具备在华为云上独立动手进行流量治理功能的使用以及通过全景监控来验证配置生效的能力。【课程链接】可扫描下方二维码进入“华为云开发者联盟“移动端直播间收听课程

终于等到你，请收下这份丰厚的见面礼！【初识容器】华为云容器服务产品页>>点击初识  云容器引擎CCE    >>点击初识  云容器实例CCI【技术入门】云原生系列技术直播课>>深入剖析Kubernetes系列直播课（视频+资料）>>Istio入门实训课（视频+资料）>>CKA认证培训课（视频+资料）【课程进阶】云容器系统学习全掌握>>21天转型容器实战营（完整pdf资料）【云端实践】应用容器化部署初体验1. 云容器引擎CCE - Flappybird 容器化小游戏部署指南（内含源码）2. 云容器引擎CCE - FC经典坦克大战 容器化小游戏部署指南（内含源码）3. 云容器实例CCI – 经典2048数字合成游戏部署指南（内含镜像文件）4. 云容器实例CCI - 使用Tensorflow训练神经网络（内含详细PDF教程）希望以上内容真的能帮助到你，有任何疑问欢迎留言哦，期待你的反馈~

喜大普奔，华为云《21天转型容器实战营》课程资料大放送啦！本课程是由华为云DevCloud&云容器服务联合重磅出品，依托华为云云容器服务，带领开发者学习和体验Docker, kubernetes, Istio等大热技术！汇聚华为云顶级容器技术专家，结合CKA认证精编21天课程，零门槛带你打通容器技术任督二脉，攻下K8s，拿下CKA，那都不是事儿！干的不能再干的课程资料，已妥妥的备好，拿走不谢哦~Day 1 了解容器的基础知识Day 2 手把手教您制作镜像Day 3  手把手教您运行一个镜像Day 4 容器进阶之kubernetes基础知识介绍Day 5 容器进阶之Kubernetes pod调度原理分析Day 7 容器进阶之Kubernetes 应用生命周期原理分析Day 9 容器进阶之Kubernetes 网络管理原理分析Day 11 容器进阶之Kubernetes 存储管理原理分析Day 13 容器进阶之Kubernetes 安全原理分析Day 15 Istio服务网格技术与实践Day 16 Istio灰度发布任务的介绍与实践加图版Day 17 Istio流量治理与全景监控Day 18 ContainerOps介绍Day 19  基于containerOps进行容器化交付Day 20 容器应用编排介绍Day 21-通过AOS完成电商网站系统创建惊不惊喜，意不意外？话不多说，赶紧下载学习吧！Ps：以上为全部的理论资料，如果想看含讲师视频讲解版的，可以去华为云学院学习，传送门再Ps：云学院的课程里有理论+实践的部分，实践部分需要用到资源，大家视自身情况选择哦~

准备工作1. 建议先 点击此处 下载.rar格式的压缩文件，只需经过一次解压即可得到 .tar 格式的镜像打包文件“docker-2048”哦。2. 建议先 点击此处 购买CCI 9元超值体验套餐包，游戏部署体验更佳哦！~下面来是完整操作步骤步骤一：创建命名空间命名空间（namespace）是kubernetes 的一个典型概念，是一种在多个用户之间划分资源的方法，适用于用户中存在多个团队或项目的情况。当前CCI服务提供两种类型的资源：“通用计算型”和“GPU型”。创建命名空间时需要选择资源类型，后续创建的负载中容器就运行在此类型的集群上。1. 登录云容器实例管理控制台，左侧导航栏中选择“命名空间”。2. 选择创建“通用计算型“命名空间。点击“一键创建”即可获得一个全新的命名空间（cci-auto-1548297057827），用于对即将部署的游戏应用进行管理。   步骤二 部署工作负载工作负载是对Pod的服务化封装，当前CCI服务中主要支持无状态负载、短任务负载、定时任务负载等。本例中游戏应用以无状态负载的方式作为一个长稳应用部署在CCI服务中。1.  在左侧导航栏中选择“工作负载”，在右侧选择上一个步骤创建的命名空间，单击“创建负载”。2. 配置无状态负载基本信息 a. 填写负载名称； b. 选择POD数量；当配置多个Pod时，云容器实例会自动在Pod间做负载均衡。此处建议POD数量不小于2，否则无法保证应用的HA能力。c. 填写负载描述信息。3. 容器设置a. 选择镜像。点击“上传镜像”、在容器镜像服务中选择“页面上传”，选择组织，选择镜像文件，上传已下载至本地的镜像文件“docker-2048”即可。上传完毕后，返回创建无状态工作负载页面刷新， 即可看到刚刚上传的镜像，点击“使用该镜像”b. 根据需要配置容器规格及高级设置（存储、环境变量、健康检查、生命周期、启动命令和ConfigMap）。本示例请保持默认值不变，然后单击“下一步”。4. 访问设置关于负载的访问设置，有如下3种选项：不启用：负载不提供外部访问方式，适合一些计算类场景，只需计算完存储结果即可，无需与外部通信。内网访问：负载之间通过“负载域名:负载端口”互相访问。公网访问：通过弹性负载均衡，从外部访问访问负载。本示例中我们的小游戏应用需要能够通过公网进行访问，此处选择公网访问。a. 参考界面提示在弹性负载均衡的界面购买增强型ELB。购买后点击界面的刷新即可选择对应的ELB实例使用。b. 选择“ELB协议”：TCP/UDP本例中，数字游戏应用的流量只需要做四层负载均衡，在TCP层进行流量转发到容器中的指定端口（80）即可。c. 选择“负载端口协议”：TCPd. 选择负载端口配置，此处ELB端口系统会根据当前选择的ELB实例的端口占用情况，自动推荐可用端口。容器端口和具体部署的应用开放端口有关，本例中该容器实例开放端口80。e. 点击下一步。5. 规格确认后，点击提交，单击“返回负载列表”。在负载列表中，待负载状态为“运行中”，负载创建成功，本游戏应用即部署完成。步骤三 获取游戏应用访问地址1. 单击负载名称，进入负载详情页面2. 选择“访问配置 > 公网访问”Tab页，拷贝公网访问地址（即“ELB IP地址:端口”），即可在浏览器中访问本游戏应用。

第一步：点击https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/guidance/list，在领取免费集群弹窗中，勾选“我已阅读并同意上述条款”，点击“立即领取”，即可获得3天免费集群，并进入云容器引擎管理控制台。 第二步：在点击“资源管理”-“节点管理”，如图所示，获取弹性IP地址。第三步：点击 https://www.huaweicloud.com/product/aos.html 进入应用编排服务AOS产品首页，点击“立即使用”。第四步：在“模板市场”-“公共模板”-“行业场景模板”处，点击坦克大战模板的“创建堆栈”按钮。第五步：填写必填的信息，ip参数值处填写第三步获取到的弹性IP地址，点击“下一步”。 第六步：点击“创建堆栈”，即可完成操作。第七步：回到云容器引擎管理控制台，点击“工作负载”-“无状态”，然后点击“外部访问地址”，即可开始坦克大战游戏啦！

第一步：点击https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/guidance/list，在领取免费集群弹窗中，勾选“我已阅读并同意上述条款”，点击“立即领取”，即可获得3天免费集群，并进入云容器引擎管理控制台。  第二步：在云容器引擎管理控制台，点击“工作负载”-“无状态”- “创建无状态工作负载”如图所示。 第三步：如图所示，配置基本信息，实例数量1个，然后点击“下一步”。第四步：点击“添加容器”，如图所示。第五步：点选“第三方镜像”，镜像名称处 输入下面的镜像地址：swr.cn-north-1.myhuaweicloud.com/hc_cce/flappybird:latest第六步：如图所示，基本信息保持默认值不变，点击“下一步”。 第七步：点击“添加服务”，然后如图所示，填写服务名称，选择公网访问，弹性IP，注意容器端口处填 80 。配置完毕后 点击“确定”-“下一步”。 第八步：点击“创建”，即可完成无状态工作负载创建环节。可查看负载详情、返回负载列表。第九步：在工作负载列表中，点击“外部访问地址”，即可开始享受这一虐心小游戏啦~

Istio，是一个由Google，Lyft，IBM联合开发的开源项目，是服务网格（Service Mesh）技术的一个标准化的开源实现，致力于解决应用的微服务化组件之间的连接控制与安全、流量管理与可观测性。Istio是云原生领域在Kubernetes之后最受关注的项目，帮助容器技术实践者从基础设施层的“容器编排“进阶到应用层的“服务治理”。Istio先天与Kubernetes无缝衔接，了解并使用Istio可以极大地提升研发和运维的工作效率。Cloud Native Lives之Istio入门实训课课程主题直播介绍观看回放资料下载Istio架构与技术点此了解点击观看下载Istio Pilot与服务发现点此了解点击观看下载Istio Gateway设计与技术点此了解点击观看下载Istio灰度发布与技术实现点此了解点击观看下载Istio xDS协议解析点此了解点击观看下载Istio Mixer架构设计与应用点此了解点击观看下载讲师介绍Idouba.Zhang华为云Istio服务架构师，Istio开源项目贡献者现负责华为云容器服务Istio产品化工作，参与华为PaaS平台产品设计研发，在Kubernetes容器服务、微服务架构、云服务目录、大数据、APM、DevOps工具等多个领域有深入研究与实践。Star.Zhang华为云Istio服务高级工程师，Istio开源项目贡献者现负责华为云容器服务Istio产品化的设计和开发工作。参与华为PaaS平台产品设计研发，在Kubernetes容器服务、微服务、PaaS平台的运维管理等多个领域有深入研究与实践。Fisher.XuIstio开源项目Approver，华为云高级工程师，华为云容器核心开发者，Istio 社区核心贡献者负责华为云容器服务的设计与核心组件开发，对Istio有深入理解。 HzxuzhongIstio开源项目Approver，华为云容器服务核心开发者Istio/Kubernetes社区核心贡献者, 主要负责Istio稳定性与可扩展性以及社区代码检视。对容器、微服务有深入认识。目前主要在istio社区从事性能优化及NetworkScope的实现以支持大规模可扩展性。

 kubernetes管理员实训培训介绍本系列课程参考CKA (Certificted Kubernetes Administrator)* 知识体系进行课程设计，并结合华为在kubernetes项目推广过程中的实践经验，理论+实践让用户快速掌握kubernetes的使用和维护技能。课程主题直播介绍观看回放材料下载CKA考纲与K8S基础概念解读点此了解点击观看点此下载K8S调度管理实训点此了解点击观看点此下载K8S日志、监控与应用管理实训点此了解点击观看点此下载K8S网络管理实训点此了解点击观看点此下载K8S存储管理实训点此了解点此观看点此下载K8S安全管理实训点此了解点此观看点此下载K8S集群运维与安装配置实训点此了解点此观看点此下载K8S问题排查实训点此了解点此观看点此下载注：CKA (Certificted Kubernetes Administrator) 由 Linux 基金会和 CNCF 联合推出的一项认证计划。详见官网： https://www.cncf.io/certification/cka。主讲大咖介绍王泽锋华为云 Kubernetes 开源负责人，Kubernetes Maintainer华为云PaaS 服务团队核心成员，专注于PaaS产品和容器开源社区。曾主导社区NodeAffinity，PodAffinity，Taints-Tolerations，Forgiveness等多个关键特性的设计开发，对K8S有深入的见解。目前负责华为云K8S开源团队在社区贡献的整体工作。杜军华为云高级工程师，Kubernetes MaintainerKubernetes核心维护者，主导了Network SIG多个核心特性设计、开发，同时是Scheduling, Cluster-lifecycle SIG的子项目owner王波华为云容器服务高级工程师华为云容器服务核心开发者，K8S社区贡献者，负责华为云容器服务多个核心组件设计与开发，对Kubernetes有深入理解。Gloria.Zhao华为云高级工程师华为云容器核心开发者，负责华为云容器服务的设计与核心组件开发，对kubernetes有深入理解。

Cloud Native Lives之深入剖析Kubernetes系列课：课程主题直播介绍观看回放资料下载云原生技术的前世今生点此了解观看回放下载K8s初体验-快速部署第一个容器应用 点此了解观看回放下载K8s工作负载原理剖析和体验 点此了解观看回放下载K8s调度器原理剖析和实践点此了解观看回放下载K8S网络原理剖析和实践 点此了解观看回放下载K8S服务发现与负载均衡原理剖析与实践点此了解观看回放下载K8S存储原理剖析与实践     点此了解观看回放下载K8S安全原理剖析和实践点此了解观看回放下载优质品牌课程介绍：Cloud Native，云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives，系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。