13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[카테고리:] k8s

  • [Kubernetes] Kubernetes CRD 심층 분석: 커스텀 리소스 정의 및 활용 전략

    [Kubernetes] Kubernetes CRD 심층 분석: 커스텀 리소스 정의 및 활용 전략

    목차

    [Kubernetes] Kubernetes CRD 심층 분석: 커스텀 리소스 정의 및 활용 전략

    Kubernetes CRD는 쿠버네티스(Kubernetes, 컨테이너 오케스트레이션 플랫폼)를 단순히 “파드를 띄우는 도구”에서 끝내지 않고, 우리 조직의 운영 규칙을 클러스터 안으로 끌고 들어오게 만드는 핵심 확장 포인트입니다. 처음엔 저도 이게 그냥 YAML 하나 더 만드는 기능인가 싶었는데, 실제로 써보니까 운영 지식을 API로 승격시키는 도구에 가깝더라고요. 특히 반복되는 인프라 작업이 많거나, 특정 서비스 배포 규칙을 팀 표준으로 강제하고 싶을 때 Kubernetes CRD의 진가가 확실히 드러납니다.

    제가 홈랩과 실무 환경에서 Kubernetes를 오래 만지면서 느낀 건, 사람이 문서 보고 수동으로 맞추는 방식은 결국 어딘가에서 틀어진다는 점이었습니다. “이 서비스는 TLS가 꼭 있어야 한다”, “이 애플리케이션은 백업 정책이 필요하다”, “이 데이터베이스는 복구 절차가 정해져 있다” 같은 규칙을 문서로만 남겨두면요. 언젠가는 빠집니다. 근데 Kubernetes CRD와 Operator 패턴(Operator Pattern, 운영 자동화 패턴)을 같이 쓰면, 그 규칙을 선언형(Declarative, 원하는 상태를 선언하는 방식)으로 관리할 수 있거든요.

    쿠버네티스 API 서버, etcd, CustomResourceDefinition, 커스텀 컨트롤러의 관계를 한눈에 보여주는 개요 이미지 위치입니다.

    Kubernetes CRD란 무엇인가요?

    쉽게 말해 CRD(CustomResourceDefinition, 커스텀 리소스 정의)는 쿠버네티스에 새로운 리소스 타입을 추가하는 방법입니다. Deployment, Service, Ingress(인그레스, 외부 트래픽 진입점)처럼 원래 있던 리소스 말고, 예를 들어 Database, BackupPolicy, AppRelease 같은 우리만의 리소스를 만들 수 있는 거죠.

    여기서 사람들이 많이 헷갈리는 포인트가 하나 있습니다. CRD 자체는 결국 스키마(schema, 데이터 구조 정의)를 등록하는 일이거든요. 즉, API 서버가 “아, 이제 이런 모양의 리소스도 받을 수 있구나” 하고 이해하게 만드는 단계예요. 그런데 실제로 그 리소스를 보고 뭔가 동작하게 만드는 건 보통 컨트롤러(Controller, 상태를 감시하고 맞추는 제어 루프)가 담당합니다. 저도 처음엔 CRD만 만들면 자동으로 뭔가 굴러갈 줄 알았는데, 아무 일도 안 일어나서 삽질 좀 했습니다 ㅎㅎ

    기본 구성 요소

    • CRD: 새로운 리소스 타입의 정의
    • Custom Resource: 실제로 생성하는 인스턴스
    • Controller: 원하는 상태와 현재 상태를 맞추는 로직
    • Operator: 특정 운영 지식을 코드로 구현한 컨트롤러 묶음
    항목 역할 비유
    CRD 새 API 타입 등록 양식(template) 만들기
    Custom Resource 실제 선언 데이터 양식에 값 채워 제출
    Controller 선언을 실제 상태로 반영 담당자가 요청 처리
    Operator 도메인 운영 자동화 숙련 엔지니어의 절차를 자동화

    왜 Kubernetes 확장에 CRD를 쓰는가

    Kubernetes 확장이라고 하면 예전에는 API Aggregation(집계 API)처럼 더 무거운 접근도 있었지만, 대부분의 팀에게는 CRD가 훨씬 현실적입니다. 이유는 분명합니다.

    1. 기존 kubectl과 선언형 워크플로우를 그대로 활용할 수 있습니다.
    2. RBAC(Role-Based Access Control, 역할 기반 접근 제어), admission, GitOps와 잘 맞습니다.
    3. 도메인 개념을 YAML로 표준화할 수 있습니다.
    4. Operator 패턴과 결합하면 반복 작업을 코드로 고정할 수 있습니다.

    예를 들어 운영팀에서 매번 데이터베이스 인스턴스를 만들 때 스토리지 클래스, 백업 주기, 리소스 제한, 비밀 정보(secret) 연결을 공통 규칙으로 적용한다고 해보겠습니다. 이걸 문서로 적어두는 대신 Database라는 커스텀 리소스를 만들고, 컨트롤러가 이를 보고 StatefulSet, Service, Secret 참조, 백업 Job을 구성하게 만들 수 있습니다. 이게 바로 커스텀 리소스와 Operator 패턴이 실무에서 힘을 발휘하는 지점입니다.

    혹시 이런 경험 있으신가요? 배포 문서는 있는데 팀원마다 해석이 조금씩 달라서 결과가 달라지는 상황이요. 저는 그걸 몇 번 겪고 나서, 사람이 읽는 문서와 시스템이 읽는 선언을 분리해야겠다고 생각했습니다. Kubernetes CRD는 바로 그 중간을 메워줍니다.

    실전 구현 1: CRD 정의하기

    이제 가장 단순한 예제로 가보겠습니다. AppClaim이라는 커스텀 리소스를 만들어서, 애플리케이션 배포에 필요한 최소 정보를 선언한다고 가정해보죠. 여기서는 이해를 위해 구조를 단순화했습니다.

    1. API 그룹(group)과 버전(version)을 정합니다.
    2. 리소스 이름과 복수형(plural)을 정합니다.
    3. OpenAPI v3 스키마로 필드를 정의합니다.
    4. 추가 프린터 컬럼으로 kubectl 가독성을 높입니다.
    apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: appclaims.platform.example.com
spec:
  group: platform.example.com
  scope: Namespaced
  names:
    plural: appclaims
    singular: appclaim
    kind: AppClaim
    shortNames:
      - ac
  versions:
    - name: v1alpha1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              required:
                - image
                - replicas
              properties:
                image:
                  type: string
                replicas:
                  type: integer
                  minimum: 1
                port:
                  type: integer
                  minimum: 1
                  maximum: 65535
                expose:
                  type: boolean
            status:
              type: object
              properties:
                phase:
                  type: string
                readyReplicas:
                  type: integer
      subresources:
        status: {}
      additionalPrinterColumns:
        - name: Image
          type: string
          jsonPath: .spec.image
        - name: Replicas
          type: integer
          jsonPath: .spec.replicas
        - name: Phase
          type: string
          jsonPath: .status.phase

    이 YAML의 핵심은 spec과 status를 분리한 거예요. spec은 사용자가 원하는 상태이고, status는 컨트롤러가 관찰한 결과입니다. 이 구분이 흐려지면 나중에 운영이 엄청 꼬입니다. 저도 예전에 status 비슷한 값을 spec에 억지로 넣었다가 reconcile loop(리컨실 루프, 상태 동기화 루프)가 지저분해져서 다시 갈아엎은 적이 있습니다.

    kubectl apply -f appclaim-crd.yaml
kubectl get crd appclaims.platform.example.com

    정상 적용되면 이제 클러스터는 AppClaim이라는 새 리소스 타입을 이해합니다. 여기서 중요한 포인트! 아직은 타입만 생긴 상태입니다. 배포는 자동으로 안 됩니다.

    Kubernetes CRD YAML을 작성하고 적용하는 실전 구성 이미지

    CRD YAML을 작성하고 kubectl로 적용하는 실전 구성 이미지를 넣는 위치입니다.

    실전 구현 2: 커스텀 리소스 생성과 컨트롤러 연결

    다음은 실제 인스턴스를 하나 만들어보겠습니다.

    apiVersion: platform.example.com/v1alpha1
kind: AppClaim
metadata:
  name: demo-web
spec:
  image: nginx:stable
  replicas: 2
  port: 80
  expose: true
    kubectl apply -f demo-appclaim.yaml
kubectl get appclaims
kubectl describe appclaim demo-web

    이제 컨트롤러가 이 리소스를 감시하면서 Deployment와 Service를 생성하도록 만들 수 있습니다. 실제 프로덕션에서는 Go와 controller-runtime을 많이 쓰지만, 여기서는 흐름 이해가 목적이니 의사 코드 수준으로 보겠습니다.

    def reconcile(appclaim):
    desired_deployment = build_deployment(appclaim.spec)
    desired_service = build_service(appclaim.spec)

    apply_object(desired_deployment)

    if appclaim.spec.get("expose"):
        apply_object(desired_service)

    update_status(
        appclaim,
        phase="Ready",
        ready_replicas=get_ready_replicas(appclaim.metadata.name)
    )

    실제로 써보니까 이 구조가 왜 좋은지 금방 체감됩니다. 사용자는 AppClaim만 만들면 되고, 배포 세부 구현은 컨트롤러가 맡습니다. 즉, 사용자 인터페이스는 단순하게, 운영 로직은 중앙집중화되는 거죠. 팀 규모가 커질수록 이 차이가 큽니다.

    Operator 패턴과의 연결

    Operator 패턴은 단순 생성 자동화를 넘어섭니다. 설치, 업그레이드, 백업, 복구, 장애 대응 같은 운영 절차를 컨트롤러 안에 녹이는 방식입니다. 대표적으로 데이터베이스, 메시지 큐, 모니터링 스택 같은 상태 저장 워크로드에서 자주 쓰입니다. Kubernetes CRD는 이 Operator의 입력 포맷이 되는 경우가 많고요.

    만약 앱 수준이 아니라 데이터베이스 운영 자동화까지 가고 싶다면, 다음 글에서 StatefulSet과 Operator 설계 포인트도 이어서 다뤄볼 예정입니다. 이전 글에서 다룬 Helm 차트 구조화 내용이 있다면 그것도 같이 보시면 흐름이 더 잘 잡힙니다.

    ⚠️ 주의사항과 트러블슈팅

    여기서부터가 진짜 실무 구간입니다. CRD는 만들기보다 버전 관리와 호환성에서 더 많이 흔들립니다. 제가 직접 해보니 아래 이슈는 거의 한 번씩 다 밟게 되더라고요.

    1. v1alpha1을 너무 오래 끌고 가는 문제

    처음엔 빠르게 실험하려고 v1alpha1로 시작합니다. 저도 그랬고요. 근데 이 상태로 사용자 수가 늘어나면 필드 변경이 무서워집니다. 기존 리소스와의 호환성을 고민해야 하거든요. 가능하면 초기에 필드 의미를 명확히 하고, status 구조도 대충 넣지 말고 의도를 분명히 하세요.

    2. 스키마 검증을 느슨하게 잡는 문제

    “컨트롤러에서 알아서 처리하면 되지”라고 생각하고 schema를 대충 열어두면 나중에 이상한 값이 다 들어옵니다. port에 문자열이 들어오거나, replicas가 0이 되거나, 필수 필드가 비는 식이죠. 그러면 에러 위치가 API 서버가 아니라 애플리케이션 쪽으로 밀려서 디버깅이 더 어려워집니다.

    3. status 업데이트 충돌

    컨트롤러가 status를 자주 갱신하면 resourceVersion 충돌이 날 수 있습니다. 이럴 때는 status subresource를 쓰고, 재시도 로직과 idempotent(멱등성 있는) 설계를 같이 가져가야 합니다. “한 번 더 실행돼도 결과가 같아야 한다” 이 원칙이 정말 중요합니다.

    4. finalizer 처리 누락

    외부 리소스를 만들었다면 finalizer(파이널라이저, 삭제 전 정리 훅)를 빼먹으면 안 됩니다. 삭제 이벤트가 왔을 때 외부 DNS, 스토리지, 인증서 같은 부수 리소스를 정리하지 않으면 유령 자원이 남습니다. 저도 예전에 테스트 환경에서 볼륨이 계속 쌓여서 왜 그런가 봤더니 finalizer 처리 누락이 원인이더라고요.

    kubectl get appclaim demo-web -o yaml
kubectl api-resources | grep appclaim
kubectl explain appclaim.spec

    위 명령어 세 개는 문제 생겼을 때 정말 자주 씁니다. 특히 kubectl explain은 Kubernetes CRD가 의도한 구조대로 등록됐는지 빠르게 확인할 때 유용합니다. 💡 작은 팁인데, 추가 프린터 컬럼을 잘 만들어두면 운영 가시성이 크게 좋아집니다.

    Kubernetes CRD 트러블슈팅과 검증 흐름을 보여주는 이미지

    스키마 검증 오류, 컨트롤러 동기화, kubectl 진단 흐름을 설명하는 트러블슈팅 다이어그램 위치입니다.

    검증과 결과 확인

    그럼 무엇을 검증해야 “Kubernetes CRD가 잘 동작한다”고 볼 수 있을까요? 단순히 리소스가 생성됐다는 것만으로는 부족합니다. 저는 보통 아래 순서로 봅니다.

    1. CRD가 정상 등록됐는지 확인합니다.
    2. Custom Resource 생성이 스키마에 맞게 통과하는지 봅니다.
    3. 컨트롤러가 원하는 하위 리소스를 생성하는지 확인합니다.
    4. status가 실제 상태를 반영하는지 확인합니다.
    5. 삭제 시 정리 로직이 정상 동작하는지 검증합니다.
    kubectl get crd
kubectl get appclaims
kubectl get deployment,service
kubectl describe appclaim demo-web
kubectl delete appclaim demo-web

    정상 흐름이라면 AppClaim을 만들었을 때 Deployment와 Service가 생성되고, 준비가 끝나면 status.phase 같은 필드가 업데이트됩니다. 삭제 시에는 관련 리소스가 정리돼야 하고요. 이 지점에서 드디어 “아, 이제 사람이 수작업으로 안 해도 되네” 하는 느낌이 옵니다. 🎉 이거 진짜 편하더라고요.

    검증 항목 확인 방법 기대 결과
    CRD 등록 kubectl get crd 리소스 타입 노출
    스키마 검증 잘못된 필드로 생성 시도 API 서버에서 거부
    하위 리소스 생성 Deployment/Service 조회 의도한 객체 생성
    Status 반영 kubectl describe 상태 필드 갱신
    삭제 정리 delete 후 잔여 리소스 확인 누수 없이 정리

    커스텀 리소스 상태와 생성된 워크로드를 검증하는 결과 화면 이미지를 넣는 위치입니다.

    언제 CRD를 쓰고, 언제 쓰지 말아야 하나

    모든 문제를 CRD로 풀 필요는 없습니다. 이건 정말 중요합니다. 저도 한때 뭐든지 커스텀 리소스로 만들면 멋있어 보인다고 생각했었는데, 나중엔 운영 복잡도만 올라간 적이 있었습니다.

    • CRD를 쓰면 좋은 경우: 반복되는 운영 절차가 있고, 선언형 API로 표준화할 가치가 있을 때
    • CRD가 과한 경우: 단순 스크립트 한 번이면 끝나는 작업일 때
    • Operator가 필요한 경우: 설치 이후에도 지속적인 상태 관리, 복구, 업그레이드가 필요할 때
    • Helm만으로 충분한 경우: 정적 템플릿 배포가 중심이고 런타임 제어가 크지 않을 때

    한 줄로 정리하면 이렇습니다. 새로운 API가 팀의 언어가 될 수준인지 먼저 보세요. 그 정도가 아니면 단순화하는 편이 낫습니다.

    정리와 FAQ

    Kubernetes CRD는 단순 기능 추가가 아니라, 팀의 운영 지식을 쿠버네티스 API로 모델링하는 방법입니다. CRD, 커스텀 리소스, Kubernetes 확장, Operator 패턴을 한 세트로 이해하면 왜 많은 플랫폼 팀이 이 접근을 쓰는지 감이 오실 겁니다. 저도 처음엔 용어가 너무 많아서 복잡했는데, 결국 핵심은 하나였습니다. “원하는 상태를 잘 정의하고, 그걸 시스템이 계속 맞추게 하자.” 이 철학만 잡히면 훨씬 편해집니다. ✅

    다음 단계로는 컨트롤러 프레임워크(controller-runtime), 상태 전이 설계, CRD 버전 업그레이드 전략까지 이어서 보시면 좋습니다. 다음 글에서 다룰 예정입니다.

    Kubernetes CRD와 Operator 패턴 역할 비교 요약 이미지

    CRD, 커스텀 리소스, 컨트롤러, Operator의 역할을 요약 비교하는 인포그래픽 위치입니다.

    자주 묻는 질문

    Q. CRD만 만들면 자동화가 되나요?
    아닙니다. CRD는 타입 등록이고, 실제 자동화는 보통 컨트롤러가 담당합니다.

    Q. CRD와 Operator는 같은 건가요?
    같지 않습니다. CRD는 API 정의이고, Operator는 운영 지식을 담은 자동화 로직입니다. 둘이 함께 쓰이는 경우가 많습니다.

    Q. 기존 Deployment나 Helm으로 충분한데도 Kubernetes CRD가 필요할까요?
    반복 운영 규칙을 API로 표준화할 필요가 없다면 굳이 안 써도 됩니다. 과한 설계는 오히려 부담이 됩니다.

    Q. 처음 만들 때 가장 중요한 한 가지는 뭔가요?
    spec과 status의 역할을 명확히 나누고, 스키마 검증을 초기에 엄격하게 잡는 겁니다. 여기서 흔들리면 나중에 계속 고생합니다.

  • [k8s] GKE 운영 1년 회고: 성공 사례와 놓쳤던 실수들

    [k8s] GKE 운영 1년 회고: 성공 사례와 놓쳤던 실수들

    목차

    [k8s] GKE 운영 1년 회고: 성공 사례와 놓쳤던 실수들

    GKE 운영 회고를 한 번 정리해봐야겠다고 마음먹은 이유가 있습니다. Kubernetes(쿠버네티스) 자체는 이제 낯설지 않은 기술이 됐는데, 막상 Google Kubernetes Engine(구글 쿠버네티스 엔진, GKE)를 1년 정도 운영해보면 문서에서 보이던 장점과 실제 운영에서 체감하는 포인트가 꽤 다르거든요. 저도 처음엔 “관리형 Kubernetes면 운영 부담이 확 줄겠지?”라고 생각했었는데, 실제로 써보니까 줄어드는 부담도 분명 있었고, 대신 다른 종류의 실수가 새로 생기더라고요. 이번 글은 그런 관점에서 정리한 GKE 운영 회고입니다.

    특히 홈랩과 회사 환경을 오가며 느낀 점이 비슷했습니다. 클러스터를 만드는 건 빠른데, 클라우드 운영의 난이도는 배포 그 자체보다 권한, 네트워크, 비용, 관측성 같은 주변 요소에서 올라가더라고요. 혹시 지금 GKE를 막 도입하셨거나, 이미 운영 중인데 “왜 자꾸 예상 밖의 이슈가 생기지?” 싶으셨다면 이 글이 꽤 현실적인 체크리스트가 될 겁니다.

    GKE 운영 회고를 위한 전체 클러스터 아키텍처 개요 이미지

    GKE 클러스터, 로드밸런서, Ingress(인그레스, 외부 트래픽 진입점), 모니터링 구성까지 한눈에 보이는 아키텍처 예시입니다.

    1. 왜 GKE 운영 회고가 중요했는가

    제가 느낀 가장 큰 차이는 이겁니다. 쿠버네티스를 설치하는 능력과 쿠버네티스를 안정적으로 운영하는 능력은 완전히 다르다는 점입니다. 온프레미스에서는 제어권이 많아서 불편해도 원인을 깊게 파고들 수 있었는데, GKE 같은 관리형 서비스에서는 편한 대신 추상화가 한 겹 더 들어갑니다. 이게 장점이자 함정이더라고요.

    쉽게 말해, GKE는 컨트롤 플레인(control plane, 클러스터 제어 영역)을 많이 대신 관리해주니까 운영 진입 장벽은 낮아집니다. 근데 워크로드(workload, 실제 애플리케이션 실행 단위), 노드(node, 컨테이너가 올라가는 서버 자원), 네트워크 정책, 비용 구조는 결국 우리가 책임져야 합니다. 그래서 GKE 운영 경험은 “쿠버네티스를 얼마나 아느냐”보다 “어디까지 자동화에 기대고, 어디서부터 운영 원칙을 세우느냐”가 더 중요했습니다.

    2. GKE를 쉽게 설명하면 뭐가 좋은가

    처음 접하시는 분 기준으로 아주 단순하게 설명해보면 이렇습니다.

    • Kubernetes(쿠버네티스): 컨테이너를 여러 대 서버에 나눠 안정적으로 배포하고 관리하는 플랫폼입니다.
    • GKE: 그 Kubernetes를 Google Cloud에서 관리형으로 제공하는 서비스입니다.
    • Ingress(인그레스): 외부에서 들어오는 HTTP/HTTPS 요청을 내부 서비스로 연결하는 관문입니다.
    • Node Pool(노드 풀): 비슷한 성격의 노드들을 묶어서 운영하는 단위입니다.
    • HPA(Horizontal Pod Autoscaler, 수평 자동 확장): 트래픽이나 리소스 사용량에 따라 Pod(파드, 컨테이너 실행 단위) 수를 자동으로 늘리거나 줄입니다.

    제가 직접 해보니 GKE의 진짜 장점은 “초기 구축이 편하다”보다 기본기 있는 팀이 운영 표준을 빠르게 정착시키기 좋다는 데 있었어요. 클러스터 생성, 로드밸런서 연동, IAM(아이엠, 권한 관리), 모니터링 연계 같은 기본 골격이 잘 맞물리거든요. 반대로 기본 원칙 없이 시작하면 편한 만큼 더 빨리 꼬입니다. 이거 진짜 그렇더라고요.

    3. 1년 운영하면서 성공했던 선택들

    3-1. Node Pool을 역할별로 분리한 것

    처음엔 하나의 노드 풀로 다 돌려도 되겠지 싶었습니다. 근데 배치 작업(batch job)과 사용자 트래픽을 받는 웹 서비스가 한곳에 섞이니까 스케줄링이 생각보다 지저분해졌습니다. 이후엔 역할별로 나눴어요.

    • 웹 애플리케이션용 노드 풀
    • 배치 작업용 노드 풀
    • 운영 도구용 노드 풀

    이렇게 나누니까 자원 격리(resource isolation, 리소스 분리)가 쉬워졌고, 장애 분석도 빨라졌어요. “어디가 문제인지”가 훨씬 선명해집니다.

    3-2. 배포 파이프라인을 일찍 표준화한 것

    CI/CD(지속적 통합/지속적 배포) 흐름을 초기에 통일한 것도 컸습니다. 이미지 태그 규칙, 배포 순서, 롤백 기준을 정해두면 사람마다 다르게 배포하는 사고를 많이 줄일 수 있어요. 사실 장애 중 꽤 많은 비율이 기술 난이도보다 절차 부재에서 나오거든요.

    3-3. 관측성부터 깔고 간 것

    Logging(로깅, 로그 수집), Monitoring(모니터링, 지표 수집), Alerting(알림, 이상 징후 통지)을 초반에 정리해둔 게 운영 피로도를 크게 낮췄습니다. 처음엔 귀찮아도, 나중에 장애가 터지면 그 투자금이 그대로 돌아옵니다. 드디어 됐다 싶었던 순간이 이런 데서 나왔습니다.

    4. 실전 구현: 제가 정착시킨 기본 운영 방식

    여기서는 아주 복잡한 구조보다, 운영하면서 무난하게 오래 버틴 기본 틀을 예시로 보여드리겠습니다. 환경마다 다르겠지만 시작점으로는 충분합니다.

    1. 클러스터와 기본 네임스페이스(namespace, 리소스 논리 분리 공간)를 나눕니다.
    2. 워크로드 특성에 따라 노드 풀을 분리합니다.
    3. Ingress와 TLS(전송 구간 암호화)를 표준화합니다.
    4. 리소스 요청치(requests)와 제한치(limits)를 반드시 넣습니다.
    5. 배포 전에 헬스 체크와 롤링 업데이트 기준을 검증합니다.

    4-1. 클러스터 접속과 기본 점검

    gcloud container clusters get-credentials my-gke-cluster --region asia-northeast3 --project my-project
