Kubeflow là gì

Trong bài viết ngắn này, tôi sẽ cố gắng nắm bắt những điểm khác biệt chính giữa các công cụ MLops Ploomber và KubeFlow. Chúng tôi sẽ trình bày một số thông tin cơ bản về đường ống Ploomber, Kubeflow là gì và tại sao chúng ta cần những công cụ đó để giúp cuộc sống của chúng ta dễ dàng hơn. 

Chúng ta sẽ thấy sự khác biệt trong 3 lĩnh vực chính:

• Dễ sử dụng
• Cộng tác và lặp lại nhanh chóng
• Gỡ lỗi, kiểm tra và khả năng tái tạo

Vì vậy, chúng ta hãy đi sâu vào!

Bối cảnh

 
Hãy bắt đầu với phần giải thích ngắn gọn về quy trình làm việc dữ liệu / ML chung trông như thế nào, tại sao chúng ta cần điều phối và cách nó sẽ giúp bạn thực hiện công việc của mình tốt hơn và nhanh hơn.

Thông thường, khi một tổ chức có dữ liệu và đang tìm cách tạo ra thông tin chi tiết hoặc dự đoán từ đó [để thúc đẩy kết quả kinh doanh], họ đưa các Nhà khoa học dữ liệu hoặc MLEs đến để khám phá dữ liệu, chuẩn bị cho việc tiêu thụ và tạo ra một mô hình. Sau đó, 3 nhiệm vụ này có thể được thống nhất thành một đường ống dữ liệu với các nhiệm vụ tương quan, lấy dữ liệu, làm sạch nó và đào tạo một mô hình. Kiến trúc này khá cơ bản cho một đường ống dữ liệu, chúng ta sẽ có một đầu vào và đầu ra cho mỗi tác vụ và đó là những gì xác định các phụ thuộc trong đường ống. 

Dàn nhạc là gì và tại sao chúng ta cần nó?

 
Thời điểm chúng ta thêm nhiều tác vụ vào đường ống, nó đột nhiên trở nên phức tạp hơn. Trong một số trường hợp, đặc biệt là trong môi trường sản xuất, đường ống có các nhiệm vụ song song và chúng có thể có một đến nhiều đầu vào và đầu ra nhưng nó luôn bắt đầu ở một nơi và kết thúc ở một nơi khác. Thông thường, điều này được gọi là biểu đồ xoay chiều trực tiếp [DAG]. DAG là đại diện của quy trình làm việc ML và trong hầu hết các khuôn khổ phổ biến hiện nay như Ploomber, Kubeflow, Airflow, MLflow và nhiều hơn nữa, đó là cách để kiểm soát và hiển thị đường ống dữ liệu. Vâng, đây là khái niệm DAG tương tự trong khóa học thuật toán của bạn! [những người trong số các bạn đã lấy nó]. Khi biểu diễn này của mỗi tác vụ được xác định, bộ điều phối sau đó sẽ tuân theo thứ tự của nó và thực hiện từng tác vụ, đó là các phụ thuộc và kết quả đầu ra, và sẽ thử lại nếu cần [chúng ta có thể xem DAG ở trên để tham khảo].

Kubeflow vs Ploomber

 
Bây giờ đến khóa học chính, chúng ta đã có một số hiểu biết về các đường ống dẫn dữ liệu cơ bản, các cấu trúc và khái niệm phổ biến và tại sao chúng ta cần chúng. Chúng tôi sẽ xem xét hai công cụ này từ 4 góc độ khác nhau để hiểu sự khác biệt và khi nào bạn sẽ cần sử dụng từng công cụ. 

Dễ sử dụng

 
Giá trị của một công cụ theo quan điểm của tôi là từ trải nghiệm tổng thể - thiết lập, các bước bổ sung, bảo trì và sự dễ sử dụng trong mỗi bước đó. Khi tôi phải triển khai một cụm Kubeflow, rào cản đầu tiên tôi gặp phải là tài liệu, tấn trang và các tùy chọn để triển khai, ngoài ra sau đó tôi đã phát hiện ra rằng tôi không thể chạy cục bộ trên máy tính xách tay của mình, điều này khá cơ bản nếu bạn muốn kiểm tra công việc của mình TRƯỚC khi nghĩ đến sản xuất. Hầu hết các dự án khoa học dữ liệu đều bắt đầu dưới dạng "thí nghiệm nghiên cứu" và không chắc họ có thể đưa nó vào sản xuất hay không. Một trong những câu hỏi đầu tiên là liệu dữ liệu có đúng không và chúng ta có đủ dữ liệu không? Ý tưởng tốt nhất ở đây là nhanh chóng bắt đầu lặp lại những câu hỏi này bằng cách xoay một môi trường cục bộ thay vì một thiết lập khổng lồ. 

