HA kubernetes cluster: Случайный сброс kubeadm на 1 главном узле, в соединении отказано при повторном присоединении к кластеру
я установил кластер kubernetes с 2 главными узлами (cp01 192.168.1.42, cp02 192.168.1.46) и 4 рабочими узлами, реализованными с haproxy и keepalived, работающими как статические модули в кластере, внутреннем кластере etcd.По каким-то глупым причинам я случайно kubeadm reset -f на cp01. Теперь я пытаюсь повторно присоединиться к кластеру с помощью команды kubeadm join, но продолжаю получать dial tcp 192.168.1.49:8443: connect: соединение отклонено, где 192.168.1.49 - это IP-адрес LoadBalancer. Пожалуйста помоги! Ниже представлены текущие конфигурации.
/etc/haproxy/haproxy.cfg на cp02
defaults
timeout connect 10s
timeout client 30s
timeout server 30s
frontend apiserver
bind *.8443
mode tcp
option tcplog
default_backend apiserver
backend apiserver
option httpchk GET /healthz
http-check expect status 200
mode tcp
option ssl-hello-chk
balance roundrobin
default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100
#server master01 192.168.1.42:6443 check ***the one i accidentally resetted
server master02 192.168.1.46:6443 check
/etc/keepalived/keepalived.conf на cp02
global_defs {
router_id LVS_DEVEL
script_user root
enable_script_security
dynamic_interfaces
}
vrrp_script check_apiserver {
script "/etc/keepalived/check_apiserver.sh"
interval 3
weight -2
fall 10
rise 2
}
vrrp_instance VI_l {
state BACKUP
interface ens192
virtual_router_id 51
priority 101
authentication {
auth_type PASS
auth_pass ***
}
virtual_ipaddress {
192.168.1.49/24
}
track_script {
check_apiserver
}
}
кластер kubeadm-config
apiVersion: v1
data:
ClusterConfiguration: |
apiServer:
extraArgs:
authorization-mode: Node,RBAC
timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta2
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: 192.168.1.49:8443
controllerManager: {}
dns:
type: CoreDNS
etcd:
local:
dataDir: /var/lib/etcd
imageRepository: k8s.gcr.io
kind: ClusterConfiguration
kubernetesVersion: v1.19.2
networking:
dnsDomain: cluster.local
podSubnet: 10.244.0.0/16
serviceSubnet: 10.96.0.0/12
scheduler: {}
ClusterStatus: |
apiEndpoints:
cp02:
advertiseAddress: 192.168.1.46
bindPort: 6443
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterStatus
...
kubectl cluster-info
Kubernetes master is running at https://192.168.1.49:8443
KubeDNS is running at https://192.168.1.49:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Подробнее
кластер был инициализируется с помощью --upload-certs на cp01.
Я осушил и удалил cp01 из кластера.
kubeadm join --token ... --discovery-token-ca-cert-hash ... --control-plane --certificate-key ...команда вернула:фаза выполнения ошибки предварительная проверка: невозможно получить kubeadm-config ConfigMap: не удалось получить карту конфигурации: получить «https://192.168.1.49:8443/api/v1/namespaces/kube-system/configmaps/kubeadm-config?timeout=10s»: наберите tcp 192.168.1.49:8443: connect: соединение отклоненоkubectl exec -n kube-system -it etcd-cp02 - etcdctl --endpoints = https: //192.168.1.46: 2379 --key = / etc / kubernetes / pki / etcd / peer.key --cert = / etc / kubernetes / pki / etcd / peer.crt --cacert = / etc / kubernetes / pki / etcd / ca.crt список участниковвернулся:..., запущен, cp02, https: / /192.168.1.46:2380, https://192.168.1.46:2379, ложьkubectl описать pod / etcd-cp02 -n kube-system:... ID контейнера: docker: // ... Изображение: k8s.gcr.io/etcd:3.4.13-0 ID изображения: docker: // ... Порт: <нет> Порт хоста: <нет> Команда: etcd --advertise-client-urls = https: //192.168.1.46: 2379 --cert-файл = / etc / kubernetes / pki / etcd / server.crt --client-cert-auth = истина --data-dir = / var / lib / etcd --initial-Advertise-peer-urls = https: //192.168.1.46: 2380 --initial-cluster = cp01 = https: //192.168.1.42: 2380, cp02 = https: //192.168.1.46: 2380 --initial-cluster-state = существующий --key-файл = / etc / kubernetes / pki / etcd / server.key --listen-client-urls = https: //127.0.0.1: 2379, https: //192.168.1.46: 2379 --listen-metrics-urls = http: //127.0.0.1: 2381 --listen-peer-urls = https: //192.168.1.46: 2380 --name = cp02 --peer-cert-file = / etc / kubernetes / pki / etcd / peer.crt --peer-client-cert-auth = истина --peer-key-file = / etc / kubernetes / pki / etcd / peer.key --peer-доверенный-ca-файл = / etc / kubernetes / pki / etcd / ca.crt --snapshot-count = 10000 --trusted-ca-file = / etc / kubernetes / pki / etcd / ca.crt ...Попытка скопировать сертификаты в
cp01: / etc / kubernetes / pkiперед запуском.kubeadm join 192.168.1.49:8443 --token ... --discovery-token-ca-cert-hash, но вернул ту же ошибку.# файл скопирован на cp01 ca.crt ca.key sa.key sa.pub фронт-прокси-ca.crt фронт-прокси-ca.key etcd / ca.crt etcd / ca.key
Устранение неполадок в сети
Возможно выполнить эхо-запрос 192.168.1.49 на cp01
nc -v 192.168.1.49 8443на cp01 вернулсяNcat: Соединение отклонено.curl -k https: //192.168.1.49: 8443 / api / v1 ...работает на cp02 и рабочих узлах (возвращает код 403, который должен быть нормальным)./etc/cni/net.d/ удален на cp01
Вручную очищены правила iptables на cp01 с помощью 'KUBE' или 'cali'.
firewalld отключен как на cp01, так и на cp02.
Я попытался подключиться к новому серверу cp03 192.168.1.48 и обнаружил тот же dial tcp 192.168.1.49: 8443: соединение: ошибка отказа в соединении.
netstat -tlnp | grep 8443на cp02 вернул:tcp 0 0.0.0.0:8443 0.0.0.0:* СЛУШАТЬ 27316 / haproxync -v 192.168.1.46 6443на cp01 и cp03 возвращает:Ncat: подключен к 192.168.1.46:6443
Любые советы / указания будут очень признательны, так как я здесь в растерянности. Я думаю, это может быть из-за сетевых правил на cp02, но я действительно не знаю, как это проверить. Спасибо!!
Понял, в чем проблема, когда ввел ip a. Понял, что ens192 на cp01 все еще содержит дополнительный IP-адрес 192.168.1.49.
Просто ip addr del 192.168.1.49/24 dev ens192 и kubeadm присоединяются... , и cp01 может успешно присоединиться к кластеру. Не могу поверить, что пропустил это...