20260319 with claude

오늘 하루 개발하면서 많이 다뤘던 영역에 대한 궁금증이나 지식들을 claude와 티키타카하면서 정리해 보기로 했다. 핵심은 claude가 말하는 걸 '그렇구나' 하고 이해만 하고 넘기지 않고, 내가 이해한 바로 글(또는 말)로 적어보는 거다. 그래야 실제로 이 개념을 어떻게든 머리 속에서 밖으로 꺼내고 표현해내기 때문에 이해가 더 잘 된다고 claude가 그러더라. 암튼 시작해 본다.

 

Comment 1

그러면 pod는 컨테이너가 맞는데, deployment나 service나 replicaset 등 그 상위에 있는 리소스들은 뭘까? container는 어쨌든 격리될 수 있는 프로그램, 프로세스라고 이해했다. 그렇다면 그 상위 리소스들도 당연히 프로세스일 것 같은데… 뭐가 다를까? 그리고 이들은 같은 host machine에서 운영되고 있을까?

 

 

Comment 2

pod는 container 그 자체가 아니라 container의 wrapper이다. 그리고 그 상위의 deployment, service, configmap, replicaset 등등은 프로세스처럼 executable한 entity가 아니라, etcd라는 쿠버네티스의 분산 저장소에 저장된 APIObject다. 일종의 명세 오브젝트라고 이해했고, 이 오브젝트들을 통해서 쿠버네티스의 다른 구성요소들(controller manager, scheduler, kube-proxy 등)이 어떻게 동작해야 할지를 정한다(누가 정하는지는 모르겠다…)

 

 

Comment 3

그리고 쿠버네티스는 마스터 노드와 워커 노드가 있다. 여기서 노드는 뭘까? APIserver, controller manager, scheduler, kube-proxy 등은 전부 컨트롤 플레인(이게 마스터 노드라고 이해했다)에서 돌고, 여기서 개별적으로 생성되는 pod는 워커 노드(마스터 노드가 관리하는 노드)에서 돈다고 이해했다. 여기서의 노드가 논리적인 개념인 건 아는데, 물리적으로는 뭘까? 프로세스인가, virtual machine인가, 아니면 또 다른 무언가인가?

 

 

Comment 4

노드는 machine이다. 물리 서버에 꽂혀 있는 machine일 수 있고, 보통은 VM(AWS, GCP, Azure 등 cloud provider의 컴퓨팅 자원)이 일반적이다. 로컬의 컴퓨터도 machine이다. 미니큐브 간단하게 돌려볼때는 로컬 컴퓨터를 사용한다. 그리고 아까 잘못 알았던 게 있는데 정정하겠다. claude의 말을 통해서 master node에는 API server, controller manager, scheduler, etcd 가 프로세스로 돈다고 이해했다. 그리고 worker node에는 kubelet과 kube-proxy가 프로세스로 돈다고 이해했다. 이때 kubelet은 control plane(master node)로부터 명령을 받아서(예를 들면 Service APIObject라는 명세를 받아서) 그걸 워커 노드에 실제로 적용하는 작업을 한다고 한다.

 

그렇다면 워커 노드가 어떻게 컨트롤 플레인의 명령을 받는지는 이해했는데, 컨트롤 플레인은 워커 노드에 어떻게 명령을 내리나? 여기도 kubelet이 있나? 아니면 컨트롤 플레인에서 돌고 있는 apiserver, controller manager, etcd, scheduler 등은 직접 명령을 내릴 수 있나? 또 궁금한 건 아까 master node는 1~3개, worker node는 N개라고 했는데 master node가 복수인 경우는 어떤 경우인지, 그리고 master node는 왜 4개 이상은 될 수 없는건지, 그리고 master node끼리는 어떻게 통신을 하거나 상태 동기화를 하는지 등이 궁금하다.

 

kubelet은 worker node에만 있다. 그리고 컨트롤 플레인이 워커 노드에다가 명령을 내리는 게 아니라 그 반대 방향이다. 워커노드의 kubelet은 컨트롤 플레인의 api server를 계속 polling해서 상태를 체크한다. 그리고 워커 노드의 kubelet, 컨트롤 플레인의 controller manager, scheduler 모두 api server하고만 얘기한다. 유일하게 apiserver가 kubelet을 호출하는 경우는, ‘kubectl logs’, ‘kubectl exec ‘ 등의 명령을 할 때이다. master node가 2개 이상인 경우는 고가용성을 위한 경우이다. 마스터 노드가 1개인데 죽으면 서버가 장애가 나기 때문이다. 근데 복수더라도 꼭 홀수이다. 왜냐하면 결정 알고리즘 때문이다. 마스터 노드가 복수일 경우에는 RAFT 알고리즘을 통해 etcd라는 분산 저장소의 상태 동기화를 한다고 이해했다. 그런데 이 RAFT 알고리즘은 현재 떠 있는 서버 중 절반 이상이 살아있을 때 그 서버들의 합의를 통해서 도출된다. 그리고 마스터 노드는 이론적으로는 N개가 될 수 있는데, 5개 이상(3개 다음 홀수 이상)부터는 etcd라는 공용 저장소를 쓸 때 합의를 도출하는 비용이 더 많이 든다고 한다. 그래서 3개가 표준이란다.

 

 

이렇게만 정리하는데도 10분보다 조금 더 걸린 것 같다. 새삼 내가 간단한 개념들도 혼동하고 있었다는 걸 많이 느낀다. 이걸 틈틈이 자주 해서, '알고 있다고 느꼈지만 사실은 잘 모르던 영역'을 조금씩 정리해 보자.