13년차의 서버실

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

[카테고리:] k8s

  • [k8s] Karpenter 오토스케일링, 성능 벤치마크: 다양한 워크로드 환경 테스트

    [k8s] Karpenter 오토스케일링, 성능 벤치마크: 다양한 워크로드 환경 테스트

    목차

    [Kubernetes] Karpenter 성능 벤치마크로 보는 오토스케일링 테스트

    Karpenter 성능 벤치마크 이야기를 해보려고 합니다. Kubernetes(쿠버네티스) 운영을 조금만 오래 해보면, 결국 병목은 애플리케이션이 아니라 노드가 언제, 얼마나 빠르게 붙느냐에서 터지는 경우가 많거든요. 저도 홈랩과 실서비스에 가까운 테스트 환경에서 이것저것 만져보면서 느낀 게, 오토스케일링은 단순히 “늘어난다”가 아니라 얼마나 빨리 반응하고, 얼마나 낭비 없이 붙고, 붙은 뒤 얼마나 안정적으로 정리되느냐까지 같이 봐야 한다는 점이었습니다.

    특히 이번 글은 Karpenter 성능 벤치마크라는 키워드에 맞춰서, 단순 사용기가 아니라 benchmark(벤치마크) 관점으로 정리했습니다. 수치만 던지는 글이 아니라, 어떤 워크로드에서 무엇을 관찰해야 하는지, 그리고 Kubernetes 오토스케일링 성능을 볼 때 어디서 실수하기 쉬운지까지 같이 묶어보겠습니다. 혹시 노드 확장 속도 테스트를 해보려고 하는데 어디서부터 봐야 할지 막막하셨다면, 이 글이 꽤 도움이 될 겁니다.

    Karpenter 성능 벤치마크를 위한 쿠버네티스 오토스케일링 아키텍처 개요 이미지

    Karpenter, 스케줄러, 워크로드, 신규 노드 프로비저닝 흐름을 한눈에 보여주는 아키텍처 개요 이미지입니다.

    Karpenter란 무엇이고, 벤치마크에서 왜 중요할까요?

    쉽게 말해 Karpenter는 Pending Pod(스케줄되지 못하고 대기 중인 파드)를 보고, 거기에 맞는 노드를 빠르게 띄우는 방식의 노드 프로비저너입니다. 예전에는 HPA(Horizontal Pod Autoscaler, 파드 수 자동 조절)와 Cluster Autoscaler(클러스터 오토스케일러, 노드 수 자동 조절)를 묶어서 보는 경우가 많았는데요. Karpenter는 여기서 조금 더 직접적으로 “어떤 노드가 필요한지”를 계산해서 띄우는 쪽에 가깝습니다.

    제가 처음 이걸 봤을 때는 “결국 노드 늘리는 거 아닌가?” 싶었는데, 실제로 써보니까 차이가 꽤 크더라고요. 특히 아래 같은 부분이 벤치마크 포인트였습니다.

    • 프로비저닝 결정 속도: Pending Pod가 생긴 뒤 새 노드가 뜨기까지의 흐름
    • bin packing(빈 패킹, 자원 밀집 배치) 효율: CPU와 메모리 요청량에 맞춰 얼마나 낭비 없이 배치되는지
    • 워크로드 적합성: 짧게 치고 빠지는 배치성 작업과, 지속적으로 부하가 유지되는 서비스형 워크로드에서 반응이 다른지
    • 정리 속도: 부하가 빠졌을 때 불필요한 노드를 얼마나 깔끔하게 줄이는지

    여기서 중요한 포인트! Karpenter 효율성 검증은 “몇 초 빨랐다”보다, 스케줄링 실패 원인이 어디서 사라졌는지를 보는 게 더 중요합니다. 이미지 풀링(Image Pulling), CNI(Container Network Interface) 초기화, 리소스 요청값 과대설정 같은 변수가 너무 많거든요.

    벤치마크 설계: 어떤 워크로드로 테스트해야 하나요?

    벤치마크는 결국 설계가 반입니다. 제가 직접 해보니, 하나의 워크로드만 보면 결론이 자꾸 왜곡되더라고요. 그래서 최소한 아래 3종류는 나눠서 보는 걸 추천합니다.

    워크로드 유형 특징 관찰 포인트
    Burst API 짧은 시간에 요청 급증 노드 확장 속도 테스트, Pending Pod 해소 시점
    Batch Job 대량 Job이 한 번에 생성 bin packing 효율, 스케줄링 밀집도
    Steady Service 지속적인 중간 부하 과잉 프로비저닝 여부, 축소 안정성

    이렇게 나누는 이유가 있습니다. Burst API는 순간 반응 속도를 보기 좋고, Batch Job은 Karpenter가 노드를 얼마나 촘촘하게 맞춰 띄우는지 보기 좋습니다. Steady Service는 오히려 쓸데없이 많이 띄우지 않는지를 확인하기 좋습니다. 사실 운영에서는 이 마지막이 비용에 제일 크게 영향을 주더라고요.

    테스트 환경 준비: 관측 지표부터 맞춰야 합니다

    벤치마크 전에 먼저 해야 할 건 화려한 부하툴이 아니라 관측 기준 통일입니다. Prometheus(프로메테우스, 메트릭 수집), Grafana(그라파나, 시각화), 그리고 kubectl 이벤트 확인 정도는 꼭 준비해두세요. 저는 처음에 부하부터 때렸다가, 나중에 보니 노드는 떴는데 이미지 풀 때문에 파드가 늦게 뜬 거라 삽질 좀 했습니다 ㅎㅎ

    1. Kubernetes 클러스터 준비
    2. Karpenter 설치 및 기본 프로비저닝 정책 정의
    3. 메트릭 수집 도구 연결
    4. 부하 생성 도구 배치
    5. 이벤트 타임라인 기록
    helm repo add karpenter https://charts.karpenter.sh
helm repo update

kubectl create namespace karpenter
helm upgrade --install karpenter karpenter/karpenter \
  --namespace karpenter \
  --set settings.clusterName=my-cluster

    설치 방식은 환경마다 조금 다를 수 있지만, 핵심은 설치 자체보다 Provisioner/NodePool 성격의 정책과 워크로드 리소스 요청값을 맞추는 겁니다.

    apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      expireAfter: 720h
  disruption:
    consolidationPolicy: WhenUnderutilized

    위 예시는 개념 예시입니다. 실제 필드나 리소스 종류는 사용 중인 Karpenter 버전에 따라 다를 수 있으니, 운영 반영 전에는 현재 문서를 꼭 맞춰보셔야 합니다. 버전 차이 무시하고 복붙했다가 안 되는 경우가 진짜 많거든요.

    Karpenter 성능 벤치마크에서 NodePool과 리소스 요청값 구성을 설명하는 이미지

    NodePool 정책, 리소스 요청/제한, 스케줄링 조건이 어떻게 연결되는지 보여주는 구성 다이어그램입니다.

    실전 구현: 다양한 워크로드로 Karpenter 성능 벤치마크 진행하기

    1. Burst API 워크로드

    짧은 시간에 Deployment(디플로이먼트) 복제 수를 확 올리거나, HPA와 부하 생성기를 함께 써서 순간 부하를 만드는 방식입니다.

    kubectl scale deployment sample-api --replicas=50
kubectl get pods -w

    여기서 보는 건 단순히 파드가 Running 되는 순간이 아닙니다.

    • 처음 Pending이 발생한 시점
    • Karpenter가 노드 생성 결정을 내린 시점
    • 노드 Ready 시점
    • 파드가 실제 서비스 가능 상태가 된 시점

    제가 직접 해보니 이 네 구간을 나눠서 봐야 병목이 보였습니다. 노드 생성은 빨랐는데 DaemonSet 초기화 때문에 실제 서비스 반영이 늦는 경우도 있더라고요.

    2. Batch Job 워크로드

    Job을 여러 개 한 번에 던져보면 bin packing 효율을 확인하기 좋습니다.

    apiVersion: batch/v1
kind: Job
metadata:
  name: cpu-batch-sample
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: worker
          image: busybox
          command: ["sh", "-c", "sleep 120"]
          resources:
            requests:
              cpu: "500m"
              memory: "256Mi"
    for i in $(seq 1 30); do
  kubectl create -f job.yaml
done

    이 테스트는 생각보다 중요합니다. 왜냐하면 실제 운영에서는 API 서버보다 배치 잡이 더 난폭하게 클러스터를 흔드는 경우가 많거든요. 여기서 Karpenter가 과도하게 큰 노드를 띄우는지, 아니면 필요한 만큼만 맞춰 띄우는지를 체크하면 Karpenter 효율성 검증에 큰 도움이 됩니다.

    3. Steady Service 워크로드

    이건 부하를 오래 유지하면서 축소 동작까지 보는 테스트입니다.

    kubectl top nodes
kubectl top pods -A
kubectl get events -A --sort-by=.lastTimestamp

    중요한 건 “늘어나는 속도”만 보지 말고, 줄어들 때 서비스에 영향 없이 정리되는지도 같이 보셔야 합니다. 노드가 줄면서 PodDisruptionBudget(PDB, 파드 중단 예산)이나 스케줄링 제약과 충돌하면 오히려 운영 피로도가 확 올라갑니다.

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

    이 섹션은 꼭 넣고 싶었습니다. 벤치마크가 이상하게 나오면 대부분 Karpenter 자체 문제라기보다 주변 설정 때문이더라고요.

    • 리소스 요청값이 비현실적일 때: requests가 과하게 크면 노드가 과잉 생성됩니다.
    • 이미지 풀 지연: 새 노드가 떠도 컨테이너 이미지 다운로드 때문에 체감은 느립니다.
    • DaemonSet 오버헤드 누락: CNI, 로깅 에이전트, 모니터링 에이전트 자원이 계산에서 빠지면 예상보다 적게 들어갑니다.
    • 스케줄링 제약 과다: nodeSelector, affinity, taint/toleration이 많으면 Karpenter가 선택할 수 있는 노드 풀이 좁아집니다.

    저도 처음엔 “왜 노드를 띄웠는데 Pending이 안 없어지지?” 싶었는데, 알고 보니 topology spread constraints와 리소스 요청이 같이 꼬였던 적이 있었습니다. 이럴 때는 아래 순서로 보면 빨리 풀립니다.

    1. Pending Pod describe로 실패 이유 확인
    2. Karpenter 로그에서 provisioning decision 확인
    3. 노드 Ready 이후 CNI/DaemonSet 상태 확인
    4. 이미지 풀 시간과 애플리케이션 startup probe 확인
    kubectl describe pod <pending-pod-name>
kubectl logs -n karpenter deploy/karpenter
kubectl get daemonsets -A
kubectl describe node <new-node-name>

    💡 팁 하나 드리면, 노드 확장 속도 테스트를 할 때는 테스트용 이미지 크기를 최대한 줄이세요. 이미지가 크면 오토스케일링 성능이 아니라 레지스트리/네트워크 성능을 재게 됩니다.

    검증과 결과 해석: 숫자보다 흐름을 보세요

    이제 결과를 봐야죠. 다만 여기서 조심할 게 있습니다. 제가 일부러 구체 벤치마크 수치를 박지 않는 이유는, 인스턴스 타입, 네트워크, 이미지 캐시, CNI 구성에 따라 결과가 너무 달라지기 때문입니다. 대신 재현 가능한 관찰 포맷을 드리는 게 더 낫습니다.

    측정 항목 어떻게 확인하나 좋게 봐야 할 신호
    Pending 해소 시간 pod 상태 변화, 이벤트 타임라인 증가 구간이 짧고 일관적임
    노드 준비 시간 node Ready 시점 워크로드 증가 시 급격한 편차가 적음
    자원 밀집도 node/pod 사용률 비교 유휴 자원이 과도하게 남지 않음
    축소 안정성 scale-in 이후 재스케줄 상태 서비스 영향 없이 정리됨

    실제로 써보니까, Kubernetes 오토스케일링 성능은 “최대 속도”보다 “예상 가능한 속도”가 더 중요했습니다. 갑자기 한 번 엄청 빠른 결과가 나오는 것보다, 비슷한 조건에서 비슷하게 반응하는 쪽이 운영에는 훨씬 유리하거든요.

    Karpenter 성능 벤치마크 결과로 워크로드별 Pending Pod와 노드 준비 시간을 비교한 이미지

    Burst, Batch, Steady 워크로드별로 Pending Pod 해소 흐름과 노드 Ready 전환을 비교한 대시보드 이미지입니다.

    비교 정리: 어떤 환경에서 Karpenter가 특히 잘 맞을까요?

    제 기준으로는 아래 환경에서 특히 체감이 좋았습니다.

    • 트래픽 변동폭이 큰 서비스
    • 짧은 배치 작업이 자주 몰리는 플랫폼
    • 팀이 노드 타입과 비용 최적화까지 같이 보고 싶은 환경

    반대로, 부하가 거의 고정이고 노드 풀도 단순한 환경이라면 체감 이점이 크지 않을 수도 있습니다. 그래서 벤치마크는 꼭 “남들도 좋다더라”가 아니라 내 워크로드 기준으로 봐야 합니다. 여기서 중요한 포인트, 다시 한 번 말씀드리면 Karpenter 성능 벤치마크는 제품 홍보 자료처럼 보면 안 됩니다. 운영 제약, 워크로드 패턴, 팀의 관측 역량이 같이 들어가야 의미가 생깁니다.

    Karpenter 성능 벤치마크와 기존 오토스케일링 방식을 비교한 요약 이미지

    프로비저닝 방식, 반응성, 자원 활용 관점에서 Karpenter와 기존 접근을 비교한 요약 인포그래픽입니다.

    자주 묻는 질문

    Karpenter만 있으면 HPA는 필요 없나요?

    아닙니다. HPA는 파드 수를 늘리고, Karpenter는 그 파드가 올라갈 노드를 준비하는 역할에 가깝습니다. 둘은 대체 관계라기보다 연동 관계로 보는 게 맞습니다.

    벤치마크에서 가장 먼저 봐야 할 로그는 뭔가요?

    Pending Pod 이벤트와 Karpenter 컨트롤러 로그입니다. 여기서 프로비저닝 판단이 있었는지 먼저 확인해야 합니다.

    비용 절감 효과도 바로 검증할 수 있나요?

    가능은 하지만, 하루 이틀 테스트로 단정하긴 어렵습니다. 최소한 여러 워크로드 패턴을 반복해보고, 축소 정책까지 함께 봐야 의미가 있습니다.

    마무리: 빠른 확장보다 중요한 건 예측 가능한 확장입니다

    이번 글에서는 Karpenter 성능 벤치마크를 워크로드 유형별로 어떻게 봐야 하는지 정리해봤습니다. 제가 직접 해보니, 제일 중요한 건 화려한 벤치마크 숫자가 아니라 Pending 발생 → 노드 생성 결정 → 노드 Ready → 서비스 가능 이 흐름을 끊김 없이 읽어내는 것이었습니다. 드디어 됐다! 싶은 순간도 있었지만, 사실 그 전에 로그 보면서 한참 헤맨 적도 많았거든요.

    정리하자면 이렇습니다.

    • ✅ Burst, Batch, Steady 워크로드를 나눠서 봐야 합니다.
    • ✅ 노드 생성 속도만 보지 말고 이미지 풀과 DaemonSet 초기화도 같이 봐야 합니다.
    • ✅ Karpenter 효율성 검증은 절대 수치보다 일관성과 자원 활용 흐름이 중요합니다.

    다음 글에서는 HPA와 함께 붙였을 때의 상호작용, 그리고 실제 운영에서 자주 쓰는 관측 대시보드 구성도 따로 다뤄볼 예정입니다. 이전 글에서 다뤘던 클러스터 리소스 요청값 설계 내용도 같이 보시면 훨씬 이해가 쉬우실 겁니다.

  • [Kubernetes] Karpenter 프로비저닝 실패 디버깅 실제 사례 분석

    [Kubernetes] Karpenter 프로비저닝 실패 디버깅 실제 사례 분석

    목차

    [Kubernetes] Karpenter 프로비저닝 실패 디버깅 실제 사례 분석

    Karpenter 프로비저닝 실패 때문에 새 파드(Pod, 쿠버네티스에서 배포되는 최소 실행 단위)는 계속 Pending 상태인데, 오토스케일링(auto scaling, 부하에 따라 자동으로 늘고 줄어드는 기능)은 움직이지 않고, 로그만 한참 들여다보셨던 적 있으신가요? 저는 홈랩이든 업무 환경이든 이런 상황을 몇 번 겪었는데요. 처음엔 “분명 노드가 부족한데 왜 안 뜨지?” 싶었고, 실제로는 Karpenter 설정 자체보다 IAM(Role, 권한 역할), 서브넷(Subnet, 네트워크 구간) 태그, 인스턴스 제약 조건 같은 바깥 조건에서 막히는 경우가 많더라고요. 이번 글에서는 제가 실제로 디버깅할 때 밟는 순서대로, Karpenter 프로비저닝 실패를 어떻게 좁혀가는지 정리해보겠습니다.

    특히 Kubernetes 노드 문제 해결이나 Karpenter 디버깅이 익숙하지 않은 분들은, 무작정 로그부터 보는 것보다 “스케줄링 실패 → 프로비저닝 판단 → 클라우드 리소스 생성 → 노드 조인(join, 클러스터 참여)” 이 흐름으로 보면 훨씬 덜 헷갈리실 거예요. 저도 처음엔 이걸 한 덩어리로 봐서 삽질 좀 했습니다 ㅎㅎ

    Karpenter 프로비저닝 실패 흐름을 보여주는 Kubernetes 아키텍처 다이어그램

    Karpenter 프로비저닝 실패가 어느 단계에서 발생하는지 한눈에 보여주는 개요 이미지입니다.

    Karpenter 프로비저닝 실패를 볼 때 먼저 이해해야 할 흐름

    쉽게 말해 Karpenter는 “스케줄되지 못한 워크로드가 있네? 그럼 조건에 맞는 노드를 하나 띄워보자” 하고 판단하는 컴포넌트입니다. 여기서 중요한 포인트는, 단순히 노드를 많이 만드는 도구가 아니라 스케줄링 제약 조건을 해석해서 그에 맞는 노드를 계산한다는 점입니다.

    문제가 나는 지점은 보통 4군데입니다

    1. 파드 스케줄링 조건이 너무 빡빡한 경우
      예: nodeSelector, affinity, toleration, resource request가 충돌합니다.
    2. Karpenter가 적절한 노드 후보를 계산하지 못하는 경우
      예: 인스턴스 타입 제약, capacity type, 아키텍처 제약이 과합니다.
    3. 클라우드 리소스 생성 단계에서 실패하는 경우
      예: IAM 권한, 보안 그룹(Security Group), 서브넷 태그, 용량 부족 등이 걸립니다.
    4. 노드는 생성됐지만 클러스터에 조인하지 못하는 경우
      예: 부트스트랩(user data), 인증, 네트워크 경로 문제가 있습니다.

    이 네 구간만 분리해서 봐도 디버깅 난이도가 확 내려갑니다. 실제로 써보니까 “Karpenter가 고장났다”기보다는, 주변 조건 하나가 꼬여서 연쇄적으로 실패하는 경우가 더 많았습니다.

    Kubernetes 노드 문제 해결을 위한 기본 점검 순서

    제가 현장에서 가장 먼저 하는 건 거창한 분석이 아니라 증상 분리입니다. 파드가 문제인지, Karpenter 컨트롤러(controller, 제어 루프) 판단이 문제인지, 아니면 클라우드 API 호출이 막히는지부터 확인해야 하거든요.

    1. Pending 파드부터 확인

    kubectl get pods -A
kubectl describe pod <pod-name> -n <namespace>

    여기서 꼭 보는 건 Events입니다. 예를 들어 다음 같은 메시지가 보이면 방향이 잡힙니다.

    • 0/3 nodes are available: 기존 노드에 스케줄이 안 되는 상황입니다.
    • Insufficient cpu 또는 Insufficient memory: 리소스 부족입니다.
    • node(s) had untolerated taint: 톨러레이션(toleration, 테인트 허용 설정) 문제입니다.
    • node affinity/selector mismatch: 파드 조건이 너무 좁습니다.

    혹시 여기서 이미 affinity나 nodeSelector 충돌이 보이면, Karpenter 이전에 워크로드 정의부터 손봐야 합니다. 이걸 놓치면 Karpenter 로그만 하루 종일 보게 되거든요.

    2. Karpenter 로그 확인

    kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter --tail=200
kubectl get events -A --sort-by=.lastTimestamp

    로그에서는 이런 식의 단서를 찾습니다.

    • 프로비저닝 후보를 계산했는지
    • 요구사항(requirements) 때문에 제외된 인스턴스 타입이 있는지
    • 클라우드 제공자(provider) 호출에서 에러가 나는지
    • 생성 이후 노드 등록(register)이 안 되는지

    제가 직접 해보니, 로그를 길게 읽는 것보다 에러 키워드를 먼저 잡는 게 훨씬 빨랐습니다. 예를 들면 access denied, no subnets found, insufficient capacity, launch template 관련 문구 같은 것들이요.

    3. 노드 생성 여부와 조인 여부 분리

    kubectl get nodes
