[Istio] ksniff 를 이용해서 패킷을 염탐하자

 

해당 글은 이스티오 인 액션이라는 책의 일부 파트를 참고하였고, 책에서 다뤘던 방법보다 한 단계 더 나아가서 진행했던 내용을 바탕으로 작성하였습니다.

이스티오 인 액션

이스티오 인 액션은 이스티오에 관한 책인데, 최근에 읽었던 중에 책 중에 가장 흥미롭게 읽은 책이였습니다.
이스티오가 궁금하다면 많은 도움을 얻을 수 있는 책으로 적극 추천합니다!

 

다시 본론으로 돌아와서 ksniff 는 tcpdump 를 사용해 파드의 네트워크 트래픽을 포착하고 이를 와이어샤크로 리다이렉트하는 kubectl 플러그인입니다.

 

ksniff 를 설치하기 위해선 우선 krew 를 먼저 설치해주어야 합니다.

 

krew 문서로 가서 그대로 진행해줍니다.

 

저 같은 경우는 아래 쉘 스크립트를 실행시켰습니다.

$ (
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)

 

이후 ~/.zshrc에 PATH 를 등록해주었습니다.

$ export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

 

krew 를 설치했으면 아래 명령어를 통해 ksniff 를 kubectl 플러그인으로 설치해줍니다.

$ kubectl krew install sniff

install 해줄 때는 ksniff 가 아니고 sniff 로 작성합니다.

 

그 다음으로 와이어샤크도 설치해줍니다.

$ brew install wireshark

 

근데 여기서 한가지 알아둘 것이 있는데 ksniff 는 wireshark 를 CLI 로 실행시키기 때문에 터미널에서 wireshark 를 실행할 수 있어야 합니다.

 

그런데 아래처럼 명령어를 날리면 not found wireshark 에러가 발생합니다.

$ wireshark -v

 

wireshark(v4.4.2) 기준으로 터미널용은 tshark를 사용해야 하는데, 저는 여전히 wireshark 명령어를 쓰고 싶었습니다.

물론 tshark를 쓰는 방법도 문서에는 나와있긴 합니다.

https://github.com/eldadru/ksniff?tab=readme-ov-file#piping-output-to-stdout

 

그런데 이렇게 할 경우 와이어샤크의 GUI 화면이 아니고 CLI 화면으로 텍스트만 봐야해서 불편했기 때문에 wireshark 를 고집했습니다.

tshark는 터미널로 직접 보여줌

 

그래서 이것저것 찾아본 결과 다행히 방법을 찾을 수 있었습니다.

 

Home Brew 로 와이어샤크를 설치했으면 /Applications/Wireshark.app/Contents/MacOS/Wireshark 경로에 실행파일이 존재하게 될 텐데,

 

이 실행파일을 PATH bin 으로 소프트링크 걸어주면 됩니다.

$ sudo ln -s /Applications/Wireshark.app/Contents/MacOS/Wireshark /usr/local/bin/wireshark

 

 

그러면 wireshark 명령어가 잘 실행됩니다.

wireshark -v

 

소프트링크도 잘 걸려있네요

l은 소프트링크를 나타냄

 

혹시 더 나은 방법이 있다면 알려주세요!

 

그럼 이제 ksniff 를 사용하기 위한 준비를 마쳤으니, 다음으로 예제 상황을 살펴보겠습니다.

예제 상황에 쓰인 코드나 애플리케이션은 다루지 않겠습니다. 
궁금하시다면 이스티오 인 액션 책을 구매하셔서 확인하시길 바랍니다.

예제 상황

 

인그레스 게이트웨이를 통해서 요청이 들어오면 게이트웨이는 v1 과 v2 서브셋에 2:8 확률로 요청을 라우팅합니다. 그리고 catalog v2 의 한 파드는 응답하는 데 0.5초 이상이 걸리는데, 이는 VirtualService 에서 설정한대로 0.5초 이상이 걸리면 타임 아웃이 발생하는지 테스트하기 위함입니다.

 

먼저 인그레스 게이트웨이에 포트 포워딩을 해줍니다.

$ kubectl port-forward -n istio-system deployments/istio-gateway 80:80

포트포워딩

 

그 다음 요청을 생성하기 위한 명령어를 실행시켜줍니다.

$ for i in {1..1000}; do curl http://localhost/items -H "Host: catalog.istioinaction.io" -w "\nStatus Code %{http_code}\n"; sleep .5s; done

 

ksniff 도 실행해줍니다.

$ kubectl sniff catalog-v2-6c7cf7bf-2sptr -i lo

 

터미널에는 아래와 같은 텍스트가 찍힐 것이고,

실행 테스트

 

와이어샤크 GUI 가 곧바로 실행됩니다.

catalog 파드에 대한 와이어샤크

 

아래 빨간색 네모를 살펴볼 것인데,

빨간색 네모 집중

 

커넥션(3-way-handshake)이 생성되었다가 종료(4-way-handshake) 되는 과정을 볼 수 있습니다.

 

