mirabo01 님의 블로그

관리형 쿠버네티스(EKS·GKE), 편해지는 만큼 무엇을 감수해야 할까앞선 글에서 실제 사례를 통해“왜 어떤 팀은 쿠버네티스를 쓰고, 어떤 팀은 안 쓰는지”를 살펴봤다.그 다음 단계에서 거의 항상 등장하는 선택지가 관리형 쿠버네티스다.직접 클러스터를 만들고 운영할 것인가아니면 클라우드가 관리해주는 쿠버네티스를 쓸 것인가이 글에서는 **관리형 쿠버네티스(EKS, GKE)**를막연히 “편하다”라고 보기보다,편해지는 만큼 무엇을 넘겨주고 무엇을 감수해야 하는지를 중심으로 정리한다.관리형 쿠버네티스란 무엇이 다른가관리형 쿠버네티스의 핵심은 단순하다.쿠버네티스 Control Plane 운영을 클라우드에 맡긴다.즉, 다음을 직접 관리하지 않아도 된다.API Server 고가용성etcd 관리Control Plane ..

쿠버네티스, 언제 도입하는 게 맞을까— 도입 전에 반드시 고민해야 할 포인트들로컬 실습까지 한 번이라도 직접 해봤다면,이제 이런 질문이 자연스럽게 나온다.“우리 서비스에도 쿠버네티스를 써야 할까?”“지금 도입하는 게 맞는 시점일까?”“아직은 과한 선택은 아닐까?”이 글에서는쿠버네티스를 어떻게 쓰는지가 아니라,언제 쓰는 게 합리적인지를 중심으로 정리한다.도입을 권유하기보다는, 판단 기준을 분명히 하는 데 초점을 둔다.쿠버네티스는 문제를 해결하기 위해 나온 도구다먼저 전제를 하나 깔고 가야 한다.쿠버네티스는 “좋아서 쓰는 기술”이 아니라“특정 문제를 해결하기 위해 쓰는 도구”다.다시 말해,아직 겪지 않는 문제를 미리 해결하려고 도입하면복잡도만 늘어날 가능성이 크다.그래서 도입 여부를 판단할 때는“지금 우리가..

로컬에서 쿠버네티스 연습하는 방법, minikube와 kind 어떻게 다를까앞선 글까지 쿠버네티스의 개념과 운영 관점을 한 바퀴 훑었다면,이제 자연스럽게 이런 질문이 나온다.“이걸 로컬에서 연습할 수는 없을까?”“운영 클러스터에 바로 실험하기는 부담된다”“구조를 손에 익히려면 어떤 환경이 좋을까?”이 글에서는 로컬 개발 환경에서 쿠버네티스를 연습하는 대표적인 방법인minikube와 kind를 중심으로,각각 어떤 상황에 잘 맞는지 정리한다.로컬 쿠버네티스 환경이 필요한 이유쿠버네티스는 문서만 읽어서는 감이 잘 안 온다.실제로 다음 작업들을 해봐야 구조가 연결된다.Pod가 뜨고 사라지는 흐름Deployment 업데이트 과정Service와 Ingress 동작 방식리소스 설정에 따른 변화운영 클러스터에서 이런 ..

쿠버네티스 운영을 덜 아프게 만드는 설계와 습관앞선 글들에서Pod 장애, OOMKilled, Evicted, Node 문제까지 살펴봤다.이쯤 되면 자연스럽게 이런 생각이 든다.“매번 터지고 나서 고치는 게 맞나?”“처음부터 덜 아프게 운영할 수는 없을까?”이 글에서는쿠버네티스를 잘 쓰는 기술이 아니라덜 고생하면서 운영하기 위한 설계와 습관을 정리한다.화려한 패턴보다는, 실제로 도움이 되는 기본에 집중한다.1. 모든 것은 “기본값에 맡기지 않는다”쿠버네티스는 기본값이 많다.문제는 이 기본값들이 운영 환경에 최적화되어 있지 않다는 점이다.대표적인 예시는 다음과 같다.resources 미설정readiness/liveness probe 미설정replicas = 1처음에는 편하지만,운영 단계로 가면 거의 항상 문..

쿠버네티스에서 로그와 모니터링은 왜 더 중요할까HPA까지 설정했다면,이제부터는 “문제가 생겼을 때 어떻게 알아차릴 것인가”가 가장 중요한 질문이 된다.쿠버네티스 환경에서는 단순히 서버에 접속해서 로그를 보는 방식이 잘 통하지 않는다.Pod는 수시로 생성되고 사라진다문제가 발생한 Pod가 이미 사라졌을 수도 있다노드 단위가 아니라 서비스 단위로 상황을 봐야 한다그래서 쿠버네티스에서는로그(Log) 와 모니터링(Monitoring) 을 별도의 영역으로 명확히 나눠서 다룬다.로그와 모니터링은 다르다먼저 이 두 개념을 구분하는 게 중요하다.로그는 “무슨 일이 있었는지”,모니터링은 “지금 상태가 어떤지”를 보여준다.로그(Log)애플리케이션이 남긴 텍스트 기록에러 원인, 요청 흐름 추적문제 발생 이후 분석에 주로 사..

