关于云计算:基于-KubeSphere-的运管系统落地实践

作者：任建伟，某出名互联网公司云原生工程师，容器技术信徒，云原生畛域的实践者。

背景介绍

在接触容器化之前，咱们团队外部的利用始终都是基于虚拟机运管，由开发人员自行保护。

因为面向多开发部门服务，而开发人员运维能力参差不齐，所以每次部署新的环境时往往都要消耗大量工夫。

针对部署难的问题，咱们将局部组件、服务容器化，采纳 Docker 公布治理解决了局部问题，但仍未升高对开发人员的运维技能要求。

上面是咱们基于虚拟机治理开发环境的流程：

从上图中咱们也能发现以后架构存在的问题：

• 下发虚机由各部开发人员治理，虚机平安问题难以保护、保障；
• 基于 shell 运维，专业性过强；
• 基于手动打包、公布，耗时耗力且不牢靠。

选型阐明

针对上述提到的痛点，咱们决定对运维架构进行革新。新建运管平台，技术选型整体基于云原生，优先选取 CNCF 我的项目。

Kubernetes 成为了咱们平台底座的不二抉择，但 Kubernetes 原生的 Dashboard 不太满足理论应用需要。

而从头开发一套 workbench 又耗时耗力，由此咱们眼光转向了开源社区。

此时，一个集颜值 + 弱小性能于一身的开源我的项目进入咱们视线。是的，它便是 KubeSphere。

而 KubeSphere 愿景是打造一个以 Kubernetes 为内核的云原生分布式操作系统，它的架构能够十分不便地使第三方利用与云原生生态组件进行即插即用（plug-and-play）的集成，反对云原生利用在多云与多集群的对立散发和运维治理。

对于 KubeSphere 是否作为部署平台，最终论断如下：

KubeSphere 虽功能强大，但更适宜作为治理端应用，不太适宜面向普通用户。

咱们须要本地化一套 workbench，简化局部性能，屏蔽专业性术语（如工作负载、容器组、平安上下文等）。

本地化局部内容如下：

• 基于企业空间、命名空间，本地化租户、工作空间的概念，一个租户（企业空间）可治理一个到多个工作空间（命名空间），并接入独立用户体系。
• 本地化利用公布流程：由拆分的利用公布流程（构建镜像 + 创立负载），本地化为：创立利用 -> 上传 jar -> 指定配置 -> 启动运行的串行流程。
• 本地化链路监控：构建镜像事后埋点，创立利用时抉择是否开启链路追踪。
• 本地化配置、利用路由等，增加版本治理性能。

事实上，咱们本地化的重点是利用治理，然而 KubeSphere 性能过于弱小、个性过于灵便，导致配置起来项过于繁琐。

针对局部配置项咱们采纳设置默认值的形式，而非交由用户去配置。（比方：容器平安上下文、同步主机工夫、镜像拉取策略、更新策略、调度策略等）

革新后的运维架构如下：

实际过程

基于 KubeSphere 的运管平台整体架构如下：

环境信息表：

本地化部署流程如下：

镜像本地化

1️⃣ 基于 harbor 搭建公有镜像库。

2️⃣ 离线下载并上传 kubesphere 依赖镜像至公有 harbor 内，project 名称放弃不变。

3️⃣ 本地化 B2I 根底镜像，本地化如下内容：

• 内置 Arthas，便于调试；
• 内置 SkyWalking Agent 用于集成链路追踪；
• 内置 Prometheus Agent 用于指标监控；
• 增加 windows 字体。

4️⃣ 本地化利用商店初始化镜像（openpitrix/release-app）。

因为预置的 chart 有很多咱们理论并未应用，所以咱们删除预置了 chart，并导入理论所需 chart（包含本地化的中间件 chart、中台 chart）

5️⃣ 镜像 GC。

针对频繁构建的 repo，配置正当的 GC 策略：

搭建 K8s

基于 KubeKey 1.0.1 部署了三主多从节点 K8s v1.18.6 集群：

搭建 Rook 集群

应用 KubeKey 1.0.1 新增三个存储节点并打上污点标签，搭建 Rook 集群

对于存储的替换次要出于以下方面思考：

• 有 Ceph 裸机部署应用教训；
• 比照默认存储 OpenEBS Local PV，Rook 反对多存储类型；
• Rook 为 CNCF 毕业我的项目。

搭建 KubeSphere 平台

基于 KubeKey 1.0.1 部署了 KubeSphere，未作本地化批改。

CI/CD 实际

CI/CD 局部咱们并没有应用 KubeSphere 提供的流水线性能，而是抉择 gitlab-runner + ArgoCD 计划。

CI 实现

CI 局部利用 gitlab-ci 切换构建时个性，咱们形象出了 provider 概念。provider 实质为工具 / 程序的容器化封装，提供某一方面能力了。如：

• maven-provider: java 程序构建时环境，内置公有 nexus 配置；
• npm-provider: nodejs 程序构建时环境，内置公有 npm 源配置；
• email-provider: smtp 交互程序，用于邮件告诉；
• chrome-headless-provider: 浏览器截屏。