kubectl get nodeclaims
kubectl get nodepools
kubectl describe nodeclaim <name>

    환경에 따라 리소스 이름은 다를 수 있지만, 핵심은 같습니다. 클라우드 인스턴스는 떴는데 노드가 안 보이는지, 아니면 인스턴스 자체가 생성되지 않았는지를 나눠서 봐야 합니다. 이 차이가 엄청 큽니다.

    Karpenter 디버깅을 위한 파드 이벤트와 로그 비교 이미지

    파드 이벤트와 Karpenter 로그를 같이 놓고 보면 어디서 막히는지 훨씬 빨리 찾을 수 있습니다.

    실전 사례: Karpenter 디버깅을 이렇게 풀었습니다

    이건 제가 자주 보는 전형적인 패턴입니다. 특정 워크로드가 배포된 뒤 Pending 상태가 길게 이어졌고, 클러스터 오토스케일링 오류 분석이 필요했던 상황이었습니다. 기존 노드는 여유가 없었고, Karpenter가 새 노드를 올려줘야 정상인데 아무 변화가 없었죠.

    증상

    • 파드는 Pending 상태 유지
    • Karpenter는 동작 중
    • 기존 노드는 리소스 부족
    • 새 노드는 추가되지 않음

    제가 먼저 확인한 파드 스펙

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-workload
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-workload
  template:
    metadata:
      labels:
        app: sample-workload
    spec:
      nodeSelector:
        kubernetes.io/arch: amd64
      tolerations:
        - key: "workload-type"
          operator: "Equal"
          value: "batch"
          effect: "NoSchedule"
      containers:
        - name: app
          image: nginx:stable
          resources:
            requests:
              cpu: "1"
              memory: "1Gi"

    겉으로 보면 큰 문제 없어 보이죠. 저도 처음엔 워크로드 쪽은 괜찮다고 생각했었습니다. 근데 여기서 Karpenter 쪽 제약과 같이 봐야 했습니다.

    확인한 Karpenter 측 제약 예시

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values:
            - amd64
        - key: kubernetes.io/os
          operator: In
          values:
            - linux
        - key: karpenter.sh/capacity-type
          operator: In
          values:
            - spot

    여기서 문제는 단순 설정 문법이 아니었습니다. 워크로드는 특정 톨러레이션을 요구하고, NodePool은 spot만 허용하며, 실제 가용 영역이나 계정 조건상 적절한 인스턴스 풀이 너무 좁아진 상태였던 거죠. 게다가 서브넷 태그도 일부 누락돼 있었습니다. 결국 Karpenter 입장에서는 만들 수 있는 노드 후보가 사실상 거의 없었던 셈입니다.

    정리하면 원인은 두 개였습니다

    구분 문제 내용 영향
    네트워크 일부 서브넷 태그 누락 적절한 서브넷 탐색 실패
    용량 제약 spot만 허용하고 요구사항이 좁음 프로비저닝 후보 부족

    이런 경우 진짜 헷갈립니다. 로그에는 하나의 에러만 크게 보일 때도 있지만, 실제론 조건이 두세 개 겹쳐서 실패하는 경우가 많거든요.

    제가 적용했던 점검 명령어와 확인 포인트

    아래 명령어들은 특정 클라우드에 종속되지 않게, 쿠버네티스 관점에서 먼저 확인할 수 있는 것들입니다. 이 순서대로 보면 꽤 안정적으로 원인을 줄여갈 수 있었습니다.

    1. 파드 이벤트 확인
    2. Karpenter 로그에서 프로비저닝 시도 여부 확인
    3. NodePool/NodeClaim 조건 확인
    4. 생성된 노드 존재 여부 확인
    5. 클라우드 콘솔 또는 API에서 인스턴스 생성 실패 원인 확인
    kubectl describe pod <pod-name> -n <namespace>
kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter --since=30m
kubectl get nodepools -o yaml
kubectl get nodeclaims -o yaml
kubectl get nodes -o wide

    여기서 중요한 포인트! Karpenter 디버깅은 “쿠버네티스 안쪽 정보”와 “클라우드 바깥 정보”를 같이 봐야 끝이 납니다. 쿠버네티스 쪽만 보면 “왜 안 되지?”에서 끝나고, 클라우드 쪽만 보면 “인스턴스가 왜 안 뜨지?”로 끝나더라고요.

    Karpenter 프로비저닝 실패 원인인 NodePool 제약 조건 다이어그램

    NodePool 제약 조건이 겹칠수록 프로비저닝 가능한 후보가 급격히 줄어드는 상황을 설명하는 이미지입니다.

    ⚠️ 실제로 많이 만나는 Karpenter 프로비저닝 실패 원인

    이 섹션은 제가 여러 번 겪으면서 “아, 이건 체크리스트로 빼야겠다” 싶었던 것들입니다. 운영 중인 분들이라면 특히 공감하실 거예요.

    1. 파드 요구사항이 너무 강한 경우

    • nodeSelector가 특정 아키텍처나 라벨만 강제
    • podAntiAffinity가 과도하게 설정됨
    • requests가 커서 맞는 노드가 매우 제한적
    • toleration이 없어서 tainted node에 못 올라감

    처음엔 Karpenter가 노드를 안 만드는 줄 알았는데, 실제론 만들어도 스케줄이 안 맞는 상태라 계산상 제외되는 경우가 있었습니다.

    2. NodePool 요구사항이 좁은 경우

    • 특정 인스턴스 계열만 허용
    • spot만 허용
    • 특정 zone만 허용
    • 아키텍처와 운영체제 조건이 불필요하게 제한됨

    이건 비용 최적화하려다 자주 생깁니다. 저도 spot 위주로 예쁘게 짜보려다가, 정작 트래픽이 몰릴 때 후보가 없어서 자동 확장이 안 된 적이 있었거든요. 그래서 운영 환경에서는 제약은 최소화하고, 꼭 필요한 정책만 남기는 쪽이 더 안전했습니다.

    3. 클라우드 리소스 검색 실패

    • 서브넷 태그 누락
    • 보안 그룹 태그 누락
    • IAM 권한 부족

    이 부분은 쿠버네티스 YAML만 아무리 봐도 안 나옵니다. 특히 태그 기반 디스커버리(discovery, 자동 탐색)를 쓰는 경우라면, 네트워크 리소스가 올바르게 식별되는지 꼭 확인하셔야 합니다.

    4. 노드 생성 후 조인 실패

    • 부트스트랩 스크립트 문제
    • 클러스터 API 엔드포인트 접근 문제
    • 노드 인증 관련 설정 누락

    이 경우는 인스턴스는 생성되는데 kubectl get nodes에 안 보입니다. 그래서 “Karpenter가 아무것도 안 했다”고 오해하기 쉬워요. 근데 사실 한 단계는 진행된 상태인 거죠.

    문제를 줄이기 위한 운영 팁

    실제로 써보니까 아래 네 가지가 제일 효과 있었습니다.

    • NodePool 제약을 처음부터 너무 촘촘하게 만들지 않기
    • 파드 requests/limits를 현실적으로 설정하기
    • 서브넷, 보안 그룹, IAM 같은 외부 조건을 체크리스트화하기
    • 이벤트와 로그를 함께 보기

    특히 Kubernetes 노드 문제 해결이 필요한 상황에서 오토스케일링 오류 분석은 재현이 어려운 경우가 많아서, 문제가 생겼을 때 바로 볼 수 있는 로그 수집 체계를 미리 만들어두는 게 좋습니다. 이전 글에서 다뤘던 클러스터 이벤트 정리 방식이 있다면 같이 묶어보셔도 좋고요. 이 부분은 다음 글에서 더 깊게 다뤄볼 예정입니다.

    검증: 수정 후 무엇을 확인했나

    저는 설정을 손본 뒤 항상 세 가지를 확인합니다. 단순히 노드가 떠도 끝이 아니거든요.

    1. Pending 파드가 실제로 Running으로 전환되는지
    2. 새 노드가 기대한 라벨과 용량으로 조인되는지
    3. 불필요하게 과한 스케일아웃이 일어나지 않는지
    kubectl get pods -A -w
kubectl get nodes --show-labels
kubectl top nodes

    문제가 해결되면 보통 흐름이 이렇게 바뀝니다.

    • Pending 파드 발생
    • Karpenter가 새 노드 계산 및 생성
    • 노드가 클러스터에 조인
    • 파드가 새 노드에 스케줄됨

    드디어 됐다! 하는 순간이 여기입니다. 특히 오래 Pending이던 워크로드가 새 노드에 바로 올라가는 걸 보면, 이거 진짜 편하더라고요. 다만 성공했다고 끝내지 말고, 왜 실패했는지 기록해두는 게 다음 장애 때 훨씬 큰 도움이 됩니다.

    Karpenter 프로비저닝 실패 해결 후 Pending 파드가 Running으로 전환된 결과 이미지

    수정 전후를 비교해 Pending 파드가 Running으로 바뀌는 결과 확인 이미지입니다.

    정리: Karpenter 디버깅은 순서가 전부입니다

    Karpenter 프로비저닝 실패를 잡을 때 가장 중요한 건, 증상을 한 번에 해석하려고 하지 않는 겁니다. 저도 처음엔 로그 한 줄에서 답을 찾으려 했는데, 실제론 파드 조건, NodePool 제약, 클라우드 리소스 검색, 노드 조인 이 네 단계를 분리해서 봐야 풀리더라고요.

    혹시 지금도 Kubernetes 노드 문제 해결 때문에 막혀 계시다면, 아래 체크리스트부터 차근차근 보시면 좋겠습니다.

    • 파드 Events에 스케줄링 실패 원인이 보이는가
    • Karpenter가 실제로 프로비저닝을 시도했는가
    • NodePool 제약이 과하지 않은가
    • 서브넷, 보안 그룹, IAM 조건이 맞는가
    • 생성된 노드가 클러스터에 정상 조인하는가

    이 순서만 익혀도 Karpenter 디버깅 속도가 꽤 빨라집니다. 저도 처음엔 헷갈렸는데, 몇 번 정리해두고 나니 장애 대응 시간이 확 줄었습니다. 마무리 전에 요약 하나 더 남겨볼게요.

    Karpenter 프로비저닝 실패 디버깅 체크리스트 인포그래픽

    Karpenter 프로비저닝 실패 원인과 대응 순서를 한 장으로 정리한 요약 이미지입니다.

    FAQ: 자주 헷갈리는 포인트

    Q1. 파드가 Pending이면 무조건 Karpenter 문제인가요?

    아닙니다. 파드 스펙의 affinity, toleration, resource request가 원인인 경우도 많습니다.

    Q2. 노드가 생성되지 않으면 어디부터 봐야 하나요?

    파드 이벤트, Karpenter 로그, NodePool 조건을 먼저 보고, 그 다음 클라우드 리소스 조건을 확인하는 게 좋습니다.

    Q3. spot만 허용해도 괜찮을까요?

    가능은 하지만, 워크로드 특성과 가용성 요구사항을 고려해야 합니다. 운영에선 제약을 너무 좁히면 Karpenter 프로비저닝 실패 가능성이 올라가더라고요.

    마무리

    이번 글은 특정 버전 문법을 깊게 파기보다는, 문제가 났을 때 어떤 순서로 생각해야 하는지에 집중해봤습니다. 사실 운영에서는 정답 YAML 하나보다, 실패를 분해해서 보는 관점이 더 오래 가거든요. 다음 글에서는 Karpenter와 Cluster Autoscaler를 어떤 기준으로 나눠서 볼지, 그리고 워크로드별로 어떤 제약을 어디까지 허용할지 이어서 정리해보겠습니다.

  • [K8s] Karpenter 온프레미스 도입의 효율성 검증 및 실전 분석

    [K8s] Karpenter 온프레미스 도입의 효율성 검증 및 실전 분석

    목차

    [K8s] Karpenter 온프레미스 도입의 효율성 검증 및 실전 분석

    Karpenter 온프레미스가 얼마나 효율적일까—이 질문은 쿠버네티스(Kubernetes, 컨테이너 오케스트레이션)를 운영하다 보면 자연스럽게 나오더라고요. 노드(Node, 작업이 실제로 돌아가는 서버)까지 더 똑똑하게 자동으로 늘리고 줄일 수 없을까 하는 생각 말입니다. 저도 홈랩과 실무에서 이런 고민을 꽤 했었어요. 처음엔 이게 뭔가 싶었는데, 막상 파고들어 보니 Karpenter는 분명 매력적이면서도, 온프레미스에서는 생각보다 전제 조건이 많더라고요.

    결론부터 말씀드리면, Karpenter 온프레미스는 “기술적으로 이름만 가져와서 붙이는 문제”가 아니라 서버 수명주기(lifecycle), 네트워크, IP 주소 할당, OS 부팅 자동화까지 전부 자동화돼 있어야 진정한 효율이 나오는 구조입니다. 이 글에서는 제가 왜 그렇게 판단했는지, 어떤 식으로 검증했고 어디서 막혔는지, 그리고 어떤 팀에 맞고 어떤 팀에는 안 맞는지 정리해보겠습니다.

    Karpenter 온프레미스 도입 검토를 위한 전체 아키텍처 개요 이미지

    온프레미스 쿠버네티스 클러스터에서 스케줄러, Pending Pod, 노드 프로비저닝 흐름을 한눈에 보여주는 개요 이미지가 들어갈 자리입니다.

    Karpenter란 무엇인가, 쉽게 말해

    쉽게 말해 Karpenter는 스케줄링되지 못한 파드(Pod, 쿠버네티스의 실행 단위)를 보고, 거기에 맞는 노드를 빠르게 만들어 붙이는 데 초점을 둔 도구입니다. 기존 Cluster Autoscaler가 노드 그룹(Node Group) 중심으로 움직였다면, Karpenter는 워크로드 요구사항 중심으로 더 유연하게 판단하는 느낌이 훨씬 강하죠.

    공식 문서 기준으로 많이 다뤄지는 프로바이더(provider, 인프라 연동 구현체)는 AWS, Azure, Alibaba Cloud 쪽입니다. 여기서 중요한 포인트! Karpenter의 핵심 아이디어는 범용적이지만, 실제 노드를 만들어내는 동작은 프로바이더 구현에 크게 의존합니다. 즉, 온프레미스에서 “Karpenter를 쓴다”는 말은 결국 내 환경에 맞는 프로비저닝 백엔드를 어떻게 연결하느냐의 문제거든요.

    Karpenter 온프레미스가 매력적으로 보이는 이유

    솔직히 말해서, 아이디어만 보면 정말 좋습니다. 저도 처음엔 “이거 진짜 편하겠는데?” 싶었거든요.

    • 빈 노드 상시 대기를 줄일 수 있습니다.
    • 워크로드별로 CPU, 메모리, 아키텍처, taint/toleration 조건을 세밀하게 나눌 수 있습니다.
    • 배치 작업(Batch Job)이나 CI 러너(Runner)처럼 들쭉날쭉한 부하에 정말 잘 맞습니다.
    • Karpenter 효율성 관점에서 보면, 과하게 큰 노드를 오래 유지하지 않아도 된다는 기대가 생기죠.

    특히 온프레미스는 클라우드처럼 분 단위 과금은 아니어도, 전력, 랙 공간, 라이선스, 예비 장비 운용비가 은근히 큽니다. 그래서 온프레미스 오토스케일링에 관심이 가는 건 아주 자연스러운 흐름이에요.

    하지만 왜 온프레미스에서는 바로 풀리지 않나

    여기서부터 현실이 시작됩니다. 퍼블릭 클라우드에서는 API 한 번으로 가상머신(VM, 가상 서버)을 만들고, 네트워크도 붙이고, IAM 권한도 맞추고, 부팅 후 조인(join)까지 이어집니다. 반면 온프레미스는 보통 이게 한 덩어리로 묶여 있지 않습니다. 제가 직접 검토해보니, 진짜 어려운 건 Karpenter 자체보다 주변 자동화의 빈틈이더라고요.

    항목 퍼블릭 클라우드 온프레미스
    서버 생성 API로 즉시 생성 가상화 플랫폼 또는 베어메탈 절차 연동 필요
    네트워크 기본 VPC/서브넷 모델 존재 VLAN, IPAM, DHCP, DNS를 따로 맞춰야 함
    부팅/조인 이미지와 userdata로 표준화 PXE, 템플릿, 클라우드이닛 대체 절차 필요
    폐기 종료 API로 간단 디스크 정리, 모니터링 해제, CMDB 반영까지 고려
    확장 속도 대체로 빠름 사내 자동화 성숙도에 따라 편차 큼

    그래서 Karpenter 사용 후기를 물어보면, 저는 항상 이렇게 답합니다. “노드를 만드는 API가 이미 예쁘게 정리된 팀이라면 검토할 만하고, 아니면 Karpenter보다 선행 과제가 더 큽니다.”

    실전 구현: 제가 검증할 때 먼저 했던 순서

    저는 Karpenter를 바로 설치해서 결론 내리지 않았습니다. 먼저 정말 노드 자동 확장이 필요한 패턴인지부터 확인했거든요. 이거 안 하고 시작하면 높은 확률로 삽질하게 됩니다.

    1. Pending Pod가 얼마나 자주 생기는지 확인합니다.
    2. 그 Pending이 CPU/메모리 부족인지, taint/toleration 문제인지 구분합니다.
    3. 노드 추가 시간이 실제 서비스 요구와 맞는지 봅니다.
    4. 온프레미스에서 노드 생성 API가 있는지, 없으면 누가 그 역할을 할지 정합니다.

    1. 병목부터 확인하기

    kubectl get pods -A --field-selector=status.phase=Pending
kubectl get events -A --sort-by=.lastTimestamp
kubectl describe pod -n default cpu-burner-0
kubectl top nodes

    이 단계에서 FailedScheduling 이벤트를 꼭 봐야 합니다. 실제로 써보니까 “노드가 부족해서”가 아니라 노드 셀렉터(nodeSelector), 어피니티(affinity), 테인트(taint) 때문에 못 붙는 경우가 꽤 많더라고요.

    2. 의도적으로 스케줄 압박 만들기

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpu-burner
  namespace: default
