1性能增强虽然Istio1.0的目标是生产可用，但从去年7月份发布以来，在性能和稳定性上并不能让用户满意。社区的Performance and Scalability工作组在Istio v1.1中做了大量的努力以提高控制面和数据面的性能，其中最明显的性能增强包括：Sidecar API，减少发给proxy的配置数量以及pilot负载。网络配置规则（Destinationrule,Virtualservie, ServiceEntry）中增加的 exportTo字段限制配置的可见范围。Envoy默认收集的统计数据大量减少。给mixer增加load-shedding功能，防止overload。提升envoy和mixer之间的交互协议。可配置并发线程数，提高吞吐量。可配置filter来约束mixer遥测数据。从对Istio 1.1的测试数据来看，这部分工作取得了显著的效果。1.1控制面性能表现Pilot的CPU和内存使用受网格内的配置和系统状态的影响，例如负载变化速率，配置变化速率，连接到Pilot的proxy的数量等。可以通过增加Pilot的实例数来减少配置分发处理的时间，提高性能。在网格内有1000个服务，2000 个sidecars，每秒1000请求下的表现：单Pilot 实例使用 1 vCPU 和1.5 GB 的内存。istio-telemetry服务使用0.6 vCPU。1.2数据面性能表现CPU：proxy在每秒1000个请求下大约消耗0.6 vCPU 。内存：proxy的内存消耗主要取决于它需要处理的配置数量，大量的listeners, clusters, and routes配置会增加内存使用。proxy每秒1000个请求下大约消耗50MB的内存。时延：数据在传输时会通过客户端和服务端的sidecar，传输路径上的这两个proxy在1000 rps情况下，99%的请求时延是10 ms（TP99），单独server端的proxy增加6ms的时延。如果启用策略会进一步增加时延。2多集群方案在1.0中只提供了一种基于扁平网络的多集群方案：Istio控制面部署在一个Kubernetes集群中。这种方案要求各集群的 Pod 地址不能重叠，且所有的 Kubernetes 控制平面API Server 互通。看上去就是物理上把多个Kubernetes并到一个Istio控制面下，在Istio看来是同一个网格。这种方案的网络要求苛刻，实际应用并不多。在新发布的1.1版本上，多集群上做了非常多的增强，除了保留1.0扁平网络作为一种单控制面的方案外，还提出了另外两种方案供用户根据实际环境和需求灵活选择，这两种方案都不要求是扁平网络：多控制面方案：在每个集群中安装完整的Istio控制面，可以看成是一种松散的联邦，集群间服务在Gateway处联通即可。通过一个全局的DNS将跨集群的请求路由到另外一个集群里去。这种集群的访问是基于Istio的ServiceEntry和Gateway来实现的，配置较多且复杂，需用户自己维护。一种集群感知（Split Horizon EDS）的单控制面方案：Istio控制面板只在一个Kubernetes集群中安装，Istio控制面仍然需要连接所有Kubernetes集群的Kube API Server。每个集群都有集群标识和网络标识。在服务间访问时，如果目标是本集群的负载，则类似单集群的方式直接转发；如果是其他集群的实例，则将流量转发到集群的入口网关上，再经过网关转发给实际对端。3安全3.1HTTP Readiness Liveness Probe自动重写mTLS模式下，进入Envoy的HTTP请求会在TLS握手阶段被拒绝。1.1新增加了HTTP Probe的自动重写，通过将HTTP Probe请求发送到pilot-agent由其转发HTTP探测到应用，进而绕开Envoy的TLS认证。默认自动重写是关闭状态，用户需要根据实际需要打开。3.2集群级别的RBAC设置ClusterRbacConfigRbacConfig被标记为废弃，用户升级1.1后，必须迁移到使用ClusterRbacConfig。因为RbacConfig有bug，在一些情况下，其作用范围会被缩小到命名空间。3.3SDSSDS（SecretDiscovery Service）通过节点密钥生成提供更强的安全性以及动态的证书回滚。可以取代目前使用secret卷挂载的方式提供证书。1.1中目前为alpha，不建议生产环境使用，但是随着Istio发展值得期待。3.4授权新增对TCP类型服务的RBAC授权以及基于用户组的授权。3.5Vault集成允许用户集成开源Vault，使用Vault CA签发证书。4网络4.1新的sidecar API资源在1.1中引入Sidecar这资源对象可以更精细的控制Envoy转发和接收的端口、协议。在指定命名空间中使用sidecar资源时，支持定义可访问的服务范围。这样可以降低发给proxy的配置的数量。在大规模的集群中，我们推荐给每个namespace增加sidecar的对象。 这个功能主要是为了提升性能，减轻pilot计算的负担。对proxy的影响是：1. 内存占用少，2. 降低网络带宽占用。  4.2exportTo在Istio1.1版本中添加了一个重要字段exportTo。用于控制VirtualService、DestinationRule和 ServiceEntry 跨Namespace的可见性。这样就可以控制一个Namespace下定义的资源对象是否可以被其他Namespace下的Envoy执行了。如果未赋值，则默认全局可见。当前版本中只支持“.”和“*”两种配置。 “.”表示仅应用到当前Namespace。“*”表示应用到所有Namespace。4.3Locality based loadbalancerIstio 1.1 引入了负载均衡新特性：基于位置的负载均衡。这也是华为主导的新特性。目前是alpha特性，只支持服务网格全局的位置感知的负载均衡设置：基于位置权重的负载均衡设置（Locality-weighted load balancing）：Locality-weighted load balancing允许管理员基于流量来源及终止的位置信息控制流量的分发。例如可以设置从源位置{region}/{zone}/{sub-zone}的工作负载发出的流量转发到目的位置的endpoints负载均衡权重：用户可以为相同区域的工作负载访问设置较高的权重，为不同区域的工作负载设置较小的权重，减少网络延迟。基于位置的故障转移设置：类似于Envoy的“Zone aware routing”负载均衡策略，基于位置的故障转移特性，通过为不同的位置的endpoints设置不同的优先级，控制流量的转发策略。默认设置如下，同一位置{region}/{zone}/{sub-zone}的endpoints优先级最高，同一{region}/{zone}的endpoints优先级次之，同一region的endpoints第三，最后故障转移设置区域以及其他区域的endpoints依次。endpoints全部健康的情况下，流量只会在同一{region}/{zone}/{sub-zone}转发。当endpoint变得不健康时，会进行相应的降级处理，选择低优先级的endpoints转发。4.4pilot配置资源发现Istio1.1将galley作为默认的 配置规则发现中心，pilot通过MCP协议与galley进行配置订阅，取代1.0以前直接从Kubernetes以CR的方式watch配置资源。5策略和遥测默认关闭策略检查功能 为了提高多数客户场景下的性能，安装时默认关闭策略检查， 后期可按需开启此功能。弃用ServiceGraph，推荐使用 Kiali：提供了更丰富的可视化体验。多方面降低开销 ，提升性能和可扩展性：o 减少Envoy生成的统计数据的默认收集o Mixer的工作负载增加load-shedding功能o 改进Envoy和Mixer的通信协议控制请求头和路由 增加选项使适配器可以修改请求头和路由进程外适配器 进程外适配器功能生产可用，下个release弃用进程内适配器。多方面增强Tracing的能力： o Trace id支持128bit的范围o 支持向LightStep发送追踪数据o 增加选项完全禁用Mixer支持的服务的追踪功能o 增加策略的decision-aware 追踪默认的TCP指标 为追踪TCP连接增加默认指标降低Addon对Load Balancer的依赖 不再通过独立的load balancers对外暴露addons，而是通过Istio gateway来暴露插件服务。安全的Addon证书 改变插件的证书存储方式。Grafana, Kiali, and Jaeger的用户名和密码存放在kubernetes的secrets中以提高安全性和合规性。去除内置的statsd collector。Istio目前支持用户自己的statsd，以提高现有Kubernetes部署的灵活性。另外，Istio运维管理的复杂度也不能被部分用户接受（比如：众多的crd资源），因此社区专门成立了User Experience工作组致力于提高Istio的易用性，进一步降低其使用门槛。经过大家的共同努力，Istio1.1版本几经推迟终于发布了！我们有理由对其充满期待和信心，共同催熟以Istio为代表的云原生服务网格技术，为我们的用户提供高品质的云服务体验。欢迎试用华为云应用服务网格Istio。相关服务请访问： https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019

