argo-rollouts
argoproj • Updated Dec 1, 2023

Why
argo-rollouts
argoproj • Updated Dec 1, 2023
?

Kubernetes部署提供了rolllingupdate策略，该策略在更新期间提供了一组基本的安全保证(就绪探测)。然而，滚动更新策略面临许多局限性:
对推出速度的控制很少
无法控制新版本的流量
准备探头不适合深度检查、压力检查或一次性检查
无法查询外部指标以验证更新
可以停止进程，但无法自动中止和回滚更新
由于这些原因，在大规模的大批量生产环境中，滚动更新通常被认为是一种风险太大的更新过程，因为它无法控制爆炸半径，可能会过于激进地推出，并且无法在故障时提供自动回滚。

支持的功能

蓝绿更新策略 灰度更新策略 细粒度、加权流量转移 自动回滚和升级 手动判断 可自定义的指标查询和业务 KPI 分析 Ingress Controller 集成：NGINX、ALB、Apache APISIX Service Mesh 集成：Istio、Linkerd、SMI 指标提供程序集成：Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs、Datadog、New Relic、InfluxDB

GitOps

是一种用于持续部署和应用程序管理的操作模型，它将 Git 作为单一的事实来源和配置的中心。这种方法依赖于 Git 的强大功能，包括版本控制、合作和审计能力，以实现更加可靠和快速的软件开发和运营流程。
GitOps 的核心概念包括：
  1. 声明式基础设施：在 Git 仓库中使用声明式配置来描述系统和应用程序的期望状态。
  1. 版本控制：所有的变更都通过 Git 提交进行管理，这样就有了一个变更历史的记录，可以追溯每一次变更和决策。
  1. 自动化：使用自动化工具来确保系统的实际状态与 Git 仓库中的声明式配置保持一致。如果有差异，自动化系统会进行必要的调整。
  1. 持续集成/持续部署 (CI/CD)：在代码提交到 Git 后，自动化的 CI/CD 流水线会进行构建、测试，并且将更新部署到生产环境。
  1. 监控和反馈循环：监控系统的实际状态，并在检测到与 Git 仓库中的声明不一致时，触发自动修复流程。
GitOps 的优势包括：
  • 改进的生产力和速度：自动化的流程减少了手动操作的需要，提高了速度和效率。
  • 更好的可靠性：通过代码审查和自动化测试，可以减少人为错误，提高系统的稳定性和可靠性。
  • 易于追踪和审计：所有变更都记录在 Git 中，方便追踪变更历史和进行审计。
  • 快速回滚：如果新的部署出现问题，可以快速回滚到之前的状态。
  • 简化的管理：使用 Git 作为单一的配置源，简化了配置管理。
GitOps 常见的工具和技术包括：
  • Argo CD：一种声明式的、Git 驱动的持续交付工具。
  • Flux CD：另一种流行的工具，用于自动化 Kubernetes 集群的配置和应用程序部署。
  • Terraform：可以与 GitOps 流程一起使用来管理和部署基础设施资源。
  • Helm：Kubernetes 的包管理器，可以用于管理 Kubernetes 应用程序的声明式配置。
GitOps 是云原生环境中的一个流行概念，尤其是与 Kubernetes 和容器化应用程序一起使用时，但它的原则也可以应用于其他类型的环境和架构。
CI/CD 是一组持续的软件开发实践，旨在提高软件交付的速度和质量。它们通常是现代软件开发流程中不可或缺的部分，特别是在敏捷开发和DevOps文化中。CI/CD 的两个主要组成部分是持续集成（Continuous Integration）和持续交付或持续部署（Continuous Delivery/Continuous Deployment）。以下是它们各自的定义和工作方式：

持续集成 (CI)

持续集成是一个自动化的过程，开发者频繁地（通常是每天多次）将代码变更合并到共享的主分支中。这个过程的目的是尽早发现并解决集成问题，避免代码分支偏离主线太久而导致合并冲突和错误累积。CI 过程通常包括以下步骤：
  1. 代码提交：开发者将代码变更提交到版本控制系统。
  1. 自动构建：CI 服务器监控版本控制系统，当检测到新的提交时，自动执行构建过程。
  1. 自动测试：构建成功后，自动执行一系列测试（单元测试、集成测试等），以确保新代码不会破坏现有功能。
  1. 反馈：如果测试通过，变更被认为是好的，可以合并到主分支。如果测试失败，团队会立即收到反馈，开发者需要修复这些问题。