spec:
  replicas: 6
  selector:
    matchLabels:
      app: cpu-burner
  template:
    metadata:
      labels:
        app: cpu-burner
    spec:
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.9
          resources:
            requests:
              cpu: "4"
              memory: "4Gi"
            limits:
              cpu: "4"
              memory: "4Gi"

    이런 식으로 일부러 Pending 상황을 만들고, 노드가 추가됐을 때 실제로 대기 시간이 얼마나 줄어드는지 봤습니다. 이 단계가 없으면 Karpenter 효율성을 논하기가 정말 어렵거든요.

    Karpenter 온프레미스 환경에서 Pending Pod와 노드 증설 흐름을 보여주는 구성 이미지

    Pending Pod 감지, 스케줄러 판단, 노드 프로비저닝 요청 흐름을 시각화한 구성 다이어그램이 들어갈 자리입니다.

    3. 지원 환경에서 기준선 만들기

    여기서 중요한 포인트가 하나 더 있습니다. Karpenter 동작 모델을 이해하려면, 우선 공식적으로 많이 다뤄지는 환경에서 기준선을 봐야 한다는 거예요. 예를 들어 AWS 계열에서는 NodePool, NodeClass 같은 리소스로 요구사항을 선언합니다. 온프레미스에서는 이 선언형 모델을 흉내 내더라도, 실제 서버 생성과 회수는 별도 자동화가 뒷받침돼야 합니다.

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      expireAfter: 720h
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

    이 YAML 자체보다 중요한 건, 온프레미스에서는 이 선언을 받아줄 실제 인프라 제어면(control plane)이 있느냐입니다. VMware vSphere, OpenStack, Proxmox, 베어메탈 PXE 자동화, BMC 연동 같은 것들이 이미 정리돼 있어야 이야기가 될 수 있거든요.

    ⚠️ 트러블슈팅: 제가 막혔던 지점들

    여기는 정말 경험상 중요합니다. 문서만 보면 쉬워 보이는데, 실제 운영에서는 대부분 여기서 시간이 날아갑니다.

    1. 노드 생성보다 노드 조인이 더 오래 걸림

    VM이 떠도 kubelet(큐블릿, 노드를 클러스터에 붙이는 에이전트) 조인이 늦으면 의미가 없습니다. 이미지 템플릿, 컨테이너 런타임, CNI(Container Network Interface, 컨테이너 네트워크), 인증서 부트스트랩이 전부 맞아야 하거든요.

    2. IPAM이 병목이 됨

    온프레미스 오토스케일링에서 자주 빠지는 함정입니다. 서버는 생겼는데 IP가 없거나, DNS 등록이 늦거나, 방화벽 정책 반영이 늦으면 결국 Pod는 계속 Pending 상태가 됩니다. 드디어 됐다! 싶었는데 네트워크 쪽에서 막히는 경우, 진짜 많습니다.

    3. 회수(deprovision) 정책이 더 민감함

    클라우드에서는 종료가 비교적 단순하지만, 온프레미스는 로그 수집, 백업, 모니터링 타깃 해제, 자산관리 반영까지 연결될 수 있습니다. 그래서 비용 최적화보다 운영 일관성이 더 우선인 팀도 많아요.

    4. 베어메탈은 더 신중해야 함

    가상머신은 그래도 템플릿 자동화가 익숙한 편인데, 물리 서버는 전원 제어, PXE, 디스크 초기화, 펌웨어 상태까지 섞입니다. 여기서는 Karpenter보다 먼저 서버 프로비저닝 파이프라인이 안정적이어야 해요.

    검증 결과: 그래서 효율적이었나

    제 결론은 꽤 단순합니다. Karpenter 온프레미스는 “이론상 가능”과 “운영상 효율적” 사이의 간격이 생각보다 크다는 거예요.

    • 효율적인 경우: VM 생성 API가 있고, 네트워크 자동화가 있으며, 노드 조인 시간이 짧고, 워크로드 변동성이 큽니다.
    • 비효율적인 경우: 서버 준비 시간이 길고, 수동 승인 절차가 많고, IP/DNS/보안정책 반영이 느립니다.
    • 애매한 경우: 항상 켜둬야 하는 기본 용량(base capacity)이 큰데, 추가 증설 빈도는 낮은 환경입니다.

    실제로 써보니까 Karpenter 자체는 정말 똑똑한데, 온프레미스에선 그 똑똑함이 발휘될 무대가 준비돼 있어야 하더라고요. 무대가 없으면 결국 “자동화된 척하는 수동 시스템”이 되기 쉽습니다.

    Karpenter 온프레미스 검증 결과를 보여주는 대시보드 이미지

    PoC 전후로 Pending Pod 수, 노드 사용률, 증설 후 조인 시간을 비교하는 대시보드 이미지가 들어갈 자리입니다.

    대안과 비교: 굳이 Karpenter여야 하나

    이 질문도 꼭 해봐야 합니다. 저도 처음엔 Karpenter에 시선이 갔는데, 나중엔 오히려 문제 정의를 다시 하는 게 더 중요하다고 느꼈거든요.

    선택지 잘 맞는 상황 한계
    Karpenter 인프라 API와 노드 자동화가 이미 성숙한 환경 주변 자동화 미성숙 시 효과 반감
    Cluster Autoscaler 기존 노드 그룹 운영이 익숙한 환경 세밀한 유연성은 상대적으로 제한
    고정 노드 + 요청/제한 재정비 부하 패턴이 예측 가능한 환경 유휴 자원 증가 가능
    배치 전용 풀 분리 CI, 렌더링, 분석 잡이 분리 가능한 환경 운영 구조가 다소 복잡해짐

    혹시 이런 경험 있으신가요? 노드가 부족한 줄 알았는데, 알고 보니 리소스 요청값(request)이 너무 공격적으로 잡혀 있었던 경우요. 이런 환경이면 Karpenter보다 먼저 requests/limits, affinity, PDB(PodDisruptionBudget, 중단 허용 범위)를 정리하는 쪽이 체감 효과가 훨씬 크더라고요.

    정리: 제가 내린 판단

    Karpenter 온프레미스는 분명 흥미로운 주제입니다. 다만 “쿠버네티스 노드 오토스케일링 도구 하나 더 설치하면 끝” 같은 그림으로 접근하면 거의 실패합니다. 제가 회고해보면, 성공 조건은 세 가지였어요.

    1. 노드 생성 API가 일관돼 있어야 합니다.
    2. 네트워크/IPAM/보안 정책 반영이 자동화돼 있어야 합니다.
    3. 노드 조인 시간이 서비스 요구를 만족해야 합니다.

    이 세 가지가 되면 Karpenter 효율성은 충분히 검토할 가치가 있습니다. 반대로 이 중 둘 이상이 수동이면, Karpenter는 멋진 이름이고 운영은 더 복잡해질 가능성이 크거든요. 그래서 저는 온프레미스에서 Karpenter를 볼 때 항상 도구보다 자동화 성숙도를 먼저 봅니다.

    Karpenter 온프레미스 도입 적합성과 대안을 정리한 요약 인포그래픽

    Karpenter 도입 적합성 체크리스트와 대안 선택 기준을 한 장으로 요약한 인포그래픽이 들어갈 자리입니다.

    FAQ와 다음 단계

    Q1. 온프레미스에서 Karpenter를 아예 못 쓰는 건가요?

    아예 불가능하다는 뜻은 아닙니다. 다만 공식적으로 널리 소개되는 흐름은 주로 클라우드 프로바이더 중심이고, 온프레미스에서는 프로비저닝 연동을 직접 설계해야 하는 비중이 훨씬 커요.

    Q2. 어떤 팀에 추천하나요?

    가상화 API, 템플릿 배포, DHCP/DNS/IPAM, 쿠버네티스 조인이 이미 자동화된 팀이라면 충분히 검토할 만합니다.

    Q3. 어떤 팀에는 비추천인가요?

    노드 한 대 늘릴 때 승인 절차가 여러 단계거나, 보안 정책 반영이 수동이면 비추천입니다. 이 경우엔 고정 노드 전략과 워크로드 정리가 훨씬 더 현실적이거든요.

    이전 글에서 다뤘던 리소스 요청값 튜닝과 스케줄링 정책 정리도 같이 보시면 정말 도움이 됩니다. 다음 글에서는 온프레미스 오토스케일링 관점에서 Karpenter 대신 어떤 선택지가 더 실용적인지, Cluster Autoscaler와 고정 노드 전략을 비교해볼 예정입니다.

    참고할 공식 자료

  • [k8s] Kubeadm vs ClusterAPI: Kubernetes 클러스터 프로비저닝 도구 비교

    [k8s] Kubeadm vs ClusterAPI: Kubernetes 클러스터 프로비저닝 도구 비교

    목차

    Kubeadm vs ClusterAPI: Kubernetes 클러스터 프로비저닝 도구 비교

    Kubeadm과 ClusterAPI를 비교할 때, 많은 분들이 같은 지점에서 막혀 있더라고요. “클러스터 하나 빨리 올리면 되는 건가?”, 아니면 “여러 환경에서 반복 가능하게 클러스터 구축 체계를 만들어야 하나?” 같은 고민 말이에요. 저도 홈랩에서 처음엔 kubeadm(쿠버네티스 클러스터 초기화 도구)만으로 시작했었는데, 노드 수가 늘고 재현 가능한 배포가 필요해지니까 Cluster API(CAPI, 쿠버네티스 방식으로 클러스터 자체를 관리하는 프로젝트) 쪽이 갑자기 눈에 들어오더라고요. 처음엔 이게 뭔가 싶었습니다. 컨트롤러도 많고, 프로바이더도 많고, YAML도 길고요. 근데 구조를 한 번 이해하고 나니 왜 운영팀들이 이 조합을 진지하게 보는지 감이 왔습니다.

    이 글에서는 단순히 기능 나열만 하지 않고, Kubeadm vs ClusterAPI를 실제 운영 관점에서 풀어보겠습니다. 쉽게 말해, kubeadm은 클러스터를 시작하게 해주는 공구에 가깝고, ClusterAPI는 클러스터 생애주기 자체를 선언형으로 다루는 운영 프레임워크에 가깝습니다. 여기서 중요한 포인트! 둘은 경쟁 관계이면서도, 실전에서는 같이 엮이는 경우가 꽤 많습니다.

    Kubeadm ClusterAPI 비교를 보여주는 쿠버네티스 클러스터 프로비저닝 아키텍처 이미지

    kubeadm은 개별 클러스터 부트스트랩 흐름에, Cluster API는 관리 클러스터에서 워크로드 클러스터를 선언형으로 제어하는 흐름에 초점이 있습니다.

    Kubernetes 클러스터 프로비저닝, 뭐가 다른가요?

    쉽게 말해 kubeadm은 노드에 들어가서 클러스터를 만드는 도구입니다. 컨트롤 플레인(클러스터 제어 영역) 초기화, 조인 토큰 생성, 인증서 배포 같은 부트스트랩 작업을 잘 해주죠. 반면 Cluster API는 클러스터를 쿠버네티스 리소스처럼 다루는 방식입니다. 즉, “이런 모양의 클러스터를 만들어줘”라고 선언하면 컨트롤러가 그 상태를 맞추려고 움직입니다.

    제가 직접 해보니 kubeadm은 구조가 비교적 단순해서 학습 진입 장벽이 낮았습니다. 특히 베어메탈(가상화 없이 물리 서버 직접 운영)이나 홈랩처럼 손으로 만질 수 있는 환경에서는 진짜 빠릅니다. 반대로 Cluster API는 관리 클러스터(다른 클러스터를 제어하는 클러스터)라는 개념부터 잡아야 해서 초반 허들이 있습니다. 대신 익숙해지면 반복 배포, 업그레이드, 스케일링, 클러스터 폐기까지 흐름이 꽤 깔끔해집니다.

    • kubeadm: 단일 클러스터 프로비저닝에 강함
    • Cluster API: 여러 클러스터의 선언형 운영과 생애주기 관리에 강함
    • CAPI + kubeadm: Cluster API가 kubeadm 기반 부트스트랩을 활용하는 조합이 현실

    Kubeadm vs ClusterAPI 핵심 구조 비교

    비교 항목 kubeadm Cluster API
    주요 목적 쿠버네티스 클러스터 초기 구성 클러스터 생성, 변경, 업그레이드, 삭제까지 생애주기 관리
    운영 방식 명령형(명령 실행 중심) 선언형(원하는 상태 기술)
    주요 실행 위치 대상 노드 관리 클러스터의 컨트롤러
    멀티 클러스터 운영 수동 설계 필요 기본 개념 자체가 멀티 클러스터 친화적
    인프라 연동 직접 구성 필요 Infrastructure Provider(인프라 프로바이더)로 연동
    업그레이드 자동화 운영 스크립트나 절차 설계 필요 버전 선언 후 컨트롤러 기반 롤링 변경 가능
    초기 난이도 상대적으로 낮음 상대적으로 높음

    여기서 중요한 포인트! Cluster API가 kubeadm을 대체하는 느낌으로 보일 수 있는데, 실제로는 Cluster API 안에서 kubeadm bootstrap provider를 사용하는 사례가 많습니다. 즉, kubeadm은 여전히 중요한 구성요소고, Cluster API는 그걸 더 큰 자동화 체계 안에 넣는 느낌이라고 보시면 이해가 편합니다.

    언제 kubeadm이 더 잘 맞을까요?

    • 처음 쿠버네티스 구조를 익히는 단계일 때
    • 노드 수가 적고 클러스터 수가 많지 않을 때
    • 베어메탈이나 제한된 홈랩 환경에서 빠르게 검증할 때
    • 구성 과정을 손으로 제어해야 안심되는 팀 문화일 때

    언제 Cluster API가 빛날까요?

    • 동일한 형태의 클러스터를 반복 생성해야 할 때
    • 개발, 스테이징, 운영 환경을 비슷한 클러스터 구축 템플릿으로 관리할 때
    • 클러스터 업그레이드와 노드 교체를 체계화하고 싶을 때
    • GitOps(Git 기반 선언형 운영)와 잘 엮고 싶을 때

    실전 구현 1: kubeadm으로 클러스터 올리기

    먼저 kubeadm 흐름부터 보겠습니다. 실제로 써보니까 kubeadm은 클러스터 내부 동작을 이해하는 데 정말 좋았습니다. 인증서, kubelet(노드 에이전트), CNI(컨테이너 네트워크 플러그인) 같은 개념이 어디서 필요한지 몸으로 익히게 되거든요. 다만 그만큼 수동 단계도 많습니다. 삽질 좀 했습니다 ㅎㅎ

    1. 런타임(container runtime)과 kubelet, kubeadm, kubectl 설치
    2. 컨트롤 플레인 노드에서 초기화
    3. CNI 설치
    4. 워커 노드 조인
    5. 상태 검증
    sudo kubeadm init \
  --pod-network-cidr=192.168.0.0/16

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubectl get nodes

    초기화가 끝나면 바로 Ready가 안 뜰 수 있습니다. 여기서 당황 많이 하시더라고요. 대부분은 아직 CNI가 없어서 그렇습니다.

    kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/master/manifests/calico.yaml
kubectl get pods -A

    워커 노드 조인은 `kubeadm token create –print-join-command`로 받은 명령을 그대로 실행하면 됩니다.

    kubeadm token create --print-join-command

    이 방식의 장점은 명확합니다. 어디서 뭐가 실패하는지 눈에 보입니다. 반대로 단점도 명확해요. 같은 클러스터를 세 번, 네 번 반복해서 만들다 보면 사람이 실수할 지점이 계속 생깁니다. 바로 이 지점에서 “클러스터 구축 도구를 더 선언형으로 가져가야 하나?”라는 생각이 들기 시작하더라고요.

    실전 구현 2: Cluster API로 선언형 클러스터 만들기

    이제 Cluster API 쪽입니다. 처음엔 관리 클러스터가 또 필요하다고 해서 부담스러웠는데, 실제 구조를 이해하고 나니 왜 필요한지 납득됐습니다. Cluster API는 몇 가지 핵심 컴포넌트로 나뉩니다.

    • Core Provider: Cluster API 핵심 리소스와 컨트롤러
    • Bootstrap Provider: 노드 초기화 데이터 생성(kubeadm 활용)
    • Control Plane Provider: 컨트롤 플레인 구성 관리
    • Infrastructure Provider: 실제 VM, 인스턴스, 머신, 네트워크 리소스 생성

    기본 흐름은 이렇습니다. 관리 클러스터에 Cluster API 컴포넌트를 설치하고, 그 위에 워크로드 클러스터(실제 애플리케이션이 올라갈 대상 클러스터)의 정의를 YAML로 적용합니다.

    clusterctl init --infrastructure <provider-name>

    프로바이더 이름은 사용하는 환경에 따라 달라집니다. 예를 들어 퍼블릭 클라우드, 프라이빗 클라우드, 베어메탈 쪽에서 선택지가 갈리죠. 여기서는 원리를 이해하는 데 집중하겠습니다.

    Cluster API 관리 클러스터와 워크로드 클러스터 구조를 설명하는 Kubeadm ClusterAPI 비교 이미지

    관리 클러스터에서 컨트롤러가 동작하고, 선언된 리소스를 바탕으로 워크로드 클러스터의 머신과 컨트롤 플레인을 조립하는 구조입니다.

    apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: demo-cluster
spec:
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: demo-control-plane
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: GenericInfrastructureCluster
    name: demo-infra
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: demo-control-plane
spec:
  replicas: 1
  version: v1.29.0
  kubeadmConfigSpec:
    clusterConfiguration: {}
    initConfiguration: {}
    joinConfiguration: {}
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: demo-md-0
spec:
  clusterName: demo-cluster
  replicas: 2
  selector:
    matchLabels: {}
  template:
    spec:
      version: v1.29.0
      clusterName: demo-cluster

    위 YAML은 Cluster API 구조 예시입니다. 실제 배포에서는 인프라 프로바이더 리소스가 더 들어가고, 환경 변수나 자격 증명도 필요합니다. 중요한 건 클러스터를 명령으로 만드는 게 아니라 상태로 선언한다는 점입니다. 이게 Cluster API의 본질이에요.

    kubectl apply -f cluster.yaml
kubectl get cluster
kubectl get machinedeployments
kubectl get machines

    제가 직접 해보니 여기서 재미있는 포인트가 있었습니다. kubeadm은 한 번 만들고 나면 이후 운영 자동화는 별도로 설계해야 하는데, Cluster API는 처음부터 “운영까지 생각한 구조”라는 느낌이 강합니다. 대신 디버깅은 더 추상적입니다. 노드 한 대에서 끝나는 문제가 아니라 컨트롤러, 프로바이더, 템플릿이 다 얽혀 있거든요.

    주의사항과 트러블슈팅: 실제로 많이 막히는 지점

    ⚠️ 여기 진짜 중요합니다. Kubeadm ClusterAPI 비교에서 많은 글이 장점만 말하는데, 실전에서는 막히는 지점이 선택 기준이 되더라고요.

    1. kubeadm은 CNI 전까지 정상처럼 보여도 정상 아닐 수 있습니다

    `kubeadm init`이 끝났다고 클러스터가 다 살아난 건 아닙니다. `kubectl get nodes`에서 `NotReady`가 보이면 CNI부터 의심하세요. 저도 처음엔 인증서 문제인 줄 알고 엉뚱한 로그만 한참 봤었습니다.

    kubectl describe node
kubectl get pods -A
journalctl -u kubelet

    2. Cluster API는 실패 지점이 더 분산됩니다

    예를 들어 머신이 안 생기면 인프라 프로바이더 문제인지, bootstrap 데이터 생성 문제인지, control plane reconciliation 문제인지 나눠서 봐야 합니다.

    kubectl get pods -A
kubectl get clusters,machines,machinedeployments,kubeadmcontrolplanes
kubectl describe machine <machine-name>
kubectl logs -n capi-system deployment/capi-controller-manager

    혹시 이런 경험 있으신가요? 리소스는 분명히 생성됐는데 상태가 계속 `Provisioning`에서 안 넘어가는 경우요. 이럴 땐 대부분 인프라 쪽 자격 증명, 이미지 템플릿, 네트워크 전제조건이 빠져 있는 경우가 많았습니다.

    3. kubeadm은 단순한 대신 표준화가 흔들리기 쉽습니다

    운영자가 둘 이상만 돼도 설치 옵션, OS 준비 상태, 네트워크 플러그인 선택이 조금씩 달라집니다. 결국 문서화와 스크립트화가 필수입니다. 즉, kubeadm이 간단하다고 해서 운영 체계까지 단순한 건 아니더라고요.

    4. Cluster API는 관리 클러스터 자체의 안정성이 중요합니다

    관리 클러스터가 흔들리면 워크로드 클러스터 변경 작업도 영향받습니다. 그래서 초기에 “관리 클러스터를 어디에 둘 것인가”를 꽤 신중하게 봐야 합니다. 홈랩에서는 한 대에 몰아넣으면 편하긴 한데, 장애 분리 측면에서는 아쉬움이 남습니다.

    검증과 결과 확인: 뭐가 더 운영 친화적인가

    검증은 단순히 `kubectl get nodes`만 보면 부족합니다. 생성, 변경, 교체, 삭제 흐름까지 봐야 합니다. 이 부분이 Kubernetes 클러스터 프로비저닝 도구를 비교할 때 핵심이거든요.

    1. 클러스터 최초 생성 시간과 절차 복잡도 확인
    2. 워커 노드 확장 방식 확인
    3. 버전 변경 시 운영 개입량 확인
    4. 장애 시 복구 절차 문서화 가능성 확인
    kubectl get nodes -o wide
