Cách đọc địa chỉ IP của khách hàng từ các yêu cầu HTTP phía sau dịch vụ Kubernetes?

Question

ứng dụng web của tôi đang chạy dưới dạng Kubernetes pod phía sau proxy ngược nginx cho SSL. Cả proxy và ứng dụng của tôi đều sử dụng các dịch vụ Kubernetes để cân bằng tải (như được mô tả here).

Vấn đề là tất cả nhật ký yêu cầu HTTP của tôi chỉ hiển thị địa chỉ IP cụm nội bộ thay vì địa chỉ của các máy khách HTTP thực tế. Có cách nào để làm cho dịch vụ Kubernetes chuyển thông tin này đến máy chủ ứng dụng của tôi không?

Answer 1

Bạn có thể nhận ra Kube-proxy của vòng lặp hoàn toàn bằng 2 cách:

1. Sử dụng một Ingress để cấu hình nginx của bạn để cân bằng dựa trên nguồn ip và gửi lưu lượng thẳng đến điểm cuối của bạn (https://github.com/kubernetes/contrib/tree/master/ingress/controllers#ingress-controllers)

2. Triển khai haproxy serviceloadbalancer (https://github.com/kubernetes/contrib/blob/master/service-loadbalancer/service_loadbalancer.go#L51) và đặt chú thích số dư trên serivce để nó sử dụng "nguồn".

Answer 2

Hiện tại, không.

Dịch vụ sử dụng kube_proxy để phân phối lưu lượng truy cập đến các chương trình phụ trợ của họ. Kube-proxy sử dụng iptables để định tuyến dịch vụ IP đến một cổng cục bộ nơi nó đang lắng nghe, và sau đó mở ra một kết nối mới đến một trong các phụ trợ. IP nội bộ bạn đang thấy là IP: cổng của kube-proxy đang chạy trên một trong các nút của bạn.

Một iptables chỉ kube-proxy là in the works. Điều đó sẽ bảo vệ IP nguồn gốc.

Answer 3

Kể từ Kubernetes 1.1, có một kube-proxy dựa trên iptables sửa lỗi này trong một số trường hợp. Nó được tắt theo mặc định; xem this post để được hướng dẫn cách bật tính năng này. Tóm lại, hãy làm:

for node in $(kubectl get nodes -o name); do kubectl annotate $node net.beta.kubernetes.io/proxy-mode=iptables; done 

Trong trường hợp lưu lượng Pod-to-Pod, với iptables kube-proxy, giờ đây bạn sẽ thấy nguồn IP đích tại điểm đến.

Tuy nhiên, nếu Dịch vụ của bạn đang chuyển tiếp lưu lượng truy cập từ bên ngoài cụm (ví dụ: dịch vụ NodePort, LoadBalancer), thì chúng tôi vẫn phải thay thế (SNAT) nguồn-IP. Điều này là do chúng tôi đang làm DNAT trên lưu lượng truy cập đến để định tuyến nó đến dịch vụ Pod (có khả năng trên một Nút khác), do đó nút DNATing cần chèn chính nó vào đường dẫn trả về để có thể hủy bỏ phản hồi DNAT.

Answer 4

Đối với các yêu cầu không phải HTTP (HTTPS, gRPC, v.v ...), dự kiến ​​sẽ được hỗ trợ trong Kubernetes 1.4. Xem: https://github.com/kubernetes/features/issues/27

Answer 5

Từ 1.5, nếu bạn đang chạy trong GCE (theo GKE mở rộng) hoặc AWS, bạn chỉ cần thêm chú thích vào Dịch vụ của mình để thực hiện công việc bảo tồn nguồn HTTP.

... 
kind: Service 
metadata: 
    annotations: 
    service.beta.kubernetes.io/external-traffic: OnlyLocal 
... 

Nó cơ bản cho thấy nhiều dịch vụ trực tiếp qua nodeports thay vì cung cấp một proxy - bằng cách phơi bày một cuộc điều tra sức khỏe trên mỗi nút, cân bằng tải có thể xác định các nút giao thông đường đến.

Trong 1.7, cấu hình này đã trở thành GA, vì vậy bạn có thể đặt "externalTrafficPolicy": "Local" trên Thông số dịch vụ của mình.

Click here to learn more