Kubernetes so với CloudFoundry [đã đóng cửa]

Phiên bản tiếp theo của CloudFoundry / Diego sẽ cung cấp hỗ trợ riêng cho vùng chứa Docker sẽ được điều phối trên nhiều máy chủ lưu trữ [ liên kết ]. Điều này nghe rất giống với Kubernetes.

Tất nhiên, vấn đề mà Kubernetes đang cố gắng giải quyết mang tính chất chung chung, trong đó CloudFoundry tập trung nhiều hơn vào phát triển ứng dụng. Tuy nhiên, đối với tôi, có vẻ như cả hai đều đang đi theo một hướng giống nhau và CloudFoundry đang bổ sung thêm nhiều tính năng hơn trên bản phối đơn giản.

Vì vậy, tôi tự hỏi về các trường hợp sử dụng mà Kubernetes sẽ thêm nhiều giá trị hơn CloudFoundry?

Với tư cách là người cam kết CloudFoundry (trước đây) và Kubernetes (hiện tại), tôi có lẽ đủ điều kiện duy nhất để trả lời câu hỏi này.

Giống PaaS

Tôi thích gọi CloudFoundry là "Application PaaS" và Kubernetes là "Container PaaS", nhưng sự khác biệt khá tinh tế và linh hoạt, vì cả hai dự án đều thay đổi theo thời gian để cạnh tranh trên cùng một thị trường.

Sự khác biệt giữa hai điều này là CF có một lớp tổ chức lấy ứng dụng người dùng (12 yếu tố) (ví dụ: jar hoặc gem) và một gói xây dựng kiểu Heroku (ví dụ: Java + Tomcat hoặc Ruby) và tạo ra một giọt (tương tự như Hình ảnh Docker). CF không hiển thị giao diện chứa cho người dùng, nhưng Kubernetes thì có.

Khán giả

Đối tượng chính của CloudFoundry là các nhà phát triển ứng dụng doanh nghiệp muốn triển khai các ứng dụng không trạng thái 12 yếu tố bằng cách sử dụng các gói xây dựng kiểu Heroku.

Đối tượng của Kubernetes rộng hơn một chút, bao gồm cả các nhà phát triển ứng dụng không trạng thái và các nhà phát triển dịch vụ có trạng thái cung cấp vùng chứa của riêng họ.

Sự khác biệt này có thể thay đổi trong tương lai:

• CloudFoundry có thể bắt đầu chấp nhận hình ảnh docker ( Lattice chấp nhận hình ảnh Docker ).
• Kubernetes có thể thêm một lớp tạo hình ảnh ( OpenShift làm như thế này ).

So sánh tính năng

Khi cả hai dự án trưởng thành và cạnh tranh, những điểm giống và khác nhau của chúng sẽ thay đổi. Vì vậy, hãy so sánh đặc điểm sau với một hạt muối.

Cả CF và K8 đều chia sẻ nhiều tính năng tương tự, như container hóa, không gian tên, xác thực,

Lợi thế cạnh tranh của Kubernetes:

• Nhóm và chia tỷ lệ các nhóm các vùng chứa chia sẻ một ngăn xếp mạng, thay vì chỉ chia tỷ lệ độc lập
• Mang theo hộp đựng của riêng bạn
• Lớp tồn tại trạng thái
• Cộng đồng PMNM lớn hơn, tích cực hơn
• Kiến trúc có thể mở rộng hơn với các thành phần có thể thay thế và plugin của bên thứ 3
• GUI web miễn phí

Lợi thế cạnh tranh của CloudFoundry:

• Xác thực người lớn, phân nhóm người dùng và hỗ trợ cho thuê nhiều lần [x]
• Mang theo ứng dụng của riêng bạn
• Bộ cân bằng tải bao gồm
• Được BOSH [x] triển khai, mở rộng và duy trì hoạt động
• Ghi nhật ký và tổng hợp chỉ số mạnh mẽ [x]
• GUI web doanh nghiệp [x]

