모든 강의 이미지 출처는 [인프런] 쿠버네티스 어나더 클래스(지상편) - Spring 1,2 입니다.
Section 15. ArgoCD 빠르게 레벨업
CI/CD 파이프라인을 구성할 때 고려해야하는 요소
운영 정책
- 관리 편의를 우선으로 할 것인지, 장애 영향도를 우선으로 할 것인지에 따라 Argo CD를 환경별로 구축할 수도, 아니면 하나의 Argo CD만 구축할 수도 있다.
CI/CD Tool
- 온라인 : Github Actions
- 오프라인 : Jenkins, Jenkins X, TEKTON
CI Tool
- 온라인 : Travis CI, Circle CI
- 오프라인 : GitLab
CD Tool
- 온라인 : (-)
- 오프라인 : Argo CD, Spinnaker
CI/CD Tool 모두 회사의 보안정책이나, 상황에 따라 온라인/오프라인에 적합한 도구를 선택해야 한다. 또한, 레퍼런스가 많고 유지보수가 편한 기술을 선택하는 것이 좋다.
배포 전략을 구성할 때 고려해야하는 요소
Recreate
- 배포 시나리오 : DB 스키마 변경 시
- 서비스 중단 공지 -> Deployment Replicas 0으로 변경 -> DB 작업 -> Deployment 태그 변경 및 Replicas 2로 수정
- 특징
- 다운 타임이 발생한다.
- 트래픽 제어가 불가능하다.
RollingUpdate
- 배포 시나리오 : DB 스키마 변경 시
- 서비스 중단 공지 -> Deployment Replicas 0으로 변경 -> DB 작업 -> Deployment 태그 변경 및 Replicas 2로 수정
- 특징
- 다운 타임이 발생한다.
- 트래픽 제어가 불가능하다.
Blue/Green
- 배포 시나리오 : 운영환경에서만 테스트가 가능한경우
- 신규 Pod를 가리키는 신규 Service를 통해 QA 담당자가 테스트를 진행
- 테스트가 완료되고 기능에 문제가 없으면 기존 Service도 신규 Pod를 가리키도록 수정
- 특징
- 수동 배포 시 롤백이 빠르다
- v2 서비스에 과도한 트래픽이 유입되면 문제가 발생할 수 있다.
Canary
- 배포 시나리오 : 특정 헤더 값에 한해서만 신규 Pod로 트래픽 유입
- 특징
- A/B 테스트, 기존/신규 버전에 트래픽 비율을 조정하며 테스트 가능(w. istio)
[미션] Docker 이미지 복사
- Docker Hub에는 IP 기반으로 6시간 동안 100번 다운받을 수 있는 제한이 있다. (로그인한 유저는 200번)
- 회사에서 작업을 할 경우에는, 여러 명이 도커 이미지를 다운받을 수 있기 때문에 종종 요청량을 넘어
Too May Request에러와 만나게 된다. - 이러한 문제를 해결하기 위해 기업 PC 혹은 VM에 컨테이너 이미지를 복사하여 이를 사용하게 한다.
- docker를 통해서 업로드된 이미지를 파일로 변환하고 containerd 이미지로 변환하는 방법을 연습해보자.
▶ docker 이미지 생성 및 파일로 변환
# 1. Dockerfile 을 기반으로 docker 이미지 생성
[root@cicd-server ~] docker build -t <My-DockerHub-Name>/hello:1.0.0 .
# 2. 생성된 docker 이미지 조회
[root@cicd-server ~] docker image list
# 3. 2.0.0 버전의 태그 생성
[root@cicd-server ~] docker tag zxd46/hello:1.0.0 zxd46/hello:2.0.0
# 4-1. DockerHub 계정으로 로그인
[root@cicd-server ~] docker login -u zxd46
# 4-2. DockerHub에 이미지 push
[root@cicd-server ~] docker push zxd46/hello:1.0.0
# 5. 로컬 환경에 있는 이미지 삭제
[root@cicd-server ~] docker rmi zxd46/hello:1.0.0
# 6. DockerHub에서 이미지 다운로드
[root@cicd-server ~] docker pull zxd46/hello:1.0.0
# 7. 이미지를 file.tar 파일로 변환
[root@cicd-server ~] docker save -o file.tar zxd46/hello:1.0.0
# 8. file.tar 파일을 이미지로 변환
[root@cicd-server ~] docker load -i file.tart▶ 결과
▶ containerd 이미지 생성 및 파일로 변환
# 1. 네임스페이스 목록 조회
[root@k8s-master ~] ctr ns list
# 2. k8s.io 네임스페이스 이미지 목록 조회
[root@k8s-master ~] ctr -n k8s.io image list
# 3. default 네임스페이스에 컨테이너 이미지 다운로드
[root@k8s-master ~] ctr images pull docker.io/zxd46/hello:1.0.0
# 4. 2.0.0 버전의 태그 생성
[root@k8s-master ~] ctr images tag docker.io/zxd46/hello:1.0.0 docker.io/zxd46/hello:2.0.0
# 5. DockerHub에 이미지 push
[root@k8s-master ~] ctr image push docker.io/zxd46/hello:2.0.0 --user zxd46
# 6. 이미지를 file.tar 파일로 변환
[root@k8s-master ~] ctr -n default image export file.tar docker.io/zxd46/hello:1.0.0
# 7. file.tar 파일을 이미지로 변환
[root@k8s-master ~] ctr -n k8s.io image import file.tar
# 8. k8s.io 네임스페이스에서 이미지 삭제
[root@k8s-master ~] ctr -n k8s.io image remove docker.io/zxd46/hello:1.0.0▶ 결과
[미션] 같은 이미지를 도커에서 받았을 때와 쿠버네티스에서 받았을 때 사이즈가 다른 이유
Docker Hub에서 이미지 크기를 확인했을 때는 247.49MB인 것을 확인할 수 있다.
하지만 docker pull 명령어를 통해 이미지를 다운받았을 때는 520MB로 훨씬 커진 것을 확인할 수 있다.
이미지의 크기가 커진 이유에 대해서 여러 가정을 세워보고 확인을 해보자.
가정 1) Container Image를 만들 때 플랫폼(amd64, arm64)을 고려해야 되는데, Docker에서는 amd64를 받았고, Kuberentes에서 arm64를 받아서 이미지 크기가 달라졌을 것이다.
▶ docker pull 로 받은 이미지 정보 조회
[root@cicd-server ~] docker image inspect zxd46/api-tester:v1.0.0▶ 결과 (arm64로 Docker Hub와 동일함)
▶ 결론: 아님.
가정 2) Container 이미지는 각각의 Layer로 구성돼 있는데, Docker에서 다운 받을 때는 전체 Layer를 받았고, Kubernetes에는 기존 이미지에 이미 존재하는 Layer가 있기 때문에 새로 받은 이미지의 Size가 작게 조회 됐을 것이다.
Kubernetes에는 기존 이미지에 Layer가 이미 존재한다면 docker pull 시에 가져오는 이미지가 더 작아야하는 게 맞겠지만, 반대로 커졌기 때문에 말이 안된다.
(그래도 해보는 예제)
▶ docker image를 tar 파일로 변환 후 Master Node로 복사
▶ Master Node에서 이미지가 존재하지 않음을 확인하고. tar 파일을 다시 이미지로 변환해도 크기는 거의 동일함.
▶ 결론: 아님.
가정 3) 쿠버네티스에는 다른 Runtime을 사용 했을 수 있고, 같은 이미지더라도 사용하는 Runtime에 따라서 이미지의 크기는 달라질 것이다.
▶ 현재 쿠버네티스는 기본 컨테이너 런타임으로 Containerd를 사용하고 있다. docker는 실제 이미지 크기에서 여러 도커 기능들과 메타데이터 규격에 맞는 데이터들을 추가해 이미지를 재구성하기 때문에 Containerd 이미지보다 더 큰 크기를 갖게된다.
따라서, Containerd를 사용하는 쿠버네티스 환경에서 Docker로 받은 이미지를 복사하는 경우 불필요하게 큰 이미지를 사용하게 된다.
▶ 결론: 맞다. containerd를 사용하는 환경에서는 Docker로 만들어진 이미지를 그대로 사용하면 불필요한 사이즈를 사용하게 되니 주의하자.
