[인프런 복습] 쿠버네티스 어나더클래스(11) - 배포를 시작하기 전에 반드시 알아야 할 것들

공부방

[인프런 복습] 쿠버네티스 어나더클래스(11) - 배포를 시작하기 전에 반드시 알아야 할 것들

터프남 2025. 6. 15. 01:57

728x90

✅ 아래 글의 내용 및 이미지는 인프런 "쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2" 강의를 듣고 정리한 글입니다.

인트로

프로젝트 상황에 따라서 적합한 기술을 쓰는게 더 중요하다!
3단계로 공부할 예정!

CI/CD 파이프라인을 구성할 때 고려해야 하는 요소

배포를 할때는 kubectl로 배포하는 것 말고도 Helm이나 Kustomize라는 툴로도 배포를 할 수가 있다.
kubectl이랑 역할이 같은 k8s 전용 배포 도구라고 생각하면 된다.
Jenkins Pipeline 이라는 것으로도 소스빌드와 컨테이너 빌드 배포까지 한번에 만들 수 있다.
파이프라인이 자동으로 연결되는 식으로 만들 수 있다.
Jenkins Pipeline 을 사용하면 구성을 분리할 필요가 없어 좀 더 깔끔하게 할 수 있다.
그러나 실무에서 일을 하다 보면 기능적인 구분보다 담당하는 사람에 따라서 구성을 분리하는 게 좋을 때도 있다!
이 강의를 듣는 나(개발자)는 배포까지 모두 Jenkins 파이프라인으로 가져가보자.
또한 Jenkins에서 소스빌드랑 컨테이너 빌드까지만 하고 ArgoCD 라는 쿠버네티스 전용 배포 툴을 이용하면 각 쿠버네티스 환경에 배포를 할 수 있다.
이때 배포 툴들은 Jenkins가 아닌 ArgoCD를 통해서 사용하게 된다.
배포 영역을 빌드와 구분해서 많이 쓰이기도 한다.
CI/CD 툴로는 온라인용으로는 Github Actions가 있고 오프라인용으로는 Jenkins와 JenkinsX 그리고 Tekton이 있다.
온라인은 인터넷 환경에 연결해서 쓰기 때문에 별도의 CI/CD 서버를 만들 필요가 없다는 장점이 있다.
오프라인으로 JenkinsX는 Jenkins에서 컨테이너 환경에 맞춰서 새롭게 만든거고 Tekton도 컨테이너 환경에 최적화된 CI/CD를 목적으로 만들어진 도구임.
온라인이든 오프라인이든 본인의 업무환경이나 시스템에 맞춰서 사용하면된다.
CI 전용 툴에는 Travis CI나 GitLab이 있고 CD 전용 툴에는 ArgoCD가 있다.
아마 찾아보면 몇가지 더 나올수도 있지만 레퍼런스가 많은걸 선택하는게 가장 후회가 적다!
필요하다면 오픈소스라면 깃허브 스타 수를 보거나 구글 트렌드에 검색해보는 것이 좋다.
Docker 대체는 왜 나오는 얘기냐면 도커가 무겁다는 이야기랑 데몬이 필요하기 때문이다.
도커는 기능이 많기 때문에 새로 만들지 않는 이상 가벼워지기 힘든 부분이고 그러다보니 자원을 많이 사용한다.
- 컨테이너 빌드를 하는 속도가 느리다는 이야기는 아니다!
컨테이너 빌드로는 Buildah 라는게 있다. (이 부분은 어려움)
쿠버네티스 위에서만 돌아가는 제품도 있다. Kaniko
구글 트렌드를 보면 아직 도커의 대세는 끝나지 않았다.!!

배포 전략을 세울 때 고려해야 하는 요소

Recreate

Recreate는 버전 1이 돌아가고 있는 상태에서 버전 2로 배포를 하려면 기존 파드를 먼저 삭제 시키기 때문에 다운 타임이 발생한다.
버전2의 새로운 파드가 만들어지면서 서비스와 연결이 되면 다시 서비스가 활성화 된다.
k8s의 deployment에서 기능을 제공. deployment만 업데이트 시키면 자동 배포가 된다.

RollingUpdate

롤링 업데이트는 V1이 아직 서비스되고 있는 상태에서 V2를 띄우기 때문에 V1과 V2 파드가 동시에 호출되는 구간이 있다가 V2 파드로 모두 전환이 되는 배포방식이다.
이런 동작을 시키기 위한 배포 작업을 보면 둘다 k8s에서 deployment로 기능을 제공하고 있기 때문에 deployment만 업데이트 시키면 자동 배포가 된다.
배포 중간에 잠깐 정지를 시킨다던가 에러가 나면 롤백이 가능하다.
트래픽에 대한 제어는 불가능하다.
서비스에 연결된 파드들은 라운드로빈 같은 방식으로 트래픽을 골고루 받는다.
롤링 업데이트에는 서비스 중단은 없다.

