Kubernetes (7)

쿠버네티스 컨트롤러 - StatefulSet, Ingress, Autoscaler

---

StatefulSet의 특징과 ReplicaSet과의 차이점

쿠버네티스에서 StatefulSet은 상태를 유지해야 하는 애플리케이션을 위한 워크로드 API 오브젝트다. ReplicaSet이 상태가 없는(Stateless) 애플리케이션을 위한 것이라면, StatefulSet은 상태가 있는(Stateful) 애플리케이션을 위해 설계되었다. 대표적인 Stateful 애플리케이션으로는 MongoDB, MariaDB, Redis와 같은 데이터베이스가 있다.

ReplicaSet과 StatefulSet의 주요 차이점

• Pod 이름 생성 방식

  • ReplicaSet: Pod 이름이 랜덤하게 생성됨 (예: my-app-jk291, my-app-f3g21)
  • StatefulSet: Pod 이름이 순차적인 인덱스로 생성됨 (예: my-app-0, my-app-1, my-app-2)

• Pod 생성 및 삭제 순서

  • ReplicaSet: Pod가 동시에 생성되고 삭제됨
  • StatefulSet: Pod가 순차적으로 생성(0→1→2)되고, 삭제는 역순(2→1→0)으로 진행됨

• Pod 재생성 시 동작

  • ReplicaSet: Pod가 삭제되면 완전히 새로운 이름으로 Pod가 생성됨
  • StatefulSet: Pod가 삭제되어도 동일한 이름으로 재생성되어 기존 신원 유지됨

• Replicas 변경 시 동작

  • ReplicaSet: replicas=0 설정 시 모든 Pod가 동시에 삭제됨
  • StatefulSet: replicas=0 설정 시 인덱스가 높은 Pod부터 순차적으로 삭제됨

# StatefulSet 예제
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db-statefulset
spec:
  serviceName: "db"
  replicas: 3
  selector:
    matchLabels:
      app: database
  template:
    metadata:
      labels:
        app: database
    spec:
      containers:
      - name: db
        image: mysql:5.7
        ports:
        - containerPort: 3306

StatefulSet, PVC 및 Headless Service 연결

StatefulSet은 상태 데이터를 영구적으로 저장하기 위해 PVC(PersistentVolumeClaim)와 Headless Service와 밀접하게 연동된다.

• PVC 연결 방식

  • ReplicaSet: PVC를 직접 생성해야 하며, 여러 Pod가 동일한 PVC를 공유함
  • StatefulSet: volumeClaimTemplate을 통해 각 Pod마다 별도의 PVC를 자동 생성하고 연결함

• Pod 삭제 시 PVC 처리

  • ReplicaSet: Pod와 함께 PVC도 삭제될 수 있음
  • StatefulSet: Pod가 삭제되어도 PVC는 유지되며, 동일한 이름의 Pod가 재생성되면 기존 PVC와 자동 연결됨

• Headless Service 사용

  • StatefulSet은 일반적으로 Headless Service와 함께 사용됨
  • Headless Service: ClusterIP가 None으로 설정된 특수한 서비스 타입
  • 각 Pod에 예측 가능한 DNS 이름 제공 (...svc.cluster.local)
  • 특정 Pod에 직접 접근 가능 (로드밸런싱 없이)

# Headless Service 예제
apiVersion: v1
kind: Service
metadata:
  name: db
spec:
  clusterIP: None  # Headless Service 설정
  selector:
    app: database
  ports:
  - port: 3306
    targetPort: 3306

# StatefulSet Pod의 DNS 이름 예시
db-0.db.default.svc.cluster.local
db-1.db.default.svc.cluster.local
db-2.db.default.svc.cluster.local

Ingress

Ingress는 쿠버네티스 클러스터 외부에서 내부 서비스로 HTTP/HTTPS 트래픽을 라우팅하는 API 오브젝트다. L7 레벨의 로드밸런싱을 제공하여 URL 경로나 호스트 이름을 기반으로 트래픽을 다양한 서비스로 분배한다.

Ingress의 주요 구성요소

• Ingress 리소스: 라우팅 규칙을 정의하는 쿠버네티스 오브젝트
• Ingress 컨트롤러: 실제 로드밸런싱을 수행하는 구현체 (예: NGINX Ingress Controller, Kong, Traefik)

Ingress의 주요 유즈케이스