[x] Những tính năng này không phải là một phần của Diego hoặc không có trong Lattice.

Triển khai

Một trong những lợi thế cạnh tranh của CloudFoundry là nó có một công cụ triển khai hoàn thiện, BOSH, cho phép các tính năng như mở rộng quy mô, phục hồi và giám sát các thành phần CF cốt lõi. BOSH cũng hỗ trợ nhiều lớp IaaS với tính trừu tượng của nhà cung cấp đám mây có thể cắm được. Thật không may, đường cong học tập và quản lý cấu hình triển khai của BOSH rất tệ. (Là một người cam kết BOSH, tôi nghĩ rằng tôi có thể nói điều này một cách chính xác.)

Sự trừu tượng hóa triển khai của Kubernetes vẫn còn sơ khai. Nhiều môi trường mục tiêu có sẵn trong kho lõi, nhưng chúng không phải tất cả đều hoạt động, được kiểm tra tốt hoặc được hỗ trợ bởi các nhà phát triển chính. Đây chủ yếu là một điều trưởng thành. Người ta có thể mong đợi điều này sẽ cải thiện theo thời gian và tăng tính trừu tượng. Ví dụ: Kubernetes trên DCOS cho phép triển khai Kubernetes vào một cụm DCOS hiện có chỉ với một lệnh duy nhất.

Bối cảnh lịch sử

Diego là người viết lại tác nhân thực thi Droplet của CF. Nó ban đầu được phát triển trước khi Kubernetes được công bố và đã có nhiều tính năng hơn khi bối cảnh cạnh tranh đã phát triển. Mục tiêu ban đầu của nó là tạo ra các giọt (ứng dụng người dùng + gói xây dựng CF) và chạy chúng trong các thùng chứa Warden (được đổi tên thành Garden khi được viết lại trong Go). Kể từ khi ra đời, nó cũng được đóng gói lại dưới dạng Lattice , một phần của CloudFoundry-lite (mặc dù tên đó được lấy bởi một dự án hiện có). Vì lý do đó, Lattice có phần giống như một món đồ chơi, ở chỗ nó đã cố tình giảm đối tượng và phạm vi người dùng, rõ ràng là thiếu các tính năng có thể khiến nó "sẵn sàng cho doanh nghiệp". Các tính năng mà CF đã cung cấp. Điều này một phần là do Lattice được sử dụng để kiểm tra các thành phần cốt lõi, mà không cần một số chi phí từ CF phức tạp hơn, nhưng bạn cũng có thể sử dụng Lattice trong các môi trường có độ tin cậy cao nội bộ nơi không quan tâm nhiều đến vấn đề bảo mật và nhiều người thuê. .

Cũng cần nhắc lại rằng CloudFoundry và Warden (công cụ chứa của nó) cũng có trước Docker vài năm.

Mặt khác, Kubernetes là một dự án tương đối mới được Google phát triển dựa trên nhiều năm sử dụng container với BORG và Omega. Kubernetes có thể được coi là điều phối vùng chứa thế hệ thứ 3 tại Google, giống như cách Diego là điều phối vùng chứa thế hệ thứ 3 tại Pivotal / VMware (v1 được viết tại VMware; v2 tại VMware với sự trợ giúp của Pivotal Labs; v3 tại Pivotal sau khi nó tiếp quản dự án) .

