호드리

쿠버네티스(k8s) 스터디2 - What is k8s’s Deployment, Service, ReplicaSet, Pod?

3 minute read

쿠버네티스에는 다양한 컨셉과 개념이 설명되어 있다.

처음에는 매우 어렵게 느껴졌지만, 다양한 강의를 연속해서 듣고 예제를 해보니 그렇지 않다는 것을 깨달았다.

즉, 우리의 편의에 의해서 사용되어 왔던 각종 툴, idea들이 시스템이 복잡해지고 고도화되고 나니 또 다른 어려움이 생겼고,

쿠버네티스는 이러한 어려움을 어떻게 하면 쉽게 관리 할 수 있을까? 하는 의문점에서 출발한 프로젝트가 분명한 것 같다.

1. 쿠버네티스는 왜 태어났을까?

당신이, 아니 내가, 아니 전 세계가 쿠버네티스에 열광하고 모든 엔터프라이즈급 시스템과 Big Tech 회사들이 도입하는 이유는 무엇일까?

내가 생각한 흐름은 아래와 같다.

우리의 시스템은 On-Premise(Legacy) 방식으로 시스템을 구성했다. 무슨 말이냐 하면, 인프라 담당자 또는 팀이 큰 서버를 사면, 그 서버에 각종 프로그램들과 application들을 설치해서 서비스를 제공해줬는데, 이게 문제의 봉착된 것이다.

What if? 미국 회사인데, 한국에 서비스를 하고 싶으면, 한국까지 날아가서 시스템을 재구성하고, 기존 시스템과 연결시켜야 함

이러다 보니, ‘Cloud’ 환경이 태어났다고 보면 된다. 클라우드 서비스를 제공해주는 업체들은 이런 것을 너의 책상 위에서 모든 것을 해결하게끔 지원해주기 시작했다. 유료로.

하지만 여기서도 문제가 발생하는데, 글로벌 환경의 시스템들은 그만큼 유저가 기하급수적으로 늘어나게 되고 서비스가 정상 동작하지 않거나, 시스템을 업그레이드 할 때 어려움을 겪기 시작하게 된 것이다.

이를 위해서는 서버를 늘리거나, 하드웨어 스펙을 더 향상 시켜야 하는데, 기술적이나 금전적으로 엄청난 문제가 발생하기 시작한다.

가상화 서비스(VM)을 이용하는 움직임이 초반에 있었으나, 결국 VM도 기계덩이리들의 H/W 스펙 위에서 동작하고 VM끼리의 자원 공유가 어렵다 보니 컨테이너라는 기술이 등장하고 대중화 되기 시작한다.

우리가 아는 Docker, 그 녀석이다.

컨테이너의 개념을 사용하기 위해서는 기존 시스템들을 잘개 쪼개서 서로 유기적으로 동작하되, 각각을 작은 시스템(서비스), 즉, 컨테이너화 시키는 작업을 하기 시작하고 유행처럼 번진다.

하지만 여기서도 문제가 발생하는데,

What if? 컨테이너 수가 몇 백, 몇 천 개라면, 어떻게 컨테이너 이미지를 업데이트하고 관리할 것인가?

AWS의 Auto Scaling도 좋은 대안이 될 수 있지만, 그것 또한 AWS에 의존적이며 단점이 없지 않다. 또한, 서비스별로 Scaling을 시켜주는 것이 아닌, AWS안의 서비스들(예, EC2 - 우리로 치면 물리 서버 컴퓨터)을 정책에 의해 하다 보니, 특정 기능만 하는 application service만 부하를 분산 시키고 싶은데 정책이 맞지 않는 경우가 발생한다.

각종 요구사항들은 넘쳐나는데, 관리 포인트가 늘어나니 아우성일 수 밖에.

이러다 보니 등장한게 k8s(쿠버네티스)가 아닌가 싶다.

공부하고 실습하고, 각종 영상을 보다보니 쿠버네티스는 매우 매력적이다.

  1. Google에서 만든 Project이다 보니 GCP(구글 클라우드 플랫폼)에서 기본 지원
  2. AWS, Azure도 지원!
  3. 쿠버네티스의 각각은 각각의 R&R만 가지고 있어서, 그 외의 범위(SCOPE)은 관여 하지 않는다.

3번 때문에 너무 많은 내용을 공부해야하고, 무슨 말인지 이해가 당최 홈페이지를 통해서도 쉽지가 않은데.

막상 실습을 하고 나면 너무나 명확해 지고 맞는 말이다.

