Kubernetes(쿠버네티스) 입문부터 실전 운영까지 | 클러스터 구성, 배포, 최적화 완전 가이드

Kubernetes는 컨테이너 오케스트레이션의 표준으로, 클러스터 구성부터 배포 자동화, 스케일링, 보안까지 모든 운영 단계를 체계적으로 관리할 수 있는 플랫폼입니다.

---

Kubernetes란 무엇인가

Kubernetes(쿠버네티스, K8s)는 Google이 개발하고 현재 CNCF(Cloud Native Computing Foundation)가 관리하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다.

컨테이너화된 애플리케이션의 배포, 스케일링, 관리를 자동화하는 강력한 시스템으로,
현대 클라우드 네이티브 환경에서 필수적인 기술로 자리잡았습니다.

2025년 현재 Kubernetes는 v1.34까지 출시되었으며,
Pod 인증서 요청(PodCertificateRequests)을 통한 X.509 인증서 발급 메커니즘이 도입되는 등 지속적으로 발전하고 있습니다.

전세계 조직의 3분의 2 이상이 클라우드에서 Kubernetes 클러스터를 호스팅하고 있으며,
이는 Kubernetes가 클라우드 네이티브 컴퓨팅의 새로운 표준이 되었음을 보여줍니다.

Kubernetes는 단순히 컨테이너를 실행하는 것을 넘어, 선언적 구성을 통해 원하는 상태를 정의하고 시스템이 자동으로 그 상태를 유지하도록 합니다.

이를 통해 개발자는 인프라 관리보다 애플리케이션 개발에 더 집중할 수 있습니다.

---

Kubernetes 핵심 아키텍처 이해하기

컨트롤 플레인(Control Plane) 구성 요소

Kubernetes 클러스터의 두뇌 역할을 하는 컨트롤 플레인은 여러 핵심 컴포넌트로 구성됩니다.

kube-apiserver는 Kubernetes API를 노출하는 컴포넌트로, 모든 클러스터 조작의 진입점 역할을 합니다.

kubectl 명령어나 다른 도구들은 모두 이 API 서버를 통해 클러스터와 통신하며,
TLS를 통한 데이터 암호화로 컨트롤 플레인과 클라이언트 간 통신을 보호해야 합니다.

etcd는 클러스터의 모든 데이터를 저장하는 분산 키-값 저장소입니다.

클러스터의 현재 상태와 구성 정보가 모두 etcd에 저장되므로, etcd 서버의 보안은 필수적이며 암호화와 강력한 접근 제어가 필요합니다.

kube-scheduler는 새로 생성된 파드를 적절한 노드에 할당하는 역할을 담당합니다.

리소스 요구사항, 하드웨어/소프트웨어 제약, 어피니티 규칙 등을 고려하여 최적의 노드를 선택합니다.

kube-controller-manager는 다양한 컨트롤러를 실행하는 컴포넌트로, 노드 컨트롤러, 복제 컨트롤러, 엔드포인트 컨트롤러 등이 포함됩니다.

각 컨트롤러는 클러스터의 현재 상태를 원하는 상태로 만들기 위해 지속적으로 동작합니다.

더 자세한 Kubernetes 아키텍처는 Kubernetes 공식 문서에서 확인할 수 있습니다.

워커 노드(Worker Node)의 역할

워커 노드는 실제 컨테이너화된 애플리케이션이 실행되는 머신입니다.

kubelet은 각 노드에서 실행되는 에이전트로, 파드 스펙을 받아 컨테이너가 정상적으로 실행되고 있는지 확인합니다.

kube-proxy는 노드의 네트워크 규칙을 유지 관리하며, 파드로의 네트워크 통신을 가능하게 합니다.

Container Runtime은 실제로 컨테이너를 실행하는 소프트웨어로, Docker, containerd, CRI-O 등이 있습니다.

---

Kubernetes 주요 오브젝트 완벽 정리

파드(Pod): 가장 작은 배포 단위

파드는 Kubernetes에서 생성하고 관리할 수 있는 가장 작은 배포 가능한 컴퓨팅 단위입니다.

하나 이상의 컨테이너로 구성되며, 같은 파드 내의 컨테이너들은 스토리지와 네트워크를 공유합니다.

파드는 일시적인(ephemeral) 성격을 가지므로, 직접 파드를 생성하기보다는 Deployment나 StatefulSet 같은 상위 수준의 컨트롤러를 사용하는 것이 권장됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80

