mirabo01 님의 블로그

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

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

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

쿠버네티스 자동 확장의 핵심, 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가 ..