之前给大家讲了构建镜像的原理，那么有了镜像之后，我们怎么样能将它快速的部署到kuberentes集群上呢？ 早期，大家都习惯于使用kubernetes接口，或者cli命令行来完成这些操作，但是yaml文件语法的复杂性、大量容器和kuernetes的概念，让人难以理解，无疑成为容器化交付路上的又不障碍。为了解决这些问题，华为云容器服务推出了向导式镜像部署，通过一步步引导、对复杂概念的屏蔽或抽象，在一定程度上降低了用户首次部署镜像的难度，但是灵活度相对较差，对于经常变更版本的场景，还是需要使用原生接口进行操作，使得整体研发交付流程的复杂度并未降低太多。鉴于此现状华为云容器团队又推出了一款易用性更好、自动化程度更高的服务产品——容器交付流水线，它以容器技术为基础，践行DevOps的理念，围绕容器业务端到端场景提供持续集成和持续交付能力，包括代码编译、镜像构建与交付、自动化部署、升级回滚等能力，并提供全量能力接口，便于与企业已有流程相结合，同时接口屏蔽底层容器概念，对接口进行了二次封装，接口定义更贴近于CI/CD业务概念，使得熟悉CI/CD流程的用户能快速切换。发布组件作为该产品的一个重要组成部分，其直接影响了整个发布周期，我们今天就跟大家一起聊聊该部件的一些实现原理。01Kubernetes DeploymentKubernetes Deployment提供了官方的用于更新Pod和ReplicaSet（下一代的Replication Controller）的方法，我们可以在Deployment对象中填写我们需要用到的配置和版本信息，Deployment控制器将现在的实际状态转换成我们所期望的状态，例如，将nginx:v1.0升级成nginx:v2.0，我们只需创建一个Deployment，Kubernetes会按照Deployment自动进行升级。而随着Kubernetes的迭代更新，目前云容器引擎服务提供了几个版本的集群，那么如何使得部署组件支持不同的集群版本呢？由于我们的CI/CD的工具提供了deployment的yaml页面编辑，部署组件会根据deployment中apiversion即：apps/v1, apps/v1beta1, extensions/v1beta1。提供不同版本的API接口。自行封装接口使得发布组件自主能动性强，免于受制于第三方库。02如何判断发布成功？解决了版本问题，还有一个最重要的问题，是如何判断组件发布结果呢？对于一个CI/CD工具，我们判断工作负载运行成功的标准并不仅仅是Pod处于running状态又或者工作负载处于可用状态。我们需要保证的是工作负载运行的镜像或者配置是新版本的。因此我们判断成功的标志应该是新起的pod处于running状态，那如何找到这些新起的pod呢？下图展示了Deployment，ReplicaSet和Pod之间的关系，以无状态工作负载为例，我们通过查询deployment中Annotations的"deployment.kubernetes.io/revision"，根据这个revision寻找Deployment控制的ReplicaSet。最后根据ReplicaSet的label去寻找这些新起的pod。我们已经找到这些新起的Pod了，那么现在就需要对pod的状态进行分析了。在K8s源码中PodPhase字段表示了pod的不同阶段：Pending: k8s已经接受创建pod的请求，但是容器并没有启动成功，这个阶段包括调度之前的，下载镜像等。 Running: pod已经绑定到node节点，并且所有的容器已经启动成功，或者至少有一个容器在运行，或者在重启中。 Succeeded: pod中的所有的容器已经正常的自行退出，并且k8s永远不会自动重启这些容器。 Failed: pod中的所有容器已经终止，并且至少有一个容器已经终止于失败（退出非零退出代码或被系统停止）。 Unknown: 由于一些未知的原因，无法获得pod的状态，通常是因为pod的主机通信错误。而以上四个阶段只是一个粗略状态阶段。而对于每一个阶段都有更详细的pod conditions信息，podcondition数组的元素都包含了类型和状态字段，这个类型分为以下四种:"Ready"：Pod能够提供服务"PodScheduled"：pod正处于调度中"Unschedulable"：调度程序现在无法调度Pod，例如由于缺乏资源或其他限制;"Initialized"：所有pod的容器初始化已经完成。"ContainersReady"：pod中的容器都已准备好。其中状态字段用"true" 表示处于,"false"表示不处于，我们发现当阶段为Running, condition中Ready状态为True时， 即表示pod中的容器可以提供服务了。因此，我们现在就可以依次判断新起的pod是否升级成功了。03如何判断发布失败？现在我们能够判断成功了，下一步就需要对失败的状态进行一个判断，其实理论上负载的成功或者失败不是一个确定性的东西，k8s本身具有重试机制，也存在概率性调度失败的情况。所以一开始我们考虑的是通过一个超时机制来判断发布失败的情况。但后面分析考虑到，发布作为一个重要的组件，需要第一时间知道问题所在，以致可以快速进行版本回退等操作。对于容器的状态，pod中的containerstatus包含了更详细的当前容器的状态。其state字段表示容器当前的状态，state分为三种状态：等待中，运行中和已终止，对应三种不同类型的结构体。等待中的结构体包含了处于非运行状态的原因和信息。其他结构体就不在此一一赘述。结合podphase、podcondition、以及containerstatus，我们总结了如下几个升级异常状态（如有不全，欢迎补充）：PodPhase == FailedPodPhase == SucceededContainerStatuses 中有一项为state.waiting 并且 waiting 的原因不是ContainerCreating 或者 PodInitializing(ContainerCreating表示容器创建中，PodInitializing表示pod初始化中)ContainerStatuses 中有一项为state.running 并且 containerStatuses.ready == falseConditions中存在一项的type为Ready且status为False且Containerstatues存在Conditions中存在一项的type为PodScheduled且status为False：调度失败由于pod的状态是动态变化的，为了保证发布结果的准确性，我们选择pod超过3次时置为失败状态，即发布失败。看完上面这些原理解析，您是不是有什么收获，或者有什么想法与我们交流呢？请在下方留下您宝贵意见和建议吧？说不定下个版本，您的创意就会出现在我们的产品里。相关服务请访问https://www.huaweicloud.com/product/swr.html?cce_helpcenter_2019

2018年，华为人一直在路上前进的同时不忘记录身边美好视线所及的边际正在不断突破留下记忆，同时也留下一份与万物的联系2019到了，新的一年打开新视界，一起看世界不经历风雨怎么见彩虹再见，2018你好，2019勇敢不止步，探索联万物伊苏尔火山喷发的火花犹如智能未来的能量春暖花开，片片樱花散落在路边铺设了延绵三公里的伊豆高原浪漫之路在风景如画的松山湖基地，华为人描绘出智能未来的蓝图并全力付诸实践知识是海洋？是峡谷？即使在家中书房创意无处不在，创新无所不及摩纳哥海滩上的戏水少年挥洒着青春活力人们渴望与大自然亲近，从联接到触碰夕阳陪同，落霞余晖，如此恬静的荷兰海牙人和动物，在自然中温馨无惧惊涛，专注垂钓于奥克兰的海岸边勇敢者的意志与巨浪的奔涌，相互辉映象群缓慢安然地散步在肯尼亚草原上它们的漫步圣地需要我们好好保护布宜诺斯艾利斯的夕阳渐渐氤氲成烟霞广阔天地之间，总有努力拼搏渲染的灿烂奔跑本身即是探索更高更远的边界从小开始，奔跑向未来白雪皑皑，一片宁静黑天鹅依旧悠闲划破平静湖面

