쿠버네티스란? 주요 개념 익혀보기 - 레플리카셋, 디플로이먼트, 서비스

 

 

목차

쿠버네티스 구성요소 - 레플리카셋

쿠버네티스 구성요소 - 디플로이먼트

쿠버네티스 구성요소 - 서비스

 

 

 

---

 

 

 

 

 

01. 쿠버네티스 구성요소 - 레플리카셋(ReplicaSet)

 

앞선 글에서 파드(pod)에 대해서 포스팅을 했었다.

(이전 글 참고)

쿠버네티스란? - 노드와 파드, 컨테이너 차이를 이해해보자

 

 

여기서, 레플리카셋은 파드의 수를 보장하기 위한 개념이다.

 

즉, 레플리카 세트를 3으로 설정했다고 가정할 때, 파드가 삭제되거나 (어떠한 이슈에 의해) 다운돼도,

쿠버네티스가 알아서 파드를 생성하여 3개를 유지하는 것을 보장한다.

 

레플리카 세트 개념을 제대로 이해하기 위해서는,

상위 개념으로 디플로이먼트(Deployment) 리소스에 대한 이해가 필요하다.

 

 

---

 

 

02. 쿠버네티스 구성요소 - 디플로이먼트(Deployment)

 

디플로이먼트란, 애플리케이션을 배포하고 업데이트를 수행하는 리소스다.

따라서, 디플로이먼트는 레플리카셋 컨트롤러를 제어하기 때문에, 레플리카셋을 생성하는 역할도 수행한다.

 

그러면, 레플리카셋은 그보다 하위 개념인 파드를 제어한다.

 

즉, 상하위 개념을 정리해보면 

디플로이먼트 > 레플리카셋 > 파드

 

가 될 수 있겠다.

 

 

 

그렇다면, 왜 디플로이먼트를 이용해서 애플리케이션을 배포 & 업데이트 해야 하는 것일까?

그 이유는, 안정성 때문이다.

 

디플로이먼트의 배포 방식은 크게 세 가지가 있는데, 그 중 기본(default)이자 가장 베이직하게 쓰이는 롤링 업데이트 방식을 이용하면 아래와 같은 장점을 얻을 수 있다.

 

1. 제로 다운타임(무중단)으로 배포(업데이트)를 수행할 수 있다.

2. 만약 업데이트 버전에서 오류가 생겨 배포 실수가 발생했을 경우, 서비스는 그 이전 버전으로 문제없이 실행되도록 설정할 수 있다.

 

(이 장점이 왜 발생하는지 이해하려면 디플로이먼트의 배포 방식을 알아야 하는데, 

이는 내일 포스팅해서 해당 위치에 태깅해두도록 하겠다.)

 

 

 

 

---

 

 

03. 쿠버네티스 구성요소 - 서비스(Service)

 

서비스를 이해하기 위해서는, 쿠버네티스의 IP 할당에 대해 알아야 한다.

쿠버네티스의 파드는 각각 다른 IP 주소를 갖는다. (여담이지만, 한 포드 안 컨테이너는 이 파드의 리소스를 공유하는 형태를 지니고 있다.)

 

하나의 어플리케이션이 있다고 가정해보자.

이 어플리케이션의 부하분산을 위해 레플리카셋을 3으로 설정했다고 가정했을 때,파드는 총 3개가 띄워진 형태일 것이다.

이때, 작업자의 실수로 한 개의 파드가 삭제되었다고 가정하자.
이러한 상황에서, 디플로이먼트는 레플리카셋 값을 맞추기 위해 자동으로 새로운 파드를 생성할 것이다.

그렇다면 각 세 개의 파드는 IP가 다를 뿐더러, 마지막에 생긴 파드는 또 새로운 IP 가 할당될 것이다.

하지만 작업자는, 사용자에게 하나의 IP만 제공하고 싶을 것이다.

 

 

서비스를 이용하면, 아무리 포드가 여러개든 & 파드가 재생성되든, 하나의 IP로 접속할 수 있도록 설정하는 것이 가능하다.

 

 

즉 서비스란, 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 리소스다.

서비스는 파드와 비슷한 REST 오브젝트로, 추후 yaml 파일로 배포할 때 pod 배포처럼 진행할 수 있다. (이는 추후 실습 포스팅에서 다뤄보도록 하겠다.)

 

 

그렇다면 어떻게 모두 다른 파드의 IP들 중, 특정 애플리케이션 집단의 파드들만을 하나의 IP로 연결할 수 있는 것일까?

이는 라벨(label, 레이블이라고도 읽음) 개념을 이용하면 가능하다.

 

 

 

라벨이 app:소희DE 로 설정된 파드들만, 같은 라벨을 지닌 서비스에 매핑

 

 

 

위 그림의 왼쪽 파드들을 살펴보자.

총 4개의 파드가 띄워져 있고, 각 'app'이라는 라벨이 붙어 있다.

이때, 위 세 개의 파드가 소희DE 라는 app 라벨이 붙어 있는 것을 알 수 있다.

 

오른쪽의 서비스 오브젝트를 살펴보자.

서비스는 한 개가 띄워져 있는데, 이 또한 'app'이라는 라벨이 붙어 있고, 왼쪽 상위 3개 파드와 같은 라벨을 가지고 있는 것을 알 수 있다.

 

그렇다면, 같은 라벨을 가진 세 개의 파드들이 해당 서비스에 매핑이 된다.

(참고로, 라벨은 원한다면 여러 개를 붙일 수도 있다.)

 

 

 

 

 

 

 

 

이로써 쿠버네티스의 굵직한 개념들에 대해 간단히 살펴보았다.

다음 포스팅들에서는 1) 디플로이먼트의 배포 방식,

2) 실습을 통해 GCP 기반 쿠버네티스 명령어를 적용해보며, 도커 파일을 쿠버네티스로 띄워보는 작업 등을 정리해보도록 하겠다.

 

 

 

 

 

 

공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치 하도록 하겠습니다. 오늘도 읽어주셔서 감사합니다!