Bối cảnh:
gần đây tôi đã gặp sự cố trong đó nhóm kubernetes (trình xuất hộp đen) sẽ nhận được phản hồi trống bất cứ khi nào nó cố gọi một URL đầu vào của nhóm nằm trong cùng một nút với chính nó. Điều này được phản ánh là một đầu dò không liên tục trên bảng điều khiển.
Bộ điều khiển xâm nhập được sử dụng là ingress-nginx và nằm sau AWS NLB.
Ví dụ:
nút1: 192.168.20.2
nút2: 192.168.20.3
nút3: 192.166.20.4
trình xuất hộp đen (được triển khai trong nút1, với clusterIP 10.244.2.21)
foo-pod (được triển khai trong nút1, với clusterIP 10.244.2.22)
foo-pod (được triển khai trong node2, với clusterIP 10.244.2.23)
foo-pod (được triển khai trong node3, với clusterIP 10.244.2.24)
Nhật ký bộ điều khiển xâm nhập:
192.168.20.3 - - [21/Jun/2021:15:15:07 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0.005 [foo-pod] [] 10.32 .0.2:3000 30015 0.004 200 e39022b47e857cc48eb6a127a7b8ce24
192.168.20.4 - - [21/Jun/2021:15:16:00 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0.005 [foo-pod] [] 10.32 .0.2:3000 30015 0.004 200 e39022b47e857cc48eb6a127a7b8ce24
192.168.20.3 - - [21/Jun/2021:15:16:30 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0.005 [foo-pod] [] 10.32 .0.2:3000 30015 0.004 200 e39022b47e857cc48eb6a127a7b8ce24
Theo dõi nhật ký của bộ điều khiển xâm nhập cho thấy rằng "phản hồi trống" (hết thời gian chờ sau 5 giây) chỉ xảy ra khi nhóm thực hiện lệnh gọi URL xâm nhập được triển khai trong cùng một nút với nhóm đích được cho là sẽ phản hồi lệnh gọi đó.
Kết luận được đưa ra dựa trên thực tế là bất cứ khi nào nhận được "phản hồi trống", sẽ không bao giờ có nhật ký nào có IP gốc khớp với IP nút mà trình xuất hộp đen đang ở, trong trường hợp này phải là nút1 192.168.20.2.
Nghi ngờ nó liên quan đến IP nguồn "không chính xác" và kết quả là nhóm mục tiêu không biết cách trả lời phản hồi, tôi đã chuyển sang sử dụng AWS Classic L7 LB và sự cố đã được giải quyết.
Bây giờ nhật ký cho thấy IP nguồn đã được thay thế bằng ClusterIP nhóm thực tế và tất cả các cuộc gọi thăm dò từ trình xuất hộp đen đều thành công.
10.244.2.21 - - [21/Jun/2021:15:15:07 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10.32 .0.2:3000 30015 0.004 200 e39022b47e857cc48eb6a127a7b8ce24
10.244.2.21 - - [21/Jun/2021:15:16:00 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10.32 .0.2:3000 30015 0.004 200 e39022b47e857cc48eb6a127a7b8ce24
10.244.2.21 - - [21/Jun/2021:15:16:30 +0000] "GET /metrics HTTP/1.1" 200 29973 "-" "curl/7.47.0" 90 0,005 [foo-pod] [] 10.32 .0.2:3000 30015 0.004 200 e39022b47e857cc48eb6a127a7b8ce24
Thêm thông tin:
Phiên bản cụm: AWS EKS v1.19
Câu hỏi:
Mạng Linux/kubernetes không phải là thế mạnh của tôi, vì vậy điều tôi muốn hỏi là, chính xác thì chuyện gì đang xảy ra ở đây?
Tại sao việc chuyển sang sử dụng bộ cân bằng tải AWS Classic L7 lại giải quyết được vấn đề?
bất kỳ thành phần nào khác (kubernetes OR linux) cũng có thể ảnh hưởng đến điều này không?
