(11) 배포를 시작하기 전에 반드시 알아야 할 것들

⚓ 쿠버네티스 어나더 클래스 (지상편) - Spring 1, 2 을 듣고 작성하는 복습 블로그 입니다.

 

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

1-1. 관리 담당

• 빌드 / 배포
• (AS-IS) 1. 소스 빌드 → 2. 컨테이너 빌드 → 3. 배포
  • 각각 담당하는 담당자가 있는 경우에는 이렇게 사용해도 좋다
  • 관리 담당자별로 나누는게 업무 분장이나 관리 책임에서 더 좋음
• (TO-BE) 젠킨스 파이프라인 (소스 빌드 → 컨테이너 빌드 → 배포)

→ 관리담당에 따라 업무 분장, 관리 책임을 고려해서 선택 (관리 vs 기능)

 

 

1-2. 운영 정책

젠킨스 빌드 (소스, 컨테이너) → ArgoCD 배포 (kubectl, HELM, Kustomize) → 인프라 환경

배포와 인프라 환경의 관계

• 1:N 으로 구축
  • 👍 장점 : 하나만 관리
  • 👎 단점 : 장애시 영향도 높음
• 1:1 으로 구축
  • 이 방식을 더 많이 사용
  • 👍 장점 : 장애시 영향도 없음
  • 👎 단점 : 이중 관리 필요

→ 운영 정책에 따라 관리 편의, 장애 영향도를 고려해 선택 (단일 vs 분리)

 

 

1-3. 제품 선정

	CI/CD Tool	CI Tool	CD Tool
온라인	GitHub Actions	Travis CI, circleci
오프라인	Jenkins, JenkinsX, TEKTON (컨테이너 환경 최적화)	GitLab	argo, Spinnaker

 

→ 제품 선정에 있어서 데이터 보안, 레퍼런스, 유지보수 업체를 고려해 선택

 

1-4. Docker 대체

단점 : 무거움, Daemon 필요

 

(1) buildah

• 빌드
  • 소스 빌드 (gradle)
  • 컨테이너 빌드 (buildah)
    • dockerhub → buildah (podman) : image pull, login
    • buildah → dockerhub (skopeo) : image push
• 배포 (argocd)
• 쿠버네티스

(2) Kaniko

• 쿠버네티스 위에서만 돌아가는 제품
• 하나만 있으면 된다

→ Docker 보다 자원사용률이 낮다

---

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

 

	Recreate	RollingUpdate	Blue/Green	Canary
배포 방식	• v1 이 있는 상태에서 v2 로 배포하려면 기존 Pod 를 삭제시키기 때문에 다운타임 발생 • v2 버전의 새로운 Pod 가 만들어지면서 Service 와 연결되면 Service 가 다시 활성화	• v1 이 서비스되는 상태에서 v2를 띄운다 • v1, v2 Pod 동시 호출 발생	• 배포할 v2 Deployment 랑 Pod 를 모두 세팅 • Service 의 Selector 를 변경해서 트래픽 제어	• Ingress Controller 랑 Ingress 사용 • Ingress 에서 트래픽 양 조절 가능 • 그 외에는 Blue/Green 과 동일
배포 작업	1. Deployment 업데이트	1. Deployment 업데이트	1. v2 Deployment 생성 2. Service Selector 변경 3. v1 Deployment 삭제	1. v2 Deployment/Ingress/Service 생성 2. v1 / v2 Ingress 가중치 변경 3. v1 Deployment/Ingress/Service 삭제
유즈 케이스	데이터 베이스 스키마 변경시 1. 서비스 중단 공지 2. Deployment Replica 0 으로 변경 3. DB 작업 4. Deployment 태그 변경 및 Replica 2로 수정		운영에서만 테스트 가능한 경우	특정 헤더 값에 한해서만 v2로 트래픽 유입 (Source IP, User, Language)
특징	• 자동 배포 (정지, 롤백 가능) • 트래픽 제어 불가	• 자동 배포 (정지, 롤백 가능) • 트래픽 제어 불가 • 서비스 중단 없음	• 수동 배포 시 롤백이 빠름 • Script 를 통해 자동 배포 가능 • v2에 과도한 트래픽 유입시 문제 발생	• 콜드 스타트 방지, 두 버전 비교 가능 • A/B 테스트 : 배포 전략 (x), Canary 배포 상황에서 v1과 v2를 비교하기 위한 테스트 방법론
배포 툴	kubectl, HELM, Kustomize		Jenkins Script + kubectl, argocd	argocd, nginx, istio

---

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

Level 1. Jenkins 기본 구성

 

• GitHub 에서 릴리즈 파일 가져오기 (Yaml, Dockerfile)
• 실행순서 : 소스 빌드 → 컨테이너 빌드 → 배포
• Jenkins 를 통해 직관적으로 만들 수 있다

 

 

 

 

 

 

 

 

 

Level 2. Jenkins Pipeline 사용

 

• 소스 빌드 → 컨테이너 빌드 → 배포가 하나로 연결
• 한 번만 실행하면 된다
• 시각적인 Stage View 제공
• Jekinsfile 을 릴리즈로 관리 가능
• Script 로 Jenkins 파이프라인 구성
• 하지만, 처음 작성한다면 Script 작성하는데 오래 걸린다

 

 

 

 

 

 

 

Level 3. Kustomize, Helm 배포

 

• Level 2와 동일한 구성
• 배포의 kubectl → Kustomize 로 변경
• 릴리즈의 Yaml → Kustomize, HELM Package 로 변경
• Package 를 사용하면 Yaml 파일을 동적 구성 가능

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[Yaml 파일 동적 구성]

• A App 을 만들기 위해서 Service Yaml, Pod Yaml, CM Yaml 을 사용
• 마이크로 서비스를 위해 B App, C App, D App 도 만들어야 하는 상황
• 이런 경우 A App 의 Yaml 을 복사해서 1. 네이밍 변경 2. env 수정
• Script 는 복사 가능하기 때문에 늘리는 작업은 쉽다
• App 을 늘리기는 쉽지만 일일히 복사해서 수정하는 건 귀찮다
• 서비스의 옵션 하나만 변경해도 전체 서비스의 옵션도 변경해줘야 한다

→ 이런 것들 때문에 HELM 이 나오게 됨

 

[HELM 동작 방식]

1. HELM 템플릿을 만들고 {값} 으로 뚫어둔다
2. Helm 배포 명령을 할 때 값을 넣어서 보낸다
3. 배포 명령 시 넣은 값에 따라서 Script 가 생성

 

Level 4. ArgoCD 배포 분리

• 쿠버네티스 인프라 환경에 ArgoCD 설치
• 내부적으론 HELM 패키지 사용
• GitHub 에서 HELM 패키지를 가져와서 배포
• 배포 순서
  1. 젠킨스 파이프라인 실행 (소스/컨테이너 빌드)
  2. 릴리즈 파일을 수정하는게 배포 행위
     • 첫 배포가 된 이후 ArgoCD 가 GitHub 에 있는 형상관리 파일이랑 실제 쿠버네티스에 배포한 Yaml 파일들에 대해서 동기화
     • 깃허브 패키지 수정 → 쿠버네티스 리소스 변경
     • 쿠버네티스 리소스 옵션 변경 → 깃허브 내용 업데이트
     • 깃허브와 쿠버네티스 사이에서 Sync 를 맞춰준다
• 쿠버네티스 리소스 UI 제공
• 배포 기능 제공 : Blue/Green, Canary

 

 

 

 

 

 

 

 

이미지 출처 URL : https://inf.run/k7mF