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

本帖最后由 橘色祥云楼楼主 于 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容器。然后他说我才不关心这什么狗屁容器，我就关心我的内核，你不要来问我这个问题。我觉得他这个就是一个非常好的一个态度，他把他自己内核这一个模块做好，他把他系统这一块做好，那么对他而言，他这个工作就可以长期延续下去。 那么对于我们来说，比较详细一点，就是说在我们软件开发当中碰到的情况是这样的。从我们的软件设计到开发到测试、生产都经过非常多，非常反复的过程。同时在大部分的集群系统当中，我们也非常难以调度它。那么我觉得对于我们来说，就是后面要解决几个方面的问题。我觉得这是我们一个大的方向。 我们以后的产品是不是可以减少语言、程序、框架不同带来的复杂性，能不能把流程进行简化，把语言进行简化，把网络和服务依赖进行简化，这是我提的另一个问题。

作为容器集群管理技术的最流行的技术，kubernetes，自从2014在github上开源后，已经通过多个项目形成了一个生态，以下是从用户角度对这些项目做一些基本的认知kubernetes主项目，实现了容器集群的调度管理，并以restful接口的形式暴露出来，可以认为是云操作系统的的内核apimachinery客户端和主项目共同依赖的一个库，开发者使用dashboard官方Web界面，降低用户使用难度test-infra测试工具frakti用于驱动hyper启动独立内核的虚拟机+容器，达到内核级别隔离，比docker方式更安全，代价是资源消耗更多外加操控不方便minikube单机上快速启动kubernetes，之所以有这个项目是因为kubernete本身的安装部署是针对大型系统的，在单机上没有docker那么方便helmhelm可以认为是kubernete上解决安装容器之间互相依赖的工具chartscharts是helm包的服务端定义client-go客户端SDKingress用于动态连接外部LB并提供服务kubeadm这是文档项目，kubeadm是用来在各种异构IaaS上安装kubernetes的dns在容器集群上提供dns服务release用于在各个操作系统上发布安装包node-problem-detector节点问题探测器，本身是kubernetes的一个应用kube-state-metrics对集群监控数据状态的加工并再次处理heapster监控数据转发项目kops又一个kubernete在云上的安装工具，看来安装果然是一大痛点简单点评目前整个社区明显是采用了集市方式而非大教堂的方式来开发，主项目内部概念内聚，外部各种项目蓬勃发展，外围项目中又以kubernetes系统的IaaS部署、监控、图形化、应用依赖管理这四者的项目关注度和贡献度最高，也是用户的痛点所在，目前社区获得的关注度很高，但在端到端的用户体验上还有很长的路要走。

华为云技术私享会是华为云面向中小企业、创业公司的开发者、程序员分享技术精华的线下活动。华为云PaaS第一站于本月17日来到北京中关村，和大家分享PaaS产品微服务、中间件的云上风采。接下来第二站[云安全]将于本月24日在北京赛欧孵化中心登场。微服务作为一颗冉冉升起的新星，如今正逐渐成为一种主流的架构。云中间件，成就了电商平台的超级承载力，实现了系统快速水平扩展。实力现场：技术大咖面对面私享会开场，四位华为云PaaS资深架构师分别从不同角度讲述了微服务和云中间件的技术精华与产品特点。·开场惊喜：应用架构演进技术面对面-微服务和中间件华为云微服务架构师张琦从速度（业务上线）与安全（系统在一个可靠的状态下运行）切入，介绍了微服务在传统企业应用开发模式缺陷下，逐渐突显的重要性，以及构建微服务架构的应用系统——Chassis和Side-car。华为云微服务架构师张琦·经典环节 ：给我一杯咖啡的时间，玩转企业IT系统微服务化上云身着ServiveComb logoT恤的华为云微服务架构师郑扬勇介绍了微服务开源项目ServiceComb的来历、发展、子项目。ServiceComb作为一个功能完善的微服务框架，包括应用框架代码生成，服务注册发现、服务配置管理、服务监控、服务调用追踪、多通信协议支持等功能，为开发者提供端到端的应用DevOps体验。此外，还介绍了ServiceComb 中的Java Chassis架构，并进行现场演示。华为云微服务架构师郑扬勇·特别环节：基于Service Mesh实现非侵入式微服务方案演示华为云微服务架构师、文艺男神田晓亮从控制面、数据面讲解了最新研发的Mesher的各大优势，并分析了ServiceComb侵入式和Mesher非侵入式微服务的联系与区别，以及未来的发展趋势（两者结合），当然，现场演示如何使用Mesher也少不了。华为云微服务架构师田晓亮·有趣环节：基于分布式云中间件，15分钟实现海量数据的高可用架构演变幽默风趣中间件华为云架构师黄靖凯在此环节回顾了他的成长史——云中间件的成长史，介绍了华为电商云的架构和典型服务，以及如何使用华为云，快速搭建一个云上电商系统以及分布式缓存的服务（DCS）内容，并演示了“电商系统的分布式改造”。华为云架构师黄靖凯精彩互动：线上线下享不停除大咖分享外，本次私享会还给大家准备了神秘礼包、亲密交流等环节，无法来到现场的朋友也能通过线上直播参与进来。·神秘彩蛋：电商系统的分布式改造终环节，为粉丝们准备了专属的400元礼包，随后通过二维码扫描进入了华为云demo的界面。20分钟后，华为云资源购买模拟完毕；10分钟后，电商系统的应用系统部署(传统的单体应用)完毕；电商系统的分布式改造(基于分布式云中间件)难题也解决了….又快又顺畅！华为云技术私享会PaaS首站现场·现场问答：面对霸气外露的“技术巨星们”，热情的”粉丝们”不管是以往使用微服务或中间件产生的疑问，还是现场产生的新想法，都踊跃提出积极交流，现场气氛一片火热。·线上互动：来不了的“粉丝”也没有被忘记，线上直播同样如约而至，300+人次观看，互动区更是评论爆满…来日再约：我在赛欧孵化中心等你如果这一次你依然错过了，没关系！11月24日，下一场华为云技术私享会-如何做好云上安全将在丰台区赛欧孵化中心，5F咖啡举办，一起玩耍吧！本次私享产品免费中，登陆华为云官网即刻体验微服务引擎CSE：http://www.huaweicloud.com/product/cse.html分布式数据库中间件 DDM：http://www.huaweicloud.com/product/ddm.html分布式消息服务DMS：http://www.huaweicloud.com/product/dms.html