Mở rộng Kubernetes lên 2.500 nút

Một tinh chỉnh hữu ích khác là lưu trữ Kubernetes Events trong một cụm etcd riêng biệt, do đó các đột biến trong quá trình tạo Event sẽ không ảnh hưởng đến hiệu suất của các phiên bản etcd chính. Để thực hiện điều này, chúng ta chỉ cần đặt cờ  --etcd-servers-overrides thành thứ gì đó như thế này: --etcd-servers-overrides=/events#https://0.example.com:2381;­https://1.example.com:2381;­https://2.example.com:2381

Một lỗi khác sau 1.000 nút là đạt đến giới hạn lưu trữ cứng của etcd (mặc định là 2GB), khiến nó ngừng chấp nhận ghi. Điều này gây ra lỗi liên tiếp: tất cả các nút Kube của chúng tôi đều không vượt qua được kiểm tra tình trạng và  trình tự động mở rộng của chúng tôi(mở trong cửa sổ mới) quyết định do đó cần phải chấm dứt tất cả các công nhân. Chúng tôi đã tăng kích thước etcd tối đa bằng  --quota-backend-bytes cờ và trình tự động điều chỉnh hiện có kiểm tra tính hợp lý để không thực hiện hành động nếu nó chấm dứt hơn 50% cụm.

Chúng tôi đặt đồng thời kube-apiserver,  kube-controller-manager và  kube-scheduler các quy trình trên cùng một máy. Để có tính khả dụng cao, chúng tôi luôn có ít nhất 2 máy chủ chính và đặt cờ  --apiserver-count theo số lượng máy chủ API mà chúng tôi đang chạy (nếu không, quá trình giám sát Prometheus có thể bị nhầm lẫn giữa các phiên bản).

Chúng tôi sử dụng Kubernetes chủ yếu như một hệ thống lập lịch hàng loạt và dựa vào  trình tự động mở rộng của chúng tôi để tăng và giảm quy mô cụm của chúng tôi một cách động — điều này cho phép chúng tôi giảm đáng kể chi phí cho các nút nhàn rỗi, trong khi vẫn cung cấp độ trễ thấp trong khi lặp lại nhanh chóng. Chính sách mặc định của kube-scheduler là phân bổ tải đều giữa các nút, nhưng chúng tôi muốn ngược lại để các nút không sử dụng có thể bị chấm dứt và cũng để  các pod lớn(mở trong cửa sổ mới) có thể được lên lịch nhanh chóng. Vì vậy, chúng tôi đã chuyển sang chính sách sau:

Chúng tôi sử dụng  KubeDNS rộng rãi để khám phá dịch vụ, nhưng ngay sau khi triển khai chính sách lập lịch mới, nó bắt đầu gặp sự cố về độ tin cậy. Chúng tôi thấy rằng lỗi chỉ xảy ra trên một số pod nhất định của KubeDNS. Với chính sách lập lịch mới, một số máy đã chạy hơn 10 bản sao của KubeDNS, tạo điểm truy cập và chúng tôi đã vượt quá ~200QPS được phép từ mỗi máy ảo Azure để tra cứu tên miền bên ngoài.

Chúng tôi đã khắc phục điều này bằng cách thêm  quy tắc chống lại sự tương thích đến các pod KubeDNS của chúng tôi:

Dota của chúng tôi dự án bắt đầu trên Kubernetes và khi nó mở rộng, chúng tôi nhận thấy rằng các nút Kubernetes mới thường có các pod nằm trong  trạng thái Đang chờ xử lý trong một thời gian dài. Hình ảnh trò chơi có kích thước khoảng 17 GB và thường mất 30 phút để kéo một nút cụm mới, vì vậy chúng tôi hiểu tại sao vùng chứa Dota sẽ ở trạng thái Chờ trong một thời gian — nhưng điều này cũng đúng với các vùng chứa khác. Khi đào sâu hơn, chúng tôi thấy rằng  kubelet có một  --serialize-image-pulls cờ mặc định là  true, nghĩa là lệnh kéo hình ảnh Dota đã chặn tất cả các hình ảnh khác. Thay đổi thành  false yêu cầu chuyển Docker sang overlay2 thay vì AUFS. Để tăng tốc độ kéo hơn nữa, chúng tôi cũng đã chuyển gốc Docker sang SSD gắn với phiên bản, giống như chúng tôi đã làm với các máy etcd.

Ngay cả sau khi tối ưu hóa tốc độ kéo, chúng tôi vẫn thấy các pod không khởi động được với thông báo lỗi khó hiểu:  rpc error: code = 2 desc = net/http: request canceled. Nhật ký kubelet và Docker cũng chứa các thông báo cho biết việc kéo hình ảnh đã bị hủy do thiếu tiến trình. Chúng tôi đã theo dõi gốc đến các hình ảnh lớn mất quá nhiều thời gian để kéo/trích xuất hoặc những lúc chúng tôi có một danh sách dài hình ảnh cần kéo. Để giải quyết vấn đề này, chúng tôi đặt  --image-pull-progress-deadline cờ của kubelet thành 30 phút và đặt tùy chọn của daemon Docker  max-concurrent-downloads thành 10. (Tùy chọn thứ hai không tăng tốc độ trích xuất các hình ảnh lớn, nhưng cho phép hàng đợi hình ảnh kéo song song.)

