[Kubernetes Best Practice] 5. 지속적 통합, 테스트, 배포

이 글은 Kubernetes Best Practice를 읽고 개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다. 모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다. 

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

컨테이너 이미지 경량화

이미지를 빌드할 때 이미지의 크기를 최적화하기 위한 고려가 필요합니다. 이미지의 크기가 작을수록 registry에서 다운 받는 시간이 감소하어 배포 과정에서 소요되는 시간이 줄어들뿐만 아니라 불필요한 패키지를 포함시키지 않게되어 보안적인 부분도 강화될 수 있습니다. 이미지 크기를 최적화하기 위해서는 다음과 같은 요소들을 고려해야합니다.

• Multistage Build
  이미지 빌드 과정을 여러 단계로 정의해서 어플리케이션을 실행할 때 필요한 파일이 아닌 빌드 단계와 같이 이전 과정에서 필요한 도구들을 제거하고 이를 통해 이미지를 경량화할 수 있습니다. 자세한 내용은 공식문서에서 확인이 가능합니다.
• Distroless Image
  일반적인 배포한 리눅스에서 제공되는 패키지 매니저, 쉘이 존재하지 않는 이미지를 사용함으로써 이미지의 경량화뿐만 아니라 CVE와 같은 보안 문제에도 대응이 가능합니다. 하지만 디버깅 난이도가 증가한다는 단점도 존재합니다.
• 최적화 이미지
  Alpine 리눅스와 같이 디버깅을 위한 최소한의 도구들을 제공하는 이미지입니다. 이 역시 이미지를 경량화 시키며 불필요한 패키지이 없기 때문에 보안 위험도 낮출 수 있습니다.

---

컨테이너 이미지 태그

CI 단계에서 소스코드가 커밋되면 테스트를 수행한 후에 CD를 진행하기 위한 도커 이미지 빌드 과정이 존재합니다. 이 때 이미지의 버전을 쉽게 식별하기 위해 적절한 이미지 태그 전략을 수립해야 합니다. 가장 중요한 점은 latest 태그를 사용하지 않아야 한다는 점입니다. latest를 사용하게 되면 새로운 버전이 어떤 부분이 수정된 버전인지 파악하기 어렵고, 롤백 오류를 발생할 가능성도 존재합니다.

일반적으로 다음과 같은 태그 전략을 사용합니다.

• (빌드 시스템)-BuildID
• Commit Hash

---

배포

컨테이너 이미지는 불변 객체로 다루어지기 떄문에 변경 사항을 배포함에 있어 환경의 불일치로 발생하는 문제를 줄일 수 있습니다. 컨테이너를 배포하는 전략으로 다양한 전략이 존재합니다.

• RollingUpdate
  Pod을 점진적으로 새로운 버전으로 교체함으로써 업데이트가 서비스 중단 없이 이루어질 수 있도록 해줍니다. 또한, maxSurge나 maxUnavailable과 같은 옵션을 통해 한 번에 업데이트 할 최대 레플리카 수, 업데이트 사용할 수 없는 최대 레플리카 수 등을 제어할 수 있습니다.
  
  만약 클라이언트가 이번에 업데이트 대상으로 선택된 Pod에 접근하여 통신하는 경우, 연결이 비정상적으로 끊어지거나 아직 준비가 되지 않은 새로운 Pod에 연결될 가능성이 존재합니다. 이를 방지하기 위해 readinessProbe를 통해 새로 배포된 Pod이 서비스를 제공할 준비가 됐는지 확인해야 하고, preStop hook을 통해 현재 종료되는 Pod의 연결을 끊는 작업을 보장해야 합니다.
  
  롤링 업데이트를 진행하면서 또 한가지 고려할 점은 2가지 버전이 동시에 수행되기 떄문에 DB 스키마는 2가지 버전을 모두 지원해야 한다는 점입니다. 
  
  
• Blue/Green
  새로운 버전을 모두 배포한 이후, 원하는 시점에 기존 트래픽을 중단하고 새로운 버전으로 트래픽을 전송하는 방법입니다. 이는 트래픽이 변경되는 시점을 통제할 수 있기 때문에 새로운 버전에 트래픽을 보내기 전까지 발생하는 오류를 추적하기 용이합니다. 또한 기존 버전으로 롤백도 용이하다는 장점이 존재합니다. 하지만, 기존 버전/ 새로운 버전에 대한 컨테이너가 모두 떠있어야 하기 때문에 용량 측면에서 부담이 될 수 있습니다.
  
  
• Canary
  카나리 배포는 블루 그린 배포와 유사하지만 트래픽을 조절한다는 점에 대해서 차이가 있습니다. 특정 유저층이나 특정 서버에만 새로운 버전을 배포함으로써 정상 동작을 테스트하고, 테스트가 완료되면 점차 트래픽 비율을 높이는 방식으로 배포가 진행됩니다. 이를 달성하기 위해서는 인그레스를 통해 트래픽을 보다 세밀하게 제어할 수 있는 기능이 존재해야합니다.

---

Chaos Engineering

카오스 엔지니어링은 실제 운영 시스템에 테스트를 수행해서 취약점을 발견하는 방법입니다. 일반적으로 다음과 같은 방법을 사용합니다.

• 가설을 세우고 안정된 상태 파악
• 시스템에 영향을 주는 이벤트 수집
• 통제 그룹 구축 후 안정된 상태와 비교
• 실험을 수행해 가설 검증

 

---

CI/CD 모범 사례

• CI를 통한 자동화와 빌드 속도 최적화를 달성해야 한다. 빌드 속도 최적화는 빠른 피드백과 이를 통한 생산성 향상을 이룰 수 있다.
• 컨테이너 이미지 최적화 수행
• CD 과정에서 클라이언트 연결과 DB 스키마가 어떻게 처리되는지 반드시 테스트 할 것