Install
- helm-charts : https://argoproj.github.io/argo-helm
- dashboard.enabled=true 옵션 추가
Dashboard
Rollout Specification
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: example-rollout-canary
spec:
# 원하는 파드 수를 지정합니다.
# 기본값은 1입니다.
replicas: 5
analysis:
# 성공한 분석 실행과 실험의 기록을 저장하는 데에 제한을 둡니다.
# 기본값은 5입니다.
successfulRunHistoryLimit: 10
# 실패한 분석 실행과 실험의 기록을 저장하는 데에 제한을 둡니다.
# 실패 스테이지: "Error", "Failed", "Inconclusive"
# 기본값은 5입니다.
unsuccessfulRunHistoryLimit: 10
# 파드를 선택하는 데 사용되는 레이블 셀렉터입니다.
# 이 롤아웃에 영향을 받는 기존 ReplicaSet을 선택해야 합니다.
# 파드 템플릿의 레이블과 일치해야 합니다.
selector:
matchLabels:
app: guestbook
# Pod 템플릿을 제공하는 워크로드를 참조합니다.
# (예: Deployment). 사용하면 롤아웃 템플릿 속성을 사용하지 마세요.
workloadRef:
apiVersion: apps/v1
kind: Deployment
name: rollout-ref-deployment
# 생성될 파드를 설명하는 템플릿입니다. Deployment와 동일합니다.
# 사용하면 롤아웃 workloadRef 속성을 사용하지 마세요.
template:
spec:
containers:
- name: guestbook
image: argoproj/rollouts-demo:blue
# 새롭게 생성된 파드가 문제없이 준비된 상태로 유지될 최소 시간 (초).
# 기본값은 0입니다. (파드는 준비되면 즉시 사용 가능한 것으로 간주됩니다)
minReadySeconds: 30
# 유지할 이전 ReplicaSet의 수를 지정합니다.
# 기본값은 10입니다.
revisionHistoryLimit: 3
# Pause는 롤아웃을 수동으로 일시 정지할 수 있게 합니다.
# 롤아웃이 일시 정지된 동안 단계를 진행하지 않지만 HPA(수평 파드 자동 확장)는 여전히 작동합니다.
# 일반적으로 명시적으로 매니페스트에 설정하지 않고, kubectl argo rollouts pause과 같은 도구를 통해 제어합니다.
# 최초 롤아웃 생성 시에 true로 설정되면 수동으로 프로모션하지 않는 한 제로에서 자동으로 복제본이 확장되지 않습니다.
paused: true
# 롤아웃이 업데이트 중에 진행해야 할 최대 시간 (초).
# 업데이트가 실패한 것으로 간주되기 전에 롤아웃이 진행되어야 합니다.
# Argo Rollouts는 실패한 롤아웃을 계속 처리하며 롤아웃 상태에 ProgressDeadlineExceeded 이유로 된 상태 조건이 표시됩니다.
# 롤아웃이 일시 정지된 동안에는 진행이 추정되지 않습니다.
# 기본값은 600초입니다.
progressDeadlineSeconds: 600
# ProgressDeadlineSeconds가 초과되면 업데이트를 중단할지 여부를 지정합니다.
# 선택적이며 기본값은 false입니다.
progressDeadlineAbort: false
# 롤아웃이 모든 파드를 순차적으로 다시 시작해야 하는 UTC 타임스탬프입니다.
# `kubectl argo rollouts restart ROLLOUT` 명령에서 사용됩니다.
# 컨트롤러는 모든 파드의 creationTimestamp가 이 값보다 크거나 같도록 보장합니다.
restartAt: "2020-03-30T21:19:35Z"
# 롤아웃을 이전에 배포한 버전으로 빠르게 이동시키기 위한 롤백 윈도우를 설정합니다.
# 선택사항이며 기본값으로 설정되지 않습니다.
rollbackWindow:
revisions: 3
strategy:
# 블루-그린 업데이트 전략
blueGreen:
# 롤아웃이 변경하는 서비스를 활성 서비스로 참조합니다.
# 필수 항목입니다.
activeService: active-service
# 서비스 전환 이전에 수행되는 사전 프로모션 분석 실행입니다.
# 선택 사항입니다.
prePromotionAnalysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: guestbook-svc.default.svc.cluster.local
# 서비스 전환 이후에 수행되는 사후 프로모션 분석 실행입니다.
# 선택 사항입니다.
postPromotionAnalysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: guestbook-svc.default.svc.cluster.local
# 롤아웃이 미리보기 서비스로 변경하는 서비스의 이름입니다.
# 선택 사항입니다.
previewService: preview-service
# 스위치 전에 미리보기 서비스에서 실행할 복제본 수입니다.
# 롤아웃이 재개되면 새로운 ReplicaSet이 완전히 확장된 후 스위치가 발생합니다.
# 선택 사항입니다.
previewReplicaCount: 1
# 롤아웃이 새로운 ReplicaSet을 자동으로 활성 서비스로 프로모션할지 여부를 지정합니다.
# 지정하지 않으면 기본값은 true입니다.
# 선택 사항입니다.
autoPromotionEnabled: false
# ReplicaSet이 준비 상태가 된 후 지정된 일시 정지 지연 시간(초) 이후에 현재 ReplicaSet을 자동으로 활성 서비스로 프로모션합니다.
# 생략되면 spec.Paused를 false로 재설정하여 수동으로 재개될 때까지 일시 정지 상태로 유지됩니다.
# 선택 사항입니다.
autoPromotionSeconds: 30
# 이전 ReplicaSet의 파드 축소를 시작하기 전에 딜레이를 추가합니다.
# 생략하면 이전 ReplicaSet의 파드 축소를 시작하기 전에 30초간 대기합니다.
# 클러스터의 모든 노드에 IP 테이블 전파를 보장하려면 최소 30초를 권장합니다.
# 선택 사항입니다.
scaleDownDelaySeconds: 30
# 한 번에 실행되는 이전 RS의 수를 제한합니다.
# 기본값은 없음입니다.
# 선택 사항입니다.
scaleDownDelayRevisionLimit: 2
# 업데이트가 중단된 경우 캐너리 파드의 축소를 시작하기 전에 대기하는 시간(초)을 추가합니다.
# 기본값은 30초입니다.
# 선택 사항입니다.
abortScaleDownDelaySeconds: 30
# 원하는 ReplicaSet과 이전 ReplicaSet 간의 안티-어파인티(anti-affinity) 구성입니다.
# 한 가지만 지정해야 합니다.
# 선택 사항입니다.
antiAffinity:
requiredDuringSchedulingIgnoredDuringExecution: {}
preferredDuringSchedulingIgnoredDuringExecution:
weight: 1 # 1~100 사이의 값
# 카나리아 업데이트 전략
canary:
# 컨트롤러가 카나리아 파드를 선택하기 위해 업데이트할 서비스를 참조합니다.
# 트래픽 라우팅을 위해 필수 항목입니다.
canaryService: canary-service
# 컨트롤러가 안정적인 파드를 선택하기 위해 업데이트할 서비스를 참조합니다.
# 트래픽 라우팅을 위해 필수 항목입니다.
stableService: stable-service
# 업데이트 동안 카나리아 파드에 부착할 메타데이터입니다.
# 이 메타데이터는 업데이트 중에만 존재하며 완전히 프로모트된 롤아웃에는 카나리아 파드가 없습니다.
# 선택 사항입니다.
canaryMetadata:
annotations:
role: canary
labels:
role: canary
# 안정적인 파드에 부착할 메타데이터입니다.
# 선택 사항입니다.
stableMetadata:
annotations:
role: stable
labels:
role: stable
# 업데이트 동안 허용할 수 있는 최대 파드 수입니다.
# 값은 절대적인 수 (예: 5) 또는 업데이트 시작 시 전체 파드 수의 백분율 (예: 10%)일 수 있습니다.
# 절대 숫자는 백분율을 내림하여 계산됩니다.
# 이 값은 0이 아니어야 합니다. MaxSurge가 0이면 0이 될 수 없습니다.
# 기본값은 1입니다. 예를 들어, 30%로 설정하면 롤링 업데이트가 시작되면 이전 ReplicaSet의 파드 수를 즉시 30% 축소시킬 수 있습니다.
# 새로운 파드가 준비되면 이전 ReplicaSet은 더 축소될 수 있으며 새로운 ReplicaSet을 확장하고 최소한 70%의 원래 파드 수가 항상 사용 가능합니다.
# 선택 사항입니다.
maxUnavailable: 1
# 최대 원래 파드 수 이상으로 스케줄될 수 있는 파드의 최대 수입니다.
# 값은 절대적인 수 (예: 5) 또는 업데이트 시작 시 전체 파드 수의 백분율 (예: 10%)일 수 있습니다.
# MaxUnavailable이 0이 아니면 0이 될 수 없습니다. 절대 숫자는 백분율을 반올림하여 계산됩니다.
# 기본값은 1입니다. 예를 들어, 30%로 설정하면 롤링 업데이트가 시작되면 새로운 ReplicaSet을 30%로 즉시 확장할 수 있습니다.
# 이전 파드가 삭제되면 새로운 ReplicaSet이 더 많이 확장됩니다. 이렇게 함으로써 업데이트 중에 언제든지 최대 원래 파드 수의 130%가 사용 가능합니다.
# 선택 사항입니다.
maxSurge: "20%"
# 카나리아 전략과 트래픽 라우팅을 사용하는 경우 이전 ReplicaSet의 파드 축소를 시작하기 전에 딜레이를 추가합니다.
# 기본값은 30초입니다.
# 안정적인 서비스 선택자를 새로운 ReplicaSet을 가리키도록 전환한 후에도 일정 시간이 필요하므로 트래픽 공급자가 새로운 파드를 대상으로 재지정할 수 있도록 시간을 주기 위해 필요합니다.
# 이 값은 기본 또는 리플리카 가중 카나리아를 사용하는 경우 무시됩니다.
# 선택 사항입니다.
scaleDownDelaySeconds: 30
# 트래픽 라우팅을 사용하는 경우 트래픽 라우팅된 카나리아를 복사하는 데 사용될 각 ReplicaSet당 요청되는 최소 파드 수를 지정합니다.
# 고 가용성을 보장하기 위해 기본값은 1입니다.
# 선택 사항입니다.
minPodsPerReplicaSet: 2
# 한 번에 실행되는 이전 RS의 수를 제한합니다.
# 기본값은 없음입니다.
# 선택 사항입니다.
scaleDownDelayRevisionLimit: 2
# 롤아웃 업데이트 중에 백그라운드에서 실행될 분석입니다.
# 최초 롤아웃 배포 시에는 생략됩니다.
# 선택 사항입니다.
analysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: guestbook-svc.default.svc.cluster.local
# valueFrom.podTemplateHashValue는 안정적인 ReplicaSet 또는 최신 ReplicaSet의 rollouts-pod-template-hash 값을 편리하게 제공합니다.
- name: stable-hash
valueFrom:
podTemplateHashValue: Stable
- name: latest-hash
valueFrom:
podTemplateHashValue: Latest
# valueFrom.fieldRef를 사용하여 롤아웃에 대한 메타데이터를 분석 인자로 제공합니다.
- name: region
valueFrom:
fieldRef:
fieldPath: metadata.labels['region']
# 카나리아 업데이트 동안 수행할 일련의 단계를 정의합니다.
# 최초 롤아웃 배포 시에는 생략됩니다.
# 선택 사항입니다.
steps:
# 카나리아 ReplicaSet 비율을 20%로 설정합니다.
- setWeight: 20
# 롤아웃을 1시간 동안 일시 정지합니다. 지원하는 단위: s, m, h
- pause:
duration: 1h
# 수동으로 재개될 때까지 무기한 일시 정지합니다.
- pause: {}
# 트래픽 라우팅을 사용하는 경우 트래픽 가중치를 변경하지 않고 카나리아 파드 수를 명시적으로 설정합니다.
# (트래픽 라우팅만 지원)
- setCanaryScale:
replicas: 3
# 트래픽 라우팅을 사용하는 경우 트래픽 가중치를 변경하지 않고 spec.replicas의 백분율로 카나리아 파드 수를 설정합니다.
# (트래픽 라우팅만 지원)
- setCanaryScale:
weight: 25
# 트래픽 라우팅을 사용하는 경우 카나리아 파드 수를 트래픽 가중치에 맞게 설정합니다.
# 기본 동작입니다.
- setCanaryScale:
matchTrafficWeight: true
# 지정된 헤더 값을 사용하여 헤더 기반 경로를 설정합니다.
# 이러한 헤더 기반 경로를 설정하면 요청 헤더 "version":"2"의 모든 100 트래픽이 카나리아로 전송됩니다.
# (트래픽 라우팅만 지원, 현재는 Istio만 가능)
- setHeaderRoute:
# argo rollouts에 의해 생성될 라우트의 이름입니다. 이것은 spec.strategy.canary.trafficRouting.managedRoutes에도 구성되어야 합니다.
name: "header-route-1"
# 헤더 라우트의 매칭 규칙입니다. 이 부분이 누락되면 라우트를 제거하는 역할을 합니다.
match:
# headerName: 매칭 규칙을 적용할 헤더의 이름입니다.
- headerName: "version"
# headerValue는 정확히 하나의 exact, regex 또는 prefix 필드를 포함해야 합니다. 모든 트래픽 라우터가 모든 유형을 지원하지는 않습니다.
headerValue:
# Exact는 헤더 값이 정확히 같은 경우에만 일치합니다.
exact: "2"
# 정규식이 일치하면 규칙이 매칭됩니다.
regex: "2.0.(.*)"
# prefix는 헤더 값의 접두사가 일치합니다.
prefix: "2.0"
# 지정된 일치 규칙을 사용하여 미러/그림자 기반 라우트를 설정합니다.
# 롤아웃 중에 트래픽은 구성된 비율로 카나리 서비스에 미러링됩니다.
# (trafficRouting으로만 지원되며, 현재 Istio에서만 지원됩니다.)
- setMirrorRoute:
# argo rollouts에서 생성할 라우트의 이름입니다.
# 또한 spec.strategy.canary.trafficRouting.managedRoutes에서 구성해야 합니다.
name: "헤더-라우트-1"
# 카나리에 미러링할 일치 트래픽의 비율입니다.
percentage: 100
# 헤더 라우트의 일치 규칙입니다. 이 부분이 빠지면 라우트가 제거됩니다.
# 하나의 일치 블록 내에서 모든 조건은 AND 세맨틱을 가지며, 일치 블록의 목록은 OR 세맨틱을 가집니다.
# 일치의 각 유형 (method, path, headers)은 하나의 일치 유형 (exact, regex, prefix)만 가져야 합니다.
# 모든 트래픽 라우터에서 모든 일치 유형 (exact, regex, prefix)을 지원하는 것은 아닙니다.
match:
- method: # 일치시킬 HTTP 메서드
exact: "GET"
regex: "P.*"
prefix: "POST"
path: # 일치시킬 HTTP URL 경로
exact: "/test"
regex: "/test/.*"
prefix: "/"
headers:
agent-1b: # 일치시킬 HTTP 헤더 이름
exact: "firefox"
regex: "firefox2(.*)"
prefix: "firefox"
# 인라인 분석 단계
- analysis:
templates:
- templateName: 성공률
# 인라인 실험 단계
- experiment:
duration: 1h
templates:
- name: 기준선
specRef: stable
# 선택 사항: 실험을 위한 서비스 생성 여부 설정
service:
# 선택 사항: 이름이 포함되지 않은 경우 service: {}도 허용됩니다.
name: 테스트-서비스
- name: 카나리
specRef: canary
# 선택 사항: 이 버전으로 라우팅되는 트래픽의 가중치 설정
weight: 10
analyses:
- name: 만-위트니
templateName: 만-위트니
# 원하는 ReplicaSet과 이전 ReplicaSet 사이의 반대극성 구성
# 반드시 하나만 지정해야 합니다.
antiAffinity:
requiredDuringSchedulingIgnoredDuringExecution: {}
preferredDuringSchedulingIgnoredDuringExecution:
weight: 1 # 1에서 100 사이의 값
# 트래픽 라우팅은 고급 트래픽 분할을 위한 인그레스 컨트롤러 또는 서비스 메시 구성을 지정합니다.
# 생략하면 카나리와 안정적인 ReplicaSet 사이의 가중치 기반 트래픽 분할을 달성합니다.
trafficRouting:
# Argo Rollouts가 관리할 라우트 목록입니다.
# 현재 setMirrorRoute와 setHeaderRoute에서만 필요합니다.
# managedRoutes 배열의 순서는 트래픽 라우터에서 우선 순위를 설정합니다.
# Argo Rollouts는 이러한 라우트를 지정된 순서대로 배치합니다.
# 이미 사용 중인 트래픽 라우터에 이미 정의된 라우트가 있는 경우에도 여기서의 이름이 일치해야 합니다.
managedRoutes:
- name: 헤더-설정
- name: 미러-라우트
# Istio 트래픽 라우팅 구성
istio:
# virtualService 또는 virtualServices 중 하나를 구성할 수 있습니다.
virtualService:
name: rollouts-vsvc1 # 필수
routes:
- primary # 단일 route가 있는 경우 선택 사항, 그렇지 않으면 필수
virtualServices:
# 하나 이상의 virtualService를 구성할 수 있습니다.
- name: rollouts-vsvc1 # 필수
routes:
- primary # 단일 route가 있는 경우 선택 사항, 그렇지 않으면 필수
- name: rollouts-vsvc2 # 필수
routes:
- secondary # 단일 route가 있는 경우 선택 사항, 그렇지 않으면 필수
# NGINX Ingress Controller 라우팅 구성
nginx:
# stableIngress 또는 stableIngresses 중 하나를 구성해야 합니다.
# 둘 다 구성하면 안 됩니다.
stableIngress: primary-ingress
stableIngresses:
- primary-ingress
- secondary-ingress
- tertiary-ingress
annotationPrefix: customingress.nginx.ingress.kubernetes.io # 선택 사항
additionalIngressAnnotations: # 선택 사항
canary-by-header: X-Canary
canary-by-header-value: iwantsit
# ALB Ingress Controller 라우팅 구성
alb:
ingress: ingress # 필수
servicePort: 443 # 필수
annotationPrefix: custom.alb.ingress.kubernetes.io # 선택 사항
# Service Mesh Interface 라우팅 구성
smi:
rootService: root-svc # 선택 사항
trafficSplitName: rollout-example-traffic-split #선택 사항
# 트래픽 라우팅이 있는 canary 전략에서 업데이트가 중단된 경우 canary pod를 스케일 다운하기 전에 지연 시간을 설정합니다.
# (기본적인 canary 전략에는 해당되지 않습니다.)
# 0은 canary pod가 스케일 다운되지 않음을 의미합니다. 기본값은 30초입니다.
abortScaleDownDelaySeconds: 30
status:
pauseConditions:
- reason: StepPause
startTime: 2019-10-00T1234
- reason: BlueGreenPause
startTime: 2019-10-00T1234
- reason: AnalysisRunInconclusive
startTime: 2019-10-00T1234참고
DevOps, 개발팀과 운영팀이 알아두면 좋은 정보를 공유합니다.