Trong sự mong đợi Vitaly Khabarov được phỏng vấn Dmitry Stolyarov (), giám đốc kỹ thuật và đồng sáng lập của công ty Flant. Vitaly hỏi Dmitry về những gì Flant làm, về Kubernetes, sự phát triển, hỗ trợ hệ sinh thái. Chúng tôi đã thảo luận tại sao Kubernetes lại cần thiết và liệu nó có cần thiết hay không. Và còn về microservices, Amazon AWS, cách tiếp cận “Tôi sẽ may mắn” với DevOps, tương lai của chính Kubernetes, tại sao, khi nào và như thế nào nó sẽ chiếm lĩnh thế giới, triển vọng của DevOps và những gì các kỹ sư nên chuẩn bị trong tương lai tươi sáng và gần với sự đơn giản hóa và mạng lưới thần kinh.
nghe dưới dạng podcast trên DevOps Deflop - podcast tiếng Nga về DevOps và bên dưới là bản văn bản.
Ở đây và bên dưới anh ấy đặt câu hỏi kỹ sư từ Express42.
Tin tức về "Flant"
- Chào Dima. Anh là giám đốc kỹ thuật"" và cũng là người sáng lập ra nó. Hãy cho chúng tôi biết công ty làm gì và bạn làm gì trong đó?
Dmitry: Nhìn từ bên ngoài có vẻ như chúng tôi là những người đi khắp nơi để cài đặt Kubernetes cho mọi người và làm điều gì đó với nó. Nhưng điều đó không đúng. Chúng tôi khởi đầu là một công ty kinh doanh Linux, nhưng trong một thời gian rất dài, hoạt động chính của chúng tôi là phục vụ các dự án sản xuất và chìa khóa trao tay tải trọng cao. Thông thường, chúng tôi xây dựng toàn bộ cơ sở hạ tầng từ đầu và sau đó chịu trách nhiệm về nó trong một thời gian dài. Vì vậy, công việc chính mà “Flant” làm và nhận được tiền là chịu trách nhiệm và thực hiện sản xuất chìa khóa trao tay.
Tôi, với tư cách là giám đốc kỹ thuật và là một trong những người sáng lập công ty, dành cả ngày lẫn đêm để tìm cách tăng khả năng tiếp cận sản xuất, đơn giản hóa hoạt động, giúp cuộc sống của quản trị viên dễ dàng hơn và cuộc sống của các nhà phát triển dễ chịu hơn .
Giới thiệu về Kubernetes
— Gần đây tôi thấy rất nhiều báo cáo từ Flant và về Kubernetes. Làm thế nào bạn đến với nó?
Dmitry: Tôi đã nói về điều này nhiều lần rồi, nhưng tôi không ngại nhắc lại chút nào. Tôi nghĩ việc lặp lại chủ đề này là đúng vì có sự nhầm lẫn giữa nguyên nhân và kết quả.
Chúng tôi thực sự cần một công cụ. Chúng tôi đã phải đối mặt với rất nhiều vấn đề, vật lộn, vượt qua chúng bằng nhiều loại nạng khác nhau và cảm thấy cần một công cụ. Chúng tôi đã trải qua nhiều lựa chọn khác nhau, chế tạo những chiếc xe đạp của riêng mình và tích lũy kinh nghiệm. Dần dần, chúng tôi bắt đầu sử dụng Docker gần như ngay khi nó xuất hiện - khoảng năm 2013. Vào thời điểm nó xuất hiện, chúng tôi đã có nhiều kinh nghiệm với các vùng chứa, chúng tôi đã viết một phần tương tự của “Docker” - một số chiếc nạng của riêng chúng tôi bằng Python. Với sự ra đời của Docker, việc vứt bỏ nạng và sử dụng một giải pháp đáng tin cậy và được cộng đồng hỗ trợ đã trở nên khả thi.
Với Kubernetes, câu chuyện cũng tương tự. Vào thời điểm nó bắt đầu có đà - đối với chúng tôi, đây là phiên bản 1.2 - chúng tôi đã có rất nhiều sự hỗ trợ trên cả Shell và Chef, bằng cách nào đó chúng tôi đã cố gắng phối hợp với Docker. Chúng tôi đã nghiêm túc hướng tới Rancher và nhiều giải pháp khác, nhưng sau đó Kubernetes xuất hiện, trong đó mọi thứ được triển khai chính xác như những gì chúng tôi lẽ ra đã làm hoặc thậm chí tốt hơn. Không có gì để phàn nàn.
Vâng, có một số điểm không hoàn hảo ở đây, có một số điểm không hoàn hảo ở đó - có rất nhiều điểm không hoàn hảo, và 1.2 nói chung là khủng khiếp, nhưng... Kubernetes giống như một tòa nhà đang được xây dựng - bạn nhìn vào dự án và hiểu rằng nó sẽ rất tuyệt. Nếu tòa nhà hiện có nền và hai tầng, thì bạn hiểu rằng tốt hơn hết là bạn chưa nên chuyển đến ở, nhưng phần mềm không có vấn đề gì như vậy - bạn đã có thể sử dụng nó.
Chúng tôi chưa có lúc nào nghĩ đến việc sử dụng Kubernetes hay không. Chúng tôi đã chờ đợi nó rất lâu trước khi nó xuất hiện và cố gắng tự mình tạo ra những sản phẩm tương tự.
Giới thiệu về Kubernetes
— Bạn có trực tiếp tham gia vào quá trình phát triển Kubernetes không?
Dmitry: Tầm thường. Đúng hơn, chúng tôi tham gia vào sự phát triển của hệ sinh thái. Chúng tôi gửi một số lượng yêu cầu kéo nhất định: tới Prometheus, tới các nhà khai thác khác nhau, tới Helm - tới hệ sinh thái. Thật không may, tôi không thể theo dõi mọi thứ chúng tôi làm và tôi có thể sai, nhưng không có một nhóm nào từ chúng tôi vào cốt lõi.
— Đồng thời, bạn có phát triển nhiều công cụ của mình xung quanh Kubernetes không?
Dmitry: Chiến lược là thế này: chúng tôi tiến hành và thu thập các yêu cầu tới mọi thứ đã tồn tại. Nếu các yêu cầu kéo không được chấp nhận ở đó, chúng tôi chỉ cần tự phân nhánh chúng và tồn tại cho đến khi chúng được chấp nhận với các bản dựng của chúng tôi. Sau đó, khi nó đến thượng nguồn, chúng ta quay lại phiên bản ngược dòng.
Ví dụ: chúng tôi có một toán tử Prometheus, với toán tử này chúng tôi đã chuyển đổi qua lại ở thượng nguồn của tổ hợp của chúng tôi có lẽ đã 5 lần rồi. Chúng tôi cần một số loại tính năng, chúng tôi đã gửi yêu cầu kéo, chúng tôi cần triển khai nó vào ngày mai, nhưng chúng tôi không muốn đợi nó được phát hành ngược dòng. Theo đó, chúng tôi tự lắp ráp, triển khai lắp ráp với tính năng của chúng tôi, vì lý do nào đó, chúng tôi cần cho tất cả các cụm của mình. Sau đó, chẳng hạn, họ chuyển nó cho chúng tôi ở thượng nguồn với dòng chữ: “Các bạn, hãy làm điều đó cho một trường hợp tổng quát hơn,” chúng tôi hoặc người khác sẽ hoàn thành nó và theo thời gian, nó sẽ hợp nhất trở lại.
Chúng tôi cố gắng phát triển mọi thứ tồn tại. Nhiều yếu tố chưa tồn tại, chưa được phát minh hoặc đã được phát minh nhưng chưa có thời gian để thực hiện - chúng tôi đang làm. Và không phải vì chúng tôi thích quy trình hay chế tạo xe đạp như một ngành công nghiệp, mà đơn giản vì chúng tôi cần công cụ này. Câu hỏi thường được đặt ra là tại sao chúng ta lại làm việc này việc kia? Câu trả lời rất đơn giản - vâng, bởi vì chúng tôi phải tiến xa hơn, giải quyết một số vấn đề thực tế và chúng tôi đã giải quyết nó bằng con tula này.
Con đường luôn như thế này: chúng tôi tìm kiếm rất cẩn thận và nếu không tìm ra giải pháp nào về cách tạo ra một chiếc xe buýt từ một ổ bánh mì, thì chúng tôi sẽ tự làm một ổ bánh mì và một chiếc xe đẩy của riêng mình.
Dụng cụ flanta
— Tôi biết rằng Flant hiện có các toán tử addon, toán tử shell và các công cụ dapp/werf. Theo tôi hiểu, đây là cùng một nhạc cụ trong các hóa thân khác nhau. Tôi cũng hiểu rằng có nhiều công cụ khác nhau trong Flaunt. Điều này có đúng không?
Dmitry: Chúng tôi có nhiều hơn nữa trên GitHub. Theo những gì tôi nhớ bây giờ, chúng tôi có một sơ đồ trạng thái - một bảng điều khiển dành cho Grafana mà mọi người đều đã xem qua. Nó được đề cập trong hầu hết các bài viết thứ hai về giám sát Kubernetes trên Medium. Không thể giải thích ngắn gọn sơ đồ trạng thái là gì - nó cần một bài viết riêng, nhưng nó rất hữu ích để theo dõi trạng thái theo thời gian, vì trong Kubernetes chúng ta thường cần hiển thị trạng thái theo thời gian. Chúng tôi cũng có LogHouse - đây là một thứ dựa trên ClickHouse và ma thuật đen để thu thập nhật ký trong Kubernetes.
Rất nhiều tiện ích! Và sẽ còn nhiều hơn thế nữa vì một số giải pháp nội bộ sẽ được phát hành trong năm nay. Trong số những cái rất lớn dựa trên toán tử addon, có rất nhiều addon dành cho Kubernetes, ala cách cài đặt trình quản lý sert đúng cách - một công cụ quản lý chứng chỉ, cách cài đặt Prometheus chính xác với một loạt phụ kiện - đây là khoảng hai mươi phụ kiện khác nhau nhị phân xuất dữ liệu và thu thập thứ gì đó, Prometheus này có đồ họa và cảnh báo tuyệt vời nhất. Tất cả điều này chỉ là một loạt các tiện ích bổ sung cho Kubernetes, được cài đặt thành một cụm và nó chuyển từ đơn giản sang thú vị, phức tạp, tự động, trong đó nhiều vấn đề đã được giải quyết. Vâng, chúng tôi làm rất nhiều.
Phát triển hệ sinh thái
“Đối với tôi, có vẻ như đây là một đóng góp rất lớn cho sự phát triển của công cụ này và các phương pháp sử dụng nó”. Bạn có thể ước tính sơ bộ ai khác sẽ có đóng góp tương tự cho sự phát triển của hệ sinh thái không?
Dmitry: Ở Nga, trong số các công ty hoạt động trên thị trường của chúng tôi, thậm chí không có công ty nào gần gũi. Tất nhiên, đây là một tuyên bố ồn ào, bởi vì có những công ty lớn như Mail và Yandex - họ cũng đang làm điều gì đó với Kubernetes, nhưng thậm chí họ còn chưa tiến gần đến sự đóng góp của các công ty trên toàn thế giới làm được nhiều việc hơn chúng tôi. Thật khó để so sánh Flant, nơi có đội ngũ nhân viên 80 người và Red Hat, chỉ có 300 kỹ sư trên mỗi Kubernetes, nếu tôi không nhầm. Thật khó để so sánh. Chúng tôi có 6 người trong bộ phận RnD, trong đó có tôi, người đã cắt tất cả các dụng cụ của chúng tôi. 6 người so với 300 kỹ sư của Red Hat - thật khó để so sánh.
- Tuy nhiên, khi ngay cả 6 người này cũng có thể làm được điều gì đó thực sự hữu ích và xa lạ, khi họ phải đối mặt với một vấn đề thực tế và đưa ra giải pháp cho cộng đồng - một trường hợp thú vị. Tôi hiểu rằng ở các công ty công nghệ lớn, nơi họ có nhóm hỗ trợ và phát triển Kubernetes của riêng mình, về nguyên tắc, các công cụ tương tự có thể được phát triển. Đây là một ví dụ cho họ về những gì có thể được phát triển và cung cấp cho cộng đồng, tạo động lực cho toàn bộ cộng đồng sử dụng Kubernetes.
Dmitry: Đây có lẽ là một tính năng của nhà tích hợp, tính đặc thù của nó. Chúng tôi có nhiều dự án và chúng tôi thấy nhiều tình huống khác nhau. Đối với chúng tôi, cách chính để tạo ra giá trị gia tăng là phân tích những trường hợp này, tìm ra điểm chung và làm cho chúng trở nên rẻ nhất có thể đối với chúng tôi. Chúng tôi đang tích cực làm việc này. Thật khó để tôi nói về Nga và thế giới, nhưng chúng tôi có khoảng 40 kỹ sư DevOps trong công ty làm việc trên Kubernetes. Tôi không nghĩ có nhiều công ty ở Nga có số lượng chuyên gia tương đương hiểu biết về Kubernetes, nếu có.
Mình hiểu hết về chức danh kỹ sư DevOps, ai cũng hiểu hết và quen gọi kỹ sư DevOps là kỹ sư DevOps, chúng ta sẽ không bàn về vấn đề này. Tất cả 40 kỹ sư DevOps tuyệt vời này đều phải đối mặt và giải quyết các vấn đề hàng ngày, chúng tôi chỉ phân tích trải nghiệm này và cố gắng khái quát hóa. Chúng tôi hiểu rằng nếu nó vẫn còn trong chúng ta, thì sau một hoặc hai năm nữa, công cụ này sẽ trở nên vô dụng, bởi vì ở đâu đó trong cộng đồng, một Tula làm sẵn sẽ xuất hiện. Chẳng ích gì khi tích lũy kinh nghiệm này trong nội bộ - nó chỉ đơn giản là tiêu hao năng lượng và thời gian vào dev/null. Và chúng tôi không cảm thấy tiếc cho điều đó chút nào. Chúng tôi vô cùng vui mừng xuất bản mọi thứ và hiểu rằng nó cần được xuất bản, phát triển, quảng bá, quảng bá để mọi người sử dụng và bổ sung kinh nghiệm của họ - sau đó mọi thứ đều phát triển và tồn tại. Sau hai năm, dụng cụ này không còn bị vứt vào thùng rác nữa. Không có gì đáng tiếc nếu tiếp tục đổ sức lực, vì rõ ràng là ai đó đang sử dụng công cụ của bạn và sau hai năm mọi người đều sử dụng nó.
Đây là một phần trong chiến lược lớn của chúng tôi với dapp/werf. Tôi không nhớ chúng tôi bắt đầu làm nó khi nào, hình như là 3 năm trước. Ban đầu, nó thường ở trên vỏ. Đó là một bằng chứng tuyệt vời về khái niệm, chúng tôi đã giải quyết được một số vấn đề cụ thể của mình - nó đã thành công! Nhưng có vấn đề với shell, không thể mở rộng thêm được, lập trình trên shell lại là một nhiệm vụ khác. Chúng tôi có thói quen viết bằng Ruby, do đó, chúng tôi làm lại thứ gì đó trong Ruby, phát triển, phát triển, phát triển và nhận thấy rằng cộng đồng, đám đông không nói “chúng tôi muốn hoặc chúng tôi không muốn nó, ” nó hếch mũi nhìn Ruby, buồn cười thế nhỉ? Chúng tôi nhận ra rằng chúng tôi nên viết tất cả những thứ này vào Go chỉ để đáp ứng điểm đầu tiên trong danh sách kiểm tra: Công cụ DevOps phải ở dạng nhị phân tĩnh. Trở thành Go hay không không quá quan trọng, nhưng một hệ nhị phân tĩnh được viết bằng Go thì tốt hơn.
Chúng tôi đã dành năng lượng của mình, viết lại dapp trong Go và gọi nó là werf. Dapp không còn được hỗ trợ, không được phát triển, chạy trong một số phiên bản mới nhất, nhưng có một đường dẫn nâng cấp tuyệt đối lên hàng đầu và bạn có thể làm theo nó.
Tại sao dapp được tạo ra?
— Bạn có thể cho chúng tôi biết ngắn gọn lý do tại sao dapp được tạo ra, nó giải quyết được những vấn đề gì không?
Dmitry: Lý do đầu tiên là ở hội. Ban đầu, chúng tôi gặp vấn đề nghiêm trọng với quá trình xây dựng khi Docker không có khả năng đa giai đoạn, vì vậy chúng tôi đã tự mình tạo nhiều giai đoạn. Sau đó, chúng tôi gặp nhiều vấn đề hơn với việc làm sạch hình ảnh. Tất cả những người thực hiện CI/CD, sớm hay muộn, đều phải đối mặt với vấn đề có rất nhiều hình ảnh được thu thập, bạn cần bằng cách nào đó loại bỏ những gì không cần thiết và để lại những gì cần thiết.
Lý do thứ hai là việc triển khai. Vâng, có Helm, nhưng nó chỉ giải quyết được một số vấn đề. Thật thú vị, người ta viết rằng “Helm là Trình quản lý gói cho Kubernetes”. Chính xác là “cái”. Ngoài ra còn có từ “Trình quản lý gói” - kỳ vọng thông thường của Người quản lý gói là gì? Chúng tôi nói: “Trình quản lý gói - cài đặt gói!” và chúng ta mong đợi anh ta nói với chúng ta: “Gói hàng đã được giao.”
Thật thú vị khi chúng tôi nói: “Helm, cài đặt gói” và khi anh ấy trả lời rằng anh ấy đã cài đặt nó, hóa ra anh ấy mới bắt đầu cài đặt - anh ấy chỉ ra Kubernetes: “Khởi chạy thứ này!”, và liệu nó có bắt đầu hay không , dù có hiệu quả hay không thì Helm cũng không giải quyết được vấn đề này.
Hóa ra Helm chỉ là một bộ tiền xử lý văn bản tải dữ liệu vào Kubernetes.
Nhưng là một phần của bất kỳ quá trình triển khai nào, chúng tôi muốn biết liệu ứng dụng đã được phát hành để sản xuất hay chưa? Triển khai cho sản phẩm có nghĩa là ứng dụng đã được chuyển đến đó, phiên bản mới đã được triển khai và ít nhất nó không gặp sự cố ở đó và phản hồi chính xác. Helm không giải quyết được vấn đề này bằng bất kỳ cách nào. Để giải quyết nó, bạn cần phải tốn rất nhiều công sức, bởi vì bạn cần ra lệnh cho Kubernetes triển khai và theo dõi những gì đang xảy ra ở đó - cho dù nó đã được triển khai hay đã triển khai. Và cũng có rất nhiều công việc liên quan đến triển khai, dọn dẹp, lắp ráp.
Kế hoạch
Năm nay chúng tôi sẽ bắt đầu phát triển địa phương. Chúng tôi muốn đạt được những gì trước đây trong Vagrant - chúng tôi đã gõ “vagrant up” và chúng tôi đã triển khai các máy ảo. Chúng tôi muốn đi đến điểm có một dự án trong Git, chúng tôi viết “werf up” ở đó và nó đưa ra một bản sao cục bộ của dự án này, được triển khai trong một mini-Kub cục bộ, với tất cả các thư mục thuận tiện cho việc phát triển được kết nối . Tùy thuộc vào ngôn ngữ phát triển, việc này được thực hiện khác nhau, tuy nhiên, để việc phát triển cục bộ có thể được thực hiện thuận tiện dưới các tệp được gắn.
Bước tiếp theo đối với chúng tôi là đầu tư vào sự thuận tiện cho các nhà phát triển. Để nhanh chóng triển khai cục bộ một dự án bằng một công cụ, hãy phát triển dự án đó, đẩy dự án đó vào Git và dự án cũng sẽ được triển khai ở giai đoạn hoặc thử nghiệm, tùy thuộc vào quy trình, sau đó sử dụng cùng một công cụ đó để đi vào sản xuất. Sự thống nhất, thống nhất, khả năng tái tạo của cơ sở hạ tầng từ môi trường địa phương đến bán hàng là một điểm rất quan trọng đối với chúng tôi. Nhưng điều này vẫn chưa có sẵn - chúng tôi chỉ đang lên kế hoạch thực hiện nó.
Nhưng con đường dẫn đến dapp/werf luôn giống với Kubernetes lúc ban đầu. Chúng tôi đã gặp phải vấn đề, giải quyết chúng bằng các cách giải quyết khác - chúng tôi đã đưa ra một số giải pháp cho chính mình về shell, trên bất kỳ thứ gì. Sau đó, họ cố gắng giải quyết bằng cách nào đó những cách giải quyết này, khái quát hóa và hợp nhất chúng thành các nhị phân trong trường hợp này mà chúng tôi chỉ chia sẻ.
Có một cách khác để nhìn toàn bộ câu chuyện này bằng những phép loại suy.
Kubernetes là khung ô tô có động cơ. Không có cửa ra vào, kính, đài, cây thông Noel - không có gì cả. Chỉ khung và máy thôi. Và có Helm - đây là vô lăng. Thật tuyệt - có vô lăng, nhưng bạn cũng cần có chốt lái, giá lái, hộp số và bánh xe, và bạn không thể làm gì nếu không có chúng.
Trong trường hợp của werf, đây là một thành phần khác của Kubernetes. Ví dụ: chỉ bây giờ trong phiên bản alpha của werf, Helm mới được biên dịch bên trong werf, bởi vì chúng tôi đã quá mệt mỏi khi phải tự mình làm việc đó. Có nhiều lý do để làm điều này, tôi sẽ cho bạn biết chi tiết về lý do tại sao chúng tôi biên soạn toàn bộ bánh lái cùng với máy xới bên trong werf .
Bây giờ werf là một thành phần tích hợp hơn. Chúng tôi có một chiếc vô lăng đã hoàn thiện, một chốt lái - Tôi không giỏi về ô tô lắm, nhưng đây là một khối lớn đã giải quyết được một loạt vấn đề khá rộng. Chúng ta không cần phải tự mình xem qua danh mục, chọn bộ phận này cho bộ phận khác, nghĩ cách kết hợp chúng lại với nhau. Chúng tôi có được một sự kết hợp làm sẵn để giải quyết một số lượng lớn vấn đề cùng một lúc. Nhưng bên trong nó được xây dựng từ cùng các thành phần nguồn mở, nó vẫn sử dụng Docker để lắp ráp, Helm cho một số chức năng và có một số thư viện khác. Đây là một công cụ tích hợp để lấy CI/CD thú vị ra khỏi hộp một cách nhanh chóng và thuận tiện.
Kubernetes có khó bảo trì không?
— Bạn nói về trải nghiệm khi bạn bắt đầu sử dụng Kubernetes, đây là khung, động cơ dành cho bạn và bạn có thể treo rất nhiều thứ khác nhau trên đó: thân xe, vô lăng, vít trên bàn đạp, ghế ngồi. Câu hỏi đặt ra - việc hỗ trợ Kubernetes đối với bạn khó khăn như thế nào? Bạn có nhiều kinh nghiệm, bạn dành bao nhiêu thời gian và nguồn lực để hỗ trợ Kubernetes tách biệt với mọi thứ khác?
Dmitry: Đây là một câu hỏi rất khó và để trả lời, chúng ta cần hiểu sự hỗ trợ là gì và chúng ta muốn gì từ Kubernetes. Có lẽ bạn có thể tiết lộ?
— Theo những gì tôi biết và thấy, hiện nay có nhiều đội muốn dùng thử Kubernetes. Mọi người đều buộc mình vào nó, đặt nó lên đầu gối của mình. Tôi có cảm giác không phải lúc nào mọi người cũng hiểu được sự phức tạp của hệ thống này.
Dmitry: Nó là như thế đấy.
— Việc cài đặt và cài đặt Kubernetes từ đầu để sẵn sàng sản xuất có khó khăn như thế nào?
Dmitry: Bạn nghĩ việc ghép một trái tim khó đến mức nào? Tôi hiểu đây là một câu hỏi mang tính thỏa hiệp. Sử dụng dao mổ và không phạm sai lầm không phải là điều khó khăn. Nếu họ cho bạn biết nơi cắt và nơi may, thì bản thân quy trình này không phức tạp. Rất khó để đảm bảo hết lần này đến lần khác rằng mọi việc sẽ diễn ra tốt đẹp.
Cài đặt Kubernetes và làm cho nó hoạt động thật dễ dàng: gà con! — đã cài đặt, có rất nhiều phương pháp cài đặt. Nhưng điều gì xảy ra khi có vấn đề phát sinh?
Các câu hỏi luôn nảy sinh - chúng ta chưa tính đến điều gì? Chúng ta chưa làm gì? Những tham số nhân Linux nào được chỉ định không chính xác? Chúa ơi, chúng ta đã đề cập đến họ chưa?! Những thành phần Kubernetes nào chúng tôi đã cung cấp và thành phần nào chưa? Hàng nghìn câu hỏi được đặt ra và để trả lời chúng, bạn cần phải dành 15-20 năm trong ngành này.
Tôi có một ví dụ gần đây về chủ đề này có thể tiết lộ ý nghĩa của vấn đề “Kubernetes có khó bảo trì không?” Cách đây một thời gian, chúng tôi đã nghiêm túc xem xét liệu có nên thử triển khai Cilium dưới dạng mạng trong Kubernetes hay không.
Hãy để tôi giải thích Cilium là gì. Kubernetes có nhiều cách triển khai hệ thống con mạng khác nhau và một trong số đó rất thú vị - Cilium. Ý nghĩa của nó là gì? Trong kernel, cách đây một thời gian, người ta có thể viết các hook cho kernel, bằng cách này hay cách khác xâm chiếm hệ thống con mạng và nhiều hệ thống con khác và cho phép bạn bỏ qua các đoạn lớn trong kernel.
Nhân Linux về mặt lịch sử có định tuyến ip, bộ lọc quá mức, cầu nối và nhiều thành phần cũ khác nhau đã 15, 20, 30 tuổi. Nói chung, họ làm việc, mọi thứ đều tuyệt vời, nhưng bây giờ họ đã chất các thùng chứa lên nhau, trông giống như một tòa tháp gồm 15 viên gạch xếp chồng lên nhau, và bạn đứng trên đó bằng một chân - một cảm giác kỳ lạ. Hệ thống này trong lịch sử đã phát triển với nhiều sắc thái, giống như ruột thừa trong cơ thể. Ví dụ: trong một số trường hợp có vấn đề về hiệu suất.
Có một BPF tuyệt vời và khả năng viết hook cho kernel - những người này đã tự viết hook cho kernel. Gói đi vào nhân Linux, họ lấy nó ra ngay ở đầu vào, tự xử lý nó như bình thường mà không cần cầu nối, không có TCP, không có ngăn xếp IP - nói tóm lại là bỏ qua mọi thứ được ghi trong nhân Linux, rồi nhổ nó ra vào thùng chứa.
Chuyện gì đã xảy ra thế? Hiệu suất rất tuyệt vời, các tính năng thú vị - thật tuyệt vời! Nhưng chúng tôi xem xét điều này và thấy rằng trên mỗi máy có một chương trình kết nối với API Kubernetes và dựa trên dữ liệu mà nó nhận được từ API này, tạo mã C và biên dịch các tệp nhị phân mà nó tải vào kernel để các hook này hoạt động trong không gian hạt nhân.
Điều gì xảy ra nếu có sự cố xảy ra? Chúng tôi không biết. Để hiểu điều này, bạn cần phải đọc tất cả mã này, hiểu tất cả logic và thật ngạc nhiên là nó khó đến mức nào. Tuy nhiên, mặt khác, có những cầu nối, bộ lọc mạng, định tuyến ip - Tôi chưa đọc mã nguồn của chúng và 40 kỹ sư làm việc trong công ty chúng tôi cũng vậy. Có lẽ chỉ một số ít hiểu được một số phần.
Và sự khác biệt là gì? Hóa ra là có ip rout, nhân Linux và có một công cụ mới - nó có gì khác biệt, chúng tôi không hiểu cái này hay cái kia. Nhưng chúng ta sợ sử dụng cái gì đó mới – tại sao? Bởi vì nếu công cụ này đã 30 tuổi, thì trong 30 năm, tất cả các lỗi đã được tìm ra, tất cả các lỗi đã được khắc phục và bạn không cần phải biết về mọi thứ - nó hoạt động như một hộp đen và luôn hoạt động. Mọi người đều biết tuốc nơ vít chẩn đoán nào nên cắm ở vị trí nào, tcpdump nào sẽ chạy vào thời điểm nào. Mọi người đều biết rõ các tiện ích chẩn đoán và hiểu cách bộ thành phần này hoạt động trong nhân Linux - không phải cách thức hoạt động mà là cách sử dụng nó.
Và Cilium cực ngầu chưa phải 30 tuổi đâu, chưa già đâu. Kubernetes cũng gặp vấn đề tương tự. Cilium đó được cài đặt hoàn hảo, Kubernetes đó được cài đặt hoàn hảo, nhưng khi có sự cố xảy ra trong quá trình sản xuất, bạn có thể nhanh chóng hiểu được điều gì đã xảy ra trong tình huống nghiêm trọng không?
Khi chúng tôi nói việc duy trì Kubernetes có khó không - không, nó rất dễ và vâng, nó cực kỳ khó. Kubernetes tự hoạt động rất tốt nhưng có hàng tỷ sắc thái.
Về phương pháp “Tôi sẽ may mắn”
— Có công ty nào mà những sắc thái này gần như chắc chắn sẽ xuất hiện không? Giả sử Yandex đột nhiên chuyển tất cả các dịch vụ sang Kubernetes, thì sẽ có một lượng tải rất lớn ở đó.
Dmitry: Không, đây không phải là cuộc trò chuyện về tải trọng mà là về những điều đơn giản nhất. Ví dụ: chúng tôi có Kubernetes, chúng tôi đã triển khai ứng dụng ở đó. Làm sao bạn biết nó đang hoạt động? Đơn giản là không có công cụ làm sẵn nào để hiểu rằng ứng dụng không bị lỗi. Không có hệ thống làm sẵn để gửi cảnh báo; bạn cần định cấu hình các cảnh báo này và từng lịch trình. Và chúng tôi đang cập nhật Kubernetes.
Tôi có Ubuntu 16.04. Bạn có thể nói rằng đây là phiên bản cũ nhưng chúng tôi vẫn sử dụng nó vì nó là LTS. Có systemd, sắc thái của nó là nó không dọn sạch các nhóm C. Kubernetes khởi chạy các nhóm, tạo nhóm C, sau đó xóa các nhóm và bằng cách nào đó, hóa ra - tôi không nhớ chi tiết, xin lỗi - các lát systemd đó vẫn còn. Điều này dẫn đến thực tế là theo thời gian, bất kỳ chiếc xe nào cũng bắt đầu giảm tốc độ mạnh. Đây thậm chí không phải là một câu hỏi về tải trọng cao. Ví dụ: nếu các nhóm cố định được khởi chạy, nếu có Cron Job liên tục tạo các nhóm, thì máy chạy Ubuntu 16.04 sẽ bắt đầu chậm lại sau một tuần. Sẽ có mức tải trung bình cao liên tục do thực tế là có nhiều nhóm C đã được tạo. Đây là vấn đề mà bất kỳ ai chỉ cài đặt Ubuntu 16 và Kubernetes lên trên sẽ gặp phải.
Giả sử bằng cách nào đó anh ta cập nhật systemd hoặc thứ gì khác, nhưng trong nhân Linux lên tới 4.16, điều đó thậm chí còn buồn cười hơn - khi bạn xóa các nhóm C, chúng sẽ rò rỉ trong kernel và không thực sự bị xóa. Vì vậy, sau một tháng làm việc trên chiếc máy này, sẽ không thể xem được số liệu thống kê về bộ nhớ của các lò sưởi. Chúng tôi lấy một tệp ra, cuộn nó vào chương trình và một tệp cuộn trong 15 giây, vì hạt nhân mất rất nhiều thời gian để đếm một triệu nhóm C bên trong chính nó, dường như đã bị xóa, nhưng không - chúng đang bị rò rỉ .
Ở đây vẫn còn rất nhiều điều nhỏ nhặt như vậy. Đây không phải là vấn đề mà các công ty khổng lồ đôi khi có thể phải đối mặt với gánh nặng rất nặng nề - không, đó là vấn đề thường ngày. Mọi người có thể sống như vậy trong nhiều tháng - họ đã cài đặt Kubernetes, triển khai ứng dụng - nó dường như hoạt động. Đối với nhiều người điều này là bình thường. Họ thậm chí sẽ không biết rằng ứng dụng này sẽ bị lỗi vì lý do nào đó, họ sẽ không nhận được cảnh báo, nhưng đối với họ đây là điều bình thường. Trước đây, chúng tôi sống trên các máy ảo mà không cần giám sát, bây giờ chúng tôi chuyển sang Kubernetes, cũng không cần giám sát - sự khác biệt là gì?
Câu hỏi đặt ra là khi đi trên băng, chúng ta không bao giờ biết được độ dày của nó trừ khi chúng ta đo trước. Nhiều người bước đi và không lo lắng vì họ đã từng bước đi trước đó.
Theo quan điểm của tôi, sắc thái và sự phức tạp của việc vận hành bất kỳ hệ thống nào là đảm bảo rằng độ dày của băng đủ chính xác để giải quyết các vấn đề của chúng ta. Đây là những gì chúng ta đang nói về.
Đối với tôi, có vẻ như trong lĩnh vực CNTT có quá nhiều cách tiếp cận “Tôi sẽ may mắn”. Nhiều người cài đặt phần mềm và sử dụng thư viện phần mềm với hy vọng sẽ gặp may mắn. Nói chung là có nhiều người may mắn. Đó có lẽ là lý do tại sao nó hoạt động.
— Theo đánh giá bi quan của tôi, có vẻ như thế này: khi rủi ro cao và ứng dụng phải hoạt động thì cần có sự hỗ trợ từ Flaunt, có thể từ Red Hat hoặc bạn cần nhóm nội bộ của riêng mình dành riêng cho Kubernetes, đội ngũ này đã sẵn sàng để kéo nó ra.
Dmitry: Khách quan mà nói thì là như vậy. Việc tự mình tham gia vào câu chuyện Kubernetes cho một nhóm nhỏ sẽ tiềm ẩn một số rủi ro.
Chúng ta có cần container không?
— Bạn có thể cho chúng tôi biết Kubernetes phổ biến như thế nào ở Nga không?
Dmitry: Tôi không có dữ liệu này và tôi không chắc ai khác có nó. Chúng tôi nói: “Kubernetes, Kubernetes,” nhưng có một cách khác để xem xét vấn đề này. Tôi cũng không biết mức độ phổ biến của các vùng chứa, nhưng tôi biết một con số từ các báo cáo trên Internet rằng 70% vùng chứa được điều phối bởi Kubernetes. Đó là một nguồn đáng tin cậy cho một mẫu khá lớn trên khắp thế giới.
Sau đó, một câu hỏi khác - chúng ta có cần container không? Cảm nhận cá nhân của tôi và quan điểm chung của công ty Flant là Kubernetes là một tiêu chuẩn trên thực tế.
Sẽ không có gì ngoài Kubernetes.
Đây là một yếu tố thay đổi cuộc chơi tuyệt đối trong lĩnh vực quản lý cơ sở hạ tầng. Chỉ tuyệt đối - thế thôi, không còn Ansible, Chef, máy ảo, Terraform. Tôi không nói về các phương pháp trang trại tập thể cũ. Kubernetes là một sự thay đổi tuyệt đối, và bây giờ nó sẽ chỉ như thế này thôi.
Rõ ràng là đối với một số người phải mất vài năm và đối với những người khác thì phải mất vài thập kỷ để nhận ra điều này. Tôi tin chắc rằng sẽ không có gì ngoài Kubernetes và giao diện mới này: chúng tôi không còn làm hỏng hệ điều hành nữa mà sử dụng cơ sở hạ tầng dưới dạng mã, không chỉ bằng mã mà còn bằng yml - cơ sở hạ tầng được mô tả khai báo. Tôi có cảm giác rằng nó sẽ luôn như thế này.
— Tức là những công ty chưa chuyển sang Kubernetes chắc chắn sẽ chuyển sang nó hoặc chìm vào quên lãng. Tôi hiểu bạn một cách chính xác?
Dmitry: Điều này cũng không hoàn toàn đúng. Ví dụ: nếu chúng ta có nhiệm vụ chạy một máy chủ DNS thì nó có thể chạy trên FreeBSD 4.10 và nó có thể hoạt động hoàn hảo trong 20 năm. Chỉ cần làm việc và thế là xong. Có lẽ trong 20 năm nữa sẽ cần phải cập nhật một cái gì đó. Nếu chúng ta đang nói về phần mềm ở định dạng mà chúng tôi đã phát hành và nó thực sự hoạt động trong nhiều năm mà không có bất kỳ bản cập nhật nào, không thực hiện thay đổi nào, thì tất nhiên sẽ không có Kubernetes. Anh ấy không cần thiết ở đó.
Mọi thứ liên quan đến CI/CD - bất cứ nơi nào cần Phân phối liên tục, nơi bạn cần cập nhật phiên bản, thực hiện các thay đổi tích cực, bất cứ nơi nào bạn cần xây dựng khả năng chịu lỗi - chỉ Kubernetes.
Giới thiệu về microservice
- Ở đây tôi có một sự bất hòa nhỏ. Để làm việc với Kubernetes, bạn cần có sự hỗ trợ từ bên ngoài hoặc nội bộ - đây là điểm đầu tiên. Thứ hai, khi chúng tôi mới bắt đầu phát triển, chúng tôi là một công ty khởi nghiệp nhỏ, chúng tôi chưa có gì cả, việc phát triển Kubernetes hoặc kiến trúc microservice nói chung có thể phức tạp và không phải lúc nào cũng hợp lý về mặt kinh tế. Tôi quan tâm đến ý kiến của bạn - các công ty khởi nghiệp có cần bắt đầu viết ngay từ đầu cho Kubernetes không, hay họ vẫn có thể viết nguyên khối rồi chỉ đến với Kubernetes?
Dmitry: Câu hỏi hay. Tôi có một cuộc nói chuyện về microservice Nhiều lần tôi đã gặp những người đang cố gắng đóng đinh bằng kính hiển vi. Bản thân cách tiếp cận này là đúng; chúng tôi tự thiết kế phần mềm nội bộ của mình theo cách này. Nhưng khi làm điều này, bạn cần hiểu rõ mình đang làm gì. Từ tôi ghét nhất về microservice là “micro”. Trong lịch sử, từ này bắt nguồn từ đó, và không hiểu vì lý do gì mà người ta cho rằng micro rất nhỏ, chưa đến một milimet, giống như micromet. Cái này sai.
Ví dụ: có một khối đá nguyên khối được viết bởi 300 người và tất cả những người tham gia phát triển đều hiểu rằng có vấn đề ở đó và nó nên được chia thành các mảnh nhỏ - khoảng 10 mảnh, mỗi mảnh được viết bởi 30 người ở phiên bản tối thiểu. Điều này quan trọng, cần thiết và tuyệt vời. Nhưng khi một công ty khởi nghiệp đến với chúng tôi, nơi có 3 anh chàng rất ngầu và tài năng đã viết 60 microservice trên đầu gối của họ, mỗi lần tôi tìm Corvalol.
Đối với tôi, có vẻ như điều này đã được nói đến hàng nghìn lần - chúng ta có một khối nguyên khối được phân phối ở dạng này hay dạng khác. Điều này không hợp lý về mặt kinh tế, nói chung là rất khó khăn trong mọi việc. Tôi vừa nhìn thấy điều này nhiều lần đến mức thực sự khiến tôi đau lòng nên tôi tiếp tục nói về nó.
Đối với câu hỏi ban đầu, có một mâu thuẫn giữa thực tế là, một mặt, Kubernetes rất đáng sợ khi sử dụng, vì không rõ điều gì có thể phá vỡ ở đó hoặc không hoạt động, mặt khác, rõ ràng là mọi thứ đều diễn ra ở đó và sẽ không có gì ngoài Kubernetes tồn tại. Trả lời - cân nhắc số lượng lợi ích mang lại, số lượng nhiệm vụ bạn có thể giải quyết. Đây là một mặt của quy mô. Mặt khác, có những rủi ro liên quan đến thời gian ngừng hoạt động hoặc giảm thời gian phản hồi, mức độ sẵn sàng - với việc giảm các chỉ số hiệu suất.
Đây rồi - hoặc là chúng tôi di chuyển nhanh chóng và Kubernetes cho phép chúng tôi thực hiện nhiều việc nhanh hơn và tốt hơn nhiều hoặc chúng tôi sử dụng các giải pháp đáng tin cậy, đã được thử nghiệm theo thời gian nhưng di chuyển chậm hơn nhiều. Đây là sự lựa chọn mà mọi công ty đều phải thực hiện. Bạn có thể coi nó như một con đường trong rừng - khi bạn đi bộ lần đầu tiên, bạn có thể gặp một con rắn, một con hổ hoặc một con lửng điên, và khi bạn đi được 10 lần, bạn đã giẫm phải con đường đó, bị loại bỏ cành cây và đi lại dễ dàng hơn. Mỗi lúc con đường lại rộng hơn. Sau đó là đường nhựa, sau đó là đại lộ tuyệt đẹp.
Kubernetes không đứng yên. Câu hỏi lại: Kubernetes một mặt là 4-5 nhị phân, mặt khác là toàn bộ hệ sinh thái. Đây là hệ điều hành mà chúng tôi có trên máy của mình. Cái này là cái gì? Ubuntu hay Curios? Đây là nhân Linux, một loạt các thành phần bổ sung. Tất cả những thứ này ở đây, một con rắn độc bị ném ra ngoài đường, một hàng rào được dựng lên ở đó. Kubernetes đang phát triển rất nhanh chóng và năng động, khối lượng rủi ro, khối lượng chưa biết đang giảm dần hàng tháng và theo đó, các quy mô này đang được tái cân bằng.
Trả lời câu hỏi một công ty khởi nghiệp nên làm gì, tôi sẽ nói - hãy đến với Flaunt, trả 150 nghìn rúp và nhận dịch vụ chìa khóa trao tay DevOps dễ dàng. Nếu bạn là một công ty khởi nghiệp nhỏ với một vài nhà phát triển, điều này sẽ hiệu quả. Thay vì thuê DevOps của riêng bạn, những người sẽ cần học cách giải quyết vấn đề của bạn và trả lương vào thời điểm này, bạn sẽ nhận được giải pháp chìa khóa trao tay cho mọi vấn đề. Vâng, có một số nhược điểm. Chúng tôi, với tư cách là người đăng việc, không thể tham gia và phản ứng nhanh chóng với những thay đổi. Nhưng chúng tôi có rất nhiều kiến thức chuyên môn và các phương pháp thực hành sẵn có. Chúng tôi đảm bảo rằng trong mọi tình huống, chúng tôi chắc chắn sẽ nhanh chóng tìm ra và hồi sinh bất kỳ Kubernetes nào từ cõi chết.
Tôi thực sự khuyên bạn nên thuê ngoài cho các công ty khởi nghiệp và các doanh nghiệp đã thành lập với quy mô mà bạn có thể dành một nhóm 10 người để vận hành, vì nếu không thì chẳng ích gì. Việc thuê ngoài việc này chắc chắn có ý nghĩa.
Giới thiệu về Amazon và Google
— Máy chủ từ giải pháp của Amazon hoặc Google có thể được coi là nguồn bên ngoài không?
Dmitry: Vâng, tất nhiên, điều này giải quyết được một số vấn đề. Nhưng một lần nữa có những sắc thái. Bạn vẫn cần phải hiểu cách sử dụng nó. Ví dụ: có hàng nghìn việc nhỏ nhặt trong công việc của Amazon AWS: Load Balancer cần được khởi động hoặc phải viết trước một yêu cầu rằng “các bạn ơi, chúng tôi sẽ nhận được lưu lượng truy cập, hãy khởi động Load Balancer cho chúng tôi!” Bạn cần biết những sắc thái này.
Khi bạn tìm đến những người chuyên về lĩnh vực này, bạn sẽ gần như đóng được tất cả những thứ điển hình. Hiện chúng tôi có 40 kỹ sư, đến cuối năm chắc chắn sẽ có 60 - chúng tôi chắc chắn đã gặp phải tất cả những điều này. Ngay cả khi gặp lại vấn đề này trong dự án nào đó, chúng tôi cũng nhanh chóng hỏi thăm nhau và biết cách giải quyết.
Có lẽ câu trả lời là - tất nhiên, một câu chuyện được lưu trữ trên máy chủ sẽ khiến một số phần trở nên dễ dàng hơn. Câu hỏi đặt ra là liệu bạn có sẵn sàng tin tưởng những nhà cung cấp dịch vụ lưu trữ này hay không và liệu họ có giải quyết được vấn đề của bạn hay không. Amazon và Google đã làm rất tốt. Đối với tất cả các trường hợp của chúng tôi - chính xác. Chúng tôi không có bất kỳ kinh nghiệm tích cực hơn. Tất cả các đám mây khác mà chúng tôi cố gắng làm việc đều tạo ra rất nhiều vấn đề - Ager, và mọi thứ ở Nga, cũng như tất cả các loại OpenStack trong các triển khai khác nhau: Headster, Overage - bất cứ điều gì bạn muốn. Tất cả đều tạo ra những vấn đề mà bạn không muốn giải quyết.
Do đó, câu trả lời là có, nhưng trên thực tế, không có nhiều giải pháp lưu trữ hoàn thiện.
Ai cần Kubernetes?
— Chưa hết, ai cần Kubernetes? Ai nên chuyển sang Kubernetes, khách hàng Flaunt điển hình dành riêng cho Kubernetes là ai?
Dmitry: Đây là một câu hỏi thú vị, bởi vì hiện tại, sau Kubernetes, nhiều người đã đến gặp chúng tôi: “Các bạn, chúng tôi biết rằng các bạn đang làm Kubernetes, hãy làm điều đó cho chúng tôi!” Chúng tôi trả lời họ: “Các quý ông, chúng tôi không làm Kubernetes, chúng tôi làm sản phẩm và mọi thứ liên quan đến nó.” Bởi vì hiện tại đơn giản là không thể tạo ra một sản phẩm nếu không thực hiện tất cả CI/CD và toàn bộ câu chuyện này. Mọi người đã rời xa sự phân chia mà chúng ta phát triển theo phát triển, rồi bóc lột bằng bóc lột.
Khách hàng của chúng tôi mong đợi những điều khác nhau, nhưng mọi người đều mong đợi một điều kỳ diệu nào đó khi họ gặp phải một số vấn đề nhất định, và bây giờ - hy vọng! — Kubernetes sẽ giải quyết chúng. Người ta tin vào phép lạ. Trong tâm trí họ hiểu rằng sẽ không có phép màu nào, nhưng trong tâm hồn họ hy vọng - điều gì sẽ xảy ra nếu Kubernetes này bây giờ giải quyết mọi thứ cho chúng ta, họ nói rất nhiều về nó! Đột nhiên anh bây giờ - hắt hơi! - và một viên đạn bạc, hắt hơi! — và chúng tôi có 100% thời gian hoạt động, tất cả các nhà phát triển có thể phát hành bất cứ thứ gì được đưa vào sản xuất 50 lần và nó không gặp sự cố. Nói chung, một phép lạ!
Khi những người như vậy đến với chúng ta, chúng ta nói: “Xin lỗi, nhưng chẳng có gì gọi là phép lạ cả”. Để khỏe mạnh, bạn cần ăn uống đầy đủ và tập thể dục. Để có một sản phẩm đáng tin cậy, nó cần phải được sản xuất một cách đáng tin cậy. Để có CI/CD tiện lợi, bạn cần làm nó như thế này. Đó là rất nhiều công việc cần phải được thực hiện.
Trả lời câu hỏi ai cần Kubernetes - không ai cần Kubernetes.
Một số người có quan niệm sai lầm rằng họ cần Kubernetes. Mọi người cần, họ có một nhu cầu sâu sắc là ngừng suy nghĩ, nghiên cứu và quan tâm đến tất cả các vấn đề về cơ sở hạ tầng cũng như vấn đề chạy các ứng dụng của họ. Họ muốn các ứng dụng chỉ hoạt động và triển khai. Đối với họ, Kubernetes là niềm hy vọng rằng họ sẽ ngừng nghe câu chuyện “chúng tôi đang nằm đó” hoặc “chúng tôi không thể lăn ra ngoài” hay điều gì khác.
Giám đốc kỹ thuật thường đến với chúng tôi. Họ hỏi anh ấy hai điều: một mặt, cung cấp cho chúng tôi các tính năng, mặt khác là sự ổn định. Chúng tôi khuyên bạn nên tự mình thực hiện và thực hiện. Viên đạn bạc, hay đúng hơn là mạ bạc, là bạn sẽ ngừng suy nghĩ về những vấn đề này và lãng phí thời gian. Bạn sẽ có những người đặc biệt sẽ kết thúc vấn đề này.
Cách diễn đạt mà chúng tôi hoặc bất kỳ ai khác cần Kubernetes là không chính xác.
Quản trị viên thực sự cần Kubernetes, vì đây là một món đồ chơi rất thú vị mà bạn có thể chơi và mày mò. Hãy thành thật mà nói - mọi người đều thích đồ chơi. Tất cả chúng ta đều là những đứa trẻ ở đâu đó và khi nhìn thấy một trò chơi mới, chúng ta muốn chơi nó. Đối với một số người, điều này đã không được khuyến khích, chẳng hạn như trong ban quản lý, vì họ đã chơi đủ rồi và đã mệt đến mức không muốn chơi nữa. Nhưng điều này không hoàn toàn bị mất vào tay bất cứ ai. Ví dụ, tôi đã chán đồ chơi trong lĩnh vực quản trị hệ thống và DevOps từ lâu rồi, nhưng tôi vẫn thích đồ chơi, tôi vẫn mua vài cái mới. Tất cả mọi người, bằng cách này hay cách khác, vẫn muốn có một loại đồ chơi nào đó.
Không cần phải chơi với sản xuất. Bất cứ điều gì tôi khuyên bạn không nên làm và những gì tôi thấy bây giờ: "Ồ, một món đồ chơi mới!" - các em chạy đi mua, mua và: “Bây giờ chúng ta hãy mang nó đến trường và khoe với tất cả bạn bè của chúng ta.” Đừng làm điều này. Tôi xin lỗi, các con tôi mới lớn, tôi liên tục nhìn thấy điều gì đó ở trẻ, nhận thấy điều đó ở bản thân mình rồi khái quát cho người khác.
Câu trả lời cuối cùng là: bạn không cần Kubernetes. Bạn cần giải quyết vấn đề của mình.
Những gì bạn có thể đạt được là:
- sản phẩm không rơi;
- ngay cả khi anh ta cố gắng ngã, chúng ta biết trước về điều đó và chúng ta có thể đặt thứ gì đó vào đó;
- chúng ta có thể thay đổi nó theo tốc độ mà công việc kinh doanh của chúng ta yêu cầu và chúng ta có thể thực hiện nó một cách thuận tiện, nó không gây ra bất kỳ vấn đề gì cho chúng ta.
Có hai nhu cầu thực sự: độ tin cậy và tính năng động/linh hoạt khi triển khai. Tất cả những người hiện đang thực hiện một số loại dự án CNTT, bất kể thuộc loại hình kinh doanh nào - mềm mại để nới lỏng thế giới và ai hiểu được điều này, đều cần phải giải quyết những nhu cầu này. Kubernetes với cách tiếp cận phù hợp, với sự hiểu biết đúng đắn và có đủ kinh nghiệm sẽ cho phép bạn giải quyết chúng.
Giới thiệu về không có máy chủ
— Nếu bạn nhìn xa hơn một chút về tương lai, sau đó cố gắng giải quyết vấn đề không còn đau đầu với cơ sở hạ tầng, với tốc độ triển khai và tốc độ thay đổi ứng dụng, các giải pháp mới sẽ xuất hiện, chẳng hạn như serverless. Bạn có cảm thấy bất kỳ tiềm năng nào theo hướng này không và giả sử, mối nguy hiểm cho Kubernetes và các giải pháp tương tự không?
Dmitry: Ở đây chúng ta cần phải nhận xét lại rằng tôi không phải là người nhìn thấy trước và nói - mọi chuyện sẽ như thế này! Mặc dù tôi chỉ làm điều tương tự. Tôi nhìn vào chân mình và thấy ở đó có rất nhiều vấn đề, chẳng hạn như cách hoạt động của bóng bán dẫn trong máy tính. Thật buồn cười phải không? Chúng tôi đang gặp một số lỗi trong CPU.
Làm cho serverless khá đáng tin cậy, rẻ, hiệu quả và thuận tiện, giải quyết mọi vấn đề của hệ sinh thái. Ở đây tôi đồng ý với Elon Musk rằng cần có hành tinh thứ hai để tạo ra khả năng chịu lỗi cho nhân loại. Mặc dù tôi không biết anh ấy đang nói gì nhưng tôi hiểu rằng tôi chưa sẵn sàng tự mình bay lên sao Hỏa và điều đó sẽ không xảy ra vào ngày mai.
Với serverless, rõ ràng đây là một điều đúng đắn về mặt ý thức hệ, giống như khả năng chịu lỗi đối với nhân loại - có hai hành tinh thì tốt hơn một. Nhưng làm thế nào để làm điều đó bây giờ? Gửi một chuyến thám hiểm không phải là vấn đề nếu bạn tập trung nỗ lực vào nó. Tôi nghĩ việc gửi một số đoàn thám hiểm và định cư hàng nghìn người ở đó cũng là thực tế. Nhưng để làm cho nó hoàn toàn có khả năng chịu lỗi để một nửa nhân loại sống ở đó, đối với tôi bây giờ dường như là không thể, chưa được xem xét.
Với máy chủ trực tiếp: mọi thứ thật tuyệt, nhưng nó khác xa với những vấn đề của năm 2019. Gần đến năm 2030 - hãy sống để thấy điều đó. Tôi tin chắc rằng chúng ta sẽ sống, chúng ta chắc chắn sẽ sống (lặp lại trước khi đi ngủ), nhưng bây giờ chúng ta cần giải quyết những vấn đề khác. Giống như tin vào câu chuyện cổ tích về chú ngựa cầu vồng. Đúng, một vài phần trăm trường hợp đã được giải quyết và chúng được giải quyết một cách hoàn hảo, nhưng về mặt chủ quan, serverless là một cầu vồng... Đối với tôi, chủ đề này quá xa vời và quá khó hiểu. Tôi chưa sẵn sàng để nói chuyện. Vào năm 2019, bạn không thể viết một ứng dụng duy nhất mà không có máy chủ.
Kubernetes sẽ phát triển như thế nào
— Khi chúng ta hướng tới tương lai xa đầy tiềm năng tuyệt vời này, bạn nghĩ Kubernetes và hệ sinh thái xung quanh nó sẽ phát triển như thế nào?
Dmitry: Tôi đã suy nghĩ về điều này rất nhiều và tôi đã có câu trả lời rõ ràng. Đầu tiên là trạng thái đầy đủ - xét cho cùng, không trạng thái sẽ dễ thực hiện hơn. Kubernetes ban đầu đầu tư nhiều hơn vào việc này, tất cả đều bắt đầu từ đó. Không trạng thái hoạt động gần như hoàn hảo trong Kubernetes, không có gì phải phàn nàn. Vẫn còn rất nhiều vấn đề, hay nói đúng hơn là các sắc thái. Mọi thứ ở đó đều rất tốt cho chúng tôi, nhưng đó là chúng tôi. Sẽ phải mất ít nhất vài năm nữa để điều này có hiệu quả với tất cả mọi người. Đây không phải là một chỉ số được tính toán mà là cảm nhận từ đầu của tôi.
Nói tóm lại, statefull nên - và sẽ - phát triển rất mạnh mẽ, bởi vì tất cả các ứng dụng của chúng tôi đều lưu trữ trạng thái; không có ứng dụng không trạng thái nào. Đây chỉ là ảo tưởng; bạn luôn cần một loại cơ sở dữ liệu nào đó và thứ gì đó khác. Statefull nói về việc giải quyết mọi thứ có thể, sửa tất cả các lỗi, cải thiện tất cả các vấn đề hiện đang gặp phải - hãy gọi đó là việc áp dụng.
Mức độ chưa biết, mức độ vấn đề chưa được giải quyết, mức độ xác suất gặp phải điều gì đó sẽ giảm đi đáng kể. Đây là một câu chuyện quan trọng. Và các toán tử - mọi thứ liên quan đến mã hóa logic quản trị, logic điều khiển để có được một dịch vụ dễ dàng: Dịch vụ dễ dàng MySQL, dịch vụ dễ dàng RabbitMQ, dịch vụ dễ dàng Memcache - nói chung, tất cả các thành phần này mà chúng ta cần được đảm bảo hoạt động tốt cái hộp. Điều này chỉ giải quyết nỗi đau mà chúng ta muốn có cơ sở dữ liệu nhưng lại không muốn quản lý nó hoặc chúng ta muốn Kubernetes nhưng lại không muốn quản lý nó.
Câu chuyện phát triển nhà điều hành dưới hình thức này hay hình thức khác sẽ rất quan trọng trong vài năm tới.
Tôi nghĩ sự dễ sử dụng sẽ tăng lên rất nhiều - hộp sẽ ngày càng đen hơn, chắc chắn hơn, với nhiều nút bấm đơn giản hơn.
Tôi đã từng nghe một cuộc phỏng vấn cũ với Isaac Asimov từ những năm 80 trên YouTube trên Saturday Night Live - một chương trình giống như Urgant, chỉ thú vị thôi. Họ hỏi anh về tương lai của máy tính. Anh ấy nói rằng tương lai nằm ở sự đơn giản, giống như chiếc radio. Máy thu thanh ban đầu là một thứ phức tạp. Để bắt được sóng, bạn phải vặn núm trong 15 phút, vặn xiên và nói chung là biết mọi thứ hoạt động như thế nào, hiểu nguyên lý vật lý của việc truyền sóng vô tuyến. Kết quả là chiếc radio chỉ còn lại một núm xoay.
Bây giờ vào năm 2019 đài nào? Trong ô tô, máy thu sóng sẽ tìm thấy tất cả các sóng và tên các đài. Tính chất vật lý của quá trình này không thay đổi trong 100 năm qua, nhưng tính dễ sử dụng thì có. Bây giờ, và không chỉ bây giờ, ngay cả vào năm 1980, khi có cuộc phỏng vấn với Azimov, mọi người đều sử dụng radio và không ai nghĩ về cách nó hoạt động. Nó luôn hoạt động - đó là điều hiển nhiên.
Azimov sau đó nói rằng điều đó cũng tương tự với máy tính - dễ sử dụng sẽ tăng lên. Mặc dù vào năm 1980 bạn phải được đào tạo cách bấm nút trên máy tính nhưng điều đó sẽ không xảy ra trong tương lai.
Tôi có cảm giác rằng với Kubernetes và cơ sở hạ tầng, tính dễ sử dụng cũng sẽ tăng lên rất nhiều. Theo tôi, điều này là hiển nhiên - nó nằm trên bề mặt.
Làm gì với kỹ sư?
— Điều gì sẽ xảy ra với các kỹ sư và quản trị viên hệ thống hỗ trợ Kubernetes?
Dmitry: Điều gì đã xảy ra với nhân viên kế toán sau sự ra đời của 1C? Về như nhau. Trước đó, họ đếm trên giấy - hiện đã có trong chương trình. Năng suất lao động đã tăng lên rất nhiều, nhưng bản thân lao động vẫn không biến mất. Nếu trước đây phải mất 10 kỹ sư để vặn một bóng đèn thì bây giờ chỉ cần một người là đủ.
Đối với tôi, có vẻ như số lượng phần mềm và số lượng nhiệm vụ hiện đang tăng với tốc độ nhanh hơn tốc độ DevOps mới xuất hiện và hiệu quả ngày càng tăng. Hiện tại trên thị trường đang có một sự thiếu hụt cụ thể và nó sẽ kéo dài trong một thời gian dài. Sau đó, mọi thứ sẽ trở lại trạng thái bình thường nào đó, trong đó hiệu quả công việc sẽ tăng lên, ngày càng có nhiều máy chủ không có máy chủ, một nơ-ron sẽ được gắn vào Kubernetes, nó sẽ chọn tất cả các tài nguyên chính xác khi cần thiết và nói chung sẽ tự mình làm mọi thứ như lẽ ra phải làm - người đó chỉ cần bước đi và không can thiệp.
Nhưng ai đó vẫn sẽ cần phải đưa ra quyết định. Rõ ràng trình độ chuyên môn, chuyên môn của người này cao hơn. Ngày nay, ở bộ phận kế toán, không cần tới 10 nhân viên ghi sổ để khỏi mỏi tay. Nó đơn giản là không cần thiết. Nhiều tài liệu được hệ thống quản lý tài liệu điện tử tự động quét và nhận dạng. Một kế toán trưởng thông minh là đủ, có kỹ năng cao hơn nhiều, có hiểu biết tốt.
Nói chung đây là con đường nên đi trong mọi ngành nghề. Ô tô cũng vậy: trước đây, một chiếc ô tô có một thợ cơ khí và ba người lái xe. Ngày nay, lái ô tô là một quá trình đơn giản mà tất cả chúng ta đều tham gia hàng ngày. Không ai nghĩ rằng một chiếc ô tô là một cái gì đó phức tạp.
DevOps hoặc kỹ thuật hệ thống sẽ không biến mất - công việc cấp cao và hiệu quả sẽ tăng lên.
— Tôi cũng nghe được một ý tưởng thú vị rằng công việc sẽ thực sự tăng lên.
Dmitry: Tất nhiên là một trăm phần trăm! Bởi vì số lượng phần mềm chúng tôi viết không ngừng tăng lên. Số lượng vấn đề chúng tôi giải quyết bằng phần mềm không ngừng tăng lên. Khối lượng công việc ngày càng tăng. Bây giờ thị trường DevOps đang quá nóng. Điều này có thể được nhìn thấy trong mức lương mong đợi. Nói một cách hay, không đi sâu vào chi tiết thì nên có đàn em muốn X, trung cấp muốn 1,5X và đàn anh muốn 2X. Và bây giờ, nếu bạn nhìn vào thị trường lương DevOps ở Moscow, một cấp dưới muốn từ X lên 3X và một cấp cao muốn từ X lên 3X.
Không ai biết nó có giá bao nhiêu. Mức lương được đo bằng sự tự tin của bạn - thành thật mà nói, hoàn toàn là một nhà thương điên, một thị trường quá nóng.
Tất nhiên, tình trạng này sẽ sớm thay đổi - sự bão hòa nào đó sẽ xảy ra. Điều này không xảy ra với phát triển phần mềm - mặc dù thực tế là mọi người đều cần nhà phát triển và mọi người đều cần nhà phát triển giỏi, thị trường hiểu ai xứng đáng - ngành công nghiệp đã ổn định. Đó không phải là trường hợp của DevOps ngày nay.
— Từ những gì tôi nghe được, tôi kết luận rằng quản trị viên hệ thống hiện tại không nên lo lắng quá nhiều, nhưng đã đến lúc phải nâng cấp kỹ năng của mình và chuẩn bị cho thực tế là ngày mai sẽ có nhiều công việc hơn nhưng sẽ có trình độ cao hơn.
Dmitry: Một trăm phần trăm. Nói chung, chúng ta đang sống trong năm 2019 và quy luật của cuộc sống là thế này: học tập suốt đời - chúng ta học suốt đời. Đối với tôi, dường như bây giờ mọi người đều đã biết và cảm nhận được điều này, nhưng chỉ biết thôi là chưa đủ - bạn phải làm điều đó. Mỗi ngày chúng ta phải thay đổi. Nếu không làm được điều này thì sớm muộn gì chúng ta cũng sẽ bị đẩy ra bên lề nghề nghiệp.
Hãy chuẩn bị cho những bước ngoặt 180 độ sắc nét. Tôi không loại trừ trường hợp một cái gì đó thay đổi hoàn toàn, một cái gì đó mới được phát minh - nó xảy ra. Nhảy lò cò! - và bây giờ chúng ta hành động khác đi. Điều quan trọng là phải chuẩn bị cho việc này và đừng lo lắng. Có thể xảy ra rằng ngày mai mọi thứ tôi làm sẽ trở nên không cần thiết - không có gì, tôi đã học cả đời và sẵn sàng học thứ khác. Không vấn đề gì. Không cần phải lo sợ về sự đảm bảo trong công việc, nhưng bạn cần phải chuẩn bị sẵn sàng để không ngừng học hỏi những điều mới mẻ.
Lời chúc và một phút quảng cáo
- Cậu có mong muốn gì không?
Dmitry: Vâng, tôi có một vài điều ước.
Đầu tiên và thương mại - đăng ký . Các độc giả thân mến, hãy truy cập YouTube và đăng ký kênh của chúng tôi. Trong khoảng một tháng nữa, chúng tôi sẽ bắt đầu tích cực mở rộng dịch vụ video. Chúng tôi sẽ có rất nhiều nội dung giáo dục về Kubernetes, mở và đa dạng: từ những điều thực tế, cho đến phòng thí nghiệm, đến những điều lý thuyết cơ bản sâu sắc và cách sử dụng Kubernetes tại mức độ của các nguyên tắc và mô hình.
Điều ước thương mại thứ hai - đi tới và đặt các ngôi sao vì chúng ta ăn chúng. Nếu bạn không cho chúng tôi ngôi sao, chúng tôi sẽ không có gì để ăn. Nó giống như mana trong một trò chơi trên máy tính. Chúng tôi làm điều gì đó, chúng tôi làm, chúng tôi cố gắng, có người nói rằng đây là những chiếc xe đạp khủng khiếp, có người cho rằng mọi thứ hoàn toàn sai, nhưng chúng tôi vẫn tiếp tục và hành động hoàn toàn trung thực. Chúng tôi nhìn thấy một vấn đề, giải quyết nó và chia sẻ kinh nghiệm của chúng tôi. Vì vậy, hãy cho chúng tôi một ngôi sao, nó sẽ không rời xa bạn mà sẽ đến với chúng tôi vì chúng tôi ăn chúng.
Mong muốn thứ ba, quan trọng và không còn mang tính thương mại - ngừng tin vào truyện cổ tích. Bạn là những người chuyên nghiệp. DevOps là một nghề rất nghiêm túc và có trách nhiệm. Dừng chơi ở nơi làm việc. Hãy để nó nhấp vào cho bạn và bạn sẽ hiểu nó. Hãy tưởng tượng rằng bạn đến bệnh viện và ở đó bác sĩ đang thử nghiệm trên bạn. Tôi hiểu rằng điều này có thể gây khó chịu cho ai đó, nhưng rất có thể, đây không phải là về bạn mà là về người khác. Hãy bảo người khác cũng dừng lại. Điều này thực sự hủy hoại cuộc sống của tất cả chúng ta - nhiều người bắt đầu coi các hoạt động, quản trị viên và DevOps như những kẻ đã phá vỡ thứ gì đó một lần nữa. Điều này thường bị "hỏng" nhất là do chúng tôi đi chơi và không có ý thức lạnh lùng rằng mọi chuyện là như vậy và nó là như vậy.
Điều này không có nghĩa là bạn không nên thử nghiệm. Chúng ta cần thử nghiệm, chúng ta tự mình làm điều đó. Thành thật mà nói, bản thân chúng ta đôi khi cũng chơi game - điều này tất nhiên là rất tệ, nhưng không có gì con người là xa lạ với chúng ta. Hãy tuyên bố năm 2019 là một năm của những thử nghiệm nghiêm túc, được cân nhắc kỹ lưỡng chứ không phải những trò chơi được sản xuất. Có lẽ vậy.
- Cảm ơn rất nhiều!
Dmitry: Cảm ơn Vitaly, cả về thời gian và cuộc phỏng vấn. Các độc giả thân mến, xin cảm ơn rất nhiều nếu bạn đột nhiên đạt đến điểm này. Tôi hy vọng rằng chúng tôi đã mang lại cho bạn ít nhất một vài suy nghĩ.
Trong cuộc phỏng vấn, Dmitry đã đề cập đến vấn đề Werf. Bây giờ đây là một con dao Thụy Sĩ phổ quát có thể giải quyết được hầu hết mọi vấn đề. Nhưng nó không phải lúc nào cũng như vậy. TRÊN tại lễ hội Dmitry Stolyarov sẽ cho bạn biết chi tiết về công cụ này. trong báo cáo sẽ có tất cả mọi thứ: các vấn đề và sắc thái tiềm ẩn của Kubernetes, các tùy chọn để giải quyết những khó khăn này và cách triển khai werf hiện tại một cách chi tiết. Hãy tham gia cùng chúng tôi vào ngày 27 và 28 tháng XNUMX, chúng tôi sẽ tạo ra những công cụ hoàn hảo.
Nguồn: www.habr.com