그런데 /items 엔드포인트에 200 응답을 잘받다가 갑자기 커넥션이 종료되는 걸 볼 수 있는데, 이는 응답 속도가 느린 파드로 인해 타임 아웃(0.5 초 이상)이 발생해서 이스티오 프록시가 커넥션을 종료시킨 것입니다.

 

이로 인해 인그레스 게이트웨이는 504 응답을 받았을 것입니다.

 

catalog 애플리케이션 같은 경우에는 인그레스 게이트웨이 입장에선 서버이고, 이 서버가 직접 504 응답을 한건 아니기 때문에(catalog 애플리케이션의 이스티오 프록시가 해줌) 504 관련한 코드는 확인할 수 없습니다.

이스티오 프록시 관점에서 누가 클라이언트이고, 누가 서버인지 구분을 명확히 해야 이해하기 쉽습니다.

 

책에선 사실 여기까지 다루고 다른 스텝으로 넘어가는데, 저는 인그레스 게이트웨이가 504 응답을 받는 것까지 와이어샤크로 확인하고 싶었습니다.

 

그런데 문제가 하나 있었는데 ksniff 는 tcpdump 가 필요하고, tcpdump 가 /tmp/static-tcpdump 위치에 있어야 합니다.

 

인그레스 게이트웨이 같은 경우 tcpdump 가 기본적으로 설치되긴 하지만 당연히 /tmp/static-tcpdump 에 있지는 않습니다. 소프트링크를 걸어주면 해결되겠지만, 굳이 인그레스 게이트웨이를 건들고 싶지 않았어요.

 

어차피 인그레스 게이트웨이는 이스티오 프록시를 타게 하기 위한 수단이였기 때문에 이스티오 프록시를 가지는 Nginx 파드만 있으면 같은 효과를 볼 수 있다고 생각하여 Nginx 파드를 생성하였습니다.

 

이후 VirtualService 는 아래와 같이 작성했습니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-catalog-v1-v2
  namespace: istioinaction
spec:
  hosts:
  - "catalog.istioinaction"
  http:
  - route:
    - destination:
        host: catalog.istioinaction.svc.cluster.local
        subset: version-v1
        port:
          number: 80
      weight: 20
    - destination:
        host: catalog.istioinaction.svc.cluster.local
        subset: version-v2
        port:
          number: 80
      weight: 80
    timeout: 0.5s

 

 

그리고 Nginx 파드 안으로 들어가서 아래와 같은 명령어를 똑같이 날려줍니다.

$ for i in {1..1000}; do curl http://catalog.istioinaction/items -w "\nStatus Code %{http_code}\n"; sleep .5s; done

 

쿠버네티스 DNS 로 접근하면 되기 때문에 curl 명령어에 더 이상 Host 헤더는 필요없습니다.

 

504 에러가 발생하는 걸 확인할 수 있고, 이걸 곧바로 ksniff 로 확인해봅니다.

upstream timeout

 

아래 명령어로 sniff 를 실행합니다.

$ kubectl sniff nginx -i lo

 

그런데 아마 아래와 같은 에러가 발생할 것입니다.

에러 발생

 

ksniff 를 tcpdump 를 사용한다고 했는데 기본적인 Nginx 이미지는 tcpdump 가 없기 때문이죠. 

그래서 설치해줍니다.

$ apt update && apt install -y tcpdump

 

그런데 여전히 에러가 발생할텐데 tcpdump 실행 파일은 ksniff 가 실행하는 위치로 옮겨주면 됩니다.

$ rm /tmp/static-tcpdump && ln /bin/tcpdump /tmp/static-tcpdump

 

해당 이슈는 여기서 확인할 수 있습니다.

 

다시 본론으로 와서 다시 ksniff 를 실행하면 와이어샤크로 리다이렉션이 될 것이고, 이번엔 504 응답을 받은 트래픽을 캡처할 수 있습니다.

504 캡처

 

catalog 애플리케이션에선 확인할 수 없었던 504 응답 코드를 어떻게 nginx 애플리케이션에선 확인할 수 있었을까요?

 

위에서 봤던 그림에서 컨테이너까지 표시해봤습니다.

 

catalog 애플리케이션 같은 경우는 앞단 Istio Proxy 에서부터 커넥션이 종료되기 때문에 504 에 관한 응답을 받을 수 없습니다.

커넥션만 연결되고 기다리다가 0.5초가 지나면 Istio Proxy 가 끊어버리죠.

 

그리고 nginx 애플리케이션은 Istio Proxy 로부터 받은 응답을 본인 파드의 Istio Proxy 로부터 전달받기 때문에 응답을 캡처할 수 있었습니다.

 

오늘은 ksniff 에 대해 알아봤는데요, 굉장히 흥미로운 도구인거 같아요. 파드 간 트래픽을 캡처하는 것이 예전부터 굉장한 고민이였는데 한층 덜어주는 것 같습니다.

 

그런데 여전히 tcpdump 가 없는 컨테이너에는 설치해줘야 한다는 것이 불편하긴 합니다.

(Istio Proxy는 기본적으로 tcpdump가 있으니 의외로 괜찮을지도?!)

 

그럼 오늘은 여기까지~