Bây giờ quay lại thiết lập nó, tôi cũng phát hiện ra có 2 phiên bản sau khi cài đặt nên tôi tiếp tục sử dụng phiên bản cũ [không có cách nào tôi phải trải qua quá trình cài đặt dài này một lần nữa]. Khi cụm được định cấu hình trên tài khoản đám mây mà tôi đã mở cho nó, tôi nhận ra rằng mình phải sử dụng apis phức tạp cho python và có một số hạn chế để chạy trên docker [phải giữ các tác vụ dưới dạng văn bản miễn phí]. Trong suốt quá trình này, tôi đã thử một trong những khuôn khổ được cho là sẽ giúp tôi giảm bớt tất cả, đặc biệt là với máy tính xách tay, Kale - nhưng không thành công. Mặt khác, với Ploomber, bắt đầu cục bộ thật dễ dàng, tất cả những gì tôi phải làm là chạy pip install ploomber, sau đó tôi có thể bắt đầu từ một đường ống mẫu và phát triển trên máy tính xách tay của mình. Các tài liệu được cấu trúc theo cách mà mọi trường hợp sử dụng đều có một sách dạy nấu ăn và các khái niệm được giải thích ở một nơi. Nó cho phép triển khai cả cục bộ và trên đám mây nên sau khi hoàn thành các bước lặp, tôi có thể gửi công việc cho cụm Kubeflow của mình. Có api CLI cho các hành động cơ bản và api python cho người dùng nâng cao hơn.

Cộng tác và lặp lại nhanh chóng

 
Trên Kubeflow khi tôi cần chạy qua một vùng chứa mỗi khi nó kéo hình ảnh và mất khoảng 1 phút để bắt đầu chạy các tác vụ. Ngoài ra, tôi thực sự không thể đăng nhập vào vùng chứa và xem những gì đang xảy ra, những thứ cơ bản như hình ảnh nào đang được sử dụng, những phụ thuộc nào hiện đang được sử dụng, v.v. Kết quả đầu ra trong vùng chứa rất khó, có một vị trí cụ thể mà tôi có thể lưu chúng , mà không cần tham số hóa. Cuối cùng, tôi đã phải sử dụng lưu trữ đám mây để cho phép lặp lại nhanh hơn. Trong Ploomber, tôi có thể chỉ cần sử dụng một env / conda ảo pip và khóa các phiên bản theo cách tôi muốn [điều này rất phù hợp trong môi trường sản xuất nơi Jupyter có quyền truy cập hạn chế vào các gói mới]. Ngoài ra, vì mã đang chạy cục bộ thông qua python, tôi có thể lặp lại từng tác vụ và hiểu chính xác những gì đang xảy ra mà không cần tạo một đường dẫn hoàn toàn mới cho nó hoặc thay đổi mã. Bạn có thể xác định chính xác nơi đầu ra đang được lưu, cục bộ hoặc lên đám mây. Ngoài ra, vì mã sổ ghi chép đang được dịch sang các tập lệnh, tôi có thể đẩy mã của mình vào Git và cộng tác với phần còn lại của nhóm khoa học dữ liệu.

Gỡ lỗi, kiểm tra và khả năng tái tạo

 
Vì Kubeflow [hoặc ít nhất là MiniKF tôi đang chạy] chạy trên một cụm đám mây và mã chạy bên trong một vùng chứa, nên khá khó để gỡ lỗi và kiểm tra mã. Tôi không thể tìm thấy bất kỳ nơi nào trong tài liệu của họ về cách tôi có thể đăng nhập vào vùng chứa và bắt đầu phiên gỡ lỗi. Điều này làm cho việc kiểm tra mã trở nên rất khó khăn. Ngoài ra, vì bạn không thể đăng nhập vào môi trường đang chạy và xem các khung dữ liệu hiện tại và các tạo tác khác nhau nên thực sự không thể tái tạo mỗi lần chạy. Mặt khác, trong Ploomber không chỉ là cục bộ nên bạn có thể bắt đầu phiên gỡ lỗi ngay lập tức, bạn cũng có thể đăng nhập vào vùng chứa docker của mình và hiểu các phụ thuộc. Cách dễ dàng hơn để kiểm tra mã của bạn khi nó ở dạng mô-đun và bạn không cần phải đợi toàn bộ đường dẫn chạy.

