Thời gian chờ 15 phút trong cụm HA k8s khi nút dừng

Tôi đã thiết lập một cụm k8s ít nhiều sau hướng dẫn này. Vì vậy, tôi có ba nút chính và mặt phẳng điều khiển. Tôi sử dụng haproxy làm trình cân bằng tải với cấu hình sau:

#/etc/haproxy/haproxy.cfg
#--------------------------------------------- --------------------
# Thiết lập toàn cầu
#--------------------------------------------- --------------------
toàn cầu
    nhật ký/dev/log cục bộ0 
    thông tin đăng nhập /dev/log local1
    yêu tinh

#--------------------------------------------- --------------------
# mặc định chung mà tất cả các phần nghe và phụ trợ sẽ
# sử dụng nếu không được chỉ định trong khối của họ
#--------------------------------------------- --------------------
mặc định
    chế độ http
    đăng nhập toàn cầu
    tùy chọn httplog
    tùy chọn donlognull
    tùy chọn http-server-đóng
    tùy chọn chuyển tiếp ngoại trừ 127.0.0.0/8
    gửi lại tùy chọn
    thử lại 1
    thời gian chờ yêu cầu http 10 giây
    hàng đợi hết thời gian 20 giây
    hết thời gian kết nối 5s
    máy khách hết thời gian 20 giây
    máy chủ hết thời gian 20 giây
    thời gian chờ http-keep-alive 10s
    kiểm tra thời gian chờ 10s

#--------------------------------------------- --------------------
# apiserver giao diện người dùng ủy quyền cho các nút của mặt phẳng điều khiển
#--------------------------------------------- --------------------
giao diện người dùng
    ràng buộc *:8443
    chế độ tcp
    tùy chọn tcplog
    apiserver default_backend

#--------------------------------------------- --------------------
# cân bằng luân chuyển cho apiserver
#--------------------------------------------- --------------------
apiserver phụ trợ
    tùy chọn httpchk NHẬN /healthz
    http-kiểm tra trạng thái mong đợi 200
    chế độ tcp
    tùy chọn ssl-hello-chk
    tùy chọn kiểm tra tcp
    thăng bằng vòng tròn
    máy chủ k8s1 x.x.x.15:6443 kiểm tra
    máy chủ k8s2 x.x.x.16:6443 kiểm tra
    máy chủ k8s3 x.x.x.17:6443 kiểm tra

cũng như keepalived để quản lý VIP:

! /etc/keepalived/keepalived.conf
! Tệp cấu hình cho keepalived
global_defs {
    router_id LVS_DEVEL
}
vrrp_script check_apiserver {
  tập lệnh "/etc/keepalived/check_apiserver.sh"
  quãng 3
  hết giờ 5
  mùa thu 10
  tăng 2
}

vrrp_instance VI_1 {
    trạng thái SAO LƯU
    giao diện ens18
    virtual_router_id 53
    ưu tiên 101
    xác thực {
        auth_type VƯỢT QUA
        auth_pass 123456
    }
    virtual_ipaddress {
        x.x.x.18
    }
    track_script {
        check_apiserver
    }
}

và tập lệnh check_apiserver:

#!/usr/bin/env bash

errorExit() {
    tiếng vang "*** $*" 1>&2
    thoát 1
}

curl --silent --max-time 2 --insecure https://localhost:6443/ -o /dev/null || errorExit "Lỗi NHẬN https://localhost:6443/"
nếu địa chỉ ip | grep -q ${VIP}; sau đó
    curl --silent --max-time 2 --insecure https://x.x.x.18:8443/ -o /dev/null || errorExit "Lỗi NHẬN https://x.x.x.18:8443/"
fi

kubelet, kubeadm và kubectl đều là phiên bản 1.22.2

Tôi tạo cụm bằng cách sử dụng

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

và thêm kiểu dệt bằng cách sử dụng

áp dụng kubectl -f "https://cloud.weave.works/k8s/net?k8s-version=$(phiên bản kubectl | base64 | tr -d '\n')&env.IPALLOC_RANGE=172.31.0.0/16"

Với cấu hình này, tôi có thể tạo ví dụ: một cụm EMQX. Sự cố xuất hiện bất cứ khi nào tôi dừng một nút. Mọi tập hợp trạng thái, có Pod chạy trên nút đã dừng, sẽ không phản hồi trong gần 15 phút.

Kiểm tra keepalived bằng cách sử dụng ip a s ens18 Tôi thấy VIP di chuyển gần như ngay lập tức đến một nút đang chạy. Sử dụng bảng điều khiển thống kê haproxy, nút được đánh dấu là đang hoạt động đi XUỐNG sau 2 giây và hoạt động hoặc sao lưu XUỐNG sau 4 giây nữa. Điều này dường như làm việc là tốt.

Việc sửa đổi thời gian chờ kubernetes (ví dụ: thời gian thu hồi nhóm) hoạt động, do đó, các Nhóm được đánh dấu là kết thúc sớm hơn nhưng bộ trạng thái vẫn không phản hồi trong 15 phút bất kể thời gian thu hồi.

Thiết lập mạng loại ba nút với tất cả các nút chính và mặt phẳng điều khiển không hiển thị hành vi này, đó là lý do tại sao tôi đoán đó là sự cố cấu hình k8s. Nhưng tôi đang thiếu gì?

Chỉnh sửa 1: Cụm vẫn có thể truy cập được trong thời gian đó để tôi có thể xem kubectl lấy tất cả --all-namespaces -o wide để kiểm tra trạng thái cụm. Tất cả những gì tôi thấy là các nhóm từ nút đã dừng vẫn ở trạng thái kết thúc.

Chỉnh sửa 2: Hành vi đáng ngờ duy nhất là dệt phát hiện địa chỉ MAC mới sau 15 phút.Để tăng tốc độ tìm kiếm lỗi, tôi đã bắt đầu loại mà không có CNI riêng và sử dụng kiểu dệt thay thế. Bằng cách này, tôi có thể đạt được các bản ghi giống hệt nhau và vấn đề chính xác giống như với cụm kubernetes "thực". Thật không may, tôi không gặp may mắn với nhật ký gỡ lỗi kiểu dệt, vì vậy tôi đã chuyển sang CNI calico và thay đổi podSubnet thành 192.168.0.0/16. Điều này đã giải quyết vấn đề bằng hiện vật nhưng việc áp dụng chính xác giải pháp tương tự cho cụm kubernetes của tôi lại khiến tôi gặp lại vấn đề tương tự ...