东方通讯基于 KubeSphere 的云计算落地经验

作者：周峰 吴昌泰
公司简介

东方通讯股份有限公司（以下简称“东方通讯”）创立于 1958 年，是一家集硬件设备、软件、服务为一体的团体解决方案提供商。公司于 1996 年成功改制上市，成为上海证交所同时发行 A 股和 B 股的国有控股上市公司。公司业务紧张包括：专网通讯及信息安全产品息争决方案、公网通讯相关产品及 ICT 服务、金融电子设备及软件产品、智能制造业务。
十四五期间，公司主责主业聚焦在以专网通讯、公网通讯、ICT 服务为底子的“信息通讯财产”，金融电子为底子的“金融科技财产”和“智能制造财产”三大财产，围绕主责主业不停创新与转型升级。 负担“科技创造价值，共筑美好生活”的使命，东方通讯对峙“诚信、务实、创新、共赢”的理念，致力于为客户提供优质的产品、便利的体验、完美的方案和满足的服务，努力成为在国际市场中拥有上风品牌、持续创新和发展的领先企业！
技术近况

• 在使用 KubeSphere 之前，公司已经开始研究云原生和探索应用上云的道路。但是由于每个团队接触和学习云原生技术的时间不同，原生 Kubernetes 的使用还是存在一定的门槛。并且随着公司云的底子办法和使用团队的的增加，也提高了云平台团队对云的管理难度。
  
• 项目的交付方式还是传统的瀑布式开发模式，没有高效的流程，不同的情况下需要对应的开发或运维职员手动摆设，增大出现差别性和错误的几率。
  

团队规模

公司拥有国家级企业技术中央和博士后工作站，承担着多项国家重点研发项目，并多次荣获国家科技进步奖，现有员工 2500 余名，此中 75% 以上为技术专业人才。
配景先容

近几年，云原生技术已经不再是一个新鲜词汇，根据权势巨子 IT 研究公司 Gartner 推测，到 2025 年，云原生平台将成为 95%以上的新数字化筹划的底子，而在 2021 年这一比例只有不到 40%。云原生技术在效率上的巨大上风，使其渐渐成为 IT 发展的主流趋势。
针对用户在业务上提出的一些需求，云原生技术可以或许为我们提供更多的选择。以我司最近的一个项目为例，用户要求为每条业务线路提供主备实例，同时还需要提供容灾备份。在传统摆设方式下，需要采购的服务器数目是业务线路数目的 4 倍。但是使用云原生技术，通过容器的方式来实现业务线路之间的隔离，可以大大低沉底子办法摆设的成本，使用 Kubernetes 作为编排引擎，以声明式脚本的方式摆设业务，规范并简化了摆设流程，提高了可重复性和同等性。
上面举例中提到的只是云原生技术带来的此中一部分改变，随着业务更加深入的进行云化改造，还可以在业务的弹性和高可用，灵敏开发等方面带来更多的价值。
选型说明

工具选型的过程

公司与 KubeSphere 的相遇始于针对 Kubernetes 的 Dashboard 的选型。在使用 KubeSphere 之前，我们也研究和试用了很多其他的项目，比如 Kubernetes 官方的 Dashboard 和其他市场同范例产品。Kubernetes 官方的 Dashboard 的功能比力单一，只是提供了对集群资源的管理，市场同范例产品固然功能更丰富，但还是无法完全满足我们的需求。
选择 KubeSphere 的缘故原由

终极选择 KubeSphere 的缘故原由有以下几点：

• 首先，KubeSphere 不但仅只是单纯的 Dashboard ，除了针对 Kubernetes 资源管理之外，还提供了统一的集群管理、包罗日志、审计、监控在内的强大的可观测性等很多附加功能。同时提供可插拔组件的摆设方式，既满足了功能多样性，又满足了摆设的机动性需求。
  
• 其次，KubeSphere 很好的集成了 DevOps 自动化流程，而 DevOps 自动化流程是提高软件交付速度、保障质量和可靠性的最佳实践方法。
  
• 最后，我们看重的是 KubeSphere 活泼的开源社区。最为一款开源产品，一个布满活力的开放性开源社区，才能提供充分的能力和技术知识支持，让大家能共享开源模式所带来的红利。
  

实践过程

底子办法与摆设架构

在使用 KubeSphere 的过程中，我们首先是借助 KubeSphere 提供的多集群和多租户功能对现有的集群资源和云上的构造团体架构做了调解，下图所示是我们现在基于 KubeSphere 的东信云构造架构。