Khi Kubeflow sẽ có ý nghĩa

 
Trong trường hợp bạn đã sẵn sàng một đường dẫn và bạn đang tìm kiếm một cụm hiệu suất cao để triển khai nó, nghĩa là sau tất cả các hoạt động thăm dò, phân tích và lặp lại dữ liệu tương tác thì đó là một trường hợp sử dụng tốt cho Kubeflow. Khi bạn mới bắt đầu quy trình, cần lặp lại dữ liệu nhanh chóng và điều chỉnh đường dẫn, Ploomber sẽ phù hợp hơn vì nó hợp lý hóa quy trình này. Bạn có thể nhanh chóng lặp lại quy trình công việc của mình, di chuyển nhanh hơn và khi bạn đã sẵn sàng, trình kết nối Kubeflow sẽ cho phép bạn triển khai liền mạch đường ống dữ liệu cuối cùng.

Kết luận

 
Nhìn chung, đây là một trải nghiệm thú vị đối với tôi, hiểu được tất cả các lỗ hổng trong kiến ​​trúc Kubeflow hiện có và đưa các giải pháp thông qua Ploomber. Tôi tin rằng khoa học dữ liệu và MLops hoạt động phải dễ dàng, có thể bảo trì và tái sử dụng. Tôi hiểu thị trường ngách mà Kubeflow đang hướng tới và tôi hy vọng rằng V2 sẽ mang lại trải nghiệm mượt mà hơn cho người dùng của họ. Trong các công cụ và cơ sở hạ tầng dành cho nhà phát triển, điều quan trọng là phải sử dụng các công cụ không chỉ giải quyết được vấn đề mà còn dễ tiếp cận với những người mới và việc bảo trì nó thân thiện [như Ploomber!], Xét cho cùng thì khả năng công cụ đó sẽ được thay thế trong một vài tháng là không cao.

Cảm ơn vì đã đọc tất cả các cách! Nếu bạn đang tìm kiếm một giải pháp tốt hơn để sắp xếp quy trình công việc của mình, hãy đưa ra Ploomber một sự cố gắng.

Ido Michael đồng sáng lập Ploomber để giúp các nhà khoa học dữ liệu xây dựng nhanh hơn. Anh ấy đã từng làm việc tại các nhóm khoa học / kỹ thuật dữ liệu hàng đầu của AWS. Anh ấy đã tự tay xây dựng 100 đường ống dẫn dữ liệu trong những lần tương tác với khách hàng đó cùng với nhóm của mình. Xuất thân từ Israel, ông đến NY để lấy bằng Thạc sĩ tại Đại học Columbia. Anh ấy tập trung vào việc xây dựng Ploomber sau khi anh ấy liên tục nhận thấy rằng các dự án dành khoảng 30% thời gian của họ chỉ để cấu trúc lại công việc của nhà phát triển [nguyên mẫu] thành một quy trình sản xuất.

• Techblog
• Dịch vụ Cloud Computing

Bảo mật vẫn luôn là mối quan tâm hàng đầu của các tất cả doanh nghiệp hiện nay. Tuy nhiên, đối với các tổ chức sử dụng Kubernetes [nền tảng mã nguồn mở], người ta lại ít bận tâm tới mức độ bảo mật không cao vốn có của nó. Thay vào đó họ phần lớn chỉ chú ý đến mức độ phức tạp của Kubernetes, và thực tế cũng cho thấy ngay cả các chuyên gia lành nghề cũng gặp khó khăn nất định khi sử dụng công cụ. 

Theo báo cáo gần đây của StackRox, các vấn đề như chưa được đào tạo, thiếu kinh nghiệm hay cấu hình sai là nguyên nhân lớn nhất gây ra sự cố bảo mật Kubernetes. Sau khi khảo sát hơn 540 tham gia vào năm ngoái,kết quả cho thấy có đến hơn 94% trong số đó đã gặp sự cố bảo mật với Kubernetes.

Tuy nhiên, không chỉ những người tham gia kẻ trên mà các trường hợp được liệt kê trong danh sách dưới đây cũng đã gặp sự cố tương tự. Vậy họ đã giải quyết lỗi bảo mật Kubernetes như thế nào, và chúng ta có thể học được gì từ đó? Tìm hiểu 5 sự cố bảo mật Kubernetes qua bài viết của Bizfly Cloud dưới đây nhé. 

Capital One

Đây là sự cố bảo mật Kubernetes khá lớn và dường như là tiếng chuông cảnh tỉnh cả cộng đồng. Sự cố xảy ra đúng một năm trước, một vụ rò rỉ 30GB dữ liệu tín dụng ảnh hưởng đến khoảng 106 triệu người. Lỗ hổng thường thấy trong nền tảng Kubernetes thường bắt nguồn từ một cấu hình lỗi. Cụ thể, một tường lửa có cấu hình sai đã tạo điều kiện cho hacker tấn công truy vấn dữ liệu nội bộ và có được thông tin xác thực về IAM [quản lý truy cập và nhận dạng] của Amazon Web Services.

