应用工作台技术概览¶

目标¶

• 对应用工作台架构有个整体认识
• 说明包含组件及集成方式
• 示例及引导文档

系统组件¶

amamba-system 主要包含以下三个组件

• apiserver：所有服务的入口，无状态的，提供 gRPC 和 REST 两种方式访问，通过 REST 或 gRPC 调用 Providers 的服务，或者通过 kube-client 或者 kpanda 创建资源与 Controllers 交互
• devops-server：主要与 Jenkins 通信，并向 apiserver 提供相关接口以支持懒加载，基于事件的同步等功能
• syncer：主要负责维护 Providers 和 Controllers 的数据与系统的保持一致，确保系统的配置能正确地下发到各个组件当中

CI¶

Jenkins¶

Amamba Jenkins 基于 kubernetes 插件增强，相比于原生的 Jenkins 我们提供了以下优势：

1. 完整的云原生解决方案

   相比于传统的 VM 部署，云原生有着弹性和可伸缩性、高可用和灵活等优点，我们提供了整套的 Jenkins 云原生方案， 包括在 Kubernetes 中运行、构建镜像和制品、发布、和其他工具链集成、DR 等；

2. 优化的读取速度

   我们提供了基于关系型数据库的缓存，流水线及运行相关的数据都存储在 DB 里，并通过事件机制保证数据及时更新。

3. 一次创建，多处运行

   得益于 DB，Jenkins 的部署位置和持久化不再重要，我们时刻可以接入另一套集群中部署的 Jenkins，并在上面运行之前创建的流水线；

4. 更低的门槛

   Jenkinsfile 强大但有着比较高的理解和使用门槛，我们提供了图形化界面以拖拉拽的方式帮助用户创建和编辑流水线，帮助用户更快地上手；

5. 多租户

   基于 DCE5 的 Workspace 机制，我们对流水线和凭证做了隔离；

此外，目前应用工作台也有着以下问题：

1. 启动慢

   相比于传统的使用注册节点的 Agent，在基于 Kubernetes 的 Jenkins 上运行流水线需要创建 Pod、等待调度和拉取镜像，这一过程导致启动的速度相对来说要更慢。

2. 缓存

   由于 Pod 的沙箱环境，使得缓存无法被有效利用，我们可以为其挂载持久化存储，但这几乎总是意味着额外的规划和管理成本；

3. 插件

   安装插件依然需要到 Jenkins 的管理界面上操作和配置，并且当迁移到其他集群上时会丢失。 我们建议通过 fork amamba-io/jenkins-agent 并修改 formula.yaml后重新构建的方式，将插件持久化到镜像中；

4. Noisy Neighbour

   我们没有对流水线做资源的配额和限制，因为我们认为 CI 和部署的资源不应该放在一起考虑， 而是依赖于管理员对 CI 系统的前期规划，但这可能导致部分流水线抢占所有资源；

5. 构建镜像慢

   除了前面说的缓存无法被有效利用的原因外，当 Kubernetes 的运行时不是 Dockerd 时，我们只能使用类似 dind 或 pind 的方式来构建镜像， 这种在容器里面运行容器的方式会导致一部分 IO 性能损失；

基于此，我们也在计划支持使用传统方式部署的 Jenkins。

整体架构¶

• 利用 Generic Event 插件提供的事件机制， 我们可以及时地更新流水线的运行情况。为了避免不同网络环境带来的事件丢失的干扰， 我们以 sidecar 的方式部署了 event-proxy，这一组件提供更强的网络流量控制能力和可靠的事件系统。 当然，对于 Amamba 来说它是完全透明的，如果网络环境可控，可以不部署它；
• 为了保证 apiserver 是完全无状态可伸缩的，我们使用 devops-server 来处理状态相关的服务——包括接收 Jenkins 的事件、同步流水线状态、运行数据的懒加载、暴露 Jenkins 事件指标等，并提供了 SDK 给 apiserver 调用；
• 由于 Jenkins 的实例可能运行在任一集群上，syncer 帮助我们将其中系统的部分同步到不同实例里去，包括：
  • 我们的凭证统一使用secret管理，syncer会将其中流水线的部分同步到 Jenkins 中；
  • Jenkins 的配置基于 CasC 生效， 我们会在系统中保留变更的部分，并使用syncer 同步到子集群里面；
• 流水线实际在 Pod 里被执行，通过 jnlp 容器与 Jenkins 通信，这种架构使得即使 Jenkins 挂掉了大部分任务也能继续运行。

更多资源¶

• 更可靠的用法：
  • HA: Jenkins 高可用方案 - DaoCloud Enterprise
  • 配置和规划：Jenkins 场景配置 - DaoCloud Enterprise
• 扩展：
  • 自定义工具：在 Jenkins 中使用自定义工具链 - DaoCloud Enterprise
  • 复用流水线：自定义模板 - DaoCloud Enterprise
  • 自定义 Agent：自定义 Jenkins Agent 镜像 - DaoCloud Enterprise （ 缺少 kubernentes 类型 agent 的定义方式 ）
  • 自定义步骤：WIP
