Summary

• k8s 자체적인 rolling update는 각 버전에 트래픽 분배, 롤백에 있어 안정적으로 사용하기는 어려움
• GatewayAPI를 사용해 외부 진입점을 설정하고, Argo Rollouts을 사용한 Blue/Green 무중단 배포 적용
• 팀의 결정사항을 기록한 ADR(Architecture Decision Records) 문서화를 통한 지식 공유

Thoughts

• 이 책에서 주로 배울 것은 단순 구현이 아니라 AI 활용과 팀 협업적인 부분
  • 환경마다 구현해야 할 적절한 선택지는 달라짐
  • AI 활용이 보편화될수록 실제 구현 내용은 표준화, 상향평준화될 것
    • Gateway API에 대한 자세한 지식 없어도 or 알고있다면 구축과정은 단순한 자연어로 구성 가능
  • 그래서 남는 차별점은 AI를 어떻게 쓰느냐?
    > (안 써본 사람에게) 개인 수준의 활용법과 팀 단위의 효율화라는 두 단계를 가르쳐 주고있음
• 실제로 팀의 AI 사용 문화를 어떻게 정리하고 어떻게 전파할 수 있을까
  • 야놀자 (AWS Korea 발표): knowledge-base를 통한 팀 지식 공유 (영상)
  • imweb 인프라팀: CLAUDE.md와 정책 파일 공유로 팀의 AI 사용경험을 표준화 (글)
  • 이러한 발표/사용사례를 볼수록 다른곳들은 실제로 어떻게 구축/어떤내용들이 들어있을지 궁금했음
  • 이 책의 과정이 실제로 저런 팀의 지식베이스를 구축하는것 같아 흥미로움
  • 다만 최소 한번의 실패가 있고 난뒤 생겨난 가드레일/프롬프트 가이드라는점

—

5장. 무중단 배포

• 3장의 Rolling Update = Pod를 하나씩 교체하는 방식, 롤링 중 구버전/신버전 모두 응답
• Notiflex API에 접근 시 kubectl port-forward 사용해야함, 로컬에서만 접근가능
• Gateway API로 외부 진입점 생성 후, Argo Rollrouts의 Blue/Green 배포로 무중단 배포 적용

5.1 Rolling Update는 왜 서비스가 끊기는가

• Rolling Update 시 새 Pod가 ready 된 후 기존 Pod down, 그 중 Service는 양쪽에 트래픽 분배
• Ready != 실제 요청을 받을 준비 완료 문제, 서버가 준비되어도 DB커넥션(5xx), 캐시워밍업(응답속도지연) 등의 미완료 가능성
• 배포가 시작되고 바로 트래픽 전달 시작 및 롤백이 빠르지 않음 > Blue/Green 배포로 새 버전 확인 후 전달 과 기존 버전으로의 빠른 롤백 가능
• 이를 위해 트래픽을 어디로 보낼지 유연하게 대응이 가능해야하며, 따라서 외부 진입점을 설정하고자함

5.2 외부 트래픽 관리: Gateway API

• 지금까지는 로컬의 k port-forward로 접근
• 실제서비스를 위한 외부 IP 필요 및 Blue/Green 배포를 위한 선언적 트래픽 경로 관리 > Gateway API

5.2.1 클로드 코드에게 트래픽 관리 도구 물어보기

• cc에서 자연어로 현재는 로컬에서만 호출 가능, 외부 API 서비스 제공하려면 어떻게해? 라고 질문
  • 현재 Notiflex API는 ClusterIP 로 존재, 내부라우팅만 가능함. 외부 접근을 위해선 GatewayAPI 추천

5.2.2 다른 도구는 없는지 비교해보기

• cc에서 자연어로 다른 서비스들과 비교해줘 라고 요청
  • GatewayAPI, Ingress NGINX, Istio, Traefik 중 GatewayAPI가 GKE 네이티브, 역할 분리, 리소스 관점에서 적합

5.2.3 Gateway API 설정하기

