Ожидается ли поведение, что kube-proxy не остановит маршрутизацию к модулям на главных узлах, или что-то «сломано»?
Доступны ли какие-либо обходные пути для такого рода настройки, позволяющие рабочим узлам по-прежнему функционировать правильно?
Ведущий кластера играет роль лица, принимающего решения для различных действий в узлах кластера. , Это может включать планирование рабочих нагрузок, управление жизненным циклом рабочих нагрузок, масштабирование и т. Д. c. Каждый узел управляется основными компонентами и содержит службы, необходимые для запуска модулей. Службы на узле обычно включают в себя kube-proxy, среду выполнения контейнера и kubelet.
Компонент kube-proxy обеспечивает соблюдение сетевых правил на узлах и помогает kubernetes управлять подключениями между модулями и службами. Кроме того, kube-proxy действует как выходной контроллер балансировки нагрузки, который постоянно отслеживает сервер API kubernetes и постоянно обновляет подсистему iptables узла на его основе.
Проще говоря, только главный узел знает обо всем и отвечает за создание списка правил маршрутизации, а также на основе добавления или удаления узла и т. д. c. kube-proxy играет своего рода принудительную функцию, посредством которой он отвечает за проверку с помощью master, синхронизацию информации и применение правил в списке.
Если главный узел (сервер API) не работает, кластер не будет способен отвечать на команды API или развертывать узлы. Если другой главный узел недоступен, не должно быть никого, кто мог бы проинструктировать рабочие узлы об изменении в распределении работы, и, следовательно, они должны продолжать выполнять операции, которые были ранее запланированы главным, до тех пор, пока главный узел не вернется. и дает разные инструкции. В дополнение к этому, kube-proxy также не сможет получить последние правила с помощью syn c до master, однако он не должен останавливать маршрутизацию и должен продолжать обрабатывать функции сети и маршрутизации (использует ранее определенные правила iptable, которые были определены до того, как мастер-узел вышел из строя), который должен обеспечивать сетевую связь с вашими модулями, при условии, что все модули в рабочих узлах все еще работают и работают.
Архитектура на основе одного главного узла не является предпочтительной архитектурой развертывания для производства. Учитывая, что отказоустойчивость и надежность являются одной из основных бизнес-целей kubernetes, рекомендуется в качестве наилучшей практики использовать архитектуру на основе кластера HA, чтобы избежать единой точки отказа.