보조 워크로드용 파드가 애플리케이션 워크로드 대비 약 3:1 비율로 증가하는 추세는 조직들이 Kubernetes를 모니터링, 서비스 메시 등 다양한 용도로 확장하고 있음을 보여줍니다.

노드(Node): 클러스터의 워커 머신

노드는 Kubernetes 클러스터의 워커 머신으로, 가상 머신이나 물리 머신일 수 있습니다.

각 노드는 파드를 실행하는 데 필요한 서비스를 포함하며, 컨트롤 플레인에 의해 관리됩니다.

노드의 상태는 주소(Address), 조건(Condition), 용량(Capacity), 정보(Info) 등으로 구성됩니다.

노드 테인트(Taint)와 톨러레이션(Toleration)을 사용하여 특정 워크로드를 특정 노드에 격리하고 리소스를 최적화할 수 있습니다.

서비스(Service) 및 네트워킹

Service는 파드의 논리적 집합과 그것들에 접근하는 정책을 정의하는 추상화입니다.

파드는 언제든지 재시작되거나 새로 생성될 수 있어 IP 주소가 변경되므로, Service가 안정적인 네트워크 엔드포인트를 제공합니다.

ClusterIP: 클러스터 내부에서만 접근 가능한 기본 서비스 타입입니다.

NodePort: 각 노드의 IP에 정적 포트를 열어 외부에서 접근할 수 있게 합니다.

LoadBalancer: 클라우드 제공자의 로드 밸런서를 사용하여 외부에 서비스를 노출합니다.

ExternalName: DNS CNAME 레코드를 반환하여 외부 서비스에 매핑합니다.

인그레스(Ingress): HTTP/HTTPS 라우팅

Ingress는 클러스터 외부에서 내부 서비스로의 HTTP와 HTTPS 라우트를 노출합니다.

트래픽 라우팅은 Ingress 리소스에 정의된 규칙에 의해 제어됩니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Kubernetes Gateway API가 버전 1.33 이상에서 일반 사용 가능해지면서, Ingress의 대안으로 더 풍부한 기능을 제공하고 있습니다.

Ingress 컨트롤러 구성에 대해서는 Kubernetes Ingress 공식 가이드를 참고하세요.

---

Kubernetes 클러스터 구성 실전 가이드

로컬 개발 환경 구축

Kubernetes 입문자는 먼저 로컬 환경에서 클러스터를 구성하는 것이 좋습니다.

Minikube는 로컬 머신에서 단일 노드 Kubernetes 클러스터를 실행할 수 있는 도구입니다.

# Minikube 설치 (macOS)
brew install minikube

# 클러스터 시작
minikube start --driver=docker

# 상태 확인
kubectl cluster-info
kubectl get nodes

kind(Kubernetes IN Docker)는 Docker 컨테이너를 노드로 사용하여
로컬 Kubernetes 클러스터를 실행합니다.

멀티 노드 클러스터 구성이 가능하며, CI/CD 환경에서 테스트용으로 많이 사용됩니다.

Docker Desktop은 Windows와 macOS에서 단일 노드 Kubernetes 클러스터를 제공합니다.

설정에서 Kubernetes를 활성화하면 간단히 사용할 수 있습니다.

프로덕션 클러스터 구성 방법

프로덕션 환경에서는 고가용성, 확장성, 보안을 고려한 클러스터 구성이 필요합니다.

kubeadm은 Kubernetes 클러스터를 부트스트랩하는 공식 도구입니다.

최소한의 안전한 클러스터를 빠르게 구성할 수 있으며, 베어메탈이나 VM 환경에 적합합니다.

# 마스터 노드 초기화
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

# kubectl 설정
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

# CNI 플러그인 설치 (예: Calico)
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# 워커 노드 추가
kubeadm join <master-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

관리형 Kubernetes 서비스는 클라우드 제공자가 컨트롤 플레인을 관리해주므로 운영 부담이 줄어듭니다.

Amazon EKS는 Kubernetes 1.34 버전을 지원하며 보안 강화와 리소스 관리 개선 기능을 제공합니다.

Google Kubernetes Engine(GKE), Azure Kubernetes Service(AKS), DigitalOcean Kubernetes 등 다양한 선택지가 있습니다.

각 서비스의 특징과 가격을 비교하여 비즈니스 요구사항에 맞는 플랫폼을 선택해야 합니다.

