如何打造一个更好的 Kubernetes 发行版
技术
作者:于爽
译者:小君君
2018-08-10 11:16

企业在使用 Kubernetes 前需要准备:重构业务以更适合微服务框架;重构应用程序,将其分离到不同的服务单元并容器化;雇用更多技术精湛的员工;重建整个团队的技能集和管理流程以采用 DevOps。这个过程很复杂,所以需要一种产品/服务来缩短企业使用 Kubernetes 的过程,减少学习成本、人力成本,并将更多资源用于业务开发。 

Gartner 分析认为,在 2020 年,大概有 50% 的企业会将他们的业务容器化,基于 Cloud Native 容器化之后,将业务跑在它的生产环境里。目前这个比例只有 5%,但用 2 年的时间就会有 10 倍的业务提升。这对企业内的技术人员来说是一个积极的信息,说明 Kubernetes 是一个值得投入人力和精力的大趋势领域。接下来我将基于公司目前打造的一款 Kubernetes 发行版,总结一下在构建整个发行版的经验。 

使用 Kubernetes 问题与挑战 

Kubernetes 如此强大的平台,如此多的便利功能,也是有缺点的。比如说 Kubernetes 学习成本比较高。 

案例一 

在 1 年前,我们基于 App Center pass 平台,交付了我们的 K8S APP。我们是把一个全托管的 Kubernetes 集群,交付给客户,客户可以通过一键部署,拥有 Kubernetes 的集群。 

用户在使用这个 Kubernetes 集群时,会碰到一些实际问题。比如一个互金客户,他是运维人员,以前他搭建一个环境,都是基于传统虚拟化,需要 50 分钟左右。而他基于 Kubernetes 搭建相同的一套环境只需要不到 5 分钟。 

以前搭建集群,这套环境是所有开发测试人员共用的。基于 Kubernetes  后,每一个测试人员都拥有一套独立完整的环境,他们利用 Namespace 去做资源隔离。但他们整个运营团队,都要围绕 Kubernetes 这套环境,在外围构建更多东西,就像它的 CI/CD(持续集成/持续交付),还有企业内部的一些业务系统集成,需要通过我们 的 App Centerde 开放的 API 进行二次开发以完成对集群自动化操作。

 案例二  

近日,一个运维人员最近总是收到很多业务人员的抱怨。之前进行的容器化改造,他们已经花费了很大力气。现在要跟他们介绍 Kubernetes。但开发者们并不关心你的平台是什么。他们关心的是业务能力,通过熟悉的代码,将业务能力变现,提供给企业,转化成企业价值,所以他不愿去承担这种额外的学习负担。
 

当你把一个 Kubernetes 集群抛给他们时,他们是不会关心这个 Pod、Namespaces 是什么。开发人员的期望是,代码提交后能给他一个可以访问的入口去测试。出现问题时,可以给他一个能看监控日志的地方,他们并不关心你用的是什么平台环境。这就是 Kubernetes 本身的问题,它学习成本高,环境搭建复杂。

对于企业来讲,它有一定的隐形成本,这个隐形成本是什么?你需要有一个专业的团队,帮你运维相应的东西。现在企业人力是最贵的,运维这样的团队,企业会产生很大的负担。另外 Kubernetes 本身的多租户比较复杂。在一个大型企业环境中,如何通过 Kubernetes 这套多租户去对接现有企业 IT 环境里的权鉴系统,这是一个问题。另外它作为一个开源项目,怎样去获取持续支持,也是一个问题。  

 Kubernetes 发行版 

Kubernetes 发行版是没有统一的定义,在 CNCF 社区的 Landscape 页面可以看到经过社区认证的 Kubernetes 发行版。这里有很多版本,这对于用户来说是非常苦恼的,用户在接受 Kubernetes 已经花了很大的精力,但面对这么多发行版又该如何选择呢? 

在我看来 Kubernetes 发行版是底层基于原生、定制化的 Kubernetes,在上层封装多种服务组件,在 Kubernetes 之上提供更多的增值服务,满足企业内各种场景需求的分布式容器编排管理平台。就像 Linux 发行版是基于 Linux 内核提供的一种操作系统。同样  Kubernetes 是在分布式领域一个内核,发行版就是在这种内核之上,去构建一个可用的分布式操作系统。 

对于企业来说 Kubernetes 最重要的几点是什么?  

第一,就是安全。安全和管控是企业用户最关心的问题,Kubernetes 本身的这种安全设计,虽然功能很强,但是它并不友好,复杂且没有一个管控入口。比如说你可以通过命令,看到和管理里面的一些权限配置。但是它没有很好的集成方式,管理起来也比较分散复杂。从发行版的角度来看,是能够去对接企业现有的这种权鉴管理系统。 

