태그: #kubernetes

한국어English日本語中文

← 전체 글

• k3s 폐쇄망 설치 완전 가이드 — 이미지 tarball 반입부터 사설 레지스트리, 에이전트 조인까지

  인터넷 경로가 전혀 없는 폐쇄망에 k3s 클러스터를 세우는 전 과정을 명령어 단위로 정리합니다. 연결망 장비에서 airgap 이미지 tarball과 k3s 바이너리를 내려받아 체크섬 매니페스트를 만들고, 반입 매체에 무엇을 담을지 정하고, 이미지를 컨테이너 런타임 디렉터리에 배치한 뒤 INSTALLK3SSKIPDOWNLOAD로 설치 스크립트를 실행하는 흐름을 다룹니다. 이어서 registri

  2026-07-31 · 33 분 읽기 #kubernetes#k3s#air-gap#on-premise#containerd

• 폐쇄망 쿠버네티스 Day 2 운영 — 인증서 만료로 죽는 클러스터를 막는 법

  폐쇄망 클러스터가 실제로 죽는 원인은 대부분 화려한 장애가 아니라 인증서 만료입니다. 아무도 건드리지 않은 채 1년이 지나면 API 서버가 조용히 멈추고, 인터넷이 없으니 검색으로 해결할 수도 없습니다. 이 글은 설치 이후를 다룹니다. 만료를 죽기 전에 탐지하는 방법, kubeadm과 k3s의 인증서 갱신 및 CA 회전 절차, NTP 드리프트가 TLS와 etcd를 동시에 무너뜨리는 경로, 스

  2026-07-31 · 31 분 읽기 #kubernetes#air-gap#day2-operations#etcd#certificate

• 컨테이너 이미지 취약점 스캔 결과 읽는 법 — Critical 수백 개를 0으로 만드는 실제 방법

  이미지 스캐너를 처음 돌리면 취약점 수천 건이 나오고 그중 상당수가 Critical입니다. 이 리포트를 그대로 팀에 던지면 아무 일도 일어나지 않습니다. 이 글은 스캐너가 실제로 하는 일이 설치된 패키지 목록과 CVE 데이터베이스를 대조하는 것뿐이라는 사실에서 출발해, 벤더 백포트 패치 때문에 생기는 오탐과 배포판 보안 권고를 참조해야 하는 이유, 애플리케이션 코드의 취약점은 애초에 보이지

  2026-07-26 · 21 분 읽기 #security#container#docker#trivy#kubernetes

• ping은 되는데 큰 요청만 멈춘다 — MTU, MSS, PMTUD 블랙홀 해부

  작은 요청은 잘 되는데 큰 응답만 중간에 멈춰 버리는 증상은 거의 언제나 경로 MTU 문제입니다. TCP는 MSS를 인터페이스 MTU 기준으로 광고하고, 경로 중간이 더 좁으면 PMTUD가 ICMP Fragmentation Needed로 알려 줘야 하는데 그 ICMP를 방화벽이 버리면 블랙홀이 생깁니다. MSS와 MTU의 산수, ping -M do로 경로 MTU를 이분 탐색하는 법, IPse

  2026-07-26 · 23 분 읽기 #network#mtu#tcp#vpn#kubernetes

• Connection refused와 timeout의 차이 — TCP 수준에서 원인 좁히는 법

  연결이 안 될 때 터미널이 돌려주는 메시지는 크게 두 갈래입니다. Connection refused는 상대가 RST를 돌려준 것이고, timeout은 보낸 SYN에 아무 응답이 없는 것입니다. 이 한 줄 차이가 프로세스 문제인지 경로 문제인지를 거의 결정합니다. tcpdump로 SYN과 RST를 직접 확인하는 법, SYN 재전송 간격으로 타임아웃 길이를 미리 계산하는 법, 리스너가 있는데도

  2026-07-26 · 20 분 읽기 #network#tcp#troubleshooting#linux#kubernetes

• dig는 되는데 애플리케이션은 실패한다 — DNS 해석 순서부터 확인하는 법

  dig로는 정상적으로 답이 오는데 애플리케이션만 이름을 못 찾는 상황은 버그가 아니라 구조입니다. dig와 nslookup은 /etc/hosts와 nsswitch.conf를 아예 거치지 않고 리졸버에 직접 질의하기 때문입니다. 애플리케이션이 실제로 밟는 경로를 nsswitch.conf부터 systemd-resolved 스텁 리졸버까지 따라가고, getent와 resolvectl로 같은 경로를

  2026-07-26 · 21 분 읽기 #network#dns#linux#kubernetes#troubleshooting