Sự cố kéo Docker cuối cùng của chúng tôi là do Google Container Registry. Theo mặc định, kubelet kéo một hình ảnh đặc biệt từ  gcr.io (do  --pod-infra-container-image cờ kiểm soát) được sử dụng khi bắt đầu bất kỳ container mới nào. Nếu lần kéo đó không thành công vì bất kỳ lý do nào, chẳng hạn như vượt quá  hạn ngạch của bạn(mở trong cửa sổ mới), nút đó sẽ không thể khởi chạy bất kỳ vùng chứa nào. Vì các nút của chúng tôi phải trải qua NAT để tiếp cận  gcr.io thay vì có IP công khai của riêng chúng, nên rất có thể chúng tôi sẽ đạt đến giới hạn hạn ngạch cho mỗi IP này. Để khắc phục điều này, chúng tôi chỉ cần tải trước hình ảnh Docker đó trong hình ảnh máy cho các công nhân Kubernetes của mình bằng cách sử dụng  docker image save -o /opt/preloaded_docker_images.tar và  docker image load -i /opt/preloaded_docker_images.tar. Để cải thiện hiệu suất, chúng tôi thực hiện tương tự đối với danh sách trắng các hình ảnh nội bộ OpenAI phổ biến như hình ảnh Dota.

Khi các thí nghiệm của chúng tôi phát triển lớn hơn, chúng cũng trở thành các hệ thống phân tán ngày càng phức tạp, phụ thuộc nhiều vào mạng để vận hành. Khi chúng tôi bắt đầu chạy các thí nghiệm phân tán lần đầu, chúng tôi nhận ra ngay rằng mạng của chúng tôi không được cấu hình tốt. Trực tiếp giữa các máy, chúng tôi đạt được thông lượng 10-15Gbit/giây, nhưng các pod Kube của chúng tôi sử dụng Flannel chỉ đạt tối đa khoảng 2Gbit/giây.  Điểm chuẩn công khai của Machine Zone hiển thị các con số tương tự, nghĩa là vấn đề không chỉ là do cấu hình kém mà còn là do môi trường của chúng ta. (Ngược lại, Flannel không thêm chi phí này vào máy vật lý của chúng ta.)

Để giải quyết vấn đề này, người dùng có thể thêm hai cài đặt khác nhau để vô hiệu hóa Flannel cho pod của họ:  hostNetwork: true và  dnsPolicy: ClusterFirstWithHostNet. (Mặc dù đã đọc các  cảnh báo trong tài liệu Kubernetes trước khi thực hiện việc này.)

Mặc dù đã điều chỉnh DNS, chúng tôi vẫn thấy các vấn đề không liên tục với việc giải quyết DNS. Một ngày nọ, một kỹ sư báo cáo rằng  nc -v máy chủ Redis của họ mất hơn 30 giây để in ra rằng kết nối đã được thiết lập. Chúng tôi đã theo dõi vấn đề này đến ngăn xếp ARP của hạt nhân. Cuộc điều tra ban đầu về máy chủ của pod Redis cho thấy có điều gì đó nghiêm trọng không ổn với mạng: giao tiếp trên bất kỳ cổng nào bị treo trong nhiều giây và không thể giải quyết được tên DNS thông qua dnsmasq cục  bộ(mở trong cửa sổ mới) daemon, với dig(mở trong cửa sổ mới) chỉ in một thông báo lỗi bí ẩn:  socket.c:1915: internal_send: 127.0.0.1#53: Invalid argument.  dmesg(mở trong cửa sổ mới) log cung cấp nhiều thông tin hơn:  neighbor table overflow! điều đó có nghĩa là bộ đệm ARP đã hết dung lượng. ARP được sử dụng để ánh xạ địa chỉ mạng như địa chỉ IPv4 thành địa chỉ vật lý như địa chỉ MAC. May mắn thay, điều này dễ khắc phục bằng cách thiết lập một vài tùy chọn trong  /etc/sysctl.conf:

Cài đặt này thường được điều chỉnh trong các cụm HPC và đặc biệt quan trọng trong các cụm Kubernetes vì ​​mỗi pod có địa chỉ IP riêng, chiếm dung lượng trong bộ đệm ARP.

Các cụm Kubernetes của chúng tôi đã không có sự cố trong khoảng 3 tháng nay và chúng tôi đang có kế hoạch mở rộng thành các cụm lớn hơn vào năm 2018. Chúng tôi vừa nâng cấp lên phiên bản 1.8.4 và rất vui mừng khi thấy rằng phiên bản này hiện chính thức hỗ trợ 5.000. Nếu bạn quan tâm đến việc xây dựng các cụm tính toán quy mô lớn.