20260320 with claude

어제 해보고 시간은 많이 걸렸지만 도움이 꽤 되었던 것 같아 오늘도 다시 해본다. 분명 한 10-20분 걸리겠지 싶었던 claude와의 복습이 40분을 넘어간다... 정작 티키타카는 두세번 했는데, 주저리주저리 적고 신중하게 읽고 이해하려니 은근 시간이 많이 걸린다. 앞으로 당분간 요 방식대로 가보자. 

 

 

Comment 1

쿠버네티스가 pod를 어떤 순서대로 띄우는 걸까? deployment의 spec을 보니, initContainers 부분과 containers 부분이 눈에 띈다. initContainers는 container를 띄우기 전에 실행하는 커맨드라고 이해했다. containers는 실제로 띄워지게 되는 컨테이너고, volumes, volumeMount는 worker node의 volume을 pod에 mount하는 거라고 이해했는데… 사실 정확히는 모르겠다. volume의 source가 configmap이 될 수도 있고, pvc가 될 수도 있으며, 그냥 emptyDir로 선언하기도 한다.

 

volume은 어떻게 연결될까? pod가 실행되면서 초기에 해당 pod에 mount된 volume에 대해 read/write를 하게 되면, 이때 pod가 read/write하는 memory 주소는 mount된 configmap, pvc 등의 저장소를 가리키게 되는 걸까? 여기서 또 궁금한 점은, 특히 write를 할 때 DB에 매번 write를 하면 성능이 느릴 것이라는 거다.

 

그러면 worker node에서, 이런 deployment APIObject/spec을 가지고 pod를 managing 하는 것은 누가 할까? 아니지, managing은 master node의 관할이고 worker node는 실행하는 입장이니까, master node에 있는 controller manager이나 scheduler가 담당하는 일이려나? (api server의 주 역할은 나머지 entity간의 통신을 담당하는 거라고 이해했고, etcd는 분산 ‘저장소’라서 직접 명령을 내리지는 않을 거라고 이해했다.)

 

 

Comment 2

쿠버네티스는 pod를 띄울 때, 우선 control plane의 scheduler가 가용한 worker node들 중 어떤 node에 pod를 띄울지를 결정한다. 무슨 기준으로 결정하는지 궁금하다. 그리고 api server를 통해 해당 worker node의 kubelet 프로세스와 통신/호출해서, worker node의 kubelet은 해당 노드에 pod를 띄우라는 명령을 받게 된다. 그러면 이 kubelet은 volume을 mount 하고, initcontainers라는 컨테이너들을 실행한 뒤(initContainers는 커맨드가 아니라 컨테이너였다!), 명세에 정의한 스펙대로 container를 띄운다.

 

이때 volume/volumeMount는 꼭 worker node의 volume을 mount하는 것만은 아니다. PVC의 경우는 cluster 사이에서 공유되는 리소스이고(read write 모두 가능), Configmap이나 Secret은 namespace에서 공유하며(read만 가능), 그리고 emptyDir로 mount된 volume은 해당 worker node VM의 메모리나 디스크에서 read, write 된다. 그러므로 PVC나 Configmap, Secret과 달리 emptyDir로 할당한 volume은 pod가 죽으면 사라진다. volume이 연결되는 것도 ‘포인터’가 정확한 개념인진 모르겠지만, linux의 VFS(virtual file system)이라는 추상화를 거친다고 한다. 쉽게 말해 컨테이너 입장에서 어떤 path ‘/a/b’에 write를 하면, 이 VFS는 그 path를 받아서, 이 path가 실제(물리적으로) 어떤 주소에 연결되는지를 매핑한다고 이해했다. 마치 가상 주소와 물리 주소의 mapping과 유사한 것 같다.

 

그리고 emptyDir이 worker node VM에 write하는 만큼 가장 빠르다고 한다. configmap/secret은 write를 하지 않으니… 그러면 아예 pod를 생성할 때 그 내용 자체를 옮겨오는 걸까? 라는 의문도 든다. 그리고 PVC의 경우는 네트워크 통신으로 read/write를 해서 세 방법 중 가장 느리다고 이해했다.

 

또 궁금한 건, PV나 PVC는 api object인지 아닌지이다. etcd라는 분산 저장소가 master node에 있다고 알고 있는데 그럼 PV는 또 뭘까? PVC는 PersistentVolume’Claim’ 이니까 저장소 자체가 아니라 ‘이 저장소를 이러이러하게 사용하겠다’ 라는 claim object일 것 같은데, PV 자체는 etcd와 별개의 저장소인가? 그리고 cluster 단위로 공유되는 리소스와 namespace 단위로 공유되는 리소스들 사이의 권한 구분은 어떻게 하는지도 궁금하다…

 

 

Comment 3

PVC와 PV는 개념이 다르다. 둘다 하나의 클러스터 안에서, 즉 넓은 범위에서 공유되는 명세 오브젝트이다. PV 자체가 스토리지가 아니다. PV 자체는 ‘etcd에 이런 저장소가 있다’는 명세 그 자체이다. etcd는 이 정보를 갖고 있고, pv에서 read/write가 발생하면 이 PV의 정보를 가지고 외부 저장소(NFS, EBS 볼륨 등)에 read/write 명령을 보낸다고 이해했다. 새삼 쿠버네티스를 쓰면 네트워크 트래픽이 참 많이 나오겠구나 싶긴 하다… 여튼 그렇다. 그리고 PVC는, ‘나는 이러이러한 조건의 PV가 필요하다’고 claim(주장)하면 그에 맞는 ‘미리 생성되어 있었던(중요!)’ PV가 PVC에 바인딩되게 되는것이다.

 

즉 PV는 저장소에 대한 명세이고, PVC는 저장소를 실제로 어떤 리소스가 사용하려고 한다는 명세라고 이해했다. 그리고 이들의 연결관계는 1:N이라고 이해했다. 왜냐하면 worker node가 복수일 경우, 한 클러스터 안의 복수의 worker node가 pvc를 만들 수도 있다. 이에 대한 접근 정책은 ReadWriteOnce, ReadOnlyMany, ReadWriteMany로 나뉜다고 한다. Once가 붙으면 하나의 워커노드만 pvc에 접근 가능한 것이고, Many가 붙으면 여러 워커노드가 접근 가능하다. configmap과 secret은 추측한 대로, pod가 만들어질 때 configmap과 secret의 내용을 읽어서 가져온다고 한다. 근데 한번 가져오고 끝이 아니라 주기적으로 polling해서 차이가 있으면 그 부분을 반영한다고 한다.