• Kubernetes Pod Pending 상태 해결 — 스케줄러가 남긴 거절 사유 읽는 법

  파드가 Pending에서 몇 분째 넘어가지 않을 때, 스케줄러는 이미 거절 사유를 이벤트에 남겨 두었습니다. 0/5 nodes are available로 시작하는 그 문장을 정확히 해독하는 법부터 시작해 아홉 갈래 원인을 하나씩 배제합니다. 리소스 부족은 실제 사용량이 아니라 requests 총합으로 판정된다는 점, taint와 톨러레이션, 노드 셀렉터와 어피니티 불일치, PVC 미바인딩과

  2026-07-26 · 20 분 읽기 #kubernetes#scheduler#pending#troubleshooting#autoscaling

• Kubernetes ImagePullBackOff와 ErrImagePull 완전 해부 — 원인 문자열 하나로 끝내기

  파드가 ErrImagePull을 거쳐 ImagePullBackOff에 머무는 상황을 원인별로 분해합니다. 두 상태가 같은 사건의 다른 단계라는 점, 그리고 kubectl describe의 Events 마지막 한 줄에 이미 정답이 적혀 있다는 점에서 출발합니다. 태그 오타, 프라이빗 레지스트리 인증 실패, 서비스어카운트에 시크릿이 안 붙은 경우, Docker Hub 익명 풀 레이트 리밋, 프록

  2026-07-26 · 19 분 읽기 #kubernetes#imagepullbackoff#container-registry#troubleshooting#containerd

• Kubernetes 프로브 3종 제대로 쓰기 — liveness, readiness, startup의 정확한 경계

  아무 문제 없는 파드가 주기적으로 재시작하거나, 배포 직후에만 502가 쏟아지거나, 느리게 뜨는 애플리케이션이 영원히 Ready에 도달하지 못하는 세 가지 사고는 모두 프로브 설계에서 나옵니다. 세 프로브가 각각 어떤 질문에 답하고 실패 시 무엇을 하는지 구분한 뒤, initialDelaySeconds부터 failureThreshold까지 파라미터가 실제로 몇 초 뒤에 컨테이너를 죽이는지 계

  2026-07-26 · 27 분 읽기 #kubernetes#liveness-probe#readiness-probe#graceful-shutdown#sre

• OOM Killer가 프로세스를 죽였을 때 — dmesg 로그 해독부터 cgroup OOM 구분까지

  프로세스가 아무 로그도 남기지 않고 사라졌고 종료 코드는 137입니다. 커널 OOM Killer가 남긴 dmesg 리포트를 한 줄씩 읽는 법, badness 점수가 계산되는 방식과 가장 큰 프로세스가 아닌 다른 프로세스가 죽는 이유, 시스템 전역 OOM과 cgroup v2 memory.max에 의한 컨테이너 OOM을 로그만 보고 구분하는 법을 정리합니다. overcommitmemory 0/1

  2026-07-26 · 27 분 읽기 #linux#memory#oom#cgroups#kubernetes

• Kubernetes OOMKilled(137) 메모리 문제 해결 — 한도를 올리기 전에 확인할 것들

  컨테이너가 Exit Code 137로 죽었는데 애플리케이션 로그에는 아무 예외도 남지 않는 상황을 다룹니다. 137이 128 더하기 9, 즉 SIGKILL이라는 사실만 말해 준다는 점에서 출발해 컨테이너 cgroup 한계에 의한 OOM과 노드 전역 OOM, kubelet 축출을 dmesg 한 줄로 구분하는 법을 정리했습니다. JVM과 Node.js와 파이썬이 컨테이너 한계를 어떻게 오해하는지

  2026-07-26 · 23 분 읽기 #kubernetes#oomkilled#memory#jvm#cgroup

• Kubernetes 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

• 시크릿 관리, .env 파일만으로는 부족한 이유 — 환경변수가 새는 경로와 로테이션 설계

  .env 파일을 .gitignore에 넣었다고 시크릿이 안전해지지는 않습니다. 프로세스 환경은 같은 호스트에서 /proc/PID/environ으로 그대로 읽히고, 크래시 리포트와 디버그 페이지와 CI 로그에 실려 나가며, 컨테이너 이미지 레이어에 영구히 남습니다. 이 글은 환경변수가 새어 나가는 실제 경로를 하나씩 보여주고, 시크릿이 이미 커밋된 경우의 대응 순서가 왜 히스토리 재작성이 아니

  2026-07-26 · 27 분 읽기 #security#secrets#devops#vault#kubernetes

• CPU steal time과 스로틀링 — top의 st, 버스터블 크레딧, CFS 쿼터를 가르는 법

  CPU 사용률은 40%인데 p99 지연이 튀고, top의 st 열에는 20%가 찍혀 있습니다. 겉으로 비슷해 보이는 이 증상에는 세 가지 전혀 다른 원인이 있습니다. 하이퍼바이저가 vCPU에 물리 CPU를 주지 않는 steal time, 버스터블 인스턴스의 CPU 크레딧 고갈, 그리고 top에 아예 보이지 않는 cgroup CFS 쿼터 스로틀링입니다. st가 몇 퍼센트부터 문제인지, nrth

  2026-07-26 · 28 분 읽기 #linux#cpu#cgroups#kubernetes#cloud