kubectl get cluster
kubectl get machines
kubectl get events --sort-by=.lastTimestamp
    Kubeadm ClusterAPI 비교 결과를 검증하는 쿠버네티스 상태 확인 이미지

    노드 Ready 상태, Machine 리소스 변화, 이벤트 흐름을 통해 선언한 상태와 실제 상태가 맞아가는지 확인하는 장면을 상상하시면 됩니다.

    실제로 써보니까 결과는 꽤 분명했습니다. 하나의 클러스터를 깊게 이해하고 빠르게 구축하려면 kubeadm이 좋았고, 반복 가능한 다수의 클러스터를 체계적으로 관리하려면 Cluster API가 훨씬 운영 친화적이었습니다. 특히 업그레이드나 머신 교체 시나리오를 생각하면 차이가 더 벌어집니다.

    상황별 선택 가이드: 클러스터 구축 도구 어떤 게 맞을까

    상황 추천 이유
    홈랩에서 쿠버네티스 구조 학습 kubeadm 구성 요소를 직접 체감하기 좋음
    단일 운영 클러스터를 신중하게 수동 관리 kubeadm 절차가 명확하고 제어감이 높음
    여러 환경에 동일한 클러스터 배포 Cluster API 선언형 템플릿 재사용이 쉬움
    업그레이드/교체 자동화를 운영 정책으로 추진 Cluster API 생애주기 관리 철학에 잘 맞음
    베어메탈 자동화까지 포함한 확장 설계 환경에 따라 다름 인프라 프로바이더 성숙도와 운영 역량이 중요
    • 빠른 시작과 학습이 목표면 kubeadm
    • 반복성과 선언형 운영이 목표면 Cluster API
    • 둘 중 하나만 고집할 필요는 없음: kubeadm으로 원리 이해 후 CAPI로 확장하는 경로가 현실적
    Kubeadm ClusterAPI 비교 선택 기준을 정리한 요약 인포그래픽

    팀 규모, 클러스터 수, 자동화 요구사항, 관리 방식에 따라 어떤 도구가 더 어울리는지 한눈에 정리한 비교 이미지입니다.

    자주 묻는 질문

    Q1. Cluster API가 있으면 kubeadm은 이제 안 써도 되나요?

    그렇진 않습니다. 오히려 Cluster API 내부에서 kubeadm 기반 부트스트랩을 활용하는 경우가 흔합니다. kubeadm은 여전히 중요한 기반 기술입니다.

    Q2. 소규모 팀도 Cluster API를 바로 도입해야 할까요?

    반드시 그렇진 않습니다. 클러스터 수가 적고 운영자가 구조를 아직 익히는 단계라면 kubeadm이 더 현실적일 수 있습니다. 자동화 비용보다 복잡도 비용이 더 클 수 있거든요.

    Q3. GitOps와 더 잘 맞는 쪽은 무엇인가요?

    Cluster API가 더 자연스럽습니다. 클러스터 정의 자체를 리소스로 관리하니까 Git 저장소 기반 운영 모델과 궁합이 좋습니다.

    마무리: 현실적인 접근

    정리해보면 이렇습니다. Kubeadm vs ClusterAPI 비교는 단순한 우열 비교가 아니라, 운영 성숙도와 목표가 다른 두 접근입니다. 제가 직접 해보니 kubeadm은 쿠버네티스를 제대로 이해하게 해주는 좋은 선생님이었고, Cluster API는 그 다음 단계에서 운영 자동화를 체계로 바꿔주는 도구였습니다. 둘 중 하나가 무조건 정답은 아니었습니다.

    개인적으로는 이런 순서를 추천드립니다. 처음엔 kubeadm으로 컨트롤 플레인 초기화, CNI 연결, 노드 조인, 인증서 구조를 손으로 한 번 겪어보세요. 그다음 반복 배포가 필요해지는 시점에 Cluster API를 붙이면 훨씬 덜 헷갈립니다. 저도 처음엔 YAML만 보고 멍했었는데, 기반 개념을 알고 나니까 드디어 됐다! 싶은 순간이 오더라고요.

    다음 글에서는 kubeadm으로 만든 클러스터를 운영 표준화하는 방법이나, Cluster API와 GitOps를 연결하는 흐름을 따로 다뤄보겠습니다. 이전 글에서 다룬 네트워크 플러그인 비교나 Ingress(외부 트래픽 진입점) 구성 글과 함께 보시면 더 이해가 잘 되실 겁니다.

    처음엔 수동 구축으로 원리를 익히고, 이후 선언형 운영으로 넘어가는 학습 및 운영 로드맵을 보여주는 마무리 이미지입니다.

  • [k8s] Karpenter 오토스케일링 문제 해결: 노드 프로비저닝 실패 디버깅 가이드

    [k8s] Karpenter 오토스케일링 문제 해결: 노드 프로비저닝 실패 디버깅 가이드

    목차

    [Kubernetes] Karpenter 문제 해결: 노드 프로비저닝 실패 디버깅 가이드

    Karpenter 문제 해결 때문에 밤에 이벤트 로그 붙잡고 계신 적, 한 번쯤 있으시죠? 저도 처음엔 “오토스케일링은 붙여놓으면 알아서 되겠지” 했다가, 정작 트래픽이 몰리는 순간 Pod(파드, 쿠버네티스의 최소 배포 단위)는 Pending(펜딩, 스케줄 대기)인데 노드는 안 뜨고, Karpenter 로그는 뭔가 말은 많은데 핵심은 안 보이는 상황을 여러 번 겪었습니다. 특히 Kubernetes 노드 프로비저닝이 실패하면 서비스 지연이 바로 드러나기 때문에, 이 구간은 감으로 보면 안 되더라고요.

    이번 글은 AWS 환경에서 Karpenter를 운영할 때 자주 만나는 오토스케일링 실패 패턴을 기준으로 정리했습니다. 제가 홈랩과 실무 환경에서 직접 부딪히며 정리한 흐름이라, 문서만 읽었을 때보다 훨씬 빠르게 원인을 좁히는 데 도움이 되실 겁니다. 핵심은 하나입니다. Karpenter 디버깅은 “Pending Pod → 스케줄링 조건 → Karpenter 로그 → 클라우드 리소스” 순서로 봐야 한다는 점입니다.

    Karpenter 문제 해결을 위한 오토스케일링 아키텍처 개요 이미지

    Pending Pod, Karpenter controller, AWS 인프라 리소스가 어떻게 연결되는지 보여주는 전체 흐름도입니다.

    Karpenter 문제 해결, 왜 이렇게 헷갈릴까요?

    쉽게 말해 Karpenter는 “Pod가 요구하는 조건에 맞춰 새 노드를 빠르게 계산하고 띄워주는 컨트롤러”입니다. 그런데 실제로는 중간에 확인할 레이어가 꽤 많습니다. Kubernetes scheduler(스케줄러), Karpenter controller(컨트롤러), IAM(권한 체계), subnet/security group(서브넷/보안 그룹), instance type(인스턴스 타입) 조건, 그리고 quota(할당량)까지 다 연결돼 있거든요.

    저도 처음엔 Karpenter 로그만 뒤졌습니다. 근데 실제로 써보니까 문제의 출발점은 의외로 Pod 스펙인 경우가 많더라고요. 예를 들어 CPU 요청량이 과하게 잡혀 있거나, 특정 아키텍처만 허용했거나, taint/toleration(테인트/톨러레이션) 조합이 안 맞으면 Karpenter가 아무리 열심히 계산해도 답이 없습니다.

    • Pod 조건 문제: requests/limits, nodeSelector, affinity, toleration 충돌
    • Karpenter 설정 문제: NodePool(노드풀) 또는 기존 Provisioner(프로비저너) 제약이 너무 빡빡함
    • AWS 리소스 문제: IAM 누락, 태그 미설정, 서브넷 발견 실패
    • 용량 문제: 가용 영역 용량 부족, 인스턴스 타입 제한 과다, 계정 할당량 부족

    여기서 중요한 포인트! Karpenter 문제 해결은 “왜 노드가 안 떴지?”가 아니라 “왜 이 Pod를 만족하는 노드를 계산하지 못했지?”로 질문을 바꾸면 훨씬 빨라집니다.

    Karpenter 디버깅의 기본 원리

    제가 실제로 보는 순서는 거의 고정입니다. 삽질 좀 했습니다 ㅎㅎ 결국 순서를 정해두는 게 제일 낫더라고요.

    1. Pending 상태의 Pod를 확인합니다.
    2. 해당 Pod의 이벤트와 스케줄링 실패 메시지를 읽습니다.
    3. Karpenter controller 로그에서 같은 시점의 에러를 확인합니다.
    4. NodePool/EC2NodeClass 또는 기존 Provisioner/AWSNodeTemplate 조건을 검토합니다.
    5. AWS 측 리소스 발견, 권한, 용량 문제를 점검합니다.

    이 흐름을 안 지키면 로그는 잔뜩 보는데 정작 원인을 놓치기 쉽습니다. 특히 이벤트 메시지 한 줄이 전체 방향을 정해주는 경우가 많아요.

    Karpenter 디버깅 1단계: Pending Pod부터 확인하기

    가장 먼저 해야 할 일은 “안 뜨는 노드”가 아니라 “대기 중인 Pod”를 보는 겁니다. 아래 명령어부터 시작해 보세요.

    kubectl get pods -A --field-selector=status.phase=Pending
kubectl describe pod -n <namespace> <pod-name>
kubectl get events -A --sort-by=.lastTimestamp

    여기서 제가 제일 먼저 보는 건 다음 세 가지입니다.

    • Insufficient cpu/memory: 리소스 요청량이 현재/예상 노드와 맞지 않는 경우
    • node affinity mismatch: nodeSelector 또는 affinity 조건이 과도한 경우
    • untolerated taint: 노드 taint를 Pod가 허용하지 않는 경우

    예를 들어 이런 Pod 스펙은 흔히 문제를 만듭니다.

    apiVersion: v1
kind: Pod
metadata:
  name: inflate
spec:
  nodeSelector:
    kubernetes.io/arch: amd64
  containers:
    - name: pause
      image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
      resources:
        requests:
          cpu: "2"
          memory: "2Gi"

    이 자체는 틀린 YAML은 아닙니다. 다만 NodePool이 arm64만 허용하거나, 너무 작은 인스턴스 타입만 열어놨다면 Karpenter는 새 노드를 못 만듭니다. 결국 Kubernetes 노드 프로비저닝 실패처럼 보이지만, 시작점은 Pod 조건이죠.

    Karpenter 디버깅 2단계: 컨트롤러 로그에서 에러 패턴 찾기

    그다음은 Karpenter 로그입니다. 저는 보통 아래처럼 확인합니다.

    kubectl logs -n karpenter deploy/karpenter --since=30m
kubectl logs -n karpenter deploy/karpenter --since=30m | grep -i "error"
kubectl logs -n karpenter deploy/karpenter --since=30m | grep -i "provision"

    로그에서 자주 보는 키워드는 대략 이렇습니다.

    로그/증상 의미 우선 확인할 것
    no instance type met the scheduling requirements 조건에 맞는 인스턴스 타입이 없음 NodePool requirements, Pod requests
    insufficient capacity 가용 영역 또는 타입의 실시간 용량 부족 타입 범위 확대, AZ 분산
    access denied / unauthorized IAM 권한 문제 controller role, instance profile
    subnet/security group not found AWS 리소스 발견 실패 태그, selector 조건

    처음엔 이게 뭔가 싶었는데, 로그를 “읽는” 게 아니라 “분류”하기 시작하니까 속도가 확 달라지더라고요. 특히 access denied 계열은 쿠버네티스 문제가 아니라 거의 AWS 권한 문제였습니다.

    Karpenter 디버깅 과정에서 컨트롤러 로그와 NodePool을 점검하는 이미지

    Karpenter 컨트롤러 로그, NodePool 조건, EC2 관련 리소스를 함께 점검하는 디버깅 흐름 예시입니다.

    실전 구현: NodePool/Provisioner 조건 점검하기

    운영 중인 Karpenter 버전에 따라 리소스 이름이 다를 수 있습니다. 최근 계열은 NodePool/EC2NodeClass 조합을 많이 쓰고, 예전 문서에서는 Provisioner/AWSNodeTemplate 예제가 남아 있습니다. 그래서 제 습관은 “내 클러스터에 실제로 어떤 CRD가 있는지 먼저 보는 것”입니다.

    kubectl api-resources | grep -i karpenter
kubectl get nodepools
kubectl get ec2nodeclasses
kubectl get provisioners

    예를 들어 NodePool이 너무 제한적으로 잡혀 있으면 문제가 생깁니다.

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]

    여기서 흔한 실수는 이런 겁니다.

    • 인스턴스 패밀리 조건을 너무 좁게 설정
    • 특정 가용 영역만 허용
    • spot(스팟)만 허용했는데 해당 시점에 용량이 부족
    • daemonset(데몬셋) 오버헤드를 고려하지 않고 너무 작은 타입만 허용

    제가 직접 해보니 조건을 처음부터 정교하게 만드는 것보다, 일단 넉넉하게 열고 정상 프로비저닝을 확인한 뒤 점진적으로 좁히는 방식이 훨씬 덜 고생합니다.

    권장 점검 명령어

    kubectl describe nodepool <nodepool-name>
kubectl get ec2nodeclass <class-name> -o yaml
kubectl get provisioner <name> -o yaml

    설정에서 확인할 항목은 다음과 같습니다.

    1. 아키텍처 제약이 Pod와 맞는지
    2. 용량 타입(on-demand/spot) 제약이 과하지 않은지
    3. 서브넷/보안 그룹 선택 조건이 실제 AWS 태그와 일치하는지
    4. 노드 만료, 통합(consolidation) 정책이 과도하게 공격적이지 않은지

    ⚠️ 오토스케일링 실패를 만드는 대표 원인 5가지

    이 섹션은 제가 실제로 많이 봤던 순서대로 적겠습니다. Karpenter 디버깅에서 제일 시간을 많이 잡아먹는 부분이기도 합니다.

    1. IAM(권한 체계) 누락

    컨트롤러가 EC2 인스턴스를 생성하거나 조회할 권한이 없으면 노드가 당연히 안 뜹니다. 로그에 access denied, unauthorized 류 메시지가 보이면 거의 이쪽입니다. EKS에서 IRSA(IAM Roles for Service Accounts, 서비스어카운트용 IAM 역할)를 쓰는 경우, role annotation과 정책 연결 상태를 다시 확인해 보세요.

    2. Subnet/Security Group 태그 문제

    Karpenter는 보통 태그 기반으로 서브넷과 보안 그룹을 찾습니다. 근데 태그가 빠져 있거나 selector 조건과 안 맞으면 리소스를 발견하지 못합니다. 저는 이걸 네트워크 문제로 착각해서 한참 헤맸었는데, 사실은 태그 오타 하나였던 적도 있습니다.

    3. 인스턴스 타입 제한 과다

    예를 들어 특정 세대, 특정 패밀리, 특정 크기만 허용해 놓으면 실시간 수용 용량이 없을 때 바로 막힙니다. 운영에서는 후보군을 넓혀야 합니다. 특히 spot만 쓰는 환경은 더 그렇습니다.

    4. Pod 요청량 과다 또는 DaemonSet 오버헤드 미반영

    실제로 써보니까 작은 워크로드 하나만 보지 말고, CNI(컨테이너 네트워크 인터페이스), 로그 에이전트, 모니터링 에이전트 같은 데몬셋 자원까지 같이 봐야 하더라고요. 남는 것 같아도 실제 스케줄 가능 용량은 더 작습니다.

    5. AWS 계정 할당량 또는 AZ 용량 이슈

    설정이 멀쩡해도 특정 가용 영역에서 타입 수급이 안 될 수 있습니다. 이럴 땐 Karpenter 자체 버그보다 클라우드 용량 이슈일 가능성도 큽니다. 그래서 저는 가능한 한 여러 AZ와 여러 타입을 열어둡니다.

    kubectl get events -A --sort-by=.lastTimestamp
kubectl describe pod -n <namespace> <pod-name>
kubectl describe nodepool <nodepool-name>

    설정 예시: 디버깅용으로 조건을 단순화해보기

    문제가 길어질 때는 조건을 줄여서 정상 동작 여부부터 확인하는 게 좋습니다. 아래처럼 Pod를 단순화해서 테스트해 보세요.

    apiVersion: v1
kind: Pod
metadata:
  name: karpenter-debug
spec:
  containers:
    - name: pause
      image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"

    이 Pod조차 스케줄이 안 되면, 애플리케이션 문제가 아니라 Karpenter 또는 인프라 레이어 문제로 보는 게 맞습니다. 반대로 이건 뜨는데 실제 서비스 Pod만 안 뜬다면, 그때는 requests/affinity/toleration을 더 자세히 보시면 됩니다.

    Kubernetes 노드 프로비저닝 점검을 위한 YAML 설정과 kubectl 디버깅 이미지

    디버깅용 Pod YAML, kubectl describe 출력, NodePool 설정을 함께 비교하는 장면을 표현한 이미지입니다.

    검증 방법: 노드가 정말 의도대로 프로비저닝됐는지 확인

    노드가 하나 떴다고 끝이 아닙니다. 저는 아래 순서로 꼭 확인합니다.

    1. 새 노드가 생성됐는지 확인
    2. Pending Pod가 Running으로 전환됐는지 확인
    3. 노드 라벨, taint, allocatable 자원이 기대와 맞는지 확인
    4. 불필요하게 큰 인스턴스가 뜨지 않았는지 확인
    kubectl get nodes
kubectl get pods -A -o wide
kubectl describe node <node-name>
kubectl top nodes

    확인 포인트는 단순합니다.

    • Pod가 실제로 새 노드에 배치됐는가
    • 노드 라벨이 workload 조건과 맞는가
    • CPU/메모리 여유가 너무 적거나 너무 많지 않은가
    • 오토스케일링 실패가 반복되지 않는가

    드디어 됐다! 싶은 순간이 여기인데요, 여기서 끝내면 안 됩니다. 몇 분 후 consolidation이나 만료 정책 때문에 노드가 정리되면서 다시 Pending이 생길 수도 있거든요. 그래서 최소한 짧은 부하 테스트나 재배포 한 번은 꼭 해보시는 걸 권합니다.

    새 노드 생성 이후 Pending Pod가 Running으로 바뀌고 자원 사용량이 안정화된 결과 화면 예시입니다.

    운영 팁: 제가 실제로 적용하는 Karpenter 문제 해결 체크리스트

    혹시 이런 경험 있으신가요? 로그는 많은데 뭘 먼저 봐야 할지 몰라서 계속 왔다 갔다 하게 되는 상황이요. 그래서 저는 아래 체크리스트를 만들어 두고 그대로 봅니다.

    체크 항목 질문 판단 기준
    Pod 이벤트 왜 Pending인가? 스케줄링 실패 메시지가 명확해야 함
    Karpenter 로그 프로비저닝 계산을 했는가? instance type, subnet, 권한 관련 힌트 확인
    설정 제약 NodePool/Provisioner가 너무 좁은가? AZ, 타입, 아키텍처, 용량 타입 검토
    AWS 리소스 태그와 권한이 맞는가? subnet/security group 발견 가능해야 함
    검증 한 번 뜬 뒤 안정적으로 유지되는가? 재배포/부하 시 반복 확인

    이 체크리스트만 잘 지켜도 Karpenter 문제 해결 시간이 꽤 줄어듭니다. 그리고 이전 글에서 다룬 클러스터 리소스 요청량 설계 내용과 같이 보시면 더 이해가 쉬우실 겁니다. 다음 글에서는 Karpenter와 Cluster Autoscaler를 어떤 기준으로 나눠 볼지 정리해보려고 합니다.

    Karpenter 문제 해결 체크리스트를 요약한 인포그래픽 이미지

    Karpenter 문제 해결 순서를 한 장으로 요약한 체크리스트 인포그래픽입니다.

    정리: Karpenter 문제 해결은 순서가 전부입니다

    오늘 내용의 핵심은 복잡하지 않습니다. 오토스케일링 실패가 보이면 바로 AWS 콘솔부터 열지 말고, 먼저 Pending Pod 이벤트를 확인하세요. 그다음 Karpenter 로그, 그리고 NodePool/Provisioner 제약, 마지막으로 IAM과 네트워크 태그를 보는 흐름이 가장 효율적이었습니다.

    저도 처음엔 Karpenter가 너무 똑똑해서 알아서 다 해줄 줄 알았는데, 실제로는 “조건을 어떻게 열고, 어떤 로그를 먼저 읽느냐”가 훨씬 중요하더라고요. 특히 Kubernetes 노드 프로비저닝 이슈는 한 군데만 봐서는 잘 안 풀립니다. 대신 순서를 지키면 생각보다 금방 풀립니다.

    혹시 지금도 Karpenter 디버깅 중이시라면, 오늘 소개한 명령어 세트부터 그대로 실행해 보세요. 그리고 Pod 이벤트 한 줄, Karpenter 로그 한 줄만 정확히 읽어도 방향이 확 잡힐 겁니다. 이거 진짜 편하더라고요.

  • [k8s] ClusterAPI 도입 성공 사례: 온프레미스 Kubernetes 클러스터 자동화 구축기

    [k8s] ClusterAPI 도입 성공 사례: 온프레미스 Kubernetes 클러스터 자동화 구축기

    목차

    [인프라] ClusterAPI 도입으로 온프레미스 자동화 성공하기

    온프레미스 Kubernetes 환경을 오래 운영하다 보면 결국 같은 고민을 하게 됩니다. 클러스터 하나 만들 때마다 문서 열고, kubeadm 옵션 다시 확인하고, 네트워크랑 인증서 맞추고, 노드 추가할 때마다 사람 손이 들어가죠. 저도 그랬습니다. 그래서 이번 글에서는 제가 실제로 정리해 본 ClusterAPI 도입 사례를 중심으로, 온프레미스 Kubernetes 환경에서 클러스터 생성과 확장을 어떻게 자동화했는지 풀어보려고 합니다. 특히 여러 팀이 같은 기준으로 클러스터를 만들고 싶을 때, 이 접근이 왜 먹히는지 말씀드릴게요.

    처음엔 솔직히 이게 뭔가 싶었어요. Kubernetes 자체도 복잡한데 관리 클러스터까지 따로 둔다니 더 어려워 보였거든요. 근데 한 번 구조가 잡히고 나니까, “아 이건 사람 손을 줄이기 위한 운영 도구구나” 싶더라고요. 혹시 지금도 새 클러스터 만들 때마다 체크리스트부터 찾고 계신다면, 여기서 중요한 포인트를 같이 보시면 됩니다.

    ClusterAPI 도입 사례를 설명하는 온프레미스 Kubernetes 전체 아키텍처 이미지

    Management Cluster(관리 클러스터), Workload Cluster(운영 클러스터), 인프라 제공자와 GitOps 흐름을 한눈에 보여주는 아키텍처 이미지입니다.

    1. ClusterAPI란 무엇인가요?

    Cluster API(CAPI, 클러스터 수명주기 관리 프로젝트)를 쉽게 말하면, Kubernetes 방식으로 Kubernetes 클러스터를 만드는 도구예요. Deployment(디플로이먼트)를 선언적으로 관리하듯이, 클러스터 자체를 YAML로 선언하고 생성, 확장, 업그레이드까지 다루는 거죠.

    핵심은 세 가지입니다.

    • Management Cluster: 다른 클러스터를 생성하고 관리하는 기준 클러스터입니다.
    • Workload Cluster: 실제 애플리케이션이 올라가는 대상 클러스터입니다.
    • Provider: vSphere(브이스피어, 가상화 플랫폼), OpenStack(오픈스택, 프라이빗 클라우드 플랫폼), Bare Metal(베어메탈, 물리 서버) 같은 인프라와 연결해 주는 구성입니다.

    제가 직접 해보니 중요한 건 “클러스터 생성 절차를 코드로 옮긴다”는 점이었어요. 이게 되면 담당자가 바뀌어도 운영 방식이 흔들리지 않거든요. ClusterAPI 도입 사례가 주목받는 이유도 결국 여기 있습니다.

    2. 왜 온프레미스 Kubernetes 자동화에 잘 맞았나

    클라우드는 원래 API가 잘 되어 있어서 자동화가 비교적 쉬워요. 반면 온프레미스는 가상화 플랫폼, 네트워크, IP 할당 정책, 이미지 관리, 인증서 처리까지 다 제각각인 경우가 많습니다. 그래서 클러스터 자동화가 더 절실한데, 아이러니하게도 더 어렵죠.

    제가 보기에 Cluster API가 온프레미스에서 특히 좋았던 이유는 아래와 같았습니다.

    구분 기존 수동 방식 ClusterAPI 방식
    클러스터 생성 문서 따라 수동 실행 YAML 기반 선언형 생성
    확장 노드별 개별 작업 replica 수 조정 중심
    표준화 작업자 숙련도 영향 큼 템플릿 재사용 가능
    변경 이력 위키나 메모 의존 Git 기반 추적 가능
    복구 재현 어려움 동일 매니페스트 재적용 가능

    특히 여러 환경을 동시에 굴릴 때 차이가 컸어요. 개발, 스테이징, 운영이 따로 있으면 사람이 일일이 맞추다가 꼭 어긋나거든요. 반면 CAPI 구축을 해두면 템플릿 하나에서 변수만 바꿔 환경을 복제할 수 있어서 훨씬 안정적이었습니다.

    3. 제가 잡았던 목표와 설계 기준

    이번 ClusterAPI 도입 사례에서 제가 세운 기준은 과하지 않게 명확했어요.

    1. 클러스터 생성 절차를 문서가 아니라 Git 저장소 기준으로 관리할 것
    2. Control Plane(컨트롤 플레인, 클러스터 제어 영역)과 Worker Node(워커 노드, 실제 워크로드 실행 서버) 확장을 분리할 것
    3. 온프레미스 Kubernetes 환경에서도 동일한 템플릿을 재사용할 것
    4. 장애가 나더라도 다시 만들 수 있는 구조를 우선할 것

    여기서 중요한 포인트는 “처음부터 모든 걸 자동화하려고 하지 않는다”는 점이에요. 저도 처음엔 네트워크, 스토리지, 로드밸런서까지 한 번에 묶으려다가 삽질 좀 했습니다 ㅎㅎ 결국 성공한 방식은 클러스터 수명주기부터 먼저 자동화하고, 그 다음에 GitOps와 운영 도구를 붙이는 순서였어요.

    4. CAPI 구축 전 준비: Management Cluster부터 정리

    실전 구현은 예시로 vSphere 기반 온프레미스 환경을 기준으로 설명드릴게요. 다만 구조 자체는 다른 인프라 제공자에도 비슷하게 적용됩니다. 준비 단계에서 필요한 건 대략 이 정도입니다.

    • kubectl(쿠버네티스 CLI), clusterctl(Cluster API CLI)
    • 부트스트랩용 Kubernetes 클러스터 1개
    • vSphere API 접근 정보 또는 사용하는 온프레미스 인프라 자격 정보
    • 템플릿에서 참조할 VM 이미지와 네트워크 정책
    • 로드밸런서 또는 API 서버 엔드포인트 전략

    저는 먼저 management cluster를 아주 작게 올리고, 여기에 Cluster API Controller(컨트롤러, 상태를 맞추는 구성요소)를 설치했어요. 이 관리 클러스터가 있어야 이후 workload cluster를 선언형으로 찍어낼 수 있거든요.

    export CLUSTER_TOPOLOGY=true
