argo rollout使用

原创 已于 2024-03-30 15:10:32 修改 · 1.3k 阅读 · 17 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#devops

于 2024-03-29 18:05:26 首次发布
本文详细介绍了如何部署和使用ArgoRollout进行高级Kubernetes发布管理，包括金丝雀发布、蓝绿发布和滚动更新，以及通过argocd自动化部署流程和监控发布过程。

一、前言

      argorollout是比argocd更高级的发布工具，其中包含自动化金丝雀发布、自动化蓝绿发布、还可以通过argo命令或者dashboard查看发布的过程

二、使用

需要先部署argo rollout服务

参考：https://github.com/argoproj/argo-rollouts/tree/master/manifests

创建argo rollout目录

mkdir /opt/argocd-rollout && cd /opt/argocd-rollout

下载yaml文件部署

wget https://github.com/argoproj/argo-rollouts/blob/master/manifests/install.yaml

创建命名空间

kubectl create namespace argo-rollouts

部署argo rollout服务

kubectl apply -f install.yaml -n argo-rollouts

查看是否部署完成

kubectl get all -n argo-rollouts

安装命令行工具

wget https://github.com/argoproj/argo-rollouts/releases/download/v1.6.6/kubectl-argo-rollouts-linux-amd64
cp kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts
chmod +x /usr/local/bin/kubectl-argo-rollouts

部署dashboard

wget https://github.com/argoproj/argo-rollouts/blob/master/manifests/dashboard-install.yaml

更改部署文件的svc配置，改为nodeport模式

vi dashboard-install.yaml

执行部署 

kubectl create -f dashboard-install.yaml -n argo-rollouts

启动dashboard

kubectl argo rollouts dashboard

滚动更新

在gitops仓库创建存放服务yaml的目录

在目录中创建部署服务的yaml文件

rollout.yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: argo
  labels:
    app: argo
spec:
  replicas: 5
  selector:
    matchLabels:
      app: argo
  template:
    metadata:
      labels:
        app: argo
    spec:
      containers:
      - name: argo
        image: argoproj/rollouts-demo:green
        imagePullPolicy: IfNotPresent
        readinessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 2
          successThreshold: 1
          failureThreshold: 2
        livenessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
          failureThreshold: 2 
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
  strategy:
    canary:      #开启金丝雀发布
      maxSurge: "20%"    #定义最大更新pod数量为20%
      maxUnavailable: 0     #定义最大不可用pod数量为0
      steps:
       - setWeight: 20
       - pause:         #如果pod探针的健康检测没过，即使手动执行继续更新pod也不会继续更新
           duration: 1h
       - setWeight: 40
       - pause: {}
       - setWeight: 60
       - pause: {}
       - setWeight: 80
       - pause: {}

 service.yaml

apiVersion: v1
kind: Service
metadata:
  name: argo
  labels: 
    app: argo
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: argo

定义完成后，在argocd创建对应的应用，先执行同步在k8s创建出服务，在更改应用为自动同步模式

 这里在gitops直接更改rollout的镜像，模拟版本更新，触发argocd的自动化发布

 等待三分钟argocd触发自动同步后可以看到开始了滚动更新发布，会发现更新了一个新版本的pod删除掉了一个老版本的pod

也可以通过argo命令行查看发布进程

kubectl argo rollouts get rollout argo --watch   #加上watch是实时观测，去掉watch是显示出当时的

执行命令让滚动更新继续执行，也可以执行命令回滚到stable版本

#继续滚动更新
 kubectl argo rollouts promote argo
#取消滚动更新，回滚到stable版本
kubectl argo rollouts abort argo

 再次查看，可以看到新版本的pod更新的同时，旧版本的pod也在删除，一直循环往复直到新版本pod删除完成，后面的就不演示了

展示一下取消更新回滚的过程

kubectl argo rollouts abort argo

 可以看到执行回滚命令后，删除新版本的pod，重新创建旧版本的pod

并且不用再通过手动开始滚动的步骤直接自动回滚到所有pod为老版本

至此滚动更新介绍完成 

自动化金丝雀发布

跟滚动更新一样在目录中创建部署服务的yaml文件

rollout.yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout       #使用rollout类型，实际就是比deployment更高级的控制器
metadata:
  name: argo
  labels:
    app: argo