使用多集群管理功能，对现有的集群资源进行了统一管理。既实现了隔离不同情况，又实现了跨集群的统一管理。通过统一的控制平面，将应用步调及其副本分发到不同集群，实现了集中监控、日志系统、事件和审计日志。
其次，借助多租户管理功能，为不同的事业部创建各自的企业空间（WorkSpace），在企业空间中控制资源访问权限。每个企业空间下按开发、测试、运维小组划分为不同的部分，同时为每个项目创建项目空间（NameSpace）。部分作为权限管理的逻辑单位，通过设置项目角色使部分拥有项目的对应权限，再将用户分配至部分后，简化对新参加成员的权限分配过程。
引入 DevOps 工作流，使用 S2I、B2I 实现镜像的快速交付，借助 Jenkins 流水线实现 CI/CD，帮助团队实现软件的快速、安全、可靠地交付。
借助 KubeSphere 的应用商店功能来管理应用步调的整个生命周期（提交、考核、测试、发布、升级和下架），同时我们还摆设了 Harbor 来管理容器镜像。
存储实现方案

为了解决长期化存储的题目，接纳基于 nfs-subdir-external-provisioner 的 storageclass 作为存储类，同时对不方便进行改造的业务支持使用本地存储。由用户创建业务 Pod 和 PVC 来申请使用一定量的存储资源，集群管理员管理存储类和 PV，假如使用的是 NFS 范例的存储，由 nfs-subdir-external-provisioner 根据 PVC 申请的存储大小自动创建 PV，假如使用的是本地存储，则由管理员负责手动创建 PV。

日志和监控方案

为了实现日志文件长期化存储，从容器中读取日志可读，且重启和掉电不丢。接纳 EFK（Elasticsearch + Fluentd + Kibana）的日志网络和分析方案来帮助有效的管理和分析大规模日志数据。日志网络目标包括：Docker 组件日志、业务容器日志、管理面组件日志。Elasticsearch 组件目前是直接使用 KubeSphere 内置的 ES，后期为了提升性能，思量接入外部的 Elasticsearch。

引入 Prometheus 服务作为监控中央，定时采集业务容器、控制面组件以及物理服务器三个层面的指标数据，通过 KubeSphere 界面或 Grafana 的界面展示详细信息。使用采集到的各种指标来判断业务或集群是否正常，针对非常可通过 Prometheus 的 AlarmManage 告警功能进行信息的转发，将告警信息同步到网管（内部管理平台）或通过邮箱、短信、钉钉等方式通知到运维职员。

多租户管理

这里我们想重点分享一下我们针对 KubeSphere 的多租户结构的分析，KubeSphere 在 Kubernetes 的 RBAC 和定名空间提供的基本的逻辑隔离能力底子上，增加了企业空间提供了跨集群、跨项目（即 Kubernetes 中的定名空间）共享资源的能力和权限控制。下面的分析都是基于我们公司使用的 KubeSphere V3.3.0 版本展开。

多租户元素资源范例泉源用户users.iam.kubesphere.ioKubeSphere crds平台角色globalroles.iam.kubesphere.ioKubeSphere crds平台角色绑定globalrolebindings.iam.kubesphere.ioKubeSphere crds企业空间workspaces.tenant.kubesphere.ioKubeSphere crdsworkspacesTemplate.tenant.kubesphere.ioKubeSphere crds企业空间角色workspaceroles.iam.kubesphere.ioKubeSphere crds企业空间角色绑定workspacerolebindings.iam.kubesphere.ioKubeSphere crds项目namespaceK8s 自带项目角色rolesK8s 自带项目角色绑定rolebindingsK8s 自带

• 用户 Users
  

用户是 KubeSphere 的帐户实例，是登陆 KubeSphere 控制台的实体账号，在 KubeSphere 中使用 users.iam.kubesphere.io 资源对用户进行抽象。

用户信息中保存了用户名、暗码、最后登陆时间等信息。

• 平台角色 globalroles
  

在 KubeSphere 中平台角色使用 globalroles.iam.kubesphere.io 资源抽象。安装成功后，会预创建 4 个内置的平台角色，每个平台角色现实又关联着一个或多个平台模板角色（平台角色的权限是关联模板角色权限的集合）。
内置角色描述workspaces-manager企业空间管理员，管理平台所有企业空间。users-manager用户管理员，管理平台所有效户。platform-regular平台普通用户，在被邀请参加企业空间或集群之前没有任何资源操作权限。platform-admin平台管理员，可以管理平台内的所有资源。

以 users-manager 角色为例子，其关联了用户检察、角色检察、用户管理、角色管理四个模板角色，这让 users-manager 角色拥有了这四个角色模板下所对应的资源访问权限。

• 平台角色绑定 globalrolebindings
  

创建用户后，需要为用户分配一个平台角色，使用 globalrolebindings.iam.kubesphere.io资源来抽象用户和平台角色的绑定关系。

在创建一个新的平台角色时，需要编辑权限，此时就是为新创建的平台角色关联预创建的角色模板。

• 企业空间 WorkSpace
  