Blue/Green

블루/그린 배포는 deployment에서 제공해주는 기능이 아니다.
k8s의 지식을 이용해서 배포 동작을 만들어야 한다.
1단계: v2 Deployment 생성
- 새로운 버전(v2)의 파드들을 완전히 별도 환경에서 생성
- 기존 운영 환경(v1)과 동일한 리소스를 복제하여 준비
- 이 시점에서는 아직 트래픽이 v2로 유입되지 않음
2단계: Service Selector 변경
- 쿠버네티스 Service의 selector를 v1에서 v2로 한 번에 완전 전환
- 모든 트래픽이 즉시 새로운 버전으로 라우팅됨
- 순간적인 완전 전환이 핵심 특징
3단계: v1 Deployment 삭제
- 이전 버전의 모든 리소스를 완전히 제거
- 롤백이 필요한 경우를 대비해 일정 시간 유지 후 삭제 가능
특성 및 장단점
- 운영서버에서 QA 테스트 가능
- 수동 배포 시 롤백이 빠름
- Script로 자동 배포 가능
- ⚠️ v2에 과도한 트래픽이 한번에 몰려 서비스에 문제가 생길 수 있음 (콜드스타트 등)
- ⚠️ 트래픽이 전면 전환되기 때문에 v2의 오류가 전체 서비스에 바로 영향을 줌

Canary

1단계: v2 Deployment/Ingress/Service 생성
- 새로운 버전을 소량의 파드로만 배포
- Ingress Controller를 통한 트래픽 분산 설정 준비
- 기존 v1 환경과 병행하여 운영 준비
2단계: v1/v2 Ingress 가중치 변경
- 초기에는 v1(90%) : v2(10%) 비율로 트래픽 분산
- 점진적으로 v2의 비율을 늘려가며 안정성 검증
- 특정 조건(Source IP, User, Language 등)에 따른 세밀한 트래픽 제어
3단계: v1 Deployment/Ingress/Service 삭제
- v2가 완전히 안정화된 후 이전 버전 제거
- 단계적 전환을 통해 리스크 최소화
특성 및 장단점
- 특정 헤더값 기반으로 v2로 트래픽을 유입할 수 있어 A/B 테스트 가능
  - 예: Source IP, User, Language 등에 따라 조건부 유입
- 트래픽 점진 전환 → 안정성 확보에 유리
- 콜드 스타트 방지 가능 (초기 일부만 유입되기 때문에)
- 두 버전(v1, v2) 비교 가능
- ⚠️ 구현 복잡도가 다소 있음 (Ingress, 라우팅 설정 등 필요)
- ⚠️ 완전 자동화하지 않으면 운영 부담 존재

단계별로 구축해보는 배포 파이프라인

여기는 좀 중요한것 같아서 교안을 다 넣어야 될 것 같다.

1단계는 Jenkins 기본 구성을 이용해서 앞 강의에서 구축을 해본 내용이다.
Github에서 릴리즈 파일을 가져오고 실행 순서에 따라서 빌드 배포
실제 실무에서도 프로젝트를 할 때 간단한 파이프라인을 만들어 놓은 다음에 차근차근 업그레이드를 해나가는게 좋다.
첫 파이프라인을 만들 때는 최대한 구성이 복잡해질 만한 툴이나 플러그인을 쓰지말고 직관적인 형태를 목표로 해서 만들어 나가는게 좋다.
2단계는 Jenkins 파이프라인을 사용한다.
젠킨스 파이프라인을 사용하면 좋은점으로는 시각적인 스테이지 뷰를 제공해줘서 전체가 어떻게 흘러가는지 쉽게 파악할 수 있다.
다른 좋은 점은 Jenkinsfile 이라는걸 릴리즈로 관리할 수 있다.
이걸 쓰면 YAML 파일이나 도커 파일처럼 사전에 만들어 놓은 스크립트로 Jenkins 파이프라인을 실행시킬 수가 있다.
단점은 스크립트를 작성하는데 시간이 오래걸린다.
처음부터 스크립트를 만들기 보다는 레벨1 구성을 만들어 놓고 그 구성을 스크립트로 옮기는게 낫다.

레벨 3는 레벨2와 똑같은 구성에 kubectl만 helm이나 kustomize로 바뀌는 부분이다.

Helm 패키지 등장 배경

쿠버네티스 초기 문제점들