kubectl get nodes
kubectl get ns
kubectl get pods -A

    이 단계는 별거 아닌 것 같아도 중요해요. 저도 초반엔 권한이 안 맞아서 접속은 되는데 일부 리소스가 안 보이는 상황을 겪었거든요. 접속 직후엔 노드 상태, 네임스페이스 목록, 전체 파드 상태를 한 번에 보는 습관을 들였습니다.

    4-2. 애플리케이션 배포 매니페스트 예시

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: gcr.io/my-project/web-app:stable
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
  name: web-app
  namespace: prod
spec:
  selector:
    app: web-app
  ports:
    - port: 80
      targetPort: 8080

    여기서 중요한 포인트! requests/limits를 빼먹으면 초반에는 멀쩡해 보여도 운영이 길어질수록 스케줄링 품질이 흔들립니다. 그리고 readiness probe(레디니스 프로브, 트래픽 받을 준비 확인)와 liveness probe(라이브니스 프로브, 살아있는지 확인)는 꼭 분리해서 생각하시는 게 좋습니다. 저도 처음엔 둘을 비슷하게 봤는데, 장애 대응할 때 차이가 꽤 커요.

    4-3. Ingress 구성 예시

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ingress
  namespace: prod
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-app
                port:
                  number: 80

    실제로 써보니까 Ingress는 단순히 외부 공개용 설정 파일이 아니라, 운영 책임 경계가 모이는 지점이더라고요. 인증서, 경로 라우팅, 헬스 체크, 방화벽, DNS까지 다 엮이거든요.

    GKE 운영 경험에서 본 배포 흐름과 Ingress 구성 이미지

    배포된 애플리케이션이 Service와 Ingress를 통해 외부 요청을 받는 구조를 시각화한 예시입니다.

    5. 놓쳤던 실수들: 문서에선 잘 안 보이던 운영 함정

    5-1. 리소스 요청치 없이 시작한 실수

    이건 정말 많이들 겪습니다. 초반 테스트에서는 다 잘 돼요. 그래서 “일단 배포부터 하자” 하고 requests/limits를 뒤로 미루기 쉽습니다. 저도 그랬습니다 ㅎㅎ 근데 운영 기간이 길어지면 특정 워크로드가 노드를 잠식하고, 다른 서비스의 응답성이 흔들립니다.

    해결 방법은 단순해요. 처음부터 보수적인 기본값이라도 넣고 시작하는 겁니다. 완벽한 값이 아니어도 괜찮습니다. 없는 것보다 훨씬 낫거든요.

    5-2. 권한 모델을 늦게 정리한 실수

    IAM과 Kubernetes RBAC(Role-Based Access Control, 역할 기반 접근 제어)를 뒤늦게 정리하면 운영자가 늘수록 위험이 커집니다. 특히 누가 클러스터 관리자 권한을 갖는지, 누가 배포만 할 수 있는지, 누가 시크릿(secret, 민감 정보)을 볼 수 있는지 기준이 애매하면 사고가 나더라고요.

    처음엔 저도 “팀이 작으니까 일단 넓게 열자”라고 생각했었는데, 이게 나중에 회수 비용이 더 커요. 최소 권한(least privilege, 필요한 최소 권한만 부여) 원칙은 빨리 적용할수록 편합니다.

    5-3. 로그는 쌓이는데 분석 기준이 없던 실수

    로그를 모으는 것과 로그를 운영에 쓰는 건 달라요. 에러 레벨 구분, 요청 ID(request ID, 요청 추적 식별자), 배포 버전 정보가 없으면 로그가 많아도 분석 속도가 안 나옵니다. 처음엔 이게 뭔가 싶었는데, 결국 로그 포맷 표준화가 먼저였습니다.

    6. ⚠️ 트러블슈팅: 실제로 시간을 잡아먹었던 문제들

    6-1. 파드는 정상인데 서비스가 안 열리던 문제

    가장 당황스러운 유형 중 하나입니다. kubectl get pods에서는 정상으로 보이는데, 외부에서는 접속이 안 됩니다. 이런 경우 저는 아래 순서로 확인했습니다.

    1. Pod readiness 상태 확인
    2. Service selector가 Deployment label과 일치하는지 확인
    3. Ingress backend 연결 상태 확인
    4. DNS 반영 여부 확인
    5. 방화벽/헬스 체크 정책 확인
    kubectl get pods -n prod
kubectl describe service web-app -n prod
kubectl describe ingress web-app-ingress -n prod
kubectl get endpoints web-app -n prod

    실제로는 selector 오타나 readiness 실패가 생각보다 많았어요. 겉으로는 작은 실수인데 장애 체감은 크게 오더라고요.

    6-2. 오토스케일링이 기대처럼 안 움직이던 문제

    HPA를 걸어두면 자동으로 다 해결될 거라 기대하기 쉽습니다. 근데 메트릭(metric, 측정 지표) 기준이 애매하거나 애플리케이션이 스케일 아웃(scale-out, 인스턴스 수 확장)에 적합하지 않으면 기대만큼 반응하지 않더라고요. CPU만 보고 확장하면 실제 병목이 I/O나 DB 연결 수에 있을 수도 있거든요.

    그래서 저는 확장 정책을 신뢰하기 전에 병목 지점을 먼저 확인하는 쪽으로 바꿨어요. 이건 GKE라서가 아니라 Kubernetes 운영 전반의 교훈이었습니다.

    6-3. 비용이 천천히 새던 문제

    운영 초반엔 성능과 안정성에 집중하느라 비용은 뒤로 밀리기 쉽습니다. 저도 그랬고요. 그런데 사용하지 않는 로드밸런서, 과하게 큰 노드, 낮과 밤 차이가 큰 서비스의 고정 리소스가 비용을 서서히 끌어올립니다.

    해결 포인트는 세 가지였습니다.

    • 유휴 리소스 정기 점검
    • 환경별 리소스 상한선 정의
    • 노드 풀 목적 분리와 요청치 재조정

    비용은 어느 날 갑자기 터지지 않고 조용히 새는 경우가 많아요. 그래서 월말보다 주 단위 점검이 더 효과적이더라고요.

    7. 검증과 결과: 운영이 안정됐다고 느낀 기준

    제가 1년쯤 지나서 “이제 좀 운영 체계가 잡혔다”라고 느낀 기준은 화려한 대시보드가 아니었습니다. 아래 같은 변화가 보이면 꽤 건강한 상태예요.

    • 배포 실패 원인을 팀원들이 비슷한 순서로 추적할 수 있음
    • 장애가 나도 어느 레이어에서 막혔는지 빠르게 좁혀짐
    • 리소스 사용량과 트래픽 패턴의 관계가 보임
    • 온콜(on-call, 장애 대응 대기) 피로도가 줄어듦
    • 신규 서비스 온보딩 시간이 짧아짐

    결국 좋은 운영은 “문제가 아예 없는 상태”가 아니라 문제가 생겨도 예측 가능한 방식으로 다루는 상태에 가깝습니다. 이 부분은 GKE 운영 회고를 쓰면서도 다시 느꼈네요.

    GKE 운영 회고의 결과를 보여주는 모니터링 대시보드 이미지

    CPU, 메모리, 파드 수, 배포 상태를 함께 보는 운영 대시보드 예시입니다.

    7-1. 운영 방식 비교 표

    항목 초기 운영 방식 1년 후 정착 방식
    노드 구성 단일 노드 풀 중심 워크로드별 노드 풀 분리
    배포 기준 서비스별 제각각 공통 매니페스트와 파이프라인 사용
    권한 관리 넓은 권한 부여 최소 권한 원칙 적용
    관측성 로그 중심 확인 로그, 메트릭, 알림 기준 통합
    비용 관리 월말 점검 주 단위 점검과 리소스 재조정

    8. 자주 묻는 질문과 운영 팁

    8-1. GKE가 있으면 Kubernetes 운영이 쉬워지나요?

    네, 분명 쉬워지는 부분이 있어요. 다만 운영 책임이 사라지는 건 아닙니다. 제어 영역 일부를 대신 관리해줄 뿐, 애플리케이션 특성, 네트워크 설계, 비용 최적화는 여전히 팀의 몫입니다.

    8-2. 처음부터 완벽한 구조를 만들어야 하나요?

    아닙니다. 오히려 처음부터 너무 크게 설계하면 유지가 어려워요. 제가 추천하는 건 작지만 일관된 표준입니다. 네임스페이스 규칙, 배포 형식, 리소스 요청치, 로그 포맷 이 정도만 먼저 맞춰도 훨씬 낫습니다.

    8-3. 어떤 지표부터 봐야 하나요?

    가장 먼저는 CPU, 메모리, 재시작 횟수, readiness 실패, 배포 이벤트입니다. 그 다음에 애플리케이션 응답 시간과 에러율을 연결해서 보시면 돼요. 인프라 지표와 서비스 지표를 따로 보면 원인 파악이 늦어지더라고요.

    GKE 운영 회고 핵심 체크리스트와 실수 방지 포인트 요약 이미지

    운영 표준, 권한, 관측성, 비용 점검 항목을 한 장으로 요약한 체크리스트 이미지입니다.

    9. 마무리: GKE 운영 경험에서 남은 교훈

    이번 GKE 운영 회고를 정리하면서 다시 느낀 건, 결국 운영의 품질은 특정 기능 하나보다 작은 원칙들을 얼마나 꾸준히 지키느냐에 달려 있다는 점이었습니다. 클러스터를 잘 만드는 것보다, 문제를 빨리 좁히고 반복 실수를 줄이는 구조를 만드는 게 훨씬 중요했어요.

    제가 직접 해보니 성공 사례는 대부분 화려하지 않았습니다. 노드 풀을 분리하고, 리소스 요청치를 넣고, 권한을 조이고, 로그 기준을 맞추는 식의 기본기였어요. 반대로 놓쳤던 실수들도 대단한 기술적 난제가 아니라 “나중에 하자”라고 미뤘던 운영 습관에서 시작됐습니다. 사실 이게 제일 무섭거든요.

    혹시 지금 Google Kubernetes Engine을 도입하려고 하시거나, 이미 쓰고 있는데 운영이 어수선하다고 느끼신다면 먼저 화려한 도구보다 배포 표준화, 권한 모델, 관측성, 비용 점검 루틴부터 다시 보시는 걸 추천드립니다. 다음 글에서는 GKE 환경에서 Ingress와 내부 서비스 분리 전략, 그리고 운영용 대시보드 구성 기준도 이어서 다뤄볼 예정입니다. 이전 글에서 다룬 Kubernetes 기본 운영 원칙과 함께 보시면 더 이해가 쉬우실 겁니다.

    🎉 한 줄로 정리하면 이렇습니다. GKE는 편한 플랫폼이지만, 편하다고 해서 운영 원칙까지 대신 만들어주지는 않습니다. 이 부분만 초반에 잡아두시면 1년 뒤 회고가 훨씬 덜 아프실 겁니다.

  • [Kubernetes] Karpenter vs Cluster Autoscaler 비교 분석

    [Kubernetes] Karpenter vs Cluster Autoscaler 비교 분석

    목차

    [Kubernetes] Karpenter vs Cluster Autoscaler 비교 분석

    Karpenter vs Cluster Autoscaler 이야기는 Kubernetes(쿠버네티스) 운영하시는 분들이 한 번쯤 꼭 부딪히는 주제입니다. 파드(Pod)가 늘어나는데 노드(Node)가 제때 안 붙으면 서비스가 밀리고, 반대로 너무 빨리 늘어나면 비용이 튀거든요. 저도 처음엔 HPA(Horizontal Pod Autoscaler, 파드 수평 확장)만 잘 걸어두면 끝인 줄 알았는데, 실제로 운영해보니 워크로드 확장과 노드 확장은 완전히 다른 문제더라고요. 특히 EKS 같은 클라우드 환경에서 직접 써보니까 Karpenter와 Cluster Autoscaler는 비슷해 보여도 철학이 꽤 다릅니다.

    이번 글에서는 Karpenter vs Cluster Autoscaler를 실무 관점에서 비교해보겠습니다. 단순히 기능 목록만 나열하는 게 아니라, 어떤 워크로드에서 무엇이 더 잘 맞는지, 설치할 때 어디서 삽질하는지, 검증은 어떻게 해야 하는지까지 정리해보겠습니다. 혹시 지금 Kubernetes 오토스케일링 구성을 만지시는 중이라면 꽤 바로 도움이 되실 겁니다.

    Cluster Autoscaler와 Karpenter가 각각 어떤 방식으로 노드를 늘리고 줄이는지 한눈에 보여주는 개요 다이어그램이 들어갈 자리입니다.

    Kubernetes 오토스케일링이 왜 생각보다 어렵냐면요

    쉽게 말해, Kubernetes 오토스케일링은 두 층으로 나뉩니다. 하나는 파드 수를 늘리는 것이고, 다른 하나는 그 파드를 올릴 노드를 확보하는 것입니다. HPA가 앞단이라면, Karpenter나 Cluster Autoscaler는 뒷단이라고 보시면 됩니다.

    • HPA: CPU, 메모리, 커스텀 메트릭 기준으로 파드 수를 늘리고 줄립니다.
    • Cluster Autoscaler: 기존 노드 그룹(Node Group, 노드 묶음)의 크기를 늘리거나 줄입니다.
    • Karpenter: 스케줄링되지 못한 파드를 보고, 필요한 조건에 맞는 노드를 더 직접적으로 프로비저닝(Provisioning, 자원 생성)합니다.

    여기서 중요한 포인트가 하나 있습니다. Cluster Autoscaler는 미리 정의된 노드 그룹 중심으로 생각하고, Karpenter는 파드 요구사항 중심으로 생각합니다. 이 차이가 운영 난이도, 비용 최적화, 확장 속도에 꽤 큰 영향을 줍니다.

    Karpenter vs Cluster Autoscaler: 핵심 개념 차이

    처음 문서를 보면 둘 다 자동으로 노드를 늘려주는 도구라서 별 차이 없어 보이는데요, 실제로 써보면 운영 감각이 다릅니다. 제가 직접 비교하면서 느낀 건 아래 표 하나로 많이 정리되더라고요.

    항목 Cluster Autoscaler Karpenter
    기본 동작 방식 기존 노드 그룹 크기 조절 파드 요구사항에 맞춰 노드 직접 생성
    확장 기준 스케줄 불가 파드를 보고 적절한 노드 그룹 선택 스케줄 불가 파드의 리소스 조건을 바로 계산
    노드 유연성 노드 그룹 설계에 크게 의존 인스턴스 타입 선택 폭이 넓음
    운영 모델 ASG/Managed Node Group 중심 Provisioner/NodePool 성격의 선언적 관리
    장점 구조가 익숙하고 보수적 운영에 적합 유연성, 속도, 비용 최적화 측면에서 강점
    주의점 노드 그룹이 많아지면 복잡도 증가 초기 설계와 제약조건 관리가 중요

    정리하면 이렇습니다. Cluster Autoscaler는 전통적인 방식입니다. 이미 만들어 둔 노드 그룹이 있고, 그 그룹의 min/max 범위 안에서 증감시키죠. 반면 Karpenter는 필요한 자원을 그때그때 맞춰 뽑아내는 쪽에 가깝습니다. 그래서 워크로드 패턴이 자주 바뀌거나, 다양한 인스턴스 타입을 섞어 쓰고 싶을 때 체감이 꽤 납니다.

    언제 Karpenter가 유리하고, 언제 Cluster Autoscaler가 편한가

    이건 솔직히 정답이 하나는 아닙니다. 운영팀 성향, 클러스터 규모, 클라우드 의존도에 따라 달라지거든요. 저도 처음엔 무조건 신형이 좋아 보였는데, 몇 번 굴려보니 케이스가 나뉘더라고요.

    Cluster Autoscaler가 잘 맞는 경우

    • 이미 Managed Node Group 기반 운영 체계가 안정적으로 잡혀 있는 경우
    • 보안, 승인, 변경 관리 때문에 노드 타입을 엄격히 통제해야 하는 경우
    • 여러 팀이 공용으로 쓰는 클러스터라서 예측 가능한 증설 패턴이 중요한 경우
    • 기존 운영팀이 노드 그룹 기반 모델에 익숙한 경우

    Karpenter가 잘 맞는 경우

    • 워크로드 확장 패턴이 들쭉날쭉해서 빠른 대응이 필요한 경우
    • 다양한 인스턴스 타입 조합으로 비용 최적화를 하고 싶은 경우
    • 스케줄링 요구사항이 세밀해서 노드 그룹을 많이 쪼개기 싫은 경우
    • 빈번한 배치 작업, CI 러너, 이벤트성 트래픽처럼 탄력성이 중요한 경우

    제 경험상 노드 그룹이 많아질수록 Cluster Autoscaler는 운영 피로도가 올라갑니다. 반대로 Karpenter는 초반 설계만 잘못 잡으면 예상치 못한 노드 생성 패턴 때문에 당황하게 되더라고요. 그러니까 둘 중 뭐가 무조건 더 좋다기보다, 운영 모델에 맞는 선택이 더 중요합니다.

    실전 구현 1: Cluster Autoscaler 구성 흐름

    먼저 Cluster Autoscaler부터 보겠습니다. 예시는 EKS 환경 기준으로 적겠습니다. 다른 클라우드에서도 개념은 비슷합니다. 핵심은 오토스케일 대상 노드 그룹이 먼저 존재해야 한다는 점입니다.

    1. 오토스케일 가능한 노드 그룹을 준비합니다.
    2. 노드 그룹의 최소/최대 크기를 정합니다.
    3. Cluster Autoscaler를 클러스터에 배포합니다.
    4. 스케줄 불가 파드가 생기면 해당 노드 그룹 크기를 늘립니다.
    helm repo add autoscaler https://kubernetes.github.io/autoscaler
helm repo update

