레플리카셋, 포드의 배포, 업데이트 등을 관리
디플로이먼트 생성, 삭제
#1 디플로이먼트 정의
파드를 3개 유지시킨다
kubectl get deployment,replicaset,pod
순차적으로 나온다
파드가 함께 사라진다
앞에서 나온 레플리카셋과 동일한 개념이다
--> 디플로이먼트를 사용하는 이유는 무엇인가?
업데이트와 배포를 편하게 한다는 것은 어떤 의미인가?: 버전 관리를 한다!
여러 개의 서버에 서버당 컨테이너가 몇백개가 돌아가는 환경에서 어떻게 돌아가게 할ㄲㅏ 고려하고 만든 것.
디플로이먼트는 컨테이너나 어플리케이션을 배포하고 업데이트 하는 것을 용이하게 하기 위해 만드는 것이다
포드의 상태--> 기존에 만들어져있던 것들은 디플로이먼트로 생성했을 때 만들어지는 것들
1.10 버전은 종료되고
1.11버전은 새롭게 생성된다
하나의 서버만 가지고 업그레이드 하는 것은 한계가 있다--> 분산시켜서 병렬로 만들어서 사용자들의 접속을 분산시킨다
증설될 수 있도록 만들 때 포트를 여러개 만든다
kubectl get replicaset
NAME DESIRED CURRENT READY AGE
my-nginx-deployment-9b5988dd 0 0 0 9m32s <-- 처음 생성했던 레플리카셋
my-nginx-deployment-d4659856c 3 3 3 6m41s <-- 새롭게 생성된 레플리카셋
이전 레플리카셋이 유지되는 것을 확인할 수 있음
포드의 이미지를 바꿨더니 예전 것을 바꿔주는 것을 알 수 있다!
서비스가 매끄럽게 업그레이드 되는 것을 알 수 있음 --> 스케일 업
필요에 따라 내가 원하는 버전으로 롤백 가능
이전 버전의 레플리카셋으로 롤백!
롤백하니 이전 레플리카셋이 올라왔다
kubectl describe deployment my-nginx-deployment
총 세 개의 버전이 있다는 뜻
히스토리는 생성된 레플리카셋의 갯수와 동일하다고 볼 수 있다
객체의 갯수만큼 가져간다!
포드를 연결하고 외부에 노출시키는 역할을 한다
yaml파일 정의시 컨테이너 포트 항목을 정의했다고 해서 해당 포드가 바로 외부에 노출되는 것은 아님
해당 포트로 사용자가 접근하거나 다른 디플로이먼트의 포트들이 내부적으로 접근하려면 서비스 객체가 필요
여러 개의 포드에 쉽게 접근할 수 있도록 고유한 도메인 이름 부여
ㄴ여러 개의 포드에 접근할 때, 요청을 분산하는 로드 밸런서 기능
클라우드 플랫폼 로드 밸런서, 클러스터 노드 포트 등을 통해 포드를 외부에 노출
ClusterIP 타입
NodePort 타입
LoadBalancer 타입
--> 파드의 호스트이름을 반환하는 웹 서버 이미지
클러스터 IP 타입의 서비스- 쿠버네티스 클러스터 내부에서만 파드에 접근가능
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hostname-svc-clusterip ClusterIP 10.97.51.221 <none> 8080/TCP 7s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 25h
=> 쿠버네티스 api 에 접근하기 위한 서비스
로드 밸런싱: 요청이 들어오면 여유 있는 파드에게 넘긴다
서비스는 이름이 있어서 이름으로 접근가능함
쿠버네티스는 어플리케이션이 서비스나 포드를 쉽게 찾을 수 있도록 내부 DNS(이름을 ip로 바꿔주는 서비스)를 구동하고 있다