목차
01 도커란?
1.1 가상 머신과 도커 컨테이너
1.2 도커를 시작해야 하는 이유
1.2.1 애플리케이션의 개발과 배포가 편해집니다.
1.2.2 여러 애플리케이션의 독립성과 확장성이 높아집니다.
1.3 도커 엔진 설치
1.3.1 도커 엔진의 종류 및 버전
1.3.2 리눅스 도커 엔진 설치
우분투 18.04, 20.04
CentOs 7, RHEL 7
1.3.3 윈도우, 맥 OS에 도커 설치
1.3.3.1 Docker Desktop for Windows 설치
1.3.3.2 Docker Desktop for Mac 설치
1.3.4 리눅스 환경에 도커 마련하기
1.3.4.1 버추얼박스, VMWare
1.3.4.2 아마존 웹 서비스 EC2
02 도커 엔진
2.1 도커 이미지와 컨테이너
2.1.1 도커 이미지
2.1.2 도커 컨테이너
2.2 도커 컨테이너 다루기
2.2.1 컨테이너 생성
2.2.2 컨테이너 목록 확인
2.2.3 컨테이너 삭제
2.2.4 컨테이너를 외부에 노출
2.2.5 컨테이너 애플리케이션 구축
2.2.6 도커 볼륨
2.2.6.1 호스트 볼륨 공유
2.2.6.2 볼륨 컨테이너
2.2.6.3 도커 볼륨
2.2.7 도커 네트워크
2.2.7.1 도커 네트워크 구조
2.2.7.2 도커 네트워크 기능
브리지 네트워크
호스트 네트워크
논 네트워크
컨테이너 네트워크
브리지 네트워크와 --net-alias
MacVLAN 네트워크
2.2.8 컨테이너 로깅
2.2.8.1 json-file 로깅 사용하기
2.2.8.2 syslog 로그
2.2.8.3 fluentd 로깅
2.2.8.4 아마존 클라우드워치 로그
1. 클라우드워치에 해당하는 IAM 권한 생성
2. 로그 그룹 생성
3. 로그 그룹에 로그 스트림 생성
4. 클라우드워치의 IAM 권한을 사용할 수 있는 EC2 인스턴스 생성과 로그 전송
2.2.9 컨테이너 자원 할당 제한
2.2.9.1 컨테이너 메모리 제한
2.2.9.2 컨테이너 CPU 제한
--cpuset-cpus
--cpu-period, --cpu-quota
--cpus
2.2.9.3 Block I/O 제한
2.2.9.4 스토리지 드라이버와 컨테이너 저장 공간 제한
2.3 도커 이미지
2.3.1 도커 이미지 생성
2.3.2 이미지 구조 이해
2.3.3 이미지 추출
2.3.4 이미지 배포
2.3.4.1 도커 허브 저장소
이미지 저장소(Repository) 생성
저장소에 이미지 올리기
조직, 팀 생성
저장소 웹훅(Webhook) 추가
2.3.4.2 도커 사설 레지스트리
사설 레지스트리 컨테이너 생성
사설 레지스트리에 이미지 Push하기
Nginx 서버로 접근 권한 생성
사설 레지스트리 RESTful API
사설 레지스트리에 옵션 설정
2.4 Dockerfile
2.4.1 이미지를 생성하는 방법
2.4.2 Dockerfile 작성
2.4.3 Dockerfile 빌드
2.4.3.1 이미지 생성
2.4.3.2 빌드 과정 살펴보기
빌드 컨텍스트
Dockerfile을 이용한 컨테이너 생성과 커밋
캐시를 이용한 이미지 빌드
2.4.3.3 멀티 스테이지를 이용한 Dockerfile 빌드하기
2.4.4 기타 Dockerfile 명령어
2.4.4.1 ENV, VOLUME, ARG, USER
2.4.4.2 Onbuild, Stopsignal, Healthcheck, Shell
2.4.4.3 ADD, COPY
2.4.4.4 ENTRYPOINT, CMD
ENTRYPOINT와 CMD의 차이점
entrypoint를 이용한 스크립트 실행
JSON 배열 형태와 일반 형식의 차이점
2.4.5 Dockerfile로 빌드할 때 주의할 점
2.5 도커 데몬
2.5.1 도커의 구조
2.5.2 도커 데몬 실행
2.5.3 도커 데몬 설정
2.5.3.1 도커 데몬 제어: -H
2.5.4.2 도커 데몬에 보안 적용: --tlsverify
1. 서버 측 파일 생성
2. 클라이언트 측에서 사용할 파일 생성
2.5.3.3 도커 스토리지 드라이버 변경: --storage-driver
스토리지 드라이버의 원리
AUFS 드라이버 사용하기
Devicemapper 드라이버 사용하기
OverlayFS 드라이버 사용하기
Btrfs 드라이버 사용하기
ZFS 드라이버 사용하기
2.5.3.4 컨테이너 저장 공간 설정
devicemapper에서의 컨테이너 저장 공간 설정
overlay2에서의 컨테이너 저장 공간 설정
2.5.4 도커 데몬 모니터링
2.5.4.1 도커 데몬 디버그 모드
2.5.4.2 events, stats, system df 명령어
events
stats
system df
2.5.4.3 CAdvisor
2.5.5 파이썬 Remote API 라이브러리를 이용한 도커 사용
03 도커 스웜
3.1 도커 스웜을 사용하는 이유
3.2 스웜 모드
3.2.1 도커 스웜 모드의 구조
3.2.2 도커 스웜 모드 클러스터 구축
3.2.3 스웜 모드 서비스
3.2.3.1 스웜 모드 서비스 개념
3.2.3.2 서비스 생성
첫 번째 서비스 생성해보기
nginx 웹 서버 서비스 생성하기
global 서비스 생성하기
3.2.3.3 스웜 모드의 서비스 장애 복구
3.2.3.4 서비스 롤링 업데이트
3.2.3.5 서비스 컨테이너에 설정 정보 전달하기: config, secret
secret 사용하기
config 사용하기
3.2.3.6 도커 스웜 네트워크
ingress 네트워크
오버레이 네트워크
docker_gwbridge 네트워크
사용자 정의 오버레이 네트워크
3.2.3.7 서비스 디스커버리
3.2.3.8 스웜 모드 볼륨
volume 타입의 볼륨 생성
bind 타입의 볼륨 생성
스웜 모드에서 볼륨의 한계점
3.2.4 도커 스웜 모드 노드 다루기
3.2.4.1 노드 AVAILABILTY 변경하기
Active
Drain
Pause
3.2.4.2 노드 라벨 추가
노드 라벨 추가하기
서비스 제약 설정
1) node.labels 제약조건
2) node.id 제약조건
3) node.hostname과 node.role 제약조건
4) engine.labels 제약조건
04 도어 컴포즈
4.1 도커 컴포즈를 사용하는 이유
4.2 도커 컴포즈 설치
4.3 도커 컴포즈 사용
4.3.1 도커 컴포즈 기본 사용법
4.3.1.1 docker-compose.yml 작성과 활용
4.3.1.2 도커 컴포즈의 프로젝트, 서비스, 컨테이너
4.3.2 도커 컴포즈 활용
4.3.2.1 YAML 파일 작성
(1) 버전 정의
(2) 서비스 정의
(3) 네트워크 정의
(4) 볼륨 정의
(5) YAML 파일 검증하기
4.3.2.2 도커 컴포즈 네트워크
4.3.2.3 도커 스웜 모드와 함께 사용하기
스택 사용하기
스택 네트워크
4.4 도커 학습을 마치며: 도커와 컨테이너 생태계
05 쿠버네티스 설치
5.1 쿠버네티스 설치 환경의 종류
5.2 쿠버네티스 버전 선택
5.3 개발 용도의 쿠버네티스 설치
5.3.1 Docker Desktop for Mac / Windows에서 쿠버네티스 사용
5.3.2 Minikube로 쿠버네티스 설치
기본 설정을 이용해 버추얼 박스로 minikube 설치
1. 버추얼박스 설치
2. minikube, kubectl 내려받기
3. minikube 가상 머신 설치
리눅스 서버에서 가상 머신없이 도커 엔진만으로 minikube 설치
5.4 여러 서버로 구성된 쿠버네티스 클러스터 설치
5.4.1 kubeadm으로 쿠버네티스 설치
1.쿠버네티스 저장소 추가
2. containerd 및 kubeadm 설치
3. 쿠버네티스 클러스터 초기화
4. 컨테이너 네트워크 애드온 설치
5.4.2 kops로 AWS에서 쿠버네티스 설치
1. kops 및 kubectl 실행 바이너리 내려받기
2. AWS 사용자 생성, 정책 연결 및 AWS CLI 설정
3. S3 버킷에 쿠버네티스 클러스터의 설정 정보 저장
4. 쿠버네티스 클러스터 옵션 변경
5. 쿠버네티스 클러스터 생성
5.4.3 구글 클라우드 플랫폼의 GKE로 쿠버네티스 사용하기
1.가상 머신 클러스터 생성
2. 쿠버네티스 클러스터에 연결
GKE 웹 사이트에서 kubectl 명령어 사용하기
클러스터에 연결
개인 터미널에서 kubectl 명령어 사용하기
06 쿠버네티스 시작하기
6.1 쿠버네티스를 시작하기 전에
모든 리소스는 오브젝트 형태로 관리됩니다.
쿠버네티스는 명령어로도 사용할 수 있지만, YAML 파일을 더 많이 사용합니다.
쿠버네티스는 여러 개의 컴포넌트로 구성돼 있습니다.
6.2 파트(Pod): 컨테이너를 다루는 기본 단위
6.2.1 파드 사용하기
6.2.2 파드 vs. 도커 컨테이너
6.2.3 완전한 애플리케이션으로서의 파드
6.3 레플리카셋(Replica Set): 일정 개수의 파드를 유지하는 컨트롤러
6.3.1 레플리카셋을 사용하는 이유
6.3.2 레플리카셋 사용하기
6.3.3 레플리카셋의 동작 원리
6.3.4 레플리케이션 컨트롤러 vs. 레플리카셋
6.4 디플로이먼트(Deployment): 레플리카셋, 파드의 배포를 관리
6.4.1 디플로이먼트 사용하기
6.4.2 디플로이먼트를 사용하는 이유
리소스 정리
6.5 서비스(Service): 파드를 연결하고 외부에 노출
6.5.1 서비스(Service)의 종류
6.5.2 ClusterIP 타입의 서비스 - 쿠버네티스 내부에서만 파드에 접근하기
6.5.3 NodePort 타입의 서비스 - 서비스를 이용해 파드를 외부에 노출하기
6.5.4 클라우드 플랫폼의 로드 밸런서와 연동하기 - LoadBalancer 타입의 서비스
온프레미스 환경에서 LoadBalancer 타입의 서비스 사용하기
6.5.5 트래픽의 분배를 결정하는 서비스 속성: externalTrafficPolicy
6.5.6 요청을 외부로 리다이렉트하는 서비스: ExternalName
리소스 정리
07 쿠버네티스 리소스의 관리와 설정
7.1 네임스페이스(Namespace): 리소스를 논리적으로 구분하는 장벽
네임스페이스 기본 개념 이해
네임스페이스 사용하기
네임스페이스의 서비스에 접근하기
네임스페이스에 종속되는 쿠버네티스 오브젝트와 독립적인 오브젝트
7.2 컨피그맵(Configmap), 시크릿(Secret): 설정값을 파드에 전달
7.2.1 컨피그맵(Configmap)
컨피그맵 사용 방법 익히기
컨피그맵의 값을 컨테이너의 환경 변수로 사용
컨피그맵의 값을 파드 내부의 파일로 마운트해 사용
컨피그맵의 데이터를 컨테이너의 환경 변수로 가져오기
컨피그맵의 내용을 파일로 파드 내부에 마운트하기
파일로부터 컨피그맵 생성하기
YAML 파일로 컨피그맵 정의하기
7.2.2 시크릿(Secret)
시크릿 사용 방법 익히기
이미지 레지스트리 접근을 위한 docker-registry 타입의 시크릿 사용하기
TLS 키를 저장할 수 있는 tls 타입의 시크릿 사용하기
좀 더 쉽게 컨피그맵과 시크릿 리소스 배포하기
컨피그맵이나 시크릿을 업데이트해 애플리케이션의 설정값 변경하기
리소스 정리
08 인그레스(Ingress)
8.1 인그레스를 사용하는 이유
8.2 인그레스의 구조
인그레스 컨트롤러의 동작 원리 이해
8.3 인그레스의 세부 기능: annotation을 이용한 설정
8.4 Nginx 인그레스 컨트롤러에 SSL/TLS 보안 연결 적용
8.5 여러 개의 인그레스 컨트롤러 사용하기
리소스 정리
09 퍼시스턴트 볼륨(PV)과 퍼시스턴스 볼륨 클레임(PVC)
9.1 로컬 볼륨: hostPath, emptyDir
9.1.1 워커 노드의 로컬 디렉터리를 볼륨으로 사용: hostPath
9.1.2 파드 내의 컨테이너 간 임시 데이터 공유: emptyDir
9.2 네트워크 볼륨
NFS를 네트워크 볼륨으로 사용하기
9.3 PV, PVC를 이용한 볼륨 관리
9.3.1 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임을 사용하는 이유
9.3.2 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임 사용하기
AWS에서 EBS를 퍼시스턴트 볼륨으로 사용하기
9.3.3 퍼시스턴트 볼륨을 선택하기 위한 조건 명시
accessModes와 볼륨 크기, 스토리지 클래스, 라벨 셀렉터를 이용한 퍼시스턴트 볼륨 선택
9.3.4 퍼시스턴트 볼륨의 라이프사이클과 Reclaim Policy
9.3.5 StorageClass와 Dynamic Provisioning
다이나믹 프로비저닝과 스토리지 클래스
AWS에서 다이나믹 프로비저닝 사용하기
다이나믹 프로비저닝에서 특정 스토리지 클래스를 기본값으로 사용
리소스 정리
10 보안을 위한 인증과 인가: ServiceAccount와 RBAC
10.1 쿠버네티스의 권한 인증 과정
10.2 서비스 어카운트와 롤(Role), 클러스터 롤(Cluster Role)
롤 vs. 클러스터 롤
여러 개의 클러스터 롤을 조합해서 사용하기
10.3 쿠버네티스 API 서버에 접근
10.3.1 서비스 어카운트의 시크릿을 이용해 쿠버네티스 API 서버에 접근
10.3.2 클러스터 내부에서 kubernetes 서비스를 통해 API 서버에 접근
10.3.3 쿠버네티스 SDK를 이용해 파드 내부에서 API 서버에 접근
10.4 서비스 어카운트에 이미지 레지스트리 접근을 위한 시크릿 설정
10.5 kubeconfig 파일에 서비스 어카운트 인증 정보 설정
10.6 유저(User)와 그룹(Group)의 생성
다양한 인증 방법에서의 User와 Group
10.7 x509 인증서를 이용한 사용자 인증
11 애플리케이션 배포를 위한 고급 설정
11.1 파드의 자원 사용량 제한
11.1.1 컨테이너와 파드의 자원 사용량 제한: Limits
11.1.2 컨테이너와 파드의 자원 사용량 제한하기: Requests
11.1.3 CPU 자원 사용량의 제한 원리
쿠버네티스에서의 CPU Requests와 Limits
11.1.4 QoS 클래스와 메모리 자원 사용량 제한 원리
쿠버네티스에서의 메모리 부족과 OOM(Out Of Memory)
QoS 클래스의 종류 - (1) Guaranteed 클래스
QoS 클래스의 종류 - (2) BestEffort 클래스
QoS 클래스의 종류 - (3) Burstable 클래스
QoS 클래스와 메모리 부족
자원 오버커밋의 필요성
11.1.5 ResourceQuota와 LimitRange
11.1.5.1 ResourceQuota로 자원 사용량 제한
ResourceQuota로 리소스 개수 제한하기
ResourceQuota로 BestEffort 클래스의 파드 개수 제한하기
11.1.5.2 LimitRange로 자원 사용량 제한
11.1.6 ResourceQuota, LimitRange의 원리: Admission Controller
리소스 정리
11.2 쿠버네티스 스케줄링
11.2.1 파드가 실제로 노드에 생성되기까지의 과정
11.2.2 파드가 생성될 노드를 선택하는 스케줄링 과정
11.2.3 NodeSelector와 Node Affinity, Pod Affinity
nodeName과 nodeSeletor를 사용한 스케줄링 방법
Node Affinity를 이용한 스케줄링 방법
Pod Affinity를 이용한 스케줄링 방법
Pod Anti-affinity를 이용한 스케줄링 방법
11.2.4 Taints와 Tolerations 사용하기
Taints와 Tolerations를 이용한 파드 스케줄링
NoExecute와 TolerationSeconds
11.2.5 Cordon, Drain 및 PodDistributionBudget
cordon을 이용한 스케줄링 비활성화
drain 명령어로 노드 비활성화하기
PodDisruptionBudget으로 파드 개수 유지하기
11.2.6 커스텀 스케줄러 및 스케줄러 확장
커스텀 스케줄러 구현
쿠버네티스 스케줄러 확장하기
리소스 정리
11.3 쿠버네티스 애플리케이션 상태와 배포
11.3.1 디플로이먼트를 통해 롤링 업데이트
디플로이먼트를 이용한 레플리카셋의 버전 관리
디플로이먼트를 통한 롤링 업데이트 설정
블루 그린 배포 사용하기
11.3.2 파드의 생애 주기(Lifecycle)
11.3.2.1 파드의 상태와 생애 주기
Completed, Error와 restartPolicy
11.3.2.2 Running 상태가 되기 위한 조건
Running 상태가 되기 위한 조건 - Init 컨테이너
Running 상태가 되기 위한 조건 - postStart
11.3.2.3 애플리케이션의 상태 검사 - livenessProbe, readinessProbe, startupProbe
livenessProbe로 애플리케이션의 상태 검사
readinessProbe로 애플리케이션의 상태 검사하기
livenessProbe와 readinessProbe의 세부 옵션
11.3.2.4 Terminating 상태와 애플리케이션의 종료
리소스 정리
11.3.3 HPA를 활용한 오토스케일링
12 커스텀 리소스와 컨트롤러
12.1 쿠버네티스 컨트롤러의 개념과 동작 방식
명령형(Imperative) vs. 선언적(Declarative)
12.2 커스텀 리소스에 대한 개념
커스텀 리소스를 사용하기 위한 단계
12.3 커스텀 리소스를 정의하기 위한 CRD(Custom Resource Definition)
1. metadata.name :
2. spec.group, versions :
3. spec.names :
4. spec.validation
12.4 커스텀 리소스와 컨트롤러
13 파드를 사용하는 다른 오브젝트들
13.1 잡(Jobs)
잡의 세부 옵션
크론잡(CronJobs)으로 잡을 주기적으로 실행하기
13.2 데몬셋(DaemonSets)
13.3 스테이트풀셋(StatefulSets)
스테이트풀셋 사용하기
스테이트풀셋과 퍼시스턴트 볼륨
리소스 정리
14 쿠버네티스 모니터링
14.1 모니터링 기본 구조
14.2 모니터링 메트릭의 분류
14.3 쿠버네티스 모니터링 기초
14.3.1 metrics-server
14.3.2 metrics-server 동작 원리: APIService 리소스
14.3.3 kube-state-metrics
14.3.4 node-exporter
14.4 프로메테우스를 활용한 메트릭 수집
14.4.1 프로메테우스 설치
14.4.2 프로메테우스로 메트릭 수집하기
14.4.3 그라파나로 프로메테우스 메트릭 시각화하기
부록 A _ 도커 데몬 시작 옵션 변경하기
(1) 도커 데몬 서비스 파일 변경하기
우분투 14.04
우분투 16.04, 18.04, CentOS 7, Raspbian Stretch: 라즈비안 스트레치
Docker Desktop for Windows
Docker Desktop for Mac
(2) daemon.json 파일 작성하기
부록 B _ 특정 버전의 도커 설치하기
(1) 바이너리 파일을 직접 내려받기
(2) apt, yum 저장소에서 설치하기
도커 리포지터리 추가
우분투
CentOS
라즈베리 파이 3 - 라즈피안 스트레치 (Stretch)
부록 C _ gcloud 명령어 설치하기
부록 D _ AWS CLI 설치하기
질문
그렇다면 호스트에 이미 디렉터리와 파일이 존재하고 컨테이너에도 존재할 때 두 디렉터리를 공유하면 어떻게 될까요?
그렇다면 --cpu-shares의 값이 512로 설정된 컨테이너가 같이 실행된다면 어떻게 될까요?
컨테이너에서 작업을 마치고 이미지로 커밋하면 되지 않느냐?
test,htm?
?
위 Dockerfile로 빌드한 이미지의 크기는 어떻게 될까요?
그렇다면 도커는 실제로 어디에 있는 걸까요?
CAdvisor는 이렇게 많은 정보를 어떻게 사용자에게 보여줄 수 있는 것일까요?
하나의 호스트 머신에서 도커 엔진을 구동하다가 CPU나 메모리, 디스크 용량과 같은 자원이 부족하면 이를 어떻게 해결할까요?
그렇다면 서비스 내의 Nginx 컨테이너를 4개로 늘리면 어떻게 될까요?
그렇다면 스웜 클러스터 내의 컨테이너가 할당받는 IP 주소는 어떻게 설정돼 있을까요?
이때 서비스 A의 컨테이너는 어떻게 서비스 B의 새로운 컨테이너에 접근할 수 있을까요?
그렇다면 server라는 서비스 이름은 어떻게 각 컨테이너의 IP로 변환된 것일까요?
Nginx 웹 서비스를 쿠버네티스에서 생성하려면 컨테이너와 파드를 어떻게 사용할 수 있을까요?
그렇다면 쿠버네티스는 왜 '도커 컨테이너'가 아니라 굳이 '파드'라는 새로운 개념을 사용하는 것일까요?
그러나 Nginx 컨테이너가 실행되기 위해 부가적인 기능을 필요로 한다면 어떨까요?
그러나 YAML에 파드만 정의해 생성하게 되면 이 파드의 생애 주기(Lifecycle)은 어떻게 될까요?
그렇다면 동일한 여러 개의 파드를 어떻게 생성할 수 있을까요?
그렇다면 app: my-nginx-pods-label 라벨을 가지는 파드를 미리 생성해 놓은 다음, 위의 레플리카셋을 생성하면 어떻게 될까요?
그렇다면 수동으로 생성한 파드를 삭제하면 어떻게 될까요?
그렇다면 레플리카셋이 생성해 놓은 파드의 라벨을 삭제한다면 어떻게 될까요?
그렇다면 쿠버네티스는 왜 레플리카셋을 그대로 사용하지 않고 굳이 상위 개념인 디플로이먼트를 다시 정의해 사용하는 것일까요?
그 뒤에 레플리카셋의 목록을 출력해보면 무엇이 출력될까요?
그렇다면 PORT(S) 항목에서 32620은 무엇을 의미할까요?
만약 아래와 같은 상황이라면 어떨까요?
그렇다면 퍼시스턴트 볼륨과 연결된 퍼시스턴트 볼륨 클레임을 삭제하면 어떻게 될까요?
여러분이 kubectl 명령어를 사용해 쿠버네티스의 기능을 실행하면 쿠버네티스 내부에서는 어떠한 일이 일어날까요?
그렇다면 쿠버네티스 클러스터 내부에서 실행되는 애플리케이션은 어떻게 API 서버에 접근하고 인증을 수행할 수 있을까요?
그렇다면 여기서 한 가지 문제가 생길 수 있는데, 컨테이너 A가 500MB를 사용하고 있을 때 컨테이너 B가 750MB를 사용하려 시도한다면 어떻게 될까요?
그렇다면 resources.requests.cpu를 설정해 CPU가 보장받아야 하는 최소한의 CPU 자원을 설정하면 컨테이너에서는 어떻게 설정될까요?
그렇지만 아래와 같이 두 개의 컨테이너가 CPU 자원을 최대로 사용하는 상태라면 어떨까요?
여러 개발팀이 쿠버네티스에서 개발 및 테스트를 진행해야 한다면 어떻게 쿠버네티스 환경을 제공하는 것이 좋을까요?
그렇다면 디플로이먼트를 통해 파드를 생성해 보면 어떨까요?
만약 토폴로지 키를 호스트 이름으로 지정하면 어떻게 될까요?
쿠버네티스에서 애플리케이션을 배포하려면 어떤 방법을 사용할 수 있을까요?
그렇다면 파드의 컨테이너가 0이 아닌 종료 코드를 반환하면 어떻게 될까요?
그렇다면 readinessProbe가 실패하면 어떻게 될까요?
그렇다면 만약 이 값을 3으로 설정하면 어떻게 될까요?
만약 이러한 상황에서 디플로이먼트에서 사용했던 일반적인 서비스를 스테이트풀셋에 사용하면 어떻게 될까요?
그렇다면 이 CAdvisor를 통해 어떻게 모니터링 데이터를 데이터베이스에 수집하고 시각화할 수 있을까요?
그렇다면 metrics-server는 어떠한 방식으로 메트릭을 모아서 사용자에게 보여줄 수 있는 것일까요?
그렇다면 metrics-server가 반환하는 메트릭은 어떠한 형태인지 확인해볼 수 있을까요?
그렇다면 metrics-server에서 사용하는 APIService 리소스는 어떤 내용을 담고 있을까요?
