mirabo01 님의 블로그

— 장애가 터지기 전에 먼저 보이는 것들관리형 쿠버네티스 장애 유형을 보면 공통점이 있다.대부분 갑자기 터진 것처럼 보이지만,사실은 그 전에 이미 신호를 보내고 있었다는 점이다.OOMKilled 전에 메모리는 계속 차오른다Evicted 전에 Node 리소스는 이미 임계치에 근접한다a서비스가 느려지기 전 CPU throttling은 먼저 발생한다이 글에서는쿠버네티스 운영에서 “최소한 이것만은 봐야 하는” 모니터링 신호들을우선순위 중심으로 정리한다.툴이 아니라 지표와 관점에 집중한다.모니터링의 목적부터 다시 잡자쿠버네티스에서 모니터링의 목적은 명확하다.“장애를 분석하기 위함”이 아니라“장애를 미리 알아차리기 위함”이다.그래서 다음 기준이 중요하다.지금 안 봐도 되는 지표는 무엇인가지금 반드시 봐야 하는 지표..

관리형 쿠버네티스에서 자주 겪는 장애 유형들— “클러스터는 멀쩡한데 서비스가 안 될 때”관리형 쿠버네티스(EKS, GKE)를 쓰기 시작하면이런 기대를 하게 된다.“이제 클러스터 장애는 신경 안 써도 되겠지”“적어도 쿠버네티스 자체가 문제일 일은 없겠지”절반은 맞고, 절반은 틀리다.Control Plane 장애는 줄어들지만,서비스 장애는 여전히 자주 발생한다.다만 양상이 조금 달라질 뿐이다.이 글에서는관리형 쿠버네티스 환경에서 실무적으로 가장 자주 겪는 장애 유형을원인과 함께 정리한다.관리형 쿠버네티스 장애의 특징온프레미스나 직접 구축한 쿠버네티스와 비교하면관리형 환경의 장애는 이런 특징을 가진다.Control Plane 문제는 거의 없다대신 워크로드·설정·리소스 문제가 대부분이다“클러스터는 정상”인데 서..

쿠버네티스 운영 비용 줄이는 현실적인 방법들— “리소스 설정만 잘해도 달라진다”관리형 쿠버네티스까지 도입했다면,다음으로 거의 반드시 나오는 말이 있다.“생각보다 비용이 많이 나온다”“리소스를 어디서 줄여야 할지 모르겠다”“아끼자니 불안하고, 쓰자니 비싸다”이 글에서는쿠버네티스 운영 비용을 줄이기 위한 실무적인 접근 방법을 정리한다.툴 나열이 아니라,현장에서 실제로 효과가 있었던 포인트들 위주다.쿠버네티스 비용은 왜 체감이 더 클까쿠버네티스 비용이 비싸게 느껴지는 이유는 단순하다.리소스가 “항상” 떠 있다requests 기준으로 서버가 잡힌다조금만 과하게 설정해도 누적된다즉,한 번의 과한 설정이 매달 비용으로 반복된다.쿠버네티스 비용 최적화는“대규모 튜닝”보다“작은 설정 정리”의 누적 효과가 크다.1. 가..

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

— 왜 어떤 팀은 쿠버네티스를 쓰고, 어떤 팀은 안 썼을까앞선 글에서는쿠버네티스 · 도커 컴포즈 · 서버리스를 이론적으로 비교했다.이번에는 한 단계 더 들어가서,실제 서비스 상황을 가정한 사례 중심으로 어떤 선택이 나왔는지를 살펴본다.중요한 건 “정답”이 아니라,어떤 조건에서 어떤 판단이 나왔는지다.실무에서 아키텍처를 결정할 때 가장 도움이 되는 부분이기도 하다.사례 1. 초기 스타트업의 MVP 서비스상황 요약사용자 수 적음기능 변경 잦음개발자 2~3명운영 전담 인력 없음이런 상황에서 가장 중요한 건빠른 개발과 낮은 운영 부담이다.선택: 서버리스 중심 구조이 경우 보통 다음 선택이 나온다.API: 서버리스 함수인증/스토리지: 관리형 서비스배포: 자동화된 CI왜 쿠버네티스를 안 썼을까클러스터 운영 자체가 ..

— 상황별로 어떤 선택이 현실적일까쿠버네티스 도입 시점을 고민하다 보면,자연스럽게 이런 비교로 이어진다.“굳이 쿠버네티스까지 가야 할까?”“도커 컴포즈로도 충분하지 않을까?”“차라리 서버리스가 더 맞는 건 아닐까?”이 글에서는쿠버네티스, 도커 컴포즈, 서버리스를기술 우열이 아니라 사용 맥락 기준으로 비교한다.실무에서 선택이 갈리는 지점을 중심으로 정리한다.비교의 전제: 같은 문제를 푸는 도구가 아니다먼저 짚고 가야 할 점이 있다.이 세 가지는 같은 문제를 다른 방식으로 푸는 게 아니라,애초에 풀려고 하는 문제의 범위가 다르다.그래서 “무조건 뭐가 낫다”는 비교는 의미가 없다.대신 어떤 상황에서 어떤 선택이 덜 아픈지를 보는 게 중요하다.도커 컴포즈: 가장 단순하고 빠른 선택도커 컴포즈는여러 컨테이너를 한..

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

로컬 쿠버네티스 실습 ③ Ingress로 외부 접근 구조 만들기앞선 실습에서는Deployment, Service, ConfigMap, 리소스 설정까지 적용해운영에 가까운 내부 구조를 만들었다.이번 단계에서는 그 서비스에외부에서 접근할 수 있는 진입점을 붙여본다.즉, Ingress를 통해 요청이 어떻게 들어오는지를 직접 확인하는 것이 목표다.왜 Service만으로는 부족할까이전 실습에서도 Service를 통해 Pod 접근은 가능했다.하지만 구조적으로 한계가 있다.서비스마다 포트를 따로 열어야 한다도메인 기반 분기가 어렵다HTTPS 처리를 Service 단에서 하기 까다롭다운영 환경에서는 보통Ingress 하나를 공통 진입점으로 두고,그 뒤에서 여러 Service로 트래픽을 나눈다.Ingress는 “외부 요..

로컬 쿠버네티스 실습 ② 운영에 가까운 형태로 확장해보기지난 글에서는Deployment와 Service만으로 가장 기본적인 배포 흐름을 따라가봤다.이번에는 그 구조를 조금만 확장해서,운영 환경에서 실제로 쓰이는 형태에 더 가깝게 만들어본다.이번 실습의 핵심은 다음 세 가지다.설정을 이미지에서 분리한다리소스 사용 범위를 명확히 한다배포가 어떻게 교체되는지 직접 확인한다이번 실습에서 추가할 요소들이전 실습 대비 추가되는 요소는 다음이다.ConfigMap으로 설정 분리requests / limits 설정롤링 업데이트 과정 확인여전히 예제 애플리케이션은 단순하지만,쿠버네티스를 쓰는 이유가 드러나는 지점을 직접 확인하는 게 목표다.1. 설정을 이미지에서 분리해야 하는 이유이전 실습에서는애플리케이션 설정이 이미지 ..

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