helm upgrade --install cluster-autoscaler autoscaler/cluster-autoscaler \
  --namespace kube-system \
  --set autoDiscovery.clusterName=my-cluster \
  --set awsRegion=ap-northeast-2 \
  --set rbac.serviceAccount.create=true

    설치 자체는 그렇게 복잡하지 않습니다. 근데 실제로는 IAM(Role, 권한 역할), 오토디스커버리 태그, 노드 그룹 min/max 값 같은 주변 설정에서 삽질을 많이 하게 됩니다. 특히 노드 그룹 태그가 안 맞으면 파드가 Pending(펜딩, 스케줄 대기) 상태로 남아 있는데도 노드가 안 늘어납니다. 저도 처음엔 로그만 한참 봤네요.

    kubectl -n kube-system logs deploy/cluster-autoscaler
kubectl get pods -A
kubectl describe pod <pending-pod-name>

    여기서 보는 포인트는 간단합니다. 파드가 왜 스케줄링되지 않았는지, 그리고 Cluster Autoscaler가 어떤 노드 그룹을 확장 후보로 판단했는지입니다.

    실전 구현 2: Karpenter 구성 흐름

    Karpenter는 접근 방식이 다릅니다. 미리 노드 그룹을 세세하게 많이 만들기보다, 어떤 종류의 노드를 허용할지 정책으로 정의하는 느낌에 가깝습니다. 그래서 처음엔 구조가 낯선 감이 있더라고요. 저도 처음엔 이게 뭔가 싶었는데, 한번 감을 잡고 나니 꽤 편하더라고요.

    1. Karpenter 컨트롤러를 설치합니다.
    2. 클라우드 권한과 네트워크 조건을 연결합니다.
    3. 어떤 노드를 만들 수 있는지 정책을 정의합니다.
    4. 스케줄 불가 파드가 생기면 그 요구사항을 기반으로 노드를 생성합니다.
    helm repo add karpenter https://charts.karpenter.sh
helm repo update

helm upgrade --install karpenter karpenter/karpenter \
  --namespace karpenter \
  --create-namespace
    apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: kubernetes.io/arch
      operator: In
      values:
        - amd64
    - key: kubernetes.io/os
      operator: In
      values:
        - linux
  limits:
    resources:
      cpu: "1000"
  ttlSecondsAfterEmpty: 30

    요즘 Karpenter 관련 리소스 모델은 환경과 시점에 따라 구성이 조금씩 달라질 수 있어서, 실제 배포 전에는 현재 사용하는 배포 가이드와 CRD(Custom Resource Definition, 사용자 정의 리소스 정의)를 반드시 맞춰보셔야 합니다. 여기서는 비교 분석이 핵심이라, 파드 요구사항 기반으로 노드를 뽑아낸다는 운영 개념에 집중해서 보시면 됩니다.

    Karpenter 정책 기반 노드 생성 흐름을 보여주는 Kubernetes 오토스케일링 이미지

    Karpenter가 파드의 요구 리소스를 읽고 적절한 노드를 동적으로 생성하는 흐름을 설명하는 구성 이미지 자리입니다.

    워크로드 확장 테스트: 직접 확인하는 방법

    설치보다 중요한 게 검증입니다. 오토스케일링은 붙어 있다고 끝이 아니거든요. 원하는 타이밍에, 원하는 방식으로, 과하지 않게 확장되는지를 봐야 합니다. 저는 보통 부하 테스트용 디플로이먼트(Deployment)를 하나 띄워두고 확인합니다.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: "1"
              memory: "1Gi"
            limits:
              cpu: "1"
              memory: "1Gi"
    kubectl apply -f inflate.yaml
kubectl scale deployment inflate --replicas=20
kubectl get pods -w
kubectl get nodes -w

    이 테스트에서 봐야 할 건 세 가지입니다.

    • 확장 속도: Pending 파드가 얼마나 빨리 해소되는지
    • 적합성: 필요한 크기의 노드가 제대로 붙는지
    • 정리 속도: 부하가 끝난 뒤 빈 노드가 얼마나 깔끔하게 제거되는지

    실제로 써보니까 Karpenter는 워크로드 확장에 좀 더 민감하게 반응하는 느낌이 있었고, Cluster Autoscaler는 노드 그룹 구조를 잘 짜놨을 때 안정감이 있었습니다. 드디어 됐다! 싶은 순간이 오긴 오는데, 그 전에 로그와 이벤트를 많이 보게 됩니다 ㅎㅎ

    워크로드 확장 과정에서 Pending 파드가 노드 증설로 해결되는 Kubernetes 오토스케일링 이미지

    파드가 Pending 상태가 되었다가 새 노드가 생성되고 Running으로 전환되는 과정을 단계별로 보여주는 이미지 자리입니다.

    ⚠️ 제가 실제로 자주 겪었던 트러블슈팅 포인트

    이 섹션이 제일 중요할 수도 있습니다. 문서대로만 보면 금방 될 것 같지만, 현실은 그렇지 않더라고요.

    1. 파드는 Pending인데 노드가 안 늘어나는 경우

    • 리소스 요청값(requests)이 비현실적으로 큰지 확인합니다.
    • 노드 선택 조건(nodeSelector, affinity, taint/toleration)이 너무 빡빡한지 봅니다.
    • Cluster Autoscaler라면 대상 노드 그룹 태그와 범위를 확인합니다.
    • Karpenter라면 허용된 인스턴스 조건과 서브넷/보안 그룹 연결을 확인합니다.

    처음엔 저도 컨트롤러 문제인 줄 알았는데, 알고 보니 파드 스펙 자체가 너무 까다로운 경우가 꽤 있었습니다. 특히 GPU나 특정 아키텍처를 요구하는 워크로드는 더 그렇습니다.

    2. 노드는 늘어나는데 생각보다 비효율적인 경우

    이건 비용 문제로 바로 이어집니다. Cluster Autoscaler는 노드 그룹 단위로 움직이기 때문에, 작은 파드 몇 개 때문에 상대적으로 큰 노드가 붙는 상황이 생기곤 합니다. Karpenter도 제약 조건을 널널하게 열어두면 예상보다 다양한 노드가 만들어지곤 해요. 그래서 요청 리소스(requests) 튜닝이 정말 중요합니다.

    3. 축소(scale down)가 너무 늦거나 안 되는 경우

    • PodDisruptionBudget(PDB, 파드 중단 예산) 때문에 축소가 막힐 수 있습니다.
    • DaemonSet(데몬셋)과 로컬 스토리지 사용 여부도 확인해야 합니다.
    • 노드가 비어 보여도 eviction(축출) 조건 때문에 남아 있을 수 있습니다.

    이 부분은 진짜 많이 놓칩니다. 저도 한동안 왜 비용이 안 줄지 봤더니, 특정 시스템 파드가 노드 정리를 막고 있더라고요.

    검증과 결과: 무엇을 기준으로 비교해야 하나

    Karpenter vs Cluster Autoscaler를 비교할 때 단순히 “누가 더 빠르냐”만 보면 아쉽습니다. 운영에서는 아래 기준으로 보시는 걸 추천드립니다.

    검증 항목 확인 포인트
    확장 지연 시간 Pending 파드 발생 후 Running까지 걸리는 체감 시간
    리소스 적합도 워크로드 요구사항에 맞는 노드가 붙는지 여부
    운영 복잡도 노드 그룹/정책 관리 난이도, 변경 영향 범위
    비용 효율성 불필요한 큰 노드가 자주 붙는지, 축소가 잘 되는지
    장애 대응성 예외 상황에서 로그와 원인 파악이 쉬운지

    제가 여러 번 테스트하면서 느낀 결론은 이렇습니다.

    • 보수적이고 예측 가능한 운영이 중요하면 Cluster Autoscaler가 편합니다.
    • 유연한 워크로드 확장과 세밀한 자원 최적화가 중요하면 Karpenter가 매력적입니다.
    • 둘 다 잘 쓰려면 결국 파드 스펙, 요청 리소스, 스케줄링 제약조건을 먼저 정리해야 합니다.
    kubectl top pods -A
kubectl top nodes
kubectl get events --sort-by=.lastTimestamp
kubectl describe node <node-name>

    이 명령어들만 잘 봐도 현재 Kubernetes 오토스케일링이 어디에서 막히는지 감이 꽤 옵니다. 대시보드만 보지 마시고 이벤트(event)와 describe 출력도 꼭 같이 보세요. 진짜 차이가 여기서 보이거든요.

    Karpenter vs Cluster Autoscaler 검증 결과를 보여주는 Kubernetes 대시보드 이미지

    노드 수 변화, 파드 Pending 해소, 리소스 사용률 등을 한눈에 보여주는 결과 검증용 대시보드 이미지 자리입니다.

    실무 선택 가이드: 그래서 무엇을 고르면 되냐

    질문을 많이 받는 부분이라 아주 현실적으로 정리해보겠습니다.

    1. 기존에 노드 그룹 체계가 잘 잡혀 있고 변경 리스크를 줄이고 싶다면 Cluster Autoscaler부터 가는 게 안전합니다.
    2. 새 클러스터를 설계하거나, 워크로드 종류가 다양하고 변동폭이 크다면 Karpenter를 적극 검토할 만합니다.
    3. 어떤 도구를 쓰든 HPA, requests/limits, affinity 정책을 먼저 정리하지 않으면 효과가 반감됩니다.
    4. 운영팀이 디버깅하기 쉬운 구조인지도 꼭 보셔야 합니다. 기술적으로 좋아 보여도 팀이 못 다루면 오래 못 갑니다.

    여기서 중요한 포인트! Karpenter vs Cluster Autoscaler의 승부는 기능표가 아니라 운영 방식에서 갈립니다. 홈랩에서 실험할 때도 그렇고 실제 서비스에서도 그렇고, 결국 오래 버티는 건 팀이 이해하고 통제할 수 있는 구조였습니다.

    정리와 FAQ

    정리하자면, Cluster Autoscaler는 익숙하고 보수적인 선택지입니다. Karpenter는 더 유연하고 워크로드 중심적인 선택지이고요. 어느 쪽이든 워크로드 확장의 핵심은 파드와 노드의 관계를 제대로 이해하는 데 있습니다. 저도 처음엔 단순히 “자동으로 늘려준다” 정도로 생각했었는데, 실제로 써보니까 오토스케일링은 설계의 문제더라고요.

    다음 글에서는 HPA와 VPA(Vertical Pod Autoscaler, 수직 오토스케일러)를 함께 붙였을 때 어떤 점을 조심해야 하는지 다뤄볼 예정입니다. 이전 글에서 다뤘던 Ingress(인그레스, 외부 트래픽 진입점)와 서비스 분리 구조를 같이 보시면 더 이해가 잘 되실 겁니다.

    자주 묻는 질문

    • Q. 둘을 동시에 써도 되나요?
      A. 환경과 목적에 따라 가능은 하지만, 노드 프로비저닝 책임이 겹치지 않도록 설계를 분명히 나누는 게 중요합니다.
    • Q. Kubernetes 오토스케일링에서 가장 먼저 봐야 할 건 뭔가요?
      A. 파드 requests/limits와 스케줄링 제약조건입니다. 여기서 꼬이면 어떤 오토스케일러를 써도 답답합니다.
    • Q. 초보 운영자에게는 뭐가 더 쉬운가요?
      A. 이미 노드 그룹 개념이 익숙하다면 Cluster Autoscaler가 더 이해하기 쉬운 편입니다. 다만 장기적으로는 Karpenter의 유연성이 매력적일 수 있습니다.
    Karpenter vs Cluster Autoscaler 핵심 차이를 요약한 비교 인포그래픽

    두 오토스케일러의 장단점, 추천 시나리오, 선택 기준을 한 장으로 정리한 마무리용 인포그래픽 자리입니다.

    ✅ 결론만 짧게 말하면 이렇습니다. 안정성과 익숙함이면 Cluster Autoscaler, 유연성과 최적화면 Karpenter입니다. 다만 둘 다 만능은 아니고, 결국 좋은 오토스케일링은 좋은 워크로드 설계에서 시작합니다. 이거 진짜 중요합니다.

  • [Kubernetes] VPA vs HPA: 리소스 오토스케일링 최적화 전략 비교

    [Kubernetes] VPA vs HPA: 리소스 오토스케일링 최적화 전략 비교

    목차

    [Kubernetes] VPA vs HPA: 리소스 오토스케일링 최적화 전략 비교

    Kubernetes VPA HPA를 처음 비교할 때 가장 헷갈리는 지점이 바로 “뭘 늘리는 거지?”였습니다. Replica(레플리카, Pod 개수)를 늘리는 건지, 아니면 Pod 하나가 먹는 CPU/Memory(메모리) 요청값을 바꾸는 건지요. 저도 처음엔 HPA(Horizontal Pod Autoscaler, 수평 Pod 오토스케일링)만 걸어두고 끝난 줄 알았는데, 실제로 운영해보니 Pod 수는 늘어나도 개별 Pod 요청값이 너무 작아서 계속 Throttling(스로틀링, CPU 제한으로 인한 성능 저하)이 나는 경우가 있더라고요. 반대로 VPA(Vertical Pod Autoscaler, 수직 Pod 오토스케일링)를 무턱대고 적용했다가 재시작 타이밍 때문에 서비스가 흔들리는 경험도 있었습니다.

    그래서 이번 글에서는 Kubernetes VPA HPA를 비교 중심으로 정리해보겠습니다. 단순 개념 비교가 아니라, 오토스케일링 비교 관점에서 어떤 워크로드에 무엇이 맞는지, 그리고 리소스 최적화와 Pod 스케일링을 어떻게 나눠서 생각해야 하는지 실제 운영자 시선으로 풀어보겠습니다. 혹시 지금 클러스터에서 CPU는 남는데 응답 속도는 들쭉날쭉하고, 어떤 서비스는 OOMKilled(메모리 부족 종료)까지 난다면 이 주제가 꽤 중요하실 거예요.

    HPA는 Pod 개수를, VPA는 Pod 자원 요청값을 조정한다는 차이를 한눈에 보여주는 개요 이미지입니다.

    1. 왜 Kubernetes VPA HPA 비교가 중요한가

    쉽게 말해 HPA는 옆으로 늘리는 방식이고, VPA는 위로 키우는 방식이에요. 둘 다 오토스케일링이긴 한데 해결하는 문제가 달라요. 여기서 중요한 포인트가 있어요. 트래픽이 몰릴 때 모든 문제가 Pod 개수 부족 때문에 생기는 건 아니거든요. 어떤 앱은 싱글 Pod당 메모리를 더 줘야 안정적이고, 어떤 앱은 그냥 복제본을 여러 개 띄우는 게 훨씬 낫다니까요.

    • HPA: 평균 CPU 사용률이나 메모리, 혹은 Custom Metric(커스텀 메트릭), External Metric(외부 메트릭)을 기준으로 Replica 수를 조절해요.
    • VPA: Pod의 requests/limits 같은 리소스 설정을 추천하거나 자동 조정합니다.
    • 핵심 차이: HPA는 분산 처리에 강하고, VPA는 개별 Pod의 자원 부족 문제를 다루는 데 유리해요.

    제가 직접 해보니 웹 애플리케이션처럼 상태가 거의 없고 수평 확장이 쉬운 경우에는 HPA가 훨씬 직관적이었어요. 반면 배치 작업이나 메모리 사용량이 시간이 지나면서 조금씩 커지는 워크로드는 VPA의 추천값이 꽤 도움이 됐습니다. 이거 진짜 편하더라고요. 다만 자동 적용은 신중해야 했어요.

    2. 개념 정리: VPA vs HPA를 쉽게 말해보면

    2-1. HPA는 언제 쓰나

    HPA는 요청이 갑자기 몰리는 서비스에 잘 맞아요. 예를 들어 API 서버, 프론트엔드 백엔드, 이벤트 소비자를 여러 개 띄워 병렬 처리할 수 있는 구조라면 HPA가 기본 선택지가 되거든요. Metrics Server(메트릭 서버)나 Prometheus Adapter(프로메테우스 어댑터)와 함께 쓰는 경우가 많습니다.

    • 장점: 빠르게 Replica를 늘려 트래픽을 분산할 수 있어요.
    • 장점: 무상태(Stateless, 상태 비저장) 서비스에 특히 잘 맞습니다.
    • 주의: 시작 시간이 긴 앱은 스케일 아웃이 늦게 체감될 수 있어요.

    2-2. VPA는 언제 쓰나

    VPA는 “이 Pod에 CPU 100m만 준 게 애초에 잘못된 거 아닌가?” 같은 상황에서 정말 빛을 봐요. 실제 사용량을 보고 requests를 추천해주기 때문에, 운영자가 감으로 자원값을 넣던 습관에서 벗어나는 데 정말 도움이 돼요. 처음엔 이게 뭔가 싶었는데 추천 모드부터 보기 시작하면 생각보다 실용적이더라고요.

    • 장점: 과소 설정된 requests/limits를 바로잡는 데 좋아요.
    • 장점: 장기적으로 노드 자원 낭비를 줄이는 리소스 최적화에 유리해요.
    • 주의: 자원값 변경을 적용하는 과정에서 Pod 재시작이 개입될 수 있습니다.

    2-3. 한눈에 보는 오토스케일링 비교

    항목 HPA VPA
    무엇을 조절하나 Replica 수 Pod requests/limits
    잘 맞는 대상 웹/API, 무상태 서비스 배치, 메모리 민감 워크로드
    주요 지표 CPU, 메모리, 커스텀/외부 메트릭 실사용 리소스 기반 추천
    반응 방식 수평 확장/축소 수직 조정
    운영 포인트 급격한 부하 대응 초기 자원 설정 보정
    주의점 잘못된 메트릭 설계 시 오동작 적용 시 재시작 영향 가능

    정리하면 HPA는 트래픽 대응, VPA는 자원 설정 보정에 가깝습니다. 둘 중 하나만 정답이라기보다 워크로드 성격에 따라 고르는 문제예요.

    3. 실전 구현: HPA부터 적용해보겠습니다

    실제로 써보니까 대부분 팀은 HPA부터 시작하는 편이 안정적이었어요. 이유가 간단해요. 애플리케이션을 재시작하지 않고도 Replica 수 조절로 대응 가능한 경우가 많기 때문입니다.

    3-1. 전제 조건 확인

    1. 클러스터에 Metrics Server가 있어야 해요.
    2. Deployment에 requests 값이 어느 정도 합리적으로 들어가 있어야 합니다.
    3. readinessProbe(레디니스 프로브)와 livenessProbe(라이브니스 프로브)가 정리되어 있으면 더 좋아요.

    여기서 requests가 엉망이면 HPA 기준도 같이 흔들려버려요. 이 부분을 무시하고 들어가면 나중에 “왜 평균 CPU가 이상하지?” 하면서 삽질 좀 했습니다 ㅎㅎ

    3-2. 샘플 Deployment

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: demo-api
          image: nginx:stable
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          ports:
            - containerPort: 80

    3-3. HPA 리소스 생성

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: demo-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo-api
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    kubectl apply -f deployment.yaml
kubectl apply -f hpa.yaml
kubectl get hpa
kubectl describe hpa demo-api-hpa

    이 상태에서 부하 테스트를 걸면 평균 CPU 사용률을 기준으로 Replica가 늘어나요. 물론 바로 늘지 않는다고 당황하실 필요는 없습니다. 메트릭 수집 주기와 안정화 구간 때문에 약간의 시간차가 생기거든요.

    Kubernetes HPA가 Metrics Server 기반으로 Pod 스케일링하는 구성도

    Metrics Server에서 수집한 지표를 바탕으로 HPA가 Deployment Replica 수를 조정하는 구성 예시입니다.

    4. 실전 구현: VPA는 추천 모드부터 시작하는 게 안전합니다

    VPA는 개인적으로 처음부터 Auto 모드로 넣기보다 Recommendation(추천) 확인부터 시작하는 걸 권장해요. 저도 초반에는 자동 조정이 멋져 보여서 바로 적용하고 싶었는데, 운영 중 Pod 교체 타이밍을 무시하면 생각보다 거칠게 느껴질 수 있더라고요.

    4-1. VPA 샘플 리소스

    apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: demo-api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo-api
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
      - containerName: demo-api
        controlledResources: ["cpu", "memory"]
    kubectl apply -f vpa.yaml
