개념 - 애플리케이션 배포

  • 5분

Kubernetes에 애플리케이션을 배포하기 전에 Kubernetes 배포를 검토하고 시나리오에서 해당 제한 사항에 대해 논의해 보겠습니다.

Kubernetes 배포란?

A diagram that shows a Kubernetes Deployment with a label and three pods.

Kubernetes 배포는 Pod의 진화입니다. 배포는 Pod를 스케일 아웃할 수 있는 인텔리전트 개체로 래핑합니다. 복잡한 네트워킹 규칙을 구성할 필요 없이 더 많은 로드를 지원하도록 애플리케이션을 쉽게 복제하고 스케일링할 수 있습니다.

배포를 활용하면 이미지 태그를 변경하는 것만으로 가동 중지 시간 없이 애플리케이션을 업데이트할 수 있습니다. 배포를 업데이트하면 온라인 앱이 하나씩 비활성화되며, 모든 앱을 삭제하고 새 앱을 만드는 대신 최신 버전으로 바뀝니다. 즉, 배포에서 가용성에 눈에 띄는 영향을 주지 않고 내부 Pod를 업데이트할 수 있습니다.

Pod를 통해 배포를 사용하는 경우 많은 이점이 있지만 시나리오를 적절하게 처리할 수는 없습니다.

이 시나리오에는 다양한 시간에 많은 수의 이벤트를 수신하는 이벤트 기반 애플리케이션이 포함됩니다. KEDA Scaler 개체 또는 HPA가 없으면 수동으로 복제본(replica) 수를 조정하여 이벤트 수를 처리하고 부하가 정상으로 돌아올 때 배포를 축소해야 합니다.

샘플 배포 매니페스트

배포 매니페스트의 샘플 조각은 다음과 같습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: contoso-microservice
spec:
  replicas: 10                      # Tells K8S the number of pods needed to process the Redis list items
  selector:                         # Define the wrapping strategy
    matchLabels:                    # Match all pods with the defined labels
      app: contoso-microservice     # Labels follow the `name: value` template
  template:                         # Template of the pod inside the deployment
    metadata:
      labels:
        app: contoso-microservice
    spec:
      containers:
        - image: mcr.microsoft.com/mslearn/samples/redis-client:latest
          name: contoso-microservice

샘플 매니페스트에서 replicas는 최대 이벤트 수를 처리하는 데 사용할 수 있는 필요한 복제본에 대해 설정할 수 있는 가장 높은 수인 10으로 설정됩니다. 그러나 이로 인해 애플리케이션이 비피크 시간 동안 너무 많은 리소스를 소비하므로 클러스터 내의 다른 배포가 굶어 죽을 수 있습니다.

한 가지 솔루션은 독립 실행형 HPA를 사용하여 Pod의 CPU 사용량을 모니터링하는 것입니다. 이는 양방향으로 수동으로 크기를 조정하는 것보다 더 나은 옵션입니다. 그러나 HPA는 Redis 목록에 수신된 이벤트 수에 초점을 맞추지 않습니다.

가장 좋은 해결 방법은 KEDA 및 Redis 스케일러 를 사용하여 목록을 쿼리하고 이벤트를 처리하는 데 더 많거나 적은 Pod가 필요한지 확인하는 것입니다.