관리형 서비스 선택 가이드는 AWS EKS 공식 문서를 참고하세요.

클러스터 네트워킹 설정

Kubernetes 네트워킹은 CNI(Container Network Interface) 플러그인을 통해 구현됩니다.

Calico는 BGP 기반의 네트워크 정책 엔진으로, 높은 성능과 유연한 정책 관리를 제공합니다.

Flannel은 간단하고 설정이 쉬운 오버레이 네트워크 솔루션입니다.

Cilium은 eBPF 기반으로 고성능 네트워킹과 보안 기능을 제공합니다.

Cilium Gateway를 사용한 Gateway API 튜토리얼이 커뮤니티에서 제공되고 있습니다.

---

애플리케이션 배포 실전 전략

Deployment와 StatefulSet의 차이점

Kubernetes에서 애플리케이션을 배포하는 방법은 상태 관리 여부에 따라 달라집니다.

특징	Deployment	StatefulSet
용도	상태를 저장하지 않는(Stateless) 애플리케이션	상태를 저장하는(Stateful) 애플리케이션
파드 식별자	랜덤 해시로 생성 (예: nginx-7d8f4c9b5-xk2lp)	순차적 인덱스 (예: mysql-0, mysql-1)
스토리지	공유 PVC 사용 가능	각 파드마다 고유 PVC 자동 생성
생성/삭제 순서	순서 없음, 병렬 처리	순차적 생성 및 역순 삭제
네트워크 ID	불안정, 재생성 시 변경	안정적, 재생성 후에도 유지
업데이트 전략	RollingUpdate 기본 지원	순차적 롤링 업데이트
사용 예시	웹 서버, API 서버, 마이크로서비스	데이터베이스, 메시징 큐, 상태 저장 앱

Deployment는 상태가 없는 애플리케이션을 위한 것이며 파드를 교환 가능한 것으로 취급하는 반면, StatefulSet은 영구적인 식별자와 스토리지가 필요한 상태 저장 애플리케이션에 사용됩니다.

Deployment 예제: 무상태 웹 애플리케이션

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"

StatefulSet 예제: MySQL 데이터베이스 클러스터

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql-headless
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

StatefulSet의 각 파드는 재스케줄링 시에도 유지되는 영구적인 식별자를 가지며, 이를 통해 기존 볼륨을 새 파드와 쉽게 매칭할 수 있습니다.

StatefulSet은 헤드리스 서비스(Headless Service)와 함께 사용하여 각 파드에 안정적인 DNS 이름을 제공합니다.

데이터베이스처럼 각 인스턴스가 고유한 역할을 가지는 경우, StatefulSet을 사용하면 primary 역할의 파드에 항상 일관되게 연결할 수 있어 read-write 액세스가 가능합니다.

더 자세한 StatefulSet 사용법은 Kubernetes StatefulSet 공식 문서를 확인하세요.

Helm 차트로 패키지 관리하기

Helm은 Kubernetes의 패키지 매니저로,
복잡한 애플리케이션을 간단하게 배포하고 관리할 수 있게 해줍니다.

Helm 차트는 모든 Kubernetes 매니페스트를 버전 관리된 단일 유닛으로 묶어,
배포를 파일이 아닌 패키지로 취급합니다.

Helm 설치 및 기본 사용

# Helm 설치 (macOS)
brew install helm

# 리포지토리 추가
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# 애플리케이션 설치
helm install my-wordpress bitnami/wordpress

# 설치된 릴리스 확인
helm list

# 업그레이드
helm upgrade my-wordpress bitnami/wordpress --set wordpressUsername=admin

# 롤백
helm rollback my-wordpress 1

커스텀 Helm 차트 생성

# 새 차트 생성
helm create my-app

# 차트 구조
my-app/
  Chart.yaml          # 차트 메타데이터
  values.yaml         # 기본 설정 값
  templates/          # Kubernetes 매니페스트 템플릿
    deployment.yaml
    service.yaml
    ingress.yaml
  charts/             # 의존성 차트

Helm 팀의 공식 베스트 프랙티스는 차트 구조화 방법과 values 사용법을 중점적으로 다루며, 공개 배포용 차트 작성에 특히 유용합니다.

Helm은 Go 템플릿 엔진을 사용하여 강력한 템플릿 기능을 제공하며, 환경별로 다른 values 파일을 사용할 수 있습니다.

# 개발 환경 배포
helm install my-app ./my-app -f values-dev.yaml

