Tôi đang cố gắng cài đặt hoàn toàn Kubernetes 1.23.x trên một cụm gồm bốn Raspberry Pi, mỗi chiếc chạy phiên bản x64 của Raspberry Pi OS, tuy nhiên, tôi đang gặp sự cố lớn ngay khi thử và chạy khởi tạo kubeadm trên nút chính (thậm chí trước khi cố gắng để các nút khác tham gia). Cụ thể: chỉ năm phút sau khi gọi khởi tạo kubeadm trên nút chính, cụm ngừng hoạt động. Trên thực tế, nó không bao giờ thực sự hoạt động ngay từ đầu. Lúc đầu, máy chủ phản hồi nói rằng nút đó là Chưa sẵn sàng, nhưng sau 5 phút, nó ngừng phản hồi hoàn toàn.
Vì vậy, đây là những gì tôi đã làm và những gì tôi thấy: Tôi đã cài đặt containerd và kubeadm. Sau đó, tôi chạy lệnh sau trên nút chính để thử và khởi động Kubernetes:
Sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
--token-ttl=0 --apiserver-advertise-address=192.168.1.194
Sau khi chạy lệnh đó và sau đó sao chép tệp /etc/kubernetes/admin.conf sang ~/.kube/config, tôi có thể chạy lệnh sau:
$ kubectl nhận các nút
TÊN TÌNH TRẠNG VAI TRÒ TUỔI PHIÊN BẢN
k8s-master-1 NotReady control-plane,master 3m36s v1.23.4
Và nó sẽ tiếp tục hiển thị trạng thái NotReady trong khoảng 5 phút, sau thời điểm đó, lệnh tương tự mang lại một kết quả rất khác:
$ kubectl nhận các nút
Kết nối với máy chủ 192.168.1.194:6443 bị từ chối - bạn đã chỉ định đúng máy chủ hoặc cổng chưa?
Tôi không chắc tại sao điều này lại xảy ra, nhưng nó rất nhất quán. Tôi đã cố gắng một vài lần bây giờ để thiết lập lại kubeadm và sau đó khởi tạo kubeadm một lần nữa và thời gian chờ kết nối luôn xảy ra ở mốc 5 phút. Vì vậy, lần cuối cùng tôi cố gắng làm điều này, tôi đã quyết định theo dõi tất cả các tệp nhật ký bên dưới /var/log/container/. Sau mốc 5 phút, nó liên tục ghi lại một số biến thể của lỗi kết nối thành 127.0.0.1:2379. Ví dụ:
2022-03-09T19:30:29.307156643-06:00 stderr F W0310 01:30:29.306871 1 clientconn.go:1331] [core] grpc: addrConn.createTransport không kết nối được với {127.0.0.1:2379 127.0.0.1 0 }. Err: lỗi kết nối: desc = "vận chuyển: Lỗi trong khi quay số quay số tcp 127.0.0.1:2379: kết nối: kết nối bị từ chối". Đang kết nối lại...
Từ Google, có vẻ như etcd đang chạy trên cổng đó, nhưng sau 5 phút, một loạt dịch vụ (bao gồm cả etcd) bắt đầu ngừng hoạt động. Tôi đã tải lên các bản ghi đầy đủ từ thời gian khởi tạo kubeadm chạy, cho đến trước mốc 5 phút đáng sợ, như một Gist.
Tôi cũng đã kiểm tra xem tất cả các cổng có đang mở không. (Đúng vậy.) Trong năm phút đầu tiên đó, tôi có thể telnet tới cổng cục bộ 2379. Tại sao Kubernetes không khởi động trên Pi của tôi? Tôi đang thiếu gì?
CẬP NHẬT: Theo yêu cầu, tôi có thể cung cấp thêm một vài chi tiết. Tôi đã thấy một bài đăng khuyến nghị đặt giá trị của --apiserver-advertise-address đến 0.0.0.0 thay vì IP trực tiếp, vì vậy tôi đã thử điều đó nhưng dường như không có gì khác biệt. tôi đã thử chạy trạng thái systemctl kubelet cho biết dịch vụ kubelet đang "hoạt động" trong khoảng thời gian 5 phút đầu tiên đó.
tôi cũng đã chạy kubectl mô tả nút k8s-master-1, hiển thị bốn sự kiện trong chuỗi này:
- KubeletCó ĐủBộ Nhớ
- KubeletKhông CóĐĩaÁp Lực
- KubeletHasSufficientPID
- KubeletChưa Sẵn Sàng
Sự kiện cuối cùng đó đi kèm với thông báo sau: "mạng thời gian chạy vùng chứa chưa sẵn sàng: NetworkReady=false lý do: Thông báo NetworkPluginNotReady: Plugin mạng trả về lỗi: plugin cni chưa được khởi tạo." Vì vậy, điều đó đã khiến tôi suy nghĩ. Tôi đã đợi Node xuất hiện ở trạng thái Sẵn sàng trước khi cài đặt Flannel (còn gọi là plugin CNI), nhưng lần này tôi quyết định thử cài đặt Flannel trong khoảng thời gian 5 phút đầu tiên đó, sử dụng lệnh này:
áp dụng kubectl -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
Và trước sự ngạc nhiên lớn của tôi, điều đó đã hiệu quả! Vâng, loại. Nút chính cuối cùng đã bắt đầu báo cáo trạng thái "Sẵn sàng".Và tôi nhận thấy rằng tất cả các nhóm của tôi đều có ngoại lệ đáng chú ý là các nhóm coredns. Tuy nhiên, sau một thời gian ngắn, nhóm kube-proxy (trong không gian tên hệ thống kube) chết và bị kẹt trong CrashLoopBackoff, và sau đó, nhóm kube-controller-manager và kube-scheduler cũng nhập CrashLoopBackoff tương tự. Sau đó, lần này, sau khoảng 15 phút, toàn bộ cụm lại chết như trước (có nghĩa là tôi nhận được thông báo 'kết nối với máy chủ bị từ chối' tương tự). Vì vậy, tôi cảm thấy như mình đã tiến gần hơn một chút, nhưng vẫn còn một chặng đường dài để việc này hoạt động.
CẬP NHẬT THỨ HAI: Một vài điều: có vẻ như khi tôi cài đặt plugin CNI flannel, coredns không được bao gồm hoặc không hoạt động. Nhưng khi tôi cài đặt CNI dệt hoạt động thì ít nhất nó cũng cố gắng khởi động các lõi, mặc dù không may là các nhóm đó bị kẹt trong ContainerCreating và không bao giờ thực sự kích hoạt. Vì vậy, theo yêu cầu, tôi đang cung cấp một số nhật ký bổ sung. Chúng đủ dài để đảm bảo tải chúng lên một cách riêng biệt, vì vậy đây là liên kết đến một Gist chứa bốn bản ghi:
- Đang chạy
kubectl -n kube-system log pod/coredns-...
- Đang chạy
kubectl -n kube-system log pod/kube-controller-manager-k8s-master-1
- Đang chạy
kubectl -n kube-system log pod/kube-proxy-...
- Đang chạy
kubectl mô tả nút k8s-master-1
Lưu ý rằng trước khi mọi thứ chết, nhóm kube-controller-manager-... khởi động nhưng sẽ sớm thấy chính nó trong CrashLoopBackoff. Trong khi các nhóm coredns không bao giờ khởi động thành công.
