핵심 요약
DevOps 역량은 도구 이름을 많이 아는 것이 아니라, 장애 상황에서 원인을 차분히 좁혀 해결하는 능력이다.
Kubernetes에서 Pod가 Running 상태여도 사용자가 503 오류를 볼 수 있으며, 이는 애플리케이션이 실제로 정상 서비스 중이라는 뜻은 아니다.
DevOps는 도구 목록이 아니라 문제 해결 능력이다
DevOps Engineer라는 이름은 흔해졌지만, 진짜 실력은 이력서의 기술 스택 목록에서 드러나지 않는다.
Kubernetes, Docker, Terraform, AWS, Jenkins, Linux를 안다고 해서 곧바로 운영 장애를 해결할 수 있는 것은 아니다.
실전 DevOps는 새벽 장애 상황에서도 당황하지 않고, 증상을 관찰하고, 가설을 세우고, 하나씩 검증하는 사람에 가깝다.
Pod가 Running이어도 서비스는 죽어 있을 수 있다
Kubernetes에서 Running은 컨테이너 프로세스가 살아 있다는 뜻에 가깝다.
하지만 사용자가 정상적으로 요청을 보내고 응답을 받는다는 뜻은 아니다.
비유하면 가게 불은 켜져 있지만, 문이 잠겨 있거나 직원이 주문을 받지 않는 상황과 비슷하다.
503 오류는 "트래픽이 제대로 처리되지 않는다"는 신호다
사용자가 503을 본다면 보통 서버 또는 라우팅 계층에서 요청을 처리할 준비가 안 된 상태일 가능성이 크다.
Pod는 살아 있지만 Service, Ingress, readiness probe, 애플리케이션 내부 상태 중 어딘가에서 연결이 끊겼을 수 있다.
따라서 "Pod가 Running인데 왜 안 되지?"에서 멈추면 안 되고, 요청이 실제로 어디까지 도달하는지 추적해야 한다.
먼저 Service와 Endpoint를 확인한다
Kubernetes Service는 트래픽을 Pod로 보내는 입구 역할을 한다.
하지만 Service가 바라보는 Endpoint가 비어 있다면, 트래픽을 보낼 대상이 없는 상태다.
이때는 Pod가 존재하더라도 Service 입장에서는 연결할 백엔드가 없는 것과 같다.
Label과 Selector 불일치를 의심한다
Service는 Pod를 이름으로 찾지 않고 Label과 Selector로 찾는다.
Pod에는 app: web이라는 라벨이 있는데 Service는 app: api를 찾고 있다면, 둘은 서로 연결되지 않는다.
이 문제는 겉으로 보기엔 Pod도 있고 Service도 있어서 더 헷갈리기 쉽다.
Readiness Probe는 실제 서비스 가능 여부를 판단한다
Readiness Probe는 "이 Pod가 지금 트래픽을 받아도 되는가?"를 판단하는 장치다.
컨테이너는 실행 중이지만 DB 연결이 안 되었거나 초기화가 끝나지 않았다면 readiness가 실패할 수 있다.
이 경우 Kubernetes는 해당 Pod를 Service 대상에서 제외할 수 있으므로, Pod 상태뿐 아니라 readiness 상태도 반드시 확인해야 한다.
Ingress와 애플리케이션 로그까지 봐야 한다
Ingress 설정이 잘못되면 외부 요청이 올바른 Service로 가지 못한다.
경로, 호스트명, TLS, 백엔드 Service 이름이나 포트가 틀리면 사용자는 503을 볼 수 있다.
마지막으로 애플리케이션 로그를 확인해야 한다. Kubernetes 구성은 맞는데 앱 내부에서 예외가 발생하거나 의존 서비스 연결이 실패했을 수도 있다.
인사이트
운영 장애를 해결하는 핵심은 "살아 있음"과 "서비스 가능함"을 구분하는 것이다.
Pod 상태만 보지 말고, Service Endpoint, Label/Selector, Readiness Probe, Ingress, 애플리케이션 로그 순서로 요청의 흐름을 따라가라.
좋은 DevOps 엔지니어는 명령어를 많이 외운 사람이 아니라, 장애 상황에서 원인을 체계적으로 좁혀가는 사람이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.