持续交付 (CD)

持续交付是在CI的基础上，确保软件可以随时被安全地发布到生产环境的做法。它扩展了CI，通过自动化部署和测试来验证，如果决定发布，软件能否随时顺利地部署到用户环境中。CD 的关键实践包括：
  1. 自动部署：代码变更在通过CI流程后，自动部署到一个或多个测试或者预生产环境中。
  1. 测试自动化：在自动部署之后，执行额外的自动化测试，这些测试可能包括UI测试、性能测试、安全测试等。
  1. 手动触发发布：在持续交付中，最终将变更部署到生产环境通常是一个手动过程，以确保对发布时机的控制。

持续部署 (CD)

持续部署是持续交付的下一步，它将自动化推向极致：每次通过CI/CD流水线的变更都会自动部署到生产环境，没有人工干预。这意味着软件的新功能和修复能够更快速地到达用户。持续部署要求有高度的自动化和非常成熟的测试策略，以确保不会因为自动部署而导致生产环境的问题。

CI/CD 的好处

  • 更快的迭代：快速集成和部署新的代码变更，加速产品迭代。
  • 较低的风险：频繁、小批量的变更减少了软件发布的风险。
  • 即时反馈：开发者可以快速得到关于他们代码的反馈，包括构建状态、测试结果和生产部署的情况。
  • 自动化流程：自动化测试和部署减少了重复性工作，减少了人为错误。

CI/CD 工具

许多工具可以支持CI/CD实践，包括：
  • Jenkins：一个开源的自动化服务器，可以用来自动化各种任务，包括构建、测试和部署。
  • GitLab CI/CD：GitLab 提供的集成CI/CD服务。
  • GitHub Actions：GitHub 的自动化和CI/CD平台。
  • CircleCI：一个专注于CI/CD的服务，支持快速的构建、测试和部署。
  • Travis CI：一个流行的托管CI服务，用于构建和测试软件项目。
  • Spinnaker：一个开源的、多云的持续交付平台，由Netflix开发。
选择哪个CI/CD工具通常取决于团队的特定需求、现有的技术栈和预算。

Helm

是 Kubernetes 的包管理工具，它允许开发者和运维人员打包、配置和部署应用程序和服务到 Kubernetes 集群。Helm 使用称为“charts”的打包格式，一个 chart 是一个包含了应用程序资源定义的文件集合。
以下是使用 Helm 安装应用的基本步骤：

1. 安装 Helm

首先，你需要在你的机器上安装 Helm。以下是在 macOS 上通过 Homebrew 安装 Helm 的命令：
对于其他操作系统，你可以访问 Helm 的官方安装指南 来查看具体的安装步骤。

2. 添加 Helm 仓库

Helm 依赖于仓库（repos）来管理 charts。你可以将公共仓库添加到 Helm 中，以便下载和安装其他人创建的 charts。例如，要添加官方的 stable 仓库，你可以运行：
然后，通过更新仓库信息来获取最新列表的 charts：

3. 搜索 Helm charts

在安装应用之前，你可以搜索可用的 charts。例如，如果你想安装一个名为 myapp 的应用，你可以运行：
这将会列出所有与 myapp 相关的可用 charts。

4. 安装 Helm chart

一旦你找到了想要安装的 chart，你可以使用以下命令来安装它：
  • [RELEASE_NAME] 是你为这次安装指定的名称，这个名字在 Kubernetes 集群中需要是唯一的。
  • [CHART_NAME] 是你想要安装的 chart 的名字。
例如，如果你想安装一个名为 myapp 的应用，并且想要将这个 release 命名为 my-release，你可以运行：

5. 配置 Helm chart

如果你需要自定义 chart 的安装，你可以创建一个名为 values.yaml 的文件，其中包含了你想要覆盖的默认配置项。然后，你可以在安装时使用 -f 参数指定这个文件：

6. 检查安装的 Helm chart

安装完成后，你可以使用以下命令来检查 release 的状态：

7. 更新和删除 Helm chart

如果你需要更新或者删除已经安装的 chart，你可以使用 helm upgrade 和 helm uninstall 命令：
使用 Helm，你可以轻松地在 Kubernetes 集群中部署、管理和升级应用程序和服务。它是 Kubernetes 生态系统中的一个关键工具，让包管理变得简单高效。