Является ли Google Container Engine Kubernetes Service LoadBalancer отправлением трафика на невосприимчивые хосты?

Question

Вопрос: Является ли облачная сеть Google Cloud LoadBalancer, созданная Kubernetes (через Google Container Engine), отправляет трафик на хосты, которые не прослушиваются? «Этот целевой пул не имеет проверки работоспособности, поэтому трафик будет отправлен во все экземпляры, независимо от их статуса».

У меня есть сервис (обратный прокси-сервер NGINX), предназначенный для конкретных контейнеров и доступный TCP: 80, 443. В моем примере в пул экземпляров работает только один модуль NGINX. Тип службы - «LoadBalancer». С помощью Google Container Engine создается новый LoadBalancer (LB), который указывает целевые пулы, конкретные экземпляры виртуальных машин. Затем создается эфемерный внешний IP-адрес для LB и связанного с ним правила брандмауэра, который разрешает входящий трафик.

Моя проблема заключается в том, что описание правила автоматического создания firewall Kubernetes является «KubernetesAutoGenerated_OnlyAllowTrafficForDestinationIP_1.1.1.1» (IP - это внешний IP-адрес LB). В тестировании я заметил, что хотя каждый экземпляр виртуальной машины имеет внешний IP-адрес, я не могу связаться с ним на порту 80 или 443 на любом из IP-адресов экземпляра, а только на LB IP. Это неплохо для внешнего трафика пользователя, но когда я попытался создать проверку работоспособности для моего LB, я обнаружил, что он всегда видел, что службы недоступны, когда он проверял каждый экземпляр виртуальной машины по отдельности.

У меня есть правильные правила брандмауэра, чтобы любой IP-адрес мог связываться с TCP 443, 80 на любом экземпляре в моем пуле, так что это не проблема.

Может кто-нибудь объяснить это мне, потому что это заставляет меня думать, что LB передает HTTP-запросы в оба экземпляра, несмотря только на один из тех экземпляров, на котором работает NGINX-блок.

Answer 1

Является ли Google Cloud-сеть LoadBalancer, созданной Kubernetes (через Google Container Engine), отправляющей трафик на хосты, которые не прослушивают?

Все хосты (которые в настоящее время выполняют функциональный процесс kube-proxy) способны принимать и обрабатывать входящие запросы для внешней службы. Запросы будут размещаться на виртуальной машине произвольного узла в вашем кластере, соответствовать правилу iptables и пересылаться (посредством процесса kube-proxy) в модуль, который имеет селектор ярлыков, соответствующий службе.

Таким образом, случай, когда средство проверки работоспособности предотвратит падение запросов, - это если у вас есть виртуальная машина узла, работающая в разбитом состоянии. У виртуальной машины все еще будет целевой тег, соответствующий правилу пересылки, но не сможет обрабатывать входящие пакеты.

В ходе тестирования я заметил, что даже если каждый экземпляр виртуальной машины имеет внешний IP-адрес, я не могу связаться с ним на порту 80 или 443 на любом из IP-адресов экземпляра, а только на LB IP.

Это изделие так, как планировалось. Каждая служба может использовать любой желаемый порт, что означает, что несколько служб могут использовать порты 80 и 443. Если пакет поступает на IP-адрес хоста на порт 80, хост не имеет способа узнать, какая из (возможно, многих) служб использует порт 80 пакет должен быть перенаправлен. Правила iptables для служб обрабатывают пакеты, предназначенные для IP-адреса виртуального внутреннего кластера и внешнего IP-сервиса, но не IP-адрес хоста.

Это не плохо для внешнего трафика пользователя, но когда я попытался создать проверку работоспособности для своего LB, я обнаружил, что он всегда видел, что службы недоступны, когда он проверял каждый экземпляр виртуальной машины по отдельности.

Если вы хотите настроить Healthcheck, чтобы убедиться, что узел работает правильно, вы можете Healthcheck процесс kubelet, который работает на порту 10250 путем установки правила брандмауэра:

$ gcloud compute firewall-rules create kubelet-healthchecks \ 
    --source-ranges 130.211.0.0/22 \ 
    --target-tags $TAG \ 
    --allow tcp:10250 

(чек из документации Container Engine HTTP Load Balancer, чтобы узнать, что вы должны использовать для $TAG).

Было бы лучше для здоровья проверить процесс Кубэ-прокси напрямую, но это только binds to localhost, в то время как процесс kubelet binds to all interfaces поэтому добраться шашками здоровья, и он должен служить хорошим показателем того, что узел является достаточно здоровым для обслуживания запросов к вашей службе.