‫Hãy nói về lý do tại sao bạn có thể cần Kubernetes.
‫Bây giờ là một bài đánh giá, hãy kiểm
‫tra lại với các phần trước đó. Phần đầu tiên dành cho Swarm
‫và có một bài giảng có tựa đề Swarm Mode built-in Orchestration.
‫Điều đó cung cấp cho bạn một số kiến thức cơ bản xung
‫quanh các vấn đề mà hệ thống điều phối giải quyết và tại sao
‫bạn có thể cần nó. Tôi sẽ nhấn mạnh rằng
‫lúc đầu, chắc chắn điều quan trọng là bạn
‫phải hiểu những lợi ích điều phối mà bạn sẽ cần để triển
‫khai các ứng dụng của mình và liệu bạn có
‫cần điều phối để bắt đầu hay không.
‫Orchestration chắc chắn đang ngày càng phổ biến, nhưng đó không
‫phải là cách duy nhất để chạy các container.
‫Chúng tôi đã nói về việc sử dụng Docker chạy ở đây.
‫Chúng tôi đã nói về Docker Compose.
‫Chúng tôi đã nói về các dịch vụ và dịch vụ nền tảng khác.
‫Tôi có những khách hàng vẫn chạy
‫vùng chứa trên các nút đơn trong AWS mà không
‫cần điều phối. Họ sử dụng các tính
‫năng của nền tảng đó để tạo ra một sự trừu tượng tương tự như điều phối,
‫nơi họ có thể sử dụng các nhóm tự động mở rộng quy mô, Cân bằng
‫tải đàn hồi và nhiều thứ khác mà tất cả chúng ta đã
‫sử dụng trong hơn một thập kỷ để quản lý việc
‫triển khai ứng dụng của mình.
‫Họ có một hệ thống tinh tế đến nỗi họ không thấy nhiều lợi
‫ích từ việc thay đổi hoàn toàn tất cả những điều đó sang
‫hệ thống điều phối.
‫Bây giờ, hầu hết chúng ta cuối cùng sẽ
‫sử dụng một số hình thức điều phối vùng chứa bởi vì đó thực sự
‫là cách mà tôi nghĩ rằng ngành đang diễn ra và đây đều
‫sẽ là những lớp bổ sung này chạy trên Docker hoặc một số
‫thời gian chạy khác, đó là những gì bạn đã học trong
‫suốt khóa học này.
‫Một trong những công thức đơn giản mà tôi sử dụng
‫để biết có nên sử dụng
‫điều phối hay không, đó là lấy số lượng
‫máy chủ mà tôi sẽ cần cho môi trường cụ thể, sau
‫đó là tốc độ thay đổi của các ứng dụng của tôi,
‫hoặc chính môi trường và nhân hai điều đó thực sự tương đương
‫với lợi ích của việc điều phối.
‫Ý tôi muốn nói là điều phối được thiết kế để tự động hóa sự
‫thay đổi và giám sát trạng
‫thái của mọi thứ và đảm bảo mọi thứ đều ở trạng thái
‫mà bạn mong đợi.
‫Ví dụ: các ứng dụng đang chạy ở trạng thái khỏe mạnh.
‫Khi mới bắt đầu, bạn có thể chỉ
‫cần một máy chủ hoặc chỉ một vài máy chủ và
‫nếu bạn không thường xuyên thay đổi các ứng dụng của mình, giả
‫sử bạn chỉ thay đổi chúng một lần mỗi tháng hoặc ít hơn, sau đó
‫điều phối, và nỗ lực liên quan đến việc triển khai nó, quản lý
‫nó, bảo mật nó, có thể là không cần thiết
‫ở trạng thái của bạn. Đặc biệt nếu bạn là một nhà phát
‫triển solo hoặc chỉ là một nhóm rất nhỏ.
‫Đó là nơi mà những thứ như Elastic Beanstalk hoặc Heroku, nền tảng
‫triển khai ứng dụng, đó là nơi mà rất nhiều trong số
‫đó bắt đầu tỏa sáng như những lựa chọn thay thế
‫cho việc điều phối của riêng bạn.
‫Tất nhiên, câu hỏi phổ biến nhất mà
‫tôi nhận được từ mọi người khi họ nhận ra rằng
‫họ cần sự điều phối, là quyết định xem họ muốn cái nào.
‫Thực sự tại thời điểm này vào
‫năm 2019, có ít nhất hai hoặc ba nền tảng chính.
‫Nếu bạn bao gồm các giải pháp Đám mây, có thể có bốn hoặc
‫năm nền tảng chính ở đó.
‫Những thứ tôi nói đến trong khóa học này là hai thứ hàng
‫đầu hoạt động ở mọi nơi. Đó là Swarm và Kubernetes.
‫Sau đó, bạn có những cái khác
‫dành riêng cho nền tảng
‫Đám mây, như ECS, chỉ có trên AWS và các
‫dịch vụ truyền thống khác đã tồn tại
‫lâu hơn một chút như Cloud Foundry hoặc Mesos và Marathon.
‫Nhưng tôi nghĩ nếu bạn là người quan
‫tâm đến việc chạy các vùng chứa tại chỗ và trong Đám
‫mây, hoặc có khả năng phát nhiều đám mây, bạn có thể
‫không muốn sử dụng các dịch vụ dành riêng cho
‫Đám mây đó như ECS vì chúng đã có trước Kubernetes.
‫Vì vậy, đó là một giải pháp kế thừa mà Amazon vẫn hỗ
‫trợ và nó vẫn là một lựa chọn gọn gàng, nhưng chỉ khi bạn dành
‫riêng cho AWS và đó là nơi duy nhất bạn từng có kế
‫hoạch triển khai các vùng chứa.
‫Đối với rất nhiều khách hàng của tôi và đối với rất nhiều sinh
‫viên của tôi, các lựa chọn thường là, tôi cần một thứ gì đó lai tạp.
‫Có nghĩa là tôi có thể chạy nó trong trung tâm dữ liệu
‫của mình hoặc trong nhiều đám mây. Nó không thể chỉ chạy
‫ở một vị trí duy nhất. Điều đó thường là Swarm hoặc
‫Kubernetes là lựa chọn lớn của họ bởi vì đó là
‫hai giải pháp là những bộ dàn nhạc vùng
‫chứa phổ biến nhất.
‫Chúng chạy trên mọi đám mây, trong các trung tâm dữ liệu và thậm
‫chí là các môi trường nhỏ có thể như IoT.
‫Nếu bạn quyết định chọn Kubernetes làm người điều khiển dàn
‫nhạc của mình, thì quyết định quan trọng tiếp theo là bạn sẽ
‫sử dụng bản phân phối nào.
‫Phần đầu tiên của việc đó là tìm hiểu xem bạn muốn một
‫giải pháp được quản lý trên Đám mây hay
‫nếu bạn muốn triển khai giải pháp của riêng mình với sản phẩm của
‫nhà cung cấp mà bạn sẽ tự cài đặt trên các máy chủ.
‫Các bản phân phối phổ biến được hỗ trợ bởi nhà cung
‫cấp mà bạn đã nghe tôi nói về, bao gồm Docker
‫Enterprise và có những bản phân phối khác như Rancher
‫OpenShift từ Red Hat. Canonical, công ty Ubuntu, có phiên
‫bản riêng của họ.
‫VMware có phiên bản riêng của họ.
‫PKS cũng vậy.
‫Trên thực tế, có rất nhiều giải pháp cơ sở
‫hạ tầng và nhà cung cấp công ty phần mềm cho Kubernetes
‫hiện nay khiến nó hơi áp đảo.
‫Tôi sẽ cung cấp cho bạn một liên kết trong các tài nguyên đến danh sách
‫các bản phân phối được Kubernetes chứng nhận.
‫Bạn muốn sử dụng một trong những cái này vì họ đảm
‫bảo rằng API từ Kubernetes được sử dụng trực tiếp và nó được
‫hỗ trợ đầy đủ.
‫Vì vậy, trường hợp lý tưởng là bạn có thể lấy khối lượng công việc
‫và các tệp YAML của mình để thiết kế cơ sở hạ tầng của bạn và
‫bạn có thể di chuyển chúng từ nhà cung cấp Kubernetes
‫này sang nhà cung cấp khác và chúng sẽ hoạt động hiệu quả
‫cho hầu hết mọi thứ.
‫Bây giờ có một tùy chọn khác mà tôi vừa đề
‫cập ở đây là sử dụng phiên bản ngược dòng GitHub
‫thô của Kubernetes.
‫Đó là những gì mà tất cả các bản phân phối dựa trên.
‫Ví dụ: nếu bạn nhìn ngược dòng và bạn
‫thấy Kubernetes 1. 14 phát hành.
‫Sau đó, khi xem sản phẩm của nhà cung
‫cấp, bạn sẽ quan tâm đến phiên bản Kubernetes nào mà họ hỗ trợ.
‫Thông thường, các sản phẩm của nhà cung cấp đi sau một vài phiên bản,
‫nhưng ngày nay, cuộc đua là tất cả đều chỉ
‫cập nhật càng nhiều càng tốt.
‫Vì vậy, tôi có xu hướng chỉ thấy chúng có một phiên bản đã lỗi thời vào
‫hầu hết các thời điểm.
‫Bây giờ, điều mà bạn nhận được từ các
‫giải pháp của nhà cung cấp, ngoài các tùy chọn hỗ trợ của
‫nhà cung cấp đó, còn là gói các công cụ khác với nó.
‫Một trong những điều về Kubernetes
‫hơi khác một chút so với Swarm
‫là nó cần thêm nhiều thứ để thực sự dễ
‫dàng sử dụng. Vì vậy, có thể
‫bạn, khi nhận được giải pháp của nhà cung cấp, sẽ thấy
‫những thứ như giải pháp xác thực tùy chỉnh, quản trị web tùy chỉnh và
‫mạng tùy chỉnh, chỉ để nêu tên một số.
‫Nói chung, tôi sẽ khuyên bạn, mà không cần biết
‫bất kỳ yêu cầu nào của bạn, rằng
‫bạn có thể không cần phiên bản ngược dòng thuần
‫túy của Kubernetes của GitHub.
‫Bạn không cần sao chép repo của Kubernetes và chỉ
‫chạy như vậy.
‫Bây giờ, nó rất tốt cho việc học.
‫Trên thực tế, tôi khuyên bạn nên bắt đầu với đó
‫là cách để học Kubernetes. Tuy nhiên, một khi bạn tham gia
‫vào các giải pháp của nhà cung cấp, tất cả những giải
‫pháp đó sẽ khác một chút về bảo mật, mạng và những thứ khác.
‫Vì vậy, sẽ rất khó để bạn học một cái và sau đó
‫cứ cho rằng cái kia cũng hành động như vậy.
‫Tuy nhiên, khi bạn bắt đầu nói về sản xuất, tôi mong
‫rằng bạn sẽ cố gắng sử dụng một trong
‫những giải pháp của nhà cung cấp đó trước vì chúng sẽ
‫dễ quản lý hơn. Bạn sẽ có các tùy chọn hỗ trợ tốt hơn.
‫Nói chung, mọi thứ sẽ hoạt động tốt hơn và nhanh
‫hơn.