쿠버네티스, 매니지드로 갈까 직접 운영할까 — 결정 기준과 첫 배포 실습

컨테이너화된 워크로드를 자동으로 배치·확장·치유하는 오픈소스 오케스트레이션 플랫폼을 쓰기로 했다면, 다음 갈림길은 이걸 누가 운영할 것인가다. CNCF가 관리하는 Kubernetes 자체는 표준이지만, 그 표준을 매니지드 서비스로 소비할지 직접 클러스터를 세울지는 조직마다 답이 다르다.

컨트롤 플레인과 워커 노드가 하는 일

쿠버네티스는 컨트롤 플레인(Control Plane)과 워커 노드(Worker Node)로 나뉜 분산 시스템이다. 컨트롤 플레인에서는 kube-apiserver가 모든 요청의 인증·인가·검증을 처리하는 단일 진입점 역할을 하고, etcd가 클러스터 상태를 저장하는 분산 키-값 스토어로 강한 일관성을 보장한다. kube-scheduler는 자원·어피니티·토폴로지를 고려해 파드를 노드에 배치하고, kube-controller-manager와 cloud-controller-manager는 ReplicaSet·Node·Endpoint·Service 같은 컨트롤 루프를 돌려 클라우드 리소스(로드밸런서, 노드 라우트 등)를 동기화한다.

워커 노드에서는 kubelet이 파드 스펙을 실제로 적용하고 컨테이너 런타임(CRI)을 호출하며 노드·파드 상태를 컨트롤 플레인에 보고한다. kube-proxy는 Service의 가상 IP와 데이터플레인을 구성해 트래픽을 라우팅하고, 파드 자체는 스케줄링의 최소 단위로서 네임스페이스와 볼륨을 공유하는 컨테이너 묶음이다.

매니지드냐 직접 운영이냐

EKS·GKE·AKS 같은 매니지드 쿠버네티스(KaaS)는 컨트롤 플레인 최적화가 기본 제공되고, 자동 확장·업그레이드 경로가 이미 마련돼 있으며, SLA와 멀티 AZ 옵션, 통합 콘솔·IAM·로깅 연계까지 따라온다. 반면 kubeadm 기반 자체 운영은 하드웨어를 직접 튜닝해 성능을 끌어올릴 여지가 크고 완전한 커스터마이제이션이 가능하지만, 무중단 확장 전략을 스스로 설계해야 하고 환경별 설정이 흐트러지는 드리프트를 조직이 직접 관리해야 한다.

항목	매니지드(KaaS: EKS/GKE/AKS)	자체 운영(kubeadm/온프렘)
성능	컨트롤 플레인 최적화 기본 제공	하드웨어 튜닝으로 고성능 최적화 가능
확장성	자동 확장/업그레이드 경로 용이	무중단 확장 전략 수립 필요
일관성	표준 설정·업데이트 일관성 확보	환경별 드리프트 관리 부담
안정성	SLA·멀티 AZ 옵션 제공	설계/테스트 품질에 의존
운영 편의	통합 콘솔·IAM·로깅 연계	완전한 커스터마이제이션 가능

이 표는 결국 "누가 운영 부담을 지는가"의 문제로 좁혀진다. 쿠버네티스 도입 전반의 기대 효과로는 파이프라인·이미지 캐시가 미리 최적화된 조건에서 배포 리드타임이 5080% 범위로 단축될 것으로 기대되고, 노드·파드 자동 확장을 제대로 쓰면 평균 자원 사용률이 2040%p 개선된다.

실제로 하나 띄워보기

전제조건은 Kubernetes v1.28 이상, kubectl, CNI가 설치돼 있고 Ingress 컨트롤러(예: ingress-nginx)가 사전 배포된 상태다. 네임스페이스는 demo를 쓴다.

apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: demo
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
      name: http
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  namespace: demo
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: web.demo.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

적용하고 검증하는 순서는 단순하다.

