오픈소스 SW PART.쿠버네티스

서론

교과목 14주차 강의 내용을 정리해 보겠습니다.

본론

- 쿠버네티스란?

우리는 지금까지 도커 이미지를 이용해서 프로젝트를 하기 위한 도구들을 배웠습니다. 도커 이미지를 사용하기 위한 인프라를 다져주는 것이 쿠버네티스입니다.

이미지 기반으로 동작을 하더라도 단순히 한 개나 적게 설치할 때는(이미지 pull) 쉽지만 엄청나게 많이 설치할 때는 이미지 기반으로 설치하는 것도 어렵습니다. 구글이라고 하면 하루에 셀 수 없이 많은 컨테이너가 발생합니다. 이 수많은 이미지를 다운 받는 것을 내가 로컬에 이미지를 다운 받을 때처럼 타이핑으로 pull하면 시간도 많이 걸리고 상식적으로 말이 안 된다고 할 수 있습니다.

 

> 이런 것을 조율해 주는 것이 쿠버네티스로 컨테이너 오케스트레이션 도구입니다. (k8s라고 부르고 k3s는 쿠버네티스를 작게 만든 버전입니다.)

구글이 만들었고 구글 인프라를 관리하려고 만들었던 것입니다. '도선사'라는 의미로 항구에 가면 주차가 어렵기 때문에 처음 오는 선장이 운전할 수 없는데, 항만 근처에는 도선사가 그 배에 올라타서 배를 운전하다고 합니다. (대신 주차를 해줍니다.) 도선사가 제대로 운영을 도와주지 않으면 큰 배에서 사고가 발생할 수 있습니다.

 

 

 

> 오픈소스 기반 도구로 시스템 전체를 총괄하고 여러 개의 컨테이너를 관리하는 일을 합니다.

 

 

 

 

쿠버네티스는 도커같은 컨테이너 엔진을 함께 가지고 있습니다. 따라서 시스템을 만들 때 필요한 이미지를 한 번에 다 설치를 해줍니다! > 아마존 서비스에 관련된 쿠버네티스가 있다면 아마존을 사용하는데 필요한 이미지가 전부 다 설치됩니다. 우리는 오픈소스를 가져다 쓰면 쿠버네티스가 알아서 조율을 해줍니다. 특정 회사에서 이미지를 관리하기 위해 본인들에 맞는 쿠버네티스를 구축해 두었다고 생각하면 됩니다. 즉, 다양한 호환 제품이 존재합니다.

※ 여러대의 서비스가 있는 곳에서 적합하게 쓰일 수 있습니다. 한 명의 사용자나 모델 하나 돌리는 데는 필요 없습니다.

 

- 개념

ex) 조율

=> 기존 시스템

입력이 들어오면 로드 벨런서가 서버의 트래픽을 체크하고 몰리지 않은 곳에 서비스를 전송합니다. > 우리가 봤을 땐 하나의 서비스지만 내부를 보면 여러 대의 서버가 존재하고 밸런서가 다 조율해 줍니다. > 동일한 서비스가 여러 개 존재하고 있는 것입니다. 이런 것들을 관리해야 할 때 쿠버네티스를 씁니다.

 

=> 쿠버네티스 시스템

 

현장 정보 수집 시스템이라면 그 위에는 다양한 기능을 하는 컨테이너가 돌아가고 있습니다. 얘네가 모여서 하나의 서비스가 됩니다. 구글이라고 하면 이미지 기반이 아니고 쿠버네티스가 없다면 셀 수 없이 많은 서비스를 다 usb로 설치로 해야 하는 것입니다. > 이것을 이미지로 대체하여 쿠버네티스가 필요합니다. (레드마인 설치할 때 원래는 30분이 걸렸는데 도커로 하면 1분 걸렸습니다.)

 

∴ 결론 : 로드 벨런서로 해도 되는데 이미지 기반으로 설치 할 거니 대신 쿠버네티스를 쓰자는 것입니다.

=> mlops에서 쿠버네티스

configuration 이미지, 데이터 Collection 이미지 각각 컨테이너로 돌아가고 이것들이 합쳐져서 하나의 mlops 서비스가 생깁니다. > 데이터를 잘 정리하고 관리하는 것을 이미지 컨테이너로 하자 근데 이걸 다 사람이 설치하면 복잡하니 관리하는 것을 조율할 수 있는 쿠버네티스라는 오케스트레이션 시스템을 쓰는 것입니다.

 

- 용어

1. 마스터 노드 : 워커 노드를 관리합니다. 워커 노드들이 서비스라고 치면 구글은 셀 수 없이 많습니다. 이것을 자동으로 관리하는 것이 마스터 노드입니다. 워커 노드를 관리하는 것이지 컨테이너를 실행하는 애는 아닙니다.

 

2. 워커노드 : 다양한 서비스를 모아 놓은 것입니다. 컨테이너가 실행되는 곳입니다. 워커노드를 만들고 마스터랑 연결을 해야 합니다. 그러면 쿠버네티스를 설치하면 관리자는 마스터만 컨트롤하면 됩니다. 이게 쿠버네티스의 개념입니다.

 