• cc에서 Gateway API 환경 구성해줘 라고 요청
  • Gateway, HTTPRoute, HealthCheckPolicy 3개의 manifest 생성 후 커밋푸시하여 ArgoCD 동기화
  • proxy-only subnet 부재로 인해 해당 서브넷 생성 필요

5.3 무중단 전환: Blue/Green 배포

• 배포 시작과 동시에 새 버전에 일부 트래픽이 전달되는 문제 해결을 위한 Blue/Green 설정

5.3.1 클로드 코드에게 무중단 배포 도구 물어보기

• cc에게 자연어로 완전한 무중단 배포를 위한 도구 알려줘 로 질의
  • ArgoCD를 쓰고있어 같은 생태계의 ArgoRollouts 권장

5.3.2 다른 도구는 없는지 비교해보기

• cc에게 자연어로 다른 무중단 배포 도구와 비교하면 어때 질의
  • Argo Rollouts, Flagger, k8s native rolling update, Istio
  • Flagger는 별도의 트래픽제어를 위한 도구 필요, 자체 롤링은 스킵, istio는 규모 및 리소스가 커서 부적합

5.3.3 Blue/Green 배포 설정하기

• cc에게 자연어로 Argo Rollouts 사용한 Blue/Green 배포 설정 해줘 요청

5.3.4 v0.2.0 배포하고 전환 과정 지켜보기

• cc에게 자연어로 실제 버전을 배포하고 Blue/Green 동작 확인 요청

5.4 마무리: 아키텍처 결정 기록하기

• 5장에서는 Gateway API(Ingress 대신), Blue/Green(Canary,Rolling 대신), 리전 로드밸런서(글로벌 대신)의 의사결정 수행
• code와 manifest는 어떻게를 보여주지만 왜는 보여주지 않음. 이는 로컬 cc 메모리에만 저장
• 회사와 팀의 협업을 위해서는 기록으로 남아야함 > ADR(Architecture Decision Records) 패턴의 정리
  • 결정사항을 한 건씩 번호 스타일로 마크다운에 누적, 같은 파일을 시간 순 채움
  • git으로 관리되어 누적 가능, 팀 및 AI에이전트가 결정 컨텍스트 확보 가능
• cc에게 자연어로 이번장의 아키텍처를 ADR로 기록해줘, 이전 챕터의 진행상황도 포함하여 합계 정리 라고 요청

• 이후 ADR로 /update-docs에 포함되어 업데이트
• 메모리> 나의 작업 컨텍스트, ADR > 팀의 결정 기록

5.5 5장 가드레일 살펴보기

서브챕터	유형	참조 파일	역할
5.2 탐색/비교	탐색과 비교	decision-guides/ch5/5.2-traffic-management.md	Gateway API 추천 + 대안 비교
5.2 실행	실행	prompt-guardrails/ch5/5.2-gateway-api.md	Gateway + HTTPRoute + HealthCheckPolicy
5.3 탐색/비교	탐색과 비교	decision-guides/ch5/5.3-deployment-strategy.md	Argo Rollouts 추천 + Flagger 비교
5.3 실행	실행	prompt-guardrails/ch5/5.3-bluegreen.md	Rollout CRD 작성 + Blue/Green 전환
5장 마무리	실행	prompt-guardrails/ch5/5.4-adr.md	ADR 신설(이전 장 결정 정리 + 5장 결정 추가) + 도구 변경 의견 응답

• 배포 이후 확인 가능한 문제를 가드레일을 통해 사전 예방 가능
• prompt-guardrails/ch5/5.2-gateway-api.md HealthCheckPolicy 확인 문구를 통해 /health:8080 설정
  • 없었으면 기본값 / 사용 > 모든 백엔드 unhealthy
• prompt-guardrails/ch5/5.3-bluegreen.md deployment.yaml 제거 후 rollout.yaml 적용
  • 없었으면 ArgoCD가 양쪽 모두 배포해 중복 생성 예정