kubectl describe vpa demo-api-vpa

    updateMode: "Off"로 두면 자동 반영은 하지 않고 추천값 위주로 볼 수 있어요. 운영 초반에는 이 방식이 훨씬 덜 위험합니다.

    4-2. 추천값을 어떻게 읽나

    보통 운영자가 보는 포인트는 이렇습니다.

    • 현재 requests가 실제 사용량보다 너무 작은가
    • 메모리 사용 패턴이 일정한가, 피크가 큰가
    • 권장값을 적용했을 때 노드 밀도(Node Density, 노드당 수용량)가 나빠지지 않는가

    제가 직접 해보니 CPU는 HPA가 어느 정도 흡수해주는데, 메모리는 오히려 VPA 추천이 더 실무적으로 도움이 되는 경우가 많았어요. 특히 Java 계열이나 캐시가 붙은 워크로드는 순간 피크보다 장기 패턴을 보는 게 중요하더라고요.

    5. 같이 쓰면 안 되는 건가요? 조합 전략이 핵심입니다

    이 질문 정말 많이 나와요. 결론부터 말하면 무조건 같이 쓰면 안 된다는 아니에요. 다만 같은 CPU/메모리 지표를 기준으로 HPA와 VPA가 동시에 서로를 흔드는 구조는 피하는 게 좋습니다. 이건 운영해보면 왜 위험한지 금방 느껴져요.

    조합 방식 추천 여부 이유
    HPA on CPU + VPA on CPU/Memory 자동 주의 requests 변경이 HPA 계산에 영향 주어 피드백 루프 가능
    HPA on Custom Metric + VPA on requests 추천 권장 역할 분리가 비교적 명확해요
    HPA만 사용 권장 무상태 웹 서비스 기본 선택지로 단순해요
    VPA 추천만 사용 권장 초기 자원 튜닝 단계에 안정적이에요

    즉, Pod 스케일링은 HPA가 맡고, VPA는 추천과 보정 역할로 두는 식이 현실적입니다. 특히 트래픽 기반 서비스라면 HPA를 메인으로 두고, VPA는 운영 관찰 도구처럼 활용하는 접근이 꽤 괜찮았어요.

    Kubernetes VPA HPA 함께 사용할 때의 권장 조합과 충돌 위험 다이어그램

    HPA와 VPA를 함께 사용할 때 역할을 분리하는 권장 패턴과 충돌 위험 구간을 시각화한 이미지입니다.

    6. ⚠️ 실제 운영에서 자주 만난 문제와 해결법

    6-1. HPA가 안 늘어나는 문제

    • 원인: Metrics Server 미설치 또는 메트릭 수집 실패
    • 원인: requests 값이 비현실적이라 CPU 사용률 계산이 왜곡돼요
    • 해결: kubectl top pod, kubectl describe hpa로 먼저 메트릭 상태 확인
    kubectl top pod
kubectl describe hpa demo-api-hpa
kubectl get apiservices

    저도 처음엔 애플리케이션 성능 문제인 줄 알고 로그만 뒤졌는데, 알고 보니 메트릭 자체가 비어 있던 적이 있었어요. 이런 건 진짜 허무합니다.

    6-2. VPA 적용 후 Pod 재시작 때문에 놀라는 문제

    • 원인: 자원값 변경을 적용하려면 기존 Pod 교체가 필요할 수 있거든요
    • 해결: 먼저 추천 모드로 충분히 관찰하고, PDB(PodDisruptionBudget, Pod 중단 예산)와 롤링 업데이트 전략 점검
    • 해결: 단일 Replica 서비스는 특히 조심해야 해요

    여기서 중요한 포인트! 단일 Pod 서비스에 VPA 자동 적용은 생각보다 부담이 커요. 실제로 써보니까 “자원은 맞아졌는데 순간 끊김이 생겼네?” 같은 상황이 나올 수 있더라고요.

    6-3. HPA와 VPA를 동시에 걸었더니 지표가 이상한 문제

    • 원인: VPA가 requests를 바꾸면 HPA의 utilization 계산 기준도 달라질 수 있거든요
    • 해결: HPA는 CPU 대신 QPS(Requests Per Second, 초당 요청 수)나 큐 길이 같은 Custom/External Metric 기반으로 분리 검토해요

    이 부분은 문서만 읽으면 감이 잘 안 오는데, 운영 그래프를 보면 이해가 돼요. 기준점이 움직이는 상태에서 자동화 둘이 같이 판단하니 안정적이지 않더라고요.

    7. 검증과 결과 확인: 무엇을 봐야 제대로 적용한 걸까

    오토스케일링 비교는 설정 파일만 보고 끝내면 안 돼요. 검증 항목을 꼭 정해두셔야 합니다.

    1. 부하 테스트 전후 평균 응답 시간 변화
    2. Replica 증가 시 에러율 변화
    3. OOMKilled 발생 여부
    4. 노드 자원 사용률과 Bin Packing(빈 패킹, 노드 자원 배치 효율)
    5. 스케일 아웃/인 빈도와 안정성
    kubectl get hpa -w
kubectl get vpa
kubectl top pod
kubectl top node

    제가 홈랩에서 테스트했을 때도, HPA만 걸어둔 서비스는 트래픽 대응은 빨랐지만 requests가 너무 작게 잡힌 컨테이너는 CPU 제한에 자주 걸렸어요. 반대로 VPA 추천을 반영하고 나니 자원 낭비는 줄고 불안정성도 꽤 줄었습니다. 드디어 됐다! 싶은 순간이 오긴 하더라고요. 물론 그 전에 requests 값과 메트릭 파이프라인 때문에 몇 번 헤맸습니다.

    Kubernetes VPA HPA 적용 결과를 검증하는 모니터링 대시보드

    HPA와 VPA 적용 이후 Replica 변화, CPU/메모리 추이, 권장 자원값을 검증하는 모니터링 예시입니다.

    8. 어떤 워크로드에 무엇이 맞나: 실무 선택 기준

    • 웹/API 서버: HPA 우선. 빠른 Pod 스케일링이 중요해요.
    • 배치 작업: VPA 추천이 유용할 수 있어요. 작업 특성상 개별 Pod 자원량이 중요하거든요.
    • 메모리 민감 애플리케이션: VPA 추천으로 기준값 정리 후 신중히 반영
    • 큐 소비자/워커: HPA를 큐 길이나 지연 시간 기반으로 설계하면 좋습니다.
    • 단일 인스턴스성 서비스: VPA 자동 적용은 매우 조심해야 해요. 먼저 수동 조정 검토

    결국 Kubernetes VPA HPA는 경쟁 관계라기보다 역할이 다른 도구예요. 리소스 최적화가 우선인지, 트래픽 분산이 우선인지부터 정해야 선택이 쉬워집니다.

    9. 정리와 FAQ

    정리하면, HPA는 서비스 확장성에, VPA는 자원 적정화에 강합니다. 저는 운영 초기에 HPA로 안정적인 Pod 스케일링 구조를 먼저 만들고, 그다음 VPA 추천으로 requests/limits를 보정하는 순서를 권장해요. 이 흐름이 가장 덜 아프고, 실수했을 때 되돌리기도 쉽습니다.

    다음 글에서는 Cluster Autoscaler(클러스터 오토스케일러, 노드 수 자동 조절)까지 포함해서 노드 레벨 확장 전략도 다뤄볼 예정입니다. 이전 글에서 다룬 Ingress와 Observability(옵저버빌리티, 관측성) 구성이 되어 있으면 검증이 훨씬 수월해요.

    워크로드 유형에 따라 VPA와 HPA를 어떻게 선택할지 빠르게 판단할 수 있는 요약 인포그래픽입니다.

    자주 묻는 질문

    • Q. 둘 중 하나만 써야 하나요?
      A. 아니에요. 다만 같은 CPU/메모리 기준으로 동시에 자동 제어하는 구성은 주의가 필요합니다.
    • Q. 초보자는 무엇부터 시작하면 좋을까요?
      A. HPA부터 시작하고, VPA는 추천 모드로 관찰하는 접근이 가장 무난했어요.
    • Q. 리소스 최적화 목적이면 바로 VPA Auto로 가도 되나요?
      A. 운영 중 서비스라면 추천값 검증 후 단계적으로 가는 쪽이 안전합니다.
  • [k8s] Loki로 Kubernetes 로그 중앙화: 효율적인 모니터링 구축 가이드

    [k8s] Loki로 Kubernetes 로그 중앙화: 효율적인 모니터링 구축 가이드

    목차

    [k8s] Loki로 Kubernetes 로그 중앙화: 효율적인 모니터링 구축 가이드

    Kubernetes 환경을 운영하다 보면 결국 로그 때문에 한 번은 크게 삽질하게 됩니다. Pod(파드)가 재시작되면 이전 로그가 날아가고, 노드가 여러 대로 늘어나면 어디서 무슨 에러가 터졌는지 찾는 데 시간이 꽤 걸리거든요. 저도 홈랩과 실무 환경에서 비슷한 문제를 겪으면서 Loki Kubernetes 로그 구성을 진지하게 붙잡게 됐습니다. 처음엔 “그냥 kubectl logs로 보면 되지 않나?” 싶었는데, 운영 규모가 조금만 커져도 그 방식은 금방 한계가 오더라고요.

    그래서 이번 글에서는 Grafana Loki를 기준으로 Kubernetes 로그 수집과 중앙 집중형 로깅 구성을 어떻게 가져가면 좋은지, 제가 직접 해보면서 정리한 흐름으로 풀어보겠습니다. 너무 이론만 길게 가지 않고, 바로 써먹을 수 있는 형태로 설명드릴게요.

    Loki, Promtail, Grafana, Kubernetes 노드와 애플리케이션 로그 흐름을 한눈에 보여주는 전체 구성도입니다.

    Loki로 Kubernetes 로그를 모아야 하는 이유

    쉽게 말해 Loki는 로그를 저장하고 검색하기 위한 시스템입니다. 로그 전체를 무겁게 색인(indexing)하는 방식보다는, 메타데이터(label) 중심으로 다루는 접근이 특징이죠. 이게 왜 좋냐면, 운영 입장에서 필요한 로그를 비교적 효율적으로 모으고 찾는 데 유리하거든요.

    제가 처음 Loki를 붙여봤을 때 좋았던 점은 딱 세 가지였습니다.

    • Grafana(그라파나)와 궁합이 좋습니다. 로그 조회 화면이 익숙해서 진입 장벽이 낮더라고요.
    • Kubernetes 로그 수집 흐름을 만들기 편합니다. 특히 DaemonSet(데몬셋) 기반 수집기가 노드별 로그를 긁어오는 구조가 이해하기 쉬웠습니다.
    • 메트릭(metrics), 로그(logs), 추적(traces) 관측 체계를 한 방향으로 정리하기 좋습니다.

    물론 무조건 Loki만 정답은 아닙니다. Elasticsearch(엘라스틱서치) 계열이 더 맞는 조직도 있습니다. 다만 “복잡도를 조금 낮추면서 Kubernetes 로그를 중앙에서 보고 싶다”는 목적이라면 Loki는 꽤 현실적인 선택지에요.

    Grafana Loki 핵심 개념부터 먼저 잡아보겠습니다

    Loki, Promtail, Grafana 역할 구분

    구성요소 역할 운영 포인트
    Loki 로그 저장 및 조회 API 제공 라벨 설계가 중요합니다
    Promtail 노드의 로그 파일 수집 후 Loki로 전송 DaemonSet으로 배포하는 경우가 많습니다
    Grafana 로그 검색, 필터링, 시각화 처리 대시보드와 Explore 기능이 편합니다

    여기서 중요한 포인트! Promtail(프롬테일)이 하는 역할은 로그를 읽어 Loki로 보내는 수집기 일이죠. Kubernetes에서는 보통 컨테이너 로그가 노드 파일 시스템에 쌓이기 때문에, 노드마다 하나씩 떠 있는 DaemonSet이 그 로그를 읽는 구조를 많이 씁니다.

    라벨(Label)이 왜 중요할까요?

    Loki는 라벨 기반으로 로그를 찾습니다. 예를 들면 namespace, pod, container, app 같은 값들이죠. 실제로 써보니까 라벨을 너무 많이 붙이면 관리가 복잡해지고, 반대로 너무 적으면 검색이 답답하더라고요. 저도 처음엔 이것저것 다 넣었다가 쿼리가 지저분해져서 다시 정리했었습니다 ㅎㅎ

    • 자주 검색하는 기준만 라벨로 둡니다
    • 변동성이 큰 값은 라벨 남발을 피합니다
    • 운영팀이 실제로 찾는 축을 먼저 정합니다

    Kubernetes 로그 중앙화 구성 흐름

    전체 흐름은 생각보다 단순합니다.

    1. 애플리케이션 컨테이너가 표준 출력(stdout/stderr)으로 로그를 남깁니다.
    2. Kubernetes 노드가 해당 로그를 파일 형태로 보관합니다.
    3. Promtail이 노드에서 로그를 읽고 라벨을 붙입니다.
    4. Loki가 로그를 저장합니다.
    5. Grafana에서 검색하고 필터링합니다.

    이 구조가 좋은 이유는 애플리케이션 코드를 크게 건드리지 않아도 된다는 거거든요. 이미 컨테이너 표준 출력으로 로그를 잘 남기고 있다면, 인프라 쪽에서 수집 체계를 붙이기 좋습니다.

    실전 구현: Helm으로 Loki와 Promtail 배포하기

    이제 본격적으로 들어가 보겠습니다. 여기서는 많이 쓰는 Helm(헬름) 기반 예시로 설명드릴게요. 실제 운영 환경에서는 스토리지, 보존 기간, 인증, 멀티 테넌시 여부 등을 더 따져야 하지만, 처음 시작할 때는 흐름을 먼저 잡는 게 중요합니다.

    1. 네임스페이스 생성

    kubectl create namespace observability

    저는 보통 모니터링/로깅 계열 리소스를 따로 분리하려고 observability 같은 네임스페이스를 씁니다. 꼭 이 이름일 필요는 없어요.

    2. Helm 저장소 추가

    helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

    3. Loki values 파일 작성

    처음엔 기본값으로도 올라가긴 하는데, 최소한 배포 형태와 저장 방식은 눈으로 확인하고 가는 게 좋습니다.

    loki:
  auth_enabled: false

singleBinary:
  replicas: 1

gateway:
  enabled: true

monitoring:
  dashboards:
    enabled: true
  rules:
    enabled: true

    테스트나 홈랩에서는 이렇게 단순하게 시작해도 됩니다. 다만 운영에서는 스토리지 백엔드와 고가용성 구성을 별도로 검토하셔야 합니다. 여기서 무작정 단일 인스턴스로 오래 끌고 가면 나중에 확장 시점에 다시 손이 많이 가더라고요.

    4. Loki 설치

    helm install loki grafana/loki -n observability -f loki-values.yaml

    5. Promtail values 파일 작성

    config:
  clients:
    - url: http://loki-gateway.observability.svc.cluster.local/loki/api/v1/push

  snippets:
    pipelineStages:
      - cri: {}

  positions:
    filename: /run/promtail/positions.yaml

  scrapeConfigs:
    - job_name: kubernetes-pods
      kubernetes_sd_configs:
        - role: pod
      relabel_configs:
        - source_labels: [__meta_kubernetes_namespace]
          target_label: namespace
        - source_labels: [__meta_kubernetes_pod_name]
          target_label: pod
        - source_labels: [__meta_kubernetes_pod_container_name]
          target_label: container
        - source_labels: [__meta_kubernetes_pod_label_app]
          target_label: app

    이 부분이 핵심입니다. 어떤 Kubernetes 메타데이터를 라벨로 가져갈지 결정하는 구간이거든요. 제가 실제로 써보니까 namespace, pod, container, app 정도부터 시작하는 게 무난했습니다.

    Kubernetes 로그 수집을 위한 Promtail과 Grafana Loki 구성도

    Promtail DaemonSet이 각 노드의 컨테이너 로그 파일을 읽고 라벨을 붙여 Loki로 보내는 흐름을 설명하는 이미지입니다.

    6. Promtail 설치

    helm install promtail grafana/promtail -n observability -f promtail-values.yaml

    7. Grafana에서 데이터 소스 연결

    Grafana를 이미 쓰고 계신다면 Loki 데이터 소스를 추가하면 됩니다. 같은 클러스터 안에 있다면 서비스 이름으로 연결하는 경우가 많습니다.

    kubectl get svc -n observability

    Grafana Explore 화면에서 Loki를 선택하고 아래처럼 조회해보면 기본 파이프라인이 제대로 도는지 확인할 수 있어요.

    {namespace="default"}

    처음 이 쿼리로 로그가 딱 뜨는 순간, 드디어 됐다! 싶은 느낌이 있습니다. 로그 중앙화는 여기서부터가 시작이거든요.

    운영하면서 유용했던 로그 쿼리 예시

    Loki는 LogQL(로그쿼리언어) 형태로 조회합니다. 익숙해지면 꽤 편합니다.

    {namespace="production", app="nginx"}
{namespace="production", pod=~"api-.*"}
{container="backend"} |= "error"
{app="payments"} |= "timeout"
    • |= 는 특정 문자열 포함 검색에 자주 씁니다
    • 정규식 매칭은 필요한 곳에만 씁니다
    • 라벨 기준 필터를 먼저 좁히고 문자열 검색을 붙이면 보기가 편합니다

    이 부분은 팀 내에서 공통 조회 패턴을 만들어두면 좋습니다. 예를 들어 장애 대응 때 “namespace 먼저, app 다음, error 문자열 마지막” 같은 식으로 말이죠.

    ⚠️ 실제로 많이 겪는 문제와 트러블슈팅

    여기서부터는 제가 꽤 자주 봤던 문제들입니다. 저도 처음엔 헷갈렸는데, 한 번 원리를 이해하고 나면 금방 잡힙니다.

    1. 로그가 아예 안 들어오는 경우

    • Promtail Pod가 정상 실행 중인지 확인합니다
    • Loki push URL이 올바른지 봅니다
    • 네트워크 정책(NetworkPolicy)으로 막히지 않았는지 확인합니다
    • 애플리케이션이 파일이 아니라 표준 출력으로 로그를 남기는지 확인합니다
    kubectl get pods -n observability
