서론

해당 글은 일프로 님의 인프런 강의 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2의 내용을 정리한 글입니다.

해당 글에 사용된 내용, 사진 및 그림은 모두 강의와 강의 자료에 포함된 내용입니다.

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

• 관리 담당
  • 기능과 관리적인 측면을 고려해 어떤 부분을 중시하는 것이 효율적인지 고려해 선택
  • 관리적인 측면을 중시할 경우
    • jenkins 프로젝트를 freestyle로 분리하고 각 담당자가 해당 freestyle 프로젝트를 관리하도록 처리
      • 트리거를 통해 파이프라인 처리 가능
      • 업무 분장 및 관리 책임면에서 더 효율적
  • 기능적인 측면을 중시할 경우
    • jenkins 프로젝트를 pipeline으로 통합
      • freestyle보다 기능적으로 뛰어남
• 운영 정책
  • 관리 편의와 장애 영향도를 고려해 배포와 인프라 환경을 단일로 진행할지, 분리해 진행할지 선택
  • 단일로 진행하는 경우
    • jenkins에서 모든 과정 진행
  • 분리해 진행하는 경우
    • jenkins + ArgoCD와 같은 쿠버네티스 전용 툴 사용
      • 배포와 인프라 환경을 분리했으므로 배포와 인프라 환경의 관계를 필요에 따라 설정할 수 있음
        • 배포와 인프라 환경의 관계를 1:1로 하는 경우
          • 하나만 관리하므로 관리 포인트가 적음
          • 장애 발생 시 영향을 많이 받음
        • 배포와 인프라 환경의 관계를 1:N으로 하는 경우
          • 이중 관리가 필요하므로 관리 포인트가 많아짐
          • 장애 발생 시 장애가 전파되지 않음
• 제품 선정
  • 시스템에서 사용할 데이터 보안, 선정할 툴의 레퍼런스, 유지보수를 할 수 있는 업체가 있는지 등을 환경에 맞게 선택
    • 온라인
      • 별도의 CI/CD 서버를 구축할 필요 없음
      • Github와 같은 글로벌한 툴은 보안 처리가 잘 되어 있음
    • 오프라인
      • 별도의 CI/CD 서버를 구축해야 함
      • 시스템에서 다루는 데이터가 중요해 인터넷 영역에 데이터를 업로드해서는 안 되는 경우에 사용
• 컨테이너 빌드 툴 - 도커 대체
  • 도커는 무겁고 Daemon이 필요함
    • kubectl과 같은 Daemonless와 다름
  • 도커 Daemon이 죽으면 다른 컨테이너도 모두 죽는다는 문제가 발생할 수 있음
    • 빌드에서만 도커를 사용한다면 이러한 문제를 최소화할 수 있음
    • 단 이러한 문제가 시스템이 치명적이라면 다른 솔루션 사용
  • 여전히 도커는 트렌드가 유지되고 있으며, 레퍼런스가 가장 풍부

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

• Recreate
  • 동작 방식
    • 이전 버전을 삭제하고 새로운 버전의 파드를 생성
  • 배포 작업
    • Deployment 업데이트
  • 유즈 케이스
    • 데이터베이스 스키마 변경 시
  • 특징
    • 다운타임 발생
    • 자동 배포
    • 트래픽 제어 불가
• RollingUpdate
  • 동작 방식
    • 이전 버전이 서비스되고 있는 상황에서 새로운 버전을 실행
  • 배포 작업
    • Deployment 업데이트
  • 특징
    • 이전 버전과 새로운 버전이 동시에 호출되는 시점 존재
    • 자동 배포
    • 트래픽 제어 불가
    • 서비스 중단 없음
• Blue/Green
  • 동작 방식
    • 기존 서비스와 파드는 셀렉터를 통해 v1로 연결된 상태
    • 새로운 버전에 해당하는 Deployment(= v2) 생성
    • v2 파드 생성
    • v2 파드가 모두 기동이 완료된 경우 서비스를 v2와 연결
  • 배포 작업
    • v2 Deployment 생성
    • 서비스 셀렉터 변경
    • v1 Deployment 삭제
  • 유즈 케이스
    • 운영에서만 테스트 가능한 경우
      • QA 담당자가 직접 운영 DB와 연동해 테스트하는 방식
  • 특징
    • 수동 배포 시 롤백이 빠름
    • 스크립트를 통해 자동 배포 가능
    • v2에 과도한 트래픽 유입시 문제 발생
• Canary
  • 동작 방식
    • 기존 서비스와 파드는 셀렉터를 통해 v1로 연결된 상태
    • 새로운 버전에 해당하는 Deployment와 서비스(= v2) 생성
    • Ingress Controller인 nginx와 각 서비스에 Ingress 리소스 생성
    • Ingress 가중치를 통해 트래픽 제어 가능
    • v2로 트래픽 전환이 완료된 경우 v1 관련 리소스 삭제
  • 배포 작업
    • v2 Deployment/Ingerss/Service 생성
    • v1 / v2 Ingress 가중치 변경
      • v2에 일부 트래픽만 전달해 Blue/Green처럼 급진적인 배포가 아닌 점진적인 배포 가능
    • V1 Deployment/Ingress/Service 삭제
  • 유즈 케이스
    • 특정 헤더 값에 한해 v2로 트래픽을 유입시킬 수 있는 경우
  • 특징
    • 콜드 스타트 방지
    • 두 버전 비교 가능 (A/B 테스트)

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

• Level 1 : Jenkins 기본 구성
  • 만들고자 하는 파이프라인을 가장 직관적으로 만들 수 있음
• Level 2 : Jenkins Pipeline 사용
  • 하나의 구성으로 빌드 배포 구성 완료
  • 시각적인 UI를 통해 전체 파이프라인 상황 파악 가능
  • jenkinsfile 형상 관리
• Level 3 : Kustomize, Helm 배포
  • Level 2에서 kubectl -> kustomize, Yaml -> Helm으로 변경
  • 패키지를 가져오므로 yaml 파일을 동적으로 구성할 수 있음
• Level 4 : ArgoCD 배포 분리
  • CI/CD 환경에서는 빌드만 수행
  • ArgoCD에서 배포 수행
    • 쿠버네티스와 릴리즈 파일의 싱크를 맞춰 배포 수행

Helm 특징

• 이전
  • A App에서 사용하고 있는 애플리케이션에 MSA를 적용하는 경우 yaml을 복사해서 네이밍만 변경
  • 애플리케이션 실행 환경에 따라 그에 맞는 yaml을 만들기 위해 복사
  • 서비스의 옵션을 변경하면 전체 yaml을 변경해야 하는 경우 발생
• 패키지를 동적으로 조회하는 경우(Helm)
  • yaml의 값을 동적인 변수로 처리해 배포 시 값 세팅
  • 서비스의 옵션을 간단하게 변경할 수 있으며 실수를 방지할 수 있음