调用链原理和场景正如Service Mesh的诞生是为了解决大规模分布式服务访问的治理问题，调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器，可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用上链路上出现问题都比较复杂，如何定位就比单进程的一个服务打印一个异常栈来找出某个方法要困难的多。需要有一个类似的调用链路的跟踪，经一次请求的逻辑规矩完整的表达出来，可以观察到每个阶段的调用关系，并能看到每个阶段的耗时和调用详细情况。Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制。模型中包含的术语也很多，理解最主要的两个即可：Trace：一次完整的分布式调用跟踪链路。Span：跨服务的一次调用； 多个Span组合成一次Trace追踪记录。上图是Dapper论文中的经典图示，左表示一个分布式调用关系。前端（A），两个中间层（B和C），以及两个后端（D和E）。用户发起一个请求时，先到达前端，再发送两个服务B和C。B直接应答，C服务调用后端D和E交互之后给A应答，A进而返回最终应答。要使用调用链跟踪，就是给每次调用添加TraceId、SpanId这样的跟踪标识和时间戳。右表示对应Span的管理关系。每个节点是一个Span，表示一个调用。至少包含Span的名、父SpanId和SpanId。节点间的连线下表示Span和父Span的关系。所有的Span属于一个跟踪，共用一个TraceId。从图上可以看到对前端A的调用Span的两个子Span分别是对B和C调用的Span，D和E两个后端服务调用的Span则都是C的子Span。调用链系统有很多实现，用的比较多的如zipkin，还有已经加入CNCF基金会并且的用的越来越多的Jaeger，满足Opentracing语义标准的就有这么多。一个完整的调用链跟踪系统，包括调用链埋点，调用链数据收集，调用链数据存储和处理，调用链数据检索（除了提供检索的APIServer，一般还要包含一个非常酷炫的调用链前端）等若干重要组件。上图是Jaeger的一个完整实现。这里我们仅关注与应用相关的内容，即调用链埋点的部分，看下在Istio中是否能做到”无侵入“的调用链埋点。当然在最后也会看下Istio机制下提供的不同的调用链数据收集方式。Istio标准BookInfo例子简单期间，我们以Istio最经典的Bookinfo为例来说明。Bookinfo模拟在线书店的一个分类，显示一本书的信息。本身是一个异构应用，几个服务分别由不同的语言编写的。各个服务的模拟作用和调用关系是：productpage ：productpage 服务会调用 details 和 reviews 两个服务，用来生成页面。details ：这个微服务包含了书籍的信息。reviews ：这个微服务包含了书籍相关的评论。并调用 ratings 微服务。ratings ：ratings 微服务中包含了由书籍评价组成的评级信息。调用链输出在Istio上运行这个典型例子，不用做任何的代码修改，自带的Zipkin上就能看到如下的调用链输出。可以看到展示给我们的调用链和Boookinfo这个场景设计的调用关系一致：productpage 服务会调用 details 和 reviews 两个服务，reviews调用了ratings 微服务。除了显示调用关系外，还显示了每个中间调用的耗时和调用详情。基于这个视图，服务的运维人员比较直观的定界到慢的或者有问题的服务，并钻取当时的调用细节，进而定位到问题。我们就要关注下调用链埋点到底是在哪里做的，怎么做的？在Istio中，所有的治理逻辑的执行体都是和业务容器一起部署的Envoy这个Sidecar，不管是负载均衡、熔断、流量路由还是安全、可观察性的数据生成都是在Envoy上。Sidecar拦截了所有的流入和流出业务程序的流量，根据收到的规则执行执行各种动作。实际使用中一般是基于K8S提供的InitContainer机制，用于在Pod中执行一些初始化任务. InitContainer中执行了一段iptables的脚本。正是通过这些Iptables规则拦截pod中流量，并发送到Envoy上。Envoy拦截到Inbound和Outbound的流量会分别作不同操作，执行上面配置的操作，另外再把请求往下发，对于Outbound就是根据服务发现找到对应的目标服务后端上；对于Inbound流量则直接发到本地的服务实例上。我们今天的重点是看下拦截到流量后Sidecar在调用链埋点怎么做的。 Istio调用链埋点逻辑Envoy的埋点规则和在其他服务调用方和被调用方的对应埋点逻辑没有太大差别。Inbound流量：对于经过Sidecar流入应用程序的流量，如果经过Sidecar时Header中没有任何跟踪相关的信息，则会在创建一个根Span，TraceId就是这个SpanId，然后再将请求传递给业务容器的服务；如果请求中包含Trace相关的信息，则Sidecar从中提取Trace的上下文信息并发给应用程序。Outbound流量：对于经过Sidecar流出的流量，如果经过Sidecar时Header中没有任何跟踪相关的信息，则会创建根Span，并将该跟Span相关上下文信息放在请求头中传递给下一个调用的服务；当存在Trace信息时，Sidecar从Header中提取Span相关信息，并基于这个Span创建子Span，并将新的Span信息加在请求头中传递。特别是Outbound部分的调用链埋点逻辑，通过一段伪代码描述如图：调用链详细解析如图是对前面Zipkin上输出的一个Trace一个透视图，观察下每个调用的细节。可以看到每个阶段四个服务与部署在它旁边上的Sidecar是怎么配合的。在图上只标记了Sidecar生成的Span主要信息。因为Sidecar 处理 Inbound和Outbound的逻辑有所不同，在图上表也分开两个框图分开表达。如productpage，接收外部请求是一个处理，给details发出请求是一个处理，给reviews发出请求是另外一个处理，因此围绕productpage这个app有三个黑色的处理块，其实是一个Sidecar在做事。同时，为了不使的图上箭头太多，最终的Response都没有表达出来，其实图上每个请求的箭头都有一个反方向的Response。在服务发起方的Sidecar会收到Response时，会记录一个CR(client Received)表示收到响应的时间并计算整个Span的持续时间。下面通过解析下具体数据来找出埋点逻辑： 首先从调用入口的Gateway开始，Gateway作为一个独立部署在一个pod中的Envoy进程，当有请求过来时，它会将请求转给入口服务productpage。Gateway这个Envoy在发出请求时里面没有Trace信息，会生成一个根Span：SpanId和TraceId都是f79a31352fe7cae9，因为是第一个调用链上的第一个Span，也就是一般说的根Span，所有ParentId为空，在这个时候会记录CS（Client Send）；请求从入口Gateway这个Envoy进入productpage的app业务进程其Inbound流量被productpage Pod内的Envoy拦截，Envoy处理请求头中带着Trace信息，记录SR(Server Received)，并将请求发送给productpage业务容器处理，productpage在处理请求的业务方法中在接受调用的参数时，除了接受一般的业务参数外，同时解析请求中的调用链Header信息，并把Header中的Trace信息传递给了调用的Details和Reviews的微服务。从productpage出去的请求到达reviews服务前，其Oubtbound流量又一次通过同Pod的Envoy，Envoy埋点逻辑检查Header中包含了Trace相关信息，在将请求发出前会做客户端的调用链埋点，即以当前Span为parent Span，生成一个子Span：新的SpanId cb4c86fb667f3114，TraceId保持一致9a31352fe7cae9，ParentId就是上个Span的Id： f79a31352fe7cae9。从prodcutepage到review的请求经过productpage的Sidecar走LB后，发给一个review的实例。请求在到达Review业务容器前，同样也被Review的Envoy拦截，Envoy检查从Header中解析出Trace信息存在，则发送Trace信息给reviews。reviews处理请求的服务端代码中同样接收和解析出这些包含Trace的Header信息，发送给下一个Ratings服务。在这里我们只是理了一遍请求从入口Gateway，访问productpage服务，再访问reviews服务的流程。可以看到期间每个访问阶段，对服务的Inbound和Outbound流量都会被Envoy拦截并执行对应的调用链埋点逻辑。图示的Reviews访问Ratings和productpage访问Details逻辑与以上类似，这里不做复述。以上过程也印证了前面我们提出的Envoy的埋点逻辑。可以看到过程中除了Envoy再处理Inbound和Outbound流量时要执行对应的埋点逻辑外。每一步的调用要串起来，应用程序其实做了些事情。就是在将请求发给下一个服务时，需要将调用链相关的信息同样传下去，尽管这些Trace和Span的标识并不是它生成的。这样在出流量的proxy向下一跳服务发起请求前才能判断并生成子Span并和原Span进行关联，进而形成一个完整的调用链。否则，如果在应用容器未处理Header中的Trace，则Sidecar在处理请求时会创建根Span，最终会形成若干个割裂的Span，并不能被关联到一个Trace上，就会出现我们开始提到的问题。不断被问到两个问题来试图说明这个业务代码配合修改来实现调用链逻辑可能不必要：问题一、既然传入的请求上已经带了这些Header信息了，直接往下一直传不就好了吗？Sidecar请求APP的时候带着这些Header，APP请求Sidecar时也带着这些Header不就完了吗？问题二、既然TraceId和SpanId是Sidecar生成的，为什么要再费劲让App收到请求的时候解析下，发出请求时候再带着发出来传回给Sidecar呢？回答问题一，只需理解一点，这里的App业务代码是处理请求不是转发请求，即图上左边的Request to Productpage 到prodcutpage中请求就截止了，要怎么处理完全是productpage的服务接口的内容了，可以是调用本地处理逻辑直接返回，也可以是如示例中的场景构造新的请求调用其他的服务。右边的Request from productpage 完全是服务构造的发出的另外一个请求；回答问题二，需要理解当前Envoy是独立的Listener来处理Inbound和Outbound的请求。Inbound只会处理入的流量并将流量转发到本地的服务实例上。而Outbound就是根据服务发现找到对应的目标服务后端上。除了实在一个进程里外两个之间可以说没有任何关系。 另外如问题一描述，因为到Outbound已经是一个新构造的请求了，使得想维护一个map来记录这些Trace信息这种方案也变得不可行。这样基于一个例子来打开看一个调用链的主要过程就介绍到这里。附加productpage访问reviews的Span详细，删减掉一些数据只保留主要信息大致是这样：Productpage的Proxy上报了个CS，CR, reviews的那个proxy上报了个SS，SR。分别表示Productpage作为client什么时候发出请求，什么时候最终收到请求，reviews的proxy什么时候收到了客户端的请求，什么时候发出了response。另外还包括这次访问的其他信息如Response Code、Response Size等。根据前面的分析我们可以得到结论：埋点逻辑是在Sidecar代理中完成，应用程序不用处理复杂的埋点逻辑，但应用程序需要配合在请求头上传递生成的Trace相关信息。服务代码修改示例前面通过一个典型例子详细解析了Istio的调用链埋点过程中Envoy作为Sidecar和应用程序的配合关系。分析的结论是调用链埋点由Envoy来执行，但是业务程序要有适当修改。下面抽取服务代码来印证下。Python写的 productpage在服务端处理请求时，先从Request中提取接收到的Header。然后再构造请求调用details获取服务接口，并将Header转发出去。首先处理productpage请问的rest方法中从Request中提取Trace相关的Header。然后重新构造一个请求发出去，请求reviews服务接口。可以看到请求中包含收到的Header。reviews服务中Java的Rest代码类似，在服务端接收请求时，除了接收Request中的业务参数外，还要提取Header信息，调用Ratings服务时再传递下去。其他的productpage调用details，reviews调用ratings逻辑类似。当然这里只是个demo，示意下要在那个位置修改代码。实际项目中我们不会这样在每个业务方法上作这样的修改，这样对代码的侵入，甚至说污染太严重。根据语言的特点会尽力把这段逻辑提取成一段通用逻辑。Istio调用链数据收集：by Envoy一个完整的埋点过程，除了inject、extract这种处理Span信息，创建Span外，还要将Span report到一个调用链的服务端，进行存储并支持检索。在Isito中这些都是在Envoy这个Sidecar中处理，业务程序不用关心。在proxy自动注入到业务pod时，会自动刷这个后端地址.即Envoy会连接zipkin的服务端上报调用链数据，这些业务容器完全不用关心。当然这个调 用链收集的后端地址配置成jaeger也是ok的，因为Jaeger在接收数据是兼容zipkin格式的。Istio调用链数据收集：by Mixer除了直接从Envoy上报调用链到zipkin后端外，Istio提供了Mixer这个统一的面板来对接不同的后端来收集遥测数据，当然Trace数据也可以采用同样的方式。即如TraceSpan中描述，创建一个TraceSpan的模板，来描述从mixer的一次访问中提取哪些数据，可以看到Trace相关的几个ID从请求的Header中提取。除了基础数据外，基于Mixer和kubernetes的继承能力，有些对象的元数据，如Pod上的相关信息Mixr可以补充，背后其实是Mixer连了kubeapiserver获取对应的pod资源，从而较之直接从Envoy上收集的原始数据，可以有更多的业务上的扩张，如namespace、cluster等信息APM数据要用到，但是Envoy本身不会生成，通过这种方式就可以从Kubernetes中自动补充完整，非常方便。这也是Istio的核心组件Mixer在可观察性上的一个优秀实践。Istio官方说明更新最近一直在和社区沟通，督促在更显著的位置明确的告诉使用者用Istio作治理并不是所有场景下都不需要修改代码，比如调用链，虽然用户不用业务代码埋点，但还是需要修改些代码。尤其是避免首页“without any change”对大家的误导。得到回应是1.1中社区首页what-is-istio已经修改了这部分说明，不再是1.0中说without any changes in service code，而是改为with few or no code changes in service code。提示大家在使用Isito进行调用链埋点时，应用程序需要进行适当的修改。当然了解了其中原理，做起来也不会太麻烦。改了个程度轻一点的否定词，很少几乎不用修改，还是基本不用改的意思。这也是社区一贯的观点。结合对Istio调用链的原理的分析和一个典型例子中细节字段、流程包括代码的额解析，再加上和社区沟通的观点。得到以下结论：Istio的绝大多数治理能力都是在Sidecar而非应用程序中实现，因此是非侵入的；Istio的调用链埋点逻辑也是在Sidecar代理中完成，对应用程序非侵入，但应用程序需做适当的修改，即配合在请求头上传递生成的Trace相关信息。华为云Istio服务网格公测中在腾讯的场子上只讲干货的技术，尽量少做广告。在这里只是用一页PPT来简单介绍下华为云当前正在公测的Istio服务网格服务。华为云容器引擎CCE的深度集成，一键启用后，即可享受Istio服务网格的全部治理能力；基于应用运行的全景视图配置管理熔断、故障注入、负载均衡等多种智能流量治理功能；内置金丝雀、A/B Testing典型灰度发布流程灰度版本一键部署，流量切换一键生效；配置式基于流量比例、请求内容灰度策略配置，一站式健康、性能、流量监控，实现灰度发布过程量化、智能化、可视化；集成华为云APM，使用调用链、应用拓扑等多种手段对应用运行进行透视、诊断和管理。华为云Istio社区贡献华为作为CNCF 基金会的初创会员、白金会员，CNCF / Kubernetes TOC 成员。在Kubernetes社区贡献国内第一，全球第三，全球贡献3000+ PR，先后贡献了集群联邦、高级调度策略、IPVS负载均衡，容器存储快照等重要项目。随着Istio项目的深入产品化，团队也积极投入到Istio的社区贡献。当前社区贡献国内第一，全球第三。Approver 3席，Member 6席，Contributor 若干。通过Pilot agent转发实现HTTP协议的健康检查： 针对mTLS enabled环境，传统的kubernetes http健康检查不能工作，实现 sidecar转发功能，以及injector的自动注入。Istioctl debug功能增强：针对istioctl缺失查询sidecar中endpoint的能力，增加proxy-config endpoint、proxy-status endpoint命令，提高debug效率。HTTPRetry API增强： 增加HTTPRetry 配置项RetryOn策略，可以通过此控制sidecar重试。MCP 配置实现： Pilot支持mesh configuration, 可以与galley等多个实现了MCP协议的server端交互获取配置。以此解耦后端注册中心。Pilot CPU异常问题解决：1.0.0-snapshot.0 pilot free 状态CPU 利用率超过20%，降低到1%以下。Pilot 服务数据下发优化：缓存service，避免每次push时进行重复的转换。Pilot服务实例查询优化：根据label selector查询endpoints（涵盖95%以上的场景），避免遍历所有namespace的endpoints。Pilot 数据Push性能优化：将原有的串行顺序推送配置，更新为并行push，降低配置下发时延。

