현재 테스트 설정에는 Debian-11을 실행하는 여러 VM이 있습니다. 모든 노드에는 개인 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
...
그래서 모든 노드에 버전 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=<wireguard-interface>설정하면 됩니다 ...nodeAddressAutodetectionV4.interface: <wireguard-interface>.
일반 노드를 추가하면 모든 것이 정상입니다. 노드가 추가되고, 포드가 생성되며, 정의된 네트워크 인터페이스를 통해 통신이 수행됩니다.
Wireguard 인터페이스 없이 제어 평면을 추가할 때 다음을 사용하여 다른 제어 평면을 추가할 수도 있습니다.
vm2> kubeadm join 127.0.0.1:443 --token ... --discovery-token-ca-cert-hash sha256:... --control-plane
물론 그 전에는 , , 및 와 /etc/kubernetes/pki같은 vm01에서 vm02로 여러 파일을 복사했습니다 .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 명령을 실행할 수 없습니다. 6443의 HTTPS 서비스가 종료되었습니다. 그러나 두 번째 API 서버를 추가할 때 vm01의 API 서버가 작동을 멈추는 이유를 이해하지 못하며 출력이 192.168.... IP에 대해 이야기하는 이유를 찾을 수도 없습니다. 클러스터는 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 없음) 결합됩니다. 내가 이해하지 못하는 것은 VM01 API 서버가 작동을 멈추는 이유입니다.
Join 명령이 내부적으로 수행하는 작업이 무엇이든 두 번째 컨트롤 플레인에서 etcd 서비스를 생성해야 하며 해당 서비스도 동일한 IP와 flannel/calico 네트워크 인터페이스에서 실행되어야 합니다. 기본 네트워크 인터페이스를 사용하는 경우 두 번째/세 번째 제어 평면에서는 이 매개변수가 필요하지 않습니다.