企业空间是 KubeSphere 中用来管理项目、DevOps 项目、应用模板和应用仓库的一种逻辑单位。可以在企业空间中控制资源访问权限，也可以安全地在团队内部分享资源。在 KubeSphere 中使用 workspaces.tenant.kubesphere.io 和 workspacesTemplate.tenant.kubesphere.io 资源对企业空间进行抽象。

• 企业空间角色 workspaceroles
  

在 KubeSphere 中企业空间角色使用 workspaceroles.iam.kubesphere.io 资源抽象。安装成功后，会预创建 4 个内置的企业空间角色，每个企业空间角色现实又关联着一个或多个企业空间模板角色（企业空间角色的权限是关联企业空间模板角色权限的集合）。
名称描述workspace-viewer企业空间观察员，可以检察企业空间中所有资源。workspace-self-provisioner企业空间普通成员，可以检察企业设置、管理应用模板、创建项目和 DevOps 项目。workspace-regular企业空间普通成员，可以检察企业空间设置。workspace-admin企业空间管理员，可以管理企业空间中的所有资源。

以 system-workspace-viewer 为例子，其关联了业空间设置检察、角色检察、成员检察、部分检察、项目检察、DevOps 项目检察、应用模板检察、应用仓库检察八个模板角色。

• 企业空间角色绑定 workspacerolebindings
  

在企业空间中，可以在企业空间成员处邀请用户参加企业空间，邀请用户参加时，还需要为其分配企业空间角色，使用 workspacerolebindings.iam.kubesphere.io 资源来抽象用户和企业空间角色的绑定关系。

此处以企业空间的默认管理员角色为例（管理员的角色绑定是在创建企业空间时选择管理员时绑定）。

• 项目 NameSpace
  

KubeSphere 中项目就是 K8s 中的定名空间，使用的就是 NameSpace 资源来抽象项目，企业空间和项目的关系是一对多，即一个企业空间下，可以创建多个项目。K8s 的默认定名空间和 KubeSphere 系统相关的定名空间，都归属于默认企业空间 system-workspace。

下面在前面创建的 demo-ws 企业空间下创建一个新的项目 demo-ws-project-01。

• 项目角色 roles
  

在 KubeSphere 中项目角色对应的就是 K8s 自带的 roles 资源。但是通过 KubeSphere 创建新项目时，会自动创建 3 个内置的项目角色，每个项目角色现实又关联着一个或多个项目模板角色（项目角色的权限是关联项目模板角色权限的集合）。
内置角色描述viewer项目观察者，可以检察项目下所有的资源。operator项目维护者，可以管理项目下除用户和角色之外的资源。admin项目管理员，可以对项目下的所有资源执行所有操作。此角色可以完全控制项目下的所有资源。 下图展示的是 demo-ws-project-01 项目下的项目角色，如需检察其他项目下的角色，需要带-n参数指定项目名（定名空间）。

以 viewer 角色为例，关联了如下的项目模板角色。

• 项目角色绑定 rolebindings
  

在项目下，可以在项目成员处邀请用户参加项目，邀请用户参加时，还需要为其分配项目角色，此时使用的就是 K8s 自带的 rolebindings 资源。
以 demo-ws-project-01 项目下绑定关系为例。

从下图可以看到，admin 用户绑定了该项目下的 admin 角色。

使用效果

对比使用 KubeSphere 之前，在针对 Kubernetes 集群的管理和使用上，我们有以下几点感受：

• 在使用了 KubeSphere 之后，原有的分散管理的多个集群在逻辑上组成了一个大一统情况，集群管理的很多操作不需要再分别连接到不同集群上去操作，对多个集群的状态监控也可以或许在统一的入口获取，极大的提高了管理的效率。
  
• 项目交付和摆设更加的规范，减少了因情况和不同职员操作而大概产生的差别性，特别是应用商城让应用如同货架上的商品一样唾手可得，应用的摆设也只需要很少的修改后即可一键安装。
  
• 友好的用户界面和可视化的操作方式，低沉了公司其他团队使用云的门槛，让即使是刚接触云原生的团队，也能很快的上手。
  

未来规划

未来我们筹划探索和使用更多 KubeSphere 的组件功能，如审计日志、服务网格等。针对东信团队的内部需求，对 KubeSphere 的源码进行二次开发，并夺取可以或许回馈社区。积极参与社区活动，与社区进行更加深入的交换。
同时，对于 KubeSphere，我们也有一些建议：

• KubeSphere 页面上能提供的监控数据只有 CPU 内存这些基本数据，日志检索功能也不是特别方便，我们现在是通过手动跳转到 Grafana 和 Kibana 页面使用，希望未来能有更好用的日志和监控功能。
  
• 目前官方提供的使用文档相对简单，有些功能只是大略带过，希望能细化文档，最好是出一些视频类的使用教程。
  
• 源码中的注解信息比力少，增加了源码解读的难度，也希望官方能推出一些指导源码解读的文档。
  

   本文由博客一文多发平台 OpenWrite 发布！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。