기본 리소스가 아닌데 kubectl get이 된다 — CRD와 컨트롤러의 짝kubectl get globalnetworkpolicies를 쳤더니 결과가 나온다. Calico의 정책 객체다. kubectl get certificates도 된다 — cert-manager의 리소스다. 이들은 Kubernetes 기본 리소스 목록에 없다. Deployment나 Service는 코어 API에 정의돼 있지만, GlobalNetworkPolicy와 Certificate는 아니다. 그런데 kubectl은 이 둘을 기본 리소스와 똑같이 가져온다. 어디서 왔는가?답은 CustomResourceDefinition(CRD)이다. CRD는 매니페스트 하나로 Kubernetes API에 새로운 리소스 종류를 추가하는 정식 통로다..
매니페스트 50장을 복붙하던 날들 — Helm이 템플릿으로 만든 재사용한 팀이 세 환경(dev/stage/prod)에 같은 앱을 띄운다. 매니페스트가 이미지 태그·replica 수·도메인만 다르고 나머진 동일한데, 환경마다 디렉터리를 복사해 50장씩 유지했다. 이미지를 바꾸면 세 디렉터리를 일일이 고쳤다. 어느 날 prod만 고치는 걸 깜빡해 stage와 prod가 달라졌다. Helm은 이 "매니페스트의 복붙 지옥"을 템플릿 하나로 끝낸다.이 글이 푸는 것은: Helm이 매니페스트를 어떻게 재사용 가능한 패키지(chart)로 만드는가, 그리고 kubectl apply와 무엇이 근본적으로 다른가다.Helm은 Kubernetes의 패키지 매니저Helm은 Kubernetes 매니페스트의 패키지 매니저다. ap..
클러스터는 처음 어떻게 태어나나 — kubeadm이 컨트롤 플레인을 세우는 과정클라우드에선 "클러스터 만들기" 버튼 한 번이다(EKS/GKE/AKS가 알아서 만든다). 그런데 그 뒤에서 무슨 일이 일어나는가? 한 팀이 베어메탈에 직접 클러스터를 세우려다 막혔다 — kube-apiserver, etcd, scheduler, controller-manager, CNI, 인증서를 손으로 하나씩 세팅하려니 2주가 걸렸다. kubeadm은 이 절차를 자동화한다. "버튼 한 번"이 가리키는 것이 바로 kubeadm(또는 그와 비슷한 부트스트랩 도구)이다.이 글이 푸는 것은: 빈 서버 여러 대에서 시작해 한 클러스터가 처음 어떻게 태어나는가다. 핵심은 kubeadm이 인증서·etcd·컨트롤 플레인·CNI·노드 참여를..
노드가 "나 지금 바쁘다"고 말하는 법 — cordon, drain, 그리고 node pressure유지보수를 위해 노드 한 대를 재부팅해야 한다. 그냥 재부팅 버튼을 누르면? 그 노드의 Pod 20개가 즉시 죽고, Service가 요청을 보내다 실패한다. Kubernetes의 정답은 다르다 — 먼저 그 노드에 새 Pod가 못 들어오게 막고(cordon), 기존 Pod를 안전하게 옮긴 뒤(drain) 재부팅한다. 이 절차를 모르면 "유지보수 = 무차별 중단"이 된다.이 글이 푸는 것은: 노드의 생명주기 상태(conditions), 노드가 스스로 "지금 압박 중"을 알리는 기전(node-pressure), 그리고 운영자가 노드를 안전하게 비우는 두 명령(cordon/drain)이다.노드의 condition..
부하가 늘면 누가, 무엇을, 늘리나 — 세 종류의 autoscaling이 잰 축블랙 프라이데이 트래픽이 10배로 뛰었다. 팀은 두 가지를 동시에 원했다: Pod 수를 늘리고(트래픽 대응), 노드를 늘리고(부족한 자원 확보). 그런데 Kubernetes엔 autoscaling이 한 종류가 아니다 — Pod 수(HPA), Pod 자원(VPA), 노드 수(Cluster Autoscaler/Karpenter) 세 축이 각기 다른 질문에 답한다. 이 셋을 하나로 뭉개면 "autoscaling 켰는데 안 커진다"는 혼란이 생긴다.이 글이 푸는 것은: 세 autoscaling이 각각 무슨 질문에 답하고, 언제 어떤 걸 써야 하며, 왜 HPA와 VPA를 동시에 쓰면 곤란한가다.세 축의 autoscaling — 각기 다..
"메모리가 부족할 때 누구를 먼저 죽이나" — QoS가 결정하는 생존 서열한 노드에 10개의 Pod가 돌고 있었다. 메모리가 꽉 찼다. kubelet은 한 Pod를 골라 죽여야 했다. 그런데 왜 그 Pod였을까? 한 팀은 "랜덤인 줄 알았다"고 했다. 랜덤이 아니었다 — kubelet은 QoS(Quality of Service) 등급이라는 보이지 않는 서열에 따라 죽일 대상을 정한다. 그 서열을 모르면, 가장 중요한 Pod를 의도치 않게 가장 먼저 죽이는 대상으로 만든다.이 글이 푸는 것은: requests와 limits가 노드 자원을 어떻게 나누고, 그 결과 세 QoS 등급(Guaranteed/Burstable/BestEffort)이 어떻게 매겨지며, 노드 압박 시 누가 먼저 죽는가다.requests와..
Archive
기본 리소스가 아닌데 kubectl get이 된다 — CRD와 컨트롤러의 짝kubectl get globalnetworkpolicies를 쳤더니 결과가 나온다. Calico의 정책 객체다. kubectl get certificates도 된다 — cert-manager의 리소스다. 이들은 Kubernetes 기본 리소스 목록에 없다. Deployment나 Service는 코어 API에 정의돼 있지만, GlobalNetworkPolicy와 Certificate는 아니다. 그런데 kubectl은 이 둘을 기본 리소스와 똑같이 가져온다. 어디서 왔는가?답은 CustomResourceDefinition(CRD)이다. CRD는 매니페스트 하나로 Kubernetes API에 새로운 리소스 종류를 추가하는 정식 통로다..
매니페스트 50장을 복붙하던 날들 — Helm이 템플릿으로 만든 재사용한 팀이 세 환경(dev/stage/prod)에 같은 앱을 띄운다. 매니페스트가 이미지 태그·replica 수·도메인만 다르고 나머진 동일한데, 환경마다 디렉터리를 복사해 50장씩 유지했다. 이미지를 바꾸면 세 디렉터리를 일일이 고쳤다. 어느 날 prod만 고치는 걸 깜빡해 stage와 prod가 달라졌다. Helm은 이 "매니페스트의 복붙 지옥"을 템플릿 하나로 끝낸다.이 글이 푸는 것은: Helm이 매니페스트를 어떻게 재사용 가능한 패키지(chart)로 만드는가, 그리고 kubectl apply와 무엇이 근본적으로 다른가다.Helm은 Kubernetes의 패키지 매니저Helm은 Kubernetes 매니페스트의 패키지 매니저다. ap..
클러스터는 처음 어떻게 태어나나 — kubeadm이 컨트롤 플레인을 세우는 과정클라우드에선 "클러스터 만들기" 버튼 한 번이다(EKS/GKE/AKS가 알아서 만든다). 그런데 그 뒤에서 무슨 일이 일어나는가? 한 팀이 베어메탈에 직접 클러스터를 세우려다 막혔다 — kube-apiserver, etcd, scheduler, controller-manager, CNI, 인증서를 손으로 하나씩 세팅하려니 2주가 걸렸다. kubeadm은 이 절차를 자동화한다. "버튼 한 번"이 가리키는 것이 바로 kubeadm(또는 그와 비슷한 부트스트랩 도구)이다.이 글이 푸는 것은: 빈 서버 여러 대에서 시작해 한 클러스터가 처음 어떻게 태어나는가다. 핵심은 kubeadm이 인증서·etcd·컨트롤 플레인·CNI·노드 참여를..
노드가 "나 지금 바쁘다"고 말하는 법 — cordon, drain, 그리고 node pressure유지보수를 위해 노드 한 대를 재부팅해야 한다. 그냥 재부팅 버튼을 누르면? 그 노드의 Pod 20개가 즉시 죽고, Service가 요청을 보내다 실패한다. Kubernetes의 정답은 다르다 — 먼저 그 노드에 새 Pod가 못 들어오게 막고(cordon), 기존 Pod를 안전하게 옮긴 뒤(drain) 재부팅한다. 이 절차를 모르면 "유지보수 = 무차별 중단"이 된다.이 글이 푸는 것은: 노드의 생명주기 상태(conditions), 노드가 스스로 "지금 압박 중"을 알리는 기전(node-pressure), 그리고 운영자가 노드를 안전하게 비우는 두 명령(cordon/drain)이다.노드의 condition..
부하가 늘면 누가, 무엇을, 늘리나 — 세 종류의 autoscaling이 잰 축블랙 프라이데이 트래픽이 10배로 뛰었다. 팀은 두 가지를 동시에 원했다: Pod 수를 늘리고(트래픽 대응), 노드를 늘리고(부족한 자원 확보). 그런데 Kubernetes엔 autoscaling이 한 종류가 아니다 — Pod 수(HPA), Pod 자원(VPA), 노드 수(Cluster Autoscaler/Karpenter) 세 축이 각기 다른 질문에 답한다. 이 셋을 하나로 뭉개면 "autoscaling 켰는데 안 커진다"는 혼란이 생긴다.이 글이 푸는 것은: 세 autoscaling이 각각 무슨 질문에 답하고, 언제 어떤 걸 써야 하며, 왜 HPA와 VPA를 동시에 쓰면 곤란한가다.세 축의 autoscaling — 각기 다..
"메모리가 부족할 때 누구를 먼저 죽이나" — QoS가 결정하는 생존 서열한 노드에 10개의 Pod가 돌고 있었다. 메모리가 꽉 찼다. kubelet은 한 Pod를 골라 죽여야 했다. 그런데 왜 그 Pod였을까? 한 팀은 "랜덤인 줄 알았다"고 했다. 랜덤이 아니었다 — kubelet은 QoS(Quality of Service) 등급이라는 보이지 않는 서열에 따라 죽일 대상을 정한다. 그 서열을 모르면, 가장 중요한 Pod를 의도치 않게 가장 먼저 죽이는 대상으로 만든다.이 글이 푸는 것은: requests와 limits가 노드 자원을 어떻게 나누고, 그 결과 세 QoS 등급(Guaranteed/Burstable/BestEffort)이 어떻게 매겨지며, 노드 압박 시 누가 먼저 죽는가다.requests와..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