# 프로덕션 환경 배포
helm install my-app ./my-app -f values-prod.yaml

Helm 차트를 CI/CD 파이프라인에 통합하면 배포를 자동화하고 릴리스 주기를 단축할 수 있습니다.

GitOps 방식으로 Helm을 사용하면 Git이 단일 진실 소스(Single Source of Truth)가 되어 일관성과 감사 추적이 가능합니다.

Helm 베스트 프랙티스는 Helm 공식 문서에서 확인할 수 있습니다.

배포 전략과 롤링 업데이트

Kubernetes는 다양한 배포 전략을 지원하여 다운타임 없이 애플리케이션을 업데이트할 수 있습니다.

롤링 업데이트(Rolling Update)는 기본 배포 전략으로, 파드를 점진적으로 업데이트합니다.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 최대 추가 파드 수
      maxUnavailable: 0  # 최대 사용 불가 파드 수

블루/그린 배포(Blue/Green Deployment)는 새 버전을 완전히 배포한 후 트래픽을 전환합니다.

Service의 selector를 변경하여 순간적으로 트래픽을 전환할 수 있습니다.

카나리 배포(Canary Deployment)는 일부 사용자에게만 새 버전을 배포하여 점진적으로 확대합니다.

Istio나 Flagger 같은 서비스 메시를 사용하면 더욱 정교한 카나리 배포가 가능합니다.

---

자동 스케일링으로 최적화하기

Horizontal Pod Autoscaler (HPA)

HPA는 CPU 사용률이나 커스텀 메트릭을 기반으로 파드 수를 자동으로 조절합니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

HPA를 사용하려면 Metrics Server가 클러스터에 설치되어 있어야 합니다.

# Metrics Server 설치
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# HPA 상태 확인
kubectl get hpa
kubectl describe hpa web-app-hpa

Vertical Pod Autoscaler (VPA)

VPA는 파드의 CPU와 메모리 요청을 자동으로 조정하여 리소스를 최적화합니다.

Kubernetes v1.34에서 In-Place Pod Resize 기능이 개선되어 메모리 제한 감소 시 best-effort OOM 보호를 추가했습니다.

VPA는 세 가지 모드로 동작합니다.

• Off: 권장 사항만 제공하고 자동 조정은 하지 않습니다
• Initial: 파드 생성 시에만 리소스를 설정합니다
• Auto: 파드를 재시작하며 리소스를 자동 조정합니다

Cluster Autoscaler

Cluster Autoscaler는 노드 수를 자동으로 조절하여 클러스터 전체의 용량을 관리합니다.

클러스터 오토스케일링은 현재 수요에 따라 클러스터 크기를 동적으로 조정하여 비용 효율성을 최적화하고 피크 시간에 충분한 용량을 보장합니다.

파드가 리소스 부족으로 스케줄링되지 못하면 노드를 추가하고, 노드의 사용률이 낮으면 노드를 제거합니다.

클라우드 제공자의 관리형 서비스를 사용하면 Cluster Autoscaler가 자동으로 설정되는 경우가 많습니다.

---

클러스터 보안 강화 전략

RBAC(Role-Based Access Control) 구성

Kubernetes API에 대한 접근을 제한하는 것이 클러스터 보안의 핵심 단계이며, 승인된 사용자만 API 서버에 접근하고 역할 기반 접근 제어로 인증 및 권한 부여해야 합니다.

RBAC는 사용자와 서비스 계정에 대한 세밀한 권한 관리를 제공합니다.

Role과 RoleBinding 예제: 네임스페이스 수준의 권한

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole과 ClusterRoleBinding: 클러스터 전체 권한

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
subjects:
- kind: Group
  name: system:monitoring
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

최소 권한 원칙을 따라 사용자에게 작업 수행에 필요한 가장 필수적인 리소스에만 접근 권한을 부여해야 합니다.

Pod Security Standards 적용

Pod Security Standards는 세 가지 광범위한 정책을 제시합니다: Privileged(가장 넓은 권한), Baseline(최소 지정 구성 허용), Restricted(가장 엄격한 제어)

Pod Security Admission을 사용하여 네임스페이스 수준에서 보안 정책을 적용할 수 있습니다.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

SecurityContext를 사용하여 파드와 컨테이너 수준에서 보안을 강화합니다.

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

가능한 한 비특권 컨테이너를 사용하고, 특권 액세스는 승인된 사용자에게만 부여하며 적절한 교육을 제공해야 합니다.