Cloud Foundry là một công cụ tuyệt vời giả sử bạn sẵn sàng luôn làm việc trong những ràng buộc của dịch vụ vì nó rất tuân thủ / quy định. Giao diện người dùng web rất thú vị khi nhìn vào ngày đầu tiên nhưng hiếm khi được sử dụng sau khi bạn bắt đầu làm việc với ứng dụng khách và đã định cấu hình đường dẫn CI / CD của mình. Tôi nhận thấy rằng Cloud Foundry rất tuyệt vời cho đến khi các trường hợp sử dụng bật lên không dễ dàng được hỗ trợ đầy đủ trong Cloud Foundry. Việc cung cấp các trường hợp sử dụng này có thể làm trì hoãn các dự án khi bạn cố gắng giải quyết các vấn đề đó, do đó bạn mất khả năng hiển thị của cơ sở hạ tầng và các lợi ích hỗ trợ của những thành phần sau đó chủ yếu chạy bên ngoài Cloud Foundry (nghĩ rằng nhiều cơ sở dữ liệu, kafka, hadoop, cassandra , v.v.) Tôi nghi ngờ theo thời gian, động lực xung quanh Docker và tính không linh hoạt của Cloud Foundry sẽ thúc đẩy người dùng đến Kubernetes, Mesos hoặc Docker Swarm / Datacenter. Có thể Cloud Foundry có thể bắt kịp ba dự án này nhưng có vẻ như khó xảy ra do sự phổ biến của các dự án mã nguồn mở này.

Thật khó để trả lời tại sao một công ty lại tạo ra một sản phẩm về cơ bản là tương tự với một sản phẩm khác. Có rất nhiều lý do. Có thể họ đã bắt đầu sử dụng và đầu tư vào nó. Có thể họ (CF) nghĩ rằng Kubernetes được thực hiện không tốt hoặc đang nhận sai API / mô hình / chi tiết. Có thể họ nghĩ rằng họ có thể tiến nhanh hơn nếu họ kiểm soát toàn bộ sản phẩm hơn là đóng góp.

Được phép, tôi nói điều này với tư cách là nhà phát triển Kubernetes - người ta có thể hỏi những câu hỏi tương tự như Kubernetes vs Mesos, Amazon ECS vs Kubernetes hoặc Docker Swarm vs Kubernetes.

Tôi hy vọng rằng theo thời gian, tất cả chúng ta đều có xu hướng theo cùng một hướng và có thể cộng tác nhiều hơn và dành ít thời gian hơn để sáng tạo lại công việc của nhau.

Đối với Kubernetes - trọng tâm là các nhà phát triển ứng dụng: các nguyên bản đơn giản và mạnh mẽ cho phép bạn xây dựng và triển khai các ứng dụng trên quy mô rất nhanh. Chúng tôi đang dựa trên kinh nghiệm của mình (tốt, của Google) với các công nghệ tương tự để lập biểu đồ cho khóa học của chúng tôi. Những người khác sẽ có kinh nghiệm hoặc ý kiến ​​khác nhau.

Theo tôi, một sự khác biệt đáng kể là cách tiếp cận mà họ đang thực hiện:

CF tự động xây dựng thời gian chạy từ 3 thành phần: nhị phân ứng dụng do người dùng cung cấp, gói xây dựng chứa phần mềm trung gian cần thiết để chạy ứng dụng và hình ảnh hệ điều hành (một tế bào gốc). Người dùng CF (nhà phát triển) chỉ phải cung cấp tệp nhị phân của ứng dụng (ví dụ: tệp jar thực thi). CF sẽ quan tâm đến phần còn lại, đó là đóng gói và chạy ứng dụng.

Kubernetes mong đợi hình ảnh Docker của nhà phát triển có chứa phần mềm trung gian và hệ điều hành đã được tích hợp sẵn và sẵn sàng chạy. Đối với điều đó, Kubernetes "kê khai triển khai" (ví dụ: biểu đồ Helm) không chỉ mô tả một ứng dụng hoặc dịch vụ mà tất cả các dịch vụ [vi mô] bao gồm giải pháp của bạn trong thời gian chạy. Bạn gửi một mô tả khai báo duy nhất về thời gian chạy của mình và Kubernetes sẽ quan tâm đến trạng thái thời gian chạy thực tế khớp với mô tả đã cung cấp của bạn.

