Kubernetes(쿠버네티스)를 공부하게 되다.
이렇게 개발에 대한 지식도 점차 넓혀갑니다.
각 분야의 전문성을 가장 크게 실감하게 되는 때는 바로 업계에서 사용되는 전문 '용어'를 접할 때일 것입니다. 저 같은 경우 IT 업계에 대해 알게 되는 과정에서 '쿠버네티스'라는 단어가 특히 그랬습니다. 반쯤 IT 업계에 발을 들이고 있다고 여겨졌을 즈음, 이 단어를 알게 되었으나 꽤나 개발자들의 영역이라 생각되기도 했고 생소한 만큼 괜히 어렵게 느껴지기도 했습니다.
그런데 이제 제대로 IT 업계에 발을 들이게 되었다고 느끼게 된 지금, 저는 카페에서 이 단어를 처음으로 제대로 마주하고 공부하고 있습니다. 꽤나 뿌듯한 순간입니다. 오늘은 제가 PO로서 공부하고 있는 개발 관련 배경 지식들을 정리할 겸 이 공간에 함께 나눠보고자 합니다.
아키텍처 방향성을 어떻게 잡는 것이 좋고, 서비스 출시 전에 인프라를 어떻게 구성하는 게 좋을지 생각하다 보니 공부하게 되었습니다. 실제로 서비스에서 사용되고 있기도 하고요.
Kubernetes(쿠버네티스, k8s)란?
쿠버네티스 클러스터란 '컨테이너 클러스터(또는 오케스트레이션) 운영 플랫폼'입니다. (*클러스터란 여러 대의 서버 즉 노드를 하나의 큰 시스템처럼 묶은 것입니다. 이 안에서 컨테이너들을 배포하고 운영합니다. Control Plane + Worker Nodes 구조로 되어 있어요.) 그 자체가 하나의 '오픈소스 플랫폼'입니다. 백엔드 인프라 전체를 운영하는 플랫폼에 해당합니다. 그렇다 보니 보통 백엔드 또는 DevOps 팀이 쿠버네티스 클러스터를 세팅/운영합니다. 이 플랫폼은 구체적으로는 앱 배포 자동화, 서비스 복구, 트래픽 분산, 로그/모니터링, 배포 전략 등을 위해 사용됩니다. 개발자로서 쿠버네티스를 활용해서 얻는 이점은 아래와 같습니다.
개발자로서 얻는 이점 (코드 작성 외의 운영 부담에서 벗어나게 해주는 도구)
1. 배포 자동화: YAML로 정의만 하면 서버에 배포됨 (kubectleapply) ??
2. 확장/복구 자동화: 수동 스케일 아웃, 복구 작업 필요 없음
3. 로그/모니터링 일원화: 표준화된 로깅 및 상태 감시 구조
4. 테스트 환경 격리: Dev/QA/Prod를 별도 네임 스페이스로 분리 가능 (prod???)
5. 무중단 롤백/배포: 실수하더라도 빠르게 원복 가능
이 플랫폼을 쉽게 쓸 수 있도록 클라우드 업체들이 각자의 쿠버네티스 플랫폼을 제공하고 있어요. 구체적으로는 아래와 같습니다.
쿠버네티스를 사용 중이라면
아래 3가지 중 하나라도 사용되고 있다면 쿠버네티스 기반으로 배포 중일 가능성이 높습니다.
1. 배포/운영 방식 확인
- Kubernetes 클러스터나 Docker 기반 배포를 사용
2. 코드/배포 저장소(GitHub, GitLab 등) 확인
- .yaml, helm, kustomize, argo 같은 디렉토리나 파일이 존재
- CI/CD 파이프라인 안에 kubectl, helm 명령이 있는 경우
3. 배포 명령어(배포 시 사용하는 명령어) 확인
- kubectl apply, helm install, ArgoCD sync 등의 명령어 사용
쿠버네티스는 언제 사용하면 좋을까?
아래 조건 중 2개 이상 해당된다면 쿠버네티스 도입을 진지하게 고려하는 게 좋다고 합니다.
1. 배포 주기가 빠른 경우 (하루에 여러 번 배포하거나 롤백이 자주 필요할 때)
2. 멀티 서비스/팀 협업 (로그인, 채팅, 알림 등 마이크로서비스 또는 팀 간 분리가 있을 때)
3. 트래픽 자동 확장 필요 시 (예: 수천~수만 명의 동시 접속, 이벤트 트래픽이 발생할 때)
4. 무중단 배포(Zero Downtime Deployment)가 필요 시: 쿠버네티스는 롤링 업데이트, 헬스체크, 트래픽 분산 등을 자동으로 처리
5. 모니터링/자원 관리가 복잡할 경우 (예: 메모리나 CPU 사용량 예측이 어렵거나, 장애 감지 체계 필요 시)
6. 멀티 테넌시 또는 SaaS 계획이 있을 경우 (기업별 인스턴스 운영, 분리된 배포가 필요): 고객사마다 환경이 다르고, 독립적인 배포/버전/리소스 관리가 필요, 고객사 늘어날수록 자동 확장이 필요. SaaS는 빠른 배포와 롤백이 필수이며, 보통 웹/클라우드 기반 SW 서비스이기에 사용자는 별도의 업데이트 설치 없이 접속만 하는 특성을 고려해야 함
최근의 SaaS/B2C 회사들 중 대부분은 쿠버네티스를 도입 중이거나 도입하였습니다. 특히 클라우드 기반의 앱일수록 도입하는 비율이 높다고 합니다. 예를 들어, 슬랙은 쿠버네티스로 이전을 완료하여 수천 개의 마이크로서비스를 쿠버네티스 위에서 운영 중입니다. (___ 데이터를 포함한 코드???) MS는 AKS(Azure Kubernetes Service)의 내부 대규모 사용자이기 때문에, Teams(팀즈) 역시 쿠버네티스 기반의 마이크로서비스 아키텍처로 운영 중인 것으로 알려져 있습니다. 아마존(
트래픽 기준으로는 대략적으로 동시 접속자 수가 '수천' 이상일 때 도입하는 것이 좋습니다. 특히 무중단 배포, 자동 복구 체계가 필요할 때 매우 유리합니다. MAU가 1만 명 이하일 때는 일반 VPS나 간단한 오토스케일링 구조로도 충분하며, MAU가 5만~20만 정도일 때는 Docker(도커)와 자동 배포 스크립트 수준의 운영으로 가능하나, 확장에 대한 준비가 필요할 수 있습니다. 즉, 컨테이너화(Docker)와 모듈화된 서비스 구조를 준비해 놓는 것이 좋습니다.
물론, 서비스 규모가 크더라도 자체 인프라나 VM(Virtual Machine, 물리적 서버 1대를 여러 대의 논리적 서버로 나눈 것) 기반 배포로 추분하다면 쿠버네티스를 사용하지 않는 경우도 있긴 합니다. 예전에는 VM 위에 앱을 설치해서 서버처럼 사용했다고 합니다. 지금은 VM보다 가볍고 빠른 컨데이너(Docker)를 더 많이 사용하지만요. VM와 컨테이너를 비교하면 아래와 같습니다.
VM과 컨테이너 특성 비교
우선 가장 궁금했던 개괄적인 개념을 중심으로 살펴 보았습니다.
앞으로 더 차근차근 상세한 내용들을 정리해보고자 합니다. 다음 글에서 이어서 작성해보겠습니다. :)