export EXP_CLUSTER_RESOURCE_SET=true

clusterctl init --infrastructure vsphere
clusterctl version
kubectl get pods -A

    이 단계에서 pod가 전부 Running 상태로 올라오는지 꼭 확인하셔야 합니다. 컨트롤러가 불안정하면 뒤 단계에서 증상이 꼬여서 원인 파악이 더 어려워져요.

    5. 실전 구현: 온프레미스 Kubernetes 클러스터 자동화 흐름

    이제 본격적으로 CAPI 구축을 진행합니다. 제 경험상 아래 순서가 가장 덜 꼬였습니다.

    1. 클러스터 템플릿 생성
    2. 환경 변수 주입
    3. 매니페스트 검토
    4. 적용 후 상태 확인
    5. 노드 확장 및 업그레이드 테스트
    export VSPHERE_SERVER=vc.example.local
export VSPHERE_USERNAME=svc_clusterapi
export VSPHERE_PASSWORD='change-me'
export VSPHERE_DATACENTER=DC1
export VSPHERE_DATASTORE=datastore01
export VSPHERE_NETWORK=VM_Network
export VSPHERE_RESOURCE_POOL=/DC1/host/Cluster/Resources
export VSPHERE_FOLDER=/DC1/vm/k8s
export VSPHERE_TEMPLATE=ubuntu-k8s-template
export KUBERNETES_VERSION=v1.29.0
export CONTROL_PLANE_MACHINE_COUNT=3
export WORKER_MACHINE_COUNT=3
export CLUSTER_NAME=onprem-prod-01

clusterctl generate cluster ${CLUSTER_NAME} \
  --kubernetes-version ${KUBERNETES_VERSION} \
  --control-plane-machine-count=${CONTROL_PLANE_MACHINE_COUNT} \
  --worker-machine-count=${WORKER_MACHINE_COUNT} \
  > ${CLUSTER_NAME}.yaml

    생성된 YAML은 바로 적용하지 말고 한 번 읽어보시는 걸 권장합니다. 처음엔 귀찮아 보여도, 여기서 네트워크 이름이나 템플릿 참조가 틀린 걸 많이 잡더라고요.

    ClusterAPI 도입 사례의 템플릿 생성과 컨트롤러 배포 흐름 이미지

    clusterctl로 템플릿을 생성하고, management cluster에서 이를 해석해 workload cluster를 만드는 흐름을 설명하는 이미지입니다.

    apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: onprem-prod-01
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.0.0/16
    services:
      cidrBlocks:
        - 10.96.0.0/12
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: onprem-prod-01-control-plane
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: VSphereCluster
    name: onprem-prod-01
    kubectl apply -f onprem-prod-01.yaml
kubectl get cluster
kubectl get machines
kubectl get kubeadmcontrolplane
kubectl describe cluster onprem-prod-01

    여기서 진짜 편한 점이 나와요. 워커 노드 늘릴 때도 별도 설치 문서가 아니라 replica 값을 조정하는 식으로 접근하게 되거든요. 사람이 SSH 들어가서 하나씩 붙이는 방식에서 벗어나는 거죠.

    apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: onprem-prod-01-md-0
spec:
  replicas: 5

    이런 식으로 선언 상태를 바꾸면 컨트롤러가 맞춰 줘요. 실제로 써보니까 운영자가 해야 할 일이 “절차 수행”에서 “원하는 상태 정의”로 바뀌더라고요.

    6. ⚠️ 트러블슈팅: 제가 실제로 막혔던 지점들

    자동화라고 해서 처음부터 매끈하진 않았어요. 오히려 수동 설치보다 어디서 실패했는지 감이 안 잡혀서 더 답답할 때도 있었죠. 특히 아래 세 가지는 자주 만났습니다.

    6-1. VM은 생성됐는데 Kubernetes 노드로 안 붙는 문제

    이건 대부분 템플릿 이미지 문제였어요. cloud-init(클라우드 이닛, 초기 설정 자동화) 또는 kubeadm bootstrap 과정이 템플릿과 안 맞는 경우가 있더라고요. 저는 골든 이미지 재생성 후 해결했습니다.

    kubectl get kubeadmconfigs
kubectl describe machine <machine-name>
kubectl logs -n capv-system deployment/capv-controller-manager

    6-2. API 엔드포인트는 열렸는데 Control Plane이 Ready로 안 가는 문제

    로드밸런서 health check 조건과 kube-apiserver 준비 상태가 안 맞으면 이런 현상이 생겨요. 겉으로는 포트가 열려 보여도 Cluster API 쪽에서는 준비가 덜 된 걸로 판단할 수 있습니다.

    6-3. 머신 삭제가 느리거나 걸리는 문제

    finalizer(파이널라이저, 정리 작업 보장 메커니즘)와 인프라 자원 정리가 꼬일 때가 있어요. 이때는 무작정 리소스부터 지우지 말고, 어떤 컨트롤러가 막고 있는지 이벤트를 먼저 봐야 합니다.

    • ⚠️ 경고: 수동으로 VM만 먼저 삭제하면 CAPI 상태와 실제 인프라 상태가 어긋날 수 있습니다.
    • 💡 팁: 문제 상황은 이벤트, controller log, Machine 상태를 함께 봐야 빨리 풀려요.
    • 💡 팁: 운영 전 테스트 환경에서 scale-out, scale-in, control plane 교체를 꼭 해보세요.

    저도 처음엔 “왜 선언형인데 선언대로 안 되지?” 싶었는데, 결국 선언형도 기반 인프라와 부트스트랩 준비가 맞아야 돌아가더라고요. 이건 정말 직접 해봐야 감이 와요.

    7. 검증과 결과: 운영 방식이 어떻게 달라졌나

    검증은 단순히 클러스터가 떠 있느냐만 보면 부족합니다. 저는 아래 순서로 확인했어요.

    1. Control Plane 3대가 정상 Ready 상태인지 확인
    2. Worker Node 증설/축소가 선언대로 반영되는지 확인
    3. kubeconfig 추출 후 실제 워크로드 배포 테스트
    4. 클러스터 재생성 시 동일한 결과가 나오는지 확인
    clusterctl get kubeconfig onprem-prod-01 > onprem-prod-01.kubeconfig
export KUBECONFIG=$(pwd)/onprem-prod-01.kubeconfig
kubectl get nodes
kubectl create deployment nginx --image=nginx
kubectl get pods -o wide

    이 검증이 끝나고 나면 체감이 확 와요. 새 환경이 필요할 때 “며칠 잡아야 하나”가 아니라 “템플릿 변수 뭘 바꿔야 하나”로 대화가 바뀌거든요. 이게 제가 느낀 가장 큰 성과였어요. 숫자를 과장할 필요도 없이, 운영 피로도가 확실히 줄었습니다.

    ClusterAPI 도입 사례에서 생성된 온프레미스 Kubernetes 클러스터 검증 결과 이미지

    노드가 Ready 상태로 정렬되고 테스트 워크로드가 배포된 모습을 보여주는 결과 검증 이미지입니다.

    🎉 성과 정리

    • 클러스터 생성 절차가 사람 의존에서 Git 기반 표준 절차로 바뀜
    • 온프레미스 Kubernetes 환경에서도 재현 가능한 배포 흐름 확보
    • 운영팀 간 작업 편차 감소
    • 추후 GitOps, 모니터링, 정책 관리 연계가 쉬워짐

    8. 정리: ClusterAPI 도입 사례에서 배운 점

    이번 ClusterAPI 도입 사례를 통해 제가 가장 크게 배운 건, 자동화의 핵심은 도구보다 기준이라는 점이었어요. Cluster API는 만능 마법봉은 아니지만, 클러스터 생성과 확장을 운영 표준으로 묶는 데는 정말 강력했습니다. 특히 클러스터 자동화를 사람 손이 아니라 선언 상태 중심으로 옮긴다는 점에서, 장기 운영에 큰 차이를 만들더라고요.

    다만 처음부터 모든 걸 얹지는 마세요. Management cluster 안정화, 템플릿 검증, 네트워크 정책 정리, 골든 이미지 검증 순으로 가는 게 좋아요. 저도 처음엔 욕심냤다가 다시 돌아왔거든요. 근데 그렇게 한 바퀴 돌고 나니 구조가 훨씬 단단해졌습니다.

    ClusterAPI 도입 사례의 도입 전후 운영 방식 비교 이미지

    수동 구축과 선언형 자동화의 차이를 한눈에 보여주는 비교 이미지입니다.

    다음 글에서는 ClusterClass(클래스 기반 클러스터 템플릿)와 GitOps를 묶어서 운영 표준화를 더 밀어붙이는 방법도 다뤄볼 예정입니다. 이전 글에서 정리한 kubeadm 기반 수동 설치 방식과 비교해서 보시면 왜 CAPI 구축이 가치 있는지 더 선명하게 보이실 겁니다.

    FAQ. ClusterAPI 도입 시 자주 묻는 질문

    Q1. 작은 팀도 Cluster API가 필요할까요?

    클러스터 수가 1개뿐이면 당장 절실하지 않을 수 있어요. 다만 환경이 늘어날 계획이 있거나 표준화가 필요하다면 일찍 검토할 가치가 있습니다.

    Q2. 베어메탈에서도 가능한가요?

    가능합니다. 다만 사용하는 인프라 제공자와 네트워크 자동화 수준에 따라 난이도가 확 달라져요. 그래서 처음엔 가상화 환경에서 개념을 먼저 익히는 걸 추천드립니다.

    Q3. 업그레이드도 선언형으로 할 수 있나요?

    네, Kubernetes 버전과 관련 리소스 정의를 통해 관리하는 방식이 일반적이에요. 다만 운영 적용 전에는 테스트 클러스터에서 롤링 동작을 꼭 검증해 보셔야 합니다.

    ✅ 한 줄 정리: 온프레미스 Kubernetes를 반복해서 만들고 운영해야 한다면, Cluster API는 복잡함을 늘리는 도구가 아니라 반복 작업을 구조화하는 도구예요.

  • [k8s] Karpenter로 EKS 비용 절감: 실전 운영 사례와 최적화 전략

    [k8s] Karpenter로 EKS 비용 절감: 실전 운영 사례와 최적화 전략

    목차

    [인프라] Karpenter 비용 절감: EKS 중심 운영 사례와 AKS 적용 포인트

    Karpenter 비용 절감 이야기는 요즘 EKS 운영하시는 분들이라면 한 번쯤은 꼭 부딪히는 주제입니다. 저도 처음엔 단순히 노드 수만 줄이면 되겠지 싶었는데, 실제로 써보니까 그렇게 단순한 문제가 아니더라고요. 특히 트래픽이 출렁이는 서비스에서는 오토스케일링 비용이 눈에 잘 안 띄게 새고 있었습니다. 월말 청구서를 보고 나서야 “아, 이거 손봐야겠네요” 싶었던 적이 꽤 있었거든요.

    먼저 중요한 점부터 짚고 갈게요. Karpenter는 AWS EKS 환경에서 실제 많이 쓰이는 오픈소스 노드 프로비저닝(Node Provisioning) 도구입니다. 반면 AKS에서는 보통 Cluster Autoscaler(클러스터 오토스케일러)나 노드풀 전략으로 비슷한 비용 최적화를 접근합니다. 그래서 이 글은 제가 직접 많이 다뤄본 EKS + Karpenter 운영 사례를 중심으로 설명하고, 마지막에 AKS 비용 최적화에 어떻게 같은 원칙을 가져갈 수 있는지 연결해서 정리해보겠습니다.

    Karpenter 비용 절감 구조를 보여주는 EKS 전체 아키텍처 다이어그램

    이미지 설명: EKS 환경에서 Karpenter가 스케줄링 수요를 보고 노드를 빠르게 생성하고, 유휴 노드를 정리하는 흐름을 한눈에 보여주는 아키텍처입니다.

    Karpenter 최적화가 왜 비용 절감으로 바로 이어질까요?

    쉽게 말해 Karpenter는 “필요한 순간에 필요한 크기의 노드를 빠르게 붙여주는 사람”입니다. 기존 Cluster Autoscaler(클러스터 오토스케일러)는 이미 만들어둔 노드 그룹(Node Group) 안에서 증감을 고민하는 느낌이 강한데요, Karpenter는 좀 더 유연하게 인스턴스 타입(Instance Type) 선택 폭을 가져갈 수 있는 게 장점입니다.

    실제로 운영해보면 비용이 새는 지점은 대체로 비슷합니다.

    • 과하게 큰 인스턴스를 기본값처럼 쓰는 경우
    • 야간이나 비업무 시간에도 노드가 그대로 살아 있는 경우
    • Pod requests/limits 설정이 보수적으로 너무 큰 경우
    • 온디맨드(On-Demand)만 고집해서 Spot(스팟) 기회를 놓치는 경우
    • DaemonSet(데몬셋)과 시스템 파드 때문에 작은 노드가 비효율적으로 배치되는 경우

    이건 꽤 중요한데요. Karpenter 비용 절감은 단순히 “노드를 줄인다”가 아니라, 워크로드에 맞는 노드를 더 잘 고른다에 가깝습니다. 저도 처음엔 이 차이를 잘 몰라서 인스턴스 수만 보고 있었는데, 결국 핵심은 빈 시간, 빈 공간, 잘못 잡은 요청치(requests)를 줄이는 쪽이더라고요.

    EKS 비용을 줄이는 Karpenter 핵심 개념

    1. Provisioner 대신 최신 문서 기준 NodePool/EC2NodeClass 흐름 이해하기

    Karpenter는 버전이 올라가면서 리소스 모델이 바뀐 적이 있습니다. 운영 중인 버전에 따라 리소스 이름이 다를 수 있는데, 실무에서는 현재 사용 중인 차트와 CRD(Custom Resource Definition) 버전을 먼저 확인하시는 게 중요합니다. 저도 예전 예제만 보고 적용했다가 CRD mismatch(정의 불일치)로 삽질 좀 했습니다 ㅎㅎ

    2. Consolidation(통합)과 Expiration(만료) 전략

    이 기능이 꽤 큽니다. 유휴 노드가 생기면 더 적은 수의 노드로 재배치하고 남는 노드를 정리하는 식인데요. 이걸 켜두지 않으면 Karpenter를 써도 생각보다 절감폭이 안 나옵니다.

    3. 다양한 인스턴스 타입 허용

    특정 타입 하나만 고정하면 스케줄링도 경직되고 단가 최적화도 어렵습니다. 저는 CPU 아키텍처, 세대, 크기 범위를 조금 넓게 허용했을 때 훨씬 안정적이었습니다. 물론 워크로드가 특정 아키텍처에 종속되지 않는지 확인은 먼저 해야 합니다.

    4. Spot과 On-Demand 혼합

    상태 비저장(Stateless) 워크로드는 Spot을 적극 검토할 만합니다. 다만 모든 걸 Spot으로 몰면 중단(interruption)에 취약해지니, 핵심 서비스는 On-Demand 기반으로 남겨두고 배치나 비핵심 API 계층만 분리하는 식이 현실적입니다.

    항목 기존 고정 노드 그룹 Karpenter 최적화 후
    인스턴스 선택 미리 정한 몇 개 타입 위주 조건 기반으로 유연하게 선택
    유휴 노드 정리 느리거나 보수적 통합 정책으로 적극 정리
    비용 대응력 트래픽 급변 시 비효율 가능 수요 기반 대응이 쉬움
    Spot 활용 노드 그룹 설계에 묶임 워크로드별 분리 전략 수월

    실전 구현: EKS에서 Karpenter 최적화 적용한 흐름

    이제 제가 실제로 자주 쓰는 흐름으로 가보겠습니다. 아래 예시는 개념을 보여주기 위한 형태이고, 계정 구조나 네트워크 설계에 따라 이름과 태그는 바꾸셔야 합니다.

    1. EKS 클러스터 버전과 Karpenter 호환성 확인
    2. IAM 역할과 IRSA(IAM Roles for Service Accounts) 구성
    3. 서브넷/보안그룹 태그 점검
    4. EC2NodeClass와 NodePool 분리 설계
    5. 온디맨드/스팟 워크로드 분리
    6. consolidation 정책 활성화
    7. 요청치(requests) 재조정 후 실제 절감률 측정

    1. Helm(헬름)으로 Karpenter 설치

    helm repo add karpenter https://charts.karpenter.sh
helm repo update