kubectl logs -n observability daemonset/promtail
kubectl logs -n observability deploy/loki

    2. 라벨이 너무 많아져서 조회가 복잡한 경우

    이건 정말 흔합니다. Kubernetes 메타데이터를 다 가져오고 싶은 마음이 들거든요. 근데 운영해보면 자주 안 쓰는 라벨은 오히려 방해가 됩니다. 중앙 집중형 로깅의 목적은 데이터를 많이 붙이는 게 아니라, 필요한 순간 빨리 찾는 데 있다는 점을 잊지 않는 게 중요합니다.

    3. 특정 Pod 로그만 유독 안 보이는 경우

    보통 라벨 매핑 문제이거나, 애플리케이션 로그 출력 방식 차이인 경우가 많았습니다. 사이드카(sidecar)를 쓰는 구조나 멀티 컨테이너 Pod에서는 컨테이너 이름 기준으로 먼저 좁혀보는 게 좋더라고요.

    4. 과거 로그를 오래 보관하고 싶은 경우

    이건 저장소 설계와 연결됩니다. 홈랩에서는 일단 짧게 가져가도 되는데, 운영에서는 보존 정책(retention policy)을 꼭 먼저 정하셔야 합니다. 로그는 쌓이는 속도가 생각보다 빠릅니다. 처음엔 괜찮다가 어느 날 저장소가 가득 차서 당황하는 경우가 생기거든요.

    검증: Loki Kubernetes 로그가 제대로 모이는지 확인하기

    설치가 끝났다고 바로 안심하면 안 됩니다. 꼭 검증 단계를 거치셔야 합니다. 저는 아래 순서로 확인합니다.

    1. 테스트용 Pod를 띄워 의도적으로 로그를 발생시킵니다.
    2. Promtail 로그에서 수집 관련 에러가 없는지 봅니다.
    3. Grafana Explore에서 namespace와 pod 기준으로 조회합니다.
    4. 문자열 필터로 원하는 로그를 찾을 수 있는지 확인합니다.
    kubectl run log-check --image=busybox --restart=Never -- /bin/sh -c 'i=0; while true; do echo "log-check-$i"; i=$((i+1)); sleep 5; done'

    그 다음 Grafana에서 아래처럼 조회합니다.

    {pod="log-check"}

    이렇게 테스트 로그가 보이면 기본 파이프라인은 정상입니다. 이후엔 에러 패턴, 특정 앱 로그, 운영 네임스페이스 로그를 차례로 점검하면 됩니다.

    Grafana Loki로 Kubernetes 로그를 조회하는 대시보드 이미지

    Grafana Explore 또는 대시보드에서 namespace, pod, app 라벨로 로그를 필터링한 결과 예시 이미지입니다.

    비교: Loki와 다른 로그 수집 접근의 차이

    항목 Loki 중심 구성 전통적 대용량 검색 중심 구성
    초기 진입 난이도 상대적으로 단순한 편 구성 요소가 많은 편
    Grafana 연동 매우 자연스러움 별도 연계 구성이 필요할 수 있음
    라벨 설계 중요도 매우 높음 상대적으로 검색 중심 접근 가능
    홈랩/소규모 시작 부담이 덜함 조금 무거울 수 있음

    이 표를 보면 감이 오실 겁니다. “빠르게 Kubernetes 로그 중앙화를 시작하고 싶다”면 Loki가 꽤 괜찮습니다. 반대로 아주 복잡한 검색 시나리오, 대규모 장기 보관 전략, 조직 표준 스택이 이미 정해져 있다면 다른 선택지가 더 맞을 수도 있어요.

    💡 운영 팁: 제가 나중에 꼭 챙기게 된 것들

    • 라벨 최소화: 처음부터 과하게 넣지 않습니다
    • 보존 정책: 저장소 사용량을 반드시 같이 봅니다
    • 대시보드 표준화: 팀이 자주 보는 쿼리를 정리합니다
    • 애플리케이션 로그 형식: JSON 로그 여부를 팀 기준으로 맞추면 훨씬 편합니다
    • 장애 대응 문서화: “로그가 안 보일 때 체크리스트”를 만들어두면 좋습니다

    특히 JSON 형태 로그를 쓰는 팀이라면 이후 파싱과 필드 추출도 훨씬 수월해집니다. Kubernetes 로그 수집을 이렇게 중앙화하면 메트릭 모니터링과 함께 관측성(Observability, 시스템 상태를 외부 신호로 이해하는 능력)이 한 단계 올라가는 걸 체감하실 겁니다.

    중앙 집중형 로깅 도입 전후 Loki Kubernetes 로그 운영 비교 이미지

    kubectl logs 중심 운영과 Loki 기반 중앙 집중형 로깅 운영의 차이를 한눈에 정리한 비교 이미지입니다.

    자주 묻는 질문

    Q1. Kubernetes 로그 수집은 꼭 Promtail이어야 하나요?

    꼭 그렇진 않습니다. 다만 Loki와 가장 자연스럽게 엮이는 수집기로 많이 사용됩니다. 시작 단계에서는 조합이 단순한 쪽이 유지보수에 유리하더라고요.

    Q2. Grafana Loki만 설치하면 끝인가요?

    아닙니다. 저장소, 보존 정책, 접근 제어, 대시보드 표준화까지 같이 봐야 운영 품질이 올라갑니다. 설치보다 운영 기준을 세우는 게 더 중요합니다.

    Q3. 중앙 집중형 로깅이 왜 필요한가요?

    장애 대응 속도가 달라집니다. 노드와 Pod를 옮겨 다니며 로그를 찾는 시간을 줄일 수 있거든요. 특히 여러 서비스가 동시에 얽히는 환경에서는 체감 차이가 큽니다.

    마무리: Loki Kubernetes 로그 구성, 처음엔 단순하게 시작하세요

    정리해보면 Loki Kubernetes 로그 구성의 핵심은 화려한 기능보다도, 어떤 로그를 어떤 라벨로 모을지를 먼저 정하는 데 있습니다. 저도 처음엔 설정 파일만 붙잡고 씨름했었는데, 결국 답은 단순하더라고요. 필요한 로그를 빨리 찾을 수 있느냐, 장애 때 팀이 같은 화면을 보고 이야기할 수 있느냐, 그게 제일 중요했습니다.

    처음 구축하신다면 작은 범위에서 시작해보세요. 특정 네임스페이스 하나, 서비스 하나부터 붙여보고, 쿼리 패턴을 정리한 다음 확장하는 방식이 훨씬 덜 힘듭니다. 실제로 써보니까 이게 가장 덜 삽질하는 길이었습니다. 혹시 지금 Grafana Loki 도입을 고민 중이시라면, 이번 주말 홈랩에서라도 한 번 꼭 올려보세요. 생각보다 금방 감이 옵니다.

  • [k8s] EKS 운영 비용 최적화 전략: 클라우드 지출 효율 높이기

    [k8s] EKS 운영 비용 최적화 전략: 클라우드 지출 효율 높이기

    목차

    [클라우드] EKS 비용 최적화 전략: 클라우드 지출 효율 높이기

    EKS 비용 최적화는 AWS를 오래 운영할수록 더 민감해지는 주제입니다. 처음엔 서비스만 잘 뜨면 된다고 생각했는데, 어느 순간 청구서를 보면 CPU는 놀고 있고 노드는 과하게 떠 있고, 로그 저장 비용까지 슬금슬금 올라가더라고요. 저도 홈랩과 실제 운영 환경을 오가면서 비슷한 패턴을 여러 번 봤습니다. 특히 AWS EKS 운영을 하다 보면 워크로드는 늘지 않았는데 비용만 올라가는 구간이 꼭 옵니다. 그 시점부터는 성능 튜닝보다 먼저 해야 할 일이 비용 구조를 보는 일입니다.

    이번 글에서는 제가 직접 현장에서 자주 적용했던 방법들을 공유하려고 합니다. Kubernetes(쿠버네티스) 클러스터에서 어디서 돈이 새는지, 어떤 순서로 손봐야 하는지 정리해볼 거예요. 무작정 인스턴스를 내리는 이야기가 아니라, 서비스 안정성을 최대한 해치지 않으면서 Kubernetes 비용 절감과 클라우드 비용 관리를 같이 가져가는 방법에 가깝습니다.

    EKS 비용 최적화 구조를 보여주는 아키텍처 다이어그램

    EKS 비용 구조를 노드, 스토리지, 네트워크, 관측 영역으로 나눠 보여주는 개요 이미지입니다.

    1. 왜 EKS 비용은 생각보다 빨리 커질까요?

    쉽게 말해 EKS는 “컨테이너만 쓰는 서비스”가 아닙니다. 실제 청구는 여러 층에서 발생하거든요. 컨트롤 플레인(Control Plane, 클러스터 제어 영역), EC2 노드(Node, 워커 서버), EBS(Elastic Block Store, 블록 스토리지), 데이터 전송, 로드밸런서, 로그 수집까지 다 합쳐져서 나옵니다. 그래서 Pod(파드) 몇 개 줄였다고 체감이 바로 안 오는 경우도 많습니다.

    • 노드 과할당: 요청 리소스(request)가 실제 사용량보다 과하게 잡혀서 빈 서버를 계속 유지합니다.
    • 상시 고정 용량: 피크 시간 기준으로 노드를 잡아두고 하루 종일 유지합니다.
    • 분산 실패: 비슷한 워크로드가 여러 노드에 흩어져서 스케일 인(scale-in)이 안 됩니다.
    • 스토리지/로그 방치: 안 쓰는 볼륨, 긴 로그 보관 기간이 누적됩니다.
    • 네트워크 비용 누락: NAT Gateway, AZ 간 트래픽, Load Balancer 비용이 생각보다 큽니다.

    여기서 중요한 포인트! EKS 비용 최적화는 “할인 상품 먼저 사기”보다 현재 사용 패턴을 정상화하는 게 우선입니다. 저도 처음엔 Savings Plans(세이빙 플랜)부터 볼까 했었는데, 실제로는 잘못된 리소스 요청값부터 정리하는 게 훨씬 효과가 컸습니다.

    2. EKS 비용을 볼 때 꼭 나눠야 하는 4가지 축

    제가 비용 분석할 때는 항상 네 가지로 쪼갭니다. 이렇게 나누면 어디를 먼저 줄여야 할지가 보입니다.

    영역 무엇을 보나 자주 나오는 문제 우선 대응
    Compute EC2 노드, Fargate 사용량 낮은 사용률, 과한 노드 수 오토스케일링, Bin Packing
    Storage EBS, 스냅샷, 로그 저장 미사용 볼륨, 긴 보관 기간 수명주기 관리, 정리 자동화
    Network Load Balancer, NAT, 트래픽 불필요한 외부 통신 경로 엔드포인트, 경로 단순화
    Observability 로그, 메트릭, 트레이싱 수집 과다, 샘플링 없음 필드 축소, 보관 기간 재설계

    이 표를 기준으로 보면, 같은 “클라우드 비용 관리”라도 접근 방식이 완전히 달라집니다. 노드 문제를 로그 보관 기간으로 해결할 수는 없으니까요.

    3. 실전 1단계: 먼저 현재 사용량을 수치로 확인합니다

    비용 최적화는 감으로 하면 거의 실패합니다. 저도 예전에 “이 노드가 제일 비싸 보이네” 하고 줄였다가 배치 작업이 밀린 적이 있었습니다. 삽질 좀 했습니다 ㅎㅎ 그래서 지금은 반드시 사용량과 요청값을 같이 봅니다.

    1. namespace(네임스페이스)별로 어떤 팀/서비스가 많이 쓰는지 확인합니다.
    2. CPU/메모리 실제 사용량과 requests/limits 차이를 봅니다.
    3. 노드별 유휴율과 스케일 인 가능 여부를 확인합니다.
    4. Spot(스팟) 전환 가능한 워크로드를 분류합니다.
    kubectl top nodes
kubectl top pods -A --sort-by=cpu
kubectl top pods -A --sort-by=memory
kubectl get pods -A -o wide
kubectl describe node <node-name>

    여기에 metrics-server(메트릭 서버)나 Prometheus(프로메테우스, 모니터링 시스템)가 붙어 있으면 더 좋습니다. 핵심은 “실사용량 대비 요청값이 얼마나 부풀어 있는가”입니다. 실제로 써보니까 메모리 request를 넉넉하게 잡아둔 서비스들이 클러스터 비용을 조용히 밀어올리는 경우가 정말 많더라고요.

    4. 실전 2단계: Node Group과 Autoscaling 구조부터 손봅니다

    AWS EKS 운영에서 비용이 가장 크게 흔들리는 영역은 대체로 노드입니다. 그래서 저는 여기부터 들어갑니다. 대표적으로 Managed Node Group(관리형 노드 그룹)과 Karpenter(카펜터, 워크로드 기반 노드 프로비저닝 도구), Cluster Autoscaler(클러스터 오토스케일러)를 조합해 구조를 정리합니다.

    운영 팁을 하나 말씀드리면, 모든 워크로드를 한 종류 노드에 태우는 건 나중에 꼭 비용 문제로 돌아옵니다. On-Demand(온디맨드)와 Spot을 분리하고, 시스템 워크로드와 일반 애플리케이션 워크로드를 구분해두는 게 좋습니다.

    EKS 비용 최적화를 위한 온디맨드와 스팟 노드 분리 구성 이미지

    시스템 워크로드는 안정적인 온디맨드 노드에, 일반 서비스는 스팟 노드에도 분산하는 구성 예시입니다.

    추천 접근 방식

    • 기반 시스템용 소규모 온디맨드 노드 그룹 유지
    • 일반 웹/API 워크로드는 오토스케일링 대상 그룹으로 분리
    • 중단 허용 가능한 배치/잡(Job)은 스팟 전용으로 이동
    • Pod Disruption Budget(파드 중단 예산)과 anti-affinity를 같이 점검
    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: sample-api
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-api
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

    HPA(Horizontal Pod Autoscaler, 수평 파드 오토스케일러)를 붙일 때도 request 값이 엉망이면 오토스케일 기준이 제대로 안 먹히더라고요. 그래서 request/right-sizing(라이트사이징, 적정 용량 조정)을 먼저 하고 HPA를 적용하는 순서가 훨씬 안정적입니다.

    5. 실전 3단계: requests/limits를 줄이는 게 진짜 핵심입니다

    많은 분들이 EKS 비용 최적화라고 하면 인스턴스 타입부터 바꾸는데, 제가 직접 해보니 제일 먼저 손대야 할 건 Deployment(디플로이먼트) 리소스 설정이었습니다. 특히 초기값을 넉넉하게 잡아놓고 그대로 운영하는 팀이 많거든요.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: example/sample-api:stable
          resources:
            requests:
              cpu: "250m"
              memory: "512Mi"
            limits:
              cpu: "500m"
              memory: "1Gi"

    여기서 중요한 건 숫자 자체보다 실측 기반으로 줄였는가입니다. CPU는 낮은데 메모리만 치솟는 애플리케이션도 있고, 반대도 있습니다. VPA(Vertical Pod Autoscaler, 수직 파드 오토스케일러)를 참고용으로 쓰거나, 일정 기간 메트릭을 보고 수동 조정해도 충분히 효과를 볼 수 있습니다.

    제가 보통 보는 체크포인트는 이렇습니다.

    • 평균 사용량이 requests의 절반 이하로 오래 유지되는가
    • OOMKilled(메모리 부족 종료) 이력이 있는가
    • 배치 시간대와 일반 시간대 사용 패턴이 다른가
    • limits 때문에 CPU throttling(스로틀링, CPU 제한)이 심한가

    이 단계만 잘해도 Kubernetes 비용 절감 효과가 꽤 크게 납니다. 왜냐하면 스케줄러가 더 촘촘하게 파드를 배치할 수 있어서, 결과적으로 노드 수가 줄어들 가능성이 커지거든요.

    6. 실전 4단계: 로그, 스토리지, 네트워크도 같이 줄여야 합니다

    노드만 줄이고 끝내면 반쪽짜리입니다. CloudWatch Logs(클라우드워치 로그), EBS, Load Balancer, NAT 비용도 무시 못 하거든요. 처음엔 이게 뭔가 싶었는데, 실제 청구를 뜯어보면 로그 저장 비용이 꽤 눈에 띄는 환경도 있습니다.

    aws logs describe-log-groups
aws ec2 describe-volumes --filters Name=status,Values=available
aws elbv2 describe-load-balancers
    • 로그: 디버그 로그 상시 수집 금지, 보관 기간을 서비스 성격에 맞게 분리
    • 스토리지: 미사용 EBS와 오래된 스냅샷 주기 점검
    • 네트워크: 내부 통신은 가능하면 Internal Load Balancer와 VPC Endpoint 활용
    • 이미지: 컨테이너 이미지 크기를 줄여 배포 시간과 캐시 비효율 감소
    EKS 비용 최적화에 포함되는 로그 보관과 EBS 정리 운영 다이어그램

    로그 보관 기간 조정, 미사용 볼륨 점검, 네트워크 경로 단순화 흐름을 설명하는 이미지입니다.

    특히 NAT Gateway 비용은 조용히 커집니다. 외부 API 호출이 많은 워크로드나 잘못된 라우팅 구조가 있으면 생각보다 빨리 누적되더라고요. 혹시 청구서에서 네트워크 비용이 이상하게 높다면, 애플리케이션보다 먼저 통신 경로를 의심해보셔도 좋습니다.

    7. ⚠️ 제가 실제로 자주 본 문제와 트러블슈팅

    비용 줄이다가 장애 내면 말짱 도루묵이죠. 그래서 아래 항목은 꼭 같이 보셔야 합니다.

    1) 스팟 노드만 늘렸더니 서비스가 불안정해진 경우

    해결은 단순합니다. 상태 저장성(Stateful) 워크로드나 핵심 시스템 컴포넌트는 온디맨드에 남기고, 스팟은 중단 허용 가능한 서비스 위주로 태워야 합니다.

    2) request를 너무 낮췄더니 HPA가 과민반응하는 경우

    CPU 기준 HPA는 request 영향을 받습니다. request를 급격히 낮추면 스케일 아웃이 너무 빨라질 수 있습니다. 그래서 한 번에 크게 줄이지 말고, 며칠 단위로 관찰하면서 조정하는 게 안전합니다.

    3) Bin Packing이 안 돼서 노드가 안 줄어드는 경우

    Topology Spread Constraints(토폴로지 분산 제약), anti-affinity, DaemonSet(데몬셋) 자원 점유 때문에 흔히 생깁니다. 저도 처음엔 오토스케일러가 이상한 줄 알았는데, 실제로는 배치 정책 때문에 노드가 비워지지 않더라고요.

    4) 로그를 줄였더니 장애 분석이 어려워진 경우

    모든 로그를 다 버리면 안 됩니다. 애플리케이션 로그는 줄이더라도 감사 로그, 에러 로그, 핵심 접근 로그는 남겨야 합니다. 비용과 가시성(observability, 관측 가능성) 사이에서 선을 잘 잡아야 합니다.

    8. 검증 방법: 비용이 정말 줄었는지 어떻게 확인할까?

    최적화는 적용보다 검증이 더 중요합니다. 저는 보통 2주에서 4주 단위로 비교합니다. 하루 이틀 데이터만 보면 배치, 이벤트 트래픽, 배포 타이밍 때문에 판단이 왜곡되거든요.

    1. 변경 전/후 노드 수와 평균 사용률을 비교합니다.
    2. namespace별 requests 합계를 기록합니다.
    3. CloudWatch 또는 Prometheus에서 CPU/메모리 추세를 봅니다.
    4. AWS Cost Explorer에서 서비스별 비용 추세를 확인합니다.
    5. 장애, 재시작, 응답 지연이 늘지 않았는지 같이 체크합니다.
    EKS 비용 최적화 전후를 비교하는 대시보드 이미지

    변경 전후 비용 추이, 노드 수, CPU/메모리 사용률을 함께 보여주는 검증용 대시보드 이미지입니다.

    검증할 때는 이렇게 보시면 됩니다.

    • 비용은 줄었는데 재시작이 늘었다면 과최적화일 수 있습니다.
    • 노드 수는 같아도 여유 자원이 늘었다면 다음 단계 최적화 여지가 생긴 겁니다.
    • 로그 비용만 줄었다면 Compute 최적화는 아직 덜 된 상태일 수 있습니다.

    드디어 됐다! 싶은 순간은 보통 “같은 트래픽인데 노드 수가 줄고, 장애 지표는 그대로일 때”입니다. 이게 가장 건강한 절감입니다.

    9. 정리: EKS 비용 최적화는 할인보다 구조가 먼저입니다

    오늘 내용을 한 줄로 정리하면 이겁니다. EKS 비용 최적화는 인스턴스 가격표를 보는 작업이 아니라, 워크로드 배치 구조와 리소스 설정을 바로잡는 작업입니다. 저도 처음엔 할인 모델만 찾았었는데, 실제로 써보니까 request 조정, 오토스케일링 구조 정리, 로그/스토리지 수명주기 관리가 훨씬 먼저더라고요.

    • 먼저 실제 사용량을 측정합니다.
    • 그다음 requests/limits를 다듬습니다.
    • 오토스케일링과 스팟 전략을 분리 적용합니다.
    • 스토리지, 로그, 네트워크 비용까지 같이 봅니다.
    • 마지막으로 Cost Explorer와 모니터링으로 검증합니다.
    EKS 비용 최적화 실행 우선순위를 요약한 인포그래픽

    사용량 측정부터 검증까지의 실행 순서를 요약한 체크리스트형 인포그래픽입니다.

    혹시 지금 EKS 청구서를 보고 “분명 서비스는 안 늘었는데 왜 이러지?” 싶으셨다면, 오늘 소개한 순서대로 한 번만 점검해보세요. 차이가 확실할 겁니다. 다음 글에서는 Karpenter와 Cluster Autoscaler를 어떤 기준으로 나눠 쓰는지, 그리고 스팟 운영 시 장애 반경을 어떻게 줄이는지 이어서 다뤄볼 예정입니다. 이전 글의 VPC 설계 내용과도 연결해서 보시면 더 이해가 쉬우실 거예요. 🎉

  • [k8s] Prometheus Operator vs 직접 설정: Kubernetes 모니터링 실전 비교 분석

    [k8s] Prometheus Operator vs 직접 설정: Kubernetes 모니터링 실전 비교 분석

    목차

    Prometheus Operator vs 직접 설정: Kubernetes 모니터링 실전 비교 분석

    쿠버네티스 운영을 조금만 해보면 결국 만나게 되는 질문이 있습니다. Prometheus Operator vs 직접 설정, 대체 뭐가 더 낫냐는 거죠. 저도 처음엔 “Prometheus(프로메테우스, 시계열 메트릭 모니터링 시스템)면 그냥 띄우면 되는 거 아닌가?” 싶었는데, 실제로 홈랩과 운영 환경에서 둘 다 굴려보니 생각보다 차이가 꽤 크더라고요. 특히 Kubernetes 모니터링을 제대로 붙이려면 서비스 디스커버리(Service Discovery, 대상 자동 발견), 알림 규칙(Alerting Rules, 경고 조건), 그리고 Grafana 연동까지 자연스럽게 이어져야 하거든요.

    이번 글에서는 제가 직접 삽질했던 경험을 바탕으로, Prometheus Operator 방식과 직접 설정 방식을 현실적으로 비교해보겠습니다. 단순히 “이게 더 최신이라 좋다” 같은 얘기는 빼고, 실제 운영 관점에서 어디가 편하고 어디서 귀찮아지는지 정리해볼게요.

    Prometheus Operator와 직접 설정 방식이 쿠버네티스 클러스터 안에서 어떻게 다르게 배치되는지 보여주는 아키텍처 이미지입니다.

    왜 이 비교가 중요한가: Kubernetes 모니터링에서 운영 비용이 갈립니다

    모니터링은 처음 붙일 때보다 나중에 유지보수할 때 진가가 드러납니다. 초반에는 둘 다 잘 돌아가는 것처럼 보여요. 근데 클러스터가 커지고, 애플리케이션이 늘고, 팀원이 늘어나면 설정 방식의 차이가 운영 비용으로 바로 튀어나옵니다.

    • 직접 설정은 구조를 깊게 이해하기 좋고, 제어권이 높습니다.
    • Operator 방식은 선언형(Declarative, 원하는 상태를 정의하는 방식) 운영이 편하고 확장성이 좋습니다.
    • 작은 홈랩에서는 직접 설정이 빠를 때도 있지만, 팀 단위 운영에서는 Operator가 훨씬 덜 피곤한 경우가 많습니다.

    제가 처음 직접 설정으로 시작했을 때는 설정 파일 하나만 고치면 끝날 줄 알았거든요. 근데 대상 서비스가 늘어나고 scrape job이 많아지니까, 어느 순간 prometheus.yml이 점점 거대해졌습니다. 그때부터 “아 이건 사람이 계속 손으로 관리할 구조가 아니구나” 싶더라고요.

    쉽게 말해: Prometheus Operator vs 직접 설정의 핵심 차이

    쉽게 말해, Prometheus Operator는 Prometheus 자체를 쿠버네티스 리소스(Custom Resource, 사용자 정의 리소스)로 관리하게 해주는 방식입니다. 반대로 직접 설정은 Deployment, ConfigMap, ServiceAccount 같은 리소스를 직접 만들고, scrape 설정도 내가 직접 관리하는 방식입니다.

    항목 Prometheus Operator 직접 설정
    설정 관리 ServiceMonitor, PodMonitor, PrometheusRule 같은 CRD 기반 prometheus.yml 직접 수정
    초기 진입 난이도 처음엔 다소 생소함 개념만 알면 바로 시작 가능
    확장성 매우 좋음 대상이 많아질수록 불편
    운영 자동화 높음 낮음
    문제 추적 리소스 구조 이해 필요 설정 파일 기준으로 단순함
    팀 협업 표준화하기 좋음 작성자 의존도가 높아짐

    여기서 중요한 포인트! 둘 중 하나가 절대적으로 우월하다기보다는, 클러스터 규모와 운영 방식에 따라 유리한 선택이 달라집니다. 저도 작은 테스트 클러스터에서는 직접 설정을 아직도 씁니다. 빠르게 확인하기 좋거든요.

    언제 어떤 방식을 고르면 좋은가

    Prometheus Operator가 잘 맞는 경우

    • 여러 네임스페이스(namespace, 논리적 격리 단위)의 워크로드를 지속적으로 모니터링해야 할 때
    • 팀원이 늘어나서 모니터링 리소스를 표준화해야 할 때
    • Alertmanager(알림 관리자), Grafana, rules 관리를 함께 묶고 싶을 때
    • Helm(헬름, 쿠버네티스 패키지 매니저) 기반 운영에 익숙할 때

    직접 설정이 잘 맞는 경우

    • 학습 목적이나 홈랩처럼 단순한 구조일 때
    • Prometheus 내부 설정을 세밀하게 직접 다루고 싶을 때
    • CRD를 추가하고 싶지 않을 때
    • 문제 발생 시 설정 파일 한 장으로 빠르게 디버깅하고 싶을 때

    사실 처음 배울 때는 직접 설정이 개념 잡기 좋습니다. Prometheus가 어떻게 scrape하고, 어떤 target을 찾고, 어떤 식으로 저장하는지 몸으로 익히게 되거든요. 반대로 운영 단계에서는 Operator가 진짜 편해집니다. 이거 써보면 “아, 사람이 yaml 몇 천 줄 들고 싸우면 안 되는구나” 싶습니다 ㅎㅎ

    실전 구현 1: Prometheus Operator로 Kubernetes 모니터링 구성

    제가 보통 가장 무난하게 시작하는 방식은 kube-prometheus-stack 차트를 쓰는 겁니다. Prometheus, Alertmanager, Grafana를 한 번에 올리기 좋고, 커뮤니티에서 널리 쓰는 편이라 자료도 많습니다.

    1. 모니터링 전용 네임스페이스를 생성합니다.
    2. Helm 저장소를 추가합니다.
    3. 차트를 설치합니다.
    4. ServiceMonitor로 수집 대상을 선언합니다.
    kubectl create namespace monitoring
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring

    설치가 끝나면 Prometheus와 Grafana가 함께 배포됩니다. 여기까지는 꽤 부드럽게 갑니다. 진짜 체감 포인트는 그 다음부터예요. 애플리케이션 하나 추가할 때마다 prometheus.yml을 직접 안 만지고, ServiceMonitor만 선언하면 되거든요.

    apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: sample-app
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: sample-app
  namespaceSelector:
    matchNames:
      - app-space
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

    이 방식의 장점은 명확합니다. 애플리케이션 쪽 Service에 라벨만 잘 붙어 있으면, 모니터링 설정이 애플리케이션 배포 흐름에 자연스럽게 붙습니다. GitOps(Git옵스, Git 기반 선언형 운영) 하시는 분들이 Operator를 좋아하는 이유가 여기 있습니다.

    ServiceMonitor가 서비스 라벨을 기준으로 메트릭 수집 대상을 찾아가는 흐름을 보여주는 구성 다이어그램입니다.

    실전 구현 2: Prometheus 직접 설정으로 구성하기

    이번엔 직접 설정입니다. 이 방식은 Prometheus가 어떻게 동작하는지 이해하기엔 정말 좋습니다. 저도 처음 구조를 배울 때는 이 방법으로 오래 굴렸습니다. 다만 규모가 커지면 금방 손이 많이 가더라고요.

    1. Prometheus 설정을 담을 ConfigMap을 만듭니다.
    2. RBAC(Role-Based Access Control, 역할 기반 권한 제어)를 설정합니다.
    3. Deployment와 Service를 배포합니다.
    4. targets 페이지에서 수집 상태를 확인합니다.
    apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval: 30s
    scrape_configs:
      - job_name: 'kubernetes-pods'
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
            action: keep
            regex: true
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
            action: replace
            target_label: __metrics_path__
            regex: (.+)
          - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
            action: replace
            regex: ([^:]+)(?::\d+)?;(\d+)
            replacement: $1:$2
            target_label: __address__
    apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
      containers:
        - name: prometheus
          image: prom/prometheus
          args:
            - --config.file=/etc/prometheus/prometheus.yml
          ports:
            - containerPort: 9090
          volumeMounts:
            - name: config
              mountPath: /etc/prometheus
      volumes:
        - name: config
          configMap:
            name: prometheus-config

    직접 설정의 핵심은 relabel_configs를 이해하는 겁니다. 이 부분이 처음엔 진짜 벽처럼 느껴집니다. 저도 여기서 꽤 오래 멈췄었어요. 왜 target이 안 잡히는지 몰라서 annotation(어노테이션, 메타데이터) 오타 하나 찾겠다고 한참 봤던 기억이 납니다.

    대신 이 방식은 구조가 명확합니다. 어떤 설정이 왜 들어갔는지 한 줄씩 따라갈 수 있어요. 학습용으로는 정말 좋습니다.

    Grafana 연동은 어떻게 보나

    Grafana 연동은 두 방식 모두 어렵지 않습니다. 차이는 연결보다도 대시보드와 데이터소스(Data Source, 데이터 공급원) 관리 방식에서 납니다. Operator 스택을 쓰면 Grafana가 함께 올라오는 경우가 많아서 시작이 빠릅니다. 직접 설정은 Prometheus만 먼저 올리고 Grafana를 따로 배포하는 흐름이 일반적입니다.

    kubectl port-forward svc/monitoring-grafana -n monitoring 3000:80
