SpringBoot 애플리케이션으로 도커 복습
- https://start.spring.io/에서 SpringBoot 웹 애플리케이션을 생성합니다.
프로젝트 생성 후 기본 URL에 Hello Docker! 를 출력하는 API 코드를 작성합니다.
localhost:8080에 접속하면 Hello Docker! 가 출력되는 것을 볼 수 있습니다.
STEP 1 : 컨테이너에 애플리케이션 배포하기
- 스프링 부트 애플리케이션을 JAR 파일로 생성
- 애플리케이션 빌드를 위해 IntelliJ IDE를 이용해 bootJar를 더블클릭합니다.
- docker/build에 libs 폴더가 생성됩니다.
- 내부에는 docker-0.0.1-SNAPSHOT.jar 파일이 생성됩니다.
- 생성된 JAR 파일을 통해 컨테이너에 배포docker run -p 8080:8080 -v /Users/사용자명/Downloads/docker/build/libs/docker-0.0.1-SNAPSHOT.jar:/app/docker.jar openjdk:11 java -jar /app/docker.jar
- p 옵션을 통해 로컬 8080 포트와 도커 컨테이너 8080 포트를 연결하게 됩니다.
- v 옵션을 사용하면 로컬 파일을 통해 컨테이너 쪽으로 디렉터리 또는 파일을 공유할 수 있습니다.
- jar 파일이 있는 로컬 절대 경로 /Users/사용자명/Downloads/docker/build/libs/docker-0.0.1-SNAPSHOT.jar:/app/docker.jar를 통해 컨테이너 내부에 /app/docker.jar 파일로 공유하게 됩니다.
- 도커 컨테이너 내부에는 Files에 app폴더와 docker.jar 파일이 생성됩니다.
- jar 파일이 있는 로컬 절대 경로 /Users/사용자명/Downloads/docker/build/libs/docker-0.0.1-SNAPSHOT.jar:/app/docker.jar를 통해 컨테이너 내부에 /app/docker.jar 파일로 공유하게 됩니다.
- MAC Terminal 명령어
[그림] (mac) Docker Desktop 4.20.1
- 실행
- openjdk:11 이미지를 사용해 컨테이너 내부에서 java -jar /app/docker.jar 명령어를 실행합니다.
- 로컬에서 localhost:8080에 접속하면 도커 컨테이너 8080 포트에 접속하여 Hello Docker!를 볼 수 있게 된다.
[그림] 도커 데스크톱 - 컨테이너 내부 jar 파일 실행 Log
[그림] 로컬에서 Hello Docker! 출력 결과
STEP 2 : 컨테이너를 바탕으로 도커 이미지 생성하기
STEP 1에서 만들었던 컨테이너를 도커 이미지로 생성하기 위해 Dockerfile을 만들어 줍니다.
// Dockerfile (root 폴더)
**FROM openjdk:11
COPY build/libs/*.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]**
Dockerfile을 통해 도커 이미지 빌드
docker build -t myimage:0.0.1 .
// 해당 이미지를 도커Hub이름/도커Repository이름:tag로 바꾸는 명령어
**docker tag myimage:0.0.1 도커Hub이름/도커Repository이름:tag**
빌드된 이미지를 통해 도커 컨테이너 실행
// (1)
docker run -p 8080:8080 myimage:0.0.1
// (2) 위에서 docker tag 통해 설정한 도커Hub이름/도커Repository이름:tag 입력
docker run -p 8080:8080 **도커Hub이름/도커Repository이름:tag**
STEP 3 : 도커 이미지를 도커 허브에 등록하기
우리가 만든 이미지를 도커 허브에 등록
docker push 사용자이름/도커Repository:tag
현재 만들어진 컨테이너 및 이미지 제거
// 컨테이너 확인
docker ps -a
// 컨테이너 제거
docker rm **컨테이너이름
//** 이미지 제거
docker image rm **도커Hub이름/도커Repository이름:tag**
docker image rm myimage:0.0.1
도커허브에 등록된 이미지를 가져와 mycontainer 이름으로 컨테이너 실행
// hub에서 이미지 가져오기
docker pull **도커Hub이름/도커Repository이름:tag
// 가져온 이미지로 컨테이너 실행
docker run -p 8080:8080 --name mycontainer 도커Hub이름/도커Repository이름:tag**
여러분들은 STEP 1 ~ STEP 3을 실습해 보면서 Jar 파일을 통해 컨테이너를 만들고 Dockerfile을 추가하여 이미지를 빌드해서 도커 허브에 저장 후 해당 이미지를 가져와 원하는 이름의 컨테이너로 만드는 연습을 해봤습니다.
다양한 도커 명령어들을 연습해 보며 도커를 이해할 수 있는 시간이 되었으면 좋겠습니다.
SpringBoot 애플리케이션 컨테이너로 동작하기
💡 도커 학습 내용을 바탕으로 아래 시나리오를 실습해 보세요.
- SpringBoot 애플리케이션 만들기
- Hello World를 출력하는 SpringBoot 웹 애플리케이션을 만듭니다.
- http://host:8080/test/hello 로 API 주소를 설정합니다.
- 위 내용을 포함하는 애플리케이션의 버전은 0.1입니다.
- 도커 이미지 저장소에 0.1 버전 생성
- SpringBoot 애플리케이션 0.1 버전을 도커 이미지로 만들고 도커 이미지 저장소에 등록합니다.
- 도커 이미지 저장소에 0.2 버전 생성
- SpringBoot 애플리케이션 0.1 버전에 아래 내용을 추가하여 0.2 버전으로 개선합니다.
- http://host:8080/test/member/1 에 해당하는 API를 작성합니다.
- 응답 json
- {”sabun” : 1, “name” : “hong gildong”, “dept_cd” : “CS001023004”, “dept_nm” : “컨테이너 실습”, “role_cd” : “EEF9852”, “role_nm” : “STUDENT”}
- H2(in-memory)로 간단한 테이블을 만들어도 되고 별도의 프로퍼티 파일을 생성하여 응답해도 됩니다. 난이도가 너무 높다면 응답 json 내용을 직접 명시해도 됩니다. 가능한 모든 방법을 동원하여 0.2 버전의 조건을 만족할 수 있게 자유롭게 개발합니다.
- SpringBoot 애플리케이션 0.2 버전을 도커 이미지로 만들고 도커 이미지 저장소에 등록합니다.
- SpringBoot 애플리케이션 0.1 버전에 아래 내용을 추가하여 0.2 버전으로 개선합니다.
- 도커 이미지 저장소에 0.3 버전 생성
- SpringBoot 애플리케이션 0.2 버전에 아래 내용을 추가하여 0.3 버전으로 개선합니다.
- http://host:8080/test/dept/1 에 해당하는 API를 작성합니다.
- 응답 json
- {”id” : 1, “dept_cd” : “CS001023004”, “dept_nm” : “컨테이너 실습”, “level” : 3, “rel_dept_cd” : “CS0010230000”, “rel_dept_nm” : “수강생대표팀”}
- H2(in-memory)로 간단한 테이블을 만들어도 되고 별도의 프로퍼티 파일을 생성하여 응답해도 됩니다. 난이도가 너무 높다면 응답 json 내용을 직접 명시해도 됩니다. 가능한 모든 방법을 동원하여 0.3 버전의 조건을 만족할 수 있게 자유롭게 개발합니다.
- SpringBoot 애플리케이션 0.3 버전을 도커 이미지로 만들고 도커 이미지 저장소에 등록합니다.
- SpringBoot 애플리케이션 0.2 버전에 아래 내용을 추가하여 0.3 버전으로 개선합니다.
- 1 ~ 4번 과정을 수행한 뒤 도커 이미지 저장소에 0.1, 0.2, 0.3 버전의 3개 도커 이미지가 등록된 결과를 갖습니다.
Chapter - 쿠버네티스
학습 목표
- 컨테이너 오케스트레이션이 무엇인지 이해할 수 있다.
- 쿠버네티스의 간단한 작동 원리를 이해할 수 있다.
- 쿠버네티스 리소스 명세를 작성할 수 있다.
- 파드 명세를 작성할 수 있다.
- 디플로이먼트 명세를 작성할 수 있다.
- 서비스를 이용해 파드를 노출할 수 있다.
- kubectl 명령어를 사용하여 리소스의 생성, 삭제, 조회를 할 수 있다.
- kubectl 명령어를 사용하여 롤아웃 관련 작업을 진행할 수 있다.
- 롤링 배포 현황을 확인할 수 있다.
- 새로운 버전에 문제가 발생했을 때 롤백할 수 있다.
Advanced
- liveness probe를 이용하여 파드의 health check를 할 수 있다.
- 쿠버네티스가 Stateful한 애플리케이션을 다루는 방법을 이해할 수 있다.
- 쿠버네티스에서 인그레스를 이용한 HTTP 기반 라우팅을 적용할 수 있다.
- helm 패키지 매니저를 사용할 수 있다.
쿠버네티스란?
쿠버네티스(Kubernetes, k8s)란
컨테이너 오케스트레이션(orchestration) 도구로, 대규모 분산 애플리케이션의 배포, 관리, 확장을 자동화하는 오픈 소스 플랫폼입니다.
- 구글에서 개발한 쿠버네티스는 컨테이너화된 애플리케이션을 효율적으로 실행하기 위한 다양한 기능과 도구를 제공합니다.
- 도커가 나타나면서 다양한 컨테이너 오케스트레이션 도구가 등장했습니다.
- 컨테이너 기술인 도커(Docker)와 같은 컨테이너 런타임을 기반으로 동작합니다.
- 도커는 애플리케이션을 컨테이너로 패키징하여 이식성과 확장성을 갖도록 해주는 기술이며, 쿠버네티스는 이러한 도커 컨테이너를 관리하고 조율하여 클러스터 내에서 효율적으로 운영할 수 있도록 합니다.
- 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링하는 등의 관리 기능을 제공
- 각기 다른 환경(온프레미스 서버, VM, 클라우드)에 대응 가능
쿠버네티스 주요 기능
컨테이너 스케줄링
- 쿠버네티스는 클러스터 내에서 컨테이너를 적절히 분배하고 스케줄링하여 자원을 효율적으로 활용합니다.
- 노드 간의 부하 분산, 자동 복구 및 확장 기능을 제공합니다.
자동화된 롤링 업데이트
- 애플리케이션의 업데이트나 패치를 자동으로 배포하고 관리할 수 있습니다.
- 서비스의 가용성을 유지하면서 사용자에게 중단 없는 업데이트를 제공할 수 있습니다.
스케일 인/아웃
- 쿠버네티스는 애플리케이션의 수평 스케일링을 지원하여 필요에 따라 자동으로 애플리케이션 인스턴스의 개수를 조정할 수 있습니다.
- 부하에 따라 자원을 동적으로 조절하여 성능을 향상할 수 있습니다.
서비스 디스커버리와 로드 밸런싱
- 쿠버네티스는 애플리케이션 인스턴스를 위한 네트워크 서비스 디스커버리와 로드 밸런싱을 제공합니다.
- 내부와 외부의 트래픽을 적절히 분배하여 안정적인 서비스를 제공할 수 있습니다.
자가 치유와 자동 복구
- 쿠버네티스는 애플리케이션 및 노드의 상태를 지속적으로 모니터링하고, 장애가 발생하면 자동으로 장애를 탐지하고 복구합니다.
- 서비스의 가용성과 안정성을 높일 수 있습니다.
쿠버네티스의 주요 개념
쿠버네티스로 실행하는 애플리케이션은 애플리케이션을 구성하는 다양한 리소스(부품)가 함께 연동해 동작하며 리소스로는 노드, 네임스페이스, 파드 등이 있다.
리소스
컨테이너 오케스트레이션
무엇을 오케스트레이션 한다는 것인가?
orchestrate는 사전적 의미를 살펴보면 다음과 같습니다
to plan and organize something carefully and sometimes secretly in order to achieve a desired result
"orchestrate"란 무언가를 주의 깊게 계획하고, 때로는 비밀스럽게 조직하여 원하는 결과를 이루기 위한 것입니다.
컨테이너 오케스트레이션 도구는, 수십~수백 개의 컨테이너를 관리하고자 할 때 보다 더 잘 관리하기 위한 툴입니다. 앞서 배운 컨테이너 조합은 기껏 해봐야 서너 개에 불과한데, 어떻게 수십~수백 개의 컨테이너가 생길 수 있다는 말일까요?
- 이는 아키텍처의 트렌드가 모놀리식에서 마이크로서비스로 바뀌고,
- 이로 인해서 컨테이너의 개수가 증가하고,
- 여기에 확장성을 고려해 스케일링까지 더할 경우에 발생할 수 있는 일입니다.
다섯 개 정도의 마이크로서비스를 운영하는 조직이 회사 내에 세 팀 정도가 존재하고, 최소한 두 개 이상의 레플리카(복제본)을 만든다고 가정하면, 벌써 서른(5 x 3 x 2) 개의 컨테이너가 존재할 것입니다. 이럴 때는 쿠버네티스 도입을 고려해 볼 수 있습니다.
쿠버네티스 공식 웹사이트에는 쿠버네티스를 만든 Google의 경험을 바탕으로 다음과 같이 안내하고 있습니다.
Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 원칙들에 따라 디자인되었기 때문에, 쿠버네티스는 운영팀의 규모를 늘리지 않고도 확장될 수 있습니다.
언제 사용하지 말아야 할까?
닭 잡는 데 소 잡는 칼을 사용하지 않는 것처럼, 어떤 기술을 적용하기에 앞서 “언제 사용하지 말아야 할지를 아는 것”이 진정한 고수로 가는 길입니다.
따라서 언제 사용하지 말아야 할지를 알아봅시다.
- 여러 Tier(단계)로 나누어지지 않은 모놀리식 아키텍처에서는 적합하지 않습니다.
- 모놀리식 아키텍처는 먼저 마이크로서비스 분해 전략을 세우는 것이 우선입니다.
- 고작 서너 개에 불과한 컨테이너만을 다루려면 적합하지 않습니다.
- 서너 개의 불과한 컨테이너는 docker-compose로도 충분합니다.
- 비교적 단순한 아키텍처에, 스케일링이 필요하지 않은 경우에는 적합하지 않습니다.
- 이후 트래픽이 증가하거나, 스케일링이 필요한 경우, 서버리스 서비스를 사용하면 다소 저렴한 가격에 관리형 서비스를 이용할 수 있으며, AWS 내에서도 오토 스케일링과 같은 관리형 서비스가 배포 환경에서 제공됩니다.
언제 사용해야 하는가? 어떤 기능이 있는가?
어떤 기능을 제공하는지를 살펴보면, AWS를 배웠을 때와 비슷한 기능을 제공합니다.
- 마이크로서비스를 컨테이너 방식으로 운영하는 조직이 확장성을 고려해야 할 때
- 무중단 서비스, 즉 고가용성을 제공해야 할 때
- 그 밖에 다양한 기능들: 자가 치유, 배치 실행, 구성 관리, 로드 밸런싱...
보시다시피 특징적인 기능은 AWS와 같은 퍼블릭 클라우드 공급자에서도 비슷하게 제공합니다. 그러나 여기에는 비용의 문제에서 자유로울 수 없습니다. 이를 피하고자 쿠버네티스를 사용하기도 합니다.
쿠버네티스를 사용하는 사람들은 다음과 같이 사용합니다.
- 쿠버네티스를 이용해 온프레미스 상에서 (사설) 클라우드 인프라를 구성하고,
- 저렴한 클라우드 서비스의 일부분을 도입하여 하이브리드 형태로 구성하기도 하며,
- 필요에 따라 쿠버네티스로 구성한 인프라를 통째로 AWS 등에 마이그레이션 합니다. (이식성)
- 주요 퍼블릭 클라우드 공급자들은 관리형 쿠버네티스를 지원합니다. 예) AWS EKS
이해가 안 되는 단어들
현재 모놀리식, 마이크로서비스, docker-compose, AWS, 클라우드 인프라, 스케일링 등 아직 이해가 안 되는 단어들이 많을 수도 있습니다.
- 위 단어들을 모두 완벽하게 알 필요가 없습니다.
- Cloud 운영 환경, 운영 전략 등을 배우며 이해할 수 있습니다.
컨테이너 오케스트레이션 플랫폼의 주요 기능
쿠버네티스의 주요 기능에서 살펴봤지만, 컨테이너 오케스트레이션 플랫폼의 기능을 살펴보겠습니다.
클러스터 관리
- 컨테이너 오케스트레이션 플랫폼은 여러 호스트(서버 또는 가상 머신)로 구성된 클러스터를 관리합니다.
- 클러스터는 애플리케이션 컨테이너를 실행하고 관리하는 노드의 집합입니다.
스케줄링
- 컨테이너 오케스트레이션 플랫폼은 컨테이너를 실행할 노드를 지능적으로 선택하는 스케줄링 기능을 제공합니다.
- 리소스 사용량, 가용성, 네트워크 규칙 등을 고려하여 컨테이너를 최적의 노드에 배치합니다.
네트워킹
- 컨테이너 오케스트레이션 플랫폼은 컨테이너 간의 네트워크 통신을 관리합니다.
- 컨테이너를 가상 네트워크에 연결하고, 로드 밸런싱, 서비스 디스커버리, 네트워크 정책 등을 제공하여 컨테이너 간의 안전하고 신뢰성 있는 통신을 지원합니다.
스케일링
- 컨테이너 오케스트레이션 플랫폼은 애플리케이션 컨테이너의 수평 스케일링을 지원합니다.
- 컨테이너를 필요에 따라 자동으로 복제하거나 제거하여 부하 분산과 리소스 활용을 최적화합니다.
서비스 디스커버리
- 컨테이너 오케스트레이션 플랫폼은 애플리케이션 서비스에 대한 디스커버리 메커니즘을 제공합니다.
- 외부에서 접근 할 수 있는 단일 진입점을 생성하고, 애플리케이션 컨테이너를 자동으로 로드 밸런싱하여 서비스의 가용성과 확장성을 유지합니다.
롤링 업데이트
- 컨테이너 오케스트레이션 플랫폼은 애플리케이션의 롤링 업데이트를 지원합니다.
- 새로운 버전의 컨테이너를 점진적으로 배포하고 이전 버전의 컨테이너를 제거하여 서비스의 중단 없이 애플리케이션 업데이트를 수행합니다.
쿠버네티스 설치
쿠버네티스를 로컬 환경에서 실행하기 위해서는 minikube로 시작하는 것이 편리합니다. minikube는 쿠버네티스 로컬 클러스터 환경입니다. 도커와 같은 컨테이너 런타임이 준비되어 있다면, 간단한 명령을 통해 해당 런타임에 적합한 쿠버네티스를 설치하고 즉시 사용할 수 있도록 만들어 줍니다.
minikube 설치
이 공식 문서를 통해 minikube를 설치합니다. 각 운영체제에 맞게 설치하면 됩니다.
minikube 시작하기
도커와 같은 가상화 도구가 실행된 상태에서 minikube start 명령을 통해 쿠버네티스를 실행할 수 있습니다.
잘 작동되는지 확인하려면, kuberctl get pods -A 명령을 실행해 봅시다. 모든 네임스페이스(-A 옵션) 존재하는 모든 파드를 조회하는 명령어입니다. 다음 결과를 통해 앞서 배운 쿠버네티스 작동 원리에서 다뤘던 제어판(Control Plane)의 구성요소가 파드로 존재함을 확인할 수 있습니다.
$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-78fcd69978-fs24v 1/1 Running 0 41s
kube-system etcd-minikube 1/1 Running 3 59s
kube-system kube-apiserver-minikube 1/1 Running 3 53s
kube-system kube-controller-manager-minikube 1/1 Running 3 55s
kube-system kube-proxy-qk8hx 1/1 Running 0 41s
kube-system kube-scheduler-minikube 1/1 Running 3 56s
kube-system storage-provisioner 1/1 Running 2 (35s ago) 50s
Action Items
다음 Hands On을 따라서 해봅시다.
- minikube를 이용해서 클러스터를 생성합니다
minikube start
- cozserver라는 이미지를 사용해 배포 가능한 리소스(디플로이먼트, deployment)를 생성합니다.
kubectl create deployment hello-minikube --image=sebcontents/cozserver:1.0
- 서비스(service)로 노출합니다.
kubectl expose deployment hello-minikube --type=NodePort --port=8080
- 위에서 만든 deployment를 통해 hello-minikube라는 서비스를 8080 포트로 설정해 줍니다.
- 로컬 클러스터를 호스트 컴퓨터에서 접속할 수 있도록 포트 포워딩을 합니다.
kubectl port-forward service/hello-minikube 3333:8080
- 브라우저를 열어서 http://localhost:3333 으로 접속합니다.
- Ctrl + C를 눌러 파드에서 빠져나옵니다.
- 다시 http://localhost:3333에 접속해 보면 서버가 종료되어있습니다.
위 일련의 과정을 따라 해 보면서 Cozserver라는 웹 애플리케이션을 작동시켰습니다. 이 과정은 결국 이미지를 바탕으로, 디플로이먼트라는 단위를 통해 배포하고, 서비스를 이용해 노출시키는 기본적인 작업을 진행한 것입니다.
연습
포트 변경
현재는 service/hello-minikube를 통해 3333:8080 포트를 연결시키고 있습니다.
- 로컬에서 8085번 포트를 통해 8080으로 연결해 보세요.
- 어떤 명령어를 써야 할까요?
kubectl port-forward service/hello-minikube 8085:8080
- 위 명령어를 실행하게 되면 8085 포트를 통해 우리가 만든 service/hello-minikube 8080포트에 접근할 수 있게 됩니다.
- service/hello-minikube를 3333:8080로 연결시켜보세요.
Pod 제거
- 현재 3333 포트와 8080 포트를 연결시키고 있는 Pod가 존재합니다.
- 전체 Pods를 조회합니다.
- 명령어를 실행하면 kube-system NAMEESPACE를 가진 Pods들과 hello-minikube- 로 시작하는 Pod를 찾을 수 있습니다.
- hello-minikube deployment를 토대로 Pod가 생성된 것을 알 수 있습니다.
- kubectl get pods
- 우리가 만든 hello-minikube- Pod를 제거해 보겠습니다.
- 위 명령을 실행하면 pod "**Pod-NAME**" deleted 가 출력됩니다.
- kubectl delete pod Pod-NAME
- 제거가 잘 되었는지 다시 전체 Pods 조회해 보세요.
- 우리가 삭제한 Pod가 잘 제거되었나요?
Pod 제거 방법
Pod를 제거하기 위한 방법엔 여러 가지 절차가 있습니다.
- 우리는 deployment hello-minikube를 통해 Pod들이 만들어졌습니다.
- deployment를 통해 만들어진 게 뭐가 있을까요?
- service/hello-minikube
- replicaset
- kubectl get replicaset 명령어를 통해 확인할 수 있습니다.
Deployment
deployment에는 다양한 정보들이 포함되어 있습니다.
- 정보 확인
- kubectl describe deployment hello-minikube
- 위 명령어를 통해 hello-minikube deployment 정보들을 확인할 수 있습니다.
- NewReplicaSet 정보를 보면 hello-minikube-이름이 존재합니다.
- kubectl get replicaset 했을 때 나오는 이름과 같습니다.
- kubectl describe deployment hello-minikube
제거 순서
단순히 파드만 제거한다해서 우리가 원하는 파드가 사라지지 않는 경우들이 존재합니다.
- 파드를 만들어 주는 replicaset이 있다면 아무리 파드를 제거하더라도 계속 만들어지게 됩니다.
- replicaset을 제거하는 명령어 kubectl delete replicaset hello-minikube-**이름** 을 사용하여 replicaset을 제거할 수 있습니다.
- 하지만 이 명령어를 실행하더라도 기존에 파드를 제거했던 것처럼 replicaset 은 계속 존재하게 됩니다.
- replicaset을 만들어 주는 deployment를 수정해야합니다.
deployment로 replicaset 수정 방법
- deployment hello-minikube의 정보를 수정하여 replicaset의 개수를 0개로 만들 수 있습니다.
- 반드시 편집 후 저장하고 나와주세요. (vi 편집기의 경우 ⇒ 편집 i, 편집 종료 키보드 esc 버튼, 저장 및 종료는 :wq 입니다.)
- 변경 후 kubectl get replicaset, kubectl get pod 명령어를 실행해 보세요.
- replicaset의 경우에는 DESIRED, CURRENT, READY 값이 모두 0으로 변경된 것을 알 수 있습니다.
- pod의 경우에는 STATUS가 terminating이 나오거나 No resources found in default namespace. 가 나오며 제거 중 또는 제거된 것을 알 수 있습니다.
- // 명령어 kubectl edit deployment hello-minikube // 편집 (spec 내부에 replicas: 1이라고 되어있는 부분을 0으로 변경) spec: progressDeadlineSeconds: 600 replicas: 0 ...
- 1번이 완료된 경우 다시 replicaset을 1로 수정해 주세요.
- 변경 후 kubectl get replicaset, kubectl get pod 명령어를 실행해 보세요.
- 다시 replicaset과 pod가 검색되는 것을 볼 수 있습니다.
- 이번에는 deployment를 제거해 보겠습니다.
- 1번에서 replicaset을 0으로 바꾼 결과와 다른 것은 pod와 마찬가지로 replicaset이 No resources found in default namespace. 으로 나오는 것을 볼 수 있습니다.
- // 명령어 kubectl delete deployment hello-minikube
- 변경 후 kubectl get replicaset, kubectl get pod 명령어를 실행해 보세요.
지금은 명령어의 세부 사항들을 완벽하게 이해할 필요는 없습니다. 하지만 어떤 명령어가 무슨 일을 하고 있는 것인지는 파악해 놓으면, 뒤에서 더욱 수월하게 각 개념을 배울 수 있습니다.
Advanced
- deployment를 제거했더라도 service는 여전히 남아있습니다.
- service가 존재하기 때문에 우리는 kubectl port-forward service/hello-minikube 3333:8080를 실행할 수 있습니다.
- 위 명령어를 실행했을 때 어떤 결과물이 나올지 생각해 보세요.
- 결과물을 확인한 뒤 왜 이 결과가 나왔는지 생각해 보세요.
- 원인을 찾아보시면 쿠버네티스에 대해 좀 더 이해하는 데 도움이 될 수 있습니다.