helm upgrade --install karpenter karpenter/karpenter \
  --namespace karpenter \
  --create-namespace \
  --set settings.clusterName=my-eks-cluster \
  --set serviceAccount.create=true

    여기서 많이 놓치는 게 IAM 권한입니다. 컨트롤러는 떠 있는데 실제 인스턴스 생성이 안 되는 경우가 꽤 많거든요. 저는 처음에 “왜 파드만 Pending(대기)이지?” 싶었는데, 알고 보니 IAM 정책 누락이었습니다.

    2. EC2NodeClass 예시

    apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2
  role: KarpenterNodeRole-my-eks-cluster
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-eks-cluster
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-eks-cluster
  tags:
    intent: apps

    서브넷과 보안그룹 태그는 정말 중요합니다. 자동 검색이 안 되면 노드가 안 뜹니다. 로그만 보면 애매하게 보여서 시간을 꽤 잡아먹더라고요.

    3. NodePool 예시

    apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: general
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h
  template:
    spec:
      nodeClassRef:
        name: default
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["m5.large", "m5.xlarge", "m6i.large", "m6i.xlarge"]

    실제로 써보니까 인스턴스 타입을 너무 좁게 잡으면 오히려 스케줄링이 꼬입니다. 반대로 너무 넓히면 운영자가 예상하지 못한 조합이 나올 수 있으니, 워크로드 특성에 맞는 범위를 정하는 게 좋습니다.

    Karpenter 최적화 설정과 온디맨드 스팟 분리를 보여주는 구성도

    이미지 설명: NodePool, EC2NodeClass, IAM, 서브넷 태그가 어떻게 연결되는지와 온디맨드/스팟 분리 구조를 보여주는 구성도입니다.

    4. 스팟 전용 워크로드 분리

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-worker
spec:
  replicas: 3
  selector:
    matchLabels:
      app: batch-worker
  template:
    metadata:
      labels:
        app: batch-worker
    spec:
      nodeSelector:
        karpenter.sh/capacity-type: spot
      containers:
        - name: worker
          image: public.ecr.aws/docker/library/busybox:latest
          command: ["sh", "-c", "sleep 3600"]
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"

    배치성 작업이나 재시도가 쉬운 서비스라면 이런 식으로 분리하는 게 꽤 잘 먹힙니다. 다만 데이터베이스 연결을 오래 붙잡는 작업이나 세션 민감한 서비스는 신중하셔야 합니다.

    ⚠️ Karpenter 운영에서 자주 겪는 문제와 해결법

    이 섹션은 진짜 경험 기반입니다. 문서만 보면 금방 될 것 같은데, 현장에서는 꼭 어딘가에서 막히더라고요.

    1. 파드는 Pending인데 노드가 생성되지 않는 경우

    • IAM 권한 누락 여부 확인
    • 서브넷/보안그룹 discovery 태그 확인
    • NodePool requirements가 너무 빡빡하지 않은지 확인
    • 리전에서 해당 인스턴스 타입 공급이 가능한지 확인

    특히 requirements 조건을 여러 개 겹치면 스케줄링 후보가 거의 사라집니다. 저는 아키텍처, 세대, capacity-type, zone까지 한꺼번에 강하게 제한했다가 노드가 안 뜬 적이 있었습니다.

    2. 절감이 기대보다 안 나오는 경우

    이건 거의 항상 requests 과다 설정이 원인이었습니다. Karpenter는 요청된 리소스를 기준으로 판단하니까, 애플리케이션 팀이 CPU 1core, 메모리 2Gi를 습관적으로 박아둔 상태면 빈 공간이 많아져도 노드를 줄이기 어렵습니다.

    kubectl top pods -A
kubectl get pods -A -o wide
kubectl describe node

    이 명령어로 실제 사용량과 요청치를 같이 보시면 감이 옵니다. 처음엔 귀찮아도 이 작업을 해두면 EKS 비용 줄이는 데 체감 차이가 큽니다.

    3. DaemonSet 때문에 작은 노드가 오히려 손해인 경우

    로깅 에이전트, 모니터링 에이전트, CNI 관련 파드가 노드마다 붙잖아요. 그래서 무조건 작은 노드가 좋은 게 아닙니다. 너무 잘게 쪼개면 시스템 오버헤드가 늘어납니다. 이 부분은 홈랩에서도 실험해봤는데, 작은 노드 여러 개보다 중간 크기 몇 개가 효율적인 구간이 분명히 있더라고요.

    4. Spot interruption 대응 부족

    스팟은 싸지만 공짜는 아닙니다. 중단 알림(interruption notice)을 고려한 설계가 없으면 장애 대응 비용이 더 커질 수 있어요. 오토스케일링 비용만 볼 게 아니라 운영 리스크까지 같이 보셔야 합니다.

    검증: 비용이 실제로 얼마나 줄었는지 어떻게 보나요?

    제가 직접 해보니 “30% 절감” 같은 숫자는 환경에 따라 차이가 큽니다. 다만 공통적으로는 아래 항목을 같이 봐야 의미가 있습니다.

    • 노드 총 가동 시간 감소 여부
    • 평균 노드 활용률 상승 여부
    • 스팟 비중 증가 여부
    • 배포 실패나 재시작 증가 여부
    • 응답 시간과 에러율 변화 여부

    저는 대시보드를 볼 때 단순 인프라 비용만 보지 않고, 서비스 안정성까지 같이 체크합니다. 비용은 줄었는데 장애가 늘면 그건 실패거든요.

    kubectl get node
kubectl get pods -A
kubectl logs -n karpenter deploy/karpenter

    추가로 클라우드 비용 분석 도구에서 노드 사용 추이를 월간으로 비교해보면 좋습니다. 같은 트래픽 수준에서 유휴 시간이 줄고, 피크 시간 확장 속도가 좋아졌다면 방향을 잘 잡은 겁니다.

    Karpenter 비용 절감 결과를 보여주는 노드 사용률 및 비용 대시보드

    이미지 설명: 비용 분석 대시보드에서 최적화 전후 노드 수, 활용률, 유휴 시간 변화를 비교하는 예시입니다.

    AKS 비용 최적화는 어떻게 연결하면 될까요?

    많이들 헷갈리시는데요. AKS 비용 최적화라는 관점은 분명히 중요하지만, 실무적으로는 Karpenter 자체보다 Cluster Autoscaler, 노드풀 분리, Spot VM, 요청치 정리 같은 방식으로 접근하는 게 일반적입니다. 즉, 도구는 달라도 원칙은 거의 같습니다.

    최적화 원칙 EKS AKS
    수요 기반 노드 증감 Karpenter Cluster Autoscaler 중심
    워크로드 분리 NodePool/taint/toleration Node Pool/taint/toleration
    저비용 인스턴스 활용 Spot Spot VM
    리소스 요청 최적화 필수 필수

    그러니까 “EKS는 Karpenter, AKS는 다른 도구”라고 외우기보다, 워크로드를 세분화하고 유휴 자원을 줄이며 저비용 노드를 안전하게 섞는 전략이 핵심이라고 보시면 됩니다. 이 관점으로 보면 클라우드가 달라도 사고방식이 꽤 통일됩니다.

    실무 체크리스트: 제가 마지막에 꼭 보는 항목

    1. requests/limits가 실제 사용량과 크게 어긋나지 않는가
    2. 온디맨드와 스팟 워크로드가 명확히 분리되어 있는가
    3. NodePool 조건이 과도하게 제한적이지 않은가
    4. 유휴 노드 정리 정책이 활성화되어 있는가
    5. 비용 절감 후에도 SLO(Service Level Objective)에 영향이 없는가

    이 체크리스트만 꾸준히 봐도 Karpenter 최적화 방향을 크게 벗어나지 않습니다. 사실 화려한 기능보다 이런 기본기가 더 중요하더라고요.

    EKS 비용과 AKS 비용 최적화 원칙을 비교한 요약 인포그래픽

    이미지 설명: EKS와 AKS 각각에서 적용 가능한 비용 절감 원칙을 비교 정리한 요약 인포그래픽입니다.

    정리와 다음 단계

    정리해보면 이렇습니다. Karpenter 비용 절감은 EKS에서 꽤 강력한 선택지이고, 제대로 설정하면 체감이 분명히 옵니다. 다만 만능은 아닙니다. 요청치가 엉망이거나 워크로드 분리가 안 되어 있으면 기대만큼 안 줄어듭니다. 저도 처음엔 “설치만 하면 끝나는 거 아닌가?” 싶었는데, 실제로는 관찰과 조정이 더 중요했습니다.

    그리고 AKS 쪽은 Karpenter를 억지로 끼워 맞추기보다, 같은 최적화 원칙을 AKS 네이티브 방식으로 적용하는 게 현실적입니다. 이건 꽤 중요한데요. EKS 비용, AKS 비용, 오토스케일링 비용 모두 결국은 워크로드 이해도가 좌우합니다.

    혹시 지금 클러스터 비용이 생각보다 많이 나오고 계신가요? 그렇다면 제일 먼저 requests/limits부터 다시 보세요. 그다음 노드 풀 전략, 그리고 마지막으로 자동화 정책을 손보시면 됩니다. 이전 글에서 다룬 Kubernetes 리소스 요청치 튜닝 내용이 있다면 같이 보시면 도움이 되고, 다음 글에서는 HPA(Horizontal Pod Autoscaler)와 Karpenter를 함께 쓸 때 생기는 상호작용도 정리해볼 예정입니다.

    자주 묻는 질문

    Karpenter만 설치하면 바로 비용이 줄어드나요?

    아닙니다. 요청치 설정, 워크로드 분리, 유휴 노드 정리 정책이 같이 맞아야 효과가 납니다.

    스팟만 많이 쓰면 무조건 유리한가요?

    아닙니다. 중단 가능성이 있어서 서비스 특성에 따라 온디맨드와 섞어야 합니다.

    AKS에도 같은 전략을 적용할 수 있나요?

    네, 가능합니다. 다만 도구는 다를 수 있고, 원칙은 비슷하다고 보시면 됩니다.

  • [k8s] AKS 워크로드 성능 벤치마크: 노드 타입별 최적화 전략

    [k8s] AKS 워크로드 성능 벤치마크: 노드 타입별 최적화 전략

    목차

    [k8s] AKS 워크로드 성능 벤치마크: 노드 타입별 최적화 전략

    AKS 성능 벤치마크를 제대로 해보면, 같은 쿠버네티스(Kubernetes, 컨테이너 오케스트레이션) 클러스터라도 노드 타입 하나 바꿨을 뿐인데 체감이 꽤 달라집니다. 저도 처음엔 “어차피 Pod(파드, 컨테이너 실행 단위)만 잘 나뉘면 되는 거 아닌가?” 싶었거든요. 근데 실제로 운영해보니까 CPU bound(연산 집약형) 워크로드, memory bound(메모리 집약형) 워크로드, burst traffic(순간 트래픽) 대응이 전부 다르게 움직이더라고요. 특히 AKS 노드 타입을 대충 고르면 비용은 비용대로 나가고, 성능은 애매한 상황이 생기는 거 있죠.

    이번 글은 특정 벤치마크 수치를 과장해서 보여주는 글이 아닙니다. 대신 제가 실무와 홈랩에서 클러스터를 굴리면서 정리한 방식대로, 어떻게 AKS 성능 벤치마크를 설계하고, 어떤 워크로드에 어떤 노드 타입을 우선 검토해야 하는지, 그리고 쿠버네티스 워크로드 최적화를 어떤 순서로 접근하면 덜 삽질하는지 정리해보겠습니다. 숫자보다 중요한 건 비교 기준이거든요.

    AKS 성능 벤치마크를 위한 노드 타입별 아키텍처 다이어그램

    AKS 클러스터에서 일반형, 컴퓨트 최적화형, 메모리 최적화형 노드를 분리하고 워크로드를 비교 측정하는 전체 구조 예시입니다.

    왜 AKS 성능 벤치마크가 중요한가

    쉽게 말해, AKS는 관리형 쿠버네티스(Managed Kubernetes)라서 제어 플레인(control plane)은 편해졌지만, 노드 선택 책임까지 사라진 건 아닙니다. 오히려 운영이 쉬워진 만큼 워크로드 특성에 맞는 인프라 설계가 더 중요해졌어요.

    예를 들어 이런 상황 있으셨을 겁니다.

    • 웹 API는 평소엔 한가한데 특정 시간대에 응답 지연(latency, 지연 시간)이 튑니다.
    • 배치 작업(batch job)은 CPU를 많이 먹는데, 일반형 노드에서 오래 끕니다.
    • 캐시나 분석용 애플리케이션은 메모리를 넉넉히 잡아야 하는데 OOMKilled가 납니다.
    • 오토스케일링(autoscaling)이 걸리긴 하는데 생각보다 늦게 반응합니다.

    이럴 때 필요한 게 감으로 고르는 인프라가 아니라, 클라우드 네이티브 벤치마크 방식으로 실제 워크로드를 분류하고 비교하는 작업입니다. 저도 예전엔 노드 스펙만 보고 판단했다가, 정작 병목은 CPU가 아니라 스토리지 I/O 혹은 스케줄링 밀집도(bin packing)였던 적이 꽤 있었어요. 정말 여러 번 삽질했습니다 ㅎㅎ

    AKS 노드 타입을 어떻게 봐야 하나

    Azure K8s 성능을 볼 때는 노드를 단순히 “비싼 게 좋다”로 보면 안 됩니다. AKS 노드 타입은 대체로 다음 관점으로 나눠서 보면 훨씬 판단이 쉬워집니다.

    분류 대표 성격 잘 맞는 워크로드 주의할 점
    General Purpose(범용형) CPU/메모리 균형 일반 웹 서비스, API, 운영도구 특정 자원 한쪽이 치우치면 효율이 애매할 수 있음
    Compute Optimized(컴퓨트 최적화형) vCPU 비중 높음 트랜스코딩, 빌드, 배치, 계산 작업 메모리 요구량이 큰 앱은 오히려 불리할 수 있음
    Memory Optimized(메모리 최적화형) 메모리 비중 높음 캐시, 인메모리 DB, JVM 계열 앱 CPU 대비 비용 효율을 따로 봐야 함
    GPU/특수형 가속기 탑재 AI/ML, 병렬 연산 일반 서비스에는 과한 경우가 많음

    실무에서는 Azure VM 계열로 풀어보면 범용형은 D 시리즈, 컴퓨트 최적화형은 F 시리즈, 메모리 최적화형은 E 시리즈를 먼저 비교하는 경우가 많습니다. 물론 세부 세대와 로컬 디스크 유무, 네트워크 성능, 가용 영역 배치까지 들어가면 이야기가 더 길어지지만, 첫 AKS 성능 벤치마크는 너무 복잡하게 시작하지 않는 게 좋습니다.

    여기서 중요한 포인트! 벤치마크의 목적은 “최고 성능 머신 찾기”가 아니라, 내 워크로드에 가장 안정적으로 맞는 조합 찾기입니다.

    벤치마크 전에 먼저 정해야 할 기준

    AKS 성능 벤치마크를 시작하기 전에 저는 보통 아래 네 가지부터 적어둡니다.

    1. 측정 대상: API 서버인지, 배치 잡인지, 스트리밍 처리인지 구분합니다.
    2. 핵심 지표: 처리량(throughput), 응답 지연(latency), 재시작 횟수, CPU throttling 여부를 봅니다.
    3. 비교 조건: 동일한 리전(region), 동일한 애플리케이션 이미지, 동일한 requests/limits로 맞춥니다.
    4. 종료 조건: 어느 지점에서 “이 노드는 부적합”이라고 판단할지 기준을 세웁니다.

    이걸 안 정하면 나중에 그래프는 많은데 결론이 없어요. 저도 처음엔 대시보드만 잔뜩 띄워놓고 뿌듯했는데, 정작 뭘 비교한 건지 흐려져서 다시 했던 기억이 납니다.

    실전 구현: AKS 벤치마크용 클러스터와 워크로드 준비

    이제 실제로 해보겠습니다. 여기서는 가장 이해하기 쉬운 방식으로, 노드 풀(node pool, 용도별 노드 그룹)을 분리하고 동일 워크로드를 각각에 붙여 비교하는 흐름으로 가보겠습니다.

    1. AKS 클러스터와 기본 노드 풀 생성

    RESOURCE_GROUP="rg-aks-bench"
CLUSTER_NAME="aks-bench-lab"
LOCATION="koreacentral"

az group create \
  --name $RESOURCE_GROUP \
  --location $LOCATION

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --node-count 1 \
  --enable-managed-identity \
  --generate-ssh-keys

az aks get-credentials \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME

    처음부터 노드를 많이 올리기보다, 기본 클러스터를 만들고 나중에 목적별 node pool을 추가하는 게 관리가 편합니다.

    2. 용도별 AKS 노드 타입 추가

    az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name gp \
  --node-count 1 \
  --node-vm-size Standard_D4s_v5

az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name cpu \
  --node-count 1 \
  --node-vm-size Standard_F4s_v2

az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name mem \
  --node-count 1 \
  --node-vm-size Standard_E4s_v5

    예시는 범용형, 컴퓨트 최적화형, 메모리 최적화형을 나눈 것입니다. 실제 운영에서는 가용성, 예산, 리전 지원 여부를 같이 봐야 합니다.

    AKS 노드 타입에 따라 워크로드를 분리 배치하는 구성도

    서로 다른 AKS 노드 풀에 동일한 애플리케이션을 배치하고, nodeSelector로 대상을 분리하는 흐름을 보여주는 구성도입니다.

    3. 테스트용 애플리케이션 배포

    여기서는 가장 단순한 웹 애플리케이션 예시로 갑니다. 핵심은 애플리케이션 자체가 아니라 동일 조건으로 여러 노드 타입에 붙여 비교하는 것입니다.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: bench-web-gp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: bench-web-gp
  template:
    metadata:
      labels:
        app: bench-web-gp
    spec:
      nodeSelector:
        agentpool: gp
      containers:
      - name: web
        image: nginx:stable
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: bench-web-gp
spec:
  selector:
    app: bench-web-gp
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

    이 YAML은 `gp`, `cpu`, `mem` 용으로 이름과 `nodeSelector`만 바꿔서 각각 하나씩 배포하면 됩니다. 실제로 해보니까 여기서 가장 많이 틀리는 게 라벨명이더라고요. AKS 노드 풀 라벨은 환경에 따라 꼭 확인해보는 게 안전합니다.

    4. 리소스 사용량과 이벤트 확인

    kubectl get nodes --show-labels
kubectl get pods -o wide
kubectl top nodes
kubectl top pods
kubectl describe pod <pod-name>

    이 단계에서 확인할 건 세 가지입니다.

    • Pod가 의도한 node pool에 올라갔는지
    • CPU throttling 징후가 있는지
    • 메모리 압박이나 재시작이 있는지

    5. 부하 테스트 실행

    HTTP 워크로드라면 외부 부하 도구를 붙여도 되고, 간단히 클러스터 내부에서 반복 요청을 보내도 됩니다.

    kubectl run loadtest --rm -it \
  --image=busybox \
  --restart=Never -- /bin/sh

while true; do
  wget -q -O- http://bench-web-gp; 
  sleep 0.2;