第二和第三个难点是网络和存储,也是最难的两件事。Kubernetes 专注的是一个分布式的调度平台,它的网络化存储基于统一化的标准,开放给其他存储和网络厂商,来帮助开源项目或是个人开发者去构建网络存储解决方案。如何帮助企业做适合他们业务的网络化存储选型,这是重点要考虑的事情。

比如,我们在 QingCloud AppCenter 上交付的 Kubernetes 集群,通过自己开发的网络插件,存储插件,和 LB 插件,对接到现有的网络、存储,和负载存储器。在 我们的 Kubernetes 发行版里也会有类似的交付物给客户。 

比如,在基于非云平台的环境上,它没有 LB 的能力。我们也即将开源一款基于物理交换器的 LB 插件,通过它可以对接物理交换器,在 Kubernetes 环境里,把你的后端业务暴露出去,提供给集群之外去服务。另外 Kubernetes 对于 CI/CD 场景、服务治理场景,应用管理场景,它都没有太好的支持。 

 Kubernetes 发行版应该帮助企业去解决这些问题。部署 Kubernetes 是比较复杂的事情。虽然现在有很多自动化的工具可以帮你很快地搭建一套 Kubernetes 环境。但是学习这些自动化工具,会带来一定成本。从发行版的角度,应该为用户提供一种习惯性的向导式的安装方式快速搭建一套 Kubernetes 环境。

从发行版的角度来看控制台是一个很重要的地方,它是发行版产品的一个入口,客户通过这个入口,接触到 Kubernetes。以前 Kubernetes 只是通过 kubectl 的入口。虽然,社区是通过一个开源项目 Dashboard 提供 UI 的能力,但交付东西对用户来说,有一定的学习成本。因为他是完全按 Kubernetes 这个架构去提供 UI 的,它的一些功能比较弱,所以从发行版来看,应该去帮用户来解决这些问题。
 

什么样的用户能够从发行版上获得益处? 

第一种用户,之前的业务是基于传统虚拟化或用物理机去构建。如果它现在有这种容器化的需求,就可以通过发行版,快速迁移到这种容器化平台上。

第二种是已经容器化的客户,他之前的业务量可能比较小。以前基于 Docker Swarm 简单的集群,就可满足业务需求。但是随着整个业务的提升,它需要迁移到一个大规模的容器调度平台来帮助它去提升业务能力,通过发行版可以快速迁移到整个平台之上。 

第三和第四种,是接触 Kubernetes 比较早的用户。他们在自己的 IT 环境里,构建了一些 Kubernetes 环境,也许这些环境是通过别的厂商来提供的,但这些都会给他们带来很大的额外负担。 

在运维上,它需要有相应的运维人员帮助他们去管理这些来源不同的 Kubernetes 资源。如果是不同厂商提供的 Kubernetes,会有各自的平台入口。企业是希望通过统一的入口,把所有 Kubernetes 管理起来。发行版就是一个很好的统一平台入口,将这些不同来源和版本的 Kubernetes 管理起来。 

不同 Kubernetes 的发行版基于不同的业务需求,不同的考量,还有不同的设计架构。各家交付与设计出来的东西不同,但是它都会有一个基本的架构。 


 基本上是这种三层的架构:

  • 底层可以去对接不同的计算资源,可以是物理机、虚拟机、不同云厂商提供的平台;
  • 中间层可以把不同的 Kubernetes 集群管理起来。对于网络存储,它可以通过不同插件,对接底层计算平台的网络和存储;
  • 上层可以提供不同的业务解决方案,比如说 CI/CD,它可以提供监控日志告警、安全、应用管理、服务治理,可以交付给用户真正地使用。

关键场景方案选型:微服务治理 

我们在做 Kubernetes 发行版时,做了一些业务、产品上的选型,调研得到一些结果供大家参考。在这并不会说哪种解决方案最好,从企业人员角度来看是要考量企业内部的业务,究竟适合哪种场景,然后去选择适合自己的解决方案。 

场景一 

对于我们自己打造的 Kubernetes 发行版,当时考量的是两种解决方案,一种是基于Spring Cloud。另一种是基于 Istio。Spring Cloud 是 Java 语言绑定的,这意味着你在写 Java 代码时,基于这种标准,你需要在代码里写进各种标签。这就意味着开发人员会承担更多的责任。另外,Spring Cloud 的服务发现是基于 Eureka 组件做的。但  Kubernetes 本身会提供服务发现功能,这就有功能上的重叠。Eureka 和 Spring Cloud 也意识到了这个问题。它现在做的另一个方案就是利用 DiscoveryClient 去满足 Kubernetes 这个平台的需求。但 DiscoveryClient 现在还在孵化阶段。 