Một trong những bài học quan trọng mà chúng ta học được từ sự cố này là cần cẩn trọng hơn khi phân chia IAM role. Hầu hết mọi người vội vàng kích hoạt Kubernetes và bỏ qua các phần cần lưu tâm như quản lý dữ liệu quan trọng và phân chia IAM theo từng nhóm thay vì từng ứng dụng. Một nhiệm vụ quan trọng khác là thường xuyên cập nhật thông tin đăng nhập, tốt nhất là dùng một dịch vụ giới hạn thời gian đăng nhập. Điều này giúp đặt ra nhiều hạn chế về thời gian hoạt động của các hoạt động vi phạm trên hệ thống.

Docker Hub

Với Kubernetes, trong các container và môi trường phân tán, phạm vi tấn công ngày càng lớn theo cấp số nhân và bạn không thể truy vết cuộc tấn công đó đến từ đâu. Ví dụ, khi hacker tấn công trình quản lý của Docker Hub để tạo ra những docker image gắn mã độc trong Docker Hub vào năm ngoái, khiến bất cứ ai sử dụng docker image đó đều bị mã hóa. Người dùng vô tình triển khai các công cụ khai thác tiền điện tử dưới dạng Docker containers, sau đó nó chuyển hướng tài nguyên sang khai thác cho kẻ tấn công. Đây chỉ là một trong số các cuộc tấn công bị phát hiện gần đây.

Tương tự như Capital One, cần thay đổi mật khẩu và thông tin đăng nhập thường xuyên để tránh loại tình huống này. Ngoài ra, đối với Kubernetes, cần thay phiên thông tin bí mật và kiểm tra docker image thường xuyên để đảm bảo chỉ những hình ảnh đã xác minh mới được sử dụng nhằm đảm bảo an ninh. Docker image gắn mã độc khá khó bị phát hiện, đặc biệt nó mất nhiều thời gian hơn. Đây là lý do vì sao các kiểm tra bổ sung sẽ sàng lọc bất kỳ sai lệch nào trong ứng dụng và phát hiện các quy trình ẩn được cài đặt trong hệ thống. Kiểu tấn công này khá hiệu quả.

Microsoft Azure

Microsoft cũng nằm trong số những cái tên gặp rắc rối về tiền điện tử. Họ tiết lộ rằng, đã có một cuộc tấn công tiền điện tử quy mô lớn chống lại tổ hợp Kubernetes trong Azure vào tháng 4 năm nay, một chiến dịch tương tự được phát hiện vào tháng 6 nhằm vào các container Kubeflow được cấu hình sai để biến chúng thành tiền điện tử. Tương tự như trường hợp Docker Hub, Kubeflow sử dụng một số dịch vụ cho phép người dùng dùng ditto được tùy chỉnh như với Katib và Jupyter Notebook. Đối với Jupyter, hình ảnh được chọn không phải là hình ảnh hợp pháp và đó là kẽ hở cho các kẻ xấu tấn công.

Nếu xem xét nguyên nhân dẫn đến cấu hình sai thì đó là do tính thiếu kiên nhẫn, lười biếng và thiếu kiến thức. Bảng điều khiển UI của Kubeflow theo mặc định chỉ có thể truy cập nội bộ thông qua cổng Istio. Tuy nhiên, một số người dùng muốn rút ngắn công đoạn để truy cập trực tiếp vào bảng điều khiển mà không thông qua máy chủ API Kubernetes và không nhận ra rằng khi họ tiết kiệm được thời gian thì nó cũng đang mở ra một số backtime trong quy trình. Họ đã để lộ cổng xâm nhập Istio vào internet, cho phép mọi người đều truy cập được vào bảng điều khiển. Bài học ở đây là đảm bảo bảo mật cho mọi cài đặt hoặc thay đổi cấu hình đang dùng.

Tesla

Với trị giá tiền điện tử tăng vọt và tài nguyên khai thác vô hạn trong Cloud, việc chiếm đoạt tài nguyên sẽ sinh lợi cao hơn việc đánh cắp thông tin. Nhà sản xuất ô tô nổi tiếng Tesla là một trong những nạn nhân của tiền điện tử khi cụm Kubernetes bị xâm phạm do bảng điều khiển không được bảo vệ. 

