[istio] Discover route TCP in Cluster Istio

Contents

1) Install a few component to testing TCP

Các bạn sẽ cùng mình tìm hiểu về tcp trong istio and version hiện tại cho bài lab này istio 1.11.3
Link:
https://www.tetrate.io/blog/understanding-istio-and-tcp-services/
https://istio.io/latest/docs/tasks/security/authorization/authz-tcp/

Trong bài này mình sử dụng luôn namspace default và deploy lên đó 2 workload sleep and tcp-echo.
tcp-echo workload listens on port 9000, 9001.

Link manifest của sleep and tcp-echo

Và mình có cấu hình thêm envoy accessLog TCP nữa nhé
https://nimtechnology.com/2021/09/05/istio-recheck-envoy-test-cac-features-lien-quan-den-envoy/#431_access_log_TCP

Tổng kết deploy sẽ ntn

2) Check port TCP by paping

Với test TCP port này thì nếu mình ping thôi thì nó chả có log j cả

3) Sending data into TCP port and recheck.

3.1) Pod to service

Theo như ví dụ:
For example, if you send “world” to tcp-echo, it will reply with hello world.

kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- sh -c 'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'

Các bạn chú ý màu đỏ là namespace và thay cho đúng nhé.

Hoặc là exec vào container sleep và gõ

sh -c 'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'

Màu đó là tên service:

Chúng ta sem log istio-proxy của pod tcp-echo:

3.2) pod to pod

Giờ mình call vào IP của pod tcp-echo:

Thấy log cũng không có j khác biệt

Giờ mình show route của các pod đã injected istio

root@work-space-u20:~/istio-1.11.2/bin# ./istioctl pc l tcp-echo-5b8f599579-gxcks.default --port 9000
ADDRESS        PORT MATCH                        DESTINATION
10.101.139.132 9000 ALL                          Cluster: outbound|9000||tcp-echo.default.svc.cluster.local
10.109.88.245  9000 Trans: raw_buffer; App: HTTP Route: spin-deck.spinnaker.svc.cluster.local:9000
10.109.88.245  9000 ALL                          Cluster: outbound|9000||spin-deck.spinnaker.svc.cluster.local

NGhĩ là nếu destination IP và port match mới bảng route của istio
thì nó sẽ đi ra theo destination của istio

Mình show route inbound trên con tcp-echo:

root@work-space-u20:~/istio-1.11.2/bin# ./istioctl pc l tcp-echo-5b8f599579-gxcks.default --port 15006
ADDRESS PORT  MATCH                                                                                           DESTINATION
0.0.0.0 15006 Addr: *:15006                                                                                   Non-HTTP/Non-TCP
0.0.0.0 15006 Trans: tls; App: istio-http/1.0,istio-http/1.1,istio-h2; Addr: ::0/0                            InboundPassthroughClusterIpv6
0.0.0.0 15006 Trans: tls; Addr: ::0/0                                                                         InboundPassthroughClusterIpv6
0.0.0.0 15006 Trans: raw_buffer; Addr: ::0/0                                                                  InboundPassthroughClusterIpv6
0.0.0.0 15006 Trans: raw_buffer; App: HTTP; Addr: ::0/0                                                       InboundPassthroughClusterIpv6
0.0.0.0 15006 Trans: tls; App: TCP TLS; Addr: ::0/0                                                           InboundPassthroughClusterIpv6
0.0.0.0 15006 Trans: tls; Addr: 0.0.0.0/0                                                                     InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: raw_buffer; Addr: 0.0.0.0/0                                                              InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: tls; App: TCP TLS; Addr: 0.0.0.0/0                                                       InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: raw_buffer; App: HTTP; Addr: 0.0.0.0/0                                                   InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: tls; App: istio-http/1.0,istio-http/1.1,istio-h2; Addr: 0.0.0.0/0                        InboundPassthroughClusterIpv4
0.0.0.0 15006 Trans: tls; App: istio,istio-peer-exchange,istio-http/1.0,istio-http/1.1,istio-h2; Addr: *:9001 Cluster: inbound|9001||
0.0.0.0 15006 Trans: tls; Addr: *:9001                                                                        Cluster: inbound|9001||
0.0.0.0 15006 Trans: raw_buffer; Addr: *:9001                                                                 Cluster: inbound|9001||
0.0.0.0 15006 Trans: tls; App: istio,istio-peer-exchange,istio-http/1.0,istio-http/1.1,istio-h2; Addr: *:9000 Cluster: inbound|9000||
0.0.0.0 15006 Trans: tls; Addr: *:9000                                                                        Cluster: inbound|9000||
0.0.0.0 15006 Trans: raw_buffer; Addr: *:9000                                                                 Cluster: inbound|9000||

Giờ mình thực hiện xoá port 9000 trong service của tcp-echo

ping service và port thì ko được
ping pod ip và port thì ok

Bạn thấy dòng log cuối dùng đã có sự thay đổi.

Workload tcp-echo còn có port 9002 nhưng chúng ta ko config trên deployment hay service.
nên khi muốn call vào workload với pod 9002 thì chỉ có thể call pod IP

TCP_ECHO_IP=$(kubectl get pod "$(kubectl get pod -l app=tcp-echo -n default -o jsonpath={.items..metadata.name})" -n default -o jsonpath="{.status.podIP}")
root@work-space-u20:# echo $TCP_ECHO_IP
10.244.36.252

Giờ có ip của pod thì chiến thôi

kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- sh -c "echo \"port 9002\" | nc $TCP_ECHO_IP 9002" | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'

>>>output
hello port 9002
connection succeeded

Nhìn access log này chúng ta có thể ngầm hiểm, route inbound 9000 đã bị xoá trong bảng route istio vì chúng ta đã xoá mất service.

https://istio.io/latest/docs/ops/configuration/traffic-management/traffic-routing/#headless-services

Mình có đọc bài này:
Ví dụ usecase của bạn Pod to Pod:
Workload A và Workload B đều được injected istio
Workload B có cấu hình Service port B
khi pod A connect to PodB IP. thì trên route istio sẽ ko có IP của pod B. theo mình follow sẽ như sau:
pod A -> OutboundPassthroughClusterIpv4 (istio-proxy A) -> InboundPassthroughClusterIpv4(istio-proxy B) -> workload B.

3.2.1) Giving Pod ip to route table of istio

Vậy nếu bạn muốn trong bảng route của istio có route Pod B thì làm sao nhỉ?

Theo istio “In general, Istio does not configure listeners for each Pod IP, as it works at the Service level. However, to support headless services, listeners are set up for each IP:Port pair in the headless service.“

Thì bạn có thể tạo service headless thì istio sẽ gán Pod IP với service headless vào route của istio
Nếu bạn muốn thấy rõ như nào thì mời bạn xem link bên dưới:
https://nimtechnology.com/2021/11/21/istio-discover-route-inside-istio/#2_Discovery

3.2.2) Testing pod to pod with strict mode (mTLS)

Pod to pod có hoặc động được khi bật strict mode (mTLS) hay không?

[Istio] Security authentication và authorization with ISTIO

Tham khải mTLS strict

root@work-space-u20:~# kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- sh -c 'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
hello port 9000
connection succeeded
root@work-space-u20:~# kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- sh -c 'echo "port 9000" | nc 10.244.36.252 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
connection rejected

Khi bật mTLS với strict mode thì pod to pod bị fail
Và làm sao làm được pod to pod với strict mode.

Bạn cần tạo service headless cho port và sử dụng cho mục đích pod to pod