쿠버네티스의 중요 컨셉

아래를 보면, 각각이 본인들의 역할과 책임만을 가지고 있으며, 본인의 R&R만 관심있으며 행동한다. 즉 본인의 것이 아니면 일체 관여하지 않는 것이다.

Deployment

  • 역할: Pod의 선언적 업데이트를 관리합니다.
  • 책임: Deployment는 하나 이상의 Pod 복제본을 유지하고, Pod의 업데이트 프로세스(예: 이미지 업데이트)를 관리하며, 변경 사항을 쉽게 롤백할 수 있게 합니다. Deployment는 ReplicaSet을 사용하여 실제로 Pod 복제본을 생성하고 관리합니다.

한마디로, 그냥 배포 관리자이다. 어떤 이미지를 어떤 방식으로 배포할지를 관리해주는 녀석. 이 녀석이 스스로 Revision을 가지고 있어서 롤백이 너무 쉽게 가능해진다.

Service

  • 역할: 네트워킹을 통한 Pod 그룹의 안정적인 접근 지점을 제공합니다.
  • 책임: Service는 여러 Pod에 걸쳐 트래픽을 로드밸런싱하며, 클러스터 내부 (또는 외부)에서 Pod들에 도달하기 위한 일관된 주소(예: DNS 이름)를 제공합니다. Service는 물리적으로 변할 수 있는 Pod의 IP 주소 대신에 안정적인 주소를 사용함으로써 클라이언트가 Pod에 지속적으로 접근할 수 있게 합니다.

말 그대로, 로드밸런싱과 일관된 주소를 관리하고, 외부 접근이 가능하도록 지원해준다. 예를 들어, 홈페이지 접속시, 어떤 외부 IP인지 알려주는 기능이라 생각하면 이해하기 쉽다.

ReplicaSet

  • 역할: 지정된 수의 Pod 복제본을 유지합니다.
  • 책임: ReplicaSet은 하나 이상의 Pod가 지정된 복제본 수를 유지하도록 보장합니다. Pod가 실패하거나 삭제되면, ReplicaSet은 자동으로 새로운 Pod를 생성하여 설정된 복제본 수를 유지합니다. Deployment의 하위 구성 요소로서, ReplicaSet은 Pod의 배포 및 스케일링을 관리하는 데 중요한 역할을 합니다.

말 그대로, 주어진 조건과 설정에 따라 Pod만 관리하는 녀석이다. Pod가 3개여야 하는데, 1개가 죽으면, 이 녀석이 알아서 1개를 더 생성해서 3개를 맞춰준다. 비용 증가가 없다. 왜? 쿠버네티스가 알아서 이 모든 것을 클러스터 안의 워커 노들에서 관리해주니까 말이다!

Pod

Pod는 ReplicaSet위에 동작하는 녀석인데, 처음에는 1 pod = 1 app? 이라고 생각했으나 절대 그렇지는 않다.

1개의 Pod안에는 N개의 컨테이너를 실행할 수 있고(이 말은 1 pod = N app), Pod안에서의 리소스는 서로 공유 한다는 것이다.

Pod 내 다수의 컨테이너 실행의 특징:

  • 공유 리소스: 같은 Pod 내의 컨테이너들은 네트워크 네임스페이스와 스토리지 볼륨을 공유합니다. 이는 컨테이너 간 통신을 localhost를 통해 가능하게 하며, 파일 시스템 레벨에서 데이터를 공유할 수 있게 합니다.
  • 라이프사이클 관리: Pod 내의 컨테이너들은 동일한 생명 주기를 공유합니다. 즉, Pod가 시작되면 모든 컨테이너가 시작되고, Pod가 종료될 때 모든 컨테이너도 종료됩니다. 따라서 긴밀하게 연관된 컨테이너들을 같은 Pod 안에서 운영하는 것이 효율적입니다.
  • 사용 예시:
    • 사이드카 패턴: 로깅, 모니터링, 데이터 동기화와 같은 보조 기능을 주 애플리케이션과 별도의 컨테이너로 실행하여, 주 애플리케이션의 복잡성을 줄이고 유지관리를 용이하게 합니다.
    • 멀티-티어 애플리케이션: 데이터베이스 서버와 같은 백엔드 서비스와 밀접하게 연결된 애플리케이션 컴포넌트를 같은 Pod 내에서 실행하여 네트워크 지연을 최소화하고 보안을 강화할 수 있습니다.

Leave a comment

You may also enjoy