• 加速（WIP，缺一个系统的文档）；
  • 在指定的节点上运行流水线 - DaoCloud Enterprise
  • 在流水线中使用缓存 - DaoCloud Enterprise
• 集成：
  • SornaQube：使用流水线实现代码扫描 - DaoCloud Enterprise
  • 使用集成的 Gitlab：WIP（基本原理，如何使用）
• 实践：
  • 基于 Git 仓构建微服务应用 - DaoCloud Enterprise
  • 基于 Jar 包构建 Java 应用 - DaoCloud Enterprise
  • 结合 ArgoCD 使用：流水线 + GitOps 实现 CI/CD - DaoCloud Enterprise
  • 构建多架构镜像（WIP 有误）：构建多架构镜像 - DaoCloud Enterprise

CD¶

Argo CD¶

Amamba 使用 Argo CD 作为引擎实现 GitOps 的能力，相比原生的 Argo CD，我们主要在和 DCE 5.0 的集成上做了增强：

1. 应用按照租户的粒度隔离，只能部署到对应的集群和命名空间下；
2. 权限按照全局 RBAC 的策略控制，只有对应权限点的用户才能执行对应操作；

问题：

1. 代码仓库没有做租户隔离：这是 Argo CD 的设计缺陷，我们已经在积极推动社区优化： argoproj/argo-cd #18290
2. 暂不支持 ApplicationSet；

整体架构¶

• 我们通过 Argo 提供的 SDK 访问argo-server，使用 AppProject - Wrokspace 一一映射的方式来为用户创建和更新相应的资源；
• syncer 会一直 watch 系统中租户的变化并将变化应用到 Argo 的资源中；

更多资源¶

• 更可靠地使用:
  • HA：Argo-CD 高可用部署 - DaoCloud Enterprise
  • 在 GitOps 中启用凭证加密功能 - DaoCloud Enterprise
• 多环境推进（Promote）部署（WIP）；
• How to Model Your GitOps Environments 提供了基于 kustomization 在多个环境间 Promote 的思路；
• GitHub - cloudogu/gitops-patterns: Collection of patterns, examples and resources for GitOps process design, GitOps repository structures, etc 总结了一些常见的 GitOps 的模式选择及利弊；

Argo Rollouts¶

Amamba 基于 Argo Rollouts 提供渐进式发布的能力，相比于原生的 Argo Rollouts，我们主要在以下方面做了增强：

1. 更加易于使用，提供了 Step By Step 的界面来将当前集群中的工作负载转换成Rollout 开始灰度发布；
2. 支持跨集群创建和管理；
3. 与 Mspider（使用 istio 作为流量控制工具时）和 skoala（使用 contour 时）有更好的集成；

问题：

1. 现在 Mspider 的托管网格模式下，子集群部署的虚拟服务（VirtualService）和目标规则（DesinationRule）不会生效， 这导致无法再这种场景下使用基于 Istio 的 Rollout，Mspider 已经在优化，预计在 v0.26 版本里支持；
2. 基于 Deployment 创建 Rollout 会导致暂时的访问失败，社区已经在着手修复这个问题 argoproj/argo-rollouts #3111，预计将在 v1.7 版本里解决；

更多资源¶

• 基于 Argo Rollout 实现灰度发布 - DaoCloud Enterprise
• 基于 Contour 的灰度发布 - DaoCloud Enterprise

应用¶

我们支持原生应用、Helm 应用、OAM 应用和 OLM 应用。

原生应用¶

原生应用即 Kubernetes 原生的工作负载类型的资源，例如 Deployment，StatefulSet 和 DaemonSet。 我们没有增加任何的心智负担，但为了将相关资源关联起来，我们使用 kubernetes-sigs/application 来说明当前应用包含的资源类型和标签。

这个 CRD 对应的 Controller 是可选安装的，需要在每个子集群手动安装，不部署并不会导致资源创建失败， 但是部署后能够不断同步资源状态，返回资源的就绪情况。

OAM 应用¶

OAM 应用基于 kubevela 实现，我们主要在多租户方面做了增强：

1. 在当前租户下首次创建 OAM 应用时会提示需要创建或指定一个命名空间作为该 Workspace 下的所有 applications.core.oam.dev 放置的位置，以此实现不同租户下应用的隔离；
2. syncer会一直 watch 系统中租户的变化并将变化应用到 KubeVela 的资源中；

Helm 应用和 OLM 应用¶

OLM 应用和 Helm 应用主要基于 Kpanda 的相应能力封装。

版本信息¶

Amamba 的所有 Addon 从 v0.21（对应安装器 v0.12）开始，都可以在应用商店以 Helm 的方式部署， 没有版本限制。但是默认版本经过了完整的测试，可以更好地集成到当前系统中，下表是 Addon 和 Amamba 的版本关系：

评论