Hạm đội Docker-Swarm, Kubernetes, Mesos & Core-OS

Tôi còn khá mới đối với tất cả những thứ này, nhưng tôi gặp khó khăn khi có một bức tranh rõ ràng trong số các công nghệ được liệt kê.

Mặc dù, tất cả những điều này cố gắng giải quyết các vấn đề khác nhau, nhưng cũng có những điểm chung. Tôi muốn hiểu những gì là phổ biến và những gì là khác nhau. Có khả năng sự kết hợp của một số ít sẽ rất phù hợp, nếu vậy chúng là gì?

Tôi đang liệt kê một vài trong số chúng cùng với các câu hỏi, nhưng sẽ thật tuyệt nếu ai đó liệt kê chi tiết tất cả chúng và trả lời các câu hỏi.

1. Kubernetes vs Mesos:

   Liên kết này

   Sự khác biệt giữa Mesos của Apache và Kubernetes của Google là gì

   cung cấp một cái nhìn sâu sắc về sự khác biệt, nhưng tôi không thể hiểu tại sao Kubernetes nên chạy trên đỉnh Mesos. Có phải là nhiều hơn để làm với nhau của hai giải pháp mã nguồn mở?

2. Kubernetes vs Hạm đội hệ điều hành lõi:

   Nếu tôi sử dụng kubernetes, đội tàu có cần thiết không?

3. Làm thế nào để Docker-Swarm phù hợp với tất cả các bên trên?

Tiết lộ: Tôi là kỹ sư chính của Kubernetes

Tôi nghĩ rằng Mesos và Kubernetes chủ yếu nhằm giải quyết các vấn đề tương tự khi chạy các ứng dụng phân cụm, chúng có lịch sử khác nhau và cách tiếp cận khác nhau để giải quyết vấn đề.

Mesos tập trung năng lượng của mình vào việc lập lịch trình rất chung chung và cắm vào nhiều lịch trình khác nhau. Điều này có nghĩa là nó cho phép các hệ thống như Hadoop và Marathon cùng tồn tại trong cùng một môi trường lập lịch. Mesos ít tập trung vào việc chạy container. Mesos tồn tại trước khi quan tâm rộng rãi đến các container và đã được tái sản xuất trong các bộ phận để hỗ trợ các container.

Ngược lại, Kubernetes được thiết kế từ đầu để trở thành môi trường để xây dựng các ứng dụng phân tán từ các container. Nó bao gồm các nguyên thủy để nhân rộng và khám phá dịch vụ như các nguyên thủy cốt lõi, trong đó những thứ như vậy được thêm vào thông qua các khung trong Mesos. Mục tiêu chính của Kubernetes là một hệ thống để xây dựng, chạy và quản lý các hệ thống phân tán.

Hạm đội là một nhà phân phối nhiệm vụ cấp thấp hơn. Nó rất hữu ích cho việc bootstrapping một hệ thống cụm, ví dụ CoreOS sử dụng nó để phân phối các tác nhân kubernetes và nhị phân ra các máy trong một cụm để bật lên một cụm kubernetes. Nó không thực sự có ý định giải quyết các vấn đề phát triển ứng dụng phân tán tương tự, hãy nghĩ về nó giống như systemd / init.d / upstart cho cụm của bạn. Không bắt buộc nếu bạn chạy kubernetes, bạn có thể sử dụng các công cụ khác (ví dụ: Salt, Puppet, Ansible, Chef, ...) để thực hiện phân phối nhị phân tương tự.

Swarm là một nỗ lực của Docker để mở rộng API Docker hiện có để làm cho một cụm máy trông giống như một API Docker duy nhất. Về cơ bản, kinh nghiệm của chúng tôi tại Google và các nơi khác chỉ ra rằng API nút không đủ cho API cụm. Bạn có thể xem một loạt các cuộc thảo luận về vấn đề này tại đây: https://github.com/docker/docker/pull/8859 và tại đây: https://github.com/docker/docker/issues/8781

Mong rằng sẽ giúp! Tham gia với chúng tôi trên IRC @ # google-container nếu bạn muốn nói nhiều hơn.

Tôi nghĩ rằng câu trả lời đơn giản nhất là không có câu trả lời đơn giản. Sự gia tăng nhanh chóng về sức mạnh của các container và đặc biệt Docker đã để lại một khoảng trống quyền lực cho "lập kế hoạch và sắp xếp container", bất cứ điều gì có thể có nghĩa. Trong thực tế, điều đó có nghĩa là bạn có một số công nghệ có thể hoạt động hài hòa ở một số cấp độ, nhưng với các khía cạnh nhất định trong cạnh tranh. Ví dụ, Kubernetes có thể được sử dụng như một cửa hàng duy nhất để triển khai và quản lý các container trên cụm tính toán (như Google đã thiết kế ban đầu), nhưng cũng có thể ngồi trên Hạm đội, sử dụng tầng khả năng phục hồi mà Hạm đội cung cấp trên CoreOS.

