하얀잔디

느린 Pod로 요청이 가지 않게 할 수 있을까?

Kubernetes에서 여러 Pod를 운영하다 보면 특정 Pod만 CPU가 튀거나 응답이 느려지는 경우가 있음.Pod A → 50msPod B → 60msPod C → 3초기본 Kubernetes Service는 Pod C가 느리다고 해서 자동으로 해당 Pod를 제외해주지는 않음.HPA를 사용하면 CPU 증가에 따라 Pod를 추가할 수 있지만, 느린 Pod를 직접 피하는 방식은 아님.그래서 Service Mesh를 찾아봄. Linkerd Linkerd는 Pod에 Proxy를 붙여 서비스 간 통신을 관리함.특히 Latency-aware Load Balancing을 통해 최근 응답시간이 빠른 Endpoint를 선호하도록 트래픽을 분산할 수 있음. Pod A → 50msPod B → 60msPod C → 3..

Node JS 에서 나타났던 상황이지만 Java 등 모든 WAS서버에서 나올수 있는 상황 상황 DB 커넥션 풀이 꽉 차서 API가 504 뜨고, 완전 가벼운 API도 덩달아 느려지고, SequelizeConnectionAcquireTimeoutError까지 터짐. 원인 파보니 트랜잭션 하나를 안 닫고 있었음.문제 코드이미 있으면 그거 리턴, 없으면 새로 생성 패턴에서 나왔던 실수임.const findOrCreateRoom = async (userId: string) => { const transaction = await sequelize.transaction() // 커넥션 하나 확보 try { const existing = await Room.findOne({ where: { u..

Pod별 CPU / Memory 사용량을 확인하기 위해 Kubernetes의 kubelet cAdvisor metric을 활용함. cAdvisor는 각 Node의 10250 포트를 통해 metric을 제공하고 있어서, 해당 endpoint를 Prometheus에서 조회하도록 구성함. 다만 kubelet API이기 때문에 그냥 접근하지 않고 ServiceAccount + RBAC을 구성해서 인증/권한을 설정함.Prometheus ↓RBAC 인증 ↓kubelet :10250 ↓/metrics/cadvisor ↓Pod별 CPU / Memory 이후 Prometheus에서 cAdvisor metric을 수집하고 Grafana에서 namespace, pod 기준으로 조회하도록 구성함. CPU..

운영 서버 로그를 보다 보면 Vite 관련 요청이나 /.env, /.git, /admin 같은 이상한 외부 요청이 들어오는 경우가 있음.이런 요청이 들어왔다고 무조건 서버가 공격받았다고 볼 필요는 없음. 중요한 건 무엇을 요청했는가보다 서버가 무엇을 응답했는가임.1. 외부에서 불필요한 파일이 노출되지 않는지 확인특히 아래 파일들은 외부 접근이 불가능해야 함..env.git/.git/configvite.config.jspackage.jsondocker-compose.yml/.env → 200 OK처럼 실제 파일 내용이 반환된다면 바로 확인 필요.2. 개발 서버를 운영에 그대로 노출하지 않기Vite 개발 서버나 각종 개발용 포트를 외부에 그대로 열어두지 않는 게 중요함.운영에서는 보통Vite ↓npm bui..

쿠버네티스 노드 디스크 꽉 차면 Kubelet이 DiskPressure 걸어버리고 Pod 강제 퇴출 시작함 ㄷㄷ. 당황하지 말고 아래 순서로 빠르게 원인 잡고 용량 확보하면 됨. 1. 장애 노드 및 상태 확인어느 노드가 찌들어있는지, 튕겨 나간 Pod 있는지 먼저 확인. # 1. DiskPressure 발생 노드 확인kubectl get nodes -o custom-columns=NAME:.metadata.name,DISK_PRESS:.status.conditions[?(@.type=="DiskPressure")].status# 2. Evicted 상태 Pod 목록 확인kubectl get pods -A | grep Evicted 2. Root Cause 탐색 (노드 디렉터리 스캔) 해당 노드 SSH 접..

운영 중 디스크 사용량 증가하면 아래 순서로 확인하면 됨. 1. 전체 디스크 확인 df -h / 사용률 확인함. 보통 Use%가 80~90% 이상이면 원인 확인 필요함. 2. Docker가 얼마나 사용하는지 확인 docker system df 이미지, 컨테이너, 볼륨, 빌드 캐시별 사용량 확인 가능함. 상세 확인: docker system df -v 3. Docker 내부에서 어디가 큰지 확인 sudo du -xhd1 /var/lib/docker 2>/dev/null | sort -h 주로 확인할 디렉터리:overlay2 → 이미지/컨테이너 레이어containers → 컨테이너 로그volumes → Docker Volumeimage → Docker 이미지 메타데이터 4. 컨..

쿠버네티스로 이것저것 하다 보니 Docker 명령어를 잠깐 까먹을 뻔함.특히 Docker 환경에서 장애 상황을 확인할 때는 아래 4개 정도만 기억해두면 편함. 명령어 보는 것 질문docker ps -a컨테이너 상태뭐가 죽었지?docker inspect상세 상태/설정왜 이런 상태지?docker logs애플리케이션 로그앱에서 무슨 에러가 났지?docker eventsDocker 이벤트언제 죽고 다시 시작됐지? 장애 발생 시 대략적인 순서docker ps -a→ 죽거나 재시작하는 컨테이너 확인docker inspect → OOMKilled, Rest..

왜 했냐최근 prod 쪽 채팅 읽기 관련 캐싱 로직을 손봤음. 근데 dev 환경은 Redis 샤딩 구성이 prod랑 달라서(dev는 샤딩 안 됨) 배포했을 때 사이드 이펙트가 터질지 확신이 안 섰음. 한 번에 100% 밀어넣긴 쫄려서 트래픽 조금만 먼저 태워보려고 canary 세팅을 해봄.​​배경 파악k3s 클러스터 보니까 dev 네임스페이스에 linkerd가 이미 떠 있길래 레포를 뒤져봄. 확인해보니 linkerd 설치랑 dev 네임스페이스 linkerd.io/inject 어노테이션이 레포엔 없고, 예전에 서버에서 수동으로 kubectl apply / annotate 때려둔 흔적이었음. GitOps 안 붙은 순수 kustomize 레포라 이런 드리프트가 종종 생김. 온 김에 canary 배포 환경까지..

핵심 기존 k8s Service 1개 구조로는 트래픽 비율 제어 불가능 (기본 무작위 라우팅이라 V1/V2 알아서 50:50 분산됨).Linkerd TrafficSplit CRD를 쓰면 클라이언트 API 주소 변경 없이 트래픽 비율 정밀 제어 가능.구조 및 동작 방식 [Ingress] │ ▼[대표 Service (Apex)] │[Linkerd TrafficSplit] ─── (가중치 분산) ───┐ │ │ ▼ (90%) ▼ (10%)[Service-V1] [Service-V2] │ ..

쿠버네티스 클러스터 구축하고 내부 통신 모니터링이나 보안 세팅하다 보면 꼭 마주치는 게 서비스 메쉬(Service Mesh)랑 mTLS임. 매번 개념만 대충 알고 넘어가다가 이번에 Linkerd로 세팅하면서 정리해 봄. mTLS가 왜 필요할까? 보통 외부에서 Ingress/Gateway 들어오는 구간만 HTTPS(TLS) 걸어두면 보안 끝났다고 생각하기 쉬움.하지만 쿠버네티스 기본 Pod to Pod 통신은 암호화 안 된 순수 평문(HTTP)으로 돌아감. 만약 클러스터 내에 노드 하나가 뚫리거나 악성 컨테이너가 하나라도 뜨면? 내부 망에서 오가는 DB 패스워드, API 토큰, 사용자 데이터 전부 패킷 스니핑으로 그대로 노출됨. 일반 TLS (HTTPS): 클라이언트가 '이 서버 진짜 맞나?' 하고 서..