kubernetes 的没有吗？

11月13-15日，由云原生计算基金会（CNCF）发起的国际顶级技术盛会KubeCon + CloudNativeCon 2018（以下简称KubeCon）又如期而至~作为技术圈的“武林大会”，这次把地点瞄准了在上海跨国采购会展中心。今天的上海可谓是吸睛十足，海内外业界技术专家、架构师、开发者等各路高手齐聚一堂，还有近200场的议题以Kubernetes为代表的云原生技术准备头脑风暴，作为技术真爱粉的你，又怎么能错过？话不多说，快跟着小云一起往下看吧~作为本次大会的钻石赞助商和容器技术的领导者，华为云到场出席并作了20场议题分享。11月15日，华为云BU PaaS产品部总经理廖振钦在全体大会上，发表《进入垂直行业，Kubernetes帮助各产业加速向云原生迁移》的主题演讲，分享了华为云在云原生技术领域的创新实践与行业使能成果，并宣布开源基因容器框架KubeGene和智能边缘框架KubeEdge，促进加速构建K8S的开放生态，加速行业使能。 华为云BU PaaS产品部总经理廖振钦作主题演讲深耕容器领域，持续创新实践 作为Kubernetes领域的早期践行者，华为云与Kubernetes领域渊源颇深。在2015年，华为就首次加入了Kubernetes社区，并作为创始会员之一参与发起了CNCF基金会；2016年，国内第一家发布基于K8S的容器服务CCE；2017年第一批成为全球K8S认证的服务提供商，并且CCE也首批通过了K8S的一致性认证。3年来，华为在基金会领域持续积极贡献：在Kubernetes领域，华为先后贡献了集群联邦、高级调度策略、IPVS负载均衡，容器存储快照等重要项目。并通过CloudNativeLives直播、参与组织各类技术峰会和云原生技术沙龙、发表技术文章等的形式，持续贡献力量助力构建国内云原生生态。截止目前，华为云在CNCF基金会，全球贡献3000+ PR，全球排名第三，国内排名第一。基于自身实践与持续创新，华为云将容器技术通过云服务的方式，提升客户创新速度与效率。咪咕互娱、猪八戒、秒拍等企业，都在基于华为云的容器服务，加速自身数字化转型。针对人工智能场景，华为云在今年10月的华为全联接大会上，为客户量身打造了AI容器产品，全球首发了基于K8S的serverless容器服务CCI，CCI可以对接业界主流AI计算框架（如Tensorflow、Caffe）的核心引擎，让客户体验到强劲、高效的AI容器计算引擎。加码行业使能，开源两项云原生技术 随着云原生技术的快速发展，越来越多的行业客户开始尝试使用容器技术来提升自身IT效率。但随之发现，一些行业GAP已经成为高效部署容器技术的障碍壁垒，其中最典型的就是基因测序与边缘计算两个行业场景。基因测序在生命科学研究中扮演着不容小觑的角色，大量的数据也有了更高质高效的数据处理需求，然而计算非常密集，对资源利用率非常敏感；波峰波谷业务量差异大；行业工具繁多，流程标准不统一，环境搭建复杂度高。结合基因测序的场景，我们发现，容器技术非常符合基因行业使用，但K8S流程框架过于复杂，行业人员学习和掌握K8S的成本过高，这已成为制约行业发展的绊脚石。此前，华为云就有针对性的发布了基因容器服务GCS，将K8S做了封装，让基因行业可以迅速部署和使用容器技术，帮助基因行业的用户提高资源利用率，轻松应对波峰波谷，降低环境搭建的复杂性。图灵生物携手华为云，利用CCE快速弥补了行业短板，从而专注业内技术的创新，加大在仪器优化、技术更新、产品迭代方面的投入，快人一步，成为行业领军者。同时，作为从云到端的“最后一公里”，边缘计算具备降低带宽使用和网络延迟，实现更高效的数据处理等优势。然而，边缘场景同时面临6大痛点：云、边通信受限；高度分散的海量边缘节点；端侧设备多样化；边侧资源可能受限；边侧安全控制管理；边侧的自治与恢复。华为云智能边缘平台IEF (Intelligent EdgeFabric)，除了解决上述六大问题外，还充分发挥华为软硬件协同的全栈技术实力，以及”云-边-端”三位一体的全栈智能服务的优势，提供从芯片、网络、硬件、边缘云服务、AI全栈一体化的智能边缘产品，帮助客户轻松构建智能边缘。该方案可广泛适用于平安城市、工业制造、车联网等领域，通过在云端进行模型训练、边缘侧推理预测，从而实现云端和边缘的高效协同。鉴于基因测序与边缘场景的行业难题，在本次大会现场，华为云宣布开源了两款技术: 基于容器技术的一站式基因测序计算框架KubeGene与基于Kubernetes架构平台的管理框架KubeEdge。其中，KubeGene主要包含针对基因测序的流程描述语法、接近SGE体验的命令行工具、根据基因流程定制的工作流引擎和基因测序的最佳实践流程，让基因组测序变得更省钱、更省时、更省力，加速基因企业云端创新。KubeEdge不仅具有支持离线自主 pod 执行、低内存边缘计算节点、边缘服务访问、注册和发现（边到数据中心云和边到边）等功能，更是对Kubernetes 边缘云环境平台的扩展。 廖振钦表示：“ 华为云开源这两款技术，意在助力构建基因和智能边缘领域的K8S开放生态，让行业开发者更容易搭建和尝试K8S技术，降低行业客户使用这些新技术的门槛。未来，华为云将基于云原生技术持续创新，助力繁荣生态，致力于为企业提供更加安全、便捷、高效的服务，使能更多行业快速发展。

本期简介本期直播是华为云kubernetes管理员实训课程的第二课，由华为云 Kubernetes 开源负责人王泽锋讲解，将为您解读K8S的调度管理，让您对K8S调度管理有一个基本的理解和认识。点击看直播时间：9月27日 周四  20:00  （今晚）精彩内容值得期待~等你哦~

本期简介本期直播是华为云kubernetes管理员实训课程的第一课，由华为云 Kubernetes 开源负责人王泽锋讲解，将为您解读CKA考试大纲与K8S基础概念，让您对CKA考试和K8S有一个基本的理解和认识。课程主题CKA考纲与K8S基础概念解读直播时间9月20日 周四 晚20:00-21:00专家介绍王泽锋华为云 Kubernetes 开源负责人，Kubernetes Maintainer。华为云PaaS 服务团队核心成员，专注于PaaS产品和容器开源社区。曾主导社区NodeAffinity，PodAffinity，Taints-Tolerations，Forgiveness等多个关键特性的设计开发，对K8S有深入的见解。目前负责华为云K8S开源团队在社区贡献的整体工作。

