본문 바로가기
반응형

K8S109

Kubernetes AWS ALB/NLB 구성 yaml 1. AWS ALB Ingress 구성1.1 아키텍처 개요 특징✅ hostNetwork 불필요✅ externalTrafficPolicy 무관 (Service 안 거침)✅ Source IP: X-Forwarded-For 헤더로 전달1.2 Target Type 비교IP Mode (기본/권장)alb.ingress.kubernetes.io/target-type: ipALB → Pod IP 직접 (Service 거치지 않음) 항목 설명트래픽 경로ALB → Pod IP 직접Service 타입ClusterIP로 충분hostNetwork불필요externalTrafficPolicy무관요구사항AWS VPC CNI (Pod가 VPC IP 사용)Instance Modealb.ingress.kubernetes.io.. 2026. 1. 26.
Kubernetes hostNetwork & externalTrafficPolicy - AWS ALB, NLB 에서 사용하는가? 1. hostNetwork1.1 개요hostNetwork: true는 Pod가 호스트(노드)의 네트워크 네임스페이스를 직접 사용하도록 하는 설정. 1.2 동작 비교hostNetwork: false (기본값) hostNetwork: true 1.3 설정 예시apiVersion: v1kind: Podmetadata: name: hostnetwork-podspec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet # hostNetwork 사용 시 필수 containers: - name: app image: nginx ports: - containerPort: 80 # 노드의 80 포트에 직접 바인딩1.4 특징 비교 항목 hostNe.. 2026. 1. 26.
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.
쿠버네티스 캐스케이딩 삭제(Cascading Deletion) 쿠버네티스에서 리소스를 삭제할 때,“부모 리소스를 지우면 자식 리소스는 어떻게 될까?”이 동작을 결정하는 메커니즘이 바로 **캐스케이딩 삭제(Cascading Deletion)**다.운영 중 Deployment, Job, ReplicaSet을 삭제하다 보면Pod가 함께 사라지거나, 남아 있거나, 삭제가 멈춰 있는 상황을 자주 마주하게 된다.이 글에서는 그 이유를 구조적으로 정리한다.1. 캐스케이딩 삭제란?캐스케이딩 삭제는부모 리소스를 삭제할 때, 그에 의해 관리되는 하위 리소스를 함께 삭제할지 여부를 결정하는 방식이다.쿠버네티스는 리소스 간 관계를 OwnerReference로 관리한다.예시 구조:Deployment └─ ReplicaSet └─ PodDeployment를 삭제하면:ReplicaSe.. 2026. 1. 22.
Kubernetes는 가상화 도구인가? 결론부터 말하자면 아니다. 쿠버네티스를 공부하다 보면 자연스럽게 이런 질문에 도달한다.containerd는 쿠버네티스의 커널인가?containerd는 가상화 OS인가?커널을 가상화하는 도구라고 볼 수 있나?그렇다면 Kubernetes 자체는 가상화인가?이 글은 위 질문들을 하나의 사고 흐름으로 정리해,개념을 명확히 분리하는 것을 목표로 한다.1. 리소스를 실제로 제어하는 주체는 누구인가쿠버네티스에서 파드에 CPU·메모리 제한을 설정하면,이를 직접 집행하는 주체는 kubelet이 아니다.실제 집행자: 리눅스 커널집행 기술: cgroup정책 전달자: kubeletkubelet은 파드 스펙을 해석해“이 컨테이너는 CPU 500m, 메모리 1Gi”라는 정책을 커널에 전달할 뿐이다.즉, 리소스 제어의 본질은 언제.. 2026. 1. 22.
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.
k9s 사용법 - v.50.x 목차 1. 설치 (Windows)# Chocolateychoco install k9s# Wingetwinget install k9s# Scoopscoop install k9s현재 최신 버전: v0.50.162. 기본 실행 옵션k9s # 기본 실행k9s --context prod-cluster # 특정 컨텍스트로 시작k9s -n kube-system # 특정 네임스페이스로 시작k9s --readonly # 읽기 전용 모드k9s --kubeconfig /path/to/config # 특정 kubeconfig 사용k9s -l debug # 디버그 로그 활.. 2025. 12. 31.
kubernetes의 Request ― startup peak, steady-state, HPA 사이에서의 현실적인 해답Kubernetes(EKS)를 운영하다 보면 거의 반드시 부딪히는 질문이 있다.“request는 평소 사용량 기준으로 잡는 게 맞지 않나?”“그런데 그렇게 하면 startup 시에 Pod가 안 뜨는 것 같은데?”“그럼 request는 HPA용 수단 말고 무슨 의미가 있지?”이 글은 resources.requests의 진짜 역할,startup peak 때문에 발생하는 오해,그리고 startup peak를 request에 포함하지 않고도 안전하게 운영하는 구조를운영 경험 관점에서 하나로 정리한다.1. request에 대한 가장 흔한 오해많은 사람들이 처음에 이렇게 이해한다.“request는 초기 요청량이고,이걸 초과하면 Po.. 2025. 12. 23.
Kubernetes HPA 설계, 웹 API는 정말 CPU-Only가 표준일까? Kubernetes에서 애플리케이션 스케일링을 설계할 때 가장 많이 쓰는 네이티브 오토스케일러가 HPA(Horizontal Pod Autoscaler)입니다.하지만 실제 운영 환경에서는, 스케일링 지표로 무엇을 선택해야 하는가가 장애 안정성과 비용 효율을 좌우합니다.운영 엔지니어들 사이에서는 “대부분 웹 API는 CPU-Only로 scaling한다”는 주장도 있고, “메모리도 트래픽에 따라 늘어난다”고 말하는 경우도 있습니다.이 글에서는 이런 논쟁의 핵심을 짚고, 최근 업계 표준 흐름과 함께 올바른 설계 레이어 분리 원칙을 정리해봅니다.1. “HPA 설계를 CPU-Only로 하는 게 좋은 선택인가?” 라는 질문의 본질클러스터 운영자라면 한 번쯤 이런 질문을 해봤을 거예요.“Kubernetes HPA 설정.. 2025. 12. 2.
반응형

티스토리툴바