Pod는 죽을 때마다 IP가 바뀌는데, 클라이언트는 어떻게 "이 앱"을 찾나한 Pod의 IP는 10.0.1.5였다. 어플리케이션 클라이언트는 그 IP로 접속했다. 그런데 노드가 죽어 Pod가 다른 노드로 재스케줄됐고, IP가 10.0.1.9로 바뀌었다. 클라이언트는 여전히 10.0.1.5로 연결을 시도하다 실패했다 — 아무도 IP가 바뀌었다고 알려주지 않았으니까.이것이 Pod IP로 직접 접속하면 안 되는 이유다. Pod는 재스케줄될 때마다 IP가 바뀐다(kubernetes 04장). 클라이언트가 "이 앱"을 안정적으로 찾으려면, 바뀌는 IP를 감추는 고정된 진입점이 필요하다. 그 역할을 Service가 한다.이 글이 푸는 것은: Service가 바뀌는 Pod IP들을 어떻게 하나의 안정된 이름으로 묶는..
기본 리소스가 아닌데 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 — 각기 다..
Archive
Pod는 죽을 때마다 IP가 바뀌는데, 클라이언트는 어떻게 "이 앱"을 찾나한 Pod의 IP는 10.0.1.5였다. 어플리케이션 클라이언트는 그 IP로 접속했다. 그런데 노드가 죽어 Pod가 다른 노드로 재스케줄됐고, IP가 10.0.1.9로 바뀌었다. 클라이언트는 여전히 10.0.1.5로 연결을 시도하다 실패했다 — 아무도 IP가 바뀌었다고 알려주지 않았으니까.이것이 Pod IP로 직접 접속하면 안 되는 이유다. Pod는 재스케줄될 때마다 IP가 바뀐다(kubernetes 04장). 클라이언트가 "이 앱"을 안정적으로 찾으려면, 바뀌는 IP를 감추는 고정된 진입점이 필요하다. 그 역할을 Service가 한다.이 글이 푸는 것은: Service가 바뀌는 Pod IP들을 어떻게 하나의 안정된 이름으로 묶는..
기본 리소스가 아닌데 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 — 각기 다..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
