‫Kubernetes hoặc Swarm.
‫Đó là một trong những câu hỏi phổ biến nhất mà tôi nhận được sau khi một người
‫nào đó đã tìm hiểu đủ về dàn nhạc và sau đó muốn đưa ra quyết
‫định về việc sử dụng cái nào.
‫Tôi khuyên bạn nên xem video đầu tiên trên
‫Swarm, đặc biệt là video đầu tiên
‫về điều đó. Đó là Chế
‫độ dàn nhạc tích hợp trong Swarm bởi vì một lần nữa, điều đó sẽ cung
‫cấp cho bạn thông tin cơ bản về lý do tại sao việc điều phối là cần thiết
‫để giải quyết một số vấn đề nhất định. Sau đó, cũng xem các video
‫trước đó trong phần này về Kubernetes để bạn hiểu nền
‫tảng của cả hai công cụ trước khi chúng ta
‫tiếp tục. Như một cơ sở ở đây, đây là
‫cả hai công cụ giải quyết các vấn đề tương tự. Cả hai đều là bộ điều phối
‫vùng chứa chạy trên đầu của
‫thời gian chạy vùng chứa.
‫Trong loạt video này, bạn đã tìm hiểu về thời gian
‫chạy của vùng chứa Docker.
‫Hiện có những cái khác, containerd và CRI-O.
‫Thực sự, Docker là số 1.
‫Nó được sử dụng trong hầu hết mọi trường hợp.
‫Cả hai đều được hỗ trợ bởi các nhà cung cấp và đội
‫ngũ những người làm việc trên các sản phẩm.
‫Nói chung, nếu tôi phải viết một
‫dòng tweet để so sánh cả hai, thì đơn giản là Swarm dễ xây
‫dựng, dễ thêm các nút vào, dễ bắt đầu
‫và dễ quản lý. Vì vậy, dễ dàng
‫chắc chắn là điều tôi muốn nói cho Swarm.
‫Tuy nhiên, nó không giải quyết được tất cả các trường
‫hợp sử dụng trong đó Kubernetes có nhiều chức năng, tính linh
‫hoạt và tùy chỉnh hơn. Nó có thể giải quyết nhiều vấn đề
‫hơn, theo nhiều cách hơn và nhìn chung cũng được áp dụng và hỗ
‫trợ rộng rãi hơn.
‫Đối với bạn, để giúp bạn quyết định bạn muốn sử dụng
‫cái nào, chúng ta sẽ đi qua một số tiêu chí về
‫ưu điểm của từng loại. Tôi nghĩ rằng điều quan trọng, thực
‫sự, đối với tất cả chúng ta nếu bạn tham gia cộng đồng DevOps và sử dụng
‫những công cụ này để giải quyết các vấn đề kinh doanh,
‫bạn nên biết cả hai.
‫Bạn sẽ có thể cài đặt cả hai và sau đó
‫triển khai ứng dụng trên cả hai và biết một
‫số chức năng cơ bản xung quanh việc triển khai ứng dụng, tạo tùy
‫chọn Ingress cho lưu lượng truy cập, sau đó cập nhật
‫các ứng dụng đó. Tôi nghĩ rằng chỉ
‫điều đó thôi sẽ giúp bạn đủ quen với các công cụ để bạn
‫biết nên sử dụng cái nào để giải quyết vấn đề nào.
‫Có rất nhiều lợi thế cho mỗi.
‫Hãy phá vỡ điều này thật nhanh chóng. Về phía Swarm,
‫như bạn đã học trong suốt khóa học này,
‫nó đi kèm với Docker. Vì vậy, đó là một giải pháp duy nhất được nhà cung cấp hỗ trợ.
‫Có nghĩa là thời gian chạy vùng chứa và bộ điều phối,
‫được xây dựng bởi cùng một công ty.
‫Điều đó gặt hái rất nhiều phần thưởng, bao gồm ít phức tạp hơn, sử
‫dụng tài nguyên nhỏ hơn chỉ để
‫chạy mọi thứ. Running Swarm sử
‫dụng rất ít tài nguyên trên Docker.
‫Nó được thiết kế với quy trình làm việc của
‫nhà phát triển. Vì vậy, nó rất tốt
‫cho các Ops và các nhà phát triển sử dụng. Như tôi đã nói, thật dễ
‫dàng để triển khai và quản lý một dàn nhạc thuộc loại này.
‫Nó có thể dễ dàng phát triển lên hàng trăm, nếu không
‫muốn nói là hàng nghìn, và bạn không nhất thiết phải cần
‫một nhóm lớn để quản lý nó. Bạn có
‫thể nói rằng nó tuân theo quy tắc 80/20, trong đó nó có
‫20% các tính năng của Kubernetes và giải quyết được 80% các
‫trường hợp sử dụng để chạy vùng
‫chứa và điều phối.
‫Bây giờ, đó không phải là một so sánh khoa học.
‫Tôi thực sự không biết số tính năng chính xác. Tôi không biết làm thế
‫nào bạn thậm chí thực sự làm điều đó.
‫Tuy nhiên, đó có vẻ là cảm giác của nó khi bạn chạy cả hai mà bạn
‫nhận ra rằng Swarm giải quyết phần lớn các trường hợp sử dụng
‫để chạy các giải pháp chạy ứng dụng web lâu dài trên máy chủ, cho
‫dù đó là trong Đám mây hoặc trung tâm dữ liệu, hoặc thậm chí trên
‫các thiết bị nhỏ. Nó dường như hoạt động tốt
‫ngay từ đầu. Nó có những gì bạn cần. Nó
‫có mạng. Nó có Ingress. Nó có mã hóa.
‫Tất cả những thứ đó. Nó có cơ sở dữ liệu.
‫Vì vậy, nó thực sự giải quyết được rất nhiều vấn đề.
‫Tuy nhiên, nó không giải quyết được tất cả các trường hợp sử dụng, cho tất cả các trường hợp, để chạy
‫một ứng dụng trên máy.
‫Đó là nơi Kubernetes có thể lấp đầy khoảng trống.
‫Một lợi thế lớn khác của điều này là nó chạy ở
‫bất cứ nơi nào Docker chạy. Docker Engine, hiện đã được sáu năm
‫tuổi và là bước khởi đầu của cuộc cách mạng toàn bộ vùng chứa
‫này, Engine chạy ở nhiều nơi hơn bất kỳ công cụ nào khác.
‫Nó không chỉ chạy trên Linux mà còn chạy trên Windows.
‫Nó chạy trên Mainframe.
‫Nó chạy trên các thiết bị ARM, có
‫nghĩa là Embedded, IoT, Raspberry Pis.
‫Nó chạy trên ARM cũ, ARM mới, 32
‫bit, 64 bit. Như tôi đã nói, nó chỉ ở khắp nơi.
‫Nó chạy nguyên bản trên Windows Server trong nhiều
‫năm kể từ Server 2016.
‫Vì vậy, nó chắc chắn là bộ dàn nhạc được hỗ trợ lâu nhất
‫cho một môi trường đa kiến trúc đa dạng, nếu đó là
‫nhu cầu của bạn.
‫Ngoài ra, nó an toàn, và bạn đã nghe
‫tôi nói về điều đó trong khóa học này,
‫rằng khi bạn tạo một Swarm và bạn thêm các nút, nó đảm
‫bảo xác thực Telus lẫn nhau. Nó mã hóa mặt phẳng điều khiển và nó mã hóa
‫cơ sở dữ liệu để bảo vệ bí mật của bạn trong
‫trường hợp bạn muốn lưu trữ chúng.
‫Điều đó thật tuyệt vì tôi thấy rất nhiều nhóm, khi họ gấp
‫rút về thời hạn hoặc
‫có thể họ hơi choáng ngợp với sự phức
‫tạp, có xu hướng quên hoặc bỏ qua một số yêu cầu bảo mật mà các
‫công cụ khác như Kubernetes yêu cầu. Cuối cùng ở đây, tôi tin rằng
‫việc khắc phục sự cố sẽ dễ dàng hơn vì có ít bộ
‫phận chuyển động hơn. Có ít thứ hơn để quản lý.
‫Vì nó được tích hợp vào Docker theo mặc định, nếu bạn biết
‫cách khắc phục sự cố Docker, thì bạn có thể biết cách
‫khắc phục sự cố Swarm.
‫Nó sử dụng các bản ghi daemon giống nhau. Nó sử dụng cùng một lệnh
‫nhật ký Docker cho các ứng dụng. Nó sử dụng cùng một lệnh
‫sự kiện Docker để xem các sự kiện trên các nút và
‫chính Swarm. Bây giờ điều đó
‫nghe có vẻ như rất nhiều lợi thế cho một Swarm, nhưng tôi không muốn
‫bạn nghĩ rằng đó luôn là điều phù hợp với
‫bạn.
‫Nói chung, Swarm là công cụ mà tôi khuyên dùng khi mọi người
‫mới bắt đầu và bắt đầu với quy mô nhỏ.
‫Có thể họ là một người đơn lẻ, hoặc chỉ một,
‫hai hoặc ba người trong nhóm của họ và họ cần xem liệu
‫một người dàn nhạc nhỏ, đơn giản có phù hợp
‫với họ hay không. Tôi luôn giới thiệu Swarm trước, trừ
‫khi bạn biết chắc chắn mình phải sử dụng Kubernetes, tôi khuyên
‫bạn nên sử dụng Swarm. Một khi bạn nghĩ rằng bạn đã
‫đạt đến một số giới hạn trong Swarm và bạn nghĩ rằng bạn không thể hoàn thành
‫những gì bạn cần từ nó, đó là lúc
‫bạn nên xem xét Kubernetes.
‫Bây giờ chúng ta hãy nói về một số trong những lợi thế.
‫Trước hết, các đám mây và các nhà cung cấp thực sự
‫thích hỗ trợ Kubernetes. Vì nó đã trở nên quá phổ biến,
‫và đặc biệt là loại zeitgeist phổ biến trên báo chí và phương tiện truyền
‫thông, nó là thứ mà mọi nhà cung cấp hiện
‫nay đang tìm cách kiểm tra trong danh sách của họ về việc
‫chúng tôi hỗ trợ Kubernetes.
‫Vì vậy, tôi có thể nói rằng nó hoàn toàn có đám mây rộng nhất và
‫hỗ trợ nhà cung cấp.
‫Mỗi nhà cung cấp dịch vụ đám mây đều cung cấp Kubernetes, vì vậy nếu
‫bạn không muốn tự chạy nó, bạn có thể để họ khởi động tất
‫cả hệ thống và sau đó về cơ bản bạn chỉ
‫đang chạy các ứng dụng của mình trên đó bằng cách sử dụng
‫các tệp triển khai Kubernetes. Ngay cả các nhà cung
‫cấp cơ sở hạ tầng hiện cũng có phân phối Kubernetes của riêng họ bao
‫gồm VMware, Red Hat. Ngay cả các công ty như
‫Netflix, vốn theo truyền thống chỉ là nhà cung cấp dịch vụ lưu trữ, cũng có
‫phiên bản hoặc bản phân phối Kubernetes đã được phê duyệt của riêng họ.
‫Vì vậy, điều hiển nhiên ở đây là nó có sự chấp
‫nhận và hỗ trợ rộng rãi nhất, và điều đó chắc chắn đúng.
‫Nhưng ngoài ra, nó còn có tập hợp các trường hợp sử dụng được hỗ trợ
‫rộng rãi nhất. Vì nó
‫có rất nhiều thứ để chuyển đổi và thao tác, cũng như
‫rất nhiều tính năng khác nhau và các
‫tùy chọn của bên thứ ba, nó chắc chắn bao gồm
‫nhiều trường hợp cạnh hơn Swarm. Trên thực tế, bạn sẽ bắt đầu thấy
‫điều này với các nhà cung cấp mà bạn có thể đã
‫làm việc hôm nay, nơi họ sẽ hỗ trợ Kubernetes
‫đầu tiên, đó là cách tôi nói rằng các nhà cung cấp sẽ xem xét cách
‫họ có thể hỗ trợ Kubernetes với sản phẩm của họ trước khi họ bận tâm. để đi xem
‫xét sản phẩm Swarm của Docker.
‫Đặc biệt là vì ngành này có thái độ như vậy nên
‫mọi thứ đều cần hỗ
‫trợ Kubernetes, bạn sẽ thấy rằng các nhà cung cấp bạn đã có
‫có thể đã có bản phân phối hoặc giải pháp để chạy
‫các công cụ của họ trên Kubernetes. Ví dụ, với Jenkins, từ
‫công ty CloudBees.
‫Nếu bạn đã mua giải pháp Enterprise của họ, họ sẽ
‫cung cấp cho bạn công cụ Kubernetes và các mẫu về cách chạy nó.
‫Nó không có nghĩa là bạn không thể chạy Jenkins trên Swarm.
‫Nó chạy rất tốt ở đó.
‫Nó chỉ có nghĩa là bạn sẽ nhận được sự hỗ trợ tốt hơn từ
‫nhà cung cấp cho việc đó.
‫Ưu điểm cuối cùng mà tôi sẽ đề cập ở đây
‫là một lợi thế kỳ lạ. Tôi sẽ bỏ qua thuật ngữ này
‫về việc không ai bị sa thải vì mua IBM.
‫Câu nói này đã trở nên phổ biến cách đây
‫nhiều thập kỷ khi IBM là nhà cung cấp máy tính
‫và gia công phần cứng lớn nhất, máy tính lớn và PC
‫của bạn, và đã có lúc họ thực sự giết
‫chết nó trên thị trường.
‫Về cơ bản, nếu bạn không thể đưa ra quyết định về nhà
‫cung cấp bạn muốn đồng hành cùng. Nếu bạn chỉ đi
‫một cách an toàn, bạn sẽ đi với IBM.
‫Bạn sẽ không bao giờ thực sự bị sa thải vì điều đó bởi vì đó là
‫nhà cung cấp đáng tin cậy vào thời điểm đó.
‫Tôi sẽ nói rằng, nói chung, đối với toàn bộ nền tảng
‫Kubernetes, điều đó đã trở thành trường hợp bây giờ.
‫Tôi sẽ tranh luận rằng nó thậm chí đã trở thành một
‫mục kiểm tra cho các CIO và CTO.
‫Điều đó có thể có một chút tốt và xấu, bởi vì điều
‫đó có thể có nghĩa là bạn sẽ được yêu cầu chạy Kubernetes ngay
‫cả khi bạn chưa có yêu cầu kỹ thuật.
‫Bạn vừa được ban quản lý thông báo rằng chúng
‫tôi cần chạy Kubernetes. Đối với họ, đó có
‫thể chỉ là thứ họ muốn chạy bất kể yêu cầu kỹ thuật, lợi
‫ích là gì, hoặc so sánh nó với các nền tảng khác nhau.
‫Đó rõ ràng là một phần của thế giới chính trị này, nơi các
‫quyết định về CNTT không phải lúc nào cũng được đưa ra chỉ dựa trên
‫các yêu cầu hoặc kỹ thuật.
‫Nó thường có thể là do việc sử dụng
‫dễ dàng mua nó. Nói cách khác, nếu bạn đã có
‫một nhà cung cấp có một nhà cung cấp, bạn có thể chỉ cần sử dụng sản phẩm của họ thay
‫vì một sản phẩm khác vì nó dễ dàng hơn.
‫O, r kinh nghiệm trong nền nhóm của bạn có thể có kinh nghiệm
‫tốt hơn từ các công việc hoặc dự án trước đây của họ.
‫Vì vậy, bạn sẽ chỉ triển khai cái đó vì
‫ai đó đã biết nó. Hoặc, có thể bạn sẽ mua nó
‫vì không may, ban quản lý của bạn đọc tạp chí hoặc đọc
‫Internet, và Internet cho họ biết họ cần chọn một sản
‫phẩm nào đó như Kubernetes.
‫Vì vậy, đó là cái mà họ yêu cầu bạn sử dụng.
‫Trên thực tế, khi tôi tổ chức các hội thảo trực tiếp và tôi hỏi
‫mọi người tại sao họ lại chọn dàn nhạc mà họ đang điều hành, câu
‫trả lời phổ biến nhất mà tôi nhận được từ họ, thật không may, vẫn là, sếp của
‫tôi đã bảo tôi làm điều này.
‫Vì vậy, mọi người không phải lúc nào cũng có tiếng nói về những gì họ
‫điều hành, đó là lý do tại sao tôi đang cố gắng cung cấp cho bạn
‫sự cân bằng tốt giữa công cụ và tính năng của cả hai để bạn là người được
‫đào tạo bài bản nhất trong nhóm của mình và có thể
‫giúp họ với các yêu cầu kỹ thuật thực sự và giúp bạn đưa ra quyết định tốt nhất.