본문 바로가기

Infra/[K8S & Docker]

Kubernetes가 뭔데?

반응형

회사 다니면서 개발이든 인프라든 여러 프로젝트를 하다 보면 어느 순간부터 '서비스가 커지면 이걸 어떻게 운영하지?'라는 고민이 생겨. 특히 요즘은 서비스 하나를 만들더라도 마이크로서비스로 쪼개고, 배포 자동화하고, 트래픽 늘어나면 확장하고 이런 게 기본이잖아. 그때 나도 처음 접하게 된 게 바로 Kubernetes, 흔히 말하는 K8s야. 처음엔 진짜 어려워 보였어. 용어도 많고 뭔가 복잡해 보이거든. 근데 하나하나 이해해가면서 지금은 꽤 유용하게 잘 쓰고 있어.

1. Kubernetes가 뭐냐고?

한마디로 말하면, 컨테이너 오케스트레이션 툴이야. 좀 더 쉽게 말하면, "컨테이너들을 잘 관리해주는 시스템"이지. 예를 들어 도커로 서비스를 컨테이너 하나 만들었어. 그걸 서버 한 대에 띄워서 쓰는 건 쉬워. 근데 그걸 수십 개, 수백 개로 확장하고, 트래픽 상황에 맞게 오토스케일링하고, 장애 나면 자동으로 복구하고, 배포 자동화까지 하려면? 거기서부터는 사람이 직접 하기는 무리야. 그걸 자동으로 해주는 게 쿠버네티스야.

이걸 만들 때 구글이 시작했고, 지금은 CNCF(Cloud Native Computing Foundation)라는 데에서 관리하고 있어. 클라우드 네이티브 시대의 핵심 기술 중 하나지.


2. 왜 쓰냐고?

솔직히 컨테이너 기술이 없던 시절에는 EC2 같은 가상머신 위에 바로 애플리케이션을 띄워서 운영했거든. 근데 이 방식은 유연하지가 않아. 예를 들어 어떤 서비스는 Node.js고 어떤 건 Python이고 버전도 다르고. 그런 걸 하나의 서버에 설치해서 관리하는 게 점점 복잡해졌지.

그래서 컨테이너가 나오고, 그걸 관리하는 툴로 쿠버네티스가 대세가 된 거야. 도커로 컨테이너는 잘 만들 수 있지만, 그걸 운영하고 관리하는 건 쿠버네티스의 영역이거든.


3. 쿠버네티스의 핵심 개념

(1) Pod

가장 작은 단위야. 컨테이너 하나 이상을 담고 있는 유닛인데, 보통은 하나의 컨테이너가 하나의 Pod 안에 있어. 이 Pod들은 보통 같은 IP를 공유하고, 같은 네임스페이스에서 돌아.

(2) Deployment

배포 단위지. 애플리케이션을 몇 개의 Pod로 띄울 건지, 어떤 버전의 이미지를 쓸 건지 정의해. 배포, 롤백, 업데이트 이런 것도 여기서 컨트롤하고.

(3) Service

Pod들은 죽고 다시 만들어지고 계속 바뀌니까, 고정된 IP가 없거든. 그래서 외부에서 접속할 수 있게 하려면 고정된 접근 포인트가 필요해. 그걸 제공하는 게 Service야. LoadBalancer, ClusterIP, NodePort 이런 타입이 있어.

(4) Namespace

말 그대로 공간 나누기야. 테스트, 운영, 개발 이런 환경을 논리적으로 분리할 때 쓰지.

(5) ConfigMap / Secret

애플리케이션 설정값이나 민감 정보(API 키 등)를 외부에서 주입할 때 사용해. ConfigMap은 일반 설정값, Secret은 암호화된 민감 정보.

(6) Ingress

도메인이나 경로 기반으로 여러 서비스에 접근을 분기할 수 있게 해줘. 서비스들을 외부에 노출할 때 유용해. 일종의 라우터 역할을 해.


4. 쿠버네티스가 진짜 좋은 이유

  • 자동 복구: Pod가 죽으면 자동으로 다시 띄워줘. 서버 다운돼도 알아서 분산해서 복구.
  • 오토스케일링: 트래픽에 따라 Pod 수를 자동으로 늘리거나 줄일 수 있어.
  • 롤링 업데이트: 서비스 업데이트 시 순차적으로 교체돼서 다운타임이 거의 없어.
  • 인프라 추상화: 클라우드 어디서든 동작할 수 있어. AWS, GCP, Azure, 또는 로컬 클러스터까지.
  • GitOps와 궁합: Git으로 운영 자동화까지 가능. 배포, 설정 변경도 코드로 관리 가능해.

5. 배우면서 느낀 어려움

처음엔 헬름(Helm) 차트, CRD(Custom Resource Definition), Volume, RBAC 이런 것들에서 멘붕 오더라. 분명히 쿠버네티스 자체는 잘 설계되어 있는데, 그 생태계가 너무 넓고 다양하니까 정리가 안 돼. 특히 yaml 파일 쓰는 게 익숙치 않으면 더 헷갈릴 수 있어.

하지만 익숙해지고 나면 진짜 효율적이야. 한번 잘 구축해두면, 팀 전체가 통일된 방식으로 배포하고 운영할 수 있어서 협업이 훨씬 수월해지거든.


6. 실제 업무에서 어떻게 쓰는지

내가 참여했던 프로젝트 중에 백엔드 API 서버랑 프론트엔드 정적 페이지를 같이 운영하는 게 있었어. CI/CD를 통해 GitHub에 코드 푸시하면 자동으로 이미지 빌드하고, 쿠버네티스 클러스터에 새로 배포되는 파이프라인을 구성했지.

Helm으로 패키징해서, staging, production 환경에 맞는 value 파일만 교체하면서 배포할 수 있도록 했고, Prometheus랑 Grafana로 모니터링도 붙였어. 처음엔 조금 삽질했는데, 구축하고 나서는 장애 대응도 빠르고 배포도 자신 있게 하게 됐지.


7. 클라우드 네이티브 시대의 핵심

요즘은 AWS EKS, GCP GKE, Azure AKS처럼 클라우드에서 관리형 쿠버네티스를 제공해줘서 인프라 구축에 드는 시간도 많이 줄었어. 대신 쿠버네티스 위에서 돌아가는 수많은 툴들 — Istio, ArgoCD, KEDA, Fluentd 등 — 이것들을 얼마나 잘 이해하고 조합하느냐가 실력 차이를 만드는 것 같아.


마무리하며

정리하자면, 쿠버네티스는 현대 소프트웨어 개발에서 거의 필수가 됐다고 봐. 물론 작은 프로젝트엔 오버킬일 수도 있긴 해. 하지만 서비스가 조금만 커지면 K8s 도입은 운영 효율과 안정성 측면에서 진짜 큰 차이를 만들어.

그리고 한 번만 제대로 경험해 보면, 왜 전 세계 개발자들이 열광하는지 알게 될 거야. 나도 그랬고. 지금은 없으면 불안한 수준이지 ㅎㅎ

반응형