15-минутный тайм-аут в кластере HA k8s при остановке узла

Я настроил кластер k8s более или менее следующим это руководство. Итак, у меня есть три узла master и control-plane. Я использую haproxy в качестве балансировщика нагрузки со следующей конфигурацией:

#/etc/haproxy/haproxy.cfg
#--------------------------------------------- --------------------
# Глобальные настройки
#--------------------------------------------- --------------------
Глобальный
    журнал /dev/лог локальный0 
    журнал /dev/log локальная1 информация
    демон

#--------------------------------------------- --------------------
# общие настройки по умолчанию для всех секций прослушивания и бэкенда
# использовать, если не указано в их блоке
#--------------------------------------------- --------------------
значения по умолчанию
    режим http
    журнал глобальный
    опция httplog
    опция
    опция http-server-close
    опция forwardfor кроме 127.0.0.0/8
    опция повторной отправки
    повторная попытка 1
    таймаут http-запроса 10s
    очередь ожидания 20 сек.
    тайм-аут соединения 5s
    тайм-аут клиента 20 сек.
    тайм-аут сервера 20 секунд
    тайм-аут http-keep-alive 10s
    проверка тайм-аута 10s

#--------------------------------------------- --------------------
# интерфейс apiserver, который проксирует узлы плоскости управления
#--------------------------------------------- --------------------
внешний интерфейс
    привязать *:8443
    режим TCP
    опция tcplog
    default_backend

#--------------------------------------------- --------------------
# циклическая балансировка для apiserver
#--------------------------------------------- --------------------
серверный сервер
    опция httpchk GET /healthz
    http-check ожидает статус 200
    режим TCP
    опция ssl-hello-chk
    опция tcp-check
    круговой баланс
    сервер k8s1 x.x.x.15:6443 проверить
    сервер k8s2 x.x.x.16:6443 проверка
    сервер k8s3 x.x.x.17:6443 проверка

а также keepalived для управления VIP:

! /etc/keepalived/keepalived.conf
! Файл конфигурации для поддержки активности
global_defs {
    router_id LVS_DEVEL
}
vrrp_script check_apserver {
  скрипт "/etc/keepalived/check_apiserver.sh"
  интервал 3
  тайм-аут 5
  осень 10
  подъем 2
}

vrrp_instance VI_1 {
    резервная копия состояния
    интерфейс ens18
    виртуальный_роутер_id 53
    приоритет 101
    аутентификация {
        auth_type ПАРОЛЬ
        auth_pass 123456
    }
    виртуальный_ipaddress {
        х.х.х.18
    }
    track_script {
        check_apserver
    }
}

и скрипт check_apserver:

#!/usr/bin/env bash

ошибкаВыход() {
    эхо "*** $*" 1>&2
    выход 1
}

curl --silent --max-time 2 --insecure https://localhost:6443/ -o /dev/null || errorExit "Ошибка GET https://localhost:6443/"
если IP-адрес | grep -q ${VIP}; тогда
    curl --silent --max-time 2 --insecure https://x.x.x.18:8443/ -o /dev/null || errorExit "Ошибка GET https://x.x.x.18:8443/"
фи

kubelet, kubeadm и kubectl версии 1.22.2

Я создаю кластер, используя

sudo kubeadm init --control-plane-endpoint "x.x.x.18:8443" --upload-certs --v=5 --pod-network-cidr=172.31.0.0/16

и добавьте плетение, используя

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(версия kubectl | base64 | tr -d '\n')&env.IPALLOC_RANGE=172.31.0.0/16"

С этой конфигурацией я могу создать, например. кластер EMQX. Проблема появляется всякий раз, когда я останавливаю один узел. Каждый statefulset, у которого был запущен Pod на остановленном узле, перестает отвечать ровно на 15 минут.

Проверка активности с помощью ip as ens18 Я вижу, как VIP почти мгновенно перемещается на работающий узел. Используя панель статистики haproxy, узел помечается как активный, переходящий в ВНИЗ через 2 секунды, и активный или резервный ВНИЗ еще через 4 секунды. Кажется, это тоже работает.

Изменение тайм-аутов kubernetes (например, времени выселения пода) действительно работает, так что поды помечаются как закрывающиеся раньше, но statefulset остается без ответа в течение 15 минут независимо от времени выселения.

Настройка сети с тремя узлами со всеми узлами master и control-plane не показывает такого поведения, поэтому я предполагаю, что это проблема конфигурации k8s. Но чего мне не хватает?

Edit1: кластер остается доступным в это время, так что я могу посмотреть, как kubectl получает все --all-namespaces -o wide для проверки состояния кластера. Все, что я вижу, это то, что модули из остановленного узла остаются в завершающем состоянии.

Edit2: единственным подозрительным поведением было обнаружение нового MAC-адреса через 15 минут.Чтобы ускорить поиск ошибок, я начал вид без собственного CNI и вместо этого использовал weave. Благодаря этому я смог добиться идентичных журналов и точно такой же проблемы, как с «настоящим» кластером kubernetes. К сожалению, мне не повезло с логами отладки weaves, поэтому я перешел на calico CNI и изменил podSubnet на 192.168.0.0/16. Это решило проблему в натуральной форме, но применение точно такого же решения к моему кластеру kubernetes снова оставляет меня с той же проблемой...