태그: #troubleshooting
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 24 편
세 줄짜리 설정 파일이 GPU 4장을 일주일 동안 죽였다 — containerd 드롭인 병합의 진실
노드가 GPU를 광고하지 않았습니다. 설정 파일에는 nvidia 런타임이 멀쩡히 적혀 있는데 containerd config dump에는 없었습니다. 범인은 일주일 전에 넣은 세 줄짜리 레지스트리 설정이었고, 이유는 containerd의 imports 병합이 필드 단위가 아니라 플러그인 단위 통째 교체이기 때문이었습니다. 두 번 잘못 진단한 과정과, 결국 답을 준 실험을 그대로 옮깁니다.
2026-08-26 · 20 분 읽기 #kubernetes#containerd#gpu#nvidia#troubleshooting디버깅은 왜 대체가 어려운가 — 배제의 기술과 가설의 문장
디버깅은 코드를 쓰는 일과 방향이 반대입니다. 쓰기는 가능한 것을 하나 만들어 내는 일이고, 디버깅은 가능한 것들을 하나만 남을 때까지 지우는 일입니다. 이 글은 디버깅이 왜 검증 비용이 비싼 쪽에 남는지, 반증 가능한 가설을 어떻게 문장으로 쓰는지, 시스템을 계층으로 잘라 절반씩 좁히는 절차가 어떻게 작동하는지, 그리고 재현되지 않는 문제를 재현 대신 관측으로 공략하는 법을 다룹니다. 같은
2026-08-15 · 13 분 읽기 #career#skills#debugging#craft#troubleshootingGPU 장애 진단 플레이북 — 계층을 정해 놓고 내려간다
쿠버네티스에서 GPU 문제를 진단할 때 가장 큰 낭비는 순서 없이 아무 데나 찔러 보는 것입니다. 파드가 스케줄되지 않는 것, 파드는 떴는데 GPU가 안 보이는 것, 드라이버와 툴킷 버전이 어긋난 것, 메모리가 부족한 것, 노드에서 GPU가 사라지는 것은 서로 다른 계층의 문제라 확인 순서가 다릅니다. 이 글은 NVIDIA GPU Operator 공식 트러블슈팅 문서와 dcgm-exporte
2026-08-12 · 14 분 읽기 #gpu#kubernetes#troubleshooting#nvidia#gpu-operator국내 개발 블로그 명글 큐레이션 2 — 장애 회고와 트러블슈팅, 직접 열어 확인한 12편
한국 개발자가 가장 잘 쓰는 장르는 장애 회고입니다. p6spy가 DB 라우팅을 무력화한 사건, HTTP 타임아웃이 DNS 조회를 덮지 못한 이유, TCP 하프 클로즈가 중복 예외로 위장된 사례, MetalLB 설정 하나가 만든 클러스터 지연 스파이크, 힙 덤프로 OOM을 추적한 기록, JIT 워밍업으로 배포 직후 CPU 스파이크를 잡은 과정, 외래키가 부른 데드락, HikariCP 커넥션
2026-08-12 · 22 분 읽기 #curation#큐레이션#troubleshooting#postmortem#incidentConnection refused와 timeout의 차이 — TCP 수준에서 원인 좁히는 법
연결이 안 될 때 터미널이 돌려주는 메시지는 크게 두 갈래입니다. Connection refused는 상대가 RST를 돌려준 것이고, timeout은 보낸 SYN에 아무 응답이 없는 것입니다. 이 한 줄 차이가 프로세스 문제인지 경로 문제인지를 거의 결정합니다. tcpdump로 SYN과 RST를 직접 확인하는 법, SYN 재전송 간격으로 타임아웃 길이를 미리 계산하는 법, 리스너가 있는데도
2026-07-26 · 20 분 읽기 #network#tcp#troubleshooting#linux#kubernetes로드 애버리지가 CPU 사용률이 아닌 이유 — load average 24에 CPU는 30%일 때
uptime의 load average는 24를 넘겼는데 top의 CPU는 30%도 되지 않는 상황을 다룹니다. 리눅스의 로드 애버리지는 다른 유닉스와 달리 실행 대기(R) 태스크뿐 아니라 D 상태(uninterruptible sleep) 태스크까지 세기 때문에, 디스크나 NFS 대기만으로도 숫자가 치솟습니다. 세 숫자가 5초 샘플링과 지수이동평균으로 어떻게 만들어지는지, 코어 수로 나누는 관
2026-07-26 · 21 분 읽기 #linux#performance#load-average#psi#troubleshootingdig는 되는데 애플리케이션은 실패한다 — DNS 해석 순서부터 확인하는 법
dig로는 정상적으로 답이 오는데 애플리케이션만 이름을 못 찾는 상황은 버그가 아니라 구조입니다. dig와 nslookup은 /etc/hosts와 nsswitch.conf를 아예 거치지 않고 리졸버에 직접 질의하기 때문입니다. 애플리케이션이 실제로 밟는 경로를 nsswitch.conf부터 systemd-resolved 스텁 리졸버까지 따라가고, getent와 resolvectl로 같은 경로를
2026-07-26 · 21 분 읽기 #network#dns#linux#kubernetes#troubleshootingToo many open files 완전 해결 — ulimit을 올려도 안 되는 이유
서버 로그에 accept4 failed (24: Too many open files)가 찍히고 ulimit -n을 올렸는데도 그대로입니다. 이 증상 뒤에는 서로 독립적인 세 가지 한계가 있습니다. 프로세스별 RLIMITNOFILE, 시스템 전역 fs.file-max, 그리고 systemd 서비스의 LimitNOFILE이 셸의 ulimit 설정을 완전히 무시한다는 사실입니다. /proc/PID
2026-07-26 · 22 분 읽기 #linux#systemd#file-descriptor#troubleshooting#containersKubernetes Pod Pending 상태 해결 — 스케줄러가 남긴 거절 사유 읽는 법
파드가 Pending에서 몇 분째 넘어가지 않을 때, 스케줄러는 이미 거절 사유를 이벤트에 남겨 두었습니다. 0/5 nodes are available로 시작하는 그 문장을 정확히 해독하는 법부터 시작해 아홉 갈래 원인을 하나씩 배제합니다. 리소스 부족은 실제 사용량이 아니라 requests 총합으로 판정된다는 점, taint와 톨러레이션, 노드 셀렉터와 어피니티 불일치, PVC 미바인딩과
2026-07-26 · 20 분 읽기 #kubernetes#scheduler#pending#troubleshooting#autoscalingKubernetes ImagePullBackOff와 ErrImagePull 완전 해부 — 원인 문자열 하나로 끝내기
파드가 ErrImagePull을 거쳐 ImagePullBackOff에 머무는 상황을 원인별로 분해합니다. 두 상태가 같은 사건의 다른 단계라는 점, 그리고 kubectl describe의 Events 마지막 한 줄에 이미 정답이 적혀 있다는 점에서 출발합니다. 태그 오타, 프라이빗 레지스트리 인증 실패, 서비스어카운트에 시크릿이 안 붙은 경우, Docker Hub 익명 풀 레이트 리밋, 프록
2026-07-26 · 19 분 읽기 #kubernetes#imagepullbackoff#container-registry#troubleshooting#containerd용량이 남았는데 No space left on device — inode 고갈, 삭제된 열린 파일, 예약 블록
df는 여유 공간을 보여 주는데 파일 하나를 만들지 못하고 ENOSPC가 납니다. 원인은 거의 항상 다섯 가지 중 하나입니다. inode 고갈, 삭제됐지만 프로세스가 열고 있는 파일, ext4의 예약 블록, 다른 파일시스템이 겹쳐 마운트되어 보이지 않는 파일, 그리고 컨테이너의 오버레이 상한입니다. 각각을 df -i, lsof +L1, tune2fs, 바인드 마운트로 어떻게 확정하고 무엇으로
2026-07-26 · 25 분 읽기 #linux#filesystem#ext4#troubleshooting#storageKubernetes CrashLoopBackOff 원인별 진단과 해결 — 로그가 비어 있을 때 무엇을 봐야 하나
파드가 CrashLoopBackOff에 빠졌는데 kubectl logs는 아무것도 뱉지 않는 상황을 처음부터 끝까지 다룹니다. BackOff가 원인이 아니라 10초에서 5분까지 늘어나는 재시작 대기 시간이라는 정확한 의미부터, describe의 Last State와 Exit Code를 읽는 순서, 종료 코드 0/1/127/137/139/143이 각각 무엇을 뜻하는지 정리했습니다. 애플리케이션
2026-07-26 · 21 분 읽기 #kubernetes#crashloopbackoff#troubleshooting#kubectl#sre.gitignore가 작동하지 않을 때 — 원인 1위와 패턴 규칙 정독
무시 목록에 분명히 적었는데 파일이 계속 올라오는 이유는 대부분 하나입니다. 이미 추적 중인 파일에는 무시 규칙이 적용되지 않습니다. 이 글은 인덱스에서 빼는 정확한 명령과 그 명령이 동료의 작업 디렉터리에서 파일을 지운다는 부작용, 어느 규칙이 범인인지 Git에게 직접 물어보는 check-ignore 사용법과 추적 중인 파일에서는 아무것도 출력하지 않는 함정, 선행 슬래시와 후행 슬래시와
2026-07-26 · 19 분 읽기 #git#gitignore#troubleshooting#security#version-controlIngress 트러블슈팅 플레이북 — 502/504/404부터 TLS까지
Ingress에서 마주치는 대표 증상(404, 502, 503, 504, TLS 오류, 리다이렉트 루프, 413)을 증상별 진단 트리로 정리한 실전 플레이북입니다. 각 증상마다 kubectl/curl/로그 확인 명령과 해결책, 일반 디버깅 절차, 흔한 설정 실수 카탈로그, 체크리스트를 제공합니다.
2026-06-14 · 19 분 읽기 #ingress#kubernetes#nginx#troubleshooting#networking체계적 디버깅 — 추측이 아니라 추론으로 버그를 잡는 법
대부분의 디버깅은 훈련되지 않은 추측이다. 재현 · 격리 · 가설 · 검증 · 수정 · 확인이라는 핵심 루프, git bisect와 이진 탐색, 스택 트레이스를 제대로 읽는 법, 하이젠버그와 레이스 컨디션 같은 어려운 버그, 그리고 AI 에이전트와 함께 디버깅하는 법까지 — 추론으로 버그를 잡는 기술을 정리한다.
2026-05-14 · 38 분 읽기 #debugging#methodology#engineering-craft#git-bisect#observabilityDNS 완전 정복: 네임서버, DDNS, nslookup 실전 가이드 — 도메인 등록부터 트러블슈팅까지
DNS의 모든 것을 한 글에! 네임서버 동작 원리, 도메인 등록/이전 실전 가이드, DDNS로 집에서 서버 운영하기, nslookup/dig 완전 활용법, DNS 레코드 타입 총정리, DNS 보안(DNSSEC, DoH, DoT), 실전 트러블슈팅 10가지 시나리오까지.
2026-03-23 · 47 분 읽기 #dns#nameserver#ddns#nslookup#digsystemd 서비스 관리 완벽 가이드: Unit 파일 작성부터 트러블슈팅까지
systemd의 핵심 개념부터 Unit 파일 작성, 서비스 의존성 관리, 리소스 제한, 타이머, 로깅, 트러블슈팅까지 프로덕션 환경의 서비스 관리에 필요한 모든 것을 다룹니다.
2026-03-14 · 27 분 읽기 #systemd#linux#service-management#troubleshooting#devops네트워크 트러블슈팅 완벽 가이드 — 6부작 시리즈 개요
실무에서 마주치는 네트워크 문제를 체계적으로 진단하고 해결하는 6부작 시리즈의 인덱스 포스트입니다. DNS부터 클라우드 네트워크까지 전 계층을 다룹니다.
2026-03-08 · 13 분 읽기 #networking#troubleshooting#devops#sreDNS 트러블슈팅 완전 가이드 - 원리부터 쿠버네티스까지
DNS 동작 원리를 이해하고, 실무에서 자주 발생하는 DNS 문제를 체계적으로 디버깅하는 방법을 다룹니다. dig, nslookup 등 도구 활용법부터 Kubernetes CoreDNS 트러블슈팅까지 실전 예제와 함께 정리합니다.
2026-03-08 · 18 분 읽기 #networking#dns#troubleshooting#devops네트워크 성능 분석 완벽 가이드: 측정, 진단, 모니터링
네트워크 성능 지표의 이해부터 iperf3, mtr, ethtool 등 도구 활용, TCP 윈도우 분석, MTU 문제 해결, Prometheus/Grafana 모니터링까지 실무 네트워크 성능 분석 방법을 정리합니다.
2026-03-08 · 21 분 읽기 #networking#performance#monitoring#troubleshooting