복잡한 애플리케이션 배포 시 수십 개의 YAML 매니페스트 파일 관리 필요
환경별(dev/staging/prod) 설정 차이를 수동으로 관리해야 하는 번거로움
애플리케이션 버전 관리와 롤백 프로세스의 복잡성
마이크로서비스 간 의존성 관리의 어려움
설정값 템플릿화와 동적 생성의 한계
애플리케이션 라이프사이클 전체 관리 도구 부재
쿠버네티스 리소스 배포/삭제 과정에서 발생하는 휴먼 에러

Helm으로 편해진 점들

패키지 관리와 배포 자동화

Chart 단위로 관련 리소스들을 하나의 패키지로 묶어서 관리
helm install/upgrade/rollback 단일 명령어로 복잡한 배포 작업 수행
Release 히스토리를 통한 자동 버전 추적 및 쉬운 롤백 기능

템플릿 시스템과 환경별 설정 분리

Go 템플릿 엔진을 활용한 동적 YAML 매니페스트 생성
values.yaml 파일을 통한 환경별 설정값 분리 및 재사용
조건부 리소스 생성과 반복문을 통한 유연한 배포 설정

의존성 관리와 커뮤니티 생태계

Chart.yaml에서 의존성 정의를 통한 자동 의존성 해결
Helm Hub와 ArtifactHub를 통한 공식/커뮤니티 Chart 활용
사전 검증된 베스트 프랙티스가 적용된 Chart 재사용 가능

Helm의 장점

운영 효율성

복잡한 마이크로서비스 아키텍처를 단일 Chart로 관리
CI/CD 파이프라인과의 자연스러운 통합을 통한 자동화
후크(Hook) 시스템을 통한 배포 전후 작업 자동 실행

표준화와 일관성

쿠버네티스 생태계의 사실상 표준 패키지 매니저로 자리매김
Chart 구조의 표준화를 통한 팀 간 일관된 배포 방식
설정 값 검증(validation)을 통한 배포 오류 사전 방지

확장성과 재사용성

템플릿 기반 구조로 다양한 환경과 요구사항에 대한 높은 적응성
서브차트(subchart) 기능을 통한 모듈화된 아키텍처 구성
커뮤니티 기여를 통한 지속적인 Chart 품질 개선

Helm의 단점

학습 곡선과 복잡성

Go 템플릿 문법과 Helm 특화 함수 학습의 필요성
간단한 애플리케이션 배포에는 오히려 오버헤드 발생
Chart 작성과 유지보수를 위한 추가적인 전문 지식 요구

디버깅과 트러블슈팅

템플릿 렌더링 결과 확인과 오류 추적의 어려움
복잡한 의존성 체인에서 발생하는 문제 분석의 복잡성
values.yaml 우선순위와 머지 로직 이해의 필요성

운영상 제약사항

Release 상태 정보 관리와 동기화 이슈 가능성
네임스페이스와 Chart 간의 복잡한 관계 설정
Helm 2의 Tiller 컴포넌트 보안 취약점 (Helm 3에서 해결)
Chart 업그레이드 시 발생할 수 있는 예상치 못한 리소스 변경

GPT로 알려달라고했음..!

레벨 4단계로 ArgoCD를 써서 배포를 분리한다.
CI/CD 환경에서는 빌드까지만 있고 k8s의 인프라 환경에 ArgoCD를 설치하고 내부적으로는 Helm 패키지가 사용되기 때문에 Helm 패키지를 가지고와서 배포를 하게 된다.
배포는 릴리즈 파일(Helm패키지나 도커파일 등) 을 수정하는게 배포 행위가 된다.
첫 배포가 된 이후에 ArgoCD는 깃허브에 있는 형상관리 파일이랑 실제 k8s에 배포한 yaml 파일들에 대해서 동기화를 시켜 놓는다.
그래서 깃허브의 패키지가 수정이 되면 자동으로 k8s의 리소스를 변경시켜주고 반대로 k8s의 리소스 옵션을 직접 변경하면 깃허브에 내용을 업데이트 해준다.
ArgoCD가 k8s와 릴리즈 파일 사이에서 계속 sync를 맞춰준다.
계속해서 sync를 맞춰주는게 큰 장점이고 또 하나의 장점으로는 k8s 리소스를 편하게 볼 수 있는 UI를 제공해준다. (한마디로 GUI가 좋다!)

출처

https://inf.run/Uf4oi

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 | 일프로 - 인프런

일프로 | ⚓쿠버네티스(Kuberentes, Containerd, Docker Hub, Helm, Jenkins, Kustomize, ArgoCD) 🙇‍♀️아직 망설이시나요? 🙋‍♂️저만 믿고 따라오세요! 이론과 실습으로 당신의 실력을 ⭐어나더 레벨로 만

www.inflearn.com

728x90

저작자표시 (새창열림)