kubectl port-forward svc/prometheus -n monitoring 9090:9090

    Grafana에서 Prometheus URL을 연결한 뒤, Kubernetes 관련 대시보드를 붙이면 CPU, 메모리, Pod 재시작 수, 노드 상태 등을 한눈에 볼 수 있습니다. 드디어 됐다! 하는 순간이 여기서 오죠. 숫자가 그래프로 보이기 시작하면, 그전까지는 안 보이던 병목이 갑자기 눈에 들어옵니다.

    ⚠️ 실제 겪었던 문제와 트러블슈팅

    여기서부터가 진짜 운영입니다. 설치보다 문제 해결이 더 중요하거든요.

    1. ServiceMonitor를 만들었는데 target이 안 잡힐 때

    • Service 라벨과 ServiceMonitor selector가 일치하는지 확인합니다.
    • metrics 포트 이름이 ServiceMonitor의 endpoints.port와 같은지 봅니다.
    • namespaceSelector가 실제 애플리케이션 네임스페이스를 포함하는지 체크합니다.

    이건 제가 꽤 자주 겪었습니다. 특히 포트 번호가 아니라 포트 이름으로 매칭한다는 걸 놓치면 한참 헤매게 됩니다.

    2. 직접 설정에서 scrape가 안 될 때

    • Pod annotation 키가 정확한지 봅니다.
    • RBAC 권한이 충분한지 확인합니다.
    • Prometheus UI의 Status > Targets에서 에러 메시지를 먼저 봅니다.

    처음엔 Prometheus 로그부터 뒤졌는데, 실제로는 Targets 화면이 더 빠르더라고요. 여기서 중요한 포인트! 모니터링 장애는 대개 설정 오타나 권한 누락에서 시작합니다.

    3. Grafana에 데이터가 안 보일 때

    • Prometheus 데이터소스 URL이 맞는지 확인합니다.
    • Prometheus 쿼리(PromQL, 프로메테우스 질의 언어)에서 메트릭이 실제로 조회되는지 먼저 봅니다.
    • 시간 범위(Time Range)가 너무 짧지 않은지 확인합니다.

    이건 별거 아닌데 은근 자주 나옵니다. 수집은 되고 있는데, 대시보드 시간 범위가 안 맞아서 “왜 빈 화면이지?” 하고 멍해지는 경우가 있거든요. 저도 몇 번 당했습니다 ㅎㅎ

    검증과 결과: 운영해보면 어떤 차이가 나나

    결론부터 말하면, Prometheus Operator vs 직접 설정은 단순한 기능 비교가 아니라 운영 방식의 선택에 가깝습니다.

    관점 Operator 직접 설정
    빠른 시작 Helm 기반으로 빠름 구성요소를 이해하면 빠름
    변경 관리 리소스 단위로 분리되어 편함 중앙 설정 파일이 비대해지기 쉬움
    문제 분석 CRD 구조 이해가 필요 설정 파일 기준으로 직관적
    확장 운영 유리함 점점 수동 작업 증가
    학습 가치 운영 패턴 학습에 좋음 Prometheus 내부 구조 학습에 좋음

    제가 실제로 써보니까, 작은 테스트 환경에서는 직접 설정이 부담이 적었습니다. 반면 운영 서비스가 두세 개를 넘어가고, 여러 네임스페이스에 exporter(exporter, 메트릭 노출 구성요소)가 붙기 시작하면 Operator 쪽이 확실히 편해집니다. 특히 팀원이 함께 건드리는 순간부터 차이가 커져요.

    Grafana 연동 결과로 Kubernetes 모니터링 대시보드를 보여주는 이미지

    Grafana 대시보드와 Prometheus 타깃 상태 화면을 함께 보여주는 결과 검증 이미지입니다.

    자주 묻는 질문 정리

    Q1. 입문자는 어떤 방식부터 시작하는 게 좋을까요?

    제가 추천하는 순서는 이렇습니다. 먼저 직접 설정으로 구조를 이해하고, 운영에는 Operator를 쓰는 방식입니다. 둘 중 하나만 알면 나중에 막힐 때 원인 파악이 어렵더라고요.

    Q2. 무조건 Operator가 정답인가요?

    그건 아닙니다. 싱글 클러스터 홈랩이나 짧은 실험 환경에서는 직접 설정이 더 가볍고 빠를 수 있습니다. 특히 CRD 추가를 최소화하고 싶다면 여전히 좋은 선택입니다.

    Q3. Grafana까지 꼭 같이 써야 하나요?

    필수는 아니지만, 실전에서는 거의 같이 갑니다. Prometheus가 수집과 저장을 담당하고, Grafana가 시각화를 담당하니까 역할이 깔끔하게 나뉘거든요.

    정리: 지금 선택해야 한다면 저는 이렇게 갑니다

    Kubernetes 모니터링을 장기적으로 운영할 계획이라면 저는 대체로 Operator를 권합니다. 선언형 리소스로 관리되고, 팀 협업에도 잘 맞고, 알림 규칙과 확장도 편하거든요. 반대로 학습 목적이 강하거나, 작은 홈랩에서 구조를 이해하고 싶다면 직접 설정으로 한 번 부딪혀보는 것도 아주 좋습니다. 저도 그렇게 배우면서 삽질 좀 했습니다. 근데 그 삽질 덕분에 지금은 문제가 생겨도 어디를 먼저 봐야 하는지 감이 오더라고요.

    혹시 지금 Prometheus Operator vs 직접 설정 사이에서 고민 중이시라면, 질문을 이렇게 바꿔보시면 결정이 쉬워집니다. “내가 지금 배우고 싶은가, 아니면 오래 운영하고 싶은가?” 이거거든요. 답이 전자면 직접 설정, 후자면 Operator 쪽이 보통 맞습니다.

    Prometheus Operator vs 직접 설정 선택 기준을 요약한 비교 이미지

    두 방식의 장단점과 추천 사용 시나리오를 한눈에 요약한 인포그래픽 이미지입니다.

    다음 글에서는 Alertmanager(알림 관리자)와 Slack 같은 채널 연동, 그리고 PromQL 기초 쿼리를 다뤄볼 예정입니다. 이전 글에서 exporter 구성 방법을 보셨다면 이번 내용이 더 잘 이어질 거예요. ✅

  • [Kubernetes] Kubernetes PodSecurity 도입 전후 비교: 보안 강화 사례 연구

    [Kubernetes] Kubernetes PodSecurity 도입 전후 비교: 보안 강화 사례 연구

    목차

    [Kubernetes] Kubernetes PodSecurity 도입 전후 비교: 보안 강화 사례 연구

    Kubernetes PodSecurity 도입을 고민하시는 분들은 아마 한 번쯤 이런 순간이 있으셨을 겁니다. 워크로드는 잘 돌아가는데, 막상 보안 점검을 해보면 privileged(특권 모드) 컨테이너가 섞여 있거나, hostPath(호스트 경로 마운트) 같은 위험한 설정이 아무 제어 없이 배포되는 경우 말이죠. 저도 처음엔 “네임스페이스만 잘 나누면 되지 않을까?” 싶었는데, 실제로 운영 환경과 홈랩에서 계속 만져보니 결국 배포 시점의 기본 보안 가드레일이 있어야 하더라고요. 그래서 이번 글에서는 Kubernetes PodSecurity 도입 전후를 어떻게 비교했는지, 어떤 문제가 줄었는지, 그리고 적용하면서 어디서 삽질했는지 경험 기반으로 정리해보겠습니다.

    특히 이 글은 Kubernetes 보안, Pod Security Standards(파드 보안 표준), 보안 정책을 실제 운영에 녹이는 관점으로 읽으시면 도움이 됩니다. 이론만 설명하는 글이 아니라, 제가 직접 해보니 어디서 걸리고 어떤 기준으로 정리해야 덜 힘든지 그 흐름을 보여드릴게요.

    PodSecurity 도입 전에는 제어가 느슨하고, 도입 후에는 네임스페이스 정책과 허용 범위가 명확해진 구조를 한눈에 보여주는 개요 이미지입니다.

    Kubernetes PodSecurity 도입이 왜 중요한가요

    쉽게 말해 PodSecurity는 “이 파드(Pod)는 어디까지 위험한 설정을 써도 되는가”를 네임스페이스 단위로 관리하는 방식입니다. 예전에는 팀마다 매니페스트를 제각각 작성하다 보니, 어떤 워크로드는 runAsNonRoot가 잘 들어가 있고, 어떤 건 아예 빠져 있고, 또 어떤 건 디버깅한다고 privileged: true를 넣어둔 채 남아 있기도 했습니다. 이게 한두 개면 눈으로 보겠는데, 서비스가 늘어나면 사람의 기억으로 통제하는 건 불가능하더라고요.

    여기서 중요한 포인트! 보안은 좋은 설정을 권장하는 것만으로는 부족합니다. 실제로는 잘못된 설정이 들어왔을 때 막아줘야 합니다. 제가 현장에서 느낀 것도 그거였습니다. 리뷰에서 빠지고, 급한 장애 대응 중엔 원칙이 밀리고, 결국 가장 약한 워크로드가 전체 클러스터 위험도를 끌어올리거든요.

    Pod Security Standards(파드 보안 표준)를 먼저 이해해야 합니다

    Pod Security Standards는 파드 보안 수준을 세 단계로 나눠서 생각하게 해줍니다. 저도 처음엔 이름만 보고 좀 딱딱하다고 느꼈는데, 실제로 써보니까 기준점이 분명해서 오히려 팀 합의가 빨라졌습니다.

    수준 설명 적합한 상황
    Privileged 제한이 거의 없는 수준입니다. 특수한 시스템 워크로드, 아주 제한적인 운영 도구
    Baseline 명백히 위험한 설정을 막는 기본선입니다. 일반적인 애플리케이션 네임스페이스의 첫 단계
    Restricted 가장 엄격한 수준으로, 안전한 기본값을 강하게 요구합니다. 보안 민감 서비스, 표준화가 잘 된 앱 워크로드

    제가 보통 권하는 방식은 이렇습니다.

    • 처음부터 전부 Restricted로 밀어붙이지 않습니다.
    • 기존 레거시 워크로드가 많다면 먼저 Baseline으로 현재 상태를 정리합니다.
    • 새로 만드는 네임스페이스나 표준화된 앱은 Restricted를 기본으로 잡습니다.

    이 접근이 중요한 이유는, 보안 정책은 강하면 좋은 게 아니라 운영에 정착해야 좋은 것이기 때문입니다. 너무 급하게 올리면 예외만 늘어나고 결국 정책이 무력화되더라고요.

    도입 전 환경에서 실제로 보였던 문제들

    제가 PodSecurity를 넣기 전에 먼저 한 일은 “무슨 설정이 돌아다니고 있는지”를 보는 것이었습니다. 막연히 위험할 것 같다가 아니라, 실제 매니페스트와 실행 중인 파드를 기준으로 봐야 하거든요. 그때 자주 보였던 문제는 아래와 같았습니다.

    • securityContext가 아예 없는 배포가 생각보다 많았습니다.
    • allowPrivilegeEscalation 설정이 빠져 있었습니다.
    • 루트(root) 권한 기반 이미지가 관성적으로 사용되고 있었습니다.
    • 운영 중 잠깐 쓰려고 만든 디버그용 파드가 그대로 남아 있었습니다.
    • 예외가 문서화되지 않아, 왜 허용했는지 아무도 설명 못 하는 설정이 있었습니다.

    이런 상태에서 보안 점검이 들어오면 굉장히 피곤해집니다. “왜 이 컨테이너는 루트로 뜨나요?” 같은 질문이 나오면, 실제 이유가 있어서가 아니라 그냥 기본값이라서 그런 경우가 많거든요. 사실 제일 무서운 건 악의적인 공격보다도 무심코 허용된 기본값입니다.

    Kubernetes PodSecurity 도입 절차: 제가 실제로 밟은 순서

    여기서는 복잡하게 가지 않고, 운영에서 비교적 덜 아픈 순서로 설명해볼게요. 핵심은 한 번에 차단(enforce)하지 말고 먼저 관찰부터 하는 겁니다.

    1. 보호할 네임스페이스를 분류합니다.
    2. audit(감사)와 warn(경고) 중심으로 먼저 적용합니다.
    3. 실패하는 워크로드를 수정합니다.
    4. 문제가 없는 네임스페이스부터 enforce(강제)로 전환합니다.
    5. 예외 워크로드는 별도 네임스페이스로 분리합니다.

    예를 들어 애플리케이션용 네임스페이스에 먼저 Baseline 경고와 감사 정책을 걸어볼 수 있습니다.

    kubectl label namespace app-team \
  pod-security.kubernetes.io/audit=baseline \
  pod-security.kubernetes.io/warn=baseline --overwrite

    이 상태에서는 배포가 바로 막히지는 않지만, 어떤 설정이 기준을 벗어나는지 확인하기 좋아요. 저는 처음부터 차단했다가 CI/CD 파이프라인이 우르르 깨지는 바람에 한 번 크게 삽질했었습니다. 그 뒤로는 무조건 경고와 감사부터 봅니다.

    조금 정리됐다 싶으면 강제로 올립니다.

    kubectl label namespace app-team \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/enforce-version=latest --overwrite

    운영에서는 latest 대신 조직에서 검증한 기준 버전을 명시적으로 관리하는 팀도 많습니다. 저는 팀 표준이 아직 흔들릴 때는 버전 기준을 문서화해두는 쪽이 더 낫다고 봅니다. 기준이 자주 바뀌면 개발팀이 체감상 더 힘들어하거든요.

    Kubernetes PodSecurity 도입 시 네임스페이스 정책 적용 흐름 이미지

    네임스페이스에 audit, warn, enforce 라벨을 붙이면서 단계적으로 정책을 강화하는 흐름을 설명하는 이미지입니다.

    Restricted(제한) 수준을 목표로 할 때 매니페스트 예시

    다음은 비교적 안전한 기본 형태의 예시입니다. 모든 앱이 이대로 되진 않겠지만, 팀 표준의 시작점으로 잡기 좋습니다.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: app-team
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: web
          image: nginx:stable
          ports:
            - containerPort: 80
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL

    여기서 자주 보는 포인트는 아래입니다.

    • runAsNonRoot: true로 비루트 실행을 강제합니다.
    • allowPrivilegeEscalation: false로 권한 상승 가능성을 줄입니다.
    • capabilities.drop: [ALL]로 불필요한 리눅스 capability(리눅스 커널 권한 집합)를 제거합니다.
    • seccompProfile.type: RuntimeDefault로 기본 시스템 호출 필터를 사용합니다.

    도입 전후 비교: 무엇이 달라졌나

    정량 수치를 억지로 붙이기보다, 운영 체감 기준으로 말씀드리는 게 더 정확할 것 같습니다. Kubernetes PodSecurity 도입 전에는 “문제 있는 매니페스트가 배포된 뒤 나중에 발견되는 구조”였다면, 도입 후에는 “기준에 맞지 않으면 배포 단계에서 바로 드러나는 구조”로 바뀌었습니다. 이 차이가 생각보다 큽니다.

    비교 항목 도입 전 도입 후
    보안 기준 문서나 리뷰에 의존 네임스페이스 정책으로 강제
    위험 설정 발견 시점 배포 후 또는 점검 시 배포 직전 또는 배포 중
    팀 간 일관성 사람마다 다름 정책 기준으로 통일
    예외 관리 구두 합의가 많음 별도 네임스페이스와 문서로 관리

    제가 직접 해보니 제일 편했던 건, 리뷰에서 감정 소모가 줄어든다는 점이었습니다. 예전엔 “이 설정 위험하지 않나요?” 같은 대화가 사람 대 사람의 의견 충돌처럼 번질 때가 있었는데, 정책을 두고 나면 “이건 Baseline 기준에서 걸립니다”처럼 훨씬 명확해집니다. 이거 진짜 편하더라고요.

    ⚠️ 적용하면서 많이 막혔던 문제와 해결 방법

    이 섹션은 꼭 넣고 싶었습니다. 문서만 보면 간단해 보이는데, 실제로는 여기서 다들 한 번씩 막히거든요.

    1. 기존 이미지가 non-root 실행을 전제로 만들어지지 않은 경우

    Restricted 수준으로 올리면 가장 먼저 터지는 부분 중 하나입니다. 애플리케이션은 문제 없어 보여도, 이미지 내부 디렉터리 권한이나 엔트리포인트 스크립트가 루트 권한을 전제하는 경우가 있습니다. 저도 처음엔 “분명 앱은 잘 뜨는데 왜 이게 안 되지?” 싶었는데, 알고 보니 컨테이너 시작 시 쓰기 권한이 필요한 경로가 있었어요.

    이럴 때는 아래 순서로 봤습니다.

    1. 이미지가 비루트 실행을 지원하는지 확인합니다.
    2. 쓰기 경로가 꼭 필요한지 줄입니다.
    3. 필요하면 Dockerfile 단계에서 권한을 정리합니다.
    4. 정말 예외가 필요한 워크로드만 별도 분리합니다.

    2. 운영 도구와 일반 앱을 같은 기준으로 묶은 경우

    로그 수집기, CNI 관련 컴포넌트, 노드 접근이 필요한 에이전트는 일반 앱과 요구 조건이 다를 수 있습니다. 그런데 이걸 한 네임스페이스 정책으로 퉁치면 꼭 어딘가서 충돌이 납니다. 저는 한동안 “왜 어떤 건 꼭 예외가 생기지?” 하다가, 결국 애플리케이션 네임스페이스와 인프라 네임스페이스를 분리하면서 정리가 되더라고요.

    3. warn만 보고 끝내는 경우

    이건 진짜 자주 봅니다. 경고는 보이는데 바빠서 미루다 보면, 3개월 뒤에도 같은 경고가 그대로 쌓여 있어요. 그래서 저는 warn → audit → enforce 전환 일정을 미리 잡아두는 편입니다. 일정이 없으면 정책은 거의 장식품이 됩니다.

    Kubernetes PodSecurity 도입 후 경고와 배포 실패 분석 이미지

    경고 단계에서 어떤 항목이 걸리는지 확인하고, enforce 전환 전에 수정 포인트를 찾는 과정을 보여주는 이미지입니다.

    검증은 이렇게 했습니다

    보안 정책은 넣는 것보다 검증이 더 중요합니다. 정책이 존재해도 실제로 막히지 않으면 의미가 없으니까요. 제가 보통 하는 검증은 두 가지입니다. 하나는 정상 매니페스트가 잘 배포되는지, 다른 하나는 의도적으로 위험한 설정을 넣었을 때 차단되는지 확인하는 겁니다.

    예를 들어 아래처럼 위험한 설정이 들어간 테스트 파드를 만들어 봅니다.

    apiVersion: v1
