개발자를 위한 Kubernetes: 실습과 디버깅

Kubernetes 실전 입문: 로컬 클러스터부터 클라우드 배포까지

Kubernetes는 단순한 컨테이너 오케스트레이션 도구가 아닙니다—분산 애플리케이션을 관리하는 사실상의 표준입니다. 이 글은 이론에서 빠르게 실전으로 넘어가고 싶은 개발자와 엔지니어를 대상으로 합니다: 로컬 클러스터를 배포하고, 기본 객체를 이해하며, 관리형 클라우드 서비스를 준비하는 내용입니다.

작업 환경 설정

첫 번째 단계는 Kubernetes API와 상호작용하는 주요 CLI 도구인 kubectl을 설치하는 것입니다. 클라이언트 버전은 클러스터 버전과 마이너 릴리스 브랜치 하나 이내로 차이가 나야 합니다. OS에 따라 설치 방법이 다릅니다:

• Linux: Kubernetes 저장소의 공식 스크립트;
• macOS: brew install kubectl;
• Windows: winget, Chocolatey, 또는 직접 바이너리 다운로드.

중요: Docker Desktop을 사용하는 경우 내장된 kubectl이 메인 설치본과 충돌할 수 있습니다. 단일 설치 지점을 사용하고 PATH 변수를 관리하는 것이 권장됩니다.

로컬 개발에는 두 가지 솔루션이 잘 맞습니다:

Minikube

Minikube는 가상 머신이나 컨테이너(드라이버에 따라 다름) 안에서 단일 노드 클러스터를 만듭니다. 한 명령어로 시작하세요:

minikube start

시작 후 노드 상태를 확인하세요:

kubectl get nodes

예상 결과: Ready 상태의 노드 하나.

Kind (Kubernetes in Docker)

Kind는 노드를 Docker 컨테이너로 실행합니다. 기존 Docker 워크플로와의 타이트한 통합에 특히 편리합니다:

kind create cluster

Kind의 장점은 빠른 시작과 간편한 정리입니다. 하지만 초보자에게는 방대한 문서와 커뮤니티 지원 덕에 Minikube가 여전히 선호됩니다.

클러스터를 시작한 후 연결성을 확인하세요:

kubectl cluster-info

명령어가 Control Plane 구성 요소 정보를 출력하면 환경이 준비된 것입니다.

Kubernetes 기본 객체

Kubernetes에서 애플리케이션은 Pod, Deployment, Service라는 세 가지 핵심 추상화로 구성됩니다.

Pod — 최소 실행 단위

Pod는 네트워크 네임스페이스, 볼륨, IPC를 공유하는 하나 이상의 컨테이너 그룹입니다. Pod 안 컨테이너들은 localhost로 서로 통신할 수 있습니다. 하지만 Pod는 일시적입니다: 장애, 업데이트, 스케일링으로 언제든 삭제될 수 있어 직접 관리하는 건 권장되지 않습니다.

Deployment — 선언적 복제본 관리

Deployment는 애플리케이션의 원하는 상태를 정의합니다: 복제본 수, 컨테이너 이미지, 업데이트 전략 등. 예제 매니페스트:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1.2
        ports:
        - containerPort: 80

매니페스트를 적용하세요:

kubectl apply -f deployment.yaml

Kubernetes가 지정된 Pod 수를 유지하는 ReplicaSet을 자동으로 생성합니다.

Service — 안정적인 네트워크 진입점

Service는 라벨로 선택된 Pod 그룹에 안정적인 IP 주소와 DNS 이름을 제공합니다. 예제 내부 서비스:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - port: 8080
      targetPort: 80
  type: ClusterIP

Minikube에서 로컬 액세스를 위해:

minikube service my-app-service

이 명령어는 올바른 URL로 브라우저를 자동으로 열어줍니다.

클라우드로 이동: 관리형 클러스터

로컬 환경을 익힌 후 프로덕션 배포로 나아가는 게 자연스럽습니다. kubeadm으로 수동 클러스터 설정은 가능하지만 대부분의 경우 비효율적입니다. 관리형 서비스를 이용하세요:

• Amazon EKS — 유연하지만 AWS IAM과 VPC에 대한 깊은 이해가 필요;
• Google GKE — 자동 노드 관리와 내장 보안으로 가장 성숙한 구현;
• Azure AKS — Microsoft 생태계와 Azure DevOps를 쓸 때 편리.

권장 방식은 Infrastructure as Code (IaC)입니다. Terraform처럼 클러스터와 노드 그룹을 선언적으로 정의하면 재현성과 버전 관리가 쉽습니다.

클라우드 클러스터 생성 후 kubeconfig를 업데이트하세요:

aws eks update-kubeconfig --name my-app-cluster

이제 모든 kubectl 명령어가 클라우드 클러스터를 대상으로 합니다.

일반적인 문제 디버깅

Kubernetes 오류는 반복되는 패턴을 보입니다. 체계적으로 접근하세요:

• Pod 상태 확인: kubectl get pods
• 로그 검토: kubectl logs <pod-name>
• 이벤트 분석: kubectl describe pod <pod-name>
• 필요 시 컨테이너 진입: kubectl exec -it <pod-name> -- /bin/sh

일반 문제와 해결법:

• ImagePullBackOff: 이미지 이름, 태그, 프라이빗 레포용 imagePullSecrets 확인;
• CrashLoopBackOff: 앱 로그와 이벤트에서 OOMKilled나 init 오류 확인;
• Service unreachable: Pod 라벨이 Service selector와 맞는지, 포트(port, targetPort, containerPort)가 일치하는지 확인.

CPU와 메모리에 resources.requests와 resources.limits를 항상 지정하세요—노드 불안정과 스케줄링 문제를 막아줍니다.

다음으로 공부할 것

기본을 익힌 후 다음에 집중하세요:

• Ingress and Gateway API — 외부 트래픽 라우팅;
• ConfigMaps and Secrets — 하드코딩 없는 구성 관리;
• Jobs and CronJobs — 일회성 및 주기적 작업;
• Horizontal Pod Autoscaler — 메트릭 기반 자동 스케일링.

Kubernetes 생태계는 빠르게 변합니다: Gateway API 같은 새 표준이 구식을 대체 중입니다. 최신 동향을 따라가되, 모든 걸 한 번에 배우려 하지 말고 구체적 문제를 먼저 해결하세요.

핵심 요약

• Kubernetes는 선언적 접근을 요구합니다: 원하는 상태를 정의하면 시스템이 실현합니다.
• 로컬 클러스터(Minikube, Kind)는 프로덕션 위험 없이 실험할 안전한 환경입니다.
• 관리형 클라우드 서비스(EKS, GKE, AKS)는 운영 시간을 수백 시간 절약해줍니다.
• 디버깅은 kubectl get, describe, logs부터—90% 문제를 해결합니다.
• 클러스터 불안정을 막기 위해 리소스 제한을 항상 설정하세요.

— Editorial Team