• 서비스 로드밸런싱: 다수의 백엔드 서비스에 URL 경로 기반으로 트래픽 분배

  예: example.com/auth/* → auth-service로 라우팅
      example.com/api/* → api-service로 라우팅

• Canary 배포: 트래픽의 일부를 새 버전으로 점진적 전환

  예: 사용자 요청의 10%는 v2로, 90%는 v1으로 라우팅

# Ingress 예제
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /auth
        pathType: Prefix
        backend:
          service:
            name: auth-service
            port:
              number: 80
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

쿠버네티스 Autoscaler 종류와 특징

쿠버네티스는 워크로드의 수요 변화에 자동으로 대응하기 위한 다양한 Autoscaler를 제공한다. 세 가지 주요 Autoscaler는 각각 다른 스케일링 방식을 제공한다.

1. HPA (Horizontal Pod Autoscaler)

• 기능: Pod의 개수를 자동으로 조절하는 수평적 확장(Scale Out/In)
• 적합한 워크로드: Stateless 애플리케이션(웹 서버, API 서버 등)
• 작동 방식:
  • CPU/메모리 사용률이나 커스텀 메트릭을 모니터링
  • 지정된 임계값을 초과하면 Pod 수를 증가(Scale Out)
  • 부하가 감소하면 Pod 수를 감소(Scale In)

2. VPA (Vertical Pod Autoscaler)

• 기능: Pod의 CPU/메모리 리소스 할당량을 자동으로 조절하는 수직적 확장(Scale Up/Down)
• 적합한 워크로드: Stateful 애플리케이션(데이터베이스 등)
• 작동 방식:
  • Pod의 리소스 사용량을 모니터링
  • 필요할 경우 Pod에 할당된 리소스(CPU/메모리)를 증가(Scale Up)
  • 리소스 사용량이 적으면 할당 리소스를 감소(Scale Down)

3. CA (Cluster Autoscaler)

• 기능: 클러스터의 노드 수를 자동으로 조절
• 작동 방식:
  • 스케줄링할 수 없는 Pod가 있으면 노드 추가
  • 노드 활용도가 낮으면 노드 삭제
  • 클라우드 환경에서 자동으로 인프라 자원 관리

[중요] 한 컨트롤러에 HPA와 VPA를 동시에 적용하면 충돌이 발생하여 정상 작동하지 않는다.

다음은 HPA 구성 예시다:

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

HPA 동작 원리 심층 분석

HPA가 어떻게 Pod의 성능을 모니터링하고 자동으로 스케일링하는지 알아보자.

HPA 작동 구조 및 구성 요소

동작 원리

HPA 동작 과정

1. 메트릭 수집 단계

   • cAdvisor(Resource Estimator): 각 노드의 컨테이너 자원 사용량(CPU, 메모리) 모니터링
   • kubelet: cAdvisor가 수집한 정보를 metrics-server로 전달
   • metrics-server: 각 노드의 kubelet으로부터 메트릭 정보를 수집하여 저장

2. 분석 및 의사결정 단계

   • HPA 컨트롤러: kube-apiserver를 통해 metrics-server에서 메트릭 정보를 가져옴
   • 기본 15초마다 메트릭을 체크하여 설정된 임계값과 비교
   • 스케일링 필요 여부 결정

3. 스케일링 실행 단계

   • 스케일링 필요 시 HPA 컨트롤러가 kube-apiserver를 통해 컨트롤러(Deployment, ReplicaSet 등)의 replicas 값을 변경
   • 컨트롤러는 변경된 replicas 값에 따라 Pod 생성 또는 삭제 작업 수행

커스텀 메트릭을 활용한 HPA

기본 CPU/메모리 메트릭 외에도 다양한 커스텀 메트릭으로 HPA를 구성할 수 있다:

• Prometheus 연동
  • 인그레스 요청 수
  • 큐 길이
  • 네트워크 패킷 수
  • 비즈니스 지표(초당 주문 수, 사용자 세션 수 등)

# 파드 및 노드의 리소스 사용량 확인 명령어
kubectl top pod
kubectl top node

고급 HPA 설정

• 스케일링 동작 안정화: scaleDown, scaleUp 정책 설정으로 급격한 변화 방지
• 안정화 기간: stabilizationWindowSeconds를 통해 급격한 메트릭 변동에 따른 빈번한 스케일링 방지
• 여러 메트릭 동시 사용: CPU, 메모리, 커스텀 메트릭을 조합하여 정교한 스케일링 정책 구현