서비스 장애가 발생했을 때의 긴박함과 대응의 중요성
모니터링 대시보드에 갑자기 빨간색 경고등이 들어오고, 사용자들로부터 접속이 안 된다는 문의가 빗발치는 상황을 상상해 보세요. 서비스 엔지니어나 보안 담당자에게 이보다 더 압박감이 큰 순간은 없을 거예요. 분명히 파드(Pod)는 정상적으로 떠 있는 것 같은데, 정작 외부나 내부의 다른 서비스에서는 연결할 수 없다는 오류 메시지만 반복된다면 당혹스러울 수밖에 없습니다.
쿠버네티스 환경에서 서비스 장애는 단순히 애플리케이션의 문제가 아니라, 네트워크 경로, 라벨 설정, 혹은 보안 정책의 충돌 등 매우 복잡한 원인에서 비롯되는 경우가 많아요. 원인을 정확히 파악하지 못한 채 재시작만 반복한다면, 문제는 해결되지 않고 시스템의 불안정성만 키울 뿐입니다. 특히 보안 정책을 수립하는 입장에서는 이러한 장애가 설정 오류인지, 혹은 외부 공격에 의한 이상 징후인지 구분하는 능력이 무엇보다 중요해요.
이 글에서는 실무에서 즉시 활용할 수 있는 서비스 트러블슈팅의 체계적인 접근법을 다룹니다. 막연한 추측이 아니라, 논리적인 진단 순서에 따라 문제를 좁혀나가는 방법을 배울 수 있어요. 장애 상황에서 무엇을 먼저 확인해야 하는지, 어떤 명령어를 사용해야 하는지, 그리고 어떻게 하면 같은 문제가 반복되지 않도록 설정할 수 있는지 단계별로 안내해 드릴게요.
- 서비스 유형별 특징과 장애 발생 가능 지점 파악
- 레이블(Label)과 엔드포인트(Endpoint)를 활용한 연결성 검증
- 로그와 이벤트를 통한 논리적 원인 추적 방법
- 네트워크 정책 및 프로브(Probe) 설정 오류 해결
- 재발 방지를 위한 안정적인 서비스 구성 전략
진단 전 반드시 점검해야 할 서비스 기본 개념
문제를 해결하기 위해서는 먼저 우리가 다루고 있는 서비스가 어떤 방식으로 동작하는지 명확히 이해해야 해요. 쿠버네티스의 서비스는 파드라는 유동적인 객체들에게 고정된 IP와 이름을 부여해 주는 역할을 합니다. 하지만 이 과정에서 설정 하나만 어긋나도 통신이 완전히 끊길 수 있어요. 진단을 시작하기 전에 현재 운영 중인 서비스의 유형과 연결 구조를 머릿속에 그려보는 과정이 반드시 필요합니다.
가장 먼저 확인해야 할 것은 셀렉터(Selector)입니다. 서비스가 어떤 파드를 자신의 관리 대상으로 삼을지 결정하는 기준이죠. 만약 파드에 부여된 레이블과 서비스의 셀렉터가 단 한 글자라도 다르다면, 서비스는 갈 곳을 잃게 됩니다. 또한, 엔드포인트(Endpoint) 객체가 실제로 생성되어 있는지 확인하는 것도 필수적인 사전 단계예요.
아래 표를 통해 현재 장애가 의심되는 서비스의 유형을 먼저 분류해 보세요. 유형에 따라 점검해야 할 네트워크 계층이 달라집니다.
| 서비스 유형 | 주요 용도 | 주요 장애 지점 | 점검 핵심 |
|---|---|---|---|
| ClusterIP | 클러스터 내부 통신 | DNS 해석 오류, 셀렉터 불일치 | CoreDNS 상태 |
| NodePort | 외부 노출 (노드 IP 이용) | 방화벽 차단, 포트 충돌 | 노드 포트 개방 여부 |
| LoadBalancer | 클라우드 로드밸런서 연동 | 클라우드 설정 미비, 프로비저닝 지연 | LB 상태 및 타겟 그룹 |
장애가 발생했을 때 무작정 명령어를 입력하기보다는, 위 표를 기준으로 어느 계층에서 통신이 끊겼는지를 먼저 가늠해 보시기 바랍니다. 클러스터 내부의 문제라면 DNS나 셀렉터를, 클러스터 외부와의 접점 문제라면 노드 포트나 로드밸런서 설정을 우선적으로 살펴봐야 해요.
체계적인 서비스 장애 원인 분석 및 진단 단계
이제 본격적으로 문제를 해결하기 위한 단계별 실행 절차를 살펴보겠습니다. 서비스 문제 해결은 넓은 범위를 좁혀나가는 과정이에요. 네트워크 계층에서 시작하여 애플리케이션 계층으로 내려가는 하향식(Top-down) 접근법이 가장 효율적입니다.
STEP 1. 서비스 이름과 DNS 해석 확인하기
가장 먼저 확인할 것은 “서비스의 이름이 올바르게 해석되는가”입니다. 쿠버네티스 내부에서는 DNS를 통해 서비스에 접근하기 때문이에요. 만약 다른 네임스페이스에서 접근한다면 `
테스트를 위해 임시 파드를 띄워 `nslookup` 명령어를 사용해 보세요. 만약 IP 주소가 반환되지 않는다면, 이는 서비스 자체의 문제가 아니라 CoreDNS 구성의 문제일 가능성이 매우 높습니다. DNS가 정상인데도 통신이 안 된다면 다음 단계로 넘어갑니다.
STEP 2. 셀렉터와 엔드포인트 일치 여부 검증
많은 실무자가 놓치는 부분이 바로 이 단계입니다. 서비스가 살아있어도 연결할 대상(Pod)을 찾지 못하면 무용지물이죠. `kubectl get endpoints
파드의 레이블을 확인하는 명령어인 `kubectl get pods –show-labels`와 서비스의 정의를 보여주는 `kubectl describe svc
STEP 3. 파드의 준비 상태(Readiness Probe) 점검
엔드포인트 목록에 파드의 IP가 있더라도 실제 통신이 실패한다면, 파드의 Readiness Probe 설정을 의심해야 합니다. 쿠버네티스는 파드가 ‘Ready’ 상태가 아닐 경우, 해당 파드를 서비스의 엔드포인트 목록에서 자동으로 제외합니다.
파드는 실행 중(Running)이지만, 애플리케이션이 아직 초기화 중이거나 특정 포트가 열리지 않아 프로브 검사에 실패하고 있을 수 있어요. `kubectl describe pod
STEP 4. 네트워크 정책(Network Policy) 및 보안 설정 확인
보안 담당자라면 반드시 확인해야 할 단계입니다. 서비스는 완벽하게 설정되었더라도, NetworkPolicy가 특정 트래픽을 차단하고 있다면 연결은 거부됩니다. 특히 클러스터 보안 강화 작업 이후 갑자기 서비스가 먹통이 되었다면 이 부분을 가장 먼저 의심하세요.
Ingress(수신) 정책과 Egress(송신) 정책이 모두 올바르게 허용되어 있는지 확인해야 합니다. 특정 네임스페이스 간의 통신을 차단하는 정책이 있는지, 혹은 프로토콜(TCP/UDP)이나 포트 번호가 정책에 명시된 것과 일치하는지 검증하세요. 이는 육안으로 확인하기 어렵기 때문에, 실제 트래픽을 발생시키며 패킷 유실 여부를 확인하는 과정이 동반되어야 합니다.
STEP 5. Kube-proxy 및 CNI 네트워크 계층 진단
위의 모든 설정이 완벽함에도 불구하고 문제가 지속된다면, 이제 클러스터 인프라 자체를 의심해야 합니다. 쿠버네티스의 네트워크 규칙을 관리하는 kube-proxy가 제대로 동작하고 있는지, 혹은 사용하는 CNI(Container Network Interface) 플러그인에 문제가 없는지 확인하는 단계입니다.
노드 간의 통신이 끊겼거나, iptables 또는 IPVS 규칙이 꼬여서 트래픽이 엉뚱한 곳으로 흐를 수 있습니다. 특정 노드에서만 서비스 접근이 안 된다면 해당 노드의 kube-proxy 상태를 점검하고, 노드 간의 네트워크 라우팅 테이블을 확인하는 깊이 있는 분석이 요구됩니다.
문제를 해결하기 위해 서비스를 재시작하거나 파드를 삭제하기 전에, 반드시 현재의 설정(YAML)과 `kubectl describe` 결과를 백업해 두세요. 원인을 파악하지 않은 채 수행하는 재시작은 일시적인 해결책일 뿐, 근본적인 문제를 덮어버릴 수 있습니다.
이러한 진단 과정을 요약하면 아래와 같은 흐름으로 진행됩니다.
1.
nslookup 실패 $ightarrow$ DNS 문제 해결
2.
get endpoints 결과 없음 $ightarrow$ Label/Selector 수정
3.
describe pod에 Probe 실패 기록 $ightarrow$ Readiness Probe 설정 조정
4.
netpol 존재 $ightarrow$ 보안 정책 허용 범위 확대
자주 하는 실수와 해결법 및 FAQ
실무 환경에서 반복적으로 발생하는 실수들을 정리했습니다. 비슷한 상황에 직면했다면 아래 내용을 통해 빠르게 해결책을 찾아보세요.
자주 하는 실수와 해결법
❌ 실수: 서비스의 포트(Port)와 타겟 포트(TargetPort)를 혼동함
왜 발생하는가: 서비스가 리스닝하는 포트와 실제 파드 애플리케이션이 사용하는 포트가 다른데, 이를 구분하지 못해 설정을 잘못하는 경우가 많습니다.
✅ 해결법: 서비스 정의 파일에서 `port`는 서비스 자체의 포트이고, `targetPort`는 파드 내부의 포트임을 명확히 구분하여 작성하세요.
❌ 실수: 네임스페이스(Namespace) 불일치
왜 발생하는가: 서비스와 파드가 서로 다른 네임스페이스에 있는데, 동일한 네임스페이스 내에 있다고 가정하고 셀렉터를 설정하기 때문입니다.
✅ 해결법: 서비스는 반드시 동일한 네임스페이스 내의 파드만 셀렉터로 선택할 수 있습니다. 다른 네임스페이스의 파드에 접근하려면 ExternalName 서비스를 사용하거나 별도의 브릿지 설정을 고려하세요.
❌ 실수: Readiness Probe의 과도한 엄격함
왜 발생하는가: 애플리케이션이 완전히 뜨기 전에 프로브가 너무 빨리 실행되어, 파드가 영원히 Ready 상태가 되지 못하는 현상입니다.
✅ 해결법: `initialDelaySeconds` 값을 충분히 늘려 애플리케이션의 기동 시간을 보장해 주세요.
❌ 실수: NetworkPolicy의 기본 차단 정책
왜 발생하는가: 보안을 위해 모든 트래픽을 차단하는 정책을 적용한 후, 특정 서비스 간의 허용 규칙을 빠뜨리는 경우입니다.
✅ 해결법: 새로운 정책을 적용하기 전, 기존 트래픽 흐름을 먼저 로그로 기록(Logging)하여 필요한 통신 경로를 명확히 파악한 뒤 허용 규칙을 추가하세요.
❌ 실수: NodePort 범위 미준수
왜 발생하는가: 쿠버네티스 기본 설정 범위(30000-32767)를 벗어난 포트를 NodePort로 지정하여 서비스가 생성되지 않는 경우입니다.
✅ 해결법: 할당된 포트 범위를 확인하거나, API 서버 설정에서 해당 범위를 변경해야 합니다.
자주 묻는 질문
Q. 서비스 IP(ClusterIP)로 핑(Ping)을 쳤는데 응답이 없어요. 문제가 있는 건가요?
대부분의 쿠버네티스 CNI 환경에서 서비스 IP는 가상 IP이며, 실제 물리적인 장치가 아닙니다. 따라서 ping 명령에 응답하지 않는 것이 정상일 수 있습니다. 서비스 연결성을 확인하려면 curl을 사용하여 특정 포트의 HTTP 응답을 확인하는 것이 더 정확합니다.
Q. 파드는 정상인데 서비스 엔드포인트가 왜 자꾸 사라지나요?
파드의 Readiness Probe가 주기적으로 실패하고 있을 가능성이 매우 높습니다. 파드가 동작 중이더라도 특정 조건에서 응답을 못 하면 쿠버네티스는 트래픽 유입을 막기 위해 엔드포인트에서 해당 파드를 즉시 제거합니다. 파드의 로그를 확인해 보세요.
Q. LoadBalancer 타입의 서비스가 계속 ‘Pending’ 상태로 떠 있어요.
사용 중인 클라우드 환경의 로드밸런서 프로비저너가 문제를 겪고 있거나, 할당할 수 있는 IP 자원이 부족한 경우입니다. 클라우드 공급자의 상태를 확인하거나, 컨트롤러의 로그를 살펴보시기 바랍니다.
Q. CoreDNS가 과부하가 걸리면 서비스에 어떤 영향이 있나요?
서비스 이름으로 통신하는 모든 내부 호출이 실패하게 됩니다. 이는 서비스 연결 오류를 넘어 클러스터 전체의 연쇄적인 장애로 이어질 수 있으므로, DNS 캐싱이나 CoreDNS 리소스 확장이 필요합니다.
장애 대응을 마치며: 안정적인 운영을 위한 요약
서비스 장애는 누구에게나 찾아올 수 있지만, 어떻게 대응하느냐에 따라 운영의 숙련도가 결정됩니다. 오늘 다룬 서비스 트러블슈팅 과정을 통해 문제의 근본 원인을 논리적으로 찾아내고, 단순히 재시작하는 것이 아닌 설정의 오류를 바로잡는 능력을 갖추시길 바랍니다.
- DNS 확인:
nslookup으로 서비스 이름 해석 여부 점검 - 연결성 확인:
kubectl get endpoints로 파드 연결 확인 - 레이블 검증: 서비스 셀렉터와 파드 레이블의 완벽한 일치 확인
- 상태 점검: Readiness Probe 실패 여부를
describe로 확인 - 보안 점검:
NetworkPolicy에 의한 차단 여부 확인 - 인프라 점검:
kube-proxy및 CNI 네트워크 상태 확인
장애를 겪은 후에는 반드시 ‘왜 이런 일이 발생했는가’에 대한 사후 분석(Post-mortem)을 진행해야 합니다. 설정 오류였다면 코드 리뷰 프로세스에 반영하고, 자원 부족이었다면 오토스케일링 정책을 검토하세요. 이러한 과정이 쌓여야만 진정으로 견고한 인프라를 구축할 수 있습니다.
오늘 바로 실천할 일: 현재 운영 중인 주요 서비스의 YAML 파일을 다시 한번 열어보고, 셀렉터와 포트 설정이 의도한 대로 되어 있는지 점검해 보세요. 작은 확인이 큰 장애를 막는 첫걸음입니다.
실습 환경에서 직접 적용해 보시다가 막히는 부분이 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하며 해결해 나가겠습니다!
함께 읽으면 좋은 글:
– 쿠버네티스 서비스 기본 개념 가이드
– 클러스터 구축 및 초기 설정 입문
