[Kubernetes] Kubernetes Concept

 

 

 

쿠버네티스는 컨테이너를 관리하는 도구이다.

여기서 컨테이너는 애플리케이션을 격리해서 실행하는 기술으로, 도커는 컨테이너 기술을 쉽게 쓰는 구현체 중 하나임.

 

쿠버네티스가 직접 컨테이너를 실행하지는 않음. 도커에 종속된 기술은 아니다. 

컨테이너를 실행하는 런타임은 꼭 도커가 아니여도 상관없음. (2022부터 쿠버는 containerd 런타임을 사용한다)

 

docker run으로 컨테이너 띄우고 컨테이너에 웹 띄우고 자러갔는데 컨테이너가 메모리 부족으로 죽어버렸다.

쿠버네티스를 사용하지 않으면 다시 docker run을 입력해야 함.

 

갑자기 사용자가 10배로 늘어버리면 컨테이너 하나로는 감당할 수 없으니 컨테이너를 여러 개 만들어야 한다.

서버컴 하나에 컨테이너 10개를 두는건 힘드니 서버컴 n개에 컨테이너 m개를 배치해야 함. 

이 때 어떤 서버가컴이 여유로운지, 어떤 서버컴에 올려야 최적인지 판단해야 하는데, 매번 사람이 계산하는게 너무 힘들다.

 

컨테이너가 m개 떠있는데 이러면 서로 다른 IP를 가진다. 사용자는 이 m개 중 하나로 연결해야 함 (수평적 확장 기준)

k번 컨테이너가 죽고 새로 띄우면 IP가 또 바뀐다. 이렇게 매번 바뀌는 IP도 관리해 줘야 하고, 로드밸런싱도 해 줘야 한다.

 

새로운 버전을 배포한다고 하자. m개의 컨테이너를 한 번에 갈아끼우면 서비스가 멈춰버린다. 그러니 한 개씩 교체해야 함. 

새 버전을 하나 띄우고, 잘 뜨는지 확인하고, 문제 없으면 옛날꺼 내리고.. 이런식으로 반복해야 하는데 이걸 어떻게 사람이 하나씩 함? 

 

 

 

---

 

 

 

앞서 나온 문제를 해결하기 위해 쿠버네티스가 도입됐다. 

원하는 상태를 선언해두면 시스템이 알아서 맞추는 declarative 관리가 쿠버네티스 철학의 핵심임. (컨테이너 m개 떠있는 상태 유지 ㄱ)

 

수평 확장을 제1원칙으로 설정하는데, 수평 확장이 가능하려면 컨테이너들이 서로 대체 가능해야 한다. 

API서버처럼 Stateless 하면 상관없지만 데이터베이스처럼 Stateful하면 수평 확장이 힘들다. 

그러니 쿠버는 Stateless는 Deployment로, Stateful은 StatefulSet으로 두 가지를 구분해서 다룬다. 

 

쿠버도 수직 확장이 가능하긴 함. Vertical Pod Autoscaler로 컨테이너 하나에 주는 CPU/메모리 크기를 자동으로 조정할 수 있다.

다만 컨테이너 크기를 바꾸려면 보통 그 컨테이너를 죽였다가 다시 올려야 하니 잠깐 멈출 수 밖에 없으니 수평 확장을 1원칙으로 사용한다.

 

 

 

---

 

 

 

 

 

쿠버네티스 전체는 클러스터라고 부른다.

클러스터를 구성하는 서버 하나하나를 노드라고 부르고, 노드는 또 두 가지로 구분된다. 

 

Control Plane은 지시하는 쪽으로 실제 컨테이너를 직접 실행하지 않는다. (얘도 노드임)

컨테이너 m개 떠있는 상태 유지하라고 declarative 선언이 들어오면 이걸 어떤 워커 노드에 배치할지를 결정하고 지시를 내린다.

 

Worker Node는 실제로 컨테이너를 실해앟는 부분이다. 

Control Plane에서 내린 명령을 Worker Node가 받아서 containerd를 사용해 실제로 컨테이너를 실행한다. 

 

트래픽이 늘어나면 Worker Node만 더 추가하면 된다. 

서버 n대에 컨테이너m개를 배치 할 때 Worker Node가 서버 n대의 역할을 수행한다. 

Worker Node 자체는 컨테이너가 아니고, 컨테이너를 담는 그릇임.

 

클러스터는 노드들의 묶음이고, 각 노드는 서버컴퓨터에 대응하며 컨테이너는 노드에 들어가는 구성요소이다.

 

 

 

---

 

 

 

노드에 그냥 컨테이너를 바로바로 배치하면 좋은데, 컨테이너를 어떤 단위로 다룰건지를 생각해야 함. 

웹 서버를 컨테이너로 묶어서 운영하려고 하는데 여기서 만들어지는 로그를 수집해서 외부로 보내야 한다. 

이러면 웹 서버 컨테이너 안에 로그 수집기를 같이 넣는게 맞을까 로그 수집기를 별도 컨테이너로 분리하는게 맞을까? 

 

컨테이너의 관심사는 하나면 좋으니 별도로 분리하자. 

