본문 바로가기
반응형

Kubernetes46

Azure AKS 요금제와 운영 선택지 정리 AKS는 “요금제 + 운영 방식 + 네트워크”를 함께 선택하는 서비스단순히 “관리형 Kubernetes”를 선택하는 서비스가 아니다.실제로 AKS를 구성할 때는 항상 다음 세 가지를 동시에 결정하게 된다.운영 모델 (기존 AKS vs Automatic)컨트롤 플레인 요금제(SKU)네트워크 방식이 글은 그중에서도 기존 AKS(Basic / Default)를 기준으로요금제와 네트워크, 그리고 운영환경에서의 현실적인 선택 흐름을 정리한다.1. AKS의 큰 구조부터 정리AKS는 먼저 운영 모델로 나뉜다.기존 AKS (Basic / Default)AKS Automatic이 글의 범위는 기존 AKS다.기존 AKS의 핵심 개념은 명확하다.Azure는 Kubernetes 컨트롤 플레인만 관리하고, 노드와 운영 판단은 .. 2026. 2. 5.
왜 여러 회사에서 AKS는 불안정하고 EKS는 안정적으로 느껴졌을까 “왜 AKS는 자잘한 오류가 많고, EKS는 더 안정적으로 느껴질까?”쿠버네티스를 여러 회사에서 운영해 본 엔지니어들 사이에서 자주 나오는 말이 있다.“이상하게 AKS는 자잘한 문제가 많고,EKS는 그냥 조용히 잘 돌아간다.” 1. 반복된 실무 체감: “우연이 아니라 패턴”개인적으로 여러 회사를 거치며 공통적으로 느낀 점은 명확했다.AKS:작은 오류가 잦음“완전히 죽진 않았는데 뭔가 이상한 상태”가 자주 발생운영자가 계속 개입해야 함EKS:평소에는 매우 조용함장애가 아예 없다는 건 아니지만 빈도가 낮음문제가 생기면 비교적 명확한 원인이 드러남이 체감이 여러 조직에서 반복되었다면,이는 개인의 운이나 환경 문제가 아니라 플랫폼 구조의 차이로 보는 게 합리적이다.2. SLA 수준에서 이미 시작되는 차이기본.. 2026. 2. 5.
Kubernetes Windows 지원: 기능 비교와 스케줄링 방식 정리 이 글은 Kubernetes 공식 문서인windows/introwindows/user-guide를 기준으로 Windows 지원을 기능 단위로 비교하고,Windows 파드가 실제로 어떻게 스케줄링되는지를 기술적으로 정리한다.1. Kubernetes Windows 지원 기능 비교클러스터 구성 요소 구성 요소LinuxWindowsControl Plane✅ 지원❌ 미지원Worker Node✅ 지원✅ 지원혼합 클러스터–✅ 가능Windows는 Worker Node 전용Control Plane 컴포넌트(kube-apiserver, etcd 등)는 Linux 필수컨테이너 런타임항목LinuxWindowscontainerd✅✅Docker❌ (deprecated)❌격리 방식cgroups + namespacesProcess .. 2026. 1. 23.
Kubernetes에서 Stateful 앱에 Blue-Green 배포를 적용할 수 있을까? 들어가며Kubernetes를 운영하다 보면 이런 고민을 하게 됩니다."우리 앱은 데이터를 로컬에 저장해야 하는데, Blue-Green 배포도 하고 싶어요"결론부터 말하면, PVC 고정 + HPA + Blue-Green을 동시에 만족하는 깔끔한 방법은 없습니다. 하지만 이 문제를 해결하는 과정에서 Kubernetes 배포 전략의 본질을 이해할 수 있었습니다.Kubernetes 워크로드 리소스 복습먼저 기본기를 짚고 가겠습니다.네 가지 주요 워크로드리소스핵심 목적스케줄링ReplicaSetPod 복제본 수 유지임의 노드DeploymentReplicaSet + 롤링 업데이트/롤백임의 노드StatefulSet상태 유지 (고유 ID, PVC)순차적DaemonSet모든 노드에 1개씩노드당 1개 핵심은 Deployme.. 2026. 1. 19.
Kubernetes Pod 부팅 스파이크, 어떻게 해결할까? 이전에 부팅스파이크 조절이 어려웠는데 kubernetes 1.35v 가 나오면서 새 기능인 In-Place Resize 으로 조절이 가능해졌습니다! 그에 대한 글 작성 시작!~ 합니다! 들어가며Kubernetes에서 Pod을 운영하다 보면 한 가지 골치 아픈 문제를 만나게 됩니다. 바로 부팅 스파이크(Boot Spike) 입니다.Pod이 시작될 때 CPU 사용량이 급격히 치솟았다가 안정화되는 현상인데요, 특히 JVM 기반 애플리케이션(Spring Boot, Java)에서 자주 발생합니다. 📊 CPU 사용량 변화300m100m50m⚡ 스파이크 ▲ 시작 ▲ Ready → 정상 운영 이 글에서는 부팅 스파이크가 왜 문제가 되는지, 그리고 어떻게 해결할 수 있는지 정리해보겠습니다.부팅 스파이크가 .. 2026. 1. 15.
Kubernetes v1.35 변화 정리 December 17, 2025 에 kubernetes v1.35 이 출시 되었습니다. 개인적으로 기대했던 In-Place Pod Resize 이 GA로 되어서이전에 pod 실행, 재실행시 부팅 스파이크로 인한 request 조절을 못했는데 할수있게 되었습니다! 이에 대한 자세한내용은 https://rainbound.tistory.com/1357 에서 확인하세요! 이 버전은 “무엇을 더 제공할 것인가”보다 “무엇을 끝내고, 어떤 방향으로 정렬할 것인가” 입니다.핵심 키워드는 다음 네 가지다.재시작 없는 리소스 변경런타임 구조 정리리소스 제어의 예측 가능성리눅스 네이티브 네트워크 스택으로의 수렴1. v1.35에서 새로 추가·안정화된 기능1️⃣ In-Place Pod Resize (GA)기능 요약실행 중인.. 2026. 1. 15.
Kubernetes에서 Prometheus 장기 저장 전략(Thanos vs Grafana Mimir ) 쿠버네티스에서 모니터링을 구성할 때 대부분 Prometheus로 시작한다.하지만 클러스터와 서비스가 늘어나면 곧 다음 질문에 부딪힌다.“Prometheus 메트릭을 몇 달~몇 년 보관하려면 어떻게 해야 하지?”이 글에서는 Prometheus 장기 저장을 위한 대표적인 두 솔루션Thanos 와 Grafana Mimir 를 중심으로각각 무엇인지구조적 차이어떤 상황에서 적합한지Prometheus 단독과 비교리소스 사용 관점의 차이를 쿠버네티스 기준으로 정리한다.1. Prometheus 단독의 한계Prometheus는 기본적으로 로컬 TSDB(Local Disk) 기반이다.장점설치/운영 단순Kubernetes 생태계 표준빠른 쿼리 성능한계장기 보관(수개월~수년)에 부적합디스크 비용 증가단일 인스턴스 병목멀티 클.. 2026. 1. 2.
kubernetes에서 Pod requests / limits Tunning 실사용량 대비 Best Practice와 운영 튜닝 방법 정리Kubernetes를 운영하다 보면 거의 반드시 마주치는 질문이 있다.“Pod의 CPU / Memory requests 와 limits를 실제 사용량 대비 어느 정도로 잡는 게 맞을까?”이 글에서는숫자로 보는 Best Practice운영에서 실제로 조절하는 방식자주 터지는 함정들을 표 중심으로 정리한다.1️⃣ requests / limits 역할 한 번에 정리 구분 역할 운영에서 의미requests스케줄러 기준 예약값노드 배치, 오토스케일 판단 기준CPU limitCPU 상한초과 시 throttling (지연 증가)Memory limit메모리 상한초과 시 OOMKill (컨테이너 재시작)핵심 요약requests = “이 Pod가 최소로 필요.. 2025. 12. 30.
Kubernetes 이벤트 기반 오토스케일링, KEDA로 트래픽과 비용을 동시에 최적화하기 Kubernetes 운영을 하다 보면 스케일링의 기준을 CPU/메모리 사용률이 아닌, 비즈니스 이벤트로 잡아야 하는 순간이 옵니다.메시지 큐의 잔량, API 호출 급증, 배치 Job 트리거 등 실제 서비스 부하의 원인을 기준으로 파드를 조정하고 싶다면, KEDA가 훌륭한 선택지가 됩니다.1. KEDA란? — Event-Driven Autoscaling의 등장 배경Kubernetes 기본 오토스케일링인 **HPA(Horizontal Pod Autoscaler)**는 CPU/메모리 기반 스케일링엔 최적이지만,다음과 같은 한계가 있습니다.지표가 실제 서비스 부하 원인과 간접적비동기/배치 워크로드에서는 Scale-to-Zero 적용 어려움외부 이벤트 소스(메시지 큐, 스트림 등)를 스케일링 기준으로 삼기 복잡이.. 2025. 12. 2.
Kubernetes 파드 리소스 최적화 자동 추천, Goldilocks로 시작하는 근거 기반 운영 Goldilocks는 Kubernetes 워크로드의 CPU/메모리 request와 limit 값을 자동으로 추천해주는 오픈소스 도구입니다. “과하지도, 부족하지도 않은 딱 맞는 값”을 제안한다는 의미에서 이름이 붙었습니다.어떻게 동작할까?Goldilocks의 분석 엔진은 VPA(Vertical Pod Autoscaler)를 활용합니다. VPA를 워크로드에 직접 적용하지 않아도 모니터링 모드로 활성화된 VPA 객체를 통해:파드의 실제 CPU/메모리 사용량트래픽이나 작업 부하에 따른 resource peak(피크 사용량)CPU limit 으로 인한 throttling(쓰로틀링) 발생 구간OOM(Out of Memory) 발생 가능 지점을 객관적으로 계산해냅니다.분석이 끝나면 Goldilocks Dashboa.. 2025. 12. 2.
Kubernetes에서 Vault로 비밀 다루기: Seal, Sync, 주입 들어가며클라우드 네이티브 환경에서 비밀 정보를 안전하게 다루는 것은 DevOps와 플랫폼 팀의 핵심 과제다. Kubernetes에서 HashiCorp Vault를 연동해 Secret을 주입하는 방식은 크게 3가지 흐름으로 나뉜다. 각 방식의 동작 주체, Secret 저장 위치, 갱신 전략이 완전히 다르다. 또한, Vault의 Seal/Unseal 개념은 Vault 서버의 보안 상태를 제어하는 관문 역할을 한다.🔒 Vault Seal / 🔓 Unseal 이란?Vault는 모든 Secret 데이터를 마스터 키(Master Key) 로 암호화하여 storage(기본적으로는 etcd가 아닌 Vault 자체 저장소)에 저장한다. 하지만 마스터 키가 평문으로 디스크에 저장되면 탈취 위험이 있기 때문에, Vaul.. 2025. 11. 27.
그림과 실습으로 배우는 쿠버네티스 입문 📘 서평: 《그림과 실습으로 배우는 쿠버네티스 입문》클라우드 환경에서 일반적인 가상머신 기반 구조를 쿠버네티스로 이전하면서,처음 쿠버네티스를 접하는 개발자에게 어떻게 이 기술을 이해시키고 익히게 할 수 있을까 고민하던 시점에 이 책을 만났습니다.개념을 설명할 때 ‘그림’만큼 강력한 도구는 없다고 생각합니다. 그래서 제가 작성하는 발표자료나 기술문서에도 늘 시각 자료를 넣습니다.이 책은 그런 면에서 정말 매력적이었습니다. 이름 그대로 ‘그림과 실습’ 중심으로 구성되어 있어,쿠버네티스를 처음 접하는 분들에게 개념을 시각적으로 쉽게 이해시켜 주고,직접 따라 하며 감각적으로 익힐 수 있도록 돕습니다.💬 만화로 시작하는 친숙한 접근 책의 챕터의 첫부분은 쿠버네티스 개념을 대화 형식의 만화로 소개합니다.지금까.. 2025. 11. 2.
반응형

티스토리툴바