3. 컨테이너와 쿠버네티스
- 이성림
- 김호진
- 1 1. Container 란
- 1.1 1.1 Container
- 1.2 1.2 VM
- 1.3 1.3 Container와 VM 비교
- 1.4 1.4 컨테이너 살펴보기
- 1.4.1 1.4.1 컨테이너
- 1.4.2 1.4.2 리눅스 네임스페이스
- 1.4.3 1.4.3 Cgroup
- 1.5 1.5 컨테이너의 장점
- 2 2. Docker
- 2.1 2.1 도커 주요 컴포넌트
- 2.2 2.2 Docker의 등장
- 2.3 2.3 OCI (Open Container Initiative)는?
- 2.4 2.4 도커를 이용한 앱 개발
- 2.5 2.5 실습환경 구축 - VM 구성 테스트
- 2.5.1 2.5.1. 기동 된 VM 확인
- 2.5.2 2.5.2. Image 가져오기
- 2.5.3 2.5.3. 컨테이너 기동
- 2.5.4 2.5.4. Container 내부 탐험
- 2.5.5 2.5.5. Image 삭제
- 2.5.6 2.5.6. Linux 서버에 웹서버 구축
- 2.5.7 2.5.7. Dockerfile을 통한 도커 이미지 생성
- 2.5.8 2.5.8. 이미지 Build
- 2.5.9 2.5.9. 이미지 태그
- 3 3. 컨테이너 Orchestration
- 4 4. 쿠버네티스
1. Container 란
보통 IT인이 아니라면 ‘컨테이너’ 라는 말에 다음의 그림을 상상하실 겁니다.
1.1 Container
사전적 의미로 컨테이너는 어떤 물체를 격리하는 공간을 뜻합니다. 하지만 우리에게 컨테이너는 어떤 의미일까요?
컨테이너는 리눅스 기술을 사용하여, 선박의 컨테이너처럼 프로세스가 사용하는 자원을 격리하는 것입니다.
컨테이너는 기존의 온프레미스 환경이나 클라우드 환경 등 어디서나 실행될 수 있도록 애플리케이션 코드와 해당 라이브러리 및 종속 항목을 포함하는 독립적으로 실행 가능한 소프트웨어 패키지입니다.
컨테이너는 OS의 기능을 활용하여 프로세스를 격리하고, 격리된 프로세스가 CPU, 메모리, 스토리지, 네트워크 리소스를 쉽게 공유할 수 있게 해줍니다.
컨테이너는 격리된 프로세스 형태로 실행되므로 환경에 상관없이 빠르고 안정적이며 일관된 배포를 보장합니다.
1.2 VM
VM은 하이퍼바이저라는 가상화 소프트웨어 계층을 사용하여 하드웨어를 가상화하고, 각 VM을 서로 분리하여 상호작용할 수 있는 가상 컴퓨팅 환경을 구축하는 기술입니다.
VM에는 애플리케이션, 관련 라이브러리 및 종속 항목과 함께 게스트 OS가 포함됩니다.
1.3 Container와 VM 비교
가상 환경에 익숙하다면 컨테이너를 가상 머신(VM)에 비교하여 생각하면 이해하기 쉽습니다.
컨테이너는 가상머신과 마찬가지로 애플리케이션을 관련 라이브러리 및 종속 항목과 함께 패키지로 묶어 소프트웨어 서비스 구동을 위한 격리 환경을 마련해 줍니다.
Host | VM | 컨테이너 |
|---|---|---|
|
|
|
컨테이너를 사용하면 개발자와 IT 운영팀이 훨씬 작은 단위로 업무를 수행할 수 있으므로 그에 따른 이점도 많습니다.
1.4 컨테이너 살펴보기
Control groups : 리소스 사용량(CPU/Memory/Network/Storage) 결정
Namespaces : 자원을 격리(네트워크/프로세스/사용자정보 - 공개 범위를 결정)
Union mount file system : 컨테이너 이미지를 효율적으로 관리
1.4.1 컨테이너
컨테이너는 애플리케이션을 실행하는 데 사용될 수 있는 OS 가상화의 한 형태입니다
이를 위해 컨테이너는 리눅스 커널의 몇 가지 새로운 기능으로 제작되었으며, 그 중 두 가지 주요 기능은 "namespace"와 "cgroups"입니다.
1.4.2 리눅스 네임스페이스
네임스페이스는 리눅스 커널의 기능 중 하나이며 리눅스의 컨테이너의 기본적인 측면입니다.반면에 네임스페이스는 격리 계층을 제공합니다.네임스페이스는 한 프로세스 집합은 한 리소스 집합을 보고 다른 프로세스 집합은 다른 리소스 집합을 보도록 커널 리소스를 분할하는 리눅스 커널의 기능입니다.
리눅스 네임스페이스 종류
PID PID 네임스페이스를 통해 별도의 프로세스를 만들 수 있습니다.
네트워크 : 네트워킹 네임스페이스를 사용하면 같은 컴퓨터에서 실행되는 다른 프로세스와 충돌하지 않고 포트에서 프로그램을 실행할 수 있습니다.
IPC(Interprocess communication) 네임스페이스에는 자체 IPC 리소스(예: POSIX 메시지 큐)가 있습니다.
마운트 : 마운트 네임스페이스를 사용하면 호스트 파일 시스템에 영향을 주지 않고 파일 시스템을 마운트 및 마운트 해제할 수 있습니다.
UNIX Time-Sharing (UTS) 네임스페이스를 사용하면 단일 시스템이 서로 다른 프로세스의 호스트 및 도메인 이름을 가지는 것처럼 보일 수 있습니다.
Linux 네임스페이스를 만드는 것은 매우 간단하며 UTS namespace를 만들어서 확인해보겠습니다.
root@ubuntu-focal:~# unshare --fork --pid --mount-proc bash
root@ubuntu-focal:~# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.3 8960 3928 pts/4 S 13:00 0:00 bash
root 8 0.0 0.3 10612 3268 pts/4 R+ 13:00 0:00 ps aux호스트에서 확인
root@ubuntu-focal:~# ps aux | grep unshare
root 9258 0.0 0.0 7232 520 pts/3 S 13:09 0:00 unshare --fork --pid --mount-proc bash
root 9372 0.0 0.0 8160 720 pts/4 S+ 13:09 0:00 grep --color=auto unshareunshare namespace에서 빠져나오기 위해 docker와 같이 exit 수행
root@ubuntu-focal:~# exit
exit
root@ubuntu-focal:~# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.8 102540 8840 ? Ss 12:04 0:02 /sbin/init
root 2 0.0 0.0 0 0 ? S 12:04 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? I< 12:04 0:00 [rcu_gp]
root 4 0.0 0.0 0 0 ? I< 12:04 0:00 [rcu_par_gp]
root 6 0.0 0.0 0 0 ? I< 12:04 0:00 [kworker/0:0H-kblockd]
1.4.3 Cgroup
리눅스 네임스페이스로 다른 프로세스와는 별도의 프로세스를 만들 수도 있었습니다.
그러나 여러 네임스페이스를 생성할 경우 각 네임스페이스의 리소스를 제한하여 다른 네임스페이스의 리소스를 차지하지 않도록 하려면 어떻게 해야 합니까?
2007년에 몇몇 사람들은 우리만을 위한 cgroup을 개발했습니다.이것은 프로세스의 리소스를 제한할 수 있는 리눅스 기능입니다.Cgroups는 프로세스에서 사용할 수 있는 CPU 및 메모리의 한계를 결정합니다.
Cgroups(제어 그룹에서 약칭)는 프로세스의 리소스 사용량(CPU, 메모리, 디스크 I/O, 네트워크 등)을 제한, 계정 및 분리하는 리눅스 커널 기능으로, 2008년 1월 출시된 커널 버전 2.6.24에서는 제어 그룹 기능이 리눅스 커널 메인 라인에 병합되었습니다.
cgroups로 제어할 수 있는 일반적인 리소스는 다음과 같습니다.
CPU: 프로세스 그룹에서 사용하는 CPU 시간을 제한
메모리: 프로세스 그룹에서 사용하는 메모리 양을 제한합니다.
I/O: 프로세스 그룹에서 사용하는 Disk I/O 양 제한
네트워크: 프로세스 그룹에서 사용하는 네트워크 대역폭의 양을 제한합니다.
1.5 컨테이너의 장점
(1) 가벼움
사용자의 Request Traffic 이 증가함에 따라, 가상머신이나 컨테이너를 추가적으로 배포합니다.
가상머신의 크기는 최소 몇 GB이지만, 컨테이너의 경우 Guest OS가 없기에 MB단위의 크기를 가집니다.
가상머신은 배포하는데 수분에서 수 십분의 시간이 소요되지만, 컨테이너는 배포에 소요되는 몇 초 밖에 걸리지 않습니다.
(2) 탄력성 / 이식성 / 플랫폼독립성
컨테이너가 모든 종속 항목들을 자신과 함께 전달하므로, OS나 라이브러리 등의 환경 설정이 호스트 운영 체제와 상관없이 동일하게 유지되며, On-premise 및 클라우드 환경에서 이를 재구성하지 않고 바로 실행할 수 있습니다
이런 특성으로 인해, 컨테이너는 운영체제 및 기동 장비 상관없이 어느 환경에서나 구동 되므로 개발 및 배포가 크게 쉬워집니다.
(3)성능
리소스 사용이 많은 애플리케이션의 성능은 하이퍼바이저를 사용하는 것보다 컨테이너가 훨씬 우수합니다.
기존 가상화에서는 게스트 OS도 자체 메모리 요구 사항을 충족해야 하기 때문에 귀중한 RAM을 호스트에서 가져와야 합니다.
하지만 컨테이너는 OS자원을 공유하므로, OS의 CPU/MEMORY의 성능을 그대로 나타냅니다.
아래 자료는 2018년도 자료이지만, CPU와 Memory는 성능저하가 거의 없습니다.
컨테이너를 따로 Layer로 칭하지 않는 이유이기도 합니다.
(4) 유지 관리 효율
운영 체제 커널이 하나밖에 없기 때문에 운영 체제 수준에서 업데이트 또는 패치 작업을 한 번만 수행하면 변경 사항이 모든 컨테이너에 적용됩니다.
이를 통해 서버를 더 효율적으로 운영하고 유지 관리할 수 있습니다.
(5) 활용도 향상
컨테이너를 사용하여 개발자와 운영자는 CPU 및 메모리 리소스 활용도를 향상시킬 수 있습니다.
컨테이너는 마이크로서비스 아키텍처도 허용하므로 애플리케이션의 구성을 보다 미세하게 배치 및 스케일링할 수 있습니다.
(6) 격리
컨테이너는 격리된 환경에서 실행되기 때문에, 한 컨테이너에서 발생한 보안/장애 문제가 다른 컨테이너나 호스트 운영체제에 영향을 미치지 않습니다.
2. Docker
개발자와 시스템 관리자가 컨테이너로 애플리케이션을 개발, 배포 및 실행할 수 있는 플랫폼입니다.
2.1 도커 주요 컴포넌트
docker engine
여러분 모두가 아는 그 엔진, 이 엔진containerd / dockerd /cri-o
container 런타임runc
Open Container Initiative (OCI) 규격에 맞게 컨테이너를 실행하고 생성하는 CLI 도구
낮은 수준의 컨테이너 런타임
하위 컨테이너 런타임의 주요 작업은 컨테이너를 생성하고 삭제하는 것입니다.
높은 수준의 컨테이너 런타임
여러 컨테이너 관리, 컨테이너 이미지 전송 및 관리, 낮은 수준의 컨테이너 런타임으로 컨테이너 이미지 로드 및 언팩에 중점을 둡니다.
2.2 Docker의 등장
사용자가 컨테이너와 더 쉽게 소통할 수 있도록 컨테이너 관리하는 새로운 도구가 탄생했는데, 도커도 그 중 하나입니다.
2.3 OCI (Open Container Initiative)는?
컨테이너 포맷과 런타임에 대한 개방형 업계 표준을 만들기 위한 목적으로 Linux Foundation 의 지원으로 구성된 오픈 거버넌스 조직 (프로젝트)입니다.
OCI는 2015년 6월 22일에 Docker 사와 CoreOS 사가 각각 별도로 표준화를 진행하고 있던 컨테이너의 규격을 통일하는 것을 목적으로 Docker, CoreOS 그리고 AWS, Google, Microsoft, IBM 등 주요 플랫폼 벤더가 참여하여 2015 년 6 월에 발족 한 단체입니다.
=> 컨테이너 규격을 통일하는 것을 목적으로 만들어진 조직
2.4 도커를 이용한 앱 개발
개발 순서
코드개발
Dockerfile 생성
Dockerfile Image 생성
Container Orchestrator를 통한 배포
Container run
Container image Push
2.5 실습환경 구축 - VM 구성 테스트
먼저 cmd로 들어간다.
2.5.1. 기동 된 VM 확인
vagrant 명령어로 확인
$ vagrant box list
2.5.2. Image 가져오기
(1) docker image 저장소
기본 개념에서와 같이 도커는 저장소(registry)에서 이미지를 가져와 사용을 합니다.
(2) docker hub 확인
(3) docker 이미지 이름 구성
(4) 이미지 가지고 오기
2.5.3. 컨테이너 기동
(1) 현재 실행 중인 컨테이너 확인
(2) 컨테이너 기동
설명>
2.5.4. Container 내부 탐험
(1) exec 명령어를 이용한 컨테이너 접속
2.5.5. Image 삭제
보통은 이미지를 삭제하기 전 컨테이너를 먼저 삭제한 후 진행됩니다.
컨테이너 이미지 삭제
컨테이너를 삭제하기 전 이미지를 삭제할 경우 -f 옵션으로 컨테이너&이미지 동시 삭제
docker rmi -f [이미지 ID]
docker hub 로그인 방법
2.5.6. Linux 서버에 웹서버 구축
(1) ubuntu 설치 & 패키지 업데이트
(2) nginx 설치
(3) Nginx 확인
nginx를 패키지를 통하여 설치 하였기에 Default directory가 /etc/nginx 아래에 위치하게 됩니다.
직접 compile한 경우에 경로는 /usr/local/nginx/conf 혹은 /use/local/etc/nginx 에 위치합니다.
기본 경로 찾기
경로설정 (필요한 경우)
기본적인 환경 설정 파일 : sites-available/default
기본페이지 작성
2.5.7. Dockerfile을 통한 도커 이미지 생성
Docker File이란 Docker Image를 만들기 위한 여러가지 명령어의 집합
(1) Dockerfile 생성
3/Dockerfile
(2) Dockerfile 설명
(2) Dockerfile 명령어 상세설명
명렁어 | 내용 | 예시 |
|
|---|---|---|---|
FROM | 베이스 이미지를 지정해줍니다. | FROM <image>:<tag> |
|
베이스 이미지는 반드시 지정해야하며, 버전 정보는 latest보다는 구체적인 버전을 지정하는 것이 좋습니다.
RUN | 직접적으로 쉘 스크립트 내에서 실행 될 명령어 앞에 적어줍니다. | RUN <command> |
|
명령 수행을 위해 많이 쓰이는 명령어입니다.
CMD | 도커가 실행될 때 실행할 명령어를 정의해줍니다. | CMD [“executable”, “param”, “param”] |
|
도커 빌드시에는 실행되지 않으며, 여러개의 CMD 명령어가 존재할 경우 가장 마지막 명령어만 실행 됩니다. CMD nginx 라고 입력하면 nginx 서버를 구동시키게 됩니다.
WORKDIR | 이후 명령어가 작업할 디렉토리로 이동합니다 | WORKDIR /path |
|
명령어(RUN, CMD ) 등이 실행될 디렉토리를 설정합니다. 각 명령어는 줄마다 초기화가 되기 때문에 ‘RUN cd /path’ 로 경로를 잡아줘도 다음줄에선 다시 위치가 초기화가 됩니다. 같은 디렉토리에서 계속 작업하기 위하여 WORKDIR을 사용해줍니다.
COPY | 파일이나 디렉토리를 이미지로 복사합니다 | COPY <src> <dst> | COPY . /usr/src/app |
일반적으로 소스를 복사하는데 사용합니다
ADD | COPY와 비슷하게 복사를 위해 사용합니다 | ADD <src> <dst> | ADD . /usr/src/app |
COPY명령어와 비슷하게 소스를 복사하는데 사용하지만 차이점은 ADD 같은경우 압축파일이 있을 경우 자동으로 압축을 해제하면서 복사됩니다.
EXPOSE | – 공개 하고자 하는 포트를 지정해줍니다 | EXPOSE <port> |
|
호스트와 연결해줄 포트를 지정해주며, 여러개의 포트를 지정할 수 있습니다.
이 밖에 사용되는 ENV , VOLUME 같은 명령어는 공식문서 를 참고 바랍니다
2.5.8. 이미지 Build
(1) 작성한 Dockerfile을 빌드합니다.
–force-rm : 기존에 존재하는 image를 삭제합니다.
–tag : 태그를 설정해줍니다.
(2) 빌드된 이미지를 확인합니다.
(3) 빌드과정을 살펴봅니다.
[1] Sending build context to Docker daemon 17.41kB
도커는 서버 클라이언트 구조이기 때문에 작업할 도커파일들(build context)을 도커서버(daemon)으로 전송해줍니다.
[2] Step 1/7 : FROM ubuntu:20.04
빌드할 도커파일의 제일 윗줄부터 한줄한줄 실행하여 줍니다.
[3] 20.04: Pulling from library/ubuntu
ubuntu라는 이미지를 repository에서 다운받는 작업을 합니다 기본적으로 DockerHub Repository를 사용하고 있으며 사용자가 별도의 저장소를 지정할 수 있습니다.
[4] ---> 6df894023726
다운받은 ubuntu 이미지의 ID를 출력해줍니다.
[5] Step 2/7 : MAINTAINER Hojin kim "khoj@osci.kr""
도커파일의 두번째 명령어를 실행해줍니다.
[6] ---> Running in b568cf60d414
도커는 이미지 형태로 저장하기 때문에 바로위에서 실행한 우분투 이미지 ‘6df894023726’를 기반으로 임시 컨테이너 ‘b568cf60d414’ 를 만듭니다.
[7],[8]Removing intermediate container b568cf60d414 ---> 7f72532b3e72
임시로 실행했던 컨테이너 ‘b568cf60d414’를 삭제해주고 새로운 이미지 ‘7f72532b3e72’를 만듭니다.
[9] Step 3/7 : RUN apt update
도커파일에 작성하였던 다음줄의 명령어를 실행해줍니다. 이전 단계 에서처럼 _전에 만들어진 이미지를 기반으로 임시 컨테이너를 만들어 명령어를 실행하고 이를 또 다른 이미지로 저장을 한 후 임시 컨테이너는 삭제_하여줍니다. 이러한 과정을 도커파일의 마지막 명령줄까지 반복합니다.
[10] successfully built 03de8991a4f8
최종적으로 만들어진 이미지ID를 출력해줍니다.
같은 Dockerfile을 재빌드하면 처음 빌드했을 때 보다 빠르게 수행합니다.
명령어를 실행할 때 이미지 위에 레이어를 추가하는 형태로 저장하고, 기존에 저장된 이미지를 그대로 캐시처럼 사용하여 빌드합니다.
이러한 도커빌드 원리를 이해하고 있으면 도커파일을 만들 때 효과적으로 만들 수 있으며, history 확인이 가능합니다.
참고로 명렁어를 주르륵 나열하기보단 최대한 간결하고 ‘&&’ 명령어를 이용해 줄여서 적어주는것이 좋습니다! (스토리지 엔진에 따라 이미지 개수가 제한되는 경우도 있기때문)
2.5.9. 이미지 태그
(1) 이미지 이름 구조
저장소 주소는 기본적으로 Docker hub를 바라보고 있고, 사용자 ID를 지정해주지 않으면 기본으로 library를 사용합니다.
docker pull 명령어 시, 모두 같은 동작을 의미합니다.
<저장소 주소, 사용자명>/<이미지이름>:<태그>
library/nginx
nginx
(2) 이미지 이름 변경
실제로는 이미지 이름 변경이 아닌 새로운 이름을 추가, 복제하는 방식입니다.
docker tag <reponame>:<old_name> <new_reponame>:<new_name>
성능이슈가 발생할수 있으므로, vagrant를 halt 시켜놓는다.
3. 컨테이너 Orchestration
Container Orchestration은 애플리케이션을 구성하고 있는 수십 또는 수백 개의 컨테이너와 호스트들을 배포하고 관리하기 위한 도구입니다.
컨테이너 Orchestration은 어떤 환경에서든 사용할 수 있으며, 재설계할 필요 없이 각기 다른 환경 전반에 동일한 애플리케이션을 배포하는데 도움이 됩니다.
3.1 컨테이너 Orchestration 종류
Kubernetes | Docker Swarm | Apache Mesos |
|---|---|---|
|
|
|
|
|
|
3.2 컨테이너 Orchestration의 활용
컨테이너 프로비저닝 및 배포
컨테이너 구성 및 스케쥴링 조정
컨테이너 상태 모니터링 및 장애 복구
컨테이너 추가 또는 제거로 확장 및 축소
실행될 컨테이너를 기반으로 애플리케이션 설정
컨테이너 간 상호 작용의 보안 유지
4. 쿠버네티스
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 오케스트레이션 도구입니다.
4.1 쿠버네티스를 구성하는 3가지 방법
(1) 관리형 쿠버네티스
퍼블릭 클라우드 업체에서 제공하는 관리형 쿠버네티스
구성이 이미 갖춰져 있고 마스터 노드는 클라우드 업체에서 관리합니다.
사용자는 필요한 부분들을 애플리케이션에 올려놓고 애플리케이션을 배포하여 사용하는 형태입니다.
예시: EKS(Amazon Elastic Kubernetes Service), AKS(Azure Kubernetes Service), GKE(Google Kubernetes Service)
(2) 설치형 쿠버네티스
SUSE, Redhat와 같은 플랫폼에서 패키지화된 쿠버네티스를 제공하는 설치형 쿠버네티스
직접 설치할 수 있도록 패키지화된 쿠버네티스를 제공합니다.
예시: Rancher, RedHat OpenShift
(3) 구성형 쿠버네티스
사용하는 시스템에 쿠버네티스 클러스터를 자동으로 구성하는 방법입니다.
관리형/설치형 쿠버네티스 보다 자유롭게 구성 가능합니다.
예시: kubeadm, kops(Kubernetes operations), KRIB(Kubernetes Rebar Integrated Bootstrap), Kuberspray
4.2 쿠버네티스에서 제공하는 기능
(1)서비스 디스커버리와 로드밸런싱
쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있습니다.
트래픽이 많아지면, 자동으로 네트워크 트래픽을 로드밸런싱하여 배포가 안정적으로 이루어질 수 있도록 합니다.
(2) 스토리지 오케스트레이션
로컬 저장소, 공용 클라우드 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있습니다.
(3) 자동화된 롤아웃과 롤백
롤아웃: 새로운 버전의 애플리케이션을 배포할 때, 이전 버전과 새로운 버전을 비교하여 설정한 속도에 따라 변경(전환) 할 수 있습니다.
롤백: 배포 중 문제가 발생하거나, 이전 버전으로 되돌아가야할 때, 롤백을 지원합니다.
롤아웃과 롤백은 이벤트 로그를 자동으로 기록하며, 추적이 가능합니다. 하여 이를 통해 배포 이력을 관리 할 수 있습니다.
(4) 자동화된 빈 패킹
컨테이너화된 작업을 실행하는데 사용할 수 있는 클러스터 노드를 제공합니다.
(5) 시크릿과 구성 관리
시크릿된 정보들은 암호화되어 저장됩니다.
시크릿과 애플리케이션 구성을 안전하게 배포하고 업데이트할 수 있습니다.
(6) 자동화된 복구
오류가 발생하거나 노드가 죽었다면, 컨테이너를 재시작하고 다시 스케줄링합니다.
(7) 배치 실행
배치(일괄적으로 모아서 한 번에 처리하는 것) 단위의 작업을 실행할 수 있도록 하며, 주기적인 배치 작업도 실행할 수 있습니다.
(8) Auto Scailing
CPU 사용률이나 애플리케이션이 제공하는 Metric을 모니터링하여 애플리케이션에서 실행되는 인스턴스의 수를 조정할 수 있습니다.
CPU 사용율을 기반(HPA, horizontal Pod Autoscaling)으로 인스턴스 수를 자동 조절 할 수 있으며, POD의 CPU와 메모리 사용량 기반(VPA, Vertical Pod Autoscaling)으로 인스턴스를 조정할 수 있습니다.