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社区项目的设计和开发，将带给您最原汁原味云原生讲解。

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

调用链原理和场景正如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 的没有吗？

本期简介本期直播是华为云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开源团队在社区贡献的整体工作。

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

本帖最后由 橘色祥云楼楼主 于 2018-4-20 14:52 编辑本文作者：乔雷 原华为PaaS架构师/系统和软件工程师，现Cloud BU中国业务技术支持部解决方案架构师 基于华为云的一个典型的持续部署方案：FunctionStage(Serverless)+(Monocular+)Helm Chart + CCE(Kubernetes+Docker) [*]1. 关于持续集成（CI）和持续部署（CD） [*]2. 一个华为云上的持续部署方案 [*]3. 部署截图 摘要：华为云迄今为止已经有14大类超过100种服务了，可以做很多有用和好玩的方案。本文以一个实际的案例，讲述如何使用华为云上的相关服务(主要是FuctionStage和CCE)完成自动化持续部署（CD，Continuous Deployment)；并且通过Monucular手动部署Helm Charts打包的Kubernetes应用。这充分说明了华为云云容器引擎CCE支持和兼容开源生态Kubernetes以及在DevOps的强大能力，以及华为云支持业界主流自动化部署工具的能力。 1. 关于持续集成（CI）和持续部署（CD）在软件开发和运维领域，我们经常会听到很多概念，比如DevOps，持续集成（CI，Continuous Integration)，持续交付（CD，Continuous Delivery），持续部署（CD，Continuous Deployment)等等。这些新的概念、方法论和工具的出现，主要是为了应对目前业务的挑战。主要是要求业务推出和运维即“快”又“稳”： [*]快：比竞争对手更快的创新、试验和部署业务的能力。快速推出业务、快速获取反馈、快速迭代、快速试错。 [*]稳：快速、频繁地特性发布，同时保证业务和系统的稳定性、可用性和持久性。 下面我们稍微解释一下持续集成（CI，Continuous Integration)，持续交付（CD，Continuous Delivery），持续部署（CD，Continuous Deployment)的概念，可以去参考：持续集成是什么？ [*]持续集成（CI，Continuous Integration)：持续集成指的是，频繁地（一天多次）将代码集成到主干。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。 [*]持续交付（CD，Continuous Delivery）：持续交付指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。 [*]持续部署（CD，Continuous Deployment)：持续部署是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 在本文的场景中，主要讲述的是基于华为云的持续部署（CD，Continuous Deployment)。2. 一个华为云上的持续部署方案前期在支撑某客户在华为云上的概念验证（PoC，Proof of Concept）中，有一个很重要的测试场景：自动化CI/CD。具体场景是：客户在私有云中完成持续集成（CI），CI采用自建的工具链；生成结果自动在华为云上完成持续部署（CD），部署在Docker容器中。客户采用Helm charts脚本部署容器应用，因此在客户的CCE（Cloud Container Engine）容器集群所在的VPC中，我们部署了一台服务器安装了Helm client，通过Helm client连接CCE集群的Kubernetes Master完成Docker容器应用部署。客户部署的容器应用中，其中有一个很重要的容器应用是一个job类应用，它的主要工作是：使用一些自动化部署工具完成应用所需资源的创建，应用环境的初始化等等。完成之后即停止。我们采用了：FunctionStage(Serverless)+(Monocular+)Helm Chart + CCE(Kubernetes+Docker)的方案完成持续部署。演示效果良好。具体如下图所示：14221描述如下： [*]客户在私有云中完成持续集成（CI），CI采用自建的工具链。CI的结果是： [*]应用容器镜像上传到华为云容器镜像仓库（SWR, SoftWare Repository for Container） [*]应用部署脚本（例如Helm Chart.yaml, values.yaml）等以约定的打包方式，上传到华为云对象存储服务（OBS, Object Storage Service）的指定桶（Bucket）的相应目录下 [*]因为华为云的FunctionStage(Serverless）和OBS有集成，事先在FunctionStage中配置触发器（Trigger），当指定桶（Bucket）的相应应用目录下有文件更新时（PUT/POST操作，即用户上传了应用部署脚本），自动触发一个Python程序的执行。 [*]这个Python程序会ssh到Helm client，执行一个自动化部署的脚本。此自动化部署脚本会执行资源清理、helm install等动作完成容器应用的部署。 [*]部署的容器应用中，其中有一个很重要的容器应用是一个job类应用，它的主要工作是：使用一些自动化部署工具完成应用所需资源的创建，应用环境的初始化等等。完成之后即停止。 [*]最后的结果是：应用通过helm client部署在CCE容器集群中，该创建的资源（例如RDS-MySQL）成功创建并初始化，资源和应用运行正常。 [*]当然，我们也安装了一个Monocular(Monocular is a web-based UI for managing Kubernetes applications packaged as Helm Charts)，允许用户手动部署Helm Charts打包的Kubernetes应用。 3. 部署截图一些部署的截图如下。请注意：这个截图是我手动部署的截图，跟自动化部署的截图是类似的，但更能说明部署过程。 [*]通过Helm client部署容器应用到CCE集群 14158 执行kubectl get pods可以看到应用pod(容器)处于Running状态。 [*]部署过程中通过自动化部署工具创建和初始化的华为云RDS-MySQL资源 14159

本帖最后由 橘色祥云楼楼主 于 2018-3-29 11:36 编辑13375 华为与 Kubernetes 的渊源颇深，早在 Kubernetes 刚开源的时候就以社区创始成员及白金会员的身份加入其中。目前拥有 1 个 Steering Committee 席位和 5 个 Maintainer 席位。 华为自身基于 Kubernetes 的实践 加入初期，作为全球最大的电信设备制造商之一，华为内部 IT 运维着遍布全球的八个数据中心，在 100K + VM 中运行 800 多个应用程序，使用虚拟机封装应用程序，但每次启动虚拟机都花费了大量的时间，这给管理及部署基于虚机应用程序的高成本和低效率带来了严峻的挑战。因此华为决定利用 Kubenetes 技术对自身 IT 系统进行容器化改造。 与此同时，华为通过参与和贡献 Kubernetes 项目，为自身带来了在规划、网络、多集群联合、应用支持、安全、可扩展性和政策执行等方面的良好设计、代码和文档管理，以及在服务治理方面的收益。通过自身的容器化改造实践，在受益的同时又将自身遇到的实际问题不断的贡献给社区，与社区成员一同推动 Kubernetes 的发展。 比如，在华为内部 IT 系统的实践历程中，业务的全球化属性给平台带来了混合云、跨地域、多 DC 部署方面的需求，这与社区发展多集群联邦的理念不谋而合。因此，华为在集群联邦项目成立之初就积极参与其中，主导了架构设计以及联邦级别的无状态应用、短任务支持、集群间策略调度、应用跨集群自动伸缩等关键特性开发。目前集群联邦已在社区正式孵化为独立子项目。 另一个例子是早期的 K8S 并不支持亲和反亲和等高级调度策略，使得大型传统应用改造上云十分困难。在华为公司对应用做微服务拆分和容器化改造的过程中，最典型的问题就是拆分后的组件间如何高效地通信。在传统方案中，往往有多个组件的业务进程部署在同个虚机上，组件间交互可以通过进程间通信来实现。应用改造后，组件变成了 k8S 中的 Pod，被相对独立地调度和拉起，通过容器网络互相通信。当一个复杂应用的各个组件十分分散时，网络通信的时延会大幅增加。 一方面，针对这个问题，华为在 k8S 社区的主导实现了节点亲和反亲和调度、应用间亲和反亲和调度、Taints tolerations 等高级调度机制。通过给 Pod 配置高级调度策略干预应用组件的分布，配合容器网络在路由策略上的优化，访问时延问题得到了显著的改善。 另一方面，在集群规模和性能方面，华为也做了很多探索与实践。面对大规模场景下海量 Service 的管理性能问题，华为设计实现并向社区贡献了使用 IPVS 管理 service 路由规则的方案，将 k8S 对 service 的管理规模从上千提升到了数万的级别。 华为云应用服务与 Kubernetes 华为云应用服务产品均围绕着“容器”为中心构建，致力于帮助客户容器化的应用在云上高效地开发、交付与运维，并保障应用运行时的高性能、高可靠、高弹性。目前，华为云应用服务产品以基于 K8S 的华为云容器引擎（CCE）为核心，协同补齐了完整的应用开发、交付与运维流程，为客户提供完整的一站式云上应用生命周期管理方案。 华为云应用服务大体上可以分为三大类： 第一类围绕着 Kubernetes 核心功能，也就是容器编排与调度，与下层的基础设施层包括计算、网络、存储，以及水平的权限控制、网络防护、镜像仓库等服务进行整合形成一个容器化基础设施平台，并向上对接到集群管理、多 DC/AZ、多区域管理实现云上的水平弹性。通常大家所提到的“容器服务”或“容器云”大部分都是指这一类服务。华为云所提供的云容器引擎（CCE）、云容器实例（CCI）归属于此类。两者均基于 Kubernetes 构建，但技术路线偏重点有所区分。 CCE 的服务形态是用户专属的 Kubernetes 集群（Kubernetes as a Service），用户能够控制整个 Kubernetes 集群的资源与应用，并且可以调用完整的 Kubernetes API，以及安装各类 Addon 以及自定义扩展比如调度器、工作负载控制器等；而 CCI 的服务形态是无服务器容器（Serverless Container），用户无需感知 Kubernetes 集群，通常只需要调用 Kubernetes Workload API 进行应用的管理即可，而把资源全部交由华为云进行自动调度与管理。因此，通常 CCE 适合业务半托管的场景，即用户自身有一定运维能力，且业务场景需要用户手动做一些管控比如资源规划、弹性伸缩，甚至自定义一些平台特性以适配业务；相对而言 CCI 适合业务全托管的场景，即用户只需关注以容器形态所交付的应用本身，无需关注资源管控，甚至无需关注 Kubernetes 的相关原理。 第二类服务围绕着 Kubernetes 标准化接口以及结合具体场景的最佳实践来构建完整的应用开发、交付与运维流程，实现云上的应用全生命周期管理。华为云在开发阶段提供微服务开发框架帮助用户在产品开发中落地微服务架构实践，在交付阶段提供“从代码到容器镜像”的自动镜像构建服务，支持一键式部署到 Kubernetes 平台之上，实现持续交付，而最终业务上线运行之后的运维阶段除了基础的容器监控、日志、告警系统之外，同时提供了微服务治理引擎，以及应用性能管理用于故障在线辅助与自动定位。 具体举例而言：[indent] [*]华为云微服务引擎（CSE）提供了具备升降级、容错、熔断等完整服务治理能力的微服务框架，兼容 Spring Cloud、Dubbo 等开源接口，并与 CCE 深度整合，支持 ServiceMesh，未来计划进一步与 CNCF 基金会各微服务相关项目，尤其是 Istio 生态相结合，提供最适合在 K8S 之上运行业务所使用的微服务开发框架 [*]华为云应用编排服务（AOS）提供了以应用为中心的高层编排引擎，能够将 K8S 上运行的各种工作负载、各类资源对象整合管理，并提供了完善的版本与生命周期管理机制，便于客户以更高层的“应用”为对象进行日常交付与运维管理 [*]华为云应用性能管理（APM）提供了丰富的各类运维工具，除了基础的监控、日志与告警，进一步面向故障定位与分析场景提供了应用全局性能拓扑展示与调用链跟踪等高级特性，使得运维人员能够及时了解应用健康状态并进行相关处理。 [/indent] 第三类则是直接在 Kubernetes 之上身体力行地构建一些典型服务化应用，针对某些业务场景提供更易用、更高效的服务，使得客户更聚焦自身业务逻辑。比如：[indent] [*]以分布式数据库（DDM）、分布式缓存（DCS）、分布式消息（DMS）为代表的云化中间件服务，供应用业务逻辑所调用，辅助客户应用的容器化、无状态化、微服务化开发或改造； [*]以 CCE/CCI 为基础设施层所构建的 Serverless Computing（FunctionStage）服务，面向 Event-Driven 的典型业务流场景简化应用代码逻辑，并基于容器热启动、各类主流语言运行时的快速启停优化，实现更高效、更低成本的实时计算； [*]区块链服务 BCS 则提供了主流的 Hyperledger 开源框架，并基于 Kubernetes 的高性能实现 3 分钟一键上链，2000+TPS 的并发区块处理能力，可满足联盟链与私有链的各类业务场景诉求，使客户免运维地使用区块链构建自有业务框架。 未来：紧随社区版本 持续优势创新 纵观华为在 Kubernetes 上的创新可以总结为优势创新、场景创新、技术创新三个层面，优势创新是围绕华为固有的自身强势领域如网络、硬件进行与容器技术的结合运用。场景创新则是聚焦在不同领域的客户需求如游戏、电商、AI 等，基于客户的计算需求进行解决方案的适配。技术创新，以无服务器容器为例，在 Serverless 的云服务趋势下，华为云提供更加便捷，更加全新理念的容器服务方式。目前看来，容器服务并没有统一的服务标准，并没有说哪一种创新可以一招解决所有企业云上容器化的痛点，这需要根据客户的业务场景进行量身匹配，而华为云的全栈容器服务的实践案例也充分说明了这一点。众多不同的容器服务在上线不久已应用在众多不同领域，裸金属容器已成功运用在一部分游戏客户中，帮助其进行测试环境，及高峰时间的流量应对。Windows 容器成功运用在传统 IT 系统的容器化改造，而无服务器容器则可以帮助更多缺乏 Kubernetes 技术投入的公司快速上手享受容器化带来的益处。 这也就是华为云对于 Kubernetes 的一些探索和思考，未来还会有更多基于容器的创新，一切才刚刚开始。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~作者简介 华为云应用服务技术团队，在容器与微服务领域具备长期的技术与实践积累，以领先的容器与微服务等云原生技术专注解决应用上云前后的技术难题，助力企业应用上云更加简单、运行更高效。~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 活动推荐 随着 AI、Big Data、Cloud 的逐渐成熟，FAAS、CAAS 等技术的兴起，以及被运维业务的多样化和复杂化，很多传统的运维技术和解决方案已经不能满足当前运维所需，AIOps 智能运维、大数据运维、ChatOps、SRE、Chaos Engineering、微服务与容器运维等新技术和方向应运而生，它们一方面把最前沿的技术结合到运维中来，一方面在人员角色、领域范围、文化等方面又有了很多扩展，让传统运维有了翻天覆地的变化。来 QCon 北京 2018 与国内外一线技术专家探讨运维前沿技术趋势，及其最佳实践和落地方略。目前大会 9 折报名中，立减 680 元。有任何问题欢迎咨询票务经理 Hanna，电话：010-84782011，微信：qcon-0410。13376 [/indent]

11959 1.人工智能养猪，到底靠不靠谱？尽管2019年才是猪年，但养猪的春天已经提前来到。继网易丁磊养猪之后，阿里也要养猪了。阿里云和两家养殖集团达成合作，将用人工智能改造养猪业。接地气的养猪，忽然就和高大上的人工智能走到一起。行业内议论纷纷，人工智能养猪到底是未来，还是炒作？>>>详情点击 2.2018年的云趋势：无服务器计算、Kubernetes平台和供应商寡头垄断根据市场调研分析机构Forrester的数据显示，尽管公有云计算以其固有的灵活性的优势在企业级的大规模采用仍然没有突破50%的门槛，但预计在全球范围内，到2020年，公共云服务的市场规模将会达到2360亿美元。>>>详情点击3.华为云全球首推K8S无服务器容器实例服务近日，华为云正式发布了云容器实例服务CCI（CloudContainer Instance），这是全球首款基于Kubernetes的无服务器容器（Serverless Container），通过CCI服务，用户无需管理和维护集群与服务器，即可快速创建原生支持Kubernetes的容器应用，尽享容器化带来的极致体验。>>>详情点击 4.福布斯：云计算四方面影响人类生活 未来至关重要美媒称，本周，电信专家将齐聚巴塞罗那参加世界移动通信大会。这个大会是本行业的一件盛事。它为技术企业提供了一个机会，它们可以展示自己在5G技术、人工智能和云技术等领域的最新发明。据美国《福布斯》双周刊网站2月25日报道，尽管“云”远非新理念，但人们现在才开始认识到它的真实能力。未来十年及以后，“云计算”将从以下四个方面影响我们的生活。>>>详情点击 5.光环新网深度报告:IDC和云计算业务双轮驱动,2018年有望继续保持高增长外资云入华获初步认可,公司17年底正式获得云牌照。2017年下半年微软与世纪互联合作获得云牌照,苹果icloud通过与云上贵州合作进入中国,12月AWS(宁夏区域)正式运营,公司公告将不超过20亿收购亚马逊北京区域固定资产,17年12月23日公司正式获得工信部颁发的云服务牌照,外资云获得初步认可相继进入中国市场。国内公有云市场已进入高速增长阶段,2017H1国内公有云IaaS市场整体规模超过10亿美元,同比去年增长近七成。自2016财年以来,阿里云连续8个季度保持100%的高速增长,17Q2营收达到29.75亿元。同时阿里、腾讯云不断在全球市场扩张,在北美市场建立多个数据中心,我们认为外资云进入中国市场、中国云计算企业全球布局大势所趋,光环云计算牌照落地,云计算业务进入高速增长阶段。>>>详情点击 6.人工智能和云计算让芯片业洗牌，英特尔成了最大输家人工智能、云计算、大数据、物联网，以及移动性的发展正在改变半导体行业的现状，而这次行业洗牌将会很有趣。在新的行业秩序中，创新的工作任务（例如人工智能）正迫使各公司设计自己的处理器。领先公司（例如英特尔）的主导地位可能会被削弱。ARM正在关注数据中心市场。曾经的挑战者，例如AMD，正试图通过GPU产品实现复兴。但GPU行业的领导者是英伟达。物联网也值得关注，这个市场的发展趋势有利于高通。>>>详情点击 7.云计算+自主可控带动国产服务器发展惠普关闭在美国的Helion公有云服务;IBM的财报显示，公司的收入大大低于预期;戴尔负载累累，却天价收购EMC;大量裁员传言一直困扰着的惠普、IBM这些传统巨头······ 一连串的新闻，似乎预示着传统IT基础设施提供商风光不再，昔日科技巨头留下了落寞的身影，再一次演绎了科技发展和商业演变的逻辑。>>>详情点击 8.央视财经专访：云计算行业高速发展 政策红利引巨额资本入市近日，央视财经频道就国内云计算行业发展状况对国家超级计算深圳中心进行了专访。国家超级计算深圳中心在云计算服务领域布局较早，创造性地将超算资源应用于云计算服务，使计算机资源既满足高性能计算需求，又能提供强大的云计算服务能力，集约化管理，政企用户可以随时按需购买和使用计算资源，从而避免过度建设，降低使用成本，在超算应用领域领跑国内各大超算中心。>>>详情点击 9.提高湖南中小企业“上云”效率 省经信委推荐一批云服务机构经过专家评审，省经信委近日确定推荐湖南星耀科技有限公司等21家云计算应用核心服务机构、航天云网等7家行业应用云平台、中国电信股份有限公司湖南分公司（天翼云）等46家云服务机构的云计算产品，以提高我省中小企业“上云”效率。>>>详情点击 10.山东政务新闻办：今年要建政务云灾备服务中心近日，山东省政府新闻办举行新闻发布会，介绍山东省政务信息系统整合共享推进情况。据了解，目前第一个时间节点的10项重点任务已顺利完成，2018年将重点抓好全省统一政务云建设、推动数据资源共享开放等六个方面的工作。>>>详情点击

近日，Kubernetes 社区首届指导委员会 ( Steering Committee ) 竞选结果揭晓，华为从 15 家候选厂商 / 组织 (共 20 名候选人) 的激烈角逐中脱颖而出，获得 Kubernetes 指导委员会席位。华为 云 PaaS 服务产品部技术副总裁 Quinton Hoole 成功当选指导委员会委员。Kubernetes 指导委员会是 Kubernetes 社区最高技术决策机构，共设 13 个席位。首届委员会成员中，7 席来自前期成立的引导治理委员会，本次选举产生了 6 席。Kubernetes 指导委员会的成立，是社区治理结构走向完善的重要一步，将引领 Kubernetes 项目持续取得成功。Quinton 的当选意味着华为将在 Kubernetes 的技术演进中扮演重要角色。为什么华为能够当选？华为对 Kubernetes 社区的投入情况如何？Kubernetes 未来会走向何方？带着这些疑问，InfoQ 记者采访了 Quinton。华为是如何投入 Kubernetes 的？华为是 Kubernetes 最早的采用者之一。当谈及这些年，华为在 Kubernetes 社区的投入情况情况时，Quinton 回忆起两年前，当他还在谷歌公司工作时，就了解到华为立足于 Kubernetes 构建完整的 PaaS 产品（即‘FusionStage’），并且为此投入重注，而当时 Kubernetes 才刚刚完成 beta 测试。而时间证明华为的选择是正确的。在 Kubernetes 实践之路上，华为逐渐发现并解决了一些功能缺失问题以及可扩展性挑战等。事实上，在大型企业客户立足其规模化生产环境使用软件时，很多问题才会真正显现出来。华为遇到并解决的很大一部分问题都是通用的，最终华为将自己对 Kubernetes 所做的改进回馈给了 Kubernetes 开源项目。即使对于华为这样的商业企业，向 Kubernetes 这样的开源项目进行回馈所带来的收益，也会超过保留私有特性所带来的竞争优势。事实上，华为通过参与和贡献 Kubernetes 项目，给他们带来了在规划、网络、多集群联合、应用支持、安全、可扩展性和政策执行等方面的良好设计、代码、文档，以及在服务治理方面的收益。当然，还有很多正在进行中的工作。有时候同时参与开源项目并保持自有产品快速发展会有冲突，特别是在有大客户急需某些新功能的时候。不过随着时间发展，这一情况已经大为改善。自 Kubernetes 成立以来，华为作为社区核心成员持续贡献，目前拥有 5 个 maintainer。在对 Kubernetes 社区的贡献中，华为整体贡献在国内厂商中位居第一；从 Commits 维度看，华为贡献国内排名第一，全球排名第五（数据统计来源 cncf.biterg.io）。华为云 PaaS 服务产品部部长贾永利表示：自 Kubernetes 社区建立以来，华为作为社区核心成员持续为社区进行贡献，展示了华为在数字化转型时代服务客户的决心和实力，未来会继续携手合作伙伴在云原生开源领域进行持续的投入。除此之外，在 Kubernetes SIG（Special Interest Groups, 负责子领域路标制定及技术方向决策）及 Working Group（主导跨 SIG 大特性方案设计）中，华为积极参与 Federation、Architecture、Auth 等 10 余个 SIG 及 ResourceManagement、ContainerPolicy 等 3 个 WorkingGroup 方案讨论及设计。同时华为也是首批获得 KCSPs（Kubernetes 认证服务提供商）资质的厂商之一。为什么华为会押注容器技术？在很长时间里，华为以它客户第一的理念而闻名，Quinton 服务过众多大公司，他认为即使在众多标榜顾客至上的企业里，华为仍然做得出类拔萃。因此在多年前某些客户抱怨分布式云应用程序的管理工作太过复杂时，他们投入大量研发资源，深入思考如何更好地解决这一痛点。而最后他们得出的答案就是：基于容器的 PaaS 平台，而 Kubernetes 成为落地这一想法的首选。据 Quinton 介绍，华为的客户对于“as-a-service” 方案抱有非常强烈的需求。他们不愿承受由可扩展、高可靠性计算基础设施的构建工作所带来的沉重负担。另外，他们也不打算投入巨额研发成本来开发并运行分布式软件系统。因此，华为在公有云上也已推出基于 Kubernetes 的服务，云容器引擎 Cloud Container Engine。纵观容器发展历程，容器强大的理论效益及其有效的编排成效实际已经在实践中得到了证实。踏着谷歌及 Facebook 等先行者的足迹，基于他们多年的实战经验，参考他们开放的基础性技术，不少中小型企业也开始作出尝试。虽然容器技术仍然存在一些短板，比如安全问题，但这更多的是成熟度问题。目前，很多企业都在研究和实践在容器里实现微服务模式的应用，因为历史原因，华为仍然有许多遗留的单体应用，这些都需要以新模式进行重构甚至重写。Quinton 称，华为会将分布式计算提升至新的高度。这就需要建立起一套能够广泛使用、全面、统一且强大的分布式应用程序平台。并且关键部分要以开源形式实现。华为会在这些领域投入可观的人力与研发资源。这一切对于华为自身、客户以及整个云计算领域的成功都将起到决定性作用。上月，Docker 宣布支持 Kubernetes，大家都在说容器编排大战宣告结束，Kubernetes 胜利了。Quinton 认为如果从目前的采用率与统计结果来看，Kubernetes 显然在数字层面成为毫无疑问的赢家。Kubernetes 的前景光明Mirants 创始人 Boris Renski 前段时间发布了一篇文章：Kubernetes 是否会重蹈 OpenStack 的覆辙，Boris 认为如果 Kubernetes 允许不同容器技术栈不受限制的发展，也许会陷入运维带来的麻烦里。Quinton 认为，自己对 OpenStack 了解不多，无法评价其项目，但是可以谈谈自己对 Kubernetes 的看法。Kubernetes 拥有一套非常坚实的技术基础，站在了 Google 内部久经考验的容器管理系统 Borg 的肩膀上；同时也吸取了旨在替代 Borg 但是没有成功的 Omega 项目的失败经验。另外，Kubernetes 在 Linux 基金会的云原生计算基金会 ( CNCF, Cloud Native Computing Foundation ) 当中也得到了非常有效的治理架构。CNCF 这个组织是开发把云原生应用作容器化微服务部署的开源技术先锋，其所依托的 Linux 基金会其在众多开源项目中积累了近二十年的实践经验——其中包含大量全球范围内最大且最为成功的开源项目。可能 OpenStack 或其他开源社区 并不具备这样深入的实践。可见，Kubernetes 拥有更加强大的技术基础与坚实的治理架构，而且已经成为一个无论是在技术层面还是在采用度层面都已经取得巨大成功的开源项目； 此外，其还拥有一个健康且积极的技术社区。因此在 Quinton 看来，Kubernetes 的前景是光明的。

大家好，我是来自于华为PaaS部门的钟成，目前正在做相关的一些产品研发。我想分享的主题是从Borg到Kubernetes，其实Borg就是Kubernetes的前身。我今天主要会谈三个方面，第一个是Borg的介绍，第二是Kubernetes基于Borg做了哪些改变，以及它的发展方向，第三个话题想谈一下未来的云可能需要一个怎么样的产品或者是怎么样的形态。 Borg是什么？它解决了什么问题？我们先看第一个话题，就是Borg是什么？它解决了什么问题？ 我们看一下这张图，这张图来自于一部电影叫做《星际迷航》相信大家大部分人都看过。Borg是里面的一种外星人，反派，他做什么事情呢？他和其他的文明接触，把你这个文明抢占下来，然后它会和你同化，会把你进行改造，把你改造成一个半人半机器的怪物，你就变成他们这个文明当中的一部分，然后他在这个宇宙当中不断的扩张下去。我觉得这是一个非常酷的种族。而Borg就以这个名字来命名其大规模分布式的集成管理系统。他希望他们的系统也可以把不同的机器同化掉，变成他们自己的机器，然后运行他们自己的程序。 5427对谷歌来说，Borg是一个比较顶层的集成管理系统。在它上面跑了谷歌大部分的应用程序和框架包括Gmail、Google Docs、Web Search这样直接面对客户的一些应用程序。它同时也包括一些底层的框架，（MR），包括它的一些GFS这些分布式的存储系统。也就是说你可以认为所有的应用程序都需要通过它来管理底层的这些物理机。Borg在谷歌已经成功的应用的十多年。 5428大家可以看一下Borg的整体的架构。它也是一个典型的分布式平台的架构，就是一个逻辑上的master，然后下面有很多的节点，每一个节点上有一些它的代理程序。这里就可以看一下，作为谷歌内部的一个工程师怎么样用这个系统呢？他们使用Borgcfg（命令行）或者Web UI提交需要跑的应用（Task） 到系统，Task可以是任何一种东西，比如说他是一个应用程序，或者是一个批处理任务，或者是一个（MR）的任务。他把这个任务通过Borgcfg提交到BorgMaster，然后BorgMaster会接受这个请求，把请求放到队列里面去，并由Scheduler来扫描这个队列，查看这个应用的资源需求，并在集群中寻找匹配的机器。你其实提交的这个任务，它需要多少的资源，你需要怎么样的机器，大概要跑多少时候，他会做一个匹配，就会看到底层有哪些机器是空闲的。然后就把这个任务发配到这个机器上面去，然后开始运行。5429 这个就是总体的一个Borg的框架。一个典型的启动时间，从用户提交应用到应用启动是25秒。其中80%的时间是每个节点上下载这个应用包的时间。大家可以看到这个时间是很快的，它的调度时间还不到5秒，其中20秒是耗在传输这一层上。 关于BorgMaster的调度原理我后面主要想探讨一下，我今天想说的一个重点就是关于BorgMaster，它这里有很多应用，它怎么样调动这个应用的优先级呢？或者说到底哪台机器应该跑什么应用呢？Borg的做法就是对单个Task做了一个资源上的估量，大家可以看到这里有好几条线，其中一个机器上面最外面的那条虚线就是用户提交的一个资源的一个配额，就是Task再怎么运行也不能超过它的限制，这是一个硬性的限制，如果说超过这个限制，就会限制它，不让它跑。这只是用户提交的数字，大家知道用户提交的数字很多时候是不准确的，你无法预估到底你的程序在你的系统上需要耗多少CPU，占多少内存。Borg是怎么去评估这个资源呢？他在Task启动300秒之后，就进行一个资源回收的工作。大家可以看到中间有一个黄色的区域，黄色的区域就是这个应用程序实际上所消耗的资源。然后它会从外面，慢慢把它推进去，推到绿区的地方，推到绿区的地方划一条线，这条线就是所谓的保留资源，就是Borg这个系统认为你这个应用是长期稳定运行的所需要的资源。5430 这里就有一个问题，为什么Borg要这么做呢？原因是为了把剩下的区域的资源给空出来，如果说我知道这个应用实际上就用了这么多的资源。然后我给它划了一定的安全线之后，剩下的这些资源我就可以调度出来，也就是说可以给到其它的应用程序用。 绿色的这一块是黄色的块加上一些安全区组成的，每过几秒重新计算一遍应用程序耗费了多少资源。这实际上是一个动态的过程，它并不是说划走了之后就再也不能变了。绿色的方块是可以一直拓展到外面的虚线的范围之内。这就是对单个Task做的一个策略。然后通过他对系统上跑的应用做了一个区分。就是说，他先想了一下，到底有哪些应用，这些应用有什么样的特性。其中有一类应用就是所谓的生产型的应用，就是prod task，其特征就是永远都是不停止的，他是一个长进程，它永远是面向用户的，比如说Gmail或者是Web Search，它中间不可能断的，它的响应时间是几微秒到几百毫秒。然后这种任务就是说，你必须要优先保证它的运行，它的短期性能波动是比较敏感的。 还有一类任务就是所谓的non-prod task，他是一个批处理任务，类似像Map Reduce，它不是直接面向用户的，对性能不是非常的敏感，跑完了就完了，下一个再跑就是下一个任务了，不是一个长进程。5431为什么要区分任务？当prod task的资源任务消耗比较大的时候，比如说很多人突然都来上一个网站，这个网站的服务器内存CPU就会非常高。这个时候，在这台机器上应用资源不足的时候，他就会把Non-prod task杀掉，杀掉之后让它去其他的机器上去运行。但是在空闲的时候，就可以让任务继续回来。这样的话，我就可以充分利用这台机器上的所有时间点上的资源，可以把这些东西塞的比较满。最后谷歌的测试结果是，大概20%的工作负载可以跑在回收资源上。这个数据其实是非常大的。对谷歌有那么多台的机器，你可以省下20%的资源，对它来说就是非常非常多的钱。 Borg的价值我这里稍微总结一下，Borg这套系统给谷歌提供了什么样的价值。它主要是提供了三个方面。第一个是隐藏的资源管理和故障处理的细节，让用户可以专注于应用开发。用户不用操心底层的系统是怎么操作的，就算我挂了他也会帮我启起来。第二个是本身提供高可靠性和高可用性的操作，并支持应用程序做到高可靠高可用。第三个是在数以万计的机器上高资源利用率运行。 对于Borg具体怎么做到这三个方面，google有一篇很长的论文《在Google使用Borg进行大规模集群的管理》，里面有很多细节，今天就不展开说了。 Kubernetes架构自从谷歌把Borg这个系统推出之后，对内部来说是非常成功，但是在外面的社区，其实大家都不知道这个东西到底是怎么做的，也不知道他内部是怎么实现的。后来做Borg的那批人他们就做了另外一个软件，这个软件就是Kubernetes，Kubernetes总体而言你可以认为是Borg的一个开源的版本，但是Kubernetes和Borg有一些不一样，我后面会大致的讲一下。这是Kubernetes的架构，大家其实可以看到，它的这个架构和Borg的架构基本上是类似的，包括用户怎么用的也是类似的。用户通过用kubectl这么一个命令行工具，把任务提交上来。5432Kubernetes与Borg的区别Borg在谷歌已经运行了十年，而且机器的规模量非常大，他一个集群就是一万台，甚至更多。而Kubernetes是2014年才出来的，我个人认为这是针对亚马逊，亚马逊的公有云非常的成功，谷歌也想进入这个领域，他的方式就是把Kubernetes这个系统开源推出来，在业界产生一定的影响力，让大家都去用。这样的话，后面就可以和亚马逊竞争一下，这是我个人推测他们的一个想法。 Borg底层用的是lxc的容器，而Kubernetes是用的Docker容器。Borg是用C++编写的，Kubernetes是用Go语言编写的。Borg在集群调度的性能上做了很多的优化，Kubernetes还没有做非常多的优化，目前他在这方面还是比较土的，后面还有很多工作需要做。Borg的单集群能够调度的机器有上万台，而按Kubernetes目前只能支持几百台，这是目前的数据。 然后我们再看一下，对于这两个系统的用户来说它们有什么区别。Borg的用户其实就是谷歌的一批工程师，大家也知道谷歌工程师都是世界比较顶尖的工程师，他们在写这个程序的时候就考虑过程序会跑在云上，他知道这个程序是分布式的。他在写这个应用的时候，就会针对这个系统做非常多的优化，在设计的时候就知道我应该做一个分布式的系统。但是Kubernetes他想做的事情更多一些，就是除了运行这些分布式的系统之外，他还想就是说能够支持一些，他首先是支持Docker的这些容器，但是他还希望支持一些比较传统的，比较菜的，技术水平一般的人写的这些应用程序。他在这方面做了一些工作。一个是用了Docker容器，这样的话就支持很多东西了。还有内他还可以挂载外部的持久层，就是你可以把一些分布层面的系统挂在那个系统上面。我的容器就去读取外部的分布式的存储。这样的话，我这个容器就算是挂了，我这个数据也可以比较安全的保存。另外他就提供了一些监控还有一些日志的功能。但是这些功能是不是够呢，这还是有一定的疑问的。后期如果说我想用Kubernetes来跑一些传统的应用，那我肯定还会对这些应用和系统做一定程度的改造，但至少没有困难到无法完成。 这个是它Kubernetes设计上的一些特色，Kubernetes的网络架构是每一个Pod都有一个单独的IP，这样的应用更加友好一些。写应用程序的人就不用考虑冲突这种情况。还有就是它分组的模式，就是我这些容器如何分组。Borg是一个比较专家的系统，他有230多个参数，但是Kubernetes是非常简单的大概就是三四个描述文件就完了。 Borg和Kubernetes的形象化总结这里就是我对Borg和Kubernetes的一个形象化的总结。Borg就是一个喷气式飞机的驾驶系统，非常的专业和高大上，他适用于谷歌这样的大公司，它有几百万的机器。Kubernetes是一个它的简化版，它是一辆设计优良的轿车，它适合中小型公司，用它来对自己的集群进行调度。 未来Kubernetes这边也会做一些相应的工作，包括多租户支持，包括容器持久化、集群规模的提升、利用率和网络方面的等等。5433未来的云需要什么？最后可以说是我个人的一些思考。我们未来的云到底需要什么样的东西。大家可以看到，自从计算机风靡以来，有很多的系统，很多的软件，一波又一波的起来，有一部分的系统或者说软件是比较成功的，可以长久存在下去，比如说像Java、或者是C，或者是像Windows这样，还有一些系统非常不幸，像Cobol或者是DOS或者是Minix这些系统，它们慢慢的被人所遗弃，慢慢被人所遗忘，最后变成废弃的停车场。 我这里想考虑一下，如果说再过十年，我们现在在用的一些技术，像Kubernetes或者是Borg这样的技术，是会进入到左边这个行列还是右边这个行列呢？我个人是希望进入左边的行列，毕竟我们还是希望他可以成为一款经典的产品。至少对这些系统来说，我们会非常自豪，我们做了一款比较经典的产品，可以长久的被人们所使用下去。 如果说想做到这一点，就得面对我们现在这个时代，整个计算机系统所面临的一个困境，或者说我们集群管理系统所面对的一个困境。这个困境是什么呢？就是这里所展示的Babel塔的困境。在以色列那个地方，这是一个圣经的故事，人们想造成一般座通天之塔，他们想挑战上帝的权威。上帝一看你们这批凡人，就觉得你们这批鸟人居然敢挑战我的权威，他就发明了各种语言，一起做巴别塔工作的人就各自使用不同的语言，他们就无法交流，最后这个塔就造不下去了。 其实在计算机的世界也是如此，大家使用各自的语言，各自的框架，最后使我们合作起来非常的复杂。包括我们的集群管理系统也好，包括其他的系统也好，其实都是帮助我们跨越这个鸿沟，帮助我们大家可以比较好的进行合作。但是目前来说，还没有一个非常好的方案可以让大家非常好的进行合作，我觉得这个是我们做这个系统需要做的一个事情。我这里引一句老子的话，大家可以看一下。 [indent]三十幅共一毂，当其无，有车之用。 埏埴以为器，当其无，有器之用。 凿户牖以为室，当其无，有室之用。 故有之以为利，无之以为用。[/indent]我在想，是什么因素决定了一个系统或者是一个软件，它是否可以长期生存下去呢？我觉得非常重要的一点，他要明确自己要做什么。其实就是前面讲的端水的端水，扫地的扫地，就是说你不但要明确自己这个软件要做什么，还得明确自己不要做什么。你什么东西是无以之为用，就是这个领域我是不进去的，我是不去做的。如果说你什么东西都做，最后就会比较弱，很容易就会颠覆，或者是被人取代。如果说你单单把一件事情做好，那你今后在这个领域，至少你是无可替代的，可以长期生存下去。我记得前一段时间有人问Linus，怎么看Docker容器。然后他说我才不关心这什么狗屁容器，我就关心我的内核，你不要来问我这个问题。我觉得他这个就是一个非常好的一个态度，他把他自己内核这一个模块做好，他把他系统这一块做好，那么对他而言，他这个工作就可以长期延续下去。 那么对于我们来说，比较详细一点，就是说在我们软件开发当中碰到的情况是这样的。从我们的软件设计到开发到测试、生产都经过非常多，非常反复的过程。同时在大部分的集群系统当中，我们也非常难以调度它。那么我觉得对于我们来说，就是后面要解决几个方面的问题。我觉得这是我们一个大的方向。 我们以后的产品是不是可以减少语言、程序、框架不同带来的复杂性，能不能把流程进行简化，把语言进行简化，把网络和服务依赖进行简化，这是我提的另一个问题。