[TIL] kubernetes에서 Pod간 통신 장애 해결 경험

관리자 페이지에서 임베딩 모델과의 연결이 실패하는 문제를 겪었다.

백엔드 서버와 임베딩 서버가 모두 kubernetes 상에서 동작 중이고, 임베딩 서버의 /health 엔드포인트도 정상적으로 응답하는 상황에서 발생한 문제였다. 문제 해결 과정을 정리하였다.

 

증상

• 관리자 페이지에서 임베딩 서비스의 URL로 요청을 보낼 때, Conection refused로 요처이 실패함.
• 임베딩 서버는 k8s 상에서 정상 동작중, Pod log도 uvicorn runing on 0.0.0.0:8000 으로 로그 확인.

 

접근 1. kubernetes 리소스가 잘 동작중인가?

우선 리소스 구성이 정상인지 확인했다. namespace 오타 여부, pod 실행 상태, service 존재 여부, Service가 실제 Pod와 연결되었는지(endpoints) 점검했다.

kubectl -n llm get pod
kubectl -n llm get svc
kubectl -n llm get endpoints sparse -o wide

서비스도 생성되어있고, pod도 정상 동작중이며 uvicorn runing on 0.0.0.0:8000 로그를 확인했다.

 

접근 2. domain name이 잘못되었는가?

관리자 페이지에서 임베딩 서버까지 요청은 다음의 흐름을 갖는다.

[web] --> [api] --> [embedding]

이때 embedding 서버의 서비스명은 embedding이고, namespace는 llm이다. 따라서 서비스의 DNS는 다음과 같다.

embedding.llm.svc.cluster.local

이를 확인하기 위해 pod 내부에서 직접 /health 요청을 확인했다.

curl -sv http://embedding.llm.svc.cluster.local:8000/health

이 요청에 대해 200 결과를 받아, DNS 해석 및 ClusterIP 자체는 정상임을 확인했다.

 

접근 3. 서비스에서 Pod로의 포트 전달이 정상적인가?

서비스 레이어를 우회하여, port-forward로 요청했을 때에는 /health 요청이 정상적으로 전달되었다.

kubectl -n llm port-forward svc/embedding 18000:8000
curl -sv http://localhost:18000/health

따라서 어플리케이션이 아닌 service에서 라우팅 문제를 의심했다. 확인 결과, embedding 서비스의 yaml 파일에서 다음의 오류를 발견했다.

# 기존의 yaml 파일
ports:
- port: 8000
  targetPort: 80

8000 포트로 전달된 요청이 서비스에서 80번 포트로 전달되고 있었다. 하지만 Pod의 uvicorn은 8000번 포트에서 listen 중이므로, Connection refused가 발생했던 것이다. yaml을 아래와 같이 수정하여 이슈를 해결했다.

# 기존의 yaml 파일
ports:
- port: 8000
  targetPort: 8000

수정 후, http://embedding.llm.svc.cluster.local:8000/health 로의 요청이 성공적으로 전달되었다.  

 

개념정리: 요청 전달 Flow

1. Ingress: L7 라우터. HTTP request message의 Host와 Path를 보고 Service를 선택.
   host, path --> Service의 ClusterIP, Service.port
2. Service: L4 라우터. Deployment 등으로 배포된 여러 pod을 하나의 endpoint로 묶는 가상 IP(ClusterIP)를 제공함.
   ClusterIP, Service.port --> PodIP, Service.targetPort
3. Pod: 최소한의 컴퓨팅 단위, pod로 들어온 요청을 container가 노출한 port로 직접 수신함.
   container 내부의 process가 listen 중인 port로 최종 이어짐

 

배운 점

쿠버네티스에서 요청을 실제로 처리하는 주체가 무엇인지,
Ingress -> Service -> Pod로 이어지는 요청이 어떻게 전달되는지를 이해할 수 있었다.
역시 이슈를 해결하면서 많은 것을 배우게 된다.