네트워크 정책으로 트래픽 제어

네임스페이스의 네트워크 정책은 애플리케이션 작성자가 다른 네임스페이스의 어떤 파드가 자신의 네임스페이스 내 파드와 포트에 접근할 수 있는지 제한할 수 있게 합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: database
    ports:
    - protocol: TCP
      port: 5432

네트워크 정책은 기본적으로 화이트리스트 방식으로 동작하며, 정책이 없으면 모든 트래픽이 허용됩니다.

네트워크를 세분화하여 클러스터에 대한 무단 접근을 방지하고, 네트워크 보안 그룹과 방화벽을 사용하여 컨트롤 플레인과 워커 노드에 대한 액세스를 제어해야 합니다.

시크릿 관리와 암호화

Kubernetes Secret은 비밀번호, OAuth 토큰, SSH 키 같은 민감한 정보를 저장합니다.

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64 인코딩
  password: cGFzc3dvcmQxMjM=

etcd 데이터 암호화와 강력한 접근 제어를 통해 고객 데이터를 보호해야 하며, 저장 시 암호화(Encryption at Rest)를 활성화해야 합니다.

External Secrets Operator나 HashiCorp Vault를 사용하면 더 안전한 시크릿 관리가 가능합니다.

# Sealed Secrets 사용 예
kubeseal --format yaml < secret.yaml > sealed-secret.yaml
kubectl apply -f sealed-secret.yaml

시크릿을 Git 저장소에 평문으로 저장하지 말고, SOPS나 Sealed Secrets 같은 도구를 사용하여 암호화해야 합니다.

보안 설정에 대한 더 자세한 내용은 Kubernetes 보안 공식 문서를 참고하세요.

컨테이너 이미지 스캔

검증된 소스에서 이미지를 가져오고 항상 최신 이미지를 사용하며, 빌드 단계에서 이미지 스캔을 추가해야 합니다.

Trivy, Grype, Clair 같은 도구로 컨테이너 이미지의 취약점을 스캔할 수 있습니다.

# Trivy로 이미지 스캔
trivy image --severity HIGH,CRITICAL nginx:1.27

# CI/CD 파이프라인에 통합
docker build -t myapp:latest .
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest
docker push myapp:latest

빌드 단계에서 조기 탐지를 통해 안전하지 않은 패키지나 구성을 수정하고, CI/CD 파이프라인에 이미지 스캔을 통합하여 지속적인 피드백을 제공해야 합니다.

---

모니터링과 로깅 구축하기

Prometheus와 Grafana로 메트릭 수집

Prometheus는 Kubernetes 환경에서 가장 널리 사용되는 모니터링 솔루션입니다.

# Helm으로 Prometheus 스택 설치
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack

# Grafana 접속
kubectl port-forward svc/prometheus-grafana 3000:80

Prometheus는 풀(pull) 기반 메트릭 수집 방식을 사용하며, PromQL 쿼리 언어로 데이터를 분석합니다.

Grafana는 Prometheus 데이터를 시각화하여 대시보드를 제공하며, 미리 만들어진 Kubernetes 대시보드를 쉽게 임포트할 수 있습니다.

알림 규칙을 설정하여 임계값을 초과하면 Slack, PagerDuty 등으로 알림을 받을 수 있습니다.

ELK 스택으로 로그 관리

로그는 애플리케이션 디버깅과 모니터링에 필수적입니다.

Elasticsearch: 로그 데이터를 저장하고 검색하는 분산 검색 엔진

Logstash/Fluentd: 로그를 수집하고 변환하여 Elasticsearch로 전송

Kibana: Elasticsearch 데이터를 시각화하고 검색하는 웹 인터페이스

Fluentd나 Fluent Bit을 DaemonSet으로 배포하여 모든 노드에서 로그를 수집할 수 있습니다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch
        env:
        - name: FLUENT_ELASTICSEARCH_HOST
          value: "elasticsearch.logging.svc.cluster.local"
        - name: FLUENT_ELASTICSEARCH_PORT
          value: "9200"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

---

Kubernetes 최적화 가이드

리소스 요청과 제한 설정

적절한 리소스 설정은 클러스터 효율성과 안정성의 핵심입니다.

Requests: 컨테이너가 보장받는 최소 리소스
Limits: 컨테이너가 사용할 수 있는 최대 리소스

resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "1000m"

