您当前的位置是:  首页 > 新闻 > 文章精选 >
 首页 > 新闻 > 文章精选 >

如何打造一个企业级 Kubernetes 发行版

--知行学院总结

2019-01-23 15:46:13   作者:   来源:CTI论坛   评论:0  点击:


  知行学院是青云QingCloud 为广大 CIO、架构师、开发者、运维工程师、技术爱好者提供的一个云计算、大数据、容器等技术的最佳分享与实践平台。其中包括线上技术公开课、云产品解析、线下实践课堂、行业沙龙等众多知识分享形式。
  本次我们邀请了青云QingCloud 容器平台产品经理于爽(Calvin Yu),带来《如何打造一个企业级Kubernetes 发行版》。
  正文:
  作为 KubeSphere 线上培训教程的第一节课,今天的内容覆盖几个方面:第一个是介绍一下 KubeSphere 这款容器产品产生的背景,第二给大家比较一下 KubeSphere 和原生的 Kubernetes 的区别,第三部分会介绍一下 KubeSphere 高级版 1.0.0 里面主要的功能,最后会有一个 Demo,给大家展示一下 KubeSphere 整体的使用方式。
  第一部分
  KubeSphere 产生的背景
  这个是 Gartner 在今年发布的调研报告,Gartner 认为到 2020 年大概有 50% 的企业会将内部非常重要的业务容器化,放到容器里面去跑、而且是放在生产环境里面跑。2018 年这个比例只有 5%,而两年的时间将会有十倍的提升。
  那么,为什么现在越来越多的企业要采用容器呢?
  容器带来的改变
  第一个原因就是相比于传统的虚拟化技术,容器可以把主机资源的利用率最大化,可以带来更轻量地资源消耗,避免无意义的资源损耗;
  第二个就是通过容器我们可以把IT界讨论的比较热的一些话题,比如 CI/CD、微服务这些从理论变为现实。特别是 CI/CD 这一块,这也是很多使用容器的客户的主要诉求,在没有容器之前,并不是说无法做CI/CD,但缺少了容器这种轻量的标准化的交付方式,带了架构沉重、效率低下、环境不一致等问题。
  基于标准化容器镜像的构建方式以及统一镜像的分发仓库,用户可以使用一系列自动化运维的工具完成从开发、代码提交、测试、预发布、发布一整套完整的流水线,它相比较于传统的基于虚拟机的交互方式更经济、更高效。同时基于容器我们可以实现跨平台的部署,企业就没有平台绑定的风险了。
  使用容器需要管理调度平台,Kubernetes 无疑是现在这种管理平台市场里最主流、最受认可的一个平台,我们知道用户想使用 Kubernetes 的热情是非常高涨的,但是它有一系列的问题。
  使用 Kubernetes 的问题与挑战
  首先就是学习成本比较高。Kubernetes 是由谷歌初始开源的一个项目,它起源于谷歌自己的 Borg 系统,大家都了解谷歌是一家技术出身的公司,Borg 系统或者说 Kubernetes 发布之初的时候给人的印象也是如此——是面向开发者、面向技术人员的,使用起来非常的复杂。谷歌在里面又抽象了很多他自己理解的调度层面的一些概念,用户想要去了解、然后再去使用这个平台需要很长的学习过程。
  同时 Kubernetes 部署安装非常复杂。在两年前你要想搭建一套 Kubernetes 的平台,可能要花一周甚至更长的时间。当然到了现在,由于它越来越得到大家的认可,有很多自动化工具可以帮助你做这件事情,但即使有了这些工具的支撑帮助,去了解这些自动化工具其实也是一个二次学习的成本。
  另外,Kubernetes 专注做的是底层分布式的容器调度平台,它把上游的一些业务场景以及跟底层资源的对接都开放出来,通过各种开源项目和厂商去支持。比如说存储,它通过 CSI 标准,把标准定出来之后,存储厂商可以接进来,网络、容器运行环境也都是如此;包括上游的一些场景,比如 CI/CD、微服务、这些都是通过其他开源项目去支持的。
  所以当企业想要去通过 Kubernetes 完成这种业务场景的交付,那么就要去选型、去选择合适自己的开源项目,这些对企业来说也是很麻烦的一件事情。
  综上可以看出,想使用 k8s 它的隐形成本是很高的,企业需要运维一个专业的团队去负责这个平台,同时 Kubernetes 多租户的模式非常复杂、安全性低,另外它作为通过开源社区支持的一个项目,缺乏本土化支持,这都是在使用 Kubernetes 过程中非常典型的一些问题和挑战。
  所以基于客户的这些痛点,我们开发了我们自己的 k8s 发行版 KubeSphere,我们的 KubeSphere 和原生的 Kubernetes 的区别是什么呢?
  第二部分
  KubeSphere 和原生的 Kubernetes 的区别
  首先来说原生的 k8s 它的安装是非常复杂的,但是我们的 KubeSphere 非常简单,只需要配置两个配置文件,然后就可以一键安装了。
  另外,由于它整个安装过程是需要拉取各种容器镜像的,有些镜像由于网络等原因,拉取起来比较复杂,而 KubeSphere 支持离线安装,在网络环境比较限制的情况下或者说在一些私有云的场景、私有化网络情况下,通过离线安装,你可以很方便地搭建一个 k8s 管理集群。
  原先的 Kubernetes 是没有界面性的东西来辅助工作的,你可以额外使用开源的 Dashboard,但是 Dashboard 提供的功能是比较弱的,体验也不是很好,而 KubeSphere 的界面功能比较强大,大家可以自己去体验一下。
  原先的 Kubernetes 的多租户和权限控制是通过配置文件和命令行去完成的,我们的 KubeSphere 提供了统一的管理入口、多租户的管理方式,可以提供资源和操作级别的权限配置。
  另外,Kubernetes 没有应用管理的概念,它是通过 Helm 去做的,使用命令行可以完成 Helm 应用包的部署、升级、删除的工作。而 KubeSphere 提供了完整的应用生命周期的管理,从应用的开发、发布、版本管控、后面使用的运维,都可以提供一整套的完整的工具。
  另外原生的 Kubernetes 是没有 CI/CD、微服务这些业务场景支持的,在我们的 KubeSphere 里面提供了这些业务场景的支持。
  监控告警,Kubernetes 它的配置是相对比较复杂的,需要基于不同的开源项目去选型。而我们提供了更简便的方式,同时我们也可以做第三方的集成支持,可以把你的监控数据导入到企业现有的监控系统里面。
  然后是存储网络。Kubernetes 存储网络是两大块,有很多开源项目的支持,我们 KubeSphere 也集成了这些主流开源的网络存储的解决方案,同时青云作为一个云厂商,我们也开发并开源了我们自己的存储网络插件去对接青云现在的 SDN 网络、SDS 块存储,可以使用青云的云平台上的硬盘。
  我们还有另外一款分布式存储产品 NeonSAN,它是可以独立部署的,我们也开发了对应的 NeonSAN 的存储插件。另外像云平台上有负载均衡器,我们也开发了负载均衡器插件,如果你把 KubeSphere 部署在青云的云平台之上,那么你可以通过我们的负载均衡器插件,在暴露服务的时候选择负载均衡器的类型,那么你的服务就通过负载均衡器去暴露了。
  简单地概括一下:KubeSphere 是在 Kubernetes 之上构建的企业级分布式多租户容器管理平台。
  它的几大亮点包括:统一门户、实现跨平台管理多种 k8s;学习成本比较低,UI 体验比较好;提供了多场景支持的整体化解决方案;可以很方便地集成第三方的系统;我们提供多租户、更细粒度的权限管理方式;我们除了提供开源的网络和存储解决方案,还有我们自己特色的网络和存储方案。
  这是 KubeSphere 一个简单的架构图,底层可以支持不同的基础设施,如物理机、vmware 虚拟机或者是公有云上的云主机,中间的门户管理多种 k8s 集群,网络和存储我们支持各种存储插件、网络插件,同时我们还有自己的网络和存储插件的支持。
  我们自己作为云厂商有自己的负载均衡器插件,同时我们还提供基于物理交换机的负载均衡器解决方案,这对物理机的部署是非常重要的。
  它的上层提供了几大场景的支持,包括多集群的运维调度、CI/CD、微服务治理、应用生命周期管理。其中应用生命周期管理,我们是基于 OpenPitrix——由我们主导开源的一个项目,大家可以在 GitHub 上搜到,它是实现多云应用管理的一个平台。
  第三部分
  KubeSphere 高级版 1.0.0 的主要功能
  这是 KubeSphere 的全景功能图,大家可以看到这里面体现了刚才提到的几大功能的支持。
  多租户管理
  比如说多租户这一块,从集群层面我们提供了平台管理角色;在集群下面我们提供了多租户的支持,我们叫做企业空间;企业空间底下我们提供了项目,对应 k8s 里面的就是 Namespace;另外基于 CI/CD 的场景,我们有 DevOps 工程层级的资源支持,如果企业想去运行自己的 CI/CD 流水线,可以创建一个 DevOps 工程,然后在里面跑自己的流水线。
  KubeSphere 定义了集群层级、企业空间层级、项目的 DevOps 工程层级,这是三个层级,它绑定的是每个层级资源不同的角色,角色底下关联的是不同的用户。关于多租户,我们接下来会专门有一期线上培训,给大家介绍里面详细的概念和操作。
  从右边这一块能看到,我们支持的 k8s 资源工作负载类型有很多,包括部署、有状态副本集、守护进程集、任务和定时任务。存储这边除了主流的开源存储插件,我们还有 NeonSAN 分布式块存储,以及支持青云的块存储;暴露服务可以通过 Ingress 的方式;配置上我们支持 Secret 和 Configmap。
  DevOps 工程里面我们提供了可视化流水线,我们支持 Jenkinsfile in&out of SCM。这是什么意思呢?其实有很多企业已经用了 Jenkins 这种流水线管理平台了,他们已经有了自己的 Jenkinsfile 去跑自己的流水线,并把 Jenkinsfile 作为他们代码管理的一部分,放在自己的代码仓库里面。
  比如说 OA 项目,我要跑自己的流水线,有一个代码仓库,你把 Jenkinsfile 放在这个代码仓库里面了,我们支持这种方式,那么你在配置流水线的时候,告诉我代码仓库的位置,我会自动地去拉取你已有 Jenkinsfile 里面的内容,去把流水线构建出来并运行。
  如果你之前没有 Jenkinsfile 、,那么通过我们提供的这种可视化流水线构建工具,你可以在页面上简单地去操作、创建自己的流水线。
  同时我们的 DevOps 工程支持凭证管理,可以去帮助你访问各种代码仓库、镜像仓库等等。
  另外在高级版 1.0.0 中我们提供了独立的监控中心,可以提供不同维度的监控功能,比如说我们可以从集群视角去查看各种指标,包括内存、CPU、磁盘、容器组运行情况、网络等等。从应用视角也可以去监控整个业务的运行状况,比如说你的项目里面使用多少资源,你的项目底下的应用使用多少资源,都是可以去查看的。
  总结一下多租户的部分:
  我们现在已经支持了 LDAP 和 AD 的统一认证,同时我们支持 OAuth 的认证集成。
  网络与存储
  除了支持各种主流的网络存储插件,我们也提供了自主可控的网络和存储。特别是在一些关键性业务上,如果你使用一些开源的插件去跑一些关键性业务的话,一旦出了问题,服务、支持都是很头疼的事情。这种自主可控的、可以得到及时支持的网络和存储的方案,对于某些客户还是非常重要的。
  作为我们青云平台的企业用户,在网络上您可以使用我们提供的开源的 hostnic 网络方案,pod 上直接绑定青云 SDN 的网卡,可以实现网卡的直通。
  然后我们还提供基于物理交换机的负载均衡器解决方案,且不绑定设备,比如说你可以自己采购华三的交换机,通过物理交换器达到负载均衡器暴露服务的场景支持。
  我们自己的 CSI 存储插件可以直接挂载青云的 SDS 块存储,我们也开发了 QingStor CSI 的插件,这个 pod 可以直接挂载 NeonSAN 的块存储。
  CI/CD on KubeSphere
  基于 CI/CD 我们可以实现容器的标准化交付物,快速构建、升级、回滚应用环境,提供完整的自动化工具的链条,降低运维成本,同时 CI/CD 为微服务场景提供了强有力的支持。比如说把一些业务拆分放在不同的容器里面去,然后再通过 CI/CD 构建整个的开发、测试和部署的链条,实现快速发布,降低管理成本。
  我们现在发布的是 1.0.0,刚才也提到 Jenkinsfile In and out 和 Source Code Management 两种方式,我们即将发布的 2.0.0 版本会支持 source to image,代码到镜像的构建,还支持代码安全扫描。
  集群运维
  我们在项目这个层级提供配额管理,比如这个项目底下你可以去使用多少 CPU、多少内存、可以创建多少个部署、多少个服务,这些都可以通过配额去配置。在工作负载上除了支持 k8s 原生之外我们还支持 HPA,即 pod 的自动弹性伸缩,你可以设置自己的CPU指标,pod 的下限和上限,当指标达到、超过的时候,pod 会自动的扩容。
  应用的生命周期管理
  这个是通过我们自己开源的一个项目 OpenPitrix 做的,OpenPitrix 是多云应用的全生命周期管理,支持不同的云厂商,如阿里云、AWS 等,k8s 也是 OpenPitrix 支持的运行平台。
  它底层是基于 Helm 去做的,也就是说 OpenPitrix 是去调用 Helm 的 API,在应用层实现包的管理。但是 OpenPitrix 比 Helm 能做的事情更多,因为 Helm 其实就是简单地实现应用打包,然后部署、版本管控、升级这些功能,但是其实应用管理、生命周期管理是非常复杂的场景,它不单单是 Helm 考虑到的那些东西,它还包括了不同角色人员的需求,还有不同场景的支持。
  比如说我作为一个应用开发者,我怎么去开发自己的应用、怎么发布、版本管控,以及应用发布之后,我的计费计量、用户使用的情况是什么样的?它碰到的各种问题怎么通过我的平台去获取支持?这都是整个应用生命周期管理里面各种场景的诉求,这个在 Helm 是没有的。而 OpenPitrix 提供了整个应用生命周期管理的功能。
  这里简单画了一个 KubeSphere 和 OpenPitrix 怎么做集成支持的场景介绍。比如说我是一个应用开发者,我开发一个应用,那么我可以通过 OpenPitrix 把我的应用打包上传,上传之后发布应用,再通过我的 KubeSphere 的 CI/CD 流水线跑一些测试,都通过之后把它发布,发布之后我就可以在我的应用仓库里面看到这个应用了。作为一个应用的消费者、使用者,他可以在应用仓库的界面里面看到并使用这个应用。
  这个是 KubeSphere 高级版的产品路线图。高级版 1.0.0 里面我们提供的是多租户、监控和 CI/CD,高级版 2.0 的时候我们会提供微服务治理、日志、告警的支持。
  2019 年,我们会在公有云上线我们自己的 QingCloud Kubernetes Service,提供容器超融合一体机。我们的 AppCenter 里提供了各种 PaaS 和 SaaS 的应用,我们会把线上比较关键性的 PaaS 应用容器化,放到 KubeSphere 的内置应用仓库里,同时我们在明年还会支持 GPU 和 arm 的架构,可以支持大数据深度学习的场景。
  最后,这是 KubeSphere 产品从开发至今累计的开源项目的地址,第一个就是 KubeSphere 这个项目的地址,然后是文档的项目,大家使用时碰到的各种问题、各种需求都可以在这上面告诉我们,我们会及时去解答。
  比如说我刚才讲到的我们自己对接云平台的各种插件,像负载均衡器插件、网卡插件、存储插件,还有我刚才提到的多云的应用管理平台 OpenPitrix,我们都在 Github 上开源。
  另外我们提供了两个在线网站,KubeSphere.io 和 KubeSphere.qingcloud.com ,大家可以在这些地址上获取想了解的信息。
  KubeSphere 系列培训课程(二)——如何通过 KubeSphere 玩转 Kubernetes 存储,将在 1 月 23 日 20:00 准时开讲,欢迎扫码订阅??
 
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

专题

CTI论坛会员企业