[쿠버네티스 #4] Replica set 과 Deployment

오늘 소개할 것은 쿠버네티스 컨트롤러 중 Replica set과 Deployment이다.

 

이 두 가지의 컨트롤러의 가장 큰 기능은 여러 차이가 있지만 결국 Pod를 관리하는 컨트롤러이다.

 

두 가지를 설명하기 전 간단하게 쿠버네티스 컨트롤러에 대해 정리해보면

 

쿠버네티스 컨트롤러는 크게 4가지의 역할을 한다고 할 수 있다.

 

1. auto healing 

  - pod에 문제가 생기거나 pod가 실행되고 있는 node에 문제가 생기면 해당 pod를 다시 실행하는 기능을 말한다. 

(ReplicaSet, DaemonSet )

 

2. software Update

  - pod 자동 업데이트에 대한 기능을 지원한다. 이 때 이 업데이트가 잘못된 업데이트라면 롤백할 수 있는 기능도 제공한다.

(Deployment)

 

3. auto scaling

  - Pod의 리소스가 부족할 때 pod를 추가적으로 생성하여 부하를 분산시키고 pod가 죽지 않게한다.

 

4. Job

  - 일시적인 작업을 처리할 때 (웹서버와 같은 지속적인 서버가 아니라 단순히 실행하는 코드) 필요한 순간에만 pod를 만들고 해당 작업을 수행하고 수행이 끝나면 pod를 삭제함. *(Job의 기능은 나중에 포스팅 하겠지만 이 job을 사용하는 이유는 해당 작업을 수행하는 동안에만 리소스를 차지하기 때문에 효율적인 자원 활용을 하기 위함이다.)

(job, cron job)

 

 

 

pod는 쉽게 삭제되고 생성되는 특성을 가지고 있는데 이러한 점을 pod를 관리하는 컨트롤러들이 보완한다.

 

Replica set은 번역그대로 복제 세트를 말한다.

 

pod를 생성, 복제, 삭제를 하는 것이 주된 기능으로 웹서버를 실행시키고 있는 pod에 접속량이 많아지거나 연산이 많아져 부하가 몰리면 해당 pod를 복제하여 접속을 분산시키기도 하고 worker node에 문제가 생겨 pod가 망가지면 정상적인 다른 node에 pod를 재생성 하여 서비스 중단을 막기도 한다.

 

 

예전에는 Replication Controller가 있었지만 이는 더이상 사용되지 않고 Replica Set이 사용된다.

이 둘의 차이는 TMI인거 같아 적지 않겠다.

Replication Controller < Replica Set 

(Replica Set의 기능이 Replication Controller를 포함한다.)

 

 

Replica Set

Replica Set의 간단한 설명을 그리면 위와 같은데 오른쪽의 yaml파일의 내용을 보게 되면 selector와 template가 있다.

이 때 오른쪽 yaml을 Deployment지만 관련없는 부분이니 selector와 template를 보면된다.

selector란 selector에 매칭되는 pod를 찾고 매칭되는 pod가 있으면 해당 pod를 Replica Set에 연결한다.

 

오른쪽 yaml파일에 relicas: 1이라고 적힌 부분은 pod의 개수를 몇개로 유지하냐는 부분이다. 여기선 1이라고 적어놨기 때문에 pod의 개수를 1개로 유지한다. 3이라고 적어놨으면 3개의 pod를 유지한다.

 

template란 template안에 적힌 내용대로 pod를 생성하는 것을 말한다. 만약 selector에서 매칭되는 pod가 없다면 replica set은 template에 적힌 내용을 보고 그에 맞게 pod를 생성한다. 

 

 

 

 

Deployment는 pod 업데이트를 위해 사용되는 기본 컨트롤러이다. 

(*확실하진 않지만 실무에서 pod를 배포할 때 Deployment로 배포를 한다.)

(Deployment를 번역하면 배포인데 배포를 배포한다? 조금 이상하다. 이건 그냥 하는 소리고

쿠버네티스에서 배포의 의미는 클러스터에 컨트롤러나 오브젝트를 실행한다 정도의 의미로 사용하는 것 같다.)

 

 

pod의 업데이트 방법에는 여러가지가 있지만 여기서는 ReCreate와 Rolling Update에 대해서만 간략하게 설명하겠다.

 

1. ReCreate

  - 업데이트를 할 pod를 한 번에 교체하는 방식이다. 버전A에서 버전B로 업데이트 할 때 버전 A를 종료하고 버전 B를 실행한다. 이 방식에서는 pod의 교체 과정에서 서비스 중단 시간이 발생하게 되는데 이를 down time이라 한다.

 

2. Rolling Update

  - 업데이트 시에 새 버전을 배포하면서 이전 버전을 하나씩 줄여나가는 방식이다. 기존 버전과 새 버전의 pod가 공존할 수 있다는 단점이 있지만 서비스가 끊기지 않기 때문에 소위 말하는 무중단 업데이트를 할 수 있다.

 

 

*Deployment의 업데이트 방식의 defalut값은 Rolling update이다. 다른 업데이트 방식은 설정을 yaml파일에 적어줘야한다.

 

 

 

Deployment에 대한 자세한 설명은

 

조대협 선생님 블로그에 올라와 있는데 

 

https://bcho.tistory.com/1266

쿠버네티스 #10 - 배포

맨 위에 롤링 업데이트에 대한 그림 설명이 이해하기 쉽게 그려져 있으니 참고하면 좋을 거 같다.