Tech Artifacts/Kubernetes

Kubernetes - 14. kubeadm

클러스터는 처음 어떻게 태어나나 — kubeadm이 컨트롤 플레인을 세우는 과정클라우드에선 "클러스터 만들기" 버튼 한 번이다(EKS/GKE/AKS가 알아서 만든다). 그런데 그 뒤에서 무슨 일이 일어나는가? 한 팀이 베어메탈에 직접 클러스터를 세우려다 막혔다 — kube-apiserver, etcd, scheduler, controller-manager, CNI, 인증서를 손으로 하나씩 세팅하려니 2주가 걸렸다. kubeadm은 이 절차를 자동화한다. "버튼 한 번"이 가리키는 것이 바로 kubeadm(또는 그와 비슷한 부트스트랩 도구)이다.이 글이 푸는 것은: 빈 서버 여러 대에서 시작해 한 클러스터가 처음 어떻게 태어나는가다. 핵심은 kubeadm이 인증서·etcd·컨트롤 플레인·CNI·노드 참여를..

Tech Artifacts/Kubernetes

Kubernetes - 02. architecture

클러스터의 두뇌와 손 — 컨트롤 플레인과 노드가 어떻게 갈리는가한 클러스터에서 노드 3대가 동시에 재부팅됐다. Pod들은 전부 죽었고, 운영자는 "클러스터가 죽었다"고 보고했다. 하지만 정확히 무엇이 죽은 걸까? 재부팅된 노드 위의 kubelet은 다시 살아나자마자 apiserver에 "내가 돌아왔다, 내 담당 Pod들을 다시 띄워 달라"고 물었고, 90초 안에 Pod들이 복구됐다. 죽은 건 Pod였지 클러스터가 아니었다.이 사례가 보여주는 건 Kubernetes의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..

Archive

'control-plane' 2

Tech Artifacts/Kubernetes

Kubernetes - 14. kubeadm

클러스터는 처음 어떻게 태어나나 — kubeadm이 컨트롤 플레인을 세우는 과정클라우드에선 "클러스터 만들기" 버튼 한 번이다(EKS/GKE/AKS가 알아서 만든다). 그런데 그 뒤에서 무슨 일이 일어나는가? 한 팀이 베어메탈에 직접 클러스터를 세우려다 막혔다 — kube-apiserver, etcd, scheduler, controller-manager, CNI, 인증서를 손으로 하나씩 세팅하려니 2주가 걸렸다. kubeadm은 이 절차를 자동화한다. "버튼 한 번"이 가리키는 것이 바로 kubeadm(또는 그와 비슷한 부트스트랩 도구)이다.이 글이 푸는 것은: 빈 서버 여러 대에서 시작해 한 클러스터가 처음 어떻게 태어나는가다. 핵심은 kubeadm이 인증서·etcd·컨트롤 플레인·CNI·노드 참여를..

댓글
Tech Artifacts/Kubernetes

Kubernetes - 02. architecture

클러스터의 두뇌와 손 — 컨트롤 플레인과 노드가 어떻게 갈리는가한 클러스터에서 노드 3대가 동시에 재부팅됐다. Pod들은 전부 죽었고, 운영자는 "클러스터가 죽었다"고 보고했다. 하지만 정확히 무엇이 죽은 걸까? 재부팅된 노드 위의 kubelet은 다시 살아나자마자 apiserver에 "내가 돌아왔다, 내 담당 Pod들을 다시 띄워 달라"고 물었고, 90초 안에 Pod들이 복구됐다. 죽은 건 Pod였지 클러스터가 아니었다.이 사례가 보여주는 건 Kubernetes의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..

댓글 1

wall

방명록

방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.