Trong thiết lập thử nghiệm hiện tại của tôi, tôi có một số máy ảo chạy Debian-11. Tất cả các nút đều có IP riêng và giao diện bảo vệ dây thứ hai. Trong tương lai, các nút sẽ ở các vị trí khác nhau với mạng khác nhau và Wireguard được sử dụng để "che phủ" tất cả các môi trường mạng khác nhau. Tôi muốn cài đặt Kubernetes trên tất cả các nút.
nút ip công khai 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
...
Vì vậy, tôi đã cài đặt docker và kubeadm/kubelet/kubectl trong phiên bản 1.23.5 trên tất cả các nút. Ngoài ra, tôi cũng đã cài đặt một haproxy trên tất cả các nút. Nó hoạt động như một bộ cân bằng tải bằng cách liệt kê tới localhost:443 và chuyển tiếp các yêu cầu tới một trong các mặt phẳng điều khiển trực tuyến.
Sau đó, tôi bắt đầu cụm với kubeadm
vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
Sau đó, tôi đã thử nghiệm để tích hợp flannel hoặc calico. Hoặc bằng cách thêm --iface=<giao diện bảo vệ dây> hoặc bằng cách đặt bảng kê khai tùy chỉnh ...nodeAddressAutodetectionV4.interface: <wireguard-interface>.
Khi tôi thêm một nút bình thường - mọi thứ đều ổn. Nút được thêm vào, nhóm được tạo và giao tiếp được thực hiện thông qua giao diện mạng đã xác định.
Khi tôi thêm một mặt phẳng điều khiển mà không có giao diện wireguard, tôi cũng có thể thêm các mặt phẳng điều khiển khác với
vm2> kubeadm tham gia 127.0.0.1:443 --token ... --Discovery-token-ca-cert-hash sha256:... --control-plane
Tất nhiên trước đó mình đã copy vài file từ vm01 sang vm02 từ /etc/kubernetes/pki giống như ca.*, sa.*, front-proxy-ca.*, apiserver-kubelet-client.* và vvd/ca.*.
Nhưng khi tôi sử dụng mạng flannel hoặc calico cùng với giao diện bảo vệ dây, có điều gì đó kỳ lạ xảy ra sau lệnh nối.
root@vm02:~# kubeadm tham gia 127.0.0.1:443 --token nwevkx.tzm37tb4qx3wg2jz --Discovery-token-ca-cert-hash sha256:9a97a5846ad823647ccb1892971c5f0004043d88f62328d051a31adce8b6 --controlplane
[preflight] Chạy kiểm tra trước chuyến bay
[preflight] Đang đọc cấu hình từ cụm...
[preflight] FYI: Bạn có thể xem tệp cấu hình này với 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Chạy kiểm tra trước chuyến bay trước khi khởi tạo phiên bản mặt phẳng điều khiển mới
[preflight] Kéo hình ảnh cần thiết để thiết lập cụm Kubernetes
[preflight] Quá trình này có thể mất một hoặc hai phút, tùy thuộc vào tốc độ kết nối internet của bạn
[preflight] Bạn cũng có thể thực hiện hành động này trước bằng cách sử dụng 'kéo hình ảnh cấu hình kubeadm'
[certs] Sử dụng thư mục certificateDir "/etc/kubernetes/pki"
[certs] Đang tạo khóa và chứng chỉ "front-proxy-client"
[certs] Đang tạo khóa và chứng chỉ "etcd/server"
[certs] etcd/server server cert được ký cho tên DNS [localhost mimas] và IP [192.168.10.11 127.0.0.1 ::1]
[certs] Đang tạo khóa và chứng chỉ "etcd/peer"
[certs] chứng chỉ phân phát etcd/peer được ký cho tên DNS [localhost mimas] và IP [192.168.10.11 127.0.0.1 ::1]
[certs] Tạo chứng chỉ và khóa "etcd/healthcheck-client"
[certs] Tạo chứng chỉ và khóa "apiserver-etcd-client"
[certs] Đang tạo khóa và chứng chỉ "apiserver"
[certs] chứng chỉ cung cấp apiserver được ký cho tên DNS [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local mimas] và IP [10.96.0.1 192.168.10.11 127.0.0.1]
[certs] Sử dụng khóa và chứng chỉ "apiserver-kubelet-client" hiện có
[certs] Chứng chỉ và khóa hợp lệ hiện tồn tại trong "/etc/kubernetes/pki"
[certs] Sử dụng khóa "sa" hiện có
[kubeconfig] Tạo tập tin kubeconfig
[kubeconfig] Sử dụng thư mục kubeconfig "/etc/kubernetes"
[điểm cuối] CẢNH BÁO: cổng được chỉ định trong controlPlaneEndpoint ghi đè bindPort trong địa chỉ mặt phẳng điều khiển
[kubeconfig] Viết tập tin kubeconfig "admin.conf"
[điểm cuối] CẢNH BÁO: cổng được chỉ định trong controlPlaneEndpoint ghi đè bindPort trong địa chỉ mặt phẳng điều khiển
[kubeconfig] Viết tệp kubeconfig "controller-manager.conf"
[điểm cuối] CẢNH BÁO: cổng được chỉ định trong controlPlaneEndpoint ghi đè bindPort trong địa chỉ mặt phẳng điều khiển
[kubeconfig] Viết tệp kubeconfig "scheduler.conf"
[mặt phẳng điều khiển] Sử dụng thư mục kê khai "/etc/kubernetes/manifests"
[control-plane] Tạo bảng kê khai Pod tĩnh cho "kube-apiserver"
[control-plane] Tạo bảng kê khai Pod tĩnh cho "kube-controller-manager"
[control-plane] Tạo bảng kê khai Pod tĩnh cho "kube-scheduler"
[check-etcd] Kiểm tra xem cụm etcd có khỏe không
[kubelet-start] Viết cấu hình kubelet vào tệp "/var/lib/kubelet/config.yaml"
[kubelet-start] Viết tệp môi trường kubelet có cờ vào tệp "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Bắt đầu kubelet
[kubelet-start] Đang đợi kubelet thực hiện TLS Bootstrap...
[etcd] Đã công bố thành viên etcd mới tham gia vào cụm etcd hiện có
[etcd] Tạo tệp kê khai Pod tĩnh cho "etcd"
[etcd] Đang chờ thành viên etcd mới tham gia cụm. Quá trình này có thể mất tới 40 giây
[kubelet-check] Thời gian chờ ban đầu là 40 giây đã qua.
lỗi thực thi giai đoạn kiểm soát mặt phẳng-tham gia/etcd: lỗi tạo tệp kê khai nhóm tĩnh etcd cục bộ: hết thời gian chờ cụm etcd khả dụng
Để xem dấu vết ngăn xếp của lỗi này, hãy thực thi --v=5 hoặc cao hơn
Và sau thời gian chờ đó, ngay cả trên vm01, máy chủ API ngừng hoạt động, tôi không thể chạy bất kỳ lệnh kubeadm hoặc kubectl nào nữa. Dịch vụ HTTPS trên 6443 đã chết. Nhưng tôi cũng không hiểu tại sao máy chủ API trên vm01 ngừng hoạt động khi thêm máy chủ API thứ hai và tôi cũng không thể tìm ra lý do, khi đầu ra đang nói về các IP 192.168...., vì cụm chỉ nên giao tiếp qua 10.11.12.0 /24 mạng bảo vệ dây.
