쿠버네티스 아키텍처
쿠버네티스 구성
User는 kubectl을 통해 Kubernetes Cluster와 통신을 한다.
Master는 전체 클러스터를 관리하고, Node에 연결해주는 역할을 담당한다.
Node는 쿠버네티스 위에서 동작하는 워크로드들이 실행되는 공간이다.
그렇다면 하나씩 보며 쿠버네티스가 "어떻게" 동작하는지 살펴보자
Master
쿠버네티스는 MSA(Microservices Architecture) 형태로 설계되어 있다.
Master는 "API Server", "Controller", "Scheduler", "etcd"로 구성되어 있다.
그렇다면 이 요소들은 무엇일까?
API Server
Service 제공자는 쿠버네티스 클러스터에 Service를 올리고 싶을 것이다.
그렇다면 관리자는 쿠버네티스에 kubectl을 통해 요청을 보낼 것이며, 요청은 API Server에서 받게 된다.
(이 때 요청은 Yaml 파일로 수행하게 된다)
API Server는 etcd라는 (key, value)를 저장하는 저장소에 어떤 상태가 되어야 하는지를 저장한다.
Controller
Desired State가 무엇인지부터 알아야 한다.
관리자는 Service가 배포될 때 원하는 환경이 존재할 것이다.
예를 들어, 어떤 서비스가 어느 정도의 트래픽을 만족했으면 좋겠는가? 서비스가 어떤 Port를 통해 제공되었으면 좋겠는가? 등이다.
이런 "개발자가 원하는 상태"를 Desired State라고 한다.
쿠버네티스는 Desired State와 Current State를 비교하여 만약 다르다면 Current State를 Desired State로 Update하는 기능을 수행하는 것이다
Controller는 Desired State와 Current State를 계속해서 비교하는 역할을 담당한다.
즉, etcd에 저장된 상태를 항상 주시하는 역할을 하는 것이다
Scheduler
Controller가 상태가 달라졌음을 깨닫고 새로운 Workload(Pod)를 실행시켜야 한다고 판단했다.
그렇다면, Master와 연결된 여러 Node 중 어떤 Node에 Workload가 띄워지는지를 판단할 필요가 있다.
이 역할을 Scheduler가 수행하는 것이다
Master에서 일어나는 과정 정리
-
API Server에 관리자나 User가 kubectl을 통해 요청을 보냄
-
etcd에 요청에 대한 상태를 (Key, Value) 형태로 저장
-
Controller는 etcd를 계속해서 주시하는데, 2번 과정에 의해 현재 상태와 Desired State가 달라짐
-
Controller는 요청에 대한 처리를 수행해야 한다고 API Server에 보냄
-
API Server는 4번에 대한 요청을 (Key, Value) 형태로 etcd에 저장
-
Scheduler는 Pod에 대한 요청임을 인지하고 Node에 Pod를 할당함
Node
실제로 Workload(Pod)들을 실행하는 공간이다.
Kubelet, Kube-Porxy와 Container Runtime(대부분 Docker)로 구성되어 있다.
Container Runtime이 Pod를 실행시켜 Service를 제공하는 것이다
Kubelet
Pod에 존재하는 Container가 동작하게 만드는 것이다.
Master에서 Node에게 작업을 요청하면 Kubelet이 이 요청을 받아 컨테이너를 생성하여 Docker에게 보낸다.
이렇게 kubelet에서 생성된 Container가 Docker를 통해 실행되며 서비스가 제공되는 것이다
Kube-Proxy
Node로 들어오고 나가는 네트워크 트래픽을 Proxy하여 Node와 Master 사이의 네트워크 통신을 관리하는 공간이다.
Master & Node 전체 실행 과정
다른 사이트 이미지를 사용 안하려고 했지만, 이 이미지는 너무 좋은 것 같아 가지고 왔다.
Master 및 Node에 어떤 과정으로 Pod가 Service를 제공하는지 잘 알아두자