Vì Google vid này tuyên bố Kubernetes không phải là một giải pháp mở rộng quy mô hộp chứa hoàn chỉnh, nhưng là một tuyên bố tốt để bắt đầu từ đó. Theo cách tương tự, ở một giai đoạn nào đó, bạn sẽ mong đợi Apache Mesos có thể làm việc với Kubernetes, nhưng không phải với Marathon, giống như Marathon dường như hoàn thành vai trò tương tự như Kubernetes. Ở đâu đó tôi nghĩ rằng tôi đã đọc những điều này có thể trở thành một phần của cùng một nỗ lực, nhưng tôi có thể sai về điều đó - đó thực sự là về định hướng chiến lược của Mesosphere và việc áp dụng các nguyên tắc Kubernetes tương ứng.

Trong bài phát biểu của DockerCon, Solomon Hykes đã đề xuất Swarm sẽ là một tầng có thể cung cấp giao diện chung cho nhiều khung công tác sắp xếp và lên lịch. Từ những gì tôi có thể thấy, Swarm được thiết kế để cung cấp quy trình triển khai Docker trơn tru, hoạt động với một số khung quy trình công việc chứa hiện có như Deis, nhưng đủ linh hoạt để mang lại khả năng triển khai và quản lý tài nguyên "nặng" như Mesos.

Hy vọng điều này sẽ giúp - đây có thể là một bài viết rất lớn. Tôi nghĩ điều quan trọng là đây là những dịch vụ trẻ, đang phát triển có khả năng hợp nhất và trở nên tương thích, nhưng chúng ta cần phải ra ngoài trong 12 tháng tới để xem nó diễn ra như thế nào. Có một số người rất thông minh về vấn đề này, vì vậy tương lai có vẻ rất tươi sáng.

Theo như tôi hiểu thì:

Mesos, Kubernetes và Hạm đội đều đang cố gắng giải quyết một vấn đề rất giống nhau. Ý tưởng là bạn trừu tượng hóa tất cả phần cứng của bạn khỏi các nhà phát triển và 'công cụ quản lý cụm' sắp xếp tất cả cho bạn. Sau đó, tất cả những gì bạn cần làm là cung cấp một container cho cụm, cung cấp cho nó một số thông tin (giữ cho nó chạy vĩnh viễn, mở rộng nếu X xảy ra, v.v.) và trình quản lý cụm sẽ làm cho nó xảy ra.

Với Mesos, nó thực hiện tất cả quản lý cụm cho bạn, nhưng nó không bao gồm bộ lập lịch. Bộ lập lịch là bit cho biết, ok quá trình này cần 2 procs và 512MB RAM, và tôi có một máy ở đó miễn phí, vì vậy tôi sẽ chạy nó trên máy đó. Có một số lịch trình plugin có sẵn cho Mesos: Marathon và Chronos và bạn có thể tự viết. Điều này cung cấp cho bạn rất nhiều sức mạnh của phân phối tài nguyên và quy mô cụm, v.v.

Hạm đội và Kubernetes dường như trừu tượng hóa những loại chi tiết đó (vì vậy về cơ bản bạn không phải viết lịch trình của riêng mình). Điều này có nghĩa là bạn phải xác định nhiệm vụ của mình và gửi chúng theo định dạng / cách được xác định bởi Hạm đội hoặc Kubernetes và sau đó họ tiếp quản và lên lịch các nhiệm vụ (thùng chứa) cho bạn.

Vì vậy, tôi đoán: Sử dụng Mesos có thể có nghĩa là một chút công việc hơn trong việc viết lịch trình của riêng bạn, nhưng có khả năng cung cấp linh hoạt hơn nếu được yêu cầu.

Tôi nghĩ ý tưởng chạy Kubernetes trên đỉnh Mesos là Kubernetes đóng vai trò là người lập lịch cho Mesos. Cá nhân tôi không chắc chắn những lợi ích này mang lại khi chạy cái này hay cái khác mặc dù (hy vọng ai đó sẽ nhảy vào và giải thích!)

Như MikeB đã nói .. đó là những ngày đầu, và tất cả đã sẵn sàng (hãy để mắt đến ECS của Amazon) vì vậy có nhiều tiêu chuẩn cạnh tranh và rất nhiều sự chồng chéo!

-edit- Tôi đã không đề cập đến Docker swarm vì tôi không thực sự có nhiều kinh nghiệm với nó.

Đối với bất cứ ai đến đây sau khi hạm đội 2017 không được chấp nhận. Không sử dụng nó nữa.

Các tài liệu của hạm đội nói rằng "hạm đội không còn được CoreOS phát triển hoặc duy trì tích cực" và liên kết với việc điều phối Container: Chuyển từ hạm đội sang Kubernetes . Hạm đội đã bị xóa khỏi Container Linux ( trước đây gọi là CoreOS Linux ) và được thay thế bằng Kubernetes kubelet (tác nhân). Điều này trùng hợp với một trụ cột của công ty để cung cấp Tectonic (một bản phân phối Kubernetes) làm sản phẩm chính của họ.