Timeout de 15 minute în clusterul HA k8s când nodul se oprește

Am configurat un cluster k8s mai mult sau mai puțin următor acest ghid. Deci am trei noduri master și plan de control. Folosesc haproxy ca echilibrator de încărcare cu următoarea configurație:

#/etc/haproxy/haproxy.cfg
#--------------------------------------------- --------------------
# Setări globale
#--------------------------------------------- --------------------
global
    log /dev/log local0 
    log /dev/log local1 informații
    demonul

#--------------------------------------------- --------------------
# valori implicite comune pe care le vor face toate secțiunile de ascultare și backend
# utilizați dacă nu este desemnat în blocul lor
#--------------------------------------------- --------------------
implicite
    modul http
    jurnal global
    opțiunea httplog
    opțiunea dontlognull
    opțiunea http-server-close
    opțiune forwardfor, cu excepția 127.0.0.0/8
    reexpedierea opțiunii
    reîncercări 1
    timeout http-request 10s
    timeout coada 20s
    timeout conectare 5s
    timeout client 20s
    timeout server 20s
    timeout http-keep-alive 10s
    verificare timeout 10s

#--------------------------------------------- --------------------
# apiserver frontend care se adresează proxy la nodurile planului de control
#--------------------------------------------- --------------------
apiserver frontend
    lega*:8443
    modul tcp
    opțiunea tcplog
    default_backend apiserver

#--------------------------------------------- --------------------
# echilibrare round robin pentru apiserver
#--------------------------------------------- --------------------
apiserver backend
    opțiunea httpchk GET /healthz
    http-check aștept starea 200
    modul tcp
    opțiunea ssl-hello-chk
    opțiunea tcp-check
    echilibru roundrobin
    server k8s1 x.x.x.15:6443 verifica
    server k8s2 x.x.x.16:6443 verifica
    server k8s3 x.x.x.17:6443 verifica

precum și keepalived pentru gestionarea unui VIP:

! /etc/keepalived/keepalived.conf
! Fișier de configurare pentru keepalived
global_defs {
    router_id LVS_DEVEL
}
vrrp_script check_apiserver {
  scriptul „/etc/keepalived/check_apiserver.sh”
  intervalul 3
  timeout 5
  toamna 10
  ridica 2
}

vrrp_instance VI_1 {
    stare BACKUP
    interfata ens18
    virtual_router_id 53
    prioritatea 101
    autentificare {
        auth_type PASS
        auth_pass 123456
    }
    adresa_virtuală {
        x.x.x.18
    }
    track_script {
        check_apserver
    }
}

și scriptul check_apserver:

#!/usr/bin/env bash

errorExit() {
    ecou „*** $*” 1>&2
    iesirea 1
}

curl --silent --max-time 2 --insecure https://localhost:6443/ -o /dev/null || errorExit „Eroare GET https://localhost:6443/”
dacă ip adresă | grep -q ${VIP}; atunci
    curl --silent --max-time 2 --insecure https://x.x.x.18:8443/ -o /dev/null || errorExit „Eroare GET https://x.x.x.18:8443/”
fi

kubelet, kubeadm și kubectl sunt toate versiunile 1.22.2

Eu creez clusterul folosind

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

și adăugați țesătură folosind

kubectl aplică -f "https://cloud.weave.works/k8s/net?k8s-version=$(versiunea kubectl | base64 | tr -d '\n')&env.IPALLOC_RANGE=172.31.0.0/16"

Cu această configurație pot crea de ex. un cluster EMQX. Problema apare ori de câte ori opresc un nod. Fiecare set de stare, care a avut un Pod care rulează pe nodul oprit, devine fără răspuns pentru aproape 15 minute.

Verificarea keepalived folosind ip a s ens18 Văd că VIP-ul se mișcă aproape instantaneu într-un nod care rulează. Folosind tabloul de bord cu statistici haproxy, nodul este marcat ca activ în sus mergând în JOS după 2 secunde și activ sau în jos după încă 4 secunde. Se pare că funcționează și asta.

Modificarea timeout-urilor kubernetes (de exemplu, timpul de evacuare a podului) funcționează, astfel încât Pod-urile să fie marcate ca fiind încheiate mai devreme, dar setul de stare rămâne fără răspuns timp de 15 minute, indiferent de ora de evacuare.

Configurarea unei rețele cu trei tipuri de noduri cu toate nodurile master și planul de control nu arată acest comportament, motiv pentru care bănuiesc că este o problemă de configurare k8s. Dar ce îmi lipsește?

Edit1: cluster-ul rămâne accesibil în acel timp, astfel încât eu să pot urmăriți cum kubectl obține toate --all-namespaces -o late pentru a verifica starea clusterului. Tot ce văd este că podurile de la nodul oprit rămân în stare finală.

Edit2: Singurul comportament suspect a fost detectarea unei noi adrese MAC după 15 minute.Pentru a accelera căutarea erorilor, am început un fel fără propriul CNI și am folosit în schimb weave. Prin aceasta, am putut realiza jurnalele identice și exact aceeași problemă ca și cu clusterul „adevărat” kubernetes. Din păcate, nu am avut noroc cu jurnalele de depanare a țesăturilor, prin urmare am trecut la calico CNI și am schimbat podSubnet-ul la 192.168.0.0/16. Acest lucru a rezolvat problema în natură, dar aplicarea exactă a aceleiași soluții la clusterul meu kubernetes mă lasă din nou cu aceeași problemă...