В моей текущей тестовой установке есть несколько виртуальных машин с Debian-11. Все узлы имеют частный IP-адрес и второй интерфейс wireguard. В будущем узлы будут находиться в разных местах с другой сетью, и Wireguard будет использоваться для «наложения» всех различных сетевых сред. Я хочу установить Kubernetes на все узлы.
общедоступный IP-адрес узла wireguard ip
вм1 192.168.10.10 10.11.12.10
вм2 192.168.10.11 10.11.12.11
вм3 192.168.10.12 10.11.12.12
...
Итак, я установил docker и kubeadm/kubelet/kubectl версии 1.23.5 на все узлы. Также я установил haproxy на все узлы. Он работает как балансировщик нагрузки, перечисляя localhost: 443 и перенаправляя запросы на одну из онлайн-плоскостей управления.
Затем я запустил кластер с помощью kubeadm.
vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
После этого я попробовал интегрировать либо фланель, либо бязь. Либо добавив --iface=<wireguard-интерфейс> или установив пользовательский манифест ...nodeAddressAutodetectionV4.interface: <wireguard-interface>.
Когда добавляю обычный узел - все нормально. Добавляется узел, создаются модули, и связь осуществляется через определенный сетевой интерфейс.
Когда я добавляю плоскость управления без интерфейса wireguard, я также могу добавлять другие плоскости управления с
vm2> kubeadm join 127.0.0.1:443 --token ... --discovery-token-ca-cert-hash sha256:... --control-plane
Конечно перед этим я скопировал несколько файлов с vm01 на vm02 с /etc/кубернетес/пки как ок.*, сб.*, передний прокси-ca.*, apiserver-kubelet-клиент.* и т. д/ок.*.
Но когда я использую сеть фланель или бязь вместе с интерфейсом wireguard, после команды соединения происходит что-то странное.
root@vm02:~# kubeadm join 127.0.0.1:443 --token nwevkx.tzm37tb4qx3wg2jz --discovery-token-ca-cert-hash sha256:9a97a5846ad823647ccb1892971c5f0004043d88f62328d056a71ce8
[preflight] Запуск проверки перед полетом
[предварительная проверка] Чтение конфигурации из кластера...
[preflight] FYI: вы можете посмотреть этот файл конфигурации с помощью «kubectl -n kube-system get cm kubeadm-config -o yaml»
[preflight] Выполнение предварительных проверок перед инициализацией нового экземпляра плоскости управления
[preflight] Извлечение изображений, необходимых для настройки кластера Kubernetes
[предварительная проверка] Это может занять минуту или две, в зависимости от скорости вашего интернет-соединения.
[preflight] Вы также можете выполнить это действие заранее, используя «вытягивание образов конфигурации kubeadm»
[certs] Использование папки certificateDir «/etc/kubernetes/pki»
[certs] Генерация сертификата и ключа «front-proxy-client»
[certs] Генерация сертификата и ключа «etcd/server»
[certs] сертификат etcd/server, обслуживающий DNS-имена [localhost mimas] и IP-адреса [192.168.10.11 127.0.0.1 ::1]
[certs] Генерация сертификата и ключа «etcd/peer»
[certs] сертификат etcd/peer service подписан для DNS-имен [localhost mimas] и IP-адресов [192.168.10.11 127.0.0.1 ::1]
[certs] Генерация сертификата и ключа «etcd/healthcheck-client»
[certs] Создание сертификата и ключа «apiserver-etcd-client»
[certs] Генерация сертификата и ключа "apiserver"
[certs] apiserver, обслуживающий сертификат, подписан для DNS-имен [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local mimas] и IP-адресов [10.96.0.1 192.168.10.11 127.0.0.1]
[certs] Использование существующего сертификата и ключа «apiserver-kubelet-client»
[certs] Действительные сертификаты и ключи теперь существуют в «/etc/kubernetes/pki»
[сертификаты] Использование существующего ключа «sa»
[kubeconfig] Создание файлов kubeconfig
[kubeconfig] Использование папки kubeconfig «/etc/kubernetes»
[конечная точка] ПРЕДУПРЕЖДЕНИЕ: порт, указанный в controlPlaneEndpoint, переопределяет bindPort в адресе плоскости управления.
[kubeconfig] Запись файла kubeconfig «admin.conf»
[конечная точка] ПРЕДУПРЕЖДЕНИЕ: порт, указанный в controlPlaneEndpoint, переопределяет bindPort в адресе плоскости управления.
[kubeconfig] Запись файла kubeconfig «controller-manager.conf»
[конечная точка] ПРЕДУПРЕЖДЕНИЕ: порт, указанный в controlPlaneEndpoint, переопределяет bindPort в адресе плоскости управления.
[kubeconfig] Запись файла kubeconfig «scheduler.conf»
[control-plane] Использование папки манифеста «/etc/kubernetes/manifests»
[control-plane] Создание статического манифеста пода для «kube-apiserver»
[control-plane] Создание статического манифеста пода для «kube-controller-manager»
[control-plane] Создание статического манифеста Pod для «kube-scheduler»
[check-etcd] Проверка работоспособности кластера etcd
[kubelet-start] Запись конфигурации kubelet в файл «/var/lib/kubelet/config.yaml»
[kubelet-start] Запись файла среды kubelet с флагами в файл «/var/lib/kubelet/kubeadm-flags.env»
[kubelet-start] Запуск kubelet
[kubelet-start] Ожидание, пока kubelet выполнит загрузку TLS...
[etcd] Объявлено о присоединении нового члена etcd к существующему кластеру etcd
[etcd] Создание статического манифеста пода для «etcd»
[etcd] Ожидание присоединения нового члена etcd к кластеру. Это может занять до 40 секунд
[kubelet-check] Исходный тайм-аут в 40 секунд пройден.
фаза выполнения ошибки control-plane-join/etcd: ошибка при создании файла манифеста локального статического модуля etcd: тайм-аут ожидания доступности кластера etcd
Чтобы увидеть трассировку стека этой ошибки, выполните с параметром --v=5 или выше.
И после этого таймаута даже на vm01 сервер API перестает работать, я больше не могу запускать команды kubeadm или kubectl. Служба HTTPS на 6443 не работает. Но я не понимаю, почему API-сервер на vm01 перестает работать при добавлении второго API-сервера, и не могу найти причину, когда вывод говорит об IP-адресах 192.168...., потому что кластер должен общаться только через 10.11.12.0 /24 сеть wireguard.