done

    물론 이건 아주 가벼운 예시입니다. 실제 AKS 성능 벤치마크라면 동시성(concurrency), 지속 시간(duration), 오류율(error rate)을 더 정교하게 잡아야 합니다. 그래도 첫 비교는 이렇게 작게 시작하는 게 좋습니다. 처음부터 너무 큰 도구를 붙이면 원인 분석이 더 어려워지거든요.

    쿠버네티스 워크로드 최적화에서 놓치기 쉬운 포인트

    노드 타입만 바꾸면 끝일 것 같지만, 실은 워크로드 정의가 더 중요할 때가 많습니다.

    체크 항목 왜 중요한가 실무 팁
    requests/limits 스케줄링과 throttling에 직접 영향 너무 보수적으로 잡으면 밀집도가 떨어집니다
    HPA 트래픽 대응 자동화 CPU만 보지 말고 메모리나 커스텀 메트릭도 검토합니다
    Pod 분산 장애 도메인 분리 anti-affinity와 topology spread를 함께 봅니다
    스토리지 특성 상태 저장 앱의 체감 성능 좌우 디스크 병목이면 노드 변경 효과가 작을 수 있습니다

    예를 들어 CPU가 부족한 줄 알고 컴퓨트 최적화 노드로 옮겼는데, 알고 보니 컨테이너 `limits`가 너무 타이트해서 throttling만 심했던 경우도 있습니다. 저도 이거 한 번 당하고 나서는, 무조건 애플리케이션 정의와 노드 타입을 같이 봅니다.

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

    여기서는 제가 자주 봤던 문제를 정리해볼게요.

    1. Pod가 원하는 노드에 안 올라가는 문제

    대부분 `nodeSelector`, `taint/toleration`, 리소스 부족 셋 중 하나입니다.

    kubectl describe pod <pod-name>

    `Events`를 보면 대개 이유가 나옵니다. 처음엔 저도 스케줄러가 이상한 줄 알았는데, 실제로는 라벨 오타가 제일 흔했어요.

    2. 벤치마크 결과가 들쭉날쭉한 문제

    이건 생각보다 흔합니다. 원인은 보통 아래 쪽입니다.

    • 테스트 시간대가 다름
    • 이미지 풀(image pull) 시간이 섞임
    • 오토스케일링 반응 시간이 포함됨
    • 클러스터 내부의 다른 작업이 간섭함

    그래서 저는 AKS 성능 벤치마크할 때 최소한 워밍업 구간과 실측 구간을 분리합니다. 이거 안 하면 첫 요청 지연이 평균값을 망치더라고요.

    3. 메모리 최적화 노드인데 성능 향상이 애매한 문제

    메모리를 많이 준다고 모든 앱이 빨라지진 않습니다. 애플리케이션이 실제로 heap(힙), cache(캐시), page cache를 활용하는 구조인지 봐야 합니다. 단순한 stateless API라면 메모리보다 CPU 클럭이나 네트워크 특성이 더 체감될 때가 많습니다.

    4. 비용은 늘었는데 개선 폭이 작은 문제

    이건 가장 뼈아픈 케이스죠. 그래서 AKS 성능 벤치마크 결과는 반드시 성능/비용 관점으로 같이 봐야 합니다. 절대 성능만 보고 결정하면 운영비가 금방 불어나니까요.

    AKS 성능 벤치마크 결과를 시각화한 대시보드 이미지

    CPU 사용률, 메모리 사용량, Pod 재시작, 응답 지연을 한 화면에서 비교하는 벤치마크 대시보드 예시입니다.

    검증: 어떤 결과를 보면 의미 있는가

    결과 검증은 단순 평균보다 분포를 보는 게 좋습니다. 특히 웹 서비스는 p95 latency(p95 지연 시간), 오류율, 재시작 여부가 중요합니다.

    1. 범용형 노드에서 안정적이지만 피크 구간에서 지연이 튀는지 봅니다.
    2. 컴퓨트 최적화형에서 CPU 사용률은 낮아졌는지, 처리량은 늘었는지 봅니다.
    3. 메모리 최적화형에서 OOMKilled가 줄고 캐시 적중 효과가 있는지 확인합니다.
    4. 같은 성능을 더 적은 노드 수로 낼 수 있는지도 함께 봅니다.

    제가 직접 해보니, 정답이 하나로 고정되기보다 워크로드 특성에 따라 꽤 명확하게 갈리더라고요.

    • 일반 웹/API는 범용형에서 시작해도 충분한 경우가 많습니다.
    • 빌드, 계산, 배치성 작업은 컴퓨트 최적화형이 먼저 후보가 됩니다.
    • 캐시, JVM, 데이터 집약형 앱은 메모리 최적화형 검토 우선순위가 올라갑니다.

    결론적으로 Azure K8s 성능은 노드 스펙 하나가 아니라, 워크로드 패턴과 리소스 설정, 스케일 전략의 합으로 결정됩니다.

    정리: AKS 노드 타입 선택 전략

    마지막으로 실무에서 바로 써먹기 좋은 방식으로 정리해보겠습니다.

    1. 기준 워크로드를 하나 정합니다. 가장 중요한 서비스부터입니다.
    2. 범용형 node pool을 기준선으로 삼습니다.
    3. 같은 앱을 컴퓨트 최적화형, 메모리 최적화형에 각각 배치합니다.
    4. `requests/limits`, HPA, 분산 정책을 동일하게 맞춥니다.
    5. 처리량, p95 지연, 재시작, 비용 관점을 같이 봅니다.
    6. 결과가 좋으면 그때 운영 표준으로 가져갑니다.

    이 순서대로 하면 적어도 “왜 느린지 모르겠는데 일단 큰 VM으로 바꾸자” 같은 결정을 줄일 수 있습니다. 사실 저도 예전엔 그렇게 했었는데요, 나중에 보면 대부분 비효율이었어요.

    혹시 지금 AKS에서 특정 워크로드가 계속 애매하게 느리다면, 이번엔 감으로 바꾸지 말고 AKS 성능 벤치마크 기준부터 잡아보세요. 그 다음에야 AKS 노드 타입 선택이 훨씬 쉬워집니다. 다음 글에서는 Cluster Autoscaler(클러스터 오토스케일러)와 HPA를 같이 묶어서, 실제 트래픽 변동 환경에서 어떻게 튜닝하는지 이어서 다뤄보겠습니다. 이전 글에서 다뤘던 Ingress(인그레스, 외부 트래픽 진입점) 최적화 내용과 연결해서 보셔도 흐름이 잘 이어질 겁니다.

    AKS 노드 타입 선택 기준과 최적화 전략 요약 인포그래픽

    범용형, 컴퓨트 최적화형, 메모리 최적화형 노드의 추천 워크로드와 판단 기준을 한눈에 요약한 인포그래픽입니다.

    FAQ: 자주 묻는 질문

    AKS 성능 벤치마크는 운영 환경에서 바로 해야 하나요?

    가능하면 운영과 유사한 별도 환경에서 먼저 하시는 걸 권합니다. 운영에서 바로 하면 다른 변수 때문에 결과 해석이 어려워져요.

    노드 타입만 바꾸면 성능 문제가 해결되나요?

    아닙니다. `requests/limits`, 애플리케이션 구조, 스토리지, 네트워크까지 같이 봐야 합니다.

    처음 시작할 때 가장 무난한 방법은 뭔가요?

    범용형을 기준선으로 잡고, CPU 중심 워크로드와 메모리 중심 워크로드를 분리해 비교해보는 게 가장 안전합니다.

  • [Kubernetes] ConfigMap 운영 중 흔히 겪는 문제와 해결 전략

    [Kubernetes] ConfigMap 운영 중 흔히 겪는 문제와 해결 전략

    목차

    [Kubernetes] ConfigMap 운영 중 흔히 겪는 문제와 해결 전략

    Kubernetes ConfigMap 문제 해결은 운영하다 보면 한 번쯤 꼭 붙잡게 되는 주제예요. 배포는 멀쩡히 끝났는데 환경 변수는 안 바뀌어 있고, YAML은 분명 맞는 것 같은데 애플리케이션이 예전 설정으로 뜨는 경우가 정말 많더라고요. 저도 처음엔 이게 뭔가 싶었거든요. 특히 홈랩에서 여러 서비스를 굴리면서 ConfigMap(컨피그맵, 설정 데이터를 담는 리소스)과 Secret(시크릿, 민감 정보 저장 리소스)을 섞어 쓰다 보니 어디서 꼬였는지 찾는 데 정말 시간이 걸렸어요. 이번 글에서는 제가 실제로 자주 봤던 ConfigMap 업데이트 이슈, 환경 변수 미적용 문제, 설정 오류 디버깅 흐름을 기준으로 정리해보겠습니다.

    핵심만 먼저 말씀드리면 이렇습니다. ConfigMap이 바뀌었다고 해서 모든 Pod(파드, 컨테이너 실행 단위)가 자동으로 기대한 방식으로 반영되지는 않습니다. 값을 어떤 방식으로 주입했는지에 따라 반영 방식이 다르고, 애플리케이션이 설정 재로딩(reload, 설정 다시 읽기)을 지원하는지도 함께 봐야 하거든요. 여기서 중요한 포인트! Kubernetes 자체 문제처럼 보여도 실제 원인은 애플리케이션 기동 방식이나 Deployment(디플로이먼트, 배포 리소스) 선언에 있는 경우가 정말 많아요.

    ConfigMap이 Pod에 주입되는 경로와, 업데이트 후 반영 지점을 한눈에 보여주는 개요 다이어그램입니다.

    1. 왜 ConfigMap 문제가 자주 생길까

    쉽게 말해 ConfigMap은 애플리케이션 이미지와 설정을 분리하려고 쓰는 도구예요. 이미지 자체를 다시 빌드하지 않고도 환경별 설정을 바꿀 수 있으니 정말 편하죠. 그런데 편한 만큼 함정도 있어요.

    • 환경 변수(env)로 주입했는지, 파일(volume)로 마운트했는지에 따라 동작이 달라집니다.
    • 애플리케이션이 시작할 때만 설정을 읽는지, 실행 중 재로딩을 지원하는지 다릅니다.
    • YAML 들여쓰기나 키 이름 오타처럼 아주 사소한 실수도 바로 장애로 이어져요.
    • 운영 중에는 여러 팀이 같은 설정을 만지다 보니 변경 이력 추적도 중요해집니다.

    실제로 써보니까 ConfigMap은 단순한 설정 저장소가 아니라, 배포 전략과 디버깅 방식까지 같이 설계해야 하는 운영 요소였어요. 처음에는 그냥 값만 넣으면 끝인 줄 알았는데, 나중에 보니 반영 타이밍 때문에 삽질 좀 했습니다 ㅎㅎ

    2. ConfigMap 개념 설명: 어디에 쓰는가

    ConfigMap은 문자열 기반 설정 데이터를 Kubernetes 클러스터 안에서 관리하기 위한 리소스예요. 보통 다음 두 가지 방식으로 많이 써요.

    주입 방식 설명 운영 시 주의점
    환경 변수(Environment Variables) 컨테이너 시작 시 값을 환경 변수로 주입 대체로 Pod 재시작 없이는 값 변경 체감이 어려워요
    볼륨 마운트(Volume Mount) ConfigMap 내용을 파일 형태로 컨테이너 내부에 제공 파일이 갱신돼도 애플리케이션이 재로딩하지 않으면 반영이 안 될 수 있어요

    여기서 많이 헷갈리는 부분이 있어요. ConfigMap 업데이트와 애플리케이션 설정 반영은 같은 일이 아닙니다. Kubernetes 입장에서는 데이터를 바꿨을 뿐이고, 그걸 애플리케이션이 언제 다시 읽을지는 별개의 문제거든요. 저도 처음엔 kubectl로 ConfigMap만 바꿔놓고 왜 서비스 동작이 그대로인지 한참 봤었어요.

    자주 쓰는 예시 ConfigMap

    apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"
  app.properties: |
    server.port=8080
    feature.toggle=true

    위 예시처럼 간단한 key-value도 넣을 수 있고, 설정 파일 전체를 문자열로 넣을 수도 있어요. 운영에서는 둘 다 많이 써요.

    3. 실전 구현: ConfigMap 생성과 Pod 연결

    이제 실전으로 가봅시다. Kubernetes ConfigMap 문제 해결의 시작은 항상 현재 어떤 방식으로 연결되어 있는지 확인하는 것이에요. 환경 변수인지, 파일 마운트인지, 둘 다인지 먼저 봐야 한다는 뜻입니다.

    3-1. ConfigMap 생성

    kubectl create configmap app-config \
  --from-literal=APP_MODE=production \
  --from-literal=LOG_LEVEL=info

    또는 선언형으로 관리하려면 YAML 파일을 두고 적용하는 방식이 더 좋아요. GitOps(깃옵스, Git 기반 운영) 흐름에도 잘 맞고요.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"

    kubectl apply -f configmap.yaml

    3-2. 환경 변수로 주입

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: app
          image: nginx
          env:
            - name: APP_MODE
              valueFrom:
                configMapKeyRef:
                  name: app-config
                  key: APP_MODE
            - name: LOG_LEVEL
              valueFrom:
                configMapKeyRef:
                  name: app-config
                  key: LOG_LEVEL

    이 방식은 선언이 명확해서 좋아요. 다만 환경 변수 미적용 이슈가 가장 자주 보이는 방식이기도 합니다. 왜냐하면 컨테이너는 보통 시작할 때 환경 변수를 읽고 끝이거든요.

    3-3. 파일로 마운트

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app-file
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app-file
  template:
    metadata:
      labels:
        app: demo-app-file
    spec:
      containers:
        - name: app
          image: nginx
          volumeMounts:
            - name: config-volume
              mountPath: /etc/app-config
      volumes:
        - name: config-volume
          configMap:
            name: app-config

    파일 마운트 방식은 애플리케이션이 파일 변경을 감지하거나 재시작 시 다시 읽는 구조일 때 특히 유용해요. 근데 여기서도 안심하면 안 돼요. 애플리케이션이 그 파일을 다시 안 읽으면 소용이 없거든요.

    Kubernetes ConfigMap 업데이트 방식 비교 이미지

    Deployment에서 ConfigMap을 환경 변수와 볼륨으로 주입하는 구성을 비교하는 다이어그램입니다.

    4. ConfigMap 업데이트 시 가장 많이 터지는 문제

    이 섹션은 제가 운영하면서 가장 많이 봤던 증상들 위주로 적어볼게요. 혹시 이런 경험 있으신가요? 분명 ConfigMap은 바뀌었는데 서비스가 그대로인 상황 말이에요. 대부분 아래 범주 안에 들어가요.

    4-1. ConfigMap 업데이트 후 환경 변수 미적용

    가장 흔한 증상이에요. 원인은 단순한 편입니다. 환경 변수는 보통 컨테이너 시작 시점에 주입되기 때문이에요. 그래서 ConfigMap만 바꿔서는 이미 떠 있는 Pod 내부 환경 변수가 즉시 바뀌지 않아요.

    제가 직접 해보니 여기서 중요한 건 Kubernetes가 아니라 주입 방식이었어요. 해결은 보통 다음 중 하나입니다.

    1. Deployment를 다시 롤아웃해서 새 Pod를 띄웁니다.
    2. 설정 변경 시점에 맞춰 배포 파이프라인에서 재시작 절차를 함께 실행해요.
    3. 가능하면 파일 기반 설정 + 애플리케이션 재로딩 구조를 검토해야 해요.
    kubectl rollout restart deployment demo-app
kubectl rollout status deployment demo-app

    4-2. 볼륨 파일은 바뀌었는데 애플리케이션 동작은 그대로

    이 경우는 더 헷갈려요. 컨테이너 안 파일을 열어보면 값이 바뀐 것 같은데, 서비스는 예전 설정대로 동작하거든요. 원인은 대개 애플리케이션이 시작할 때만 파일을 읽고 메모리에 들고 있기 때문이에요.

    이럴 때는 아래를 점검해야 해요.

    • 애플리케이션이 SIGHUP 같은 재로딩 신호를 받는지
    • 파일 변경 감지(watch)를 지원하는지
    • 설정 파일 경로가 실제 읽는 경로와 같은지
    • 서브패스(subPath) 사용 여부

    특히 subPath로 마운트한 파일은 기대한 방식의 갱신이 안 보이는 사례가 있어서 운영 시 더 조심하게 되더라고요. 저도 예전에 특정 설정 파일 하나만 예쁘게 꽂으려고 subPath를 썼다가, 왜 변경 반영이 안 되지 하고 한참 봤었어요.

    4-3. 키 이름 오타, 네임스페이스 착오

    은근히 자주 나와요. ConfigMap 이름은 맞는데 key가 다르거나, 적용한 namespace(네임스페이스, 리소스 격리 단위)가 달라서 Pod가 다른 리소스를 보고 있는 경우죠.

    kubectl get configmap app-config -n default -o yaml
kubectl get deployment demo-app -n default -o yaml
kubectl describe pod <pod-name> -n default

    이 세 가지를 같이 보면 생각보다 금방 풀려요. 저는 디버깅할 때 항상 ConfigMap 원본, Deployment 참조, 실제 Pod 상태를 한 세트로 봐요.

    5. 설정 오류 디버깅: 제가 실제로 보는 순서

    문제가 터졌을 때는 감으로 보면 더 꼬여요. 순서를 정해두는 게 좋습니다. 저는 아래 흐름으로 봐요.

    1. ConfigMap 값 확인
      kubectl get configmap으로 현재 값이 정말 바뀌었는지 확인합니다.
    2. Deployment 선언 확인
      env, envFrom, volumeMounts, volumes가 예상대로 연결됐는지 봐요.
    3. Pod 재생성 여부 확인
      환경 변수 방식이라면 새 Pod가 떴는지 확인합니다.
    4. 컨테이너 내부 확인
      printenv, cat 등으로 실제 반영 상태를 확인해요.
    5. 애플리케이션 로그 확인
      설정 파싱 오류나 fallback 값 사용 흔적이 없는지 봅니다.
    kubectl get configmap app-config -o yaml
kubectl get deployment demo-app -o yaml
kubectl get pods -l app=demo-app
kubectl exec -it <pod-name> -- printenv | grep APP_MODE
kubectl exec -it <pod-name> -- sh -c 'cat /etc/app-config/app.properties'
kubectl logs <pod-name>

    여기서 중요한 포인트! 컨테이너 내부 확인 없이 추측으로 넘어가면 시간만 더 써요. 실제로 써보니까 운영 이슈는 눈으로 확인하는 게 제일 빠르더라고요.

    Kubernetes ConfigMap 문제 해결을 위한 설정 오류 디버깅 이미지

    kubectl 명령으로 ConfigMap 값, Pod 환경 변수, 마운트 파일을 순서대로 점검하는 디버깅 흐름 이미지입니다.

    6. 운영에서 쓰는 해결 전략 정리

    단순히 문제를 푸는 것보다, 다시 안 터지게 만드는 게 더 중요해요. 제가 지금은 아래 전략을 기본으로 가져가고 있습니다.

    상황 권장 전략 이유
    환경 변수 기반 설정 변경 후 롤아웃 재시작 절차 포함 Pod 재기동이 반영 경로가 되기 쉬워요
    파일 기반 설정 애플리케이션 재로딩 지원 여부 확인 파일 변경과 동작 반영은 별개예요
    설정 변경 잦음 선언형 관리와 변경 이력 추적 누가 무엇을 바꿨는지 파악하기 쉬워요
    장애 대응 검증 명령어를 런북(runbook, 운영 절차서)화 야간 대응 속도가 크게 향상돼요
    • ConfigMap 이름에 버전성 힌트를 두는 방식도 운영에 따라 정말 유용해요.
    • Deployment annotation 변경으로 롤링 업데이트를 유도하는 패턴도 자주 써요.
    • 애플리케이션 기본값(fallback) 존재 여부를 꼭 확인해야 해요. 설정이 안 먹었는데도 앱이 떠버리면 더 위험하거든요.
    • Secret과 ConfigMap 역할 분리도 중요해요. 민감 정보는 ConfigMap에 넣지 않는 게 기본입니다.

    그리고 k8s 설정 관리는 결국 사람 문제이기도 해요. 파일명, 키 네이밍, 네임스페이스 규칙을 팀 단위로 맞추지 않으면 나중에 디버깅 비용이 훨씬 커져요.

    7. 검증과 결과 확인: 바뀐 설정이 정말 적용됐는지

    배포가 끝났다고 끝난 게 아니에요. 저는 항상 아래 세 가지를 같이 봐요.

    1. 리소스 기준 검증: ConfigMap과 Deployment 선언 확인
    2. 컨테이너 기준 검증: 환경 변수 또는 파일 내용 확인
    3. 애플리케이션 기준 검증: 로그, 헬스체크, 실제 동작 확인
    kubectl rollout status deployment demo-app