RedLock Cloud Security Intelligence phát hiện và công khai trong một báo cáo đã nêu rõ việc cấu hình sai đã tạo điều kiện những kẻ tấn công nắm giữ vùng chứa thông tin xác thực AWS S3 của Tesla. Những thông tin đăng nhập sau đó được sử dụng để chạy các tập lệnh được mã hóa trên một nhóm.

Điều thú vị trong cuộc tấn công là số lượng thủ thuật được thực hiện để tránh bị phát hiện. Ngoài việc không sử dụng nhóm khai thác đã bị phát hiện thay vào đó là một nhóm không công khai, chúng còn sử dụng dịch vụ CDN của Cloudflare để ẩn IP của chúng.

Những kẻ tấn công cũng thiết lập tập lệnh khai thác không sử dụng hết tài nguyên CPU để tránh gây ra báo động hoặc bị phát hiện và nghe trên một cổng không chính thức, khiến việc phát hiện dựa trên lưu lượng truy cập hầu như không thể. Cách duy nhất để phát hiện vi phạm này là chủ động giám sát các cấu hình để đảm bảo tất cả các chính sách bảo mật đang được tuân thủ.

Jenkins

Cùng với sự cố Tesla, tin tặc đã khai thác lỗ hổng trong Jenkins để mã hóa khoảng 3,5 triệu đô la, hay 10.800 Monero trong 18 tháng. Moreno là một loại tiền điện tử có liên quan đến sự cố hình ảnh độc hại Docker Hub được nhắc đến trước đó. Trong trường hợp của Docker Hub, người ta đã phát hiện có 6 hình ảnh gắn mã độc được kéo hơn 2 triệu lần, đó là 2 triệu người dùng bị kẻ tấn công tận dụng để khai thác Monero một cách khá kỳ công.

Sự cố bảo mật Kubernetes của Jenkins vẫn là một trong những vi phạm nghiêm trọng nhất được phát hiện cho đến nay. Nó sử dụng các máy Windows và máy tính cá nhân dễ bị tấn công và cũng nhắm vào các máy chủ của Jenkins CI. Nó liên tục tự cập nhật và thay đổi nhóm khai thác để tránh bị phát hiện. Việc nó có thể nhắm vào các máy chủ là một bước tiến mới của những kẻ tấn công đến từ Trung Quốc. Nếu họ có thể thu về hơn 3 triệu đô la từ máy tính bàn thì các máy chủ mạnh mẽ có thể mang lại nguồn lợi có giá trị thêm vài số 0 nữa.

Bảo mật Kubernetes gia tăng nhờ không gian tấn công ngày càng đa dạng

Sự cố bảo mật Kubernetes đang gia tăng vì môi trường tấn công cũng đang trở nên đa dạng vô cùng tận với các cụm Cloud, trung tâm dữ liệu tại chỗ, thiết bị IoT, máy tính cá nhân… Bảo mật khép kín không còn tồn tại nữa - khi bạn chỉ tập trung vào ứng dụng của mình và để phần công việc còn lại cho tường lửa phòng thủ. 

Mối đe dọa có thể đến từ một dịch vụ đang được sử dụng ngay trong hệ thống hoặc từ bên cung cấp dịch vụ thứ ba bạn đang sử dụng. Giờ đây, bảo mật là trách nhiệm chung của tất cả mọi người, các nhà cung cấp dịch vụ Cloud hay quản lý Kubernetes chỉ có thể đảm nhiệm tốt phần công việc của họ mà thôi. Cryptojacking [khai thác tiền ảo] chỉ thực sự phát triển khi chúng nắm được lỗ hổng bảo mật đó và sẽ khá khó để phát hiện trừ khi bạn thực hiện các kiểm tra hóa đơn dịch vụ Cloud và phát hiện định mức cao bất thường.

Tham khảo Techgenx.com

>> Có thể bạn quan tâm: BizFly Cloud chính thức ra mắt Kubernetes Engine đầu tiên tại Việt Nam

BizFly Cloud là hệ sinh thái điện toán đám mây được vận hành bởi VCCorp - Công ty dẫn đầu trong lĩnh vực công nghệ và truyền thông tại Việt Nam. Với đội ngũ kỹ thuật viên trình độ cao và kinh nghiệm lâu năm làm việc trên các công nghệ khác nhau như cloud, mobile, web..., chúng tôi có đủ khả năng để hỗ trợ đưa ra những giải pháp và công nghệ toàn diện giúp doanh nghiệp chuyển đổi số thành công. Hãy tăng tốc thích nghi cho doanh nghiệp cùng các giải pháp công nghệ của BizFly Cloud tại đây.