쿠버네티스 자동 확장의 핵심, HPA는 어떻게 동작할까앞선 글에서 requests와 limits를 다뤘다면,이번에는 그 설정을 실제로 활용하는 기능인 HPA(Horizontal Pod Autoscaler) 를 살펴볼 차례다.쿠버네티스를 쓰는 이유 중 하나가“트래픽에 따라 자동으로 늘고 줄어드는 구조”일 텐데,그 중심에 바로 HPA가 있다.다만 HPA는 설정만 해두면 마법처럼 동작하는 기능은 아니다.동작 원리를 이해하지 않으면,원하지 않는 타이밍에 스케일이 되거나 아예 안 되기도 한다.HPA란 무엇인가HPA를 한 문장으로 정리하면 다음과 같다.HPA는 “메트릭을 기준으로 Pod 개수를 자동 조절하는 리소스”다.여기서 핵심은 두 가지다.무엇을 기준으로 판단하는가Pod 개수를 어떻게 조절하는가HPA는 Depl..

쿠버네티스 리소스 관리의 핵심, requests와 limits 이해하기ConfigMap과 Secret으로 설정을 분리했다면,이제는 애플리케이션이 얼마나 많은 리소스를 써도 되는지를 고민해야 한다.쿠버네티스를 운영하다 보면 이런 상황을 자주 만난다.특정 Pod 하나가 CPU를 과도하게 사용한다메모리 사용량이 치솟으면서 다른 서비스까지 영향을 준다Pod가 갑자기 종료(OOMKilled)된다이 문제의 중심에는 requests와 limits가 있다.이 글에서는 쿠버네티스가 리소스를 어떻게 바라보는지부터 차근히 정리한다.쿠버네티스는 리소스를 “나눠 쓰는 환경”이다쿠버네티스 클러스터의 Node는 보통 여러 Pod가 함께 사용한다.즉,CPU메모리같은 자원은 공유 자원이다.아무 설정 없이 Pod를 띄우면,한 Pod가 ..

쿠버네티스 네트워킹의 핵심, Service와 Ingress 이해하기Deployment, StatefulSet 같은 워크로드를 이해했다면다음으로 막히는 지점은 거의 항상 네트워킹이다.Pod IP는 왜 계속 바뀌는지외부 요청은 어떻게 Pod까지 들어오는지Service랑 Ingress는 정확히 뭐가 다른지이 글에서는 쿠버네티스 네트워킹의 중심이 되는 Service와 Ingress를“요청이 들어와서 Pod에 도달하는 흐름” 기준으로 정리한다.Pod IP를 직접 쓰지 않는 이유쿠버네티스에서 Pod는 일시적인 존재다.재배포 시 삭제되고 새로 생성된다장애가 나면 다른 Node에서 다시 뜬다그때마다 IP가 바뀐다즉, Pod IP는 신뢰할 수 있는 접근 수단이 아니다.그래서 쿠버네티스는Pod 앞에 항상 고정된 접근 지점..

StatefulSet과 DaemonSet, 언제 어떤 워크로드를 써야 할까Deployment까지 이해했다면, 이제 쿠버네티스의 워크로드 개념 중 조금 성격이 다른 두 가지를 볼 차례다.바로 StatefulSet과 DaemonSet이다.이 둘은 Deployment만으로는 해결하기 어려운 요구사항을 다루기 위해 존재한다.실무에서 자주 쓰이진 않지만, 필요해지는 순간이 분명히 있는 리소스다.Deployment로 해결되지 않는 요구사항들실제로 쿠버네티스를 쓰다 보면 이런 요구가 나온다.Pod마다 고정된 이름과 순서가 필요하다Pod마다 각각의 스토리지를 가져야 한다특정 애플리케이션은 모든 Node에서 반드시 하나씩 실행되어야 한다이런 요구를 Deployment로 억지로 해결하려고 하면설정이 복잡해지고, 운영이 불..

쿠버네티스 배포의 핵심, Deployment와 ReplicaSet 이해하기앞선 글에서 Pod, Node, Cluster 같은 기본 구조를 살펴봤다.이제부터는 실제로 쿠버네티스를 쓰면서 가장 자주 만나게 되는 개념으로 넘어간다.바로 Deployment와 ReplicaSet이다.쿠버네티스에서 애플리케이션을 배포한다고 할 때,대부분의 경우 직접 Pod를 만들지는 않는다.대신 Deployment를 정의하고, 나머지는 쿠버네티스에 맡긴다.왜 Pod를 직접 만들지 않을까처음 쿠버네티스를 접하면 이런 생각이 든다.“컨테이너 하나 띄우면 되는데 Pod만 만들면 되지 않나?”“굳이 Deployment까지 써야 하나?”기술적으로는 가능하다.하지만 운영 관점에서는 거의 의미가 없다.Pod는 다음과 같은 특성을 가진다.언제든..