본문 바로가기
WIKI 기술 지식 베이스

디버그 사이드카 사용하기

원문 보기 위키 갱신

서비스 메시를 디버깅하는 것은 어려울 수 있어요. 무언가 동작하지 않을 때, 문제가 프록시 때문일까요? 애플리케이션 때문일까요? 클라이언트 때문일까요? 아니면 기본 네트워크 때문일까요? 때로는 원시 네트워크 데이터를 보는 것만 한 것이 없어요.

애플리케이션에 들어오고 나가는 패킷에 대한 네트워크 레벨 가시성이 필요할 때, Linkerd는 유용한 도구들이 포함된 *디버그 사이드카(debug sidecar)*를 제공해요. 프록시 사이드카 주입과 유사하게, 파드 생성 시점에 config.linkerd.io/enable-debug-sidecar: "true" 어노테이션을 설정해 파드에 디버그 사이드카를 추가해요. 편의를 위해 linkerd inject 명령은 이 어노테이션을 대신 해주는 --enable-debug-sidecar 옵션을 제공해요.

(Kubernetes 파드의 컨테이너 집합은 변경할 수 없으므로, 이미 존재하는 파드에 이 어노테이션을 추가하는 것만으로는 동작하지 않아요. 파드 생성 시점에 반드시 있어야 해요.)

출처: Linkerd Using the Debug Sidecar

본문

Linkerd 운영 팁

이 페이지에는 오픈 소스 커뮤니티가 최선의 노력(best-effort)으로 작성한 설명이 포함되어 있어요. 미션 크리티컬 애플리케이션을 운영하는 사용자는 Linkerd 프로덕션 리소스를 숙지하거나 상용 Linkerd 제공업체와 연결해야 해요.

디버그 사이드카 이미지에는 tshark, tcpdump, lsof, iproute2가 포함되어 있어요. 설치되면 tshark로 들어오고 나가는 모든 트래픽 로깅을 자동으로 시작하며, 이는 kubectl logs로 볼 수 있어요. 또는 kubectl exec를 사용해 컨테이너에 접근해 명령을 직접 실행할 수도 있어요.

예를 들어 Linkerd Getting Started 가이드를 따라 emojivoto 애플리케이션을 설치했다면, voting 서비스로 가는 트래픽을 디버깅하고 싶을 때 다음을 실행할 수 있어요:

kubectl -n emojivoto get deploy/voting -o yaml \
  | linkerd inject --enable-debug-sidecar - \
  | kubectl apply -f -

이렇게 하면 voting 서비스의 모든 파드에 디버그 사이드카 컨테이너가 배포돼요. (이 디플로이먼트에는 파드가 하나뿐이며, 이를 위해 재생성될 거예요. 위의 파드 변경 불가에 대한 참고 사항을 참고하세요.)

voting-svc 라벨이 있는 파드의 모든 컨테이너를 나열해 디버그 컨테이너가 실행 중인지 확인할 수 있어요:

kubectl get pods -n emojivoto -l app=voting-svc \
  -o jsonpath='{.items[*].spec.containers[*].name}'

그런 다음, 다음을 실행해 로그에서 실시간 tshark 출력을 볼 수 있어요:

kubectl -n emojivoto logs deploy/voting linkerd-debug -f

그것만으로 부족하다면 컨테이너에 exec해서 네트워크 맥락에서 원하는 명령을 실행할 수 있어요. 예를 들어 요청의 HTTP 헤더를 검사하고 싶다면, 다음과 같이 실행할 수 있어요:

kubectl -n emojivoto exec -it \
  $(kubectl -n emojivoto get pod -l app=voting-svc \
    -o jsonpath='{.items[0].metadata.name}') \
  -c linkerd-debug -- tshark -i any -f "tcp" -V -Y "http.request"

디버그 사이드카가 문제 해결에 효과적인 실제 프록시 오류 메시지는 다음과 같은 Connection Refused 오류예요:

ERR! [] proxy={server=in listen=0.0.0.0:4143 remote=some.svc:50416}
linkerd2_proxy::app::errors unexpected error: error trying to connect:
Connection refused (os error 111) (address: 127.0.0.1:8080)

이 경우 tshark 명령을 수정해 오류에 언급된 특정 포트 사이의 트래픽을 수신하도록 할 수 있어요:

kubectl -n emojivoto exec -it \
 $(kubectl -n emojivoto get pod -l app=voting-svc \
  -o jsonpath='{.items[0].metadata.name}') \
  -c linkerd-debug -- tshark -i any -f "tcp" -V \
  -Y "(tcp.srcport == 4143 and tcp.dstport == 50416) or tcp.port == 8080"

Connection reset by peer라는 메시지의 유사한 오류가 있다는 점에 유의하세요. 애플리케이션 로그 출력에 연관된 오류나 메시지가 보이지 않는다면 이 오류는 보통 무해해요. 이 시나리오에서는 디버그 컨테이너가 오류 메시지 문제 해결에 도움이 되지 않을 수 있어요.

ERR! [] proxy={server=in listen=0.0.0.0:4143 remote=some.svc:35314}
linkerd2_proxy::app::errors unexpected error: connection error:
Connection reset by peer (os error 104)

물론 이 예시들은 Kubernetes 클러스터에서 임의의 컨테이너에 exec할 수 있는 권한이 있을 때만 동작해요. 이 접근 방식의 대안으로 linkerd tap을 참고하세요.

더 알아보기 (Learn more)