Kubernetis #04 (Deployment/Service)

01. Kubernetis Deployment 다루기

 

Deployment란?

서비스 버전이 업데이트되어 Pod를 새로운 버전의 이미지 파드로 교체하거나 롤백을 진행해야 할 경우

사용되는 API-Resource

 

특징

- Pod의 이미지 버전이 갱신될 때 배포 전략을 설정

- Deployment 오브젝트를 생성하면 대응되는 ReplicaSet 과 Pod 자동 생성

- 기본적으로 Recreate 전략과 RollingUpdate 전략 지원

 

** 사용자는 특수한 목적이 아니라면 Pod와 ReplicaSet이 아닌 Deployment로 워크로드를 관리한다.

 

Deployment 배포 전략

재생성(Recreate)

- 기존 ReplicaSet의 Pod를 모두 종료 후 새 ReplicaSet의 Pod를 새로 생성

 

롤링 업데이트(Rolling Update)

- 세부 설정에 따라 기존 ReplicaSet 에서 새 ReplicaSet 으로 점진적으로 디옫

maxSurge : 업데이트 과정에서 spec.replicas 수 기준 최대 새로 추가되는 파드 수

maxUnavailable : 업데이트 과정에서 spec.replicas 수 기준 최대 이용 불가능 파드 수

 

 

02. Kubernetis Deployment 명령어

$kubectl apply -f deployment.yaml

- deployment가 정의된 yaml 파일로 pod 생성

- yaml 파일의 kind 인자 값을 Deployment 로 설정

- ReplicaSet 과 비슷한 듯 보이나 kubectl get deploy하여 Deployment 생성 된 것 확인

- ReplicaSet을 조회하면, "deploy명" - "랜덤 값"으로 ReplicaSet이 생성 된 것을 확인

 

$kubectl apply -f rolling-update.yaml --record

- 배포전략을 설정한 yaml 파일을 apply하며, --record 옵션을 추가하면 이 후 history 확인 가능

- "spec" 속성 하위에 "strategy" 속성이 추가된 것을 확인 (해당 속성이 Deployment 배포 전략을 정의한다.)

- Recreate가 아닌 Rolling 배포 전략이며, maxSurge 값이 1이므로 새로운 Pod가 1개 추가되고, 기존 Pod 1개가 삭제된다. 이 사이클이 반복되며, 최종적으로 5개의 Pod가 모두 업데이트 된다.

 

$kubectl rollout history deployment

 

- Deployment의 이미지를 변경하는 명령어를 사용하여, 이미지를 업데이트 해보았다.

- 그 결과 maxSurge의 값이 1이기 때문에, 업데이트 과정에서 최대 6개(5+1)까지 Pod가 생성되는 것을 볼수있다. 

 

$kubectl rollout undo deployment rolling --to-revision=1

- deployment의 revision을 "1"로 되돌리는 명령어이다.

 

 

03. Kubernetis Service 다루기

외부로부터 받은 요청을 받으면 해당 트래픽을 각 파드별로 분산시키는 API-Resource 이다.

• 여러 파드에 대해 클러스터 내에서 사용 가능한 고유 도메인 부여
• 여러 파드에 대한 요청을 분산하는 로드 밸런서 기능 수행
• 파드의 IP는 항상 변할 수 있음에 유의한다.

 

 

Kubernetis Service 종류

가. Cluster IP

• Service API 리소스의 가장 기본적인(Default) 타입이다.
• 쿠버네티스 클러스터는 Pod에 부여되는 CIDR대역과 Service에 부여되는 Cluster IP CIDR이 존재
• Cluster IP로 들어오는 요청에 대하여 Pod에 L4(IP/Port) 레벨의 로드밸런싱
• Cluster IP 타입의 Service는 쿠버네티스 클러스터 내부 통신 목적으로만 사용 가능하다.

---

$kubectl apply -f service.yaml

- "spec.type" Service의 유형이 들어간다. 아무것도 안넣으면 ClusterIP(Default)로 설정된다.

- "spec.ports.port"에는 ClusterIP가 받는 포트가 설정되고, "~targetPort" 에는 LB되는 Pod의 Port가 설정된다.

- "spec.selector"에 목적지 Pod의 Lable 값을 추가한다.

 

- 클러스터 내부에 들어가서 Cluster IP에 신호를 줄 때마다 LB되기 때문에 대상 Pod가 바뀌는 것을 볼 수 있다.

 

나. NodePort

• 모든 쿠버네티스 노드의 동일 포트를 오픈하여 외부에서 서비스에 접근하는 방식
• NodePort는 외부에서 접속하기 위한 포트이며 Cluster IP 타입을 품는 형태가 된다.
• NodePort로 들어온 요청은 실제로 Cluster IP로 전달되어 Pod로 포워딩 된다.

---

$kubectl apply -f service.yaml

- NordPort 타입은 기존 Cluster IP 타입에서 "spec.ports.nodeport" 값이 추가된다. 미 지정시 랜덤 포트 지정

$kubectl get service

- 생성된 서비스 항목을 확인한다. "targetPort/NodePort"를 확인할 수 있다.

$minikube service [SERVICE-NAME] -url

- 생성한 서비스를 시작해 준다.

- 브라우저(외부)를 통해서 서비스를 통해서 Pod에 접근해본다.

- 위의 IP 중에서 localhost로 접근한다.

 

다.  LoadBalancer

• 클라우드 프로바이더에서 제공하는 로드밸런서를 동적으로 생성하는 방식이다. (Ex. AWS ELB)
• 본 방식은 minikube에서는 지원이 안되기 때문에 개념만 알고 넘어가자. 

 

라. ExternalName

• 서비스가 Pod를 가리키는 것이 아닌 외부 도메인을 가리키도록 구성하는 타입이다.
• 보통 클러스터 외부에 존재하는 레거시 시스템을 쿠버네티스로 마이그레이션하는 과정에서 활용한다.
• ExternalName 타입의 서비스는 일반적으로 잘 사용되지는 않는다고 한다.

 

- END -