그런데 로그 수집기와 웹 서버는 서로 통신이 가능해야 한다. 같은 파일 시스템을 보면 좋으니 로컬호스트에서 통신하면 더 좋다.

쿠버가 얘내 둘을 따로 배치해서 웹서버는 Worker Node 1에 배치하고 로그 수집기는 Worker Node 2에 배치하면? 귀찮아진다.

 

그래서 Pod가 등장한다. 하나로 묶여서 다루면 좋은 것들은 Pod에 넣고, 배치할 때는 컨테이너 단위 대신 Pod 단위로 배치한다.

 

 

 

 

Pod 안에 담긴 컨테이너들은 로컬호스트로 통신할 수 있고 저장 공간도 공유할 수 있다. 

당연히 같은 Worker Node에 배치되는게 보장됨. 

 

그러니까 정확히 말하면 쿠버네티스는 컨테이너를 관리하는게 아니고 Pod를 관리하는거임.

앞에서 컨테이너 m개 떠있는 상태 유지하라는 명령은 Pod m개가 떠있는 상태를 유지하라는 말이다. 

 

당연히 컨테이너 하나만 Pod에 넣는 경우도 많지만, 그래도 Pod로 포장해서 배치한다.

일관성 있게 처리해야 하니까.. 어디는 Pod로 배치하고 어디는 컨테이너로 배치하면 귀찮아진다. 

 

IP도 Pod에 붙고, 죽고 다시 올릴 때 마다 붙어있는 IP가 매번 바뀐다. 

Pod 내부의 컨테이너들은 포트번호로 나눠서 구분한다. 

 

다만 Worker Node가 죽어버리면 Control Plane이 감지하고 다른 Worker Node에 새 Pod을 필요한 만큼 띄운다. 

즉, Pod은 특정 노드에 묶여있지 않음. 어떤 노드에서든 새로 띄워질 수 있다. 

 

 

 

---

 

 

 

Pod에는 무엇을 실행할지가 정의되어있다. 다만 몇 개를 유지할지와 죽으면 어떻게 할 지는 정의되어 있지 않음. 

Pod를 관리하는 주체는 두 가지가 있다.

 

 

 

 

 

1. ReplicaSet 

Pod를 항상 정해진 개수만큼 유지하는 역할을 수행한다. 이름처럼 Pod의 복제본을 몇 개 유지할지를 관리함.

3개로 만들어두라고 선언해두면 4개가 되면 하나 죽여서 3개로 만들고 2개가 되면 하나 띄워서 3개로 만들어준다.

 

2. Deployment 

Deployment는 Replica 위에 있는 관리자로 ReplicaSet를 직접 다룬다. 

무중단 업데이트를 위해 버전을 갈아끼울 때 v2 Pod을 새로 띄우고, 확인하고, v1 Pod를 하나 죽이는 작업을 수행할 때 사용함.

 

ReplicaSet을 두 개 사용하는 방식으로 무중단 업데이트를 구현한다. 

v2용 ReplicaSet을 만들고 v2용 ReplicaSet의 Pod 개수를 하나 늘리고 v1용 ReplicaSet의 Pod 개수를 하나 줄이는 작업을 반복한다.

이러면 예전 ReplicaSet을 지우지 않으니 롤백도 쉽다. 

 

아까는 쿠버네티스가 Pod를 관리한다고 했는데 지금 보면 쿠버네티스가 Deployment를 관리하는 것 처럼 보임.

그런데 둘 다 맞다. 내가 직접 다루는건 Deployment이고 쿠버네티스가 실제로 다루는 최소 단위는 Pod이다. 

Deployment는 Pod를 관리하는 여러 방법 중 하나일 뿐.. Stateful 애플리케이션은 StatefulSet으로 관리한다. 

이 외에도 DaemonSet, Job 등 상황별로 여러 관리자가 있음. 

 

 

 

---

 

 

 

Deployment가 Pod 3개를 관리하고, Pod는 자신만의 IP를 가진다.

3개니까 IP도 3개인데, 사용자에게 3개중 아무데나 가라고 할 수는 없으니 로드밸런싱이 필요함.

 

그냥 라운드로빈 돌면 될 것 같지만 Pod가 죽으면 새로 띄워지고 새로 띄워질 때 마다 IP가 바뀐다.

그러니 그냥 IP를 하드코딩해두면 라우팅이 안된다. 

 

여타 다른 클라우드 플랫폼이 그렇듯 고정된 이름을 하나 두는 식으로 해결하는데, 쿠버에서는 그 고정 IP를 가지는 객체를 서비스라고 부른다.

 

 

 

 

서비스는 고정된 주소(아이피 + 도메인)를 하나 가지고 이 주소는 서비스 뒤에 있는 여러 Pod이 죽든 말든 바뀌지 않는다.

그러니 로드밸런싱을 수행하는 주체는 서비스임. 

 

 

 

 

 

서비스가 알아서 죽은 Pod의 아이피를 정리하고 살아있는 Pod으로 연결해준다. 

Pod에는 라벨이 붙어있다. 그리고 서비스는 라벨을 통해 Pod을 찾아냄. 

Pod가 죽고 다시 띄워질 때 IP는 계속 바뀌더라도 라벨은 바뀌지 않으니 매번 바뀌는 IP를 관리할 수 있다.