.

Data_engineering_TIL(20211205)

[학습자료]

“클라우드 네이티브를 위한 쿠버네티스 실전 프로젝트” 책을 읽고 정리한 내용입니다.

• 동양북스, 아이자와 고지&사토 가즈히코 지음, 박상욱 옮김

참고자료 URL : https://github.com/dybooksIT/k8s-aws-book

“Gitops 기본개념”에 이어서 공부한 내용을 정리한 내용임

• URL : https://minman2115.github.io/DE_TIL312

[학습내용]

애플리케이션이나 환경마다 클러스터를 나누어야 할까?

어플리케이션을 바로 서비스 환경에서 배포하는 일은 없을 것이다. 일반적으로는 개발환경에서 테스트를 진행하고, 스테이징 환경에서 최종 점검하여 문제가 없는 경우 서비스 환경에 배포한다. 쿠버네티스로의 배포도 마찬가지다. 브랜치 각각에 맞는 환경을 준비해두고 해당 브랜치에 푸쉬되는 시점에 해당 환경에 배포되도록 파이프라인을 구성하는 것이 바람직하다. 그런데 여기서 말하는 ‘환경’은 클러스터일수도 있고, 네임스페이스 일수도 있다. 다시말해서 특정 단위로 클러스터를 나누는 문제는 어려운 문제이다. 큰 클러스터를 구성해 여러 서비스와 환경을 공통으로 사용하는 경우 네임스페이스를 나누어서 운영하게 된다. 이 경우 리소스를 효율적으로 사용할 수 있지만 클러스터에 장애가 발생하면 모든 서비스가 올스탑된다.

위와 같은 구조일때의 장점

• 리소스를 하나만 사용한다는 점에서 효율성이 좋다.

• 클러스터 운영, 관리, 버전 업데이트 관점에서 편리하다.

위와 같은 구조일때 단점

• 클러스터에 장애가 발생하면 모든 서비스에 영향이 있다.

반면에 아래와 같이 환경마다 클러스터를 분리하면 클러스터 장애가 발생했을때 영향을 제한할 수 있지만 리소스 사용 효율성이 떨어지고 클러스터 별로 관리해야 한다는 부담이 있다.

위와 같은 구조일때의 장점

• 환경마다 클러스터를 나누기 때문에 클러스터별 설정이 단순해질 수 있다.

• 클러스터에 장애가 발생했을때 영향 범위를 제한할 수 있다.

위와 같은 구조일때 단점

• 클러스터별로 운영, 관리, 버전 업데이트 등이 필요하기 때문에 번거로워진다.

결론적으로 어떤 조건으로 클러스터를 나눌지는 쿠버네티스를 사용하는 조직체계나 여건 등 종합적으로 판단해서 결정하면 된다.