Прокси-протокол ELB (Classic Load Balancer) не работает на кластере Kubernetes - PullRequest
0 голосов
/ 07 февраля 2019
  • Создан кластер K8s на AWS (EKS).
  • Создана рабочая нагрузка развертывания.
  • Создан балансировщик нагрузки типа службы с аннотацией service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*" (который должен включать прокси-протокол на ELB) для TCP-порта 4334.

Так что в моем модуле я не вижу протокол Proxy, сохраняющий IP-адрес клиента.Пробовал анализаторы пакетов и tcpdump, но не там, где я вижу, что IP-адрес клиента сохраняется по протоколу.

Кто-нибудь может сказать мне, как проверить, что прокси-протокол сохраняет IP-адрес клиента?

См. Балансировщик нагрузкиупомянуто ниже.У него есть политика с именем «k8s-proxyprotocol-enabled», которая применяется к «BackendServerDescription» на порту 31431 экземпляра.

Одна вещь, которую я заметил, заключается в том, что в «ListenerDescription», например, порт 31431, имя политики пусто.Для того, чтобы прокси-протокол работал должным образом, необходимо ли применять политику «k8s-proxyprotocol-enabled» к политике прослушивателя в описании прослушивателя?

Может ли кто-нибудь подтвердить, что приведенный ниже конфиг достаточен для протокола Proxy для сохранения исходного IP-адреса, или необходимо выполнить дополнительную настройку?

"LoadBalancerDescriptions": [
    {
        "Subnets": [
            "subnet-1",
            "subnet-2",
            "subnet-2"
        ],
        "CanonicalHostedZoneNameID": "******",
        "CanonicalHostedZoneName": "*************",
        "ListenerDescriptions": [
            {
                "Listener": {
                    "InstancePort": 31431,
                    "LoadBalancerPort": 4334,
                    "Protocol": "TCP",
                    "InstanceProtocol": "TCP"
                },
                "PolicyNames": []
            }
        ],
        "HealthCheck": {
            "HealthyThreshold": 2,
            "Interval": 10,
            "Target": "TCP:31499",
            "Timeout": 5,
            "UnhealthyThreshold": 6
        },
        "VPCId": "vpc-***********",
        "BackendServerDescriptions": [
            {
                "InstancePort": 31431,
                "PolicyNames": [
                    "k8s-proxyprotocol-enabled"
                ]
            }
        ],
        "Instances": [
            {
                "InstanceId": "i-085ece5ecf"
            },
            {
                "InstanceId": "i-0b4741cf"
            },
            {
                "InstanceId": "i-03aea99"
            }
        ],
        "DNSName": "***************************",
        "SecurityGroups": [
            "sg-********"
        ],
        "Policies": {
            "LBCookieStickinessPolicies": [],
            "AppCookieStickinessPolicies": [],
            "OtherPolicies": [
                "k8s-proxyprotocol-enabled"
            ]
        },
        "LoadBalancerName": "a1df476de2aa011e9aabe0af927e6700",
        "CreatedTime": "2019-02-07T06:18:01.020Z",
        "AvailabilityZones": [
            "us-east-1a",
            "us-east-1b",
            "us-east-1c"
        ],
        "Scheme": "internet-facing",
        "SourceSecurityGroup": {
            "OwnerAlias": "906391276258",
            "GroupName": "k8s-elb-a1df476de2aa011e9aabe0af927e6700"
        }
    }
]

1 Ответ

0 голосов
/ 08 февраля 2019

Да, этой аннотации достаточно для включения протокола Proxy Protocol v1 на уровне балансировки нагрузки (ELB Classic).

service.beta.kubernetes.io / aws-load-balancer-proxy-protocol: "*"

У меня есть контроллер ingress-nginx, доступный через сервисный тип LoadBalancer с вышеупомянутой аннотацией, и когда я запускаю его с уровнем ведения журнала, установленным на debug , я вижучто каждый запрос клиента сохраняет реальный IP-адрес источника:

172.20.32.78 - [172.20.32.78] - - [08 / Feb / 2019: 18: 02: 43 +0000] "PROXY TCP4 xxx.xxx.xxx.xx 172.20.xx.xxx 42795 80 "400 157" - "" - "0 0.172 []


xxx.xxx.xxx.xx - это мой частный IP-адрес, а не LB один.

Другое дело - включить прокси-протокол на бэкэнде LB, чтобы он мог правильно понимать перенаправленные клиентские запросы (здесь описаны шаги для NGINX ).

...