mirabo01 님의 블로그

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

로컬 쿠버네티스 실습 ① 간단한 웹 애플리케이션 배포 흐름 따라가기minikube나 kind로 로컬 클러스터를 준비했다면,이제는 직접 하나 올려보는 단계가 가장 중요하다.이 글에서는 복잡한 예제 대신,컨테이너 하나Deployment 하나Service 하나이 세 가지만으로쿠버네티스에서 애플리케이션이 어떻게 배포되고 노출되는지를 처음부터 끝까지 따라가본다.실무에서 가장 자주 반복하는 기본 흐름이기도 하다.실습 목표와 전제이번 글의 목표는 다음이다.Deployment로 애플리케이션 배포Pod 생성과 관리 방식 확인Service를 통한 접근 구조 이해전제 조건은 다음 정도면 충분하다.로컬 쿠버네티스 클러스터(minikube 또는 kind)kubectl 사용 가능Docker 이미지 하나1. 예제 애플리케이션 준비..

쿠버네티스 네트워킹의 핵심, 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는 다음과 같은 특성을 가진다.언제든..

쿠버네티스 핵심 구성 요소 한 번에 정리하기 (Pod, Node, Cluster)지난 글에서는 쿠버네티스가 왜 등장했고 어떤 문제를 해결하려는지를 중심으로 살펴봤다.이번 글에서는 쿠버네티스를 이해하기 위해 반드시 넘어야 하는 핵심 구성 요소들을 정리한다.처음 쿠버네티스를 접하면 용어가 많아서 막막해지기 쉽다.하지만 구조를 단순하게 보면, 생각보다 복잡하지는 않다.이 글은 개념을 한 번에 정리하고 싶은 사람에게 도움이 되도록 구성했다.쿠버네티스 구성 요소를 바라보는 관점쿠버네티스를 이해할 때 가장 좋은 방법은 다음 질문에서 출발하는 것이다.컨테이너는 어디서 실행되는가누가 컨테이너를 관리하고 감시하는가문제가 생기면 누가 판단하고 조치하는가이 질문에 답하다 보면 자연스럽게 주요 구성 요소가 정리된다.Pod: ..

쿠버네티스란 무엇인가, 왜 요즘 더 중요해졌을까요즘 백엔드나 인프라 쪽 이야기를 하다 보면 쿠버네티스를 빼놓기 어렵다.단순히 “컨테이너 오케스트레이션 도구”라고 설명하기에는, 실제로 사용하는 범위와 영향력이 꽤 넓어졌다.이 글은 쿠버네티스를 처음 접하는 사람이나,도커까지는 써봤지만 그 다음 단계에서 막힌 개발자를 대상으로 한다.개념을 최대한 차분하게 정리하고, 왜 이 기술이 등장했고 어떤 문제를 해결하려는지부터 짚어본다.쿠버네티스는 어떤 문제를 해결하려고 나왔을까컨테이너 기술이 본격적으로 쓰이기 시작하면서, 애플리케이션 배포는 훨씬 가벼워졌다.하지만 컨테이너 개수가 늘어나기 시작하면 다른 문제가 생긴다.컨테이너를 여러 서버에 어떻게 나눠서 배치할지서버가 죽었을 때 컨테이너를 어떻게 다시 띄울지트래픽이 늘..