应用时，只需援用并传递相应参数即可：

variables:
  AAA: xxx
  BBB: yyy

stages:
  - build
  - scan
  - email

build:
  stage: build
  image: harbor.devops.io/devops/maven-provider
  tags:
    - k8s-runner
  script:
    - mvn clean package
  only:
    refs:
     - develop
    changes:
      - src/**/*

scan:
  stage: scan
  image: harbor.devops.io/devops/sonar-provider
  tags:
    - k8s-runner
  script: xxx
rules:
    - if: '$CI_PIPELINE_SOURCE =="schedule"'

email:
  stage: email
  image: harbor.devops.io/devops/sendmail
  tags:
    - k8s-runner
  script:
    - /work/send-mail sonar --email-to=$EMAIL_TO_LIST --email-cc=$EMAIL_CC_LIST --sonar-project-id=$PROJECT_NAME --sonar-internal-url=$SONAR_INTERNAL_ADDR --sonar-external-url=$SONAR_EXTERNAL_ADDR
  rules:
    - if: '$CI_PIPELINE_SOURCE =="schedule"'

CD 实现

CD 局部，咱们利用 chart 对利用进行定义，并将 chart 剥离于开发库，独立于配置库进行治理，用于 ArgroCD 同步。

对于配置库与开发库拆散，次要出于以下思考：

• 清晰拆散了利用程序代码与应用程序配置。
• 更清洁的审计日志：出于审计目标，只保留配置库历史更改记录，而不是掺有日常开发提交的日志记录。
• 拜访的拆散：开发应用程序的开发人员不肯定是可能 / 应该推送到生产环境的同一个人，无论是无意的还是无心的。
  通过应用独自的库，能够将提交拜访权限授予源代码库，而不是应用程序配置库。
• 自动化 CI Pipeline 场景下，将清单更改推送到同一个 Git 存储库可能会触发构建作业和 Git 提交触发器的有限循环。
  应用一个独自的 repo 来推送配置更改，能够避免这种状况产生。

角色划分

角色方面，咱们定义了三种类型角色，职责如下：

应用成果

通过引入 KubeSphere 平台以及 CI/CD，效率晋升显著：

• 计算资源池化，不再下发虚机，计算资源对立运管；
• 基于容器化的流水线构建、公布利用，保障了构建的可靠性，同时解放双手；
• 基于本地化 workbench 运维，因为屏蔽了专业性词汇术语，升高使用者学习老本。日志查看、利用更新等操作更为便捷；
• 针对角色的划分，使得运维边界清晰，责任明确。

问题 & 解决

在一年多的容器平台应用过程中，咱们遇到了蛮多的小问题，这里我举几个有代表性的例子：

B2I 没有清理策略

存在问题：

在应用 kubesphere v3.0 的过程中咱们发现：一直通过 B2I 构建利用，会产生大量的 B2I 工作记录，并且 minio 内上传的程序包文件越来越多，且并没有相应的清理策略。

解决方案：

开发定时 job , 定期进行清理。

内核版本过低，导致容器相干破绽的产生

存在问题：

初期，咱们应用 CentOS7 默认的 3.10 版本内核。

解决方案：

降级内核版本至 5.x。

链路追踪

存在问题：

KubeSphere 预装的 jaeger 不反对 dubbo 协定，无奈对 dubbo 利用进行监控。

解决方案：

利用 SkyWalking 用于链路追踪，并在根底镜像内埋点。

报表相干服务短少字体

解决方案：

将短少 windows 字体装置至 B2I 根底镜像内。

5. 路由集群外服务

因为局部利用部署于 K8s 内部，针对这部分利用咱们抉择 Endpoint + ExternalName + Ingress 的形式进行路由。

将来布局或瞻望

1️⃣ 有状态利用的 Operator 开发

以后有状态利用依赖 helm hook 治理，且性能繁多。
将来咱们打算，针对罕用有状态利用，开发对应 operator，提供创立、扩容、备份等罕用性能。

2️⃣ CNI 迁徙至 Cilium

选取 Cilium 替换 Calico 次要出于以下思考 :

• Cilium 为 CNCF 毕业我的项目，活跃度高；
• Cilium 基于 eBPF 实现，在粒度和效率上实现了对系统和应用程序的可观测性和管制；

• Cilium 平安防护性能更强，提供了过滤单个利用协定申请的能力，例如 :

  • 容许所有应用 GET 办法和 /public/.* 门路的 HTTP 申请，回绝所有其余申请；
  • 容许 service1 在 Kafka 主题 topic1 上生产，容许 service2 在 topic1 上生产，回绝所有其余 Kafka 音讯；
  • 要求 HTTP 报头 X-Token:[0-9]+ 呈现在所有 REST 调用中。

3️⃣ cri 由 Docker 替换为 Containerd

4️⃣ 容器文件浏览器性能开发

以后阶段，开发人员下载容器内文件的需要，只能由运维人员应用 kubectl cp 的形式帮助获取，后续咱们布局开发容器文件浏览器相应性能。

5️⃣ 容器宿主机零碎替换为 rocky，以应答 CentOS 进行保护。

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