API-сервер на главном компьютере останавливается после добавления второй плоскости управления

API-сервер на главном компьютере останавливается после добавления второй плоскости управления

В моей текущей тестовой настройке есть несколько виртуальных машин под управлением Debian-11. Все узлы имеют частный IP и второй интерфейс Wireguard. В будущем узлы будут находиться в разных местах с разными сетями, и Wireguard будет использоваться для «наложения» всех различных сетевых сред. Я хочу установить Kubernetes на все узлы.

node   public ip        wireguard ip
vm1    192.168.10.10    10.11.12.10
vm2    192.168.10.11    10.11.12.11
vm3    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-interface>либо устанавливая пользовательский манифест ...nodeAddressAutodetectionV4.interface: <wireguard-interface>.

Когда я добавляю обычный узел - все нормально. Узел добавляется, pod'ы создаются и связь осуществляется через определенный сетевой интерфейс.

Когда я добавляю плоскость управления без интерфейса Wireguard, я также могу добавлять различные плоскости управления с

vm2> kubeadm join 127.0.0.1:443 --token ... --discovery-token-ca-cert-hash sha256:...  --control-plane

Конечно, перед этим я скопировал несколько файлов с vm01 на vm02, /etc/kubernetes/pkiнапример ca.*, sa.*, front-proxy-ca.*, , apiserver-kubelet-client.*и etcd/ca.*.

Но когда я использую сеть Flannel или Calico вместе с интерфейсом Wireguard, после команды join происходит что-то странное.

root@vm02:~# kubeadm join 127.0.0.1:443 --token nwevkx.tzm37tb4qx3wg2jz --discovery-token-ca-cert-hash sha256:9a97a5846ad823647ccb1892971c5f0004043d88f62328d051a31ce8b697ad4a --control-plane
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost mimas] and IPs [192.168.10.11 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost mimas] and IPs [192.168.10.11 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local mimas] and IPs [10.96.0.1 192.168.10.11 127.0.0.1]
[certs] Using the existing "apiserver-kubelet-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Checking that the etcd cluster is healthy
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
[etcd] Announced new etcd member joining to the existing etcd cluster
[etcd] Creating static Pod manifest for "etcd"
[etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
[kubelet-check] Initial timeout of 40s passed.
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: timeout waiting for etcd cluster to be available
To see the stack trace of this error execute with --v=5 or higher

И после этого таймаута даже на vm01 сервер API перестает работать, я больше не могу запустить команды kubeadm или kubectl. Служба HTTPS на 6443 мертва. Но я не понимаю, почему сервер API на vm01 перестает работать при добавлении второго сервера API, и не могу найти причину, когда вывод говорит об IP-адресах 192.168...., потому что кластер должен взаимодействовать только через сеть Wireguard 10.11.12.0/24.

решение1

После обнаружения подобной проблемы вhttps://stackoverflow.com/questions/64227042/setting-up-a-kubernetes-master-on-a-different-ipЯ думаю, это также решение здесь. Когда я добавляю --apiserver-advertise-address=<this-wireguard-ip>, вывод меняется (нет 192.168.. IP) и он присоединяется. Чего я не понимаю, почему сервер API VM01 перестает работать.

Что бы команда join ни делала под капотом, ей необходимо создать службу etcd на второй плоскости управления, и эта служба также должна работать на том же IP, что и сетевой интерфейс flannel/calico. В случае использования основного сетевого интерфейса этот параметр не нужен на второй/третьей плоскости управления.

Связанный контент