Я настроил кластер kubernetes с 2 главными узлами (cp01 192.168.1.42, cp02 192.168.1.46) и 4 рабочими узлами, реализованными с помощью haproxy и keepalived, работающими как статические модули в кластере, внутренний кластер etcd.По каким-то глупым причинам я случайно сбросил kubeadm -f на cp01. Теперь я пытаюсь повторно присоединиться к кластеру с помощью команды kubeadm join, но я продолжаю получать набор tcp 192.168.1.49:8443: подключение: отказ в подключении, где 192.168.1.49 — это IP-адрес LoadBalancer. Пожалуйста помоги! Ниже приведены текущие конфигурации.
/etc/haproxy/haproxy.cfg на cp02
значения по умолчанию
тайм-аут соединения 10 сек.
тайм-аут клиента 30 сек.
тайм-аут сервера 30 секунд
внешний интерфейс
привязать *.8443
режим TCP
опция tcplog
default_backend
серверный сервер
опция httpchk GET /healthz
http-check ожидает статус 200
режим TCP
опция ssl-hello-chk
круговой баланс
сервер по умолчанию между 10 с downinter 5 с подъем 2 падение 2 медленный старт 60 с maxconn 250 maxqueue 256 вес 100
# server master01 192.168.1.42:6443 проверьте *** тот, который я случайно сбросил
сервер master02 192.168.1.46:6443 проверить
/etc/keepalived/keepalived.conf на cp02
global_defs {
router_id LVS_DEVEL
root_user_script
enable_script_security
динамические_интерфейсы
}
vrrp_script check_apserver {
скрипт "/etc/keepalived/check_apiserver.sh"
интервал 3
вес -2
осень 10
подъем 2
}
vrrp_instance VI_l {
резервная копия состояния
интерфейс ens192
виртуальный_роутер_id 51
приоритет 101
аутентификация {
auth_type ПАРОЛЬ
auth_pass ***
}
виртуальный_ipaddress {
192.168.1.49/24
}
track_script {
check_apserver
}
}
кластер kubeadm-config
апиВерсия: v1
данные:
Конфигурация кластера: |
API-сервер:
дополнительные аргументы:
режим авторизации: Node,RBAC
таймаутфорконтролплане: 4м0с
Версия API: kubeadm.k8s.io/v1beta2
сертификатыКаталог: /etc/kubernetes/pki
имя_кластера: kubernetes
controlPlaneEndpoint: 192.168.1.49:8443
диспетчер диспетчера: {}
DNS:
тип: CoreDNS
и т. д.:
местный:
каталог данных: /var/lib/etcd
imageRepository: k8s.gcr.io
тип: конфигурация кластера
kubernetesВерсия: v1.19.2
сети:
DNS-домен: cluster.local
подсеть: 10.244.0.0/16
сервисная подсеть: 10.96.0.0/12
планировщик: {}
Состояние кластера: |
конечные точки API:
cp02:
рекламаАдрес: 192.168.1.46
порт привязки: 6443
Версия API: kubeadm.k8s.io/v1beta2
тип: ClusterStatus
...
информация о кластере kubectl
Мастер Kubernetes работает по адресу https://192.168.1.49:8443.
KubeDNS работает по адресу 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: не удалось получить карту конфигурации: Get "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
Идентификатор изображения: докер://...
Порт: <нет>
Хост-порт: <нет>
Команда:
и т. д.
--advertise-client-urls=https://192.168.1.46:2379
--cert-file=/etc/kubernetes/pki/etcd/server.crt
--client-cert-auth=true
--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-file=/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=true
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
--snapshot-count=10000
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
...
Пробовал копировать сертификаты на cp01:/etc/кубернетес/пки перед бегом
kubeadm join 192.168.1.49:8443 --token ... --discovery-token-ca-cert-hash но вернул ту же ошибку.
# файлы скопированы на cp01
ca.crt
ca.key
sa.key
са.паб
передний прокси-ca.crt
передний прокси-ca.key
etcd/ca.crt
etcd/ca.key
Устранение неполадок сети
Можно пропинговать 192.168.1.49 на cp01
нк -в 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 и столкнулся с тем же набором tcp 192.168.1.49:8443: соединение: ошибка отказа в соединении.
netstat -tlnp | группа 8443 на cp02 возвращено:
TCP 0 0.0.0.0:8443 0.0.0.0:* ПРОСЛУШИВАТЬ 27316/haproxy
нк -в 192.168.1.46 6443 на cp01 и cp03 возвращает:
Ncat: подключен к 192.168.1.46:6443
Любые советы / рекомендации будут очень признательны, так как я здесь в недоумении. Я думаю, что это может быть связано с сетевыми правилами на cp02, но я действительно не знаю, как это проверить. Спасибо!!
