
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Sun, 26 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/kubectl/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/kubernetes/2026-07-26-kubernetes-crashloopbackoff-debugging</guid>
    <title>Kubernetes CrashLoopBackOff 원인별 진단과 해결 — 로그가 비어 있을 때 무엇을 봐야 하나</title>
    <link>https://www.youngju.dev/blog/kubernetes/2026-07-26-kubernetes-crashloopbackoff-debugging</link>
    <description>파드가 CrashLoopBackOff에 빠졌는데 kubectl logs는 아무것도 뱉지 않는 상황을 처음부터 끝까지 다룹니다. BackOff가 원인이 아니라 10초에서 5분까지 늘어나는 재시작 대기 시간이라는 정확한 의미부터, describe의 Last State와 Exit Code를 읽는 순서, 종료 코드 0/1/127/137/139/143이 각각 무엇을 뜻하는지 정리했습니다. 애플리케이션 즉시 종료, 설정과 시크릿 누락, OOMKilled, liveness 프로브에 의한 강제 종료, 잘못된 command, 볼륨 마운트 실패, init 컨테이너 실패까지 원인별 진단 명령과 해결책을 제시합니다. 컨테이너를 살려 둔 채 안으로 들어가는 두 가지 방법과, 같은 사고가 다음 배포에서 재현되지 않게 하는 장치도 함께 다룹니다.</description>
    <pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>kubernetes</category><category>crashloopbackoff</category><category>troubleshooting</category><category>kubectl</category><category>sre</category>
  </item>

    </channel>
  </rss>
