Кубернетес - безопасность внутренней балансировки нагрузки

Question

Мы расширяем наше приложение для микросервисного стада, и я смотрел на Кубернете для наших нужд. До моего погружения в современные оркестровки я думал об открытии сервиса следующим образом:

• Кластера загрузился с каким-то распределенной службой реестра (консул в нашем случае)
• Каждой службу запускаются с реестром службы конечные точки, передаваемые в каким-то образом
• Каждый сервис самостоятельно регистрирует себя в реестре
• Когда служба нуждается в некоторых других служебных адресов, она извлекает точки контакта из реестра

В этом случае, если какая-либо услуга терпит неудачу или произойдет какое-то сетевое нарушение, служба клиента может перейти к следующей точке контакта и, в конечном счете, преуспеть (в случае, если она не полностью отключена). Насколько я понял, kubernetes использует совершенно другую модель:

• Всех стручки самостоятельно зарегистрированы в kubernetes
• Kubernetes обеспечивает экземпляр балансира одного нагрузок для передачи трафика через к услугам
самого
• балансировки нагрузки может быть обнаружены через переменные среды или DNS-запрос (и это может привести к жутким вещам, таким как выборка из записей DNS или просто устаревшей переменной окружения)

И это меня немного смущает. Если я прав (не стесняйтесь сказать мне, что нет, если это так), это в основном превращает балансировщик нагрузки в SPOF, который может остановить все приложение в момент его смерти. Я прав? Существуют ли какие-либо гарантии Кубернеса о том, что такая ситуация не будет или будет решена в <N> < единиц времени >?

Answer 1

Распределитель нагрузки в кластере в Кубернете (kube-proxy) распределяется между всеми узлами вашего кластера. Он синхронизирует все конечные точки службы с правилами iptables на узле. Kube-proxy проверяется на здоровье kubelet и будет перезапущен, если он нездоровый в течение 30 секунд (это, по-моему, настраивается). Фактический трафик не проходит через двоичный код kube-proxy, поэтому, если kube-proxy застрял, самое худшее, что происходит, - ваше представление о конечных точках обслуживания становится устаревшим. Взгляните на документы и Virtual IPs section из Сервисных документов, Services FAQs и slides 46-61 этой сетевой колоды kubernetes для получения более подробной информации о kube-proxy.

Для обнаружения услуг каждая услуга доступна по имени через kube-dns. Pods имеют kube-dns в своем пути поиска, поэтому нет необходимости изменять переменную окружения. Slides 68-83 этой же колоды имеет полное прохождение DNS-> Virtual IP-> Pod трафика.

Таким образом, балансировщик нагрузки не является SPOF. Он должен в основном делиться судьбой с рабочими нагрузками, выполняемыми на одном узле. Kube-dns может быть SPOF для обнаружения сервисов, но он может быть реплицирован, как вам нравится.