kubectl exec -it <pod-name> -- printenv | grep LOG_LEVEL
kubectl exec -it <pod-name> -- sh -c 'ls -l /etc/app-config && cat /etc/app-config/app.properties'
kubectl logs <pod-name>

    여기서 드디어 됐다! 하는 순간이 와요. 그런데 한 단계 더 가야 해요. 애플리케이션이 실제로 새 설정으로 동작하는지 확인해야 하거든요. 예를 들어 로그 레벨이 바뀌었는지, 특정 기능 토글이 반영됐는지, 외부 연결 정보가 새 값으로 적용됐는지까지 봐야 진짜 검증이에요.

    처음엔 kubectl 출력만 보고 끝냈었는데, 나중에 보니 앱은 예전 설정으로 캐시해서 쓰고 있더라고요. 그래서 지금은 결과 검증을 더 꼼꼼히 하고 있어요.

    Kubernetes ConfigMap 적용 결과 검증 대시보드 이미지

    롤아웃 완료, 환경 변수 확인, 로그 검증까지 끝난 상태를 보여주는 결과 확인 이미지입니다.

    8. 자주 묻는 질문 정리

    Q1. ConfigMap 업데이트만 하면 바로 반영되나요?

    항상 그렇지는 않아요. 주입 방식과 애플리케이션 동작 방식에 따라 다르거든요. 환경 변수 기반이면 보통 재시작 관점으로 보는 게 안전해요.

    Q2. 환경 변수 미적용 문제는 Kubernetes 버그인가요?

    대부분은 버그라기보다 동작 방식 이해 차이에서 나와요. 저도 처음엔 그렇게 오해했는데, 실제로는 컨테이너 재기동 시점과 설정 읽는 타이밍 문제인 경우가 정말 많았어요.

    Q3. 설정 오류 디버깅은 어디서부터 봐야 하나요?

    ConfigMap 원본, Deployment 참조, Pod 내부 상태를 순서대로 보세요. 이 흐름만 지켜도 절반은 빨리 해결돼요.

    Q4. k8s 설정 관리를 더 안정적으로 하려면?

    선언형 관리, 변경 이력 추적, 운영 런북 정리 이 세 가지가 효과적이에요. 이전 글에서 다뤘던 배포 점검 체크리스트와 함께 보면 더 도움이 될 거예요. 다음 글에서는 Secret 운영 패턴과 ConfigMap 분리 기준도 다뤄볼 계획입니다.

    9. 마무리: ConfigMap은 단순한 설정 파일이 아니었습니다

    Kubernetes ConfigMap 문제 해결은 결국 설정 저장보다 설정 반영 경로를 이해하는 일에 가까워요. 제가 직접 해보니 ConfigMap 업데이트 자체보다, 그 값이 언제 어떻게 애플리케이션에 전달되는지 파악하는 게 핵심이었어요. 특히 환경 변수 미적용, 설정 오류 디버깅, k8s 설정 관리 이 세 가지는 따로 떨어진 주제가 아니라 한 흐름으로 묶여 있더라고요.

    혹시 지금 운영 중인 서비스에서 ConfigMap 업데이트 후 반영이 이상하다면, 오늘 글의 순서대로만 점검해보세요. 꽤 빨리 원인을 좁힐 수 있을 거예요. 완벽한 정답 하나가 있다기보다, 주입 방식에 맞는 운영 전략을 정해두는 것이 제일 중요했어요. 저도 처음엔 많이 헷갈렸는데, 한 번 패턴이 잡히고 나니까 훨씬 덜 흔들리더라고요.

    Kubernetes ConfigMap 문제 해결 전략 요약 인포그래픽

    환경 변수 방식과 파일 마운트 방식의 차이, 그리고 운영 체크포인트를 요약한 인포그래픽입니다.

    정리하면 이렇습니다.

    • ConfigMap 업데이트와 애플리케이션 반영은 같은 일이 아니에요.
    • 환경 변수 방식은 재시작 관점을 기본으로 가져가는 게 안전해요.
    • 파일 마운트 방식은 애플리케이션 재로딩 지원 여부를 꼭 확인해야 해요.
    • 설정 오류 디버깅은 ConfigMap, Deployment, Pod 내부 확인 순서로 보면 빨라져요.

    운영은 결국 반복 가능한 습관 싸움이더라고요. 다음 글에서는 Secret과 ConfigMap 분리 기준, 그리고 배포 자동화 파이프라인에서 설정 반영을 안전하게 묶는 방법도 이어서 정리해보겠습니다.

  • [k8s] AKS에서 Vault on K8s 구축: 보안 강화 및 민감 정보 관리 방안

    [k8s] AKS에서 Vault on K8s 구축: 보안 강화 및 민감 정보 관리 방안

    목차

    [k8s] AKS에서 Vault on K8s 구축: 보안 강화 및 민감 정보 관리 방안

    AKS(Azure Kubernetes Service, 애저 쿠버네티스 서비스)를 운영하다 보면 결국 부딪히는 문제가 하나 있습니다. 바로 시크릿 관리예요. 처음에는 Kubernetes Secret(쿠버네티스 시크릿)만으로도 충분하다고 느끼실 수 있는데, 저도 처음엔 그랬거든요. 그런데 운영 환경이 커지고, 애플리케이션 수가 늘고, 누가 어떤 자격 증명(credential)을 어디서 쓰는지 추적해야 하는 순간이 오면 상황이 달라져요. 그때부터는 “이걸 계속 이렇게 들고 가도 될까?” 싶은 생각이 드더라고요.

    그래서 오늘은 Vault on K8s AKS 구성을 어떻게 접근하면 좋을지, 제가 실제로 비슷한 구조를 설계하고 검증할 때 중요하게 봤던 포인트를 중심으로 정리해보려 해요. 핵심은 단순히 HashiCorp Vault(해시코프 볼트)를 올리는 게 아니라, AKS 환경에서 인증(auth), 저장(storage), 정책(policy), 주입(injection) 흐름을 어떻게 안전하게 묶을지하는 거거든요. 특히 민감 정보가 Git, 환경 변수, 컨테이너 이미지 안에 흩어지기 시작한 팀이라면 한 번쯤 진지하게 볼 만한 주제입니다.

    AKS 클러스터, Vault 서버, 애플리케이션 Pod, Kubernetes Auth 흐름을 한눈에 보여주는 전체 구조 이미지입니다.

    1. 왜 AKS에서 Vault on K8s가 필요할까요

    쉽게 말해, Vault는 시크릿을 중앙에서 관리하고 접근을 통제하는 금고 역할을 하는 거예요. Kubernetes Secret도 이름은 시크릿이지만, 그 자체만으로는 운영 통제 수준이 부족하다고 느끼는 경우가 많아요. Base64 인코딩만으로는 보안이 해결되지 않거든요. 물론 etcd 암호화(encryption at rest) 같은 보완책이 있지만, 접근 통제와 감사(audit), 동적 자격 증명(dynamic credentials)까지 생각하면 Vault가 주는 이점이 분명합니다.

    • 중앙 집중형 관리: DB 비밀번호, API 토큰, 인증서 등을 한곳에서 관리할 수 있어요.
    • 정책 기반 접근 제어: 누가 어떤 경로(path)의 시크릿을 읽을 수 있는지 세밀하게 나눌 수 있습니다.
    • 감사 추적: 접근 기록을 남겨서 운영 가시성을 확보하기 좋아요.
    • 동적 시크릿 확장 가능성: 정적 비밀번호를 오래 들고 가지 않는 구조로 발전시키기 쉬워요.

    여기서 중요한 포인트! AKS에서 Vault를 쓴다고 해서 자동으로 다 안전해지는 건 아니에요. 어디에 저장할지, 어떻게 인증할지, 어떤 네트워크 경계 안에 둘지를 같이 설계해야 의미가 있어요. 저도 처음엔 “Vault만 올리면 끝 아닌가?” 싶었는데, 실제로 해보니까 그다음이 진짜 시작이더라고요.

    2. Vault, AKS, Kubernetes Auth를 쉽게 풀어보면

    개념을 너무 어렵게 잡으면 오히려 구현이 꼬여요. 쉽게 말하면 흐름은 이렇습니다.

    1. 애플리케이션 Pod가 AKS 안에서 실행돼요.
    2. Pod는 자신의 ServiceAccount(서비스 어카운트)를 이용해 Vault에 신원을 증명합니다.
    3. Vault는 Kubernetes Auth(쿠버네티스 인증)로 이 Pod가 누구인지 확인해요.
    4. 정책에 맞으면 필요한 시크릿을 내려줍니다.

    즉, 애플리케이션 입장에서는 “내가 누구인지 증명하고, 허용된 비밀만 받아간다”는 구조예요. 이 방식의 장점은 시크릿을 애플리케이션 매니페스트에 하드코딩하지 않아도 된다는 거거든요. 운영해보신 분들은 아실 텐데, Secret YAML 파일이 여기저기 복사되기 시작하면 관리가 정말 힘들어져요.

    항목 Kubernetes Secret Vault on K8s
    저장 위치 클러스터 내부 Vault 백엔드
    접근 제어 RBAC 중심 정책 기반 세분화 가능
    감사 추적 제한적 Audit Device(감사 장치) 활용 가능
    주입 방식 환경 변수, 볼륨 Agent Injector, CSI 등 확장 가능
    운영 복잡도 낮음 상대적으로 높음

    결국 선택의 기준은 단순해요. 작고 단순한 환경이면 Kubernetes Secret만으로도 충분합니다. 반대로 권한 분리, 감사, 로테이션, 멀티 서비스 운영이 중요해지면 Vault on K8s AKS 구성이 훨씬 낫습니다.

    3. AKS에서 Vault on K8s 아키텍처를 어떻게 잡으면 좋을까

    제가 추천하는 기본 방향은 이래요. 과하게 복잡하게 시작하지 말고, 운영상 필요한 최소 안전장치를 먼저 넣는 거예요.

    • Vault는 전용 네임스페이스에 배치합니다.
    • Integrated Storage Raft(통합 스토리지 래프트)를 사용해 내부 저장소를 구성해요.
    • Kubernetes Auth로 애플리케이션 인증을 처리합니다.
    • Vault Agent Injector 또는 템플릿 렌더링 방식으로 시크릿을 Pod에 주입해요.
    • NetworkPolicy(네트워크 정책)와 Ingress(인그레스, 외부 트래픽 진입점) 또는 내부 LoadBalancer 정책을 명확히 나누어요.

    실무에서는 Vault를 외부에 완전히 공개하지 않는 편이 훨씬 나아요. 가능하면 내부 네트워크에서만 접근하게 만들고, 운영자 접근도 제한하는 쪽이 좋거든요. 홈랩에서도 이 부분을 느슨하게 두면 결국 테스트 편의성이 보안 기준을 이겨버리더라고요. 처음엔 편한데 나중에 반드시 정리해야 해요.

    AKS에서 Vault 네임스페이스와 컴포넌트 배치 구조 이미지

    Vault 전용 네임스페이스, Raft 스토리지, Agent Injector, 애플리케이션 네임스페이스 분리를 보여주는 구성 이미지입니다.

    4. 실전 구현: AKS에 Vault 배포하기

    이제 실제 흐름으로 가봅시다. 여기서는 Helm(헬름)을 이용해 Vault를 AKS에 배포하는 예시를 기준으로 설명할게요. 세부 값은 환경마다 다르니, 그대로 복붙보다 구조를 이해하고 적용하시는 게 훨씬 중요합니다.

    4-1. 네임스페이스와 Helm 저장소 준비

    kubectl create namespace vault
helm repo add hashicorp https://helm.releases.hashicorp.com
helm repo update

    여기까지는 크게 어렵지 않아요. 문제는 그다음 values 설정이에요. 처음엔 기본값으로 올리고 싶어지는데, 운영 목적이라면 최소한 스토리지와 UI, Injector 여부는 같이 잡아주는 게 좋습니다.

    4-2. values.yaml 예시

    server:
  enabled: true
  ha:
    enabled: true
    replicas: 3
    raft:
      enabled: true
  dataStorage:
    enabled: true
    size: 10Gi
  service:
    enabled: true
    type: ClusterIP
  ingress:
    enabled: false
  resources: {}

ui:
  enabled: true

injector:
  enabled: true

    여기서는 HA(고가용성)와 Raft storage를 켰어요. Vault on K8s는 단일 인스턴스로도 테스트는 되지만, 실제 운영 관점에서는 장애 대응을 생각하지 않을 수가 없거든요. 물론 노드 수, 디스크 크기, 서비스 타입은 환경에 맞춰 조정해야 합니다.

    4-3. 배포

    helm install vault hashicorp/vault \
  --namespace vault \
  --values values.yaml

    배포 후에는 Pod 상태부터 확인하세요.

    kubectl get pods -n vault
kubectl get svc -n vault

    이 시점에서 Pod가 뜬다고 끝이 아니에요. Vault는 초기화(initialization)와 언실(unseal) 과정을 거쳐야 하거든요. 이 부분에서 처음 삽질 많이 합니다 ㅎㅎ

    4-4. 초기화와 언실

    kubectl exec -it -n vault vault-0 -- vault operator init

    이 명령을 실행하면 unseal key와 initial root token이 출력돼요. 이 정보는 정말 민감하니까요, 테스트 환경이라고 터미널 히스토리에 남기고 방치하면 나중에 곤란해져요. 저도 예전에 PoC 환경이라고 가볍게 봤다가 정리하느라 번거로웠던 적이 있어요.

    이후 각 Pod에 대해 언실을 진행합니다.

    kubectl exec -it -n vault vault-0 -- vault operator unseal
kubectl exec -it -n vault vault-1 -- vault operator unseal
kubectl exec -it -n vault vault-2 -- vault operator unseal

    로그인도 해두세요.

    kubectl exec -it -n vault vault-0 -- vault login

    5. Kubernetes Auth와 시크릿 엔진 구성

    이제부터가 진짜 핵심이에요. Vault 서버를 띄우는 건 절반이고, AKS 워크로드가 안전하게 시크릿을 받아가게 만드는 과정이 나머지 절반입니다.

    5-1. KV 시크릿 엔진 활성화

    kubectl exec -it -n vault vault-0 -- vault secrets enable -path=secret kv-v2
kubectl exec -it -n vault vault-0 -- vault kv put secret/app/config username="demo-user" password="demo-pass"

    여기서는 예시로 KV v2(Key-Value Version 2) 엔진을 사용했어요. 정적 시크릿 관리의 기본 출발점으로 가장 무난하거든요.

    5-2. Kubernetes Auth 활성화

    kubectl exec -it -n vault vault-0 -- vault auth enable kubernetes

    그다음 Kubernetes API와 통신할 수 있도록 설정해야 합니다. 실제 값은 클러스터 환경에 맞게 확인이 필요해요.

    kubectl exec -it -n vault vault-0 -- sh

vault write auth/kubernetes/config \
  kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"

    환경에 따라 서비스 계정 토큰과 CA 인증서 경로까지 함께 지정하는 구성이 필요할 수 있어요. 이 부분은 클러스터 설정과 배포 방식에 따라 달라지니, 반드시 현재 환경 기준으로 검증해야 합니다.

    5-3. 정책 생성

    kubectl exec -it -n vault vault-0 -- sh -c 'cat > /tmp/app-policy.hcl <<EOF
path "secret/data/app/config" {
  capabilities = ["read"]
}
EOF
vault policy write app-policy /tmp/app-policy.hcl'

    정책은 정말 최소 권한(least privilege)으로 가야 해요. “일단 다 읽게 해두고 나중에 줄이자”는 접근이 제일 위험하거든요. 운영에 들어가면 나중은 잘 안 와요.

    5-4. Role 생성

    kubectl exec -it -n vault vault-0 -- vault write auth/kubernetes/role/app-role \
  bound_service_account_names=app-sa \
  bound_service_account_namespaces=default \
  policies=app-policy \
  ttl=1h

    이렇게 하면 default 네임스페이스의 app-sa 서비스 계정을 사용하는 Pod만 해당 정책으로 인증받을 수 있어요. namespace와 service account를 분리해두면 실수 범위를 줄이기 좋거든요.

    Vault on K8s AKS의 Kubernetes Auth와 정책 매핑 흐름

    ServiceAccount, Vault Role, Policy, Secret Path가 어떻게 연결되는지 보여주는 인증 및 권한 흐름 이미지입니다.

    6. 애플리케이션 Pod에 시크릿 주입하기

    실제로 써보니까 운영팀과 개발팀 모두 만족도가 올라가는 구간이 바로 여기였어요. 개발자는 애플리케이션에서 민감 정보를 직접 들고 다니지 않아도 되고, 운영자는 중앙 통제가 가능해지거든요.

    Vault Agent Injector를 사용하는 예시는 아래처럼 가져갈 수 있습니다.

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: default
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "app-role"
        vault.hashicorp.com/agent-inject-secret-config.txt: "secret/data/app/config"
        vault.hashicorp.com/agent-inject-template-config.txt: |
          {{- with secret "secret/data/app/config" -}}
          username={{ .Data.data.username }}
          password={{ .Data.data.password }}
          {{- end }}
    spec:
      serviceAccountName: app-sa
      containers:
        - name: app
          image: nginx
          volumeMounts: []

    이 예시는 Pod 안에 파일 형태로 시크릿을 렌더링하는 방식이에요. 환경 변수 주입만 고집하기보다, 파일 기반 주입을 먼저 고려해보세요. 이유는 단순해요. 환경 변수는 프로세스 정보나 디버깅 과정에서 노출 범위를 관리하기 까다로울 수 있거든요.

    배포 후에는 Pod 내부에서 실제로 파일이 생성됐는지 확인하세요.

    kubectl apply -f app.yaml
kubectl get pods
kubectl exec -it deploy/demo-app -- cat /vault/secrets/config.txt

    7. ⚠️ 운영 중 자주 만나는 문제와 트러블슈팅

    여기서는 제가 꼭 강조하고 싶은 실전 포인트를 적어볼게요. 문서대로만 하면 바로 될 것 같지만, 실제 AKS에서 붙일 때 자주 막히는 지점이 몇 군데 있어요.

    7-1. Pod는 떴는데 시크릿 파일이 안 생기는 경우

    • ServiceAccount 이름과 Vault Role의 bound_service_account_names가 일치하는지 확인하세요.
    • 네임스페이스가 Role 설정과 같은지 봐요.
    • Pod annotation 오타가 없는지 확인해요.
    • Injector Pod 로그를 확인합니다.
    kubectl logs -n vault deploy/vault-agent-injector

    이거 진짜 자주 나와요. 저도 처음엔 Vault 정책 문제인 줄 알았는데, 알고 보니 annotation 키 오타였던 적이 있었어요. 허무하죠. 근데 이런 게 제일 오래 갑니다.

    7-2. Vault 로그인 또는 Auth 설정이 실패하는 경우

    • Kubernetes API 접근 경로가 맞는지 봐요.
    • Vault 서버가 클러스터 내부 DNS와 API 서버에 접근 가능한지 확인하세요.
    • 서비스 계정 토큰과 CA 인증서 전달이 필요한 구성인지 점검해요.

    AKS는 관리형 Kubernetes라서 제어 플레인 세부 구현을 직접 만지지는 않지만, 그렇다고 인증 흐름이 자동으로 다 맞아떨어지지는 않아요. 특히 네트워크 제한이나 정책이 들어가면 더 꼼꼼히 봐야 합니다.

    7-3. Vault 자체의 고가용성은 올렸는데 운영 절차가 없는 경우

    이 부분도 많이 놓쳐요. HA로 배포했다고 해서 운영이 끝난 게 아니거든요.

    • 언실 절차를 누가 어떻게 수행할지
    • 루트 토큰 보관 정책을 어떻게 할지
    • 백업과 복구 테스트를 할지
    • 감사 로그 보존을 어디까지 할지

    보안 시스템은 설치보다 운영 절차가 훨씬 중요해요. 이건 정말 해보면 바로 체감됩니다.

    8. 검증 방법과 기대 결과

    구축이 끝났다면 그냥 “접속된다” 수준에서 멈추면 아쉬워요. 최소한 아래 항목은 꼭 검증해보세요.

    1. 권한이 있는 Pod만 시크릿을 읽을 수 있는지 확인하세요.
    2. 다른 ServiceAccount를 쓰는 Pod는 접근이 거부되는지 확인합니다.
    3. Vault 정책 변경 시 반영 범위를 확인해요.
    4. Pod 재기동 시 시크릿 주입이 일관되게 되는지 확인하세요.
    5. 감사 로그와 서버 로그에서 접근 기록을 추적할 수 있는지 봐요.

    예를 들어 권한 없는 Pod를 하나 띄워서 동일 경로를 읽어보는 식으로 검증할 수 있어요. 이런 부정 테스트(negative test)를 같이 해봐야 진짜 구성이 맞는지 보여요.

    kubectl run test-deny --rm -it --image=busybox --restart=Never -- sh

    운영 결과 관점에서 기대할 수 있는 건 명확합니다.

    • 애플리케이션 매니페스트에 민감 정보가 직접 들어가지 않아요.
    • 시크릿 접근 경로가 정책으로 정리돼요.
    • 누가 무엇을 읽는지 추적성이 좋아져요.
    • 향후 동적 시크릿이나 인증서 자동화로 확장하기 쉬워져요.

    특히 팀 규모가 커질수록 이점이 커져요. 처음엔 조금 번거롭지만, 나중에는 “왜 더 빨리 안 했지?” 싶을 때가 와요. 실제로 써보니까 시크릿이 여기저기 흩어져 있던 상태보다 운영 피로도가 훨씬 낮아지더라고요.

    AKS에서 Vault 시크릿 주입 검증 결과 이미지

    애플리케이션 Pod 내부 시크릿 파일 생성, 정책 기반 접근 허용/거부 검증 결과를 보여주는 이미지입니다.

    9. 정리와 다음 단계

    Vault on K8s AKS 구성의 핵심은 단순해요. Vault를 설치하는 것이 목적이 아니라, AKS에서 민감 정보를 안전하게 배포하고 통제하는 체계를 만드는 게 진짜 목표거든요. 처음엔 Kubernetes Secret만으로 충분해 보일 수 있어요. 저도 그렇게 시작했었는데, 서비스가 늘고 권한 관리가 복잡해지니까 한계가 분명히 보이더라고요.

    오늘 정리한 흐름을 다시 압축하면 이렇습니다.

    • Vault를 AKS에 전용 네임스페이스로 배치해요.
    • Raft 기반 저장소와 HA 구성을 검토해요.
    • Kubernetes Auth로 Pod 신원을 검증합니다.
    • 정책 기반으로 필요한 시크릿만 주입해요.
    • 운영 절차와 감사 체계를 같이 설계하세요.

    혹시 지금 HashiCorp Vault 도입을 고민 중이세요? 그렇다면 처음부터 모든 기능을 한 번에 붙이기보다, KV 시크릿 엔진 + Kubernetes Auth + 최소 정책부터 시작해보는 걸 추천해요. 그게 훨씬 덜 꼬여요. 드디어 됐다! 싶은 순간이 분명 옵니다.

    다음 글에서는 AKS에서 Vault와 외부 비밀 저장소를 어떻게 연계해서 운영 부담을 줄일지, 또는 Vault Agent Injector와 CSI 방식의 차이를 어떻게 판단하면 좋을지 이어서 다뤄볼 예정이에요. 이전 글에서 Kubernetes 기본 보안 설정을 정리했다면 그 내용과 함께 보셔도 흐름이 잘 맞을 거예요.

    FAQ: 자주 묻는 질문

    AKS에서 꼭 Vault가 필요할까요?

    작고 단순한 환경이라면 꼭 그렇지는 않아요. 다만 시크릿 관리 범위가 넓어지고 감사와 권한 분리가 중요해지면 검토 가치가 크답니다.

    Vault on K8s는 운영 난도가 높지 않나요?

    맞습니다. Kubernetes Secret보다 복잡해요. 대신 통제력과 확장성이 좋아져요. 그래서 작은 범위로 시작하는 게 중요합니다.

    시크릿은 환경 변수보다 파일 주입이 더 나은가요?

    상황에 따라 다르지만, 운영 노출 범위를 생각하면 파일 기반 주입이 더 다루기 편한 경우가 많아요.

    Vault on K8s AKS 도입 전후 비교 인포그래픽

    도입 전 분산된 시크릿 관리와 도입 후 중앙 통제 구조를 비교하는 요약 인포그래픽입니다.