리소스가 설정되지 않은 파드는 스케줄링 우선순위가 낮고, 노드 리소스 부족 시 먼저 종료될 수 있습니다.

네임스페이스에 CPU와 메모리 쿼터를 설정하면 단일 네임스페이스가 클러스터 리소스를 독점하는 것을 방지할 수 있습니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: development
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"

헬스 체크와 프로브 구성

Kubernetes는 세 가지 유형의 프로브를 제공합니다.

Liveness Probe: 컨테이너가 실행 중인지 확인하며, 실패 시 컨테이너를 재시작합니다

Readiness Probe: 컨테이너가 요청을 처리할 준비가 되었는지 확인하며, 실패 시 서비스 엔드포인트에서 제외합니다

Startup Probe: 컨테이너 애플리케이션이 시작되었는지 확인하며, 시작이 느린 애플리케이션에 유용합니다

spec:
  containers:
  - name: app
    image: myapp:1.0
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
      timeoutSeconds: 5
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    startupProbe:
      httpGet:
        path: /startup
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

프로브는 서비스가 예상대로 작동하는지 지속적으로 보장하여 다운타임을 최소화하고 무응답 애플리케이션의 트래픽 수신을 방지합니다.

Pod Disruption Budget 설정

PDB는 자발적 중단 중에도 최소한의 파드가 실행되도록 보장합니다.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

노드 유지보수나 클러스터 업그레이드 시 PDB가 있으면 애플리케이션 가용성을 보장할 수 있습니다.

ConfigMap과 환경 변수 관리

ConfigMap은 민감하지 않은 구성 데이터를 저장하여 애플리케이션 코드와 분리하고, 컨테이너 이미지를 재빌드하지 않고도 쉽게 관리하고 업데이트할 수 있게 합니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database.host: "postgres.database.svc.cluster.local"
  database.port: "5432"
  app.log.level: "info"
  feature.flags: |
    {
      "newUI": true,
      "betaFeature": false
    }

ConfigMap을 환경 변수나 볼륨으로 마운트하여 사용할 수 있습니다.

spec:
  containers:
  - name: app
    envFrom:
    - configMapRef:
        name: app-config
    volumeMounts:
    - name: config
      mountPath: /etc/config
  volumes:
  - name: config
    configMap:
      name: app-config

---

트러블슈팅 가이드

일반적인 문제와 해결 방법

파드가 Pending 상태에 머물러 있을 때

# 파드 상태 확인
kubectl describe pod <pod-name>

# 이벤트 확인
kubectl get events --sort-by=.metadata.creationTimestamp

리소스 부족, 노드 셀렉터 미스매치, PVC 바인딩 실패 등이 원인일 수 있습니다.

파드가 CrashLoopBackOff 상태일 때

# 로그 확인
kubectl logs <pod-name>
kubectl logs <pod-name> --previous

# 컨테이너 실행 명령어 확인
kubectl get pod <pod-name> -o yaml

애플리케이션 오류, 잘못된 환경 변수, 헬스 체크 실패 등을 확인해야 합니다.

ImagePullBackOff 오류

이미지 이름 오타, 레지스트리 인증 실패, 네트워크 문제 등이 원인입니다.

# 이미지 풀 시크릿 생성
kubectl create secret docker-registry regcred \
  --docker-server=<registry-server> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email>

# 파드에 적용
spec:
  imagePullSecrets:
  - name: regcred

디버깅 도구 활용

kubectl debug는 임시 디버그 컨테이너를 생성하여 문제를 진단합니다.

# 디버그 컨테이너 실행
kubectl debug <pod-name> -it --image=busybox

# 노드 디버깅
kubectl debug node/<node-name> -it --image=ubuntu

stern은 여러 파드의 로그를 동시에 스트리밍합니다.

# stern 설치 (macOS)
brew install stern

# 특정 라벨의 모든 파드 로그 보기
stern -l app=web -n production

---

프로덕션 운영 체크리스트

프로덕션 환경에서 Kubernetes를 안전하게 운영하기 위한 핵심 체크리스트입니다.

클러스터 구성
- 고가용성을 위한 멀티 마스터 노드 구성
- 정기적인 etcd 백업 및 복구 테스트
- 노드 오토스케일링 설정
- 적절한 네트워크 플러그인 선택 및 설정

보안
- RBAC 최소 권한 원칙 적용
- Pod Security Standards 강제 적용
- 네트워크 정책으로 트래픽 제어
- 시크릿 암호화 및 외부 키 관리 시스템 사용
- 정기적인 컨테이너 이미지 취약점 스캔
- API 서버 감사 로깅 활성화