kind: Pod
metadata:
  name: privileged-test
  namespace: app-team
spec:
  containers:
    - name: test
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      securityContext:
        privileged: true

    그리고 배포를 시도합니다.

    kubectl apply -f privileged-test.yaml

    정상이라면 보안 정책 위반으로 거부되는 흐름이 나와야 합니다. 반대로, 팀 표준 매니페스트는 무리 없이 통과해야 하고요. 여기서 중요한 건 단순히 “막혔다”가 아니라, 왜 막혔는지 개발자도 이해할 수 있어야 한다

    추가로 확인했던 항목은 아래와 같습니다.

    • 새 네임스페이스 생성 시 기본 라벨 정책이 누락되지 않는지
    • CI/CD에서 배포 실패 메시지가 충분히 읽히는지
    • 예외 네임스페이스가 무분별하게 늘어나지 않는지
    • 운영 문서와 실제 클러스터 라벨 상태가 일치하는지
    Kubernetes PodSecurity 도입 후 배포 검증 결과 이미지

    정상 배포와 정책 위반 배포가 어떻게 구분되는지, 운영자가 어떤 식으로 결과를 확인하는지 보여주는 이미지입니다.

    운영 기준을 문서화해야 도입이 끝납니다

    사실 PodSecurity는 라벨 몇 개 붙인다고 끝나지 않습니다. 진짜 끝은 팀 운영 기준이 문서로 남고, 다음 사람도 같은 방식으로 적용할 수 있을 때입니다. 저도 처음엔 클러스터에만 반영해두고 안심했었는데, 시간이 지나니 “이 네임스페이스는 왜 baseline이지?” 같은 질문이 계속 나오더라고요.

    그래서 저는 아래 항목을 최소 문서 세트로 남깁니다.

    • 네임스페이스별 목표 수준: baseline 또는 restricted
    • 예외 허용 기준: 누가 승인하고 언제 재검토하는지
    • 개발팀용 체크리스트: 보안 컨텍스트 기본 예시
    • 배포 실패 시 확인 순서: 어떤 필드를 먼저 볼지

    혹시 이런 경험 있으신가요? 정책은 분명 있는데, 새 프로젝트가 생길 때마다 같은 설명을 또 하고 또 하게 되는 상황 말이죠. 이런 반복을 줄이려면 결국 문서화와 템플릿화가 답입니다. 다음 글에서는 OPA Gatekeeper(오픈 정책 에이전트 게이트키퍼)나 Kyverno(카이버노) 같은 정책 엔진과 PodSecurity를 어떻게 역할 분담할지 다뤄볼 예정입니다. 이전 글에서 다룬 네임스페이스 표준화 내용이 있으시다면 같이 연결해서 보시는 것도 좋습니다.

    도입 전후의 차이, 운영 체크리스트, 다음 단계까지 한 장으로 요약한 인포그래픽 이미지입니다.

    정리: Kubernetes 보안은 작은 강제에서 시작됩니다

    Kubernetes PodSecurity 도입은 거창한 보안 프로젝트처럼 보일 수 있지만, 실제로는 “위험한 기본값을 그냥 두지 않겠다”는 아주 현실적인 출발점에 가깝습니다. 제가 여러 번 적용해보니 가장 효과적인 방식은 이렇습니다. 먼저 경고와 감사로 현재 상태를 파악하고, 그다음 Baseline으로 정리한 뒤, 준비된 워크로드부터 Restricted로 올리는 흐름이었습니다. 처음엔 이게 뭔가 싶었는데, 한 번 기준이 잡히고 나면 운영이 훨씬 편해집니다. 드디어 됐다! 싶은 순간이 오더라고요.

    마지막으로 한 줄 요약하면 이겁니다. Pod Security Standards는 문서가 아니라 운영 습관으로 들어와야 합니다. 보안 정책이 실제 배포 과정에 녹아들면, 리뷰 품질도 좋아지고 예외도 줄고, 나중에 감사 대응도 덜 힘들어집니다. Kubernetes 보안을 어디서부터 손대야 할지 막막하셨다면, PodSecurity부터 차근차근 시작해보세요.

    FAQ: 자주 묻는 질문

    모든 네임스페이스를 바로 Restricted로 가야 하나요?

    아닙니다. 레거시 워크로드가 많다면 Baseline부터 정리하는 편이 현실적입니다. 무리하게 올리면 예외만 늘어날 수 있습니다.

    PodSecurity만 있으면 보안 정책이 충분한가요?

    기본 보안 가드레일로는 매우 유용하지만, 조직별 세부 규칙까지 모두 대신하진 못합니다. 필요한 경우 별도 정책 엔진과 역할을 나눠가는 게 좋습니다.

    가장 먼저 점검할 필드는 무엇인가요?

    runAsNonRoot, allowPrivilegeEscalation, privileged, capabilities, hostPath 같은 항목부터 보는 걸 권합니다.

  • [Kubernetes] Karpenter 오토스케일러 1년 사용 후기: 비용 절감과 성능 최적화 회고

    [Kubernetes] Karpenter 오토스케일러 1년 사용 후기: 비용 절감과 성능 최적화 회고

    목차

    [Kubernetes] Karpenter 오토스케일러 1년 사용 후기

    Karpenter 오토스케일러 후기를 한 줄로 먼저 말씀드리면, EKS 운영에서 노드 증설 속도와 비용 통제가 동시에 좋아졌습니다. 저도 처음엔 “Cluster Autoscaler(클러스터 오토스케일러)로도 되는데 굳이?” 싶었거든요. 그런데 서비스가 늘고, 배치 작업이 섞이고, 팀별로 워크로드 특성이 달라지니까 기존 방식이 점점 답답해지더라고요. 특히 Kubernetes 오토스케일링을 노드 그룹 중심으로만 운영하면 빈 자원이 남아도는 순간이 꽤 자주 생깁니다. 실무에서 결국 비용은 숫자로 돌아오니까요.

    제가 지난 1년 동안 홈랩과 업무 환경에서 비슷한 패턴으로 실험하고 운영해보니, Karpenter는 “노드를 미리 크게 잡아두는 습관”을 줄여주는 쪽에 강점이 있었습니다. 다만 마법은 아닙니다. 설정을 대충 하면 오히려 인스턴스 종류가 너무 넓게 열리거나, 반대로 너무 좁아서 스케일이 안 붙는 일도 생깁니다. 오늘 글에서는 제가 실제로 겪었던 삽질까지 포함해서, 왜 도입했고 어떻게 운영했고 무엇을 조심해야 하는지 정리해보겠습니다.

    Karpenter 오토스케일러 후기용 EKS 아키텍처 개요 이미지

    Amazon EKS 환경에서 Karpenter가 대기 중인 Pod를 보고 적절한 EC2 노드를 프로비저닝하는 전체 흐름을 보여주는 아키텍처 이미지입니다.

    Karpenter란 무엇인가: Kubernetes 오토스케일링을 더 세밀하게

    쉽게 말해 Karpenter는 Pod(파드)의 요구사항을 보고 바로 노드를 만들어주는 노드 프로비저너(node provisioner, 노드 생성기)입니다. 기존 Cluster Autoscaler는 미리 만들어둔 Auto Scaling Group(오토 스케일링 그룹)이나 Managed Node Group(관리형 노드 그룹)을 기준으로 증설을 판단합니다. 반면 Karpenter는 “지금 이 파드가 CPU, 메모리, 아키텍처, 스팟 여부를 이렇게 요구하네? 그럼 여기에 맞는 노드를 하나 올리자”에 더 가깝습니다.

    처음엔 이게 뭔가 싶었는데, 실제로 써보니까 포인트가 명확하더라고요. 노드 그룹을 여러 개 미리 쪼개서 관리하던 부담이 줄어듭니다. 그리고 워크로드에 맞는 인스턴스 타입을 더 유연하게 고를 수 있어서 AWS EKS 비용 절감 관점에서 꽤 체감이 됐습니다.

    항목 Cluster Autoscaler Karpenter
    기준 노드 그룹 중심 파드 요구사항 중심
    유연성 사전 정의된 그룹 범위 내 인스턴스 선택 폭이 넓음
    비용 최적화 그룹 설계에 크게 의존 빈 자원 축소에 유리
    운영 포인트 노드 그룹 관리 요구사항과 제약 조건 설계

    왜 도입했는가: 노드 프로비저닝 병목이 보이기 시작했습니다

    제가 Karpenter를 본격적으로 보기 시작한 이유는 세 가지였습니다.

    • 배치와 실시간 서비스가 같은 클러스터에 섞이면서 노드 성격이 달라졌습니다.
    • Managed Node Group을 늘릴수록 운영 포인트가 많아졌습니다.
    • 스팟(Spot)과 온디맨드(On-Demand)를 상황에 따라 유연하게 섞고 싶었습니다.

    예전에는 팀별로 노드 그룹을 하나씩 나누면 깔끔해 보였거든요. 근데 시간이 지나면 태그, 라벨, 테인트(Taint, 특정 워크로드 제한), AMI, 서브넷, 보안 그룹까지 관리 포인트가 계속 늘어납니다. 결국 “지금 이 파드가 왜 여기 못 올라가지?”를 찾는 시간이 길어지더라고요. Karpenter는 그 문제를 완전히 없애주진 않지만, 적어도 노드 프로비저닝을 워크로드 관점으로 다시 정리하게 만들어줍니다.

    실전 구현: EKS에 Karpenter 붙이면서 제가 잡았던 기준

    여기서 중요한 포인트! Karpenter를 처음 붙일 때는 욕심내서 모든 워크로드를 한 번에 옮기지 않는 게 좋습니다. 저도 처음엔 한 번에 바꾸려다가 삽질 좀 했습니다 ㅎㅎ 작은 NodePool부터 시작해서 점진적으로 옮기는 게 훨씬 안전했습니다.

    1. 기본 EKS 클러스터와 워커 노드를 준비합니다.
    2. Karpenter용 IAM 권한과 인터럽션 처리 큐를 구성합니다.
    3. Karpenter 컨트롤러를 설치합니다.
    4. NodeClass와 NodePool을 최소 범위로 선언합니다.
    5. 특정 워크로드만 먼저 태워서 동작을 검증합니다.

    1. 컨트롤러 설치 전 확인할 것

    • 클러스터의 OIDC provider가 연결되어 있는지
    • 서브넷과 보안 그룹에 Karpenter가 찾을 수 있는 태그가 있는지
    • 기존 CNI, CoreDNS, metrics-server 같은 필수 애드온이 정상인지

    특히 태그는 정말 중요합니다. 이거 하나 빠지면 로그만 보고 한참 헤맵니다.

    2. 설치 예시

    export CLUSTER_NAME=my-eks
export AWS_REGION=ap-northeast-2
export KARPENTER_NAMESPACE=karpenter

helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm upgrade --install karpenter eks/karpenter \
  --namespace ${KARPENTER_NAMESPACE} \
  --create-namespace \
  --set settings.clusterName=${CLUSTER_NAME} \
  --set settings.interruptionQueue=${CLUSTER_NAME} \
  --set serviceAccount.create=true

    환경마다 IAM Role for Service Account(IRSA, 서비스어카운트용 IAM 역할) 구성 방식은 다를 수 있습니다. 그래서 설치 커맨드 자체보다도, 컨트롤러가 EC2 인스턴스 생성과 조회 권한을 제대로 갖고 있는지를 먼저 보는 게 중요합니다.

    3. NodeClass / NodePool 예시

    아래 예시는 운영에서 자주 쓰는 방향을 단순화한 것입니다. 핵심은 “너무 넓지도, 너무 좁지도 않게” 시작하는 겁니다.

    apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-eks
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-eks
  role: KarpenterNodeRole-my-eks
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: general
spec:
  template:
    metadata:
      labels:
        workload: general
    spec:
      nodeClassRef:
        name: default
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["m5.large", "m5.xlarge", "m6i.large", "m6i.xlarge"]
  disruption:
    consolidationPolicy: WhenUnderutilized
  limits:
    cpu: "100"

    제가 직접 해보니 처음부터 인스턴스 타입을 수십 개 열어두는 것보다, 검증된 계열 몇 개로 시작하는 편이 좋았습니다. 나중에 확장하는 건 쉽지만, 처음부터 범위를 넓히면 왜 그 타입이 선택됐는지 추적이 어려워지거든요.

    Karpenter 오토스케일러 후기의 NodePool 구성 이미지

    EC2NodeClass와 NodePool이 연결되어 서브넷, 보안 그룹, 인스턴스 타입, capacity type을 결정하는 구조를 보여주는 구성 이미지입니다.

    4. 테스트용 워크로드로 검증

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 6
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      nodeSelector:
        workload: general
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"

    이렇게 요청 리소스(requests, 예약 자원)를 명시한 테스트 파드를 올려보면 스케줄링이 안 되는 순간 Karpenter가 새 노드를 붙이는 흐름을 직관적으로 볼 수 있습니다. 드디어 됐다! 하는 순간이 여기서 나옵니다.

    운영하면서 체감한 장점: 비용 절감과 성능 최적화 포인트

    Karpenter 오토스케일러 후기에서 가장 많이 물어보는 게 “그래서 돈이 진짜 줄었나요?”인데요, 제 경우엔 AWS EKS 비용 절감 효과를 숫자 하나로 단정하긴 어려웠습니다. 워크로드 패턴이 계속 바뀌니까요. 다만 분명했던 변화는 있었습니다.

    • 대기 중인 파드 처리 속도가 좋아졌습니다. 노드 그룹 단위보다 반응이 직관적이었습니다.
    • 빈 자원이 남는 노드가 줄었습니다. 특히 야간 배치 종료 후 차이가 컸습니다.
    • 스팟과 온디맨드 혼합 전략을 잡기 쉬웠습니다.
    • 팀별 노드 그룹 난립을 줄이면서 운영 복잡도가 낮아졌습니다.

    성능 최적화라는 게 꼭 CPU 사용률 그래프만 예쁘게 만드는 건 아니더라고요. 스케줄링 지연이 줄고, 워크로드 특성에 맞는 노드가 더 빨리 생기고, 과하게 큰 노드를 덜 쓰게 되는 것 자체가 운영 품질 향상입니다. 실제로 써보니까 이 부분이 더 크게 다가왔습니다.

    ⚠️ 주의사항과 트러블슈팅: 여기서 많이 막혔습니다

    이 섹션은 좀 중요합니다. Karpenter는 잘 되면 정말 편한데, 안 될 때는 로그와 이벤트를 꼼꼼히 봐야 하거든요.

    1. 서브넷/보안 그룹 태그 누락

    가장 흔했습니다. 컨트롤러는 떠 있는데 노드가 안 생깁니다. 원인은 대개 discovery 태그 누락이었습니다.

    kubectl logs -n karpenter deploy/karpenter
kubectl describe nodepool general
kubectl get events -A --sort-by=.lastTimestamp

    해결: 서브넷과 보안 그룹 선택 조건에 맞는 태그가 있는지 다시 확인했습니다. 이건 문서보다 실제 AWS 리소스 태그 화면이 더 빠르더라고요.

    2. 인스턴스 요구 조건을 너무 빡빡하게 잡음

    저도 처음엔 특정 세대, 특정 사이즈만 고집했습니다. 그러면 순간적으로 가용한 인스턴스가 없을 때 스케일이 멈춥니다. 특히 스팟만 강제하면 더 민감해집니다.

    • 인스턴스 패밀리를 1개만 두지 말 것
    • 사이즈를 한 단계 이상 열어둘 것
    • 스팟만 고정하지 말고 온디맨드 fallback을 고려할 것

    3. DaemonSet(데몬셋) 자원 계산을 과소평가

    이거 진짜 많이 놓칩니다. 노드 하나가 올라오면 CNI, 로그 에이전트, 모니터링 에이전트 같은 DaemonSet이 먼저 자리를 먹거든요. 파드 request를 딱 맞춰 잡아두면 생각보다 노드가 더 필요해집니다.

    해결: 시스템 DaemonSet이 차지하는 CPU/메모리를 감안해서 워크로드 request를 다시 계산했습니다. 제가 직접 해보니 이 조정만으로도 불필요한 추가 스케일링이 꽤 줄었습니다.

    4. Consolidation(통합 축소) 설정이 너무 공격적일 때

    유휴 노드를 잘 정리해주는 기능은 좋지만, 워크로드 패턴이 들쭉날쭉하면 노드가 자주 교체될 수 있습니다. 배치가 짧게 반복되는 환경에서는 오히려 흔들릴 수 있겠더라고요.

    해결: 처음엔 보수적으로 운영하고, 패턴이 보인 뒤에 consolidation 정책을 조정했습니다. 이건 정답이 하나가 아니라 워크로드 성격을 타는 부분입니다.

    검증과 결과 확인: 무엇을 보면 잘 되고 있다고 판단할까

    Karpenter 오토스케일러 후기를 쓰면서 가장 조심한 부분이 여기입니다. 비용 수치나 처리량 수치를 함부로 적으면 안 되거든요. 그래서 저는 운영에서 다음 지표를 기준으로 판단했습니다.

    1. Pending Pod가 줄어드는 속도
    2. 피크 시간 이후 유휴 노드가 정리되는지
    3. 스팟 중단 이후 재스케줄링이 안정적인지
    4. 특정 노드 그룹에 과도하게 몰리던 패턴이 줄었는지
    kubectl get nodes