Vì vậy, cách tiếp cận CF cho phép nó giải quyết các trường hợp sử dụng như “thay thế một hệ điều hành bằng một lỗ hổng bảo mật đã vá trong toàn bộ đám mây của bạn mà không cần thời gian ngừng hoạt động cho các dịch vụ của bạn”. Nhưng nó cũng tập trung vào việc triển khai dịch vụ trên mỗi dịch vụ thay vì mô tả khai báo về thời gian chạy mục tiêu “lý tưởng” của hệ thống của bạn.

Cloud Foundry là một hệ thống điện toán đám mây nền tảng như một dịch vụ mã nguồn mở. Cloud Foundry cho phép các dự án được triển khai trong các không gian khác nhau và nó cũng liên kết bất kỳ dịch vụ đám mây nào với ứng dụng của bạn.

Kubernete giống như một công cụ trang trí cho các thùng chứa (pod), tự động hóa việc triển khai, mở rộng quy mô và quản lý các ứng dụng được đóng gói. Nó sử dụng thuật ngữ nhóm để xác định vùng chứa hoặc nhóm các vùng chứa.

Bất kỳ triển khai kubernetes nào cũng cần ít nhất hai tài nguyên:

1) deploy.yaml: Tài nguyên này xác định phiên bản hình ảnh nào nó cần lấy từ đăng ký vùng chứa của bạn, các bản sao (pod replicas), chiến lược triển khai, mở rộng quy mô và thăm dò, v.v.

2) service.yaml: Là giao diện giữa các nhóm bên trong của bạn và thế giới bên ngoài, tất cả lưu lượng bên ngoài sẽ lắng nghe cổng được xác định trong tài nguyên này từ đó nó phân phối tải cho các nhóm bên trong.

Có nhiều tài nguyên hơn đang thâm nhập mà kubernetes cung cấp để quản lý quyền truy cập từ bên ngoài vào các dịch vụ trong một cụm, thường là http. Thông qua Ingress, bạn có thể cung cấp tính năng cân bằng tải, kết thúc SSL và lưu trữ ảo dựa trên tên.

Bạn có thể tìm thấy thêm thông tin về kubernetes bên dưới: https://kubernetes.io/docs/

[pcf vs kubernetes] [1] Sự khác biệt giữa pcf và kubernetes

                                PCF

(trừu tượng nền tảng ở cấp ứng dụng) • Pivotal Cloud Foundry là một trừu tượng hóa cấp cao của phát triển ứng dụng gốc đám mây.

• Chúng tôi có nền tảng trừu tượng ở cấp ứng dụng, xây dựng và triển khai ứng dụng được cấu hình đầy đủ

• PCF là một ví dụ về PaaS “ứng dụng” (còn được gọi là Thời gian chạy ứng dụng Cloud Foundry)

• Nhà phát triển duy trì ứng dụng Trong tương lai

• Lý tưởng cho các ứng dụng mới, ứng dụng gốc đám mây. Đối với các nhóm làm việc với vòng đời ngắn và phát hành thường xuyên, PCF cung cấp một sản phẩm tuyệt vời.

                       Kubernetes 

(trừu tượng hóa nền tảng ở cấp độ vùng chứa) • Kubernetes là một bộ lập lịch hoặc dàn nhạc vùng chứa.

• Chúng tôi có sự trừu tượng hóa nền tảng ở cấp độ vùng chứa, xây dựng và triển khai các vùng chứa như một phần của một ứng dụng hoàn chỉnh.

• Kubernetes là một PaaS “container” (đôi khi được gọi là CaaS).

• Với các công cụ điều phối vùng chứa, Nhà phát triển tạo và sau đó duy trì vùng chứa trong tương lai.

• Đối với ứng dụng mới, nhiều công việc hơn cho các nhóm kỹ sư của bạn và giảm năng suất

Sau 4 năm, xu hướng sẽ như thế này:

Các cụm Kubernetes ngày nay đang trở nên thực sự rẻ và môi trường công cụ cho kubernetes tốt hơn.

Ngoài ra, hầu hết các tính năng cạnh tranh được liệt kê bởi các áp phích khác hiện nay rất dễ sao chép bên trong kubernetes.