[K8S] 배포를 하기전에 알아야 할 것들

CI/CD 파이프라인 구성시 고려해야 할 요소

이전 포스팅에서는 kubectl 명령어를 사용하여 Kubernetes 클러스터에 직접 배포하는 방식으로 구성하였습니다. 하지만 실제 환경에서는 Helm, Kustomize와 같은 도구를 활용하여 보다 유연하고 효율적인 배포가 가능합니다. 또한, 이전에는 소스 빌드, 컨테이너 이미지 빌드, Kubernetes 배포를 각각 개별 Jenkins Item으로 나누어 구성하였습니다. 이러한 방식은 각 단계별로 담당자가 분리되어 있거나, 실패 원인 추적이 필요한 경우에 효과적입니다.

 

반면, 모든 단계를 하나의 Jenkins Pipeline으로 통합하여 구성하면 전 과정이 일관된 흐름으로 자동화되어 효율적인 배포가 가능하다는 장점이 있습니다. 따라서 실제 프로젝트에서는 조직의 운영 방식, 협업 구조, 서비스 복잡도 등을 고려하여 적절한 방식으로 CI/CD 파이프라인을 구성하는 것이 중요합니다.

 

또한 ArgoCD를 활용하여 개발환경과 운영환경을 동시에 배포하는 방식도 고려할 수 있습니다.

• 단일 ArgoCD 인스턴스 구성: 관리 효율성이 높고 운영 포인트가 단순해지지만, ArgoCD 자체 장애 시 두 환경 모두에 영향을 줄 수 있습니다.
• 개별 ArgoCD 인스턴스 구성: 환경별로 배포 정책과 책임을 분리할 수 있어, 장애 영향도를 최소화할 수 있습니다.

운영 안정성과 유지보수 전략에 따라 적절한 구성을 선택해야 합니다.

 

운영 안정성과 유지보수 전략에 따라, 단일 또는 이중 구성 중 어떤 방식이 적절한지 선택하는 것이 중요합니다.

 

CI/CD 도구 선택 시 고려사항

CI/CD 도구는 Jenkins 외에도 GitHub Actions, Travis CI 등 다양한 선택지가 존재합니다.

• GitHub Actions: 클라우드 기반 도구로 GitHub 저장소와 통합되어 있으며, 서버 설치 없이 빠르게 CI/CD 구성이 가능합니다.
• Jenkins: 온프레미스 환경에 적합하며, 보안이 중요한 내부망 환경에서도 사용할 수 있습니다.
• ArgoCD: GitOps 방식의 CD 도구로, 오프라인 환경에서도 사용 가능합니다.
• Travis CI: GitHub Actions와 마찬가지로 온라인 도구로, 민감한 환경에는 적합하지 않을 수 있습니다.

CI/CD 도구를 선택할 때는 운영 환경이 온라인인지 오프라인인지, 보안 요구사항이 어떤지 등을 충분히 고려해야 합니다.

 

배포 전략

1. Recreate

• 기존 Pod를 완전히 종료한 후, 새로운 버전을 배포합니다.
• 서비스 중단(Downtime)이 발생할 수 있습니다.
• 트래픽을 제어할 수 없습니다.
• Jenkins나 kubectl로 자동화 배포가 가능합니다.
• 대표 유스케이스: DB 스키마 변경처럼 서비스 중단이 불가피한 작업

2. RollingUpdate

• 기존 Pod(v1)과 신규 Pod(v2)를 순차적으로 교체합니다.
• 서비스 중단 없이 배포됩니다.
• 트래픽은 v1과 v2에 동시에 분산됩니다.
• 기본적으로 Kubernetes Deployment에서 제공하는 방식입니다.

3. Blue-Green

• v1과 v2 두 개의 Deployment를 별도로 생성합니다.
• 서비스 객체(Service)의 selector를 변경하여 트래픽을 전환합니다.
• 롤백이 매우 빠릅니다 (서비스 selector만 다시 돌리면 됨).
• 스크립트로 자동화가 가능합니다.
• 하지만v2로 전환 시 과도한 트래픽이 몰릴 수 있습니다.

4. Canary

• v1과 v2 버전을 동시에 일부만 배포하고, 점차 트래픽을 v2에 몰아줍니다.
• A/B 테스트 또는 실험군 테스트에 적합합니다.
• 트래픽 제어는 주로 Ingress Controller(Nginx, Istio 등)를 사용합니다.
• 콜드 스타트 문제도 방지할 수 있습니다. 

각 배포 전략은 상황에 따라 장단점이 분명하므로, 서비스 특성과 요구사항에 따라 적절한 방식을 선택하는 것이 중요합니다.

 

CI/CD 파이프라인 단계별 구성 전략

인프런 - 쿠버네티스 어나더 클래스

Level 1: Jenkins 기본 구성

• Jenkins UI를 통해 각각의 Job을 생성
• 순차적으로 소스 빌드 → 컨테이너 빌드 → 배포(kubectl) 수행
• YAML과 Dockerfile만 있으면 구성 가능

Level 2: Jenkins Pipeline 사용

• Jenkinsfile을 작성하여 스크립트 기반 파이프라인 구성
• 빌드 로직과 설정을 코드로 관리할 수 있어 변경 이력 추적 용이
• Jenkins UI 대신 코드 기반 구성으로 확장성 향상

Level 3: Helm / Kustomize 활용

• kubectl 대신 Helm이나 Kustomize를 활용하여 배포
• 리소스 구성과 배포를 YAML 패키지로 동적으로 관리 가능
• 복잡한 배포 구조도 명확하게 유지 가능

Level 4: ArgoCD 분리 배포

• CI 파이프라인과 CD 파이프라인을 분리
• Jenkins는 빌드만, ArgoCD는 배포 전담 (GitOps 방식)
• Git 저장소 변경을 감지하여 자동으로 K8s에 배포 (Sync)
• UI 제공, Canary/Blue-Green 전략도 간편하게 적용 가능

이러한 방식으로 단계적으로 구성하는 이유는 각 단계의 역할과 구조를 명확히 이해하고, 시스템 안정성을 확보한 후 다음 단계로 확장하기 위해서입니다.