spec:
  replicas: 3     #定义副本数
  selector:
    matchLabels:
      app: argo
  template:
    metadata:
      labels:
        app: argo
    spec:
      containers:
      - name: argo
        image: argoproj/rollouts-demo:green       #使用argo rollouts的demo可以更直观的看到金丝雀发布过程
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
  strategy:       #定义升级策略
    canary:         #使用金丝雀发布
      canaryService: argo-canary   #金丝雀环境的svc服务名称
      stableService: argo          #生产环境的svc服务名称
      canaryMetadata:       #应用于金丝雀环境pod的标签
        labels:
          deployment: canary
      stableMetadata:       #应用于生产环境pod的标签
        labels:
          deployment: stable
      trafficRouting:       #定义ingress
        nginx:          #使用nginx控制器
          stableIngress: argo       #定义生产环境ingress的名称
          additionalIngressAnnotations:     #定义ingress的参数
            canary-by-header: X-Canary      #定义使用该请求头的请求走金丝雀环境
      steps:              #升级流程
        - setWeight: 20    #更新百分之20，会根据pod的数量更新20%的pod，也会设置金丝雀环境的ingress流量权重为20%
        - pause: {}        #暂停更新，需要手动执行恢复才会继续执行
        - setWeight: 50    #设置金丝雀环境的流量权重为50%
        - pause:
            duration: 30s   #暂停30秒
        - setWeight: 70
        - pause:
            duration: 30s

service.yaml

apiVersion: v1      #这里创建两个svc来切分生产环境和金丝雀环境的流量
kind: Service
metadata:
  name: argo
  labels: 
    app: argo
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: argo
---
apiVersion: v1
kind: Service
metadata:
  name: argo-canary
  labels: 
    app: argo
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: argo

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress      #创建生产环境的ingress
metadata: 
  name: argo
  labels:
    app: argo
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: argo.apex.com       #定义域名
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argo     #匹配生产环境的svc
                port:
                  name: http

定义完成后，在argocd创建对应的应用，先执行同步在k8s创建出服务，在更改应用为自动同步模式

 访问一下部署的argo服务，会看到现在所有访问都是绿的

 这里在gitops直接更改rollout的镜像，模拟版本更新，触发argocd的自动化发布

 等待三分钟argocd触发自动同步后可以看到开始了金丝雀发布

查看部署的argo服务 会发现有一部分金丝雀环境的流量即蓝色的

 也可以使用curl命令访问去验证，会有一部分流量调度到金丝雀环境

 查看一下发布的情况，可以用命令行，也可以用dashboard

kubectl argo rollouts get rollout argo --watch  #后面的argo是部署的服务名称

 

与此同时可以来查看一下ingress、svc的情况 

可以看到金丝雀环境的svc 标签选择器绑定了一个新的标签，并且新版本的pod也是绑定在了金丝雀环境的svc上

 可以看到新建了一个金丝雀环境的ingress，并且通过金丝雀环境的svc发现了新版本的pod

 还可以通过rollout更直观的了解金丝雀发布的流程

kubectl describe rollout argo

先是新建了rs并将pod数量设置为1,然后创建金丝雀环境的ingress设置流量权重，再将金丝雀环境的svc标签选择器更改

了解到这里就在继续执行更新，也可以执行取消更新

继续更新 

kubectl argo rollouts promote argo

取消更新，执行取消后会回滚到stable版本

kubectl argo rollouts abort argo

 可以通过dashboard看发布的情况

查看argo服务也会发现全部是蓝的流量

 全部发布完成后再查看svc和ingress会发现，金丝雀环境、生产环境的svc和ingress都是指向的新版本的pod，但金丝雀环境的ingress流量权重为0

补充一下金丝雀发布是金丝雀环境的所有pod启动后，再去删除生产环境的所有pod

 至此金丝雀发布完成

自动化蓝绿发布

跟金丝雀发布一样使用gitops仓库存放yaml文件

rollout.yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: argo
  labels:
    app: argo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: argo
  template:
    metadata:
      labels:
        app: argo
    spec:
      containers:
      - name: argo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
  strategy:       #发布策略
     blueGreen:     #开启蓝绿发布
       autoPromotionEnabled: true
       activeService: argo     #定义svc服务名称

 service.yaml

