添加第二个控制平面后主站上的API-Server

Question

在我当前的测试设置中，我有几个VM运行Debian-11。所有节点都有一个私有IP和第二个有线接口。在未来，节点将在不同的位置，不同的网络，并使用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
...

因此，我已经在所有节点上安装了版本1.23.5中的docker和kubeadm/kubelet/kubectl。此外，我也在所有节点上安装了一个haproxy。它作为负载均衡器，列出到localhost:443，并将请求转发到在线控制平面之一。

然后，我用kubeadm启动了集群。

vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16

在那之后，我测试了整合法兰绒或棉布。通过添加--iface=或设置自定义清单...nodeAddressAutodetectionV4.interface: 。

当我添加一个普通节点时-一切都很好。添加节点，创建豆荚，并通过定义的网络接口进行通信。

当我添加一个没有wireguard接口的控制平面时，我也可以用

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

当然，在此之前，我从vm01复制了几个文件到vm02，比如ca.*、sa.*、front-proxy-ca.*、apiserver-kubelet-client.*和etcd/ca.*。

但是，当我使用法兰绒或棉布网络以及wireguard接口时，连接命令之后会发生一些奇怪的事情。

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命令了。6443的HTTPS服务已经死了。但是，我既不理解为什么vm01上的API服务器在添加第二个API服务器时停止工作，我也无法找到一个原因，当输出讨论的是192.168.IPs，因为集群只能通过10.11.12.0/24有线网络进行通信。

Answer 1

在https://stackoverflow.com/questions/64227042/setting-up-a-kubernetes-master-on-a-different-ip中发现类似的问题后，我认为这也是解决方案。当我添加--apiserver-advertise-address=时，输出会发生变化(编号192.168..。它就会加入。我不明白的是，为什么VM01 API服务器停止工作。

无论join命令在外壳下做什么，它都需要在第二个控制平面上创建一个etcd服务，并且该服务还必须运行在同一个IP上，然后是flannel/calico网络接口。在使用主网络接口的情况下，在第二/第三控制平面上不需要此参数。