[istio]istio service mesh 掃雷記

前言

狀況很奇特，奇特到我不知道該從哪裡找。簡單說就是gateway裡面有mesh的話，
就會有這個狀況出現，也只能說這是因為要轉呼叫其他部門的API，才會有這個狀況。

正文

先說明一下環境，Deployment A 的 VirtualService 有設定 domain , abc.com
此時進去 Deployment裡面的 pod ， 使用 curl 呼叫外部的ip，會發生404的錯誤。
e.g. curl -v 123.213.123.213 -H “Host:abc.com”
但是，如果Host不帶abc.com ，改帶任意的 domain，即可正常執行。

這是因為如果使用service mesh的話，istio會判斷請求的header host是在同一個服務內，

所以在服務內理所當然就找不到這個，變成404報錯。

要解決的話，也只能拔掉mesh了。

除錯過程

1. 使用tcpdump ，將所有的封包撈出，但發現如果 host 帶 abc.com ，沒有任何的封包進出。
   但帶任意 domain: def.com ，則會有封包進出。故開始懷疑是 sidecar的某些機制將流量導到本機，
   以至於回傳404的錯誤。

   簡易的tcpdump使用，
   詳細用法請參考連結

     針對 host 是 123.213.123.213 且 port 是 80 的封包截取，並存入demo2.pcap的檔案
     tcpdump host 123.213.123.213 and port 80 -w demo2.pcap
   

   但是從pod裡面看封包，會想哭，所以進一步要把封包的檔案放到自己的機器上，再使用wireshark看。

     將pod(api-beta-v2-primary-69797b47d6-bl6vf)，裡面的檔案 demo2.pcap 複製到本機上
     kubectl cp api-beta-v2-primary-69797b47d6-bl6vf:/app/demo2.pcap -n istio ./demo2.pcap
   

   ref. [Linux] Tcpdump 擷取封包指令範例教學

2. 查詢outbound handler

  istioctl proxy-config route api-beta-v2-primary-69797b47d6-bl6vf -n istio

終於查到了一個關鍵，在有問題domain，他match的path是另外一個virtualService(fig.1)，最後查到那個VirtualSerice ，在gateway上面多設了一組 mesh，
導致他一直在網格內繞，所以才會404。

(fig.1)

額外補充，查詢 Inbound handler

   istioctl proxy-config listener reviews-v1-54b8794ddf-jxksn

可直接用 istioctl pc 來取帶 proxy-config

ref. Istio 中的 Sidecar 注入及透明流量劫持過程詳解