3. 관리자 : 마스터에게 명령을 내리는데 kubectl 프로그램을 설치합니다.

 

워커노드는 파드가 죽으면 마스터 노드에게 알려줍니다. 그러면 마스터노드는 알려준 워커노드를 다운시킵니다. > 파드들이 문제가 있으면 자신들을 꺼달라고 명령이 되어있으면 다운이 됩니다.

 

> 마스터 노드는 이미지가 설치되지 않습니다. 관리만 하는 것이지 컨테이너는(서비스, 서버) 워커노드에 있습니다. > 관리자는 마스터 노드에게 "과부화 워커는 쉬게 해라"라고 하면 마스터가 알아서 워커를 다운하고 쉬고 있던 다른 워커노드를 활성화시킵니다.

 

> 워커랑 마스터 둘 다 쿠버네티스가 있어야 합니다. 마스터가 워커를 다룰 때는 얘들만의 ip를 써야 합니다. > 별도의 네트워크를 양쪽에 만듭니다. 그게 CNI입니다.

 

+ 마스터 노드는 etcd라는 db를 가지는데 마스터 노드에 관련된 데이터가 다 있습니다.(연결된 모든 워커노드 정보도 있습니다.) 마스터는 관리한 저장소인 etcd가 필요하고 워커는 서비스를 제공하기 위한 도커가 있으면 되고 양쪽에 쿠버랑 CNI가 있어야 합니다.

 

=> 클러스터

마스터 + 워커 + 관리자 > 마스터 하나가 관리할 수 있는 범위를 하나의 클러스터라고 합니다.(무조건 하나의 클러스터에는 하나의 마스터만 존재!)

 

-> 설치되는 것

마스터 노드 : 

1) apiserver : 관리자랑 통신하는 것

2) scheduler : 파드를 워커 노드에 할당

3) controller-manager : 컨트롤러를 통합 관리 /실행

4) etcd : 클러스터 관련 정보 전반을 관리하는 데이터 베이스

 

워커 노드 :

1) let : 스케쥴러로부터 명령을 받아서 POD를 실제로 실행하는 애

2) proxy : 네트워크 통신의 라우팅 메커니즘

3) pod : 가장 기본적인 이미지 단위

 

-> pod 강화

레드마인에 깃허브 연결할 때 v 옵션을 주지 않으면 레드 마인과 wsl은 각각 연결할 길이 생기지 않는다고 했습니다. 즉 무조건 v 옵션을 해야 합니다. > ★ 컨테이너인데 v 옵션이 이미 되어있는 것을 파드라고 합니다. ★

 

> 여러 개의 컨테이너가 합쳐서 파드가 되기도 합니다. (기본은 하나의 컨테이너가 v 옵션이 달려있으면 파드라고 합니다. = 가장 기본적인 단위입니다. 단순하게 v 옵션 넣는 것입니다.) 

 

> 쿠버네티스가 파드를 기본 단위로 두는 이유 : 관리자가 워커노드와 통신, 파일을 주고받을 수 있어야 하기 때문입니다. 컨테이너 여러 대가 하나의 파드를 이룰 수 있다는 것은 뭐냐면 레드마인 연결 시킬 때 mysql 다운 받는데 레드마인과 mysql이 하나의 파드입니다. 근데 통신은 레드마인과만 하면 됩니다. (이것이 여러 개의 컨테이너가 하나의 파드를 이루는 것이라고 보면 됩니다.)

 

 

- 서비스

파드는 서비스와 연결이 됩니다.(교수님이 만들라고 하신 service!) : ★파드들이 모여서 하나의 특정 목적을 제공하기 위해 만들어진 것을 하나의 서비스라고 합니다. ★

 

 

> 서비스는 하나의 파드일 수도 있고 여러 개의 파드일 수도 있습니다. ex) 일반적으로 웹은 db, 웹 서비스, 필요한 어플리케이션 서비스 등등 다 필요하지만 이것을 모아서 하나의 서비스를 제공합니다.

 

=> 요청을 배분

서비스는 물리적으로 분리 가능합니다. 서비스가 여러 개의 파드들로 이루어질 수 있지만 물리적으로 여러 개의 워커 노드에 걸쳐 실행되더라도 하나의 서비스가 관리됩니다. 파드를 가져다 쓰니 묶이기만 하면 서비스가 됩니다. (다른 워커 노드에서 실행되는 파드로 하나의 서비스를 이룰 수 있다는 얘기!)

 

=> 레플리카세트

레플리카란, 복제라는 뜻입니다. > 레플리카는 3개의 동일한 기능을 제공하는 서버가 있습니다. pod가 다운되면 pod 복제본을 만들어서 정상적으로 돌게 만들기 위한 관리를 진행합니다. 레플리카랑 서비스는 같은 레벨에서 동작하고 서비스는 파드를 쓰는 것이고 레플리카는 파드를 관리하는 것입니다.