云早报，(北京时间)9月3日，星期一【云头条】谷歌将 Kubernetes 控制权转移给 CNCF（云原生计算基金会）谷歌近日宣布，它将向云原生计算基金会（CNCF）提供价值900万美元的谷歌云积分（credit），帮助促进和推动其在Kubernetes容器编排工具方面的工作，谷歌还将该项目的运营控制权交给了这个社区。这些积分将在三年内享用，用于支付构建、测试和分发Kubernetes软件的基础设施成本。150000个容器，因此运行这些系统的成本迅速积少成多。自项目启动以来，Kubernetes容器注册中心的下载量已将近1.3亿人次。【华为云新闻】华为发布云管网络2.0 将“智简”做到极致 近日，在北京举办的“云网融天下，智简赢未来”云管理网络发布会，华为正式发布华为云管理网络2.0平台，并正式入驻华为公有云，即日起可登录Huawei Cloud申请免费试用。同时，华为宣布与上海文骋、新网程和汉朔科技等行业伙伴进行合作。自去年云网络转型以来，华为在数据中心网络，企业园区专线、管域网络和安全方面都进行了诸多的实践，助力700多家企业客户走向数字化转型。据了解，近十年时间华为共投入3900亿资金研发，截至目前华为在此领域专利超过74000多件，并在360多个标准组织中发挥了重要作用。【互联网新闻】1.京东称调查未发现刘强东有不当行为，美国警方称正在调查中尚未有结论昨天，一张关于明尼苏达州治安官方网站截图盛传社交网站，截图信息显示京东创始人兼CEO刘强东在美国明尼苏达州因涉及性侵女大学生而遭当地警方逮捕。随后，京东对外声明称“刘强东先生在美国商务活动期间，遭遇到了失实指控，经过当地警方调查，未发现有任何不当行为”，并指责网络传播上有不实传言。但负责调查该案件的明尼苏达州明尼阿波利斯市警方发言人John Elder对网易财经称，该案件目前正处于调查中，自己对当事人对外称的声明结果——“经过当地警方调查，未发现有任何不当行为”并不知情。网友评论：借用王思聪的一句话：“奶茶变抹茶了”。2.阿里病逝员工妻子：起诉自如已获立案 9月27日开庭刚入职阿里不久的王先生租自如的房子2个多月后，便在首都医科大学附属北京朝阳医院被确诊为急性髓系白血病并过世。病逝后，王先生的妻子英子（化名）来到丈夫生前租住在杭州的自如公寓，委托专业空气检测机构检测，结果显示甲醛超标。英子已将自如起诉至法院，杭州市滨江区法院已立案，并将于9月27日开庭审理。网友评论：在家住自如出事，出门坐滴滴也出事，人生不易。3.长生生物：无法在预定期限披露半年报，股票明日起停牌长生生物因人用冻干狂犬疫苗事件被调查，导致公司部分高层被依法批捕，公司资金被冻结，目前，长生生物由于疫苗门事件影响，导致公司半年报编制工作陷入停顿，无法按时披露2018年度半年报。长生生物将于9月3日起开始停牌。具体复盘时间并没披露。网友评论：想停就停吧...4.2018中国企业500强揭晓：国家电网蝉联榜首，华为列民营企业之首中国企业联合会、中国企业家协会联合发布了“2018中国企业500强”排行榜。在今年的榜单上，国家电网有限公司蝉联榜首，当年营收达2.4万亿元。值得注意的是，今年的500强榜单中，民营企业占到接近一半，达到237家。其中，华为、苏宁、正威位居民营企业前三。网友评论：菊厂还是那个菊厂~5.摩根大通：给予一点资讯180亿估值近日，摩根大通给予了一点资讯150-180亿元人民币估值。摩根大通称，一点资讯作为中国领先的基于算法的新闻APP，日活跃用户数（目前已达到6500万人次）继续以20-30%的年增长率扩张，与此同时其变现能力也得以持续强化。基于2018年的营收基础，摩根大通认为一点资讯的市值或达到150至180亿元人民币。网友评论：你说是，就是吧。6.凤凰自行车起诉ofo 拖欠6815万元货款上海凤凰8月31日晚发布公告称，上海凤凰控股子公司凤凰自行车因与东峡大通（北京）管理咨询有限公司买卖合同纠纷，于近日向北京市第一中级人民法院提起诉讼，诉讼涉及金额6815.11万元。资料显示，东峡大通即为ofo小黄车运营方。ofo公关部人士对中国证券报记者表示对此事不予置评。网友评论：关键现在卖身也卖不出出去...7.奥委会主席：电竞入奥前途未卜，暴力元素违背价值观据NBC Sports报道，国际奥委会主席Thomas Bach在接受美联社采访时发表了对电竞入奥的一些看法，他表示现在还无法确定电竞能否以及何时会被奥运会接纳。Bach直言，“我们不能允许某些提倡暴力和歧视的游戏进入奥运会，也就是所谓的‘杀人游戏’。从我们的观点来看，它们与奥林匹克价值观是矛盾的，因此无法被接受。”网友评论：“吃鸡”莫名躺枪~8.滴滴回应女乘客遇车祸：永久封禁司机账号，会进行赔偿9月1日，近日有女性乘客乘坐滴滴快车时遇车祸受伤，面部受损，后续处理中发现驾车司机信息与平台注册司机身份不符。滴滴称，因有私借账号行为，该账号被平台永久封禁，并表示已向乘客提出由平台先行垫付医疗费，待乘客治疗完毕后，再给予合理赔偿。滴滴表示，乘客家属拒绝平台进行垫付，直接向平台提出20万元的赔偿诉求。（36氪）网友评论：赔偿这一套流程，滴滴是轻车熟路呀。9.抖音宣布加入Apple Music合作伙伴计划8月31日，抖音宣布加入Apple Music合作伙伴计划，中国内地的用户可以在抖音app内聆听Apple Music 曲库内的完整歌曲。据悉，抖音也是国内首个加入该合作伙伴计划的短视频平台。加入该计划后，已订阅Apple Music 会员方案的抖音用户可以在抖音app 内直接收听完整歌曲；未订阅Apple Music 会员方案的抖音用户也可通过歌曲详情页中的“Apple Music 即刻聆听”标签获取三个月免费试用，并在试用期间聆听完整歌曲。网友评论：一波新的抖音神曲即将到达战场。10.腾讯第5款短视频产品“有视频”上线代号为“火锅”的腾讯短视频APP正式上线，名为“有视频”，这是腾讯推出的第5款短视频产品。8月30日，“有视频”正式上线，目前仅可在安卓应用商店进行下载，苹果商店还未上线。目前，“有视频”APP的主页只有“推荐”和“关注”两个栏目，下方呈现的是双列feed视频，点开一个视频进行播放之后，进行上下滑动进行切换。（短视频工场）网友评论：什么鬼代号，和“有视频”三个字有毛线关系啊！【更多内容，欢迎访问】http://forum.huaweicloud.com/forum.php?mod=forumdisplay&fid=569&filter=typeid&typeid=266（内容来源于互联网，如侵犯您的合法权益或有其他任何疑问，请联系：huaweicloud.bbs@huawei.com沟通处理。谢谢！）