kubectl get pods -A -o wide
kubectl top nodes
kubectl top pods -A
kubectl describe pod <pending-pod-name>

    제가 실제로 써보니까, 가장 눈에 띄는 건 노드 수 자체보다도 대기 중인 파드가 오래 머무르지 않는 것이었습니다. 클러스터가 바빠질 때 운영자가 덜 초조해집니다. 이건 체감이 꽤 큽니다.

    AWS EKS 비용 절감과 Karpenter 오토스케일링 결과 이미지

    파드 증가 시 노드가 빠르게 늘고, 부하가 줄면 유휴 노드가 정리되는 모습을 대시보드 형태로 보여주는 결과 이미지입니다.

    정리 표: 어떤 환경에 특히 잘 맞았나

    환경 Karpenter 적합도 이유
    배치와 웹 서비스 혼합 높음 워크로드별 노드 요구사항 차이가 큼
    스팟 적극 활용 높음 capacity type 전략을 유연하게 설계 가능
    소규모 고정 트래픽 보통 정적 노드 그룹만으로도 충분할 수 있음
    규제가 강한 고정 인스턴스 정책 보통 이하 유연성 장점이 줄어듦

    자주 묻는 질문: 도입 전에 많이 받았던 질문

    Q1. Cluster Autoscaler 대신 무조건 Karpenter가 답인가요?

    그건 아닙니다. 워크로드가 단순하고 노드 그룹이 적다면 기존 방식도 충분히 안정적입니다. 다만 노드 그룹이 많아지고 Kubernetes 오토스케일링 설계가 복잡해질수록 Karpenter의 장점이 커졌습니다.

    Q2. 스팟만 써도 되나요?

    중단 허용성이 높은 워크로드라면 가능하지만, 핵심 서비스는 온디맨드 fallback을 함께 두는 게 마음이 편합니다. 저도 처음엔 공격적으로 갔다가 다시 섞어서 운영했습니다.

    Q3. 어떤 팀이 먼저 도입해보면 좋을까요?

    배치 작업, CI 러너, 일시적인 이벤트성 워크로드가 있는 팀부터 추천드립니다. 효과가 빨리 보입니다.

    Kubernetes 오토스케일링 비교를 보여주는 Karpenter 요약 이미지

    Cluster Autoscaler와 Karpenter의 차이점, 추천 사용 시나리오, 운영 포인트를 한 장에 요약한 비교 인포그래픽 이미지입니다.

    마무리: 1년 써보니 결국 설계가 반이었습니다

    Karpenter는 분명 좋은 도구입니다. 하지만 설치했다고 끝나는 종류는 아니었습니다. 어떤 인스턴스를 허용할지, 어떤 워크로드를 어디에 태울지, 스팟과 온디맨드를 어떻게 섞을지, consolidation을 얼마나 공격적으로 둘지 같은 정책 설계가 훨씬 중요했습니다. 저도 처음엔 도구가 다 알아서 해줄 줄 알았는데, 실제로 써보니까 “잘 설계된 제약 조건”이 핵심이더라고요.

    그래도 1년 기준으로 돌아보면, Karpenter 오토스케일러 후기는 꽤 긍정적입니다. 노드 프로비저닝이 더 민첩해졌고, 불필요한 여유 자원을 줄이는 방향으로 운영 습관이 바뀌었습니다. 혹시 지금 EKS에서 노드 그룹이 점점 복잡해지고 있다면, 작은 워크로드 하나부터 붙여보셔도 좋겠습니다. 다음 글에서는 HPA(Horizontal Pod Autoscaler, 파드 수평 확장)와 Karpenter를 같이 운영할 때 생기는 타이밍 이슈도 다뤄볼 예정입니다. 이전 글의 EKS 운영 체크리스트와 함께 보시면 흐름이 더 잘 잡히실 겁니다.

    1년 운영 후 배운 점, 추천 도입 순서, 주의할 설정 포인트를 요약한 마무리 이미지입니다.

  • [Kubernetes] StatefulSet vs Deployment: 상태 저장 애플리케이션 배포 비교

    [Kubernetes] StatefulSet vs Deployment: 상태 저장 애플리케이션 배포 비교

    목차

    [Kubernetes] Kubernetes StatefulSet vs Deployment 비교 분석

    Kubernetes StatefulSet vs Deployment를 처음 제대로 구분하게 된 건, 홈랩에서 데이터베이스를 올렸다가 볼륨이 꼬이면서 한참 삽질했을 때였습니다. 처음엔 둘 다 그냥 Pod(파드)를 여러 개 띄우는 Kubernetes 워크로드(workload, 애플리케이션 실행 단위)겠거니 싶었거든요. 근데 실제로 운영해보니까 차이가 꽤 크더라고요. 특히 상태 저장 애플리케이션(stateful application, 데이터와 식별성이 중요한 앱) 쪽은 정말 그랬습니다. 웹 API처럼 가볍게 교체되는 애플리케이션 배포는 Deployment(디플로이먼트)가 정말 편한데, MySQL이나 PostgreSQL 같은 건 접근을 잘못하면 나중에 복구할 때 진짜 식은땀이 나더라고요.

    혹시 이런 경험 있으신가요? 애플리케이션은 잘 떴는데, 재시작 후 데이터 경로가 달라지거나 Pod 이름이 바뀌면서 클러스터 구성이 꼬이는 상황 말입니다. 여기서 중요한 포인트! Kubernetes StatefulSet vs Deployment는 단순히 생성 방식만 다른 게 아니라, 애플리케이션의 정체성(identity), 저장소(storage), 배포 순서(ordering)를 다루는 철학 자체가 다릅니다.

    이번 글에서는 제가 직접 홈랩에서 써보며 정리한 기준으로, Kubernetes StatefulSet vs Deployment 차이를 실무 감각으로 풀어보겠습니다. 단순 정의만 보면 헷갈리기 쉬우니까, 실제 YAML 예제와 트러블슈팅까지 같이 보시죠. 이전 글에서 다룬 Persistent Volume(PV, 영구 볼륨)과 StorageClass(스토리지 클래스) 내용을 같이 보시면 이해가 더 빨라집니다. 다음 글에서는 Helm(헬름, 쿠버네티스 패키지 매니저)으로 상태 저장 애플리케이션 배포 자동화하는 방법도 다룰 예정입니다.

    Kubernetes StatefulSet vs Deployment 구조 비교 아키텍처 이미지

    Deployment와 StatefulSet이 Pod, Service, Volume을 어떻게 다르게 다루는지 한눈에 보는 개요 이미지입니다.

    1. 왜 Kubernetes StatefulSet vs Deployment가 중요한가

    쉽게 말해 Deployment는 언제든 교체 가능한 복제본을 잘 다루고, StatefulSet은 각 인스턴스가 자기 이름과 저장소를 유지해야 하는 경우를 잘 다룹니다.

    예를 들어 보겠습니다.

    • 웹 프론트엔드나 API 서버는 Pod가 하나 죽어도 새 Pod가 뜨면 보통 괜찮습니다.
    • 반면 데이터베이스나 메시지 큐(message queue, 비동기 메시지 처리 시스템)는 각 인스턴스가 가진 데이터와 순서가 중요거든요.
    • 캐시 서버도 단일 노드냐 클러스터 구성이냐에 따라 선택이 달라집니다.

    제가 처음엔 Redis를 무조건 Deployment로 올렸었는데요. 단일 캐시 테스트 용도에선 괜찮았는데, 나중에 persistent volume을 붙이고 노드 재스케줄링이 일어나니까 예상과 다르게 동작하는 부분이 있었어요. 그때 느낀 게, 상태 저장 애플리케이션은 살아 있는 데이터만 보는 게 아니라, 재시작 이후의 동일성까지 봐야 한다는 점이었습니다.

    2. 개념부터 쉽게 정리해보겠습니다

    2-1. Deployment란?

    Deployment는 ReplicaSet(레플리카셋, 동일 Pod 복제 관리)을 통해 여러 Pod를 선언적으로 관리하는 방식입니다. 주 목적은 무중단에 가깝게 애플리케이션 배포를 반복 가능하게 만드는 것입니다.

    • Pod 이름은 매번 바뀔 수 있습니다.
    • 특정 Pod가 죽어도 새 Pod가 대체되면 됩니다.
    • Rolling Update(롤링 업데이트, 순차 교체)가 편하죠.
    • 웹 서버, API 서버, 워커(worker, 백그라운드 작업 프로세스)에 잘 맞습니다.

    2-2. StatefulSet이란?

    StatefulSet은 이름 그대로 상태(state)를 가진 워크로드를 위한 리소스입니다. 각 Pod가 고정된 네트워크 식별자와 안정적인 스토리지 연결을 유지하도록 설계되어 있거든요.

    • Pod 이름이 ordinal(순번) 기반으로 고정됩니다. 예: db-0, db-1
    • 생성/삭제 순서가 제어됩니다.
    • 각 Pod마다 독립적인 PersistentVolumeClaim(PVC, 영구 볼륨 요청)이 붙을 수 있습니다.
    • 데이터베이스, ZooKeeper, Kafka 계열, 복제 구조가 있는 저장소에 자주 씁니다.

    저도 처음엔 이게 뭔가 싶었는데, 실제로 써보니까 StatefulSet은 Pod를 복제한다기보다, 번호가 붙은 개별 인스턴스를 관리한다는 느낌으로 이해하는 게 가장 쉽더라고요.

    3. 핵심 차이점 비교: Kubernetes StatefulSet vs Deployment

    항목 Deployment StatefulSet
    주 용도 Stateless 애플리케이션 배포 Stateful 애플리케이션 배포
    Pod 이름 가변적 고정적 순번 부여
    스토리지 공유 또는 외부 스토리지 중심 Pod별 고정 스토리지 할당 가능
    생성/종료 순서 순서 보장 약함 순차 생성, 순차 종료
    네트워크 식별성 Pod 교체 시 변경 가능 안정적인 DNS 이름 유지
    대표 사용 사례 웹, API, 배치 워커 DB, 분산 저장소, 클러스터형 메시지 시스템

    여기서 독자분들이 가장 헷갈리는 부분이 스토리지입니다. Deployment에도 PVC를 붙일 수는 있습니다. 그래서 겉보기엔 둘 차이가 없어 보일 수 있어요. 근데 StatefulSet은 각 Pod가 자기 볼륨을 안정적으로 유지해야 하는 구조를 전제로 설계되어 있거든요. 이 차이가 운영 중엔 꽤 크게 작용합니다.

    3-1. 언제 Deployment를 선택하나

    • Pod가 교체돼도 서비스만 유지되면 되는 경우
    • 세션 상태를 외부 Redis나 DB에 저장하는 경우
    • 스케일 아웃/인 빈도가 잦은 경우
    • CI/CD로 잦은 애플리케이션 배포가 필요한 경우

    3-2. 언제 StatefulSet을 선택하나

    • 각 인스턴스마다 고유 ID가 필요한 경우
    • 볼륨을 Pod별로 안정적으로 유지해야 하는 경우
    • 클러스터 합류 순서나 부팅 순서가 중요한 경우
    • 상태 저장 애플리케이션 특성상 재시작 후에도 동일한 엔드포인트가 필요한 경우

    실제로 써보니까, 애매하면 먼저 데이터의 소유권이 누구에게 붙는지를 보면 판단이 쉽습니다. 데이터가 서비스 전체에 느슨하게 연결되면 Deployment 쪽, 데이터가 특정 인스턴스에 강하게 묶이면 StatefulSet 쪽이더라고요.

    4. 실전 구현 1: Deployment로 Stateless 앱 배포

    먼저 Nginx(엔진엑스, 웹 서버)를 Deployment로 배포해보겠습니다. 이 예제는 구조를 이해하기 위한 가장 기본적인 형태입니다.

    1. Deployment 매니페스트를 작성합니다.
    2. Service(서비스, 네트워크 접근 추상화)로 노출합니다.
    3. 롤링 업데이트와 스케일링을 확인합니다.
    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP
    kubectl apply -f web-deployment.yaml
kubectl get deploy,pods,svc -o wide

    이 상태에서 Pod 하나가 내려가도 새 Pod가 올라오면 됩니다. 이름이 바뀌어도 크게 문제되지 않죠. 바로 이 특성이 Deployment의 장점입니다.

    업데이트도 간단합니다.

    kubectl set image deployment/web-deployment nginx=nginx:latest
kubectl rollout status deployment/web-deployment

    제가 직접 해보니 테스트 환경이나 프론트엔드 계층은 거의 이 패턴으로 끝나더라고요. 단순하고, 빠르고, 운영 피로도가 낮습니다. 드디어 됐다! 싶은 순간이 자주 오는 쪽이죠.

    Kubernetes StatefulSet vs Deployment 중 Deployment 롤링 업데이트 설명 이미지

    Deployment가 ReplicaSet과 함께 Pod를 순차 교체하는 흐름을 설명하는 이미지입니다.

    5. 실전 구현 2: StatefulSet으로 상태 저장 애플리케이션 배포

    이번엔 StatefulSet 예제를 보겠습니다. 여기서는 이해를 위해 간단한 Nginx 이미지를 쓰되, 핵심은 고정된 Pod 이름과 volumeClaimTemplates 구조를 보는 데 있습니다. 실제 운영에서는 MySQL, PostgreSQL, Redis 클러스터, RabbitMQ 같은 워크로드에서 더 의미가 커요.

    StatefulSet은 보통 Headless Service(헤드리스 서비스, 개별 Pod 식별을 위한 서비스)와 함께 사용합니다.

    apiVersion: v1
kind: Service
metadata:
  name: web-headless
spec:
  clusterIP: None
  selector:
    app: web-stateful
  ports:
    - port: 80
      name: http
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web-stateful
spec:
  serviceName: web-headless
  replicas: 3
  selector:
    matchLabels:
      app: web-stateful
  template:
    metadata:
      labels:
        app: web-stateful
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80
              name: http
          volumeMounts:
            - name: web-data
              mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
    - metadata:
        name: web-data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Gi
    kubectl apply -f web-statefulset.yaml
kubectl get statefulset,pods,pvc,svc

    적용 후 보면 Pod가 이런 식으로 생성됩니다.

    • web-stateful-0
    • web-stateful-1
    • web-stateful-2

    그리고 PVC도 Pod별로 따로 붙습니다. 이게 진짜 중요합니다. 예를 들어 web-data-web-stateful-0 같은 식으로 각 인스턴스가 자기 스토리지를 계속 들고 가거든요.

    여기서 중요한 포인트! StatefulSet은 삭제 후 다시 생성되어도 같은 이름 규칙과 볼륨 연결을 유지하는 데 초점이 있습니다. 이 특성 덕분에 상태 저장 애플리케이션 운영이 가능해집니다.

    kubectl delete pod web-stateful-1
kubectl get pods -w

    이렇게 해보면 동일한 ordinal을 가진 Pod가 다시 올라옵니다. 제가 홈랩에서 PostgreSQL 실험할 때도 이 패턴 덕분에 노드 교체 후 구조를 이해하기 쉬웠습니다. 물론 데이터 정합성은 애플리케이션 레벨에서 별도로 봐야 하지만요.

    6. ⚠️ 실제로 많이 겪는 문제와 트러블슈팅

    6-1. Deployment에 데이터베이스를 올리고 나중에 후회하는 경우

    이거 진짜 자주 봅니다. 처음엔 빠르게 띄우려고 Deployment로 시작하거든요. 근데 운영 중에 Pod가 교체되고, 스토리지 붙는 방식이 예상과 다르면 문제를 마주하게 됩니다.

    • Pod 이름이 바뀌어 클러스터 노드 인식이 꼬임
    • 단일 PVC 공유 구조가 애플리케이션 특성과 맞지 않음
    • 복제본 간 데이터 소유권이 불명확해짐

    해결 방향: 데이터가 인스턴스별로 귀속되는 구조라면 StatefulSet으로 전환을 검토해야 합니다.

    6-2. Headless Service를 빼먹는 경우

    저도 처음엔 왜 서비스가 꼭 필요하지? 했었는데, StatefulSet에서 안정적인 네트워크 식별성을 얻으려면 Headless Service가 사실상 핵심이거든요.

    kubectl get svc web-headless
kubectl describe statefulset web-stateful

    Pod 간 통신이나 클러스터 초기화가 필요한 앱이라면 이 부분을 꼭 확인하세요.

    6-3. PVC가 남는 걸 보고 당황하는 경우

    StatefulSet을 줄였는데 볼륨이 바로 안 지워져서 당황하는 경우가 있습니다. 근데 이건 오히려 안전장치에 가깝습니다. 실수로 데이터가 날아가면 더 큰일이거든요.

    주의: StatefulSet 삭제가 곧 데이터 삭제를 의미하지는 않습니다. 스토리지 정책과 reclaim policy를 같이 확인해야 합니다.

    6-4. 순서 의존성을 무시하고 병렬처럼 다루는 경우

    StatefulSet은 생성과 종료 순서가 의미가 있습니다. 특히 클러스터형 데이터베이스나 합의 기반 시스템은 더 그렇습니다. 그래서 readiness probe, startup probe 같은 헬스체크도 같이 설계해야 하죠. 저도 이걸 대충 봤다가 부팅 순서 꼬여서 한참 로그만 들여다봤습니다 ㅎㅎ

    Kubernetes StatefulSet vs Deployment 중 StatefulSet 스토리지 구조 이미지

    StatefulSet에서 각 Pod가 독립적인 영구 볼륨과 DNS 이름을 갖는 구조를 설명하는 이미지입니다.

    7. 검증 방법: 내가 만든 배포가 의도대로 동작하는지 확인

    설정이 끝났으면 꼭 검증해야 합니다. YAML만 맞다고 끝이 아니더라고요. 실제로 재시작, 스케일링, 이름 유지 여부를 봐야 합니다.

    7-1. Deployment 검증

    kubectl get deployment web-deployment
kubectl rollout history deployment/web-deployment
kubectl scale deployment web-deployment --replicas=5
kubectl get pods -l app=web
    • Pod 수가 바로 조정되는지
    • 업데이트 중 서비스 중단이 없는지
    • 새 Pod 이름이 생성되어도 서비스 접근이 유지되는지

    7-2. StatefulSet 검증

    kubectl get statefulset web-stateful
kubectl get pods -l app=web-stateful
kubectl get pvc
kubectl scale statefulset web-stateful --replicas=2
kubectl get pods,pvc
    • Pod가 역순으로 종료되는지
    • 줄였다가 다시 늘렸을 때 ordinal이 유지되는지
    • PVC가 각 Pod에 맞게 보존되는지

    🎉 여기서 원하는 대로 동작하면 거의 감이 옵니다. Deployment는 교체 가능한 인스턴스 관리에 최적화되어 있고, StatefulSet은 상태와 순서를 존중하는 구조라는 점이 실제 결과에서 드러납니다.

    Kubernetes StatefulSet vs Deployment 검증 결과 대시보드 이미지

    배포 후 Pod, PVC, 롤아웃 상태를 검증하는 운영 화면 느낌의 이미지입니다.

    8. 자주 묻는 질문과 정리

    8-1. Kubernetes StatefulSet vs Deployment: PVC를 붙이면 차이가 없나요?

    비슷해 보일 수는 있지만 다릅니다. 핵심은 Pod별 고정 정체성과 순서 보장입니다. PVC 하나 붙였다고 StatefulSet의 운영 특성이 생기지는 않습니다.

    8-2. 모든 데이터베이스는 무조건 StatefulSet인가요?

    대체로 그렇지만, 실제 운영 구조에 따라 외부 매니지드 데이터베이스를 쓰면 Kubernetes 안에 직접 올리지 않을 수도 있습니다. 즉, 워크로드 선택은 애플리케이션 구조 전체를 봐야 합니다.

    8-3. 캐시는 어떤 걸 써야 하나요?

    단순 캐시, 세션 캐시처럼 날아가도 되는 구조는 Deployment가 편합니다. 반면 복제, 영속성, 노드 식별이 중요해지면 StatefulSet 쪽을 봐야 합니다.

    8-4. 결국 어떤 기준으로 결정하면 되나요?

    1. Pod가 바뀌어도 되는가?
    2. 각 인스턴스가 자기 데이터를 가져야 하는가?
    3. 이름과 네트워크 식별성이 유지되어야 하는가?
    4. 생성/종료 순서가 중요한가?

    이 네 가지에 하나라도 강하게 해당되면 StatefulSet을 우선 검토해보세요.

    정리해보겠습니다.

    • Deployment: 빠르고 유연한 애플리케이션 배포, stateless 워크로드에 적합
    • StatefulSet: 상태 저장 애플리케이션, 고정 이름, 고정 스토리지, 순서 제어에 적합

    저도 처음엔 Kubernetes StatefulSet vs Deployment를 너무 단순하게 봤었는데, 실제로 운영해보니까 선택이 잘못되면 나중에 구조를 다시 뜯어고쳐야 하더라고요. 특히 홈랩처럼 이것저것 실험하는 환경에서는 처음부터 정답을 맞히기 어렵습니다. 그래서 더더욱 워크로드의 상태 특성을 먼저 보는 습관이 중요합니다.

    💡 팁 하나 남기자면, 처음 설계할 때는 “이 Pod가 내일 사라져도 괜찮은가?”를 스스로에게 물어보세요. 괜찮으면 Deployment일 가능성이 높고, 안 괜찮으면 StatefulSet을 봐야 합니다.

    마지막으로, 다음 글에서는 StatefulSet 기반 데이터베이스를 백업/복구 관점에서 어떻게 설계하면 좋은지 다뤄보겠습니다. 그 글까지 같이 보시면 Kubernetes 워크로드 선택 감이 훨씬 또렷해지실 겁니다.

    어떤 워크로드에 Deployment를 쓰고, 어떤 경우 StatefulSet을 써야 하는지 요약한 비교 이미지입니다.