쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 스케일링

■ 쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 일반적인 스케일링

• `kubectl scale deployment/[이름] --replicas=10`
  • 디플로이먼트에서 관리하고 있는 파드의 수량을 10개로 증가 시킨다.  별도의 조건이나 상태 확인 없이 증가 시킨다.
• `kubectl autoscale deployment/[이름] --min=10 --max=15 --cpu-percent=80`
  • 평균 CPU 사용량 80% 유지
  • 최소 레플리카 수량 10개
  • 최대 레플리카 수량 15개
  • 정의된 CPU 사용량을 유지하기 위해 레플리카의 수량을 조절하는 방식을 HPA (Horizontal Pod Autoscaler)라고 하며, HPA를 사용한다면 디플로이먼트/레플리카셋에서 `.spec.replica` 값을 삭제하는 것을 쿠버네티스테서는 권장한다. 삭제하지 않는다면 디플로이먼트의 업데이트 및 수정 발생 시 쿠버네티스가 `.spec.replica`을 참조하여 파드의 수를 조정하기 때문이다. 
  • 단, `.spec.replica`의 값을 삭제하게 되면 1회성으로 파드의 숫자가 1개를 남기고 나머지 파드는 모두 중지 된다 (기본값이 1) . 이후 HPA에 의해 롤링 업데이트가 동작한다. 쿠버네티스에서는 1회성 성능 저하를 방지하는 방법을 제공하며 수정 방법에 따라 클라이언트(기본값)에서 수정할 것인지 서버쪽에서 수정할 것인지 선택 가능하다. 참조:  Horizontal Pod Autoscaling | Kubernetes

 

■ 쿠버네티스(Kubernetes) 디플로이먼트 (Deployment) 비례적(Proportional) 스케일링

• 비례적 스케일링은 디플로이먼트의 배포 전략과 연관이 있다. 디플로이먼트의 배포 전략은 Recreate와 RollingUpdate 2가지 방법이 있고, 배포전략을 롤링 업데이트로 수행하게 되면 디폴로이먼트 컨트롤러는 위험을 줄이기 위해 기존 활성화된 레플리카셋과 추가 레플리카의 균형을 조절하게 되는데 이것을 비례적 스케일링 이라고 한다. 
• 롤링 업데이트는 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 해준다. 롤링 업데이트 선택 시 "최대 불가(Max Unavailable)"와 "최대 서지(Max Surge)"를 정의 하여 프로세스를 제어 한다.
  • 최대 불가(Max Unavailable): 업데이트 프로세스 중에 사용할 수 없는 최대 파드의 수를 지정하는 선택적 필드이며 절대 숫자 또는 비율(%)로 정의 한다. 기본값은 25%이다. 즉, 디플로이먼트의 레플리카 설정을 10개이고 최대 불가 비율이 30%인 경우,  롤링 업데이트가 발생하게 되면 최대 불가 비율에 따라 업데이트 과정에서 동시에 사용할 수 없는 파드의 수가 3개를 넘지 않도록 보장 한다. 
  • 최대 서지(Max Surge): 의도한 파드의 수에 대해 생성할 수 있는 최대 파드의 수를 지정하는 선택적 필드이다. 이 값은 절대 숫자 또는 의도한 파드 비율(%)로 정의한다. 기본값은 25% 이다. 즉, 해당 값을 30%로 지정 후 롤링 업데이트를 수행 하게 되면 기존 레플리카와 신규 레플리카의 파드 수량의 합이 130%를 넘지 않도록 한다. 레플리카 수량을 10개로 정의 한다면 롤링 업데이트 과정에서 13개 (10개 + 최대 서지 30% 3개) 초과 하지 않도록 보장하는 것이다.