apiVersion: v1
kind: Service
metadata:
  name: argo
  labels: 
    app: argo
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: argo

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argo
  labels:
    app: argo
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: argo.apex.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argo
                port:
                  name: http

在argocd中创建该服务的应用并进行第一次同步在k8s集群中创建服务再设置该应用为自动同步

在gitops仓库中更改rollout文件的镜像配置模拟版本发布

 

等待argocd自动同步，会发现两个版本的pod共存

查看argo服务会发现全部都是绿的流量

可以通过svc查看，也是通过更改svc的标签选择器，去选择新版本的pod，来达到流量切换到新版本pod的效果 

也可以通过rollout查看

至此自动化蓝绿发布介绍完成

Argo rollout 是生产环境下部署的利器
海鸥
09-21 523
Argo rollout 是生产环境下部署的利器
k8s学习--使用argo-rollouts实现金丝雀发布
lwxvgdv的博客
06-12 2732
Argo-Rollout是一个Kubernetes Controller和对应一系列的CRD（自定义资源类型），提供更强大的Deployment能力。包括灰度发布、蓝绿部署、更新测试(experimentation)、渐进式交付(progressive delivery)等特性。
Argo Rollouts 实现蓝绿/金丝雀发布
DevOps持续集成的博客
08-04 1424
Argo Rollouts 是一个 Kubernetes Operator 实现，它为 Kubernetes 提供更加高级的部署能力，如蓝绿、金丝雀、金丝雀分析、实验和渐进式交付功能，为云...
【GitOps】Argo Rollouts 金丝雀发布
最新发布
weixin_73059729的博客
10-22 1260
Argo Rollouts是Kubernetes的高级部署控制器，支持蓝绿、金丝雀等渐进式交付策略。它通过自定义Rollout资源替代原生Deployment，提供流量拆分、自动回滚和指标分析等功能。核心组件包括Rollout控制器、Analysis资源用于指标验证，以及集成多种服务网格和Ingress控制器。安装过程简单，只需创建命名空间并应用YAML文件即可部署。Argo Rollouts通过精确控制发布流程，显著降低了生产环境发布风险，是云原生应用持续交付的理想解决方案。
Argo Rollouts 体验
ygqygq2的IT博客
05-16 1013
文章目录1. Argo Rollouts 简单介绍2. Argo Rollouts 安装3. Argo Rollouts Kubectl 插件安装4. Argo Rollouts 架构5. 官方示例体验6. 示例体验6.1 基本使用6.1.1 部署 rollout6.1.2 更新 rollout6.1.3 恢复 rollout6.1.4 中断 rollout6.1.5 小结6.2 Argo Rollouts 配合 Istio 使用6.3 Argo Rollouts 配合 Nginx Ingress 使用7.
【 云原生 | kubernetes 】- Argo Rollouts渐进式发布
ycloud
09-29 794
Argo Rollouts是用于渐进式交付的Kubernetes 控制器，是Argo开源项目的一部分。为提供高级部署功能，具有渐进式交付、蓝绿发布、金丝雀发布和金丝雀分析等功能。
【kubernetes】Argo Rollouts -- k8s下的自动化蓝绿部署
因吹斯汀
09-01 2313
在现代软件开发和交付中，确保应用程序的平稳更新和发布对于用户体验和业务连续性至关重要。蓝绿部署是一种备受推崇的部署策略，它允许开发团队在不影响用户的情况下，将新版本的应用程序引入生产环境。蓝绿部署的核心思想在于维护两个独立的环境：蓝环境和绿环境。蓝环境是当前正在运行的稳定版本，而绿环境是即将发布的新版本。在进行部署时，首先将新版本部署到绿环境中，并在绿环境中进行严格的测试和验证。一旦新版本通过了各项测试，并被确认为稳定和可靠，就可以将流量从蓝环境切换到绿环境，使用户开始访问新版本。
渐进式交付 - 使用 Argo Rollouts 实现金丝雀与蓝/绿发布
weixin_42587823的博客
06-09 845
Argo Rollouts 同样完美支持蓝/绿部署。只需将strategy修改为blueGreenstrategy:blueGreen:# 指向当前线上 (blue) 版本的 Service# 指向新 (green) 版本的 Service，用于发布前的预览和测试# 部署完 Green 版本后是否自动切换流量，设为 false 则会暂停等待人工 promotepromote操作会通过修改的selector来实现流量的瞬间切换。今天，我们从标准的滚动更新迈出了一大步，进入了渐进式交付的领域。
精选资源
argo-rollouts：Kubernetes的渐进式交付
02-03
Argo推广-Kubernetes的逐步交付 什么是Argo推广？ Argo Rollouts是Kubernetes控制器和CRD集合，它们提供高级部署功能，例如蓝绿色，金丝雀，金丝雀分析，实验和向Kubernetes的渐进式交付功能。 Argo分支机构（可选...
在 Istio 服务网格中使用 Argo Rollouts 实现智能的渐进式发布
cr7258的博客
12-10 1291
在本文中我们介绍了如何使用 Argo Rollouts 结合 Istio 服务网格中丰富的流量治理以及可观测性能力；并通过 Argo Rollouts 提供的 Analysis 机制，在应用升级时对应用的健康状态进行分析，根据分析结果自动决定是否继续更新或者回滚，从而实现了智能的渐进式发布。
使用argo-rollouts实现金丝雀发布
testbaibai的博客
07-13 985
Argo-Rollout是一个Kubernetes Controller和对应一系列的CRD，提供更强大的Deployment能力。包括灰度发布、蓝绿部署、更新测试(experimentation)、渐进式交付(progressive delivery)等特性。支持特性如下：蓝绿色更新策略金丝雀更新策略细粒度，加权流量转移自动回rollback和promotion手动判断可定制的指标查询和业务KPI分析入口控制器集成：NGINX，ALB服务网格集成：Istio，Linkerd，SMI。
argo-rollouts
03-11
argo-rollouts
你好，argo-rollouts
02-08
你好，argo-rollouts
datou-k8-argocd-rollouts：在5分钟内刷新。 60分钟内学习
02-14
datou-k8-argocd推出 5分钟后刷新。 在60分钟内学习。
argocd-progressive-rollout-controller:ArgoCD ApplicationSet的渐进式推出控制器
05-22
argocd-渐进式推出控制器 ArgoCD ApplicationSet的渐进式推出控制器。 地位： 概念验证（积极寻找反馈） 我们正在构建它 为什么 正在开发作为替代app-of-apps模式的解决方案。 尽管ApplicationSet非常适合以编程方式生成应用程序，但您仍然需要解决如何更新应用程序的问题。 如果启用策略，则将同时更新所有生成的应用程序。 如果您只有一个生产集群，那么这可能不是问题，但是拥有数十个或数百个生产集群的组织需要避免在全球范围内推广，并以更安全的方式发布新版本。 argocd-progressive-rollout-operator通过允许操作员决定如何更新其应用程序来解决此问题。 概念 使用源引用来跟踪所有权，以监视“应用程序和机密”事件。 使用标签选择器检索群集列表。 依靠正确标记ArgoCD机密。 集群可以重新排队。 这意味着操作员将在阶
Argo Rollouts简介
闲余知道
07-09 418
Argo Rollouts简介
K8S - 金丝雀发布实战 - Argo Rollouts 流量控制解析
weixin_46619605的博客
05-07 1684
K8S - 金丝雀发布实战 - Argo Rollouts 流量控制解析
K8S - 蓝绿发布实战 - Argo Rollouts 零停机方案解析
weixin_46619605的博客
05-08 1386
K8S - 蓝绿发布实战 - Argo Rollouts 零停机方案解析
KubeVela配合argocd使用
04-14
<think>好的，我现在需要回答用户关于如何将KubeVela与ArgoCD集成使用的问题。首先，我得回忆一下KubeVela和ArgoCD各自的用途。KubeVela是一个基于OAM的云原生应用管理平台，主要关注应用交付和运维的抽象。而ArgoCD则是一个GitOps工具，专注于持续部署，通过声明式的方式同步Git仓库中的配置到Kubernetes集群。 用户需要的是集成这两者的教程或最佳实践。首先，我应该考虑它们各自的优势，以及如何互补。比如，KubeVela负责应用定义和跨环境部署，而ArgoCD负责同步状态，确保集群状态与Git仓库一致。 接下来，我需要查阅相关的文档或最佳实践。根据用户提供的引用，特别是引用[1]中的GitOps最佳实践链接可能有用。另外，引用[4]提到的BizWorks平台基于KubeVela的实践，可能也会涉及集成其他工具。 然后，我需要确定集成的基本步骤。可能的步骤包括：1.在KubeVela中定义应用，生成对应的Kubernetes资源清单；2.将清单提交到Git仓库；3.配置ArgoCD监控该仓库，自动同步到集群。同时，可能需要处理两者之间的协调，比如避免冲突，确保KubeVela控制器和ArgoCD控制器不会互相覆盖对方的修改。 还需要考虑权限管理和同步策略。比如，是否由KubeVela负责部分资源的部署，而ArgoCD负责另一部分？或者通过某种标签或注解来区分管理的资源？ 另外，参考引用[5]中提到的KubeVela与KEDA的集成，可能类似的模式可以应用在ArgoCD上，即通过KubeVela的应用模型生成配置，由ArgoCD进行持续部署。 最后，我应该验证这些步骤是否符合最佳实践，是否有官方文档或社区案例支持。如果发现可能存在冲突或需要注意的地方，比如资源的所有权问题，需要提醒用户进行适当的配置以避免问题。</think>### KubeVela 与 ArgoCD 集成使用实践 #### 1. 集成架构设计 KubeVela 作为应用定义层，负责跨集群、跨环境的抽象化部署策略；ArgoCD 作为 GitOps 引擎，负责将 Git 仓库中的配置声明同步至目标集群。两者通过以下方式协作： - **职责划分**：KubeVela 定义应用组件（Component）和运维特征（Trait），生成标准 Kubernetes 资源；ArgoCD 监听 Git 仓库变化并执行同步[^1][^4]。 - **资源所有权**：建议通过 `app.kubernetes.io/managed-by` 标签区分管理主体，避免控制循环冲突。 #### 2. 具体操作步骤 **步骤 1：KubeVela 生成部署清单** ```yaml # application.yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: demo-app spec: components: - name: frontend type: webservice properties: image: nginx:1.21 ports: - port: 80 expose: true traits: - type: scaler properties: replicas: 3 ``` 通过 `vela export -f application.yaml > manifests.yaml` 导出 Kubernetes 原生资源[^1]。 **步骤 2：配置 Git 仓库** - 创建 Git 仓库目录结构： ``` ├── apps │ └── demo-app │ ├── kustomization.yaml │ └── manifests.yaml └── environments └── production └── patch.yaml ``` - 提交生成的 `manifests.yaml` 至仓库 **步骤 3：ArgoCD 配置同步** ```yaml # argo-app.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: demo-app spec: project: default source: repoURL: https://github.com/yourrepo/gitops-demo path: apps/demo-app targetRevision: HEAD destination: server: https://kubernetes.default.svc namespace: default syncPolicy: automated: selfHeal: true prune: true ``` #### 3. 高级实践技巧 - **环境差异化配置**：使用 Kustomize 叠加层实现多环境配置，ArgoCD 通过 `ApplicationSet` 自动生成多环境实例[^4] - **渐进式交付**：结合 KubeVela 的 Rollout Trait 与 Argo Rollouts 实现金丝雀发布 ```yaml traits: - type: rollout properties: targetSize: 5 rolloutBatches: - replicas: 20% - replicas: 40% ``` - **状态同步**：通过 ArgoCD 的 `Resource Hooks` 调用 KubeVela 的 HealthScope 进行健康检查[^2] #### 4. 运维监控配置 - 部署拓扑关系可视化： ```bash vela status demo-app --dashboard ``` - ArgoCD 事件与 KubeVela 资源状态集成： ```bash argocd app get demo-app --show-params ``` #### 5. 权限控制建议 | 主体 | 权限范围 | RBAC 配置示例 | |------------|---------------------------|-----------------------------------| | KubeVela | 应用定义层资源 | ClusterRole 绑定 core.oam.dev API | | ArgoCD | 标准 Kubernetes 资源 | Role 限制特定命名空间 | | 开发者 | 应用级操作 | Application 级别的 edit 权限 | #### 注意事项 1. **同步频率**：建议 ArgoCD 同步间隔设置为 3-5 分钟，与 KubeVela 的控制器协调周期错开 2. **冲突解决**：优先以 Git 仓库为唯一真实来源（Single Source of Truth） 3. **密钥管理**：敏感配置通过 KubeVela 的 Secret Store 或 ArgoCD 的 Sealed Secrets 处理
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值