另外,Spring  Cloud 有代码侵入,它需要在代码里插入相应的标签。同时,Spring  Cloud 在做部署调度时,要通过 Spring Boot。Spring Cloud 专注的是服务治理,它要把整个流程串起来还需要其它的组件来完成整个的业务链条打通。 

但是 Istio,第一,它跟语言无关;第二,它是基于 Kubernetes 做的服务发现;天然的适合 Kubernetes 这个平台;第三,它不会侵入你的代码;第四,它的调度部署是直接使用 Kubernetes 本身的功能。

在我们自己的 K8S APP上,很早就把 Istio 作为一个服务组件,集成到这个 Kubernetes 的 APP 里。当时 Istio 是 0.6,后来又更新到 0.7。有些客户就反映,Istio 有很多问题且性能相对较低。 

目前我们在调研的 Istio 0.8 这个版本,它这已经能够很好的解决之前的一些问题。同时,我们对它今年要发布的 1.0 版本也比较有信心,相信它能解决之前一些性能上的问题。 

场景二 

另外一个关键场景,就是 CI/CD 的持续集成、持续交付。它涉及到了三个环节,第一是应用管理,你的应用如何去交付,如何去做应用包管理。Kubernetes 本身在这个平台上有一个开源项目叫 Helm。比如,Linux 发行版在安装一些软件时,通过 apt-get 或 yum 去装。Helm 在 Kubernetes 这个平台上类似于这种地位,它是做应用包管理的。 

如果我要在产品里面去集成,把这些三个链条,三个阶段去打通,去集成这些产品的话,会给我带来很多的风险,比如说权限管控,流程管控,如何去跟企业现有的这种权限系统去做集成。 

为了解决这些问题,我们决定以微服务的方式去构建我们的 CI/CD 模块,基于 Kubernetes 去交付,这样可以天然地利用平台的种种已有功能区降低风险,比如发行版上已有的权限管理,调度等功能可以直接作用于 CI/CD。 

实践分享 

在做 Kubernetes 发行版时遇到的问题 

第一,就是 etcd 和 MySQL。发行版最重要的就是给用户提供统一的入口,用户体验是至关重要的。Kubernetes 把它整个集群里面的信息都注册到 etcd 里,但以 UI 的方式去把 etcd 交付。这并不是一件很友好的事情。因为 etcd 是一个分布式的 KV 存储系统,它比较适合订阅,服务发现等场景。 

但在 UI 里,通过 etcd 去做一些分页和复杂性的检索会比较麻烦。最终我们通过 watch etcd 里的数据变化,把相应的数据导入到 MySQL 里。这样前端人员直接面对的就是 MySQL 的后端数据业务展示,聚合会比较方便。 

第二,监控。Kubernetes 监控,它本身推荐了几种方式,包括 Heapster,Metrics Server,还有 Prometheus。那么 Heapster 已经是 deprecated 的状态,但它还是在维护阶段。Heapster 可以支持到 1.12。Heapster 页面的替代品是 Metrics server。但是 Metrics server 还在孵化阶段,它的 Metrics 提供的监控比较少,它也支持不了 kubectl top,无法看到资源使用率排序数据,而且 Metrics server 在社区活跃度很低。 

Prometheus,它不只支持 Kubernetes 这个平台,它还支持其它的一些平台。但这种通用的解决方案使用起来过于复杂,我们期望的是一种简单化的方式交付给用户。 

目前,我们使用 Heapster 作为临时解决方案,把数据 sink 到 Kafka,这样很方便我们做 HA。通过 Kafka 去做第三方系统集成。在这种大型企业里,已经有监控系统和日志管理系统。我们发行版会提供内置的监控和日志这些服务组件,但是企业并不会去采用,企业想把所有监控信息,日志信息通过统一的平台把它管理起来,所以我们要提供这种第三方对接的功能。 

另外,我们在使用 Heapster 的过程中碰到一些问题。不同规模的集群,比说上百上千的这种集成规模,需要对 Heapster 所占用的资源进行调整,根据做集群的规模的不同去做调优。Heapster 对于开发者并不友好。它的每个 Metrics 都是一个独立的 REST API,前端使用起来很麻烦。 

小结 

Kubernetes 已经占据了容器编排领域的主导地位,但其高昂的学习以及运维成本,导致个人和企业用户望而却步,在这个分布式操作系统的内核之上,我们打造了我们认为更好的 Kubernetes 发行版,让它能更贴近于用户,让用户更专注与自己的业务。在这个过程中,我们碰到并解决了诸多问题,借这次机会和这个平台分享给大家,希望能给各位在日常使用和评估相关 Kubernetes 产品的时候提供一定帮助,谢谢。 


于爽 / Qingcloud 容器平台资深架构师 

青云容器研发工程师,负责青云 QingCloud PaaS 平台容器相关服务的设计与研发工作。 

151 comCount 0