kubectl apply -f demo.yaml
kubectl -n demo get deploy,po,svc,ing
# 로컬 테스트(예시): /etc/hosts에 web.demo.local 매핑 후
curl -I http://web.demo.local/

여기까지가 Deployment·Service·Ingress 조합의 최소 형태다. 실무에서는 여기에 오토스케일과 가용성 보장 장치를 얹는다.

kubectl autoscale deploy web -n demo --cpu-percent=70 --min=3 --max=10

PodDisruptionBudget으로 배포 중에도 최소 가용 파드 수를 유지하고, NetworkPolicy로 외부 접근을 필요한 범위로만 좁히는 것이 이 단계의 운영 체크포인트다. 자동 확장·자기치유는 라이브니스·레디니스·스타트업 프로브의 실패 감지에 의존하는데, 이 복구 루프가 제대로 작동하면 실패 복구 시간(MTTR)이 30~60% 단축되는 효과를 기대할 수 있다.

워크로드 유형마다 구성이 달라진다

마이크로서비스 API 플랫폼이라면 Deployment·Service·Ingress 조합으로 독립 배포·롤백·카나리 릴리스를 구현하고, 서비스 메시로 트래픽을 분할하거나 레이트 리밋·mTLS를 적용한다. HPA로 피크 트래픽에 대응하고 PDB로 배포 중 가용성을 지키는 건 이 패턴의 기본 세트다.

데이터·배치 처리는 다른 그림이다. CronJob·Job으로 ETL·리포팅 파이프라인을 실행하고, 노드 셀렉터와 테인트/톨러레이션으로 리소스를 격리한다. CSI 기반 퍼시스턴트 볼륨으로 데이터 내구성을 확보하고 스토리지 클래스의 QoS를 관리해야 한다는 점이 마이크로서비스 패턴과 다르다.

엣지·하이브리드 배포는 다중 클러스터·리전 배치로 지연을 최소화하고, Argo CD·Flux 같은 GitOps 도구로 선언적 동기화를 건다. Ingress 글로벌 라우팅과 로컬 오토스케일을 결합해두면 장애가 나도 근접 리전으로 페일오버할 수 있다.

운영에서 부딪히는 트레이드오프

보안 쪽에서는 최소 권한 RBAC, 네임스페이스 단위 격리, NetworkPolicy 기본 차단 전략을 세우고 이미지 서명·스캔과 불변 태그를 쓴다. Secret은 암호화(at-rest, KMS 연동)하고 Admission Policy로 보안 기준을 강제하는데, 초기 정책 설계와 예외 처리 비용이 늘어나는 게 대가다.

리소스 관리에서는 Requests/Limits로 노이지 네이버를 막고 QoS(Guaranteed/Burstable/BestEffort) 등급을 관리한다. HPA의 신호원(metrics-server, Prometheus Adapter)이 정확해야 하는데, 상한을 과도하게 설정하면 오히려 스로틀링 위험이 커진다.

네트워킹·가시성 쪽은 eBPF 기반 CNI(Cilium)로 성능·정책·가시성을 강화하고 Ingress 컨트롤러를 이중화하며 WAF를 연계한다. OpenTelemetry로 표준 로깅·트레이싱을 수집하면 관측력은 올라가지만 데이터 수집 비용과 오버헤드도 함께 늘어난다.

업그레이드·신뢰성은 불변 인프라·블루/그린, 서지 업데이트(maxSurge/Unavailable) 적용과 컨트롤 플레인 다중화, etcd 백업 정례화가 기본이다. 창구(maintenance window) 조정과 호환성 검증에 드는 노력은 피할 수 없는 비용이다.

결국 매니지드와 자체 운영 중 무엇을 고르든, 보안·리소스·네트워킹·업그레이드 네 영역의 트레이드오프는 그대로 남는다. 매니지드는 이 부담의 상당 부분을 클라우드 사업자에게 넘길 뿐이지 완전히 없애주지는 않는다 — 그래서 조직의 운영 역량과 트래픽 패턴을 먼저 보고 운영 모델을 정하는 순서가 맞다.