- Published on
쿠버네티스를 사용하는 이유
- Authors
- Name
- zkrp
안녕하세요!! 다름이 아니라 제 미니서버에 Kubernetes를 도입했는데 왜 도입하고 사용하게 됐는지 설명할겸 글을 작성하려합니다.
일단 설명하기전에 제가 어떤 환경에서 운영했는지 말하겠습니다.
1. 나의 환경
하드웨어: eqr6 32GB , Ser7 64GB
OS : Ubuntu 22.04
사용했던 솔루션: Docker
저 환경에서 Docker 를 사용하면서 불편했던 점이 여러가지 있었습니다.
불편했던점을 나열하자면
2. Docker 환경에서 느낀 불편함
2-1) 도메인 연결 불편함
첫 번째 이유는 도메인을 연결하기 불편했다는 점입니다. 도커 컨테이너는 도메인을 인식하거나 자동으로 외부 도메인에 연결되는 기능은 없어서 서버의 IP에 포트를 매핑한 뒤, 도메인과 IP를 연결하는 작업을 해줘야합니다.
또한 매번 포트 번호를 직접 명시를 해야하니 번거로웠습니다.
2-2) 컨테이너 버전업 시 수동 관리
개발을 할때마다 늘 이미지 버전이 올라가는데 컨테이너를 운영할때는 수동으로 버전 관리가 필요해서 불편함을 느꼈습니다.
ex) 새 이미지 푸시 후, 기존 컨테이너를 stop하고 새 컨테이너를 run을 하여 직접 관리
2-3) 서비스 확장/축소 어려움
여러 서비스를 운영할 때 수동으로 컨테이너 갯수를 조절하여 운영부담이 컸습니다.
2-4) 멀티 서버 고려
서버가 2대가 되면 Docker로도 멀티 서버 구성이 가능합니다.
예를 들어, 각 서버에 컨테이너를 배포하고 Nginx나 HAProxy로 로드밸런싱을 구현할 수 있습니다.
또는 Docker Swarm을 활용해 클러스터를 구성할 수도 있습니다.
하지만 이런 방식은 여전히 한계가 있습니다.
- 노드가 추가되거나 빠질 때마다 로드밸런서 설정을 직접 수정해야합니다.
- 서버와 컨테이너 상태를 지속적으로 모니터링해야합니다.
결국 멀티 서버 환경이 되더라도, 운영의 복잡성은 크게 줄어들지 않는다는 것을 느꼈습니다.
Kubernetes는 위에 언급한 불편한점을 다 해결한다는것을 알게 되어서 Kubernetes를 도입하기로 했습니다.
3. Kubernetes 의 장점
Kubernetes는 서비스 관리 자동화, 네트워크 라우팅*, 확장성 등 다양한 기능을 통해 _Docker* 단독 운용에서 겪었던 불편함을 모두 해소할 수 있습니다
어떻게 해결할수 있는지 설명하겠습니다.
3-1) 도메인 연결 간소화
쿠버네티스는 Ingress Controller 를 사용하면, 서비스별 도메인을 쉽게 연결할수 있습니다.
- 포트를 일일이 입력할 필요 없이, example.com과 같이 도메인만으로 접속이 가능합니다. 또한 yaml 파일로 경로 기반 라우팅 지원을 할 수 있습니다.
ingress에대해 궁금하시다면 밑에 링크 참고해주세요!
3-2) 컨테이너 자동 버전 관리
Deployment 설정을 변경하면 쿠버네티스가 업데이트 진행을 할수 있습니다.
또한 CI/CD 파이프라인과 연동 하면 Deployment 설정이 자동으로 변경 되어 직접 관리해야한다는 번거로움이 사라집니다.
CI/CD에 대해 궁금하시다면 밑에 링크 참고해주세요!
3-3) 서비스 확장/ 축소 자동화
쿠버네티스는 Horizontal Pod Autoscaler(HPA)는 CPU, 메모리 사용률 등의 지표를 기반으로 부하에 따라 자동으로 파드 수를 늘리거나 줄여줍니다.
3-4) 멀티 서버 관리 유용
Kubernetes는 여러 대의 서버를 하나의 클러스터로 묶어_, 마스터 노드에서 전체 워커 노드를 중앙집중적으로 관리할 수 있습니다.
이러한 장점들을 이용해서 저는 실제 서비스를 운영할때 Kubernetes를 장점을 극대화 하여 실제 서비스 운영 환경에 적용하였습니다.
4. 실제 도입
Kubernetes를 실제로 도입하기 위해서는 밑에 링크를 참고하시면 도움이 될거같습니다.
https://montkim.com/homeserver-clustering
저는 실제로 서버2대를 하나의 클러스터로 묶어서 마스터 노드와 워커 노드를 구성하였습니다.
마스터 노드에는 Ingress Controller 를 이용해 서비스별 도메인 연결, 라우팅 연결 관리를 해놓고 워커노드에는 제 실질적인 프로젝트에 필요한 Mysql, SpringBoot ,ES 로 배치를 했습니다.
워커노드와 마스터 노드를 분리하면서 다음과 같은 장점을 얻었습니다.
- 고가용성 및 안정성
마스터노드와 워커노드 분리를 통해, 서비스 장애 시 마스터에서 상태를 제어하거나 자동 복구가 수월해졌습니다. - 리소스 효율화
워커노드에 필요한 서비스만 집중 배포함으로써, 하드웨어 자원을 효율적으로 사용할 수 있게 되었습니다. - 배포 및 확장 유연성
Ingress를 통한 경로/도메인 기반 라우팅 설정이 간소화되어, 새로운 서비스 추가나 확장 시 yaml 파일 한 번만 수정하면 되었기에 관리가 매우 편리해졌습니다. - 중앙 집중 관리
클러스터 단위로 모든 노드와 서비스를 제어할 수 있어 운영 부담이 크게 줄었습니다.
5. 회고
솔직하게 말하자면 저처럼 소규모 프로젝트를 운영한다면 Kubernetes가 다소 오버엔지니어링이라는 것을 알고 있습니다.
하지만 인프라 경험(스케일 아웃, 실무 인프라 구성, 장애 대응)과 같은 경험을 직접 해보고 싶어서 Kubernetes를 선택한것도 있습니다.
비록 규모에 비해 큰 시스템일 수 있지만, 이번 구축 과정을 통해 많은 인프라 지식과 운영 노하우를 쌓을 수 있었습니다.
읽어주셔서 감사합니다!