• Talos Linux 1.13 — 쉘 없는 불변 OS가 디버그 쉘을 배송하기까지

  쿠버네티스 전용 불변 OS인 Talos Linux의 1.13이 2026년 4월 27일에 나왔습니다. 이번 릴리스에는 Clang/ThinLTO로 빌드된 커널, 재현 가능한 디스크 이미지, 머신 전역 컨테이너 이미지 서명 검증, 그리고 가장 상징적인 기능 — 쉘도 SSH도 없는 OS를 위한 공식 디버그 컨테이너(talosctl debug) — 이 들어 있습니다. 이 글은 1.13의 실제 릴리스

  2026-07-17 · 25 분 읽기 #linux#kubernetes#talos#immutable-infrastructure#devops

• Flux 2.9와 Weaveworks 이후 2년 — 스폰서를 잃은 GitOps 프로젝트는 어떻게 유지되고 있나

  2024년 초 Flux의 원 개발사 Weaveworks가 문을 닫았을 때, GitHub 디스커션에는 "이 프로젝트의 미래는 위험한가?"라는 질문이 올라왔습니다. 2년 반이 지난 2026년 6월 30일, Flux는 2.9.0을 릴리스했습니다. 이 글은 그 사이에 실제로 일어난 일을 검증 가능한 1차 자료로 재구성합니다 — 릴리스 케이던스가 어떻게 흔들렸다 회복됐는지(v2.0부터 v2.9까지 릴

  2026-07-17 · 21 분 읽기 #devops#gitops#fluxcd#kubernetes#open-source

• OTel의 Kubernetes 속성이 stable이 됐다 — k8sattributes 기본값이 뒤집히기 전에 할 일

  OpenTelemetry의 Kubernetes 시맨틱 컨벤션이 2026년 6월 12일 semconv v1.42.0에서 stable로 승급했습니다. 그런데 Collector의 k8sattributes 프로세서는 아직 기본값이 옛 스키마(v0)라, 대부분의 사람은 아무 일도 겪지 않았습니다. 문제는 이게 영구적이지 않다는 것입니다 — Collector RFC가 정한 롤아웃대로라면 피처 게이트가

  2026-07-16 · 22 분 읽기 #opentelemetry#observability#kubernetes#semantic-conventions#telemetry-pipeline

• Kubernetes v1.36의 Workload/PodGroup API — 갱 스케줄링이 kube-scheduler 안으로 들어오는 중

  AI 학습·배치 워크로드의 갱 스케줄링은 지금까지 Volcano나 Kueue 같은 외부 스케줄러의 몫이었지만, Kubernetes가 이 기능을 코어로 가져오기 시작했습니다. v1.35가 Workload API와 첫 갱 스케줄링 구현을 알파로 내놨고, 2026년 4월 22일 나온 v1.36은 구조를 갈아엎어 Workload를 정적 템플릿으로, 새 PodGroup을 런타임 객체로 분리하고 그룹

  2026-07-16 · 34 분 읽기 #kubernetes#scheduling#gang-scheduling#distributed-training#dra

• ambient로 옮기면 EnvoyFilter는 조용히 무시된다 — Istio 1.30 TrafficExtension이 메운 구멍과 남은 구멍

  ambient 모드 이전을 막는 진짜 장애물은 리소스가 아니라 확장성입니다. Istio 공식 마이그레이션 문서는 EnvoyFilter가 waypoint에서 지원되지 않으며 이전 후 "조용히 무시된다"고, 대안이 없으면 "마이그레이션 블로커"라고 직접 적어 두었습니다. 2026년 5월 18일 나온 Istio 1.30은 이 구멍을 겨냥해 TrafficExtension API를 냈습니다 — Was

  2026-07-16 · 26 분 읽기 #kubernetes#istio#service-mesh#envoy#ambient-mesh

• 좋은 도구는 보이지 않는다: gingerBill의 주장과 "너무 보이지 않는" 도구의 함정

  Odin 언어를 만든 gingerBill의 글 'Good Tools Are Invisible'을 읽고, 그 논지를 정리한 뒤 현업 관점의 단서를 더한다. 그는 좋은 도구란 마찰 없이 배경으로 사라져야 하며, 결함을 '풀면 재미있는 퍼즐'로 되파는 수사법을 비판한다. 나는 '느끼는 생산성 대 실제 생산성'이라는 구분에는 동의하지만, 인터페이스가 보이지 않는 것과 내부 동작이 불투명한 것은 다르

  2026-07-11 · 14 분 읽기 #tools#developer-experience#kubernetes#build-systems#editors