하얀잔디

파드 상태별 확인방법 정리

배포하면 종종 파드 에러뜸. CrashLoopBackOff나 Error.. 한번에 보고 뭔지 알게 잠시 정리!! CrashLoopBackOff 컨테이너가 실행은 되는데 바로 죽음(exit) → kubelet이 재시작 반복하다가 백오프(재시작 간격 증가). 앱 설정/환경변수 누락 → 즉시 종료설정 파일(ConfigMap/Secret) 잘못됨 (nginx conf 문법, upstream DNS 등)DB/Redis 등 의존성 연결 실패 후 프로세스 종료커맨드/엔트리포인트 잘못됨OOMKilled(메모리 부족)로 죽고 다시 올라옴 Error 뜻: Pod가 정상 Running으로 못 가고 컨테이너 생성/시작 과정에서 오류로 멈춤(원인은 이벤트에 나옴) ErrImagePull, ImagePullBackO..

Rolling Update & Roll BackRollout처음 deployment 를 생성하면, rollout 을 만들어내고, 새로운 deployment revision 을 만든다.배포가 새로이 될 때마다 버전업이 되고, Deployment에 발생하는 변화를 추적하고, 필요 시 이전 버전으로 원복 가능[ command ]kubectl rollout status deployment/[deployment명]kubectl rollout history deployment/[deployment명]Deployment 전략Recreate 전략실행 중인 인스턴스들 삭제, 새로운 인스턴스들 배포이전 버전이 다 삭제되고 새로운 버전이 생성되기 이전에 응용 프로그램이 다운됨 (서비스 불가)Rolling Update 전략 ..

요즘 작업하면서 들었던 생각임.db에 쓸데없는 쿼리 돌아가고 있는지,불필요하게 파싱하는 로직이 많은지 이런 거. 항상 느끼지만불필요한 걸 줄이는 게 어디서든 제일 중요한 듯함. 지금 서비스 구조를 보니까모든 요청마다 DB를 한 번씩 조회하는 공통 로직이 있었고,유저 정보를 전역(global)으로 처리하는 구조도 있었음.사실 요청마다 꼭 필요하지도 않은데습관처럼 들어가 있던 로직들이었음. 사실 요청마다 꼭 필요하지도 않은데습관처럼 들어가 있던 로직들이었음.그래서 이번에 모든 요청에서 무조건 실행되던 DB 조회 로직 제거 전역 user 처리 방식 제거하고 요청 단위 data 객체로 대체 결과적으로서버 부담도 줄고,동시 요청에서 발생할 수 있는 이상한 문제들(레이스 컨디션 같은 거)도 같이 제거됨. 교훈..

alias k='kubectl'export do='--dry-run=client -o yaml' 문제 ) Configure kubelet hosting to start a pod on the nodeTask :Node: hk8s-w1pod Name: webimage: nginx 이름에 configure kubelet 같은거 있으면 static pod 문제임. -> k run web --image=nginx $do 하기 -> yaml 저장해놓기 ( 시험에서 저장 가능) Static Pod = kubelet이 파일 보고 직접 띄우는 Pod -> 그냥 독립적인 파드!!! 하는법 : /etc/kubernetes/manifests들어감 ssh node01 sudo -i cd /etc/kuberne..

가능!! kubectl config get-contexts를 치면됨. 그리고, 다른곳에서 당겨오고싶으면, 다른곳에서 sudo cat /etc/rancher/k3s/k3s.yaml 한 값을 이런곳에 저장함.~/.kube/k3s-dev.yaml 그 후에 이거 치고export KUBECONFIG=~/.kube/config:~/.kube/k3s-dev.yaml 조회하면 2개뜸!! kubectl config get-contexts 그러면 실제로 '노드'는 클러스터 1개지만, 여러개 조종 가능.

