Cô gái trên một chiếc xe tay ga. Hình minh họa , Logo Nomad từ
Kubernetes là con khỉ đột nặng 300 pound của dàn nhạc container. Nó hoạt động trong một số hệ thống container lớn nhất thế giới nhưng đắt tiền.
Đặc biệt tốn kém đối với các nhóm nhỏ hơn, đòi hỏi nhiều thời gian hỗ trợ và đường cong học tập dốc. Đây là quá nhiều chi phí cho nhóm bốn người của chúng tôi. Vì vậy, chúng tôi bắt đầu tìm kiếm các lựa chọn thay thế - và yêu thích .
Bạn muốn gì
Nhóm của chúng tôi hỗ trợ một số dịch vụ phân tích và giám sát hiệu suất phổ biến: điểm cuối API cho các số liệu được viết bằng Go, xuất Prometheus, trình phân tích cú pháp nhật ký như Logstash và , cũng như các cơ sở dữ liệu như InfluxDB hoặc Elaticsearch. Mỗi dịch vụ này chạy trong vùng chứa riêng của nó. Chúng ta cần một hệ thống đơn giản để duy trì hoạt động của tất cả.
Chúng tôi bắt đầu với danh sách các yêu cầu đối với việc điều phối vùng chứa:
- Chạy một bộ dịch vụ trên nhiều máy.
- Tổng quan về các dịch vụ đang chạy
- Liên kết giữa các dịch vụ.
- Tự động khởi động lại nếu dịch vụ ngừng hoạt động.
- Bảo trì cơ sở hạ tầng bởi một nhóm nhỏ.
Ngoài ra, những điều sau đây sẽ tốt nhưng không bắt buộc phải bổ sung:
- Gắn thẻ máy dựa trên khả năng của chúng (ví dụ: gắn thẻ máy có đĩa nhanh cho các dịch vụ I/O nặng).
- Khả năng chạy các dịch vụ độc lập với bộ điều phối (ví dụ: trong quá trình phát triển).
- Nơi chung để chia sẻ cấu hình và bí mật.
- Điểm cuối cho số liệu và nhật ký.
Tại sao Kubernetes không phù hợp với chúng tôi
Khi tạo nguyên mẫu với Kubernetes, chúng tôi nhận thấy rằng chúng tôi đang bổ sung thêm các lớp logic ngày càng phức tạp mà chúng tôi phụ thuộc rất nhiều vào.
Ví dụ: Kubernetes hỗ trợ các cấu hình dịch vụ tích hợp thông qua . Bạn có thể nhanh chóng bị nhầm lẫn, đặc biệt là khi hợp nhất nhiều tệp cấu hình hoặc thêm các dịch vụ bổ sung vào nhóm. Kubernetes (hoặc trong trường hợp này) cho phép bạn triển khai linh hoạt các cấu hình bên ngoài để phân tách các mối quan tâm. Nhưng điều này dẫn đến sự kết nối chặt chẽ, ẩn giấu giữa dự án của bạn và Kubernetes. Tuy nhiên, Helm và ConfigMaps là các tùy chọn bổ sung nên bạn không cần phải sử dụng chúng. Bạn chỉ cần sao chép cấu hình vào hình ảnh Docker. Tuy nhiên, bạn sẽ rất muốn đi theo con đường này và xây dựng những thứ trừu tượng không cần thiết mà sau này bạn có thể hối hận.
Ngoài ra, hệ sinh thái Kubernetes đang phát triển nhanh chóng. Phải mất rất nhiều thời gian và năng lượng để cập nhật các phương pháp hay nhất và các công cụ mới nhất. Kubectl, minikube, kubeadm, helm, Tiller, kops, oc - danh sách này vẫn tiếp tục dài ra. Không phải tất cả những công cụ này đều cần thiết khi bạn mới bắt đầu, nhưng bạn không biết mình sẽ cần những gì, vì vậy bạn cần phải biết mọi thứ. Bởi vì điều này, đường cong học tập khá dốc.
Khi nào nên sử dụng Kubernetes
Trong công ty của chúng tôi, nhiều người sử dụng Kubernetes và khá hài lòng với nó. Những phiên bản này được quản lý bởi Google hoặc Amazon, những đơn vị có đủ nguồn lực để hỗ trợ chúng.
Kubernetes đi kèm với , giúp việc điều phối vùng chứa trên quy mô lớn dễ quản lý hơn:
- Chi tiết .
- thêm logic vào cụm. Đây chỉ đơn giản là những chương trình giao tiếp với Kubernetes API.
- ! Kubernetes có thể mở rộng quy mô dịch vụ theo yêu cầu bằng cách sử dụng số liệu dịch vụ mà không cần can thiệp thủ công.
Câu hỏi đặt ra là liệu bạn có thực sự cần tất cả những tính năng này hay không. Bạn không thể chỉ dựa vào sự trừu tượng; .
Nhóm của chúng tôi cung cấp hầu hết các dịch vụ từ xa (do kết nối chặt chẽ với cơ sở hạ tầng chính), vì vậy chúng tôi không muốn phát triển cụm Kubernetes của riêng mình. Chúng tôi chỉ muốn cung cấp dịch vụ.
Không bao gồm pin
Nomad là 20% dàn nhạc cung cấp 80% những gì cần thiết. Tất cả những gì nó làm là quản lý việc triển khai. Nomad đảm nhiệm việc triển khai, khởi động lại vùng chứa trong trường hợp có lỗi... và thế là xong.
Toàn bộ mục đích của Nomad là những gì nó làm tối thiểu: không có quản lý quyền chi tiết hoặc , cái này được thiết kế đặc biệt. Các thành phần này được cung cấp từ bên ngoài hoặc không hề được cung cấp.
Tôi nghĩ Nomad đã tìm ra sự dung hòa hoàn hảo giữa tính dễ sử dụng và tiện ích. Nó tốt cho các dịch vụ nhỏ, độc lập. Nếu cần kiểm soát nhiều hơn, bạn sẽ phải tự mình nâng cao chúng hoặc sử dụng một cách tiếp cận khác. Nomad là chỉ người dàn nhạc.
Điều tốt nhất về Nomad là nó dễ dàng thay thế. Thực tế không có kết nối nào với nhà cung cấp vì các chức năng của nó có thể dễ dàng tích hợp vào bất kỳ hệ thống quản lý dịch vụ nào khác. Nó chỉ chạy như một hệ nhị phân thông thường trên mọi máy trong cụm, thế thôi!
Hệ sinh thái du mục gồm các thành phần liên kết lỏng lẻo
Sức mạnh thực sự của Nomad là hệ sinh thái của nó. Nó tích hợp rất tốt với các sản phẩm khác - hoàn toàn tùy chọn - như (kho khóa-giá trị) hoặc (xử lý bí mật). Bên trong tệp Nomad có các phần để trích xuất dữ liệu từ các dịch vụ này:
template {
data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH
destination = "secrets/file.env"
env = true
}
Ở đây chúng ta đọc chìa khóa service/geo-api/log-verbosity từ Lãnh sự và trong khi làm việc, chúng tôi tiếp xúc với một biến môi trường LOG_LEVEL. Chúng tôi cũng trình bày chìa khóa secret/geo-api-key từ Vault dưới dạng API_KEY. Đơn giản nhưng mạnh mẽ!
Do tính đơn giản của nó, Nomad có thể dễ dàng mở rộng với các dịch vụ khác thông qua API. Ví dụ: thẻ cho nhiệm vụ được hỗ trợ. Chúng tôi gắn thẻ tất cả các dịch vụ bằng số liệu trv-metrics. Bằng cách này, Prometheus có thể dễ dàng tìm thấy các dịch vụ này thông qua Consul và kiểm tra điểm cuối định kỳ /metrics cho dữ liệu mới. Điều tương tự có thể được thực hiện, ví dụ, đối với nhật ký, sử dụng .
Có nhiều ví dụ khác về khả năng mở rộng:
- Chạy công việc Jenkins bằng cách sử dụng hook và Consul giám sát việc triển khai lại công việc Nomad khi cấu hình dịch vụ thay đổi.
- Ceph thêm hệ thống tệp phân tán vào Nomad.
- để cân bằng tải.
Tất cả điều này cho phép không có bất kỳ mối liên hệ đặc biệt nào với nhà cung cấp.
Cảnh báo đúng
Không có hệ thống nào là hoàn hảo. Tôi không khuyên bạn nên đưa ngay các tính năng mới nhất vào sản xuất. Tất nhiên là có lỗi và thiếu tính năng, nhưng điều tương tự cũng áp dụng cho Kubernetes.
So với Kubernetes, cộng đồng Nomad không lớn lắm. Kubernetes đã có khoảng 75 cam kết và 000 người đóng góp, trong khi Nomad có khoảng 2000 cam kết và 14 người đóng góp. Nomad sẽ khó theo kịp tốc độ của Kubernetes, nhưng có lẽ điều đó không cần thiết! Đây là một hệ thống chuyên biệt hơn và cộng đồng nhỏ hơn cũng có nghĩa là yêu cầu kéo của bạn có nhiều khả năng được chú ý và chấp nhận hơn so với Kubernetes.
Tóm tắt thông tin
Điểm mấu chốt: Đừng sử dụng Kubernetes chỉ vì những người khác đang làm việc đó. Đánh giá các yêu cầu của bạn một cách cẩn thận và kiểm tra xem công cụ nào có lợi hơn.
Nếu bạn dự định triển khai nhiều dịch vụ đồng nhất trên cơ sở hạ tầng quy mô lớn thì Kubernetes là một lựa chọn tốt. Chỉ cần lưu ý đến sự phức tạp và chi phí vận hành tăng thêm. Có thể tránh được một số chi phí bằng cách sử dụng môi trường Kubernetes được quản lý như hoặc .
Nếu bạn chỉ đang tìm kiếm một bộ điều phối đáng tin cậy, dễ bảo trì và có thể mở rộng, tại sao không thử Nomad? Bạn có thể ngạc nhiên về việc điều này sẽ đưa bạn đi bao xa.
Nếu Kubernetes được so sánh với một chiếc ô tô thì Nomad sẽ là một chiếc xe tay ga. Đôi khi bạn cần một thứ và đôi khi bạn cần một thứ khác. Cả hai đều có quyền tồn tại.
Nguồn: www.habr.com