Istio Ingress Controller не сохраняет первоначальный IP-адрес клиента - PullRequest
Новая
       9

Istio Ingress Controller не сохраняет первоначальный IP-адрес клиента

0 голосов
/ 12 июня 2018

Мы используем Istio 0.7 с входным контроллером istio для обработки запросов других стран.Мы используем свойство "externalIPs" типа службы "ClusterIP", чтобы выставить входной контроллер за пределами kubernetes.

Контроллер входа Istio Yaml: 

apiVersion: v1
kind: Service
metadata:
  name: istio-ingress-3
  namespace: istio-system
  labels:
    istio: ingress
spec:
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
  externalIPs:
  - 192.168.X.X
  selector:
    istio: ingress-3
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: istio-ingress-3
  namespace: istio-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        istio: ingress-3
      annotations:
        sidecar.istio.io/inject: "false"
    spec:
      nodeSelector:
        kubernetes.io/hostname: node3.example.com
      serviceAccountName: istio-ingress-service-account
      containers:
      - name: istio-ingress
        image: docker.io/istio/proxy:0.7.1
        args:
        - proxy
        - ingress
        - --discoveryAddress
        - istio-pilot:8080 #--controlPlaneAuthPolicy
        - --discoveryRefreshDelay
        - '1s' #discoveryRefreshDelay
        - --drainDuration
        - '45s' #drainDuration
        - --parentShutdownDuration
        - '1m0s' #parentShutdownDuration
        - --connectTimeout
        - '10s' #connectTimeout
        - --serviceCluster
        - istio-ingress
        - --zipkinAddress
        - zipkin:9411
        - --statsdUdpAddress
        - istio-mixer:9125
        - --proxyAdminPort
        - "15000"
        - --controlPlaneAuthPolicy
        - NONE #--controlPlaneAuthPolicy
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        - containerPort: 443
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        volumeMounts:
        - name: istio-certs
          mountPath: /etc/certs
          readOnly: true
        - name: ingress-certs
          mountPath: /etc/istio/ingress-certs
          readOnly: true
      volumes:
      - name: istio-certs
        secret:
          secretName: istio.istio-ingress-service-account
          optional: true
      - name: ingress-certs
        secret:
          secretName: istio-ingress-certs
          optional: true

Проблемакаждый раз, когда мы проверяем журналы входного контроллера после запуска запроса, он выдает тот же ip, который мы указали во внешнем ip (host ip).Но нам нужна исходная информация клиента, такая как исходный IP-адрес клиента

То, что вы ожидали получить:

Нам нужен оригинальный IP-адрес клиента, а не IP-адрес, указанный во externalIP, т.е.(192.168.XX).

Дополнительная информация

Я проверил в Интернете и обнаружил, что с помощью флага "externalTrafficPolicy: Local" мы можем сохранить ip клиента, ноэтот флаг действителен только в сервисах типа NodePort.И мы не хотим использовать сервис NodePort, потому что, если мы его используем, он откроет наш входной контроллер для всех интерфейсов для хоста, как частного, так и публичного.

Kubernetes version

Версия клиента: version.Info {Major: "1", Minor: "10", GitVersion: "v1.10.1", GitCommit: "d4ab47518836c750f9949b9e0d387f20fb92260b", GitTreeStateD: "clean", Buate, Buate"2018-04-12T14: 26: 04Z", GoVersion: "go1.9.3", компилятор: "gc", платформа: "linux / amd64"} Версия сервера: version.Info {Major: "1", Minor: "10 ", GitVersion:" v1.10.3 + coreos.0 ", GitCommit:" f1b890dbbf11abe58280b3ffe17d67749f5ae70e ", GitTreeState:" clean ", BuildDate:" 2018-05-21T17: 27: 17Z ", GoVersion:" компилятор 1 ": "gc", платформа: "linux / amd64"}

ОС (например, из / etc / os-release)

NAME =«Контейнер Linux от CoreOS» ID = coreos VERSION = 1745.5.0 VERSION_ID = 1745.5.0 BUILD_ID = 2018-05-31-0701 PRETTY_NAME = "Контейнер Linux от CoreOS 1745.5.0 (Rhyolite)" ANSI_COLOR = "38; 5; 75" ГЛАВНАЯ_URL = "https://coreos.com/" BUG_REPORT_URL =" https://issues.coreos.com" COREOS_BOARD = "amd64-usr"

Ядро (например, uname -a)

Linux node1.example.com 4.14.44-coreos-r1 # 1 SMP, четверг, 31 мая 06:04:02 UTC 2018 x86_64 Процессор Intel (R) Xeon (R) L5640 @ 2,27 ГГц GenuineIntel GNU / Linux

Может кто-нибудь нам помочь?

1 Ответ

0 голосов
/ 13 июня 2018

Исходя из этой проблемы GitHub он выглядит , что Istio достаточно умен, чтобы включить заголовок X-Forwarded-For в свои запросы в восходящем направлении, поэтому я ожидаю, что Pod назначения необходимо обновитьобратиться к этому заголовку, а не к $HTTP_REMOTE или к какому-либо механизму, который он использует для получения IP-адреса.

...