사내에서 클라이언트 로그들을 수집해달라는 말이 있었다! 클라이언트 자체에서 로그를 기기에 담긴했었는데, 실제로 유저들이 겪는 불편함 ( VOC로 안들어오는 ) 을 체크하고, 주요 기능의 에러율을 모니터링 하고자 하는 취지였다. 그래서 우선 그냥 쉽게 생각이 든건 다음과 같았다. 클라이언트 -> 서버로 API 쏘고 서버에서 DB 받으면 매우 easy. good~~ 빠르게 만들 수 있고, 조회도 쉬운 장점이 있음. 다만 바로 DB에 쌓는 방식의 고민하지만 클라이언트 로그 특성상,발생량이 많아질 수 있고에러 / 이벤트 / 트래킹 로그가 뒤섞일 수 있으며단순 조회보다 집계·비율·추이 분석이 더 중요함이라는 점을 고려하면일반 서비스 DB에 그대로 적재하는 방식은장기적으로 부담이 될 수 있다고 판단했음. 현재 ..

예전 NHN 기술면접때 당황했던 질문이 있다. '한 파드에 여러 컨테이너가 있는 경우가 있을까요?' 나는 그때당시 1파드 = 1컨테이너 말고는 생각해본적이없었기에 얼버무렸다.. 한 파드에 여러 컨테이너? 있음쿠버네티스에서 Pod는 컨테이너의 실행 단위이지컨테이너 1개만 올리는 단위는 아님.실제로 한 파드에 여러 컨테이너를 두는 패턴이 존재함.대표적인 예가 바로 사이드카(sidecar) 패턴임. 왜 굳이 한 파드에 여러 컨테이너를 두나?핵심 이유“같이 떠야 하고, 같이 죽어야 하고, 리소스를 공유해야 하는 경우”Pod 안의 컨테이너들은 다음을 공유함:네트워크 (localhost)볼륨라이프사이클그래서 논리적으로 하나의 애플리케이션처럼 동작해야 할 때여러 컨테이너를 한 파드에 묶음. 1) 로그 수집 사이드..

300Mbps가 설정되어있었음.. 실제로는 그러면 40Mb/sec인데, exe 파일이 77메가라 다운시에 느림... 앞서 리포팅한 TC 도입이 최고인것같은데, 개별적으로 트래픽 속도를 늦추는 방법도 있어서 우선 메모하자. nginx 설정만으로는 전체 트래픽을 나눠서 보장하는 QoS는 불가함FILE 트래픽에 대해 개별 커넥션/요청 단위 제한만 가능함가능한 설정 범위limit_rate: 파일 1건(커넥션)당 전송 속도 제한limit_conn: 파일 동시 처리 커넥션 수 제한limit_req: 파일 요청 빈도 제한위 설정으로 파일 트래픽 폭주 시API/WEB 트래픽 영향 완화 가능GW 전체 대역폭을 파일이 독점하는 현상은 일부 완화됨단, FILE 트래픽 전체 합산 300Mbps 제한이나FILE 외 트래픽 ..

tc = 리눅스 인터넷 속도 관리자 -> 개발자 말고 인프라쪽에서 하는거임. tc는 운영체제 단에서, 이 트래픽은 느리게, 저 트래픽은 빠르게”를 직접 정하는 도구임. “파일 다운로드는 최대 300Mbps까지만 쓰고, 나머지(API/웹)는 그 영향 안 받게 해줘”이걸 운영체제 수준에서 해주는 게 tc야. Nginx 설정과 tc의 차이 구분Nginx limit_ratetctc레벨애플리케이션 운영체제(커널)기준URL / location포트, IP, 인터페이스보장❌ (느리게만 함)✅ (대역폭 분리/보장 가능)“파일 때문에 다른 트래픽 굶지 않게”❌✅ 정답 그럼 Nginx 설정으로는 어떻게 할까?? -> 다음편에,,,

k3s의 기본 Ingress Controller임. 외부 트래픽 → 서비스로 라우팅해주는 역할 NodePort + Ingress 역할을 같이 함 외부 → NodeIP:NodePort → Traefik Service → Ingress Rule → Kubernetes Service → Pod 보통 이런식으로 감. 지금 나의 경우에는 3000에서 외부 5000으로 간다는 가정하에 뭘 바꿔야하는지 보자. [Client] ↓ NodeIP:3000 ↓ Traefik EntryPoint :3000 ← 수신 (Traefik) ↓ IngressRoute ↓ Service (ext-backend) ↓ Endpoints (172.31.99.10:5000) ← 목적지 ..