애플리케이션 배포
- 모든 워크로드에 리소스 요청/제한 설정
- Liveness, Readiness, Startup Probe 구성
- Pod Disruption Budget 설정
- 환경별 구성 분리 (ConfigMap, Secret)
- 적절한 배포 전략 선택 (Rolling, Blue/Green, Canary)

모니터링 및 로깅
- Prometheus와 Grafana로 메트릭 수집 및 시각화
- 중앙 집중식 로깅 시스템 구축
- 알림 규칙 설정 및 온콜 로테이션
- SLI/SLO 정의 및 추적

지속적 개선
- 정기적인 Kubernetes 버전 업그레이드
- 리소스 사용량 분석 및 최적화
- 재해 복구 계획 수립 및 테스트
- 팀 교육 및 문서화

---

마치며

Kubernetes는 현대 클라우드 네이티브 애플리케이션 운영의 핵심 기술입니다.

이 가이드에서 다룬 컨테이너 오케스트레이션의 기본 개념부터 프로덕션 운영까지의 여정이 여러분의 Kubernetes 입문과 실전 운영에 도움이 되기를 바랍니다.

파드(Pod), 노드(Node), 서비스(Service) 및 인그레스(Ingress) 같은 기본 오브젝트부터 자동 스케일링, Helm 차트, StatefulSet/Deployment 차이, 클러스터 보안까지 모든 주제를 실전 중심으로 다루었습니다.

Kubernetes는 계속 발전하고 있으며, 커뮤니티와 공식 문서를 통해 최신 정보를 지속적으로 업데이트하는 것이 중요합니다.

Kubernetes 공식 문서와 CNCF 웹사이트에서 더 많은 리소스를 찾아볼 수 있습니다.

실습을 통해 경험을 쌓고, 작은 프로젝트부터 시작하여 점진적으로 복잡한 시스템으로 확장해 나가는 것을 추천합니다.

Kubernetes 클러스터 구성과 배포, 최적화를 마스터하여 여러분의 DevOps 여정에 성공하시기를 응원합니다.

---

참고 자료

• Kubernetes 공식 문서
• Helm 공식 문서
• CNCF 프로젝트
• Kubernetes Best Practices

---

DynamoDB 완전 정복 | AWS DynamoDB로 NoSQL 마스터하기

AWS DynamoDB 완전 가이드. NoSQL 데이터베이스 설계, Single Table Design, GSI 활용법, 프로비저닝/온디맨드 용량 비교, DynamoDB 스트림으로 서버리스 애플리케이션 구축하는 실전 방법 총정리.

🌐 tech-in-depth-hub.blogspot.com

Gemini 2.5 Flash Image(aka Nano-Banana) 개발자 가이드 2025 | 새 기능 해부

Gemini 2.5 Flash Image(Nano-Banana) GA 버전의 10가지 aspect_ratio, response_modalities 설정법과 실전 코드 예제를 담은 완벽한 개발자 가이드입니다.

🌐 tech-in-depth-hub.blogspot.com

로드밸런싱 알고리즘 종류, 페일오버, 헬스 체크까지 완전 해설

로드밸런싱 알고리즘 종류부터 헬스 체크, 페일오버 전략까지 웹서버 로드밸런싱 구성의 모든 것을 다룬 완벽 가이드. 실무 예제와 클라우드 비교 포함.

🌐 tech-in-depth-hub.blogspot.com

양자컴퓨터란 무엇인가 | 큐비트부터 응용까지 한눈에 정리

양자역학 원리를 활용한 양자컴퓨터는 큐비트의 중첩과 얽힘 현상을 통해 기존 슈퍼컴퓨터가 1만 년 걸릴 계산을 단 몇 분 만에 처리하며, 2025년 구글 윌로우와 마이크로소프트 Majorana 1 등 획기적 기술 발전으로 신약 개발부터 암호 해독까지 다양한 분야에서 혁신

🌐 tech-in-depth-hub.blogspot.com

REST API vs GraphQL 비교 가이드 | 어떤 방식을 선택할까?

REST API vs GraphQL 차이점 완벽 분석. 오버페칭·언더페칭 해결법과 실무 도입 기준을 2025년 최신 트렌드로 제시하는 개발자 필수 가이드.

🌐 tech-in-depth-hub.blogspot.com