Istio是什么？Istio是Google继Kubernetes之后的又一开源力作，主要参与的公司包括Google，IBM，Lyft等公司。它提供了完整的非侵入式的微服务治理解决方案，包含微服务的管理、网络连接以及安全管理等关键能力，无需修改任何代码就能够实现微服务的负载均衡，服务与服务之间的认证授权以及监控。从整个基础设施角度上看，可以将它理解为PaaS平台上的一个面向微服务管理平台的补充。Istio架构示意图Istio与KubernetesKubernetes提供了部署、升级和有限的运行流量管理能力；利用service的机制来做服务注册和发现，转发，通过kubeproxy有一定的转发和负载均衡能力。但并不具备上层如熔断、限流降级、调用链治理等能力.Istio则很好的补齐了k8s在微服务治理上的这部分能力，同时是基于k8s构建的，但不是像SpringCloud Netflix等完全重新做一套。Istio是谷歌微服务治理上的非常关键的一环。Istio与k8s紧密结合，包括：Sicecar 运行在k8s pod里，作为一个proxy和业务容器部署在一起，部署过程对用户透明。Mesh中要求业务程序的运行感知不到sidecar的存在，基于k8sd的pod的设计这部分做的更彻底，对用户更透明，用户甚至感知不到部署sidecar的这个过程。试想如果是通过VM上部署一个agent，不会有这么方便。Pilot中包含一个controller，通过list/watch kube-apiserver自动发现K8S中的services、endpoints。它通过在Kubernetes里面注册一个controller来监听事件，从而获取Service和Kubernetes的Endpoint以及Pod的关系，但是在转发层面，不再使用kube-proxy转发了，而是将这些映射关系转换成为pilot自己的转发模型，下发到envoy进行转发。K8s编排容器服务已经成为一种事实上的标准；因为微服务与容器在轻量、快速部署运维等特征的匹配，微服务运行在容器中也正成为一种标准实践；对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。            自行管理Istio与CCE上使用Istio服务网格的对比华为云 · 云容器引擎CCE(Cloud Container Engine)提供高可靠高性能的企业级容器应用管理服务，支持Kubernetes社区原生应用和工具，简化云上自动化容器运行环境搭建：Ø  简单易用：自动化创建容器集群，一站式部署/运维容器应用，一键式滚动升级；Ø  高性能：自研高性能容器网络，秒级自动弹性伸缩，支持高性能裸金属容器私有集群；Ø  企业级：集群控制面HA和跨AZ高可用，容器应用优雅伸缩，安全下线，保障业务不掉线；Ø  开放兼容：兼容Kubernetes/Docker社区原生版本，CNCF认证的Kubernetes服务提供商，社区的主要贡献者；下列从安装、运行管理和监控多维度对比自建Istio和华为云CCE上使用Istio的差别：自建华为云CCEIstio包管理用户自行下载和管理用户不感知运行配置用户自行配置运行环境和依赖用户不感知Istio安装用户自行探索和安装用户不需要关注具体细节，创建集群时按需启用。Sidecar注入用户自行探索和开发、配置用户不感知Istio升级用户自行探索、开发不影响业务的升级方案提供完整解决方案，按需进行控制面和数据面的升级操作应用调用链用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供请求调用链跟踪查看能力应用拓扑用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供查看应用拓扑能力性能监控用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供请求响应时延的实时性能状态监控云原生应用在CCE上的部署、管理实践云原生应用、云平台与微服务架构云原生应用，是指原生为在云平台上部署运行而设计开发的应用。公平的说，大多数传统的应用，不做任何改动，都是可以在云平台运行起来的，只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式，仅仅是把虚拟机当物理机一样使用，不能够真正利用起来云平台的能力。云计算平台的核心能力就是提供按需分配资源和弹性计算的能力，而云原生应用的设计理念就是让部署到云平台的应用能够利用云平台的能力实现按需使用计算资源和弹性伸缩。微服务架构是实现企业分布式系统的一种架构模式，即将一个复杂的单体应用按照业务的限定上下文，分解成多个独立部署的组件。这些独立部署的组件，就称为微服务。而在谈论云原生应用与微服务架构关系的时候，根据上下文不同可以从两个角度去看。1） 宏观的云原生应用，即将整个分布式系统看作一个应用，这个角度下，微服务架构是实现云原生应用的一种架构模式；2） 微观的云原生应用，即每个微服务是一个应用，这种语境下，每个微服务要按照云原生应用的设计理念去设计(如我们所熟知的云原生12要素），才能真正实现微服务架构所要达到的目的，即让分布式系统具备按需使用计算资源和弹性伸缩的能力。在华为云CCE容器服务中，我们将宏观的云原生应用，称之为“应用”，而将微观层面的云原生应用，称之为“组件“，用这两个概念来对分布式应用进行管理：图：应用、组件与工作负载的关系在CCE上进行云原生应用管理的实践创建Kubernetes集群            在创建应用前，需要准备好一个Kubernetes集群（1.9及以上版本），并启用Istio服务网格治理。登录CCE控制台，在左侧导航栏中单击“资源管理 > 虚拟机集群”，在“虚拟机集群”界面，单击“创建Kubernetes集群”，按照向导式逐步配置：图1：创建Kubernetes集群图2：使能服务网格，一键式安装Istio并自动使能应用sidecar注入：其他集群创建步骤、配置与已有CCE上创建虚拟机集群一致.创建云原生应用这里我们以Istio开源社区的bookinfo样例应用为例，其包含ProductPage、Reviews、Details、Ratings这4个微服务，拓扑结构以及网络访问信息如下：在CCE左侧导航栏中选择“应用管理”，单击“创建应用”，选择“向导式创建” （后续将支持通过helm模板一键式创建微服务应用以及其流量策略配置，更方便管理），分三大块配置：应用基本信息、网格内组件定义、对外放开路由配置。1、 首先定义应用的基本信息：名称、选择所在集群和namespace：2、 第二步，点击添加组件，按照上方的应用拓扑和网络设计，把组件加入到服务网格：A、添加ratings微服务组件（容器内监听端口为9080，开放至service mesh内部访问端口也配置为9080，后者可根据客户端配置自行调整）1）配置组件基本信息：2）选择负载镜像，并配置版本号为v13） 点击“下一步”，负载高级配置中可以选择配置升级策略、缩容策略、自定义监控等，我们这里不做配置，点击“添加“：可以看到我们为bookinfo添加了一个微服务组件进网格B、 添加reviews微服务组件参考上述添加ratings的步骤，添加reviews：C、 添加details微服务组件参考上述添加组件步骤，添加details微服务组件：D、                添加productpage微服务组件3、 最后，配置应用对外开放的访问路由，从上方拓扑设计可知，productpage作为访问入口：A、点击“添加应用访问方式“B、选择开放至外部访问的组件，并配置开放端口配置后的访问方式信息如下所示：最后点击右下角“创建”，启动应用，在应用列表中可以看到新建的分布式微服务应用bookinfo及其包含的微服务组件：通过应用开放的访问入口访问productpage：在CCE上使用Istio进行灰度发布的实践一键式在集群上启用Istio服务网格集群下应用如果需要做微服务治理，只需要在创建集群时点击启用服务网格即可，不需要自行进行Istio镜像下载、yaml配置、安装、升级等与应用业务无关的复杂基础设施构建工作：开发打包新版本下方我们以开发了一个新版本reviews微服务为例（初始容器镜像版本号为1.5.0），新版本镜像版本号为1.5.0-v2，并且已在本地开发机通过docker push上传至华为云容器镜像服务（SWR）：新版本在现在版本基础上增加对ratings微服务的调用，支持评分星星级别展示.发布灰度版本并配置灰度策略现在我们计划通过灰度发布的方式，平滑的在现网升级，在应用列表页面，展开bookinfo下的组件信息，选择reviews微服务组件的“添加灰度版本”：启动灰度版本：配置灰度版本号v2，确认好镜像版本（系统会默认选择最新版本的镜像），点击“启动负载”即可启动灰度版本，容器高级配置已默认继承已有版本观察灰度版本运行状态并配置灰度策略：按照比例分配灰度版本流量比例（这里以20%为例），观察负载启动成功后，点击“提交策略”：回到组件列表可以看到，review微服务已处于灰度发布状态：对review服务进行灰度发布前后的流量对比如下所示：初始版本：灰度状态：如图示，review v2版本调用ratings服务获取星级评价，并将20%流量分流至本版本上访问productpage，可以看到部分请求可以显示星级评价，部分请求仍然是老版本的显示效果（即没有评星这个新特性），并且出现的比例接近1:4.部分访问结果为原有的页面：部分访问结果为带有星级评价特性的页面：持续观测灰度版本运转状态，并进行流量切换接下来，我们会持续观测灰度版本的运行状态，在确认业务处理、性能满足要求后，我们可以选择逐步调大灰度版本的流量比例，而后进一步将流量全部导流至灰度版本上：Ø  观察健康与性能状态：点击CCE左侧导航栏“运维中心”进入AOM服务：选择“指标”->“应用”菜单，持续观察review服务灰度版本v2的健康状态与性能状态：Ø   观察调用链以及请求响应时延：在CCE应用管理中，点击bookinfo应用，查看详情，可以看到CCE服务提供了请求调用链跟踪能力，能够实现分布式异常请求的快速定位（当前提供开源zipkin和grafana能力，后续将对接至华为云AOM服务提供相应能力）可以看到V2版本运转正常，那么下一步我们将逐步扩大流量比，最后将流量全部导至灰度版本，在cce服务中，点击组件名称，进入组件详情页面，点击“接管所有流量”：系统提示会将接管原有版本的所有流量，点击“确定“按钮：现在所有访问reviews的流量都导向v2版本：访问productpage，所有的请求都会呈现星级评价特性：最后，我们将原有老版本（V1）从平台移除：点击确认后，可以看到该微服务只剩下v2版本在运转：通过Istioctl工具进行更多微服务流量治理在上述规则的基础上，cce Istio服务网格还提供了Istioctl命令行工具，实现更全面的流量治理能力，如限流、熔断、连接池管理、会话保持等。进入”资源管理“->“虚拟机集群“，点击所要管理的集群，可以看到Istio命令行的下载和使用指导：  总结华为云CCE容器引擎 + Istio + AOM/APM + SWR服务，提供了完整的云原生应用从开发、部署、上线、监控的完整生命周期管理全栈服务，让企业上云更简单，运行更高效。目前Istio服务网格能力已开放公测，可通过下方链接，快速申请公测，华为云容器服务的专家将全力为您服务，为您的成功保驾护航.申请链接：https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/Istio/meshList

Istio是什么？Istio是Google继Kubernetes之后的又一开源力作，主要参与的公司包括Google，IBM，Lyft等公司。它提供了完整的非侵入式的微服务治理解决方案，包含微服务的管理、网络连接以及安全管理等关键能力，无需修改任何代码就能够实现微服务的负载均衡，服务与服务之间的认证授权以及监控。从整个基础设施角度上看，可以将它理解为PaaS平台上的一个面向微服务管理平台的补充。                                                               Istio架构示意图Istio与KubernetesKubernetes提供了部署、升级和有限的运行流量管理能力；利用service的机制来做服务注册和发现，转发，通过kubeproxy有一定的转发和负载均衡能力。但并不具备上层如熔断、限流降级、调用链治理等能力. Istio则很好的补齐了k8s在微服务治理上的这部分能力，同时是基于k8s构建的，但不是像SpringCloud Netflix等完全重新做一套。Istio是谷歌微服务治理上的非常关键的一环。  自建与公有云上使用Istio的对比目前业界大部分云平台上所提供的Istio能力均需要自己负载Istio包的下载、配置、安装等，还是比较费劲的。不过华为云CCE服务这里深度集成了Istio服务网格，个人感觉使用上还是方便很多的，简单对比了下：自建华为云CCEIstio包管理用户自行下载和管理用户不感知运行配置用户自行配置运行环境和依赖用户不感知Istio安装用户自行探索和安装用户不需要关注具体细节，创建集群时按需启用。Sidecar注入用户自行探索和开发、配置用户不感知Istio升级用户自行探索、开发不影响业务的升级方案提供完整解决方案，按需进行控制面和数据面的升级操作应用调用链用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供请求调用链跟踪查看能力应用拓扑用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供查看应用拓扑能力性能监控用户自行探索、开发和安装、配置对接华为云APM/AOM服务，提供请求响应时延的实时性能状态监控流量治理需要自行编写配置文件提供界面进行流量和发布的管理 云原生应用的部署、管理实践云原生应用、云平台与微服务架构云原生应用，是指原生为在云平台上部署运行而设计开发的应用。公平的说，大多数传统的应用，不做任何改动，都是可以在云平台运行起来的，只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式，仅仅是把虚拟机当物理机一样使用，不能够真正利用起来云平台的能力。云计算平台的核心能力就是提供按需分配资源和弹性计算的能力，而云原生应用的设计理念就是让部署到云平台的应用能够利用云平台的能力实现按需使用计算资源和弹性伸缩。微服务架构是实现企业分布式系统的一种架构模式，即将一个复杂的单体应用按照业务的限定上下文，分解成多个独立部署的组件。这些独立部署的组件，就称为微服务。而在谈论云原生应用与微服务架构关系的时候，根据上下文不同可以从两个角度去看。1） 宏观的云原生应用，即将整个分布式系统看作一个应用，这个角度下，微服务架构是实现云原生应用的一种架构模式；2） 微观的云原生应用，即每个微服务是一个应用，这种语境下，每个微服务要按照云原生应用的设计理念去设计(如我们所熟知的云原生12要素），才能真正实现微服务架构所要达到的目的，即让分布式系统具备按需使用计算资源和弹性伸缩的能力。在华为云CCE中，将宏观的云原生应用，称之为“应用”，而将微观层面的云原生应用，称之为“组件“，用这两个概念来对分布式应用进行管理：                                          图：应用、组件与工作负载的关系云原生应用管理的实践创建Kubernetes集群       在创建应用前，需要准备好一个Kubernetes集群（1.9及以上版本），并启用Istio服务网格治理。登录CCE控制台，在左侧导航栏中单击“资源管理 > 虚拟机集群”，在“虚拟机集群”界面，单击“创建Kubernetes集群”，按照向导式逐步配置： 图1：创建Kubernetes集群 图2：使能服务网格，一键式安装Istio并自动使能应用sidecar注入：其他集群创建步骤、配置不变.创建云原生应用这里我们以Istio开源社区的bookinfo样例应用为例，其包含ProductPage、Reviews、Details、Ratings这4个微服务，拓扑结构以及网络访问信息如下： 在左侧导航栏中选择“应用管理”，单击“创建应用”->“向导式创建”:1、 首先定义应用的基本信息：名称、选择所在集群和namespace，并按照上方的应用拓扑和网络设计添加组件 A、添加ratings微服务组件机器监听端口，容器内监听端口为9080，开放至service mesh内部访问端口也配置为9080：1）配置组件基本信息：2）选择负载镜像和版本后点击“添加”，可以看到我们为bookinfo添加了一个微服务组件进网格：B、     参考上述步骤，添加reviews、details和productpage微服务组件2、    配置应用对外开放的访问路由：A、点击“添加应用访问方式“B、选择开放至外部访问的组件，并配置开放端口：最后点击右下角“创建”，启动应用，应用及其微服务组件如下所示： 通过应用开放的入口访问productpage：使用Istio两步实现灰度发布在集群上启用Istio服务网格集群下应用如果需要做微服务治理，只需要在创建集群时点击启用服务网格即可，不需要自行进行Istio镜像下载、yaml配置、安装、升级等与应用业务无关的复杂基础设施构建工作。开发打包新版本下方我们以开发了一个新版本reviews微服务为例（初始容器镜像版本号为1.5.0），新版本镜像版本号为1.5.0-v2，并且已上传至华为云容器镜像服务（SWR），新版本在现在版本基础上增加对ratings微服务的调用，支持评分星星级别展示. 发布灰度版本并配置灰度策略在应用列表页面，展开bookinfo下的组件信息，选择reviews微服务组件的“添加灰度版本”： 启动灰度版本：配置灰度版本号v2，系统已自动选择最新镜像版本，点击“启动负载”即可启动灰度版本：观察灰度版本运行状态并配置灰度策略：按照20%比例分配灰度版本流量可以看到，review微服务已处于灰度发布状态： 对review服务进行灰度发布前后的流量对比：初始版本：reviews服务未调用ratings来获取星级评价能力灰度状态：review v2版本调用ratings服务获取星级评价，并将20%流量分流至本版本上访问productpage，可以看到部分请求可以显示星级评价，部分请求仍然是老版本的显示效果，部分访问结果为带有星级评价特性的页面： 持续观测灰度版本运转状态，并进行流量切换持续观测灰度版本的运行状态，在确认业务处理、性能满足要求后，我们可以选择逐步调大灰度版本的流量比例，而后进一步将流量全部导流至灰度版本上： Ø  观察健康与性能状态：点击左侧导航栏“运维中心”进入AOM服务，选择“指标”->“应用”菜单，持续观察review-v2的健康与性能状态：  下一步我们将逐步扩大流量比，最后将流量全部导至灰度版本，点击“接管所有流量”：现在所有访问reviews的流量都导向v2版本，访问productpage，所有的请求都会呈现星级评价特性： Istioctl命令行工具       Istio服务网格还提供了命令行工具，满足更多的流量规则配置诉求，如限流、熔断、连接池管理、会话保持等。进入”资源管理“->“虚拟机集群“，选择对应集群，可以看到Istio命令行的下载和使用指导：总结总的来说，华为云CCE + Istio + AOM/APM服务在组件部署、灰度版本管理、流量策略配置以及灰度过程中的监控还是能够满足基本诉求，操作上也比较简单，通过简单的两三步配置即可实现新版本的发布和流量切换，期待华为云CCE Istio服务网格这里能够有更多能力开放出来。

微服务的挑战微服务将一单体的复杂应用分解成若干小的服务，服务间使用轻量级的协议进行通信。这种方式带给我们很多好处：1）  从Dev上看，每个微服务的功能更内聚，可以在微服务内设计和扩展功能；并且微服务可以采用不同的开发语言，不同的开发工具；2）  从Ops上看，微服务化后，每个微服务在独立的进程里，可以自运维；更重要的是微服务化是单一变更的基础，迭代速度更快，上线风险更小。                                                                                                                 复杂单体应用改造成微服务示意图  但是，在享受微服务带给我们福利的同时，微服务也给开发和运维功能在带来了很大的挑战。因为微服务化也仅仅是一种分而治之，化繁为简的方法论，业务本身的规模和复杂度并没有变少，而且为了支持微服务中间还要多做些事情。你会发现你的系统变成了分布式的，网络可靠性、通讯安全、网络时延、网络拓扑变化等这些原来不用特别关心的也得关心起来。另外还有微微自身机制的问题，比如服务怎么找到对端服务需要服务发现和负载均衡等。原来的在一个进程里的调用栈，现在变成了跨进程的分布式调用栈，就是所谓的分布式调用链追踪。那么面对这些问题，就需要对应的工具集来搞定这些事情，就是治理的工具集，包括服务发行，负载均衡，熔断容错，调用链分析等等。 微服务从业者，一直试图告诉大家这些工具集是微服务提供的福利，我更愿意认为这是解决微服务化带来的问题的工具集。 Service Mesh 微服务治理逻辑最初由开发人员写在业务代码里，缺点很明显，功能重复，业务代码和治理逻辑耦合。                                                         阶段一：微服务治理逻辑耦合在业务逻辑中 那么很容易想到通过封装吧公共逻辑提炼出来，形成一个公共库，就是所谓的SDK，使用SDK开发，则所有治理能力就内置了。Spring Cloud和Netflix都是此类的工具，使用比较广泛。但语言相关，而且对于开发人员有一定的学习成本。虽然SDK都强调开箱即用，使用anotation或者其他配置的方式，或者starter方式便让开发人员入手，但使用起来并不容易。另外推动已经在用的旧的系统使用SDK重写下也不是个容易的事情。                                                         阶段二：提供SDK进行开发 于是考虑是否可以继续封装，将治理能力提到进程外面来，作为独立进程。即Sidecar方式，也就是当前比较受广泛关注的service mesh的方式。真正可以做到对业务代码和进程0侵入，这对于原来的系统完全不用改造，直接使用sidecar进行治理。                                                         阶段三：service mesh方式   如下图深色是proxy，浅色的是服务，所有流入流出服务的都通过proxy。服务网格正是由这一组轻量代理组成，和应用程序部署在一起，但是应用程序感知不到他的存在。尤其对于云原生应用，一般有都有着复杂的应用访问拓扑，服务网格保证请求可以在这些拓扑中可靠的传递。为了能对这这么多代理有个统一的管理，所有的代理都一般都接入了一个控制面，对代理进行生命期管理和统一的治理规则的配置。 Istio的问世Istio是一个Service Mesh开源项目，是Google继Kubernetes之后的又一力作，主要参与的公司包括Google，IBM等公司。它提供了完整的微服务治理的完整的解决方案。2017年5月发布第一个release 0.1.0，当前版本0.8是一个LTS版本于6.1发布，预计1.0版本会在七月份发布，最新的信息是7.20号1.0版本就会发布。 下图反映了Istio项目的一个发展现状。Star数基本上一直是线性增长。右图是前阵子哥本哈根kubecon上议题里istio相关的，可以看到还是非常有热度的。 Istio的架构以下Istio的总体架构图：由两部分组成，控制面和数据面。 Pilot负责部署在Istio服务网格中的Envoy实例的生命周期管理，主要干两个事情：服务发现和治理规则的配置和下发。Mixer是负责在服务网格上执行访问控制和策略，并从Envoy代理收集遥测数据。Citadel提供服务间认证和终端用户认证，使用交互TLS，内置身份和证书管理。 ISTIO架构上非常注重解耦这个点，一个好的系统，一个设计好的系统，都满足这个特点，k8s满足，istio也集成了这个基因。不只是提供一个功能。而是一个框架，提供足够的可扩展性。在国内我们好像更愿意管这个叫做二次开发。像模板的设计模式订好了模板留下实现的接口，就像java语言喜欢在框架上用接口和抽象类来定义行为，这本身就体现了设计，体现了约束，甚至体现了现在开发中角色地位。Pilot服务发现的解耦设计  首先看下istio的服务发现。本身还是微服务的框架，微服务的模型。定义了一个抽象的服务模型，包括服务、服务实例、版本等，Adapter对接不同的平台。 如在k8s中，Pilot中的Kubernetes适配器通过Kubernetes API服务器得到Kubernetes中Pod注册信息的更改，入口资源以及存储流量管理规则等信息，然后将该数据被翻译为标准模型提供给Pilot使用。同样对接Eureka，也是用一个httpclient去rest访问eureka的名字服务的集群，获取服务实例的列表。Istio的服务模型：服务、服务实例、pilot的model. ServiceInstance中的定义连字段都和版本 和 netflix的eureka和springcloud的 servcieinstance类元素基本一样。 Pilot数据面接口的解耦设计除了对接各种运行的平台外，istio和数据面的对接也非常灵活，设计了标准的接口，只要满足该接口的proxy都可以被istio管理。Envoy提供服务发现，负载均衡池和路由表的动态更新的API，这些API将Istio和Envoy的实现解耦。Envoy API负责和Envoy的通讯, 主要是发送服务发现信息和流量控制规则给Envoy。可以在运行期对微服务的流量进行调整和控制。提供标准的API接口，可以对接多种不同的数据面，当前支持Envoy，也可以对接其他的满足协议的Sidecar。 Mixer后端的解耦设计 Mixer通过使用通用插件模型实现的对接不同后端，避免了proxy对每种处理后端的对接。每个插件都被称为Adapter。对于每个请求Sidecar会从每一次请求中收集相关信息，如请求的路径，时间，源IP，目地服务，tracing头，日志等，并请这些属性上报给Mixer。Mixer和后端服务之间是通过适配器进行连接的，Mixer将Sidecar上报的内容通过适配器发送给后端服务。可以在不停止应用服务的情况下动态切换后台服务。除了可以通过adapter机制接入不同的后端，mixer还支持根据需要定义收集的metric，和对metric的处理方式，如下样例所示，可以自定义监控指标：apiVersion: "config.istio.io/v1alpha2"kind: metricmetadata:  name: requestduration  namespace: istio-systemspec:  value: response.duration | "0ms"  dimensions:    source_service: source.service | "unknown"    source_version: source.labels["version"] | "unknown"    destination_service: destination.service | "unknown"    destination_version: destination.labels["version"] | "unknown"    response_code: response.code | 200 Istio API开放ISTIO服务治理能力对于治理策略都是定义在服务提供者的对象上，但是执行大部分都是在服务消费者一端。典型的如负载均衡，又请求端选择调用后端哪个实例，其实ribbon等sdk的对应组件也都是同样逻辑，下表展示了ISTIO的服务治理能力以及执行方： V1alph3 API在0.8后Istio推出了最新的V1alph3的API。V1alpha3在0.7时候就有了，在0.8时做了些少的调整。当前版v1a1已经标记成废弃了，在未来会被弃用。它将完全取代之前的API。尽管v1alph3和之前的API模型基本相同，但它不向后兼容，需要从旧API手动转换。在Istio接下来的版本中会包含一个转换工具提供转换的功能。  1. Gateway，提供外部服务访问接入。不同于v1alph1使用ingress做服务接入，只能支持七层。使用Gateway后可以将内部任意一个端口上的服务发布出去进行外部访问。配合VS规则，使用标准的Istio规则来控制进入Gateway的HTTP和TCP流量。和内部流量统一套的治理外部力量。2. VirtualServiceVS是istio中最核心的接口。所有的路由访问规则都是通过VS来描述。比如比较典型的做灰度发布，可以描述满足什么条件的规则去哪个特征的路由上。在V1alpha1里是多个routerule搞优先级，VirtualService的引入使路由规则的配置更为集中和灵活。4. DestinationRule配置将流量转发到服务的策略集。断路器，负载均衡设置，TLS设置等5. ServiceEntry外部服务接入到服务注册表中。可以像注册表中的任何其他服务一样,与VirtualService和/或DestinationRule一起使用 Istio和kubernetes 谷歌围绕k8s打造了一个生态圈，我们以微服务的视角看下这里的功能：K8s提供了部署、升级和有限的运行流量管理能力；利用service的机制来做服务注册和发现，转发，通过kubeproxy有一定的转发和负载均衡能力。但是往上的如熔断、限流降级、调用链治理能力就没有了. Istio很好的补齐了k8s在微服务治理上的这部分能力，同时是基于k8s构建的，但不是像springcloud netflix等完全重新做一套。istio是谷歌微服务治理上的非常关键的一环。 Istio基于k8s之上构造能力，包括：Sicecar 运行在k8s pod里，作为一个proxy和业务容器部署在一起，部署过程对用户透明。Mesh中要求业务程序的运行感知不到sidecar的存在，基于k8sd的pod的设计这部分做的更彻底，对用户更透明，用户甚至感知不到部署sidecar的这个过程。试想如果是通过VM上部署一个agent，不会有这么方便。istioctl 命令行工具提供类似kubectl风格的功能，提供命令行的配置功能。Istio所有的配置都是通过CRD表达，通过对K8S原生API的扩展，用户可以方便的使用起来。Pilot中包含一个controller，listwatch kubeapiserver，做服务发现。pilot通过在kubernetes里面注册一个controller来监听事件，从而获取Service和Kubernetes的Endpoint以及Pod的关系，但是在转发层面，不再使用kube-proxy转发了，而是将这些映射关系转换成为pilot自己的转发模型，下发到envoy进行转发。 K8s编排容器服务已经成为一种事实上的标准；因为微服务与容器在轻量、快速部署运维等特征的匹配，微服务运行在容器中也正成为一种标准实践；随着istio的成熟和ServiceMesh技术的流行，使用Istio进行微服务治理的实践也越来越多；而istio和k8s的天然融合使得上面形成了一个完美的闭环。对于云原生应用，采用kubernetes构建微服务部署和集群管理能力，采用Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。 Istio和k8s在华为云Istio在华为云这是istio加入华为云k8s全栈容器服务大家庭的一个全局视图，可以看到华为云容器服务提供了从容器集群、容器运维、容器镜像、应用编排、serviceless container以及微服务治理的端到端完整容器全栈服务，让企业上云更简单，运行更高效。 在华为云容器应用中可以使用istio进行服务治理和服务发布管理功能，下面以灰度发布功能为例。用过CCE的用户会发现使用方式和原来使用基本没有差别，如果您的集群下应用需要进行微服务治理，只需要在集群创建时启动istio服务网格，简单的鼠标点击就可以实现开启服务治理的能力！最佳实践：通过简单2个步骤即可实现微服务的新版本灰度发布下面以灰度发布的例子来看如何通过ISTIO服务网格简单、快速的实现新版本发布诉求。下方图示为典型的灰度发布以及版本管控流程： 那么按照这个步骤，在华为云容器服务中如何实现呢？ 第一步：在已有应用组件中点击“添加灰度版本”，只需要简单配置新版本号即可（如下方配置，版本号为V1.1），系统将自动为您选择最新版本的镜像，并继承已有版本配置（支持按需更新），如下图示：  第二步：配置灰度流量策略，根据您的发布诉求，选择基于权重或者内容的策略：   基于权重的策略：基于请求内容的策略：配置完毕点击“提交策略”即可实现灰度发布，可以看到，在华为云容器服务上，如果要对您的应用微服务进行灰度发布，只需要简单的两步操作，总共输入3个配置项即可实现微服务的灰度发布。而后，通过华为云容器应用性能监控服务做进一步的运行态监控以及版本管理  按照权重和内容的业务数据流向分别如下图所示：    基于比例调度的业务流量示意图     基于内容调度的业务流量示意图 最后，用户可以根据诉求逐步提升灰度版本的流量比例，通过简单的点击将流量全部切换到灰度版本，便捷实现新版本的逐步、平滑、稳定的在现网发布上线： （1）简单点击即可实现灰度版本“接管所有流量”：（2）所有流量已切换至灰度版本（V1.1）  华为云容器服务Istio服务网格震撼公测目前ISTIO服务网格能力已开放公测，如欲获取更多信息，更便捷的解决企业微服务化过程中碰到挑战，可通过下方链接，快速申请公测，华为云容器服务的专家将全力为您服务，为您的成功保驾护航. 申请链接：https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/istio/meshList

看产品介绍是基于Kubernetes的Serverless Container（无服务器容器）引擎，有如下疑问： 1、功能是否完全与Kubernetes一样呢？ 2、除了Kubernetes，是否还用了其他流行的开源软件？

本帖最后由 橘色西瓜 于 2018-6-13 17:37 编辑活动已经顺利结束，为了方便大家回顾下载当天私享会的会场资料，小编汇总整理当天资料，待补充内容后续再补充，持续刷新中~~ 欢迎大家阅读下载。 2018年6月10日议题： ServiceStage-让企业应用上云更加简单，运营更高效 讲师：PaaS高级解决方案经理/吴方杰 源于开源，高于开源，Kubernetes全栈容器技术剖析 讲师：华为云应用服务产品经理/江舒杭 快人一步，华为云新一代分布式缓存Redis(DCS2.0) 讲师：PaaS高级解决方案经理/吴方杰 华为微服务架构转型实践之路 讲师：华为云微服务产品经理/蒋鸿伟 华为云立体运维 讲师：华为云运维服务产品经理/徐博 演讲材料合集请见附件： 17260

本帖最后由 橘色西瓜 于 2018-6-27 17:03 编辑直播链接：https://zhibo.huaweicloud.com/watch/2047212 16216 直播链接：https://zhibo.huaweicloud.com/watch/2047212