期待中 維塔利·哈巴羅夫 受訪 德米特里·斯托利亞羅夫 (），Flant 公司技術總監兼共同創辦人。 Vitaly 向 Dmitry 詢問了 Flant 的業務、Kubernetes、生態系統開發和支援。 我們討論了為什麼需要 Kubernetes 以及是否需要它。 還有微服務、Amazon AWS、DevOps 的「我會很幸運」的方法、Kubernetes 本身的未來、它為何、何時以及如何接管世界、DevOps 的前景以及工程師在未來應該做好哪些準備。簡化和神經網路的光明和不久的將來。
收聽 DevOps Deflop 上的播客 - 關於 DevOps 的俄語播客，以下是文字版本。
他在這裡和下面提出問題 Express42 的工程師。
關於“芙蘭特”
- 你好迪瑪。 你是技術總監””，也是它的創始人。 請告訴我們公司是做什麼的以及你在裡面做什麼？
德米特里：從外面看，我們似乎是為每個人安裝 Kubernetes 並用它做一些事情的人。 但事實並非如此。 我們最初是一家處理 Linux 的公司，但很長一段時間以來，我們的主要活動一直是為生產和高負載交鑰匙專案提供服務。 通常我們從頭開始建立整個基礎設施，然後在很長一段時間內對其負責。 因此，「Flant」主要從事的、獲得資金的工作是 承擔責任，實施統包生產.
我作為公司的技術總監和創始人之一，日以繼夜地思考如何提高生產的可訪問性，簡化其操作，讓管理員的生活更輕鬆，讓開發人員的生活更愉快。
關於庫伯內特斯
— 最近我看到了很多來自 Flant 和 關於 Kubernetes。 你是怎麼想到的？
德米特里: 我已經說過很多次了，但我不介意重複一遍。 我認為重複這個話題是正確的，因為因果關係有混淆。
我們確實需要一個工具。 我們遇到了很多問題，掙扎著，用各種拐杖克服了它們，並感到需要一種工具。 我們經歷了許多不同的選擇，建造了自己的自行車，並累積了經驗。 漸漸地，我們幾乎在 Docker 一出現的時候就開始使用它了——大約在 2013 年。 在它出現的時候，我們已經有了很多容器方面的經驗，我們已經用 Python 編寫了一個類似「Docker」的東西——我們自己的一些拐杖。 隨著 Docker 的出現，人們可以丟掉拐杖，使用可靠且社群支持的解決方案。
Kubernetes 的情況也類似。 當它開始獲得動力時——對我們來說這是 1.2 版本——我們已經在 Shell 和 Chef 上有了一堆拐杖，我們以某種方式嘗試用 Docker 來協調它們。 我們認真地尋找 Rancher 和各種其他解決方案，但後來 Kubernetes 出現了，其中一切的實現都與我們完全一樣，甚至更好。 沒有什麼好抱怨的。
是的，這裡有某種不完美，那裡有某種不完美- 有很多不完美，1.2 一般都很糟糕，但是...... Kubernetes 就像一座正在建設中的建築- 你看看這個項目就明白了這會很酷。 如果建築物現在有地基和兩層樓，那麼您明白最好不要搬進去，但該軟體不存在此類問題 - 您已經可以使用它了。
我們沒有考慮過要不要使用 Kubernetes。 在它出現之前我們就一直在等待它，並嘗試自己創建類似物。
關於庫伯內特斯
— 您直接參與了 Kubernetes 本身的開發嗎？
德米特里: 平庸。 相反，我們參與生態系的發展。 我們發送一定數量的拉取請求：發送給 Prometheus、發送給各個操作員、發送給 Helm - 發送給生態系統。 不幸的是，我無法追蹤我們所做的一切，我可能是錯的，但我們沒有一個池進入核心。
— 同時，您是否圍繞 Kubernetes 開發了許多工具？
德米特里：策略是這樣的：我們去向所有已經存在的東西拉取請求。 如果拉取請求在那裡不被接受，我們只需自己分叉它們並生存，直到它們被我們的構建接受。 然後，當它到達上游時，我們回到上游版本。
例如，我們有一個 Prometheus 操作符，我們用它來回切換到組件的上游可能已經有 5 次了。 我們需要某種功能，我們發送了拉取請求，我們需要明天推出它，但我們不想等待它在上游發布。 因此，我們為自己組裝，將具有我們出於某種原因需要的功能的組裝推出到我們的所有集群。 然後，例如，他們將其移交給上游的我們，並說：“夥計們，讓我們來做一個更一般的情況”，我們或其他人完成它，隨著時間的推移，它會再次合併回來。
我們嘗試開發現有的一切。 許多還不存在、尚未發明、或已經發明但還沒有時間實現的元素——我們正在做。 不是因為我們喜歡自行車製造這個產業，而是因為我們需要這個工具。 人們常問這樣的問題：我們為什麼要做這件事或那件事？ 答案很簡單 - 是的，因為我們必須走得更遠，解決一些實際問題，我們用這個圖拉解決了它。
路徑總是這樣的：我們非常仔細地搜索，如果我們找不到任何關於如何用一條麵包製作無軌電車的解決方案，那麼我們就製作我們自己的麵包和我們自己的無軌電車。
弗蘭達工具
— 我知道 Flant 現在有外掛程式運算符、shell 運算子和 dapp/werf 工具。 據我了解，這是同一種樂器的不同化身。 我還了解到 Flaunt 中還有更多不同的工具。 這是真實的？
德米特里：我們在 GitHub 上還有更多內容。 據我所知，我們有一個狀態圖 - 每個人都遇到的 Grafana 面板。 Medium 上幾乎每兩篇關於 Kubernetes 監控的文章都會提到它。 不可能簡單地解釋一下狀態圖是什麼——它需要一篇單獨的文章，但它對於監控一段時間內的狀態非常有用，因為在 Kubernetes 中我們經常需要顯示一段時間內的狀態。 我們還有 LogHouse - 這是一個基於 ClickHouse 和黑魔法的東西，用於在 Kubernetes 中收集日誌。
很多實用程式！ 而且還會更多，因為今年將會發布一些內部解決方案。 在基於插件操作符的非常大的插件中，有很多用於Kubernetes 的插件，以及如何正確安裝sert manager - 一個用於管理證書的工具，如何使用一堆附件正確安裝Prometheus - 這些大約有二十種不同的插件導出資料和收集某些東西的二進位文件，普羅米修斯擁有最令人驚嘆的圖形和警報。 所有這一切只是 Kubernetes 的一堆插件，安裝在叢集中，它從簡單變成了酷、複雜、自動化，其中許多問題已經解決。 是的，我們做了很多。
生態系發展
“在我看來，這對這種儀器及其使用方法的發展做出了非常大的貢獻。” 您能粗略估計還有誰會對生態系的發展有同樣的貢獻嗎？
德米特里: 在俄羅斯，在我們市場上營運的公司中，沒有一家可以與之相媲美。 當然，這是一個響亮的聲明，因為有像 Mail 和 Yandex 這樣的主要參與者 - 他們也在利用 Kubernetes 做一些事情，但即使他們也無法與全世界比我們做得更多的公司的貢獻相提並論。 如果我沒記錯的話，很難將擁有 80 名員工的 Flant 和僅每個 Kubernetes 就有 300 名工程師的 Red Hat 進行比較。 很難比較。 我們研發部門有 6 個人，包括我在內，他們削減了我們所有的工具。 6 名紅帽工程師與 300 名紅帽工程師 - 這在某種程度上很難進行比較。
- 然而，當這 6 個人能夠做一些真正有用且令人疏遠的事情時，當他們面臨實際問題並向社區提供解決方案時 - 一個有趣的案例。 據我了解，在大型科技公司中，他們有自己的 Kubernetes 開發和支援團隊，原則上可以開發相同的工具。 對他們來說，這是一個可以開發並提供給社群的範例，為使用 Kubernetes 的整個社群提供動力。
德米特里：這可能是積分器的一個特點，它的特殊性。 我們有很多項目，我們看到很多不同的情況。 對我們來說，創造附加價值的主要方法是分析這些案例，找到共通點並讓它們盡可能便宜地為我們服務。 我們正在積極致力於此。 我很難談論俄羅斯和世界，但我們公司有大約 40 名 DevOps 工程師從事 Kubernetes 工作。 我認為俄羅斯沒有太多公司擁有同等數量的了解 Kubernetes 的專家（如果有的話）。
關於DevOps工程師這個職位我什麼都懂，大家都懂，也習慣稱DevOps工程師為DevOps工程師，這個我們就不討論了。 所有這 40 位出色的 DevOps 工程師每天都會面臨並解決問題，我們只是分析這些經驗並嘗試概括。 我們知道，如果它留在我們體內，那麼在一兩年內該工具將毫無用處，因為在社區的某個地方，一個現成的圖拉將會出現。 在內部累積這些經驗是沒有意義的——它只是將精力和時間消耗到 dev/null 中。 我們對此一點也不感到遺憾。 我們非常高興地發布一切，並且明白它需要發布、開發、推廣、推廣，以便人們使用它並添加他們的經驗 - 然後一切都會生長和生存。 兩年後，儀器不會被丟進垃圾桶。 繼續傾注力量並不可惜，因為很明顯有人在使用你的工具，而且兩年後每個人都在使用它。
這是我們 dapp/werf 大策略的一部分。 我不記得我們什麼時候開始製作的，好像是三年前了。 最初，它通常位於外殼上。 這是一個超級概念證明，我們解決了一些特殊問題 - 它有效！ 但是shell有問題，不可能再進一步擴展，在shell上程式設計是另一項任務。 我們有用 Ruby 編寫的習慣，因此，我們用 Ruby 重新製作了一些東西，開發、開發、開發，然後遇到了這樣一個事實：社區、人群不會說“我們想要它或我們不想要它， ” 對Ruby 嗤之以鼻，這有多有趣？ 我們意識到我們應該用 Go 編寫所有這些內容只是為了滿足清單上的第一點： DevOps 工具應該是靜態二進位文件。 是否成為 Go 並不那麼重要，但用 Go 編寫的靜態二進位檔案更好。
我們花費了精力，用 Go 重寫了 dapp，並將其命名為 werf。 該 Dapp 不再受支持，不再開發，在某些最新版本中運行，但有一個絕對的升級路徑，您可以遵循它。
為什麼要創建 dapp？
— 您能簡單介紹一下為什麼要創建這個 dapp，它解決了哪些問題嗎？
德米特里: 第一個原因是在裝配中。 最初，我們在建置時遇到了嚴重的問題，因為 Docker 不具備多階段功能，因此我們自己做了多階段。 然後我們在清理圖像時遇到了更多問題。 每個做 CI/CD 的人遲早都會面臨這樣的問題：收集到的鏡像有一堆，你需要以某種方式清理掉不需要的東西，留下需要的東西。
第二個原因是部署。 是的，有 Helm，但它只能解決部分問題。 有趣的是，它寫道「Helm 是 Kubernetes 的套件管理器」。 正是「那個」。 還有「套件管理器」這個詞——套件管理器通常的期望是什麼？ 我們說：“套件管理器 - 安裝套件！” 我們希望他告訴我們：“包裹已送達。”
有趣的是，我們說：“Helm，安裝這個包”，當他回答說他安裝了它時，結果發現他剛剛開始安裝——他向 Kubernetes 指示：“啟動這個東西！”，以及它是否啟動，不管有效與否，Helm根本就沒有解決這個問題。
事實證明，Helm 只是一個將資料載入到 Kubernetes 中的文字預處理器。
但作為任何部署的一部分，我們想知道應用程式是否已發布用於生產？ 推出到生產環境意味著應用程式已移至那裡，新版本已部署，並且至少不會在那裡崩潰並正確回應。 Helm 沒有以任何方式解決這個問題。 要解決這個問題，你需要花費大量的精力，因為你需要給 Kubernetes 下達命令來部署並監控那裡發生的事情 - 無論是部署還是部署。 還有很多與部署、清理、組裝相關的任務。
計劃
今年我們將開始本地開發。 我們想要實現 Vagrant 之前的目標 - 我們輸入「vagrant up」並部署虛擬機器。 我們想要到達 Git 中有一個專案的地步，我們在那裡寫“werf up”，它會調出該專案的本地副本，部署在本地 mini-Kub 中，並連接所有方便開發的目錄。 根據開發語言的不同，這樣做的方式有所不同，但仍然可以在掛載的文件下方便地進行本地開發。
我們的下一步是 投資為開發商提供便利。 要使用工具在本地快速部署項目，開發它，將其推送到 Git，它還將根據管道進行階段或測試，然後使用相同的工具投入生產。 這種從當地環境到銷售的基礎設施的統一性、統一性、可重複性對我們來說是非常重要的一點。 但這還沒有在 werf 中實現——我們只是計劃這樣做。
但通往 dapp/werf 的道路始終與一開始的 Kubernetes 相同。 我們遇到了問題，用變通辦法解決了它們——我們在 shell 上、任何事情上為自己想出了一些解決方案。 然後他們嘗試以某種方式糾正這些解決方法，將它們概括並合併為二進位文件，我們只是分享。
還有另一種方式可以透過類比來看待整個故事。
Kubernetes 是帶有引擎的汽車骨架。 沒有門、玻璃、收音機、聖誕樹——什麼都沒有。 只有車架和引擎。 還有 Helm——這是方向盤。 酷——有方向盤，但你還需要轉向銷、轉向齒條、變速箱和車輪，而且你離不開它們。
就 werf 而言，這是 Kubernetes 的另一個組件。 只是現在在 werf 的 alpha 版本中，例如 Helm 是在 werf 內部編譯的，因為我們厭倦了自己做。 這樣做的原因有很多，我會詳細告訴你為什麼我們把整個helm和tiller一起編譯在werf裡面 .
現在 werf 是一個更整合的組件。 我們得到了一個成品方向盤，一個轉向銷——我不太擅長汽車，但這是一個大塊，已經解決了相當廣泛的問題。 我們不需要自己瀏覽目錄，為另一個零件選擇一個零件，然後考慮如何將它們組合在一起。 我們得到了一個現成的聯合收割機，可以一次解決大量問題。 但它的內部是由相同的開源元件建構的，它仍然使用 Docker 進行組裝，Helm 來實現某些功能，還有其他幾個函式庫。 這是一個整合工具，可以快速、方便地開箱即用，很酷的 CI/CD。
Kubernetes 難維護嗎？
——你談到了你開始使用 Kubernetes 的經歷，這是你的一個框架，一個引擎，你可以在上面掛很多不同的東西：車身、方向盤、踏板上的螺絲、座椅。 問題出現了 - Kubernetes 對您的支援有多困難？ 您擁有豐富的經驗，您花了多少時間和資源來獨立於其他一切來支援 Kubernetes？
德米特里：這是一個非常困難的問題，要回答，我們需要了解什麼是支援以及我們希望從 Kubernetes 獲得什麼。 也許你可以透露一下？
——就我所知和所見，現在很多團隊都想嘗試 Kubernetes。 每個人都用它來約束自己，把它放在膝蓋上。 我有一種感覺，人們並不總是理解這個系統的複雜性。
德米特里： 就像那樣。
— 從頭開始安裝 Kubernetes 使其做好生產準備有多困難？
德米特里：您認為心臟移植有多難？ 我明白這是一個妥協的問題。 使用手術刀並且不犯錯並不是那麼困難。 如果他們告訴您在哪裡切割和縫製，那麼程序本身並不復雜。 很難一次又一次地保證一切都會順利。
安裝 Kubernetes 並讓它運行起來很簡單：小妞！ ——安裝，安裝方法有很多種。 但當問題出現時會發生什麼事？
問題總是出現──我們還沒有考慮到什麼？ 我們還沒有做什麼？ 哪些 Linux 核心參數指定不正確？ 主啊，我們有沒有提到他們？ 我們已經交付了哪些 Kubernetes 元件，哪些還沒交付？ 出現了成千上萬的問題，要回答這些問題，你需要在這個行業花費 15 到 20 年的時間。
我最近有一個關於這個主題的例子，也許可以揭示「Kubernetes 難以維護嗎？」這個問題的含義。 前段時間我們認真考慮是否應該嘗試將 Cilium 實作為 Kubernetes 中的網路。
讓我解釋一下什麼是Cilium。 Kubernetes 有許多不同的網路子系統實現，其中之一非常酷 - Cilium。 它的意義是什麼？ 在核心中，不久前可以為核心編寫鉤子，它以一種或另一種方式侵入網路子系統和各種其他子系統，並允許您繞過核心中的大塊。
Linux 核心歷史上有一個 ip 路由、一個過度過濾器、網橋和許多已有 15、20、30 年歷史的不同舊元件。 總的來說，他們工作正常，一切都很好，但現在他們堆起了集裝箱，看起來就像一座由15 塊磚塊疊在一起的塔，你單腿站在上面- 一種奇怪的感覺。 這個系統在歷史上有許多細微差別，就像體內的闌尾一樣。 例如，在某些情況下會出現效能問題。
有一個很棒的 BPF 和為內核編寫鉤子的能力 - 這些人為內核編寫了自己的鉤子。 軟體包進入 Linux 內核，他們在輸入處將其取出，自行處理，無需橋接，無需 TCP，無需 IP 堆疊 - 簡而言之，繞過 Linux 內核中編寫的所有內容，然後吐出將其放入容器中。
發生了什麼事？ 非常酷的性能，很酷的功能 - 太酷了！ 但我們觀察一下，發現每台機器上都有一個程式連接到 Kubernetes API，並根據從該 API 接收的資料生成 C 程式碼並編譯二進位文件，然後加載到核心中，以便這些鉤子起作用在內核空間中。
如果出現問題怎麼辦？ 我們不知道。 要理解這一點，您需要閱讀所有這些程式碼，理解所有邏輯，令人驚訝的是它有多困難。 但是，另一方面，還有這些網橋、網路過濾器、ip 路由——我沒有讀過它們的源代碼，我們公司的 40 名工程師也沒有讀過它們的源代碼。 也許只有少數人理解某些部分。
有什麼區別呢？ 事實證明，有 ip rout、Linux 內核，還有一個新工具——它們有什麼區別，我們不明白其中一個。 但我們害怕使用新的東西 - 為什麼？ 因為如果這個工具已經使用了 30 年，那麼在 30 年內，所有的 bug 都已被發現，所有的錯誤都已被踩過，你不需要知道一切 - 它就像一個黑盒子一樣工作，並且始終有效。 每個人都知道哪個診斷螺絲起子應該插在哪個位置，哪個tcpdump 在什麼時刻運行。 每個人都非常了解診斷實用程序，並且了解這組組件在 Linux 核心中的工作原理 - 不是它如何工作，而是如何使用它。
而且非常酷的 Cilium 還不到 30 歲，它還沒有老化。 Kubernetes 也有同樣的問題，複製。 Cilium 安裝完美，Kubernetes 安裝完美，但是當生產中出現問題時，你能在危急情況下快速了解出了什麼問題嗎？
當我們說維護 Kubernetes 很難時，不，它非常容易，是的，它非常困難。 Kubernetes 本身運作良好，但存在十億個細微差別。
關於「我會幸運」的方法
— 有哪些公司幾乎肯定會出現這些細微差別？ 假設Yandex突然將所有服務轉移到Kubernetes上，那裡會產生巨大的負載。
德米特里：不，這不是關於負載的對話，而是關於最簡單的事情。 例如，我們有 Kubernetes，我們在那裡部署了應用程式。 你怎麼知道它有效？ 根本沒有現成的工具可以了解應用程式是否崩潰。 沒有現成的系統可以發送警報；您需要配置這些警報和每個計劃。 我們正在更新 Kubernetes。
我有 Ubuntu 16.04。 你可以說這是一個舊版本，但我們仍在使用它，因為它是 LTS。 有 systemd，其細微差別在於它不會清理 C 組。 Kubernetes 啟動 pod，建立 C 群組，然後刪除 pod，結果不知何故 - 我不記得細節了，抱歉 - systemd 切片仍然存在。 這導致隨著時間的推移，任何汽車都開始大幅減速。 這甚至不是一個關於高負載的問題。 如果啟動永久 pod，例如，如果有一個 Cron Job 不斷產生 pod，那麼安裝 Ubuntu 16.04 的機器將在一週後開始變慢。 由於創建了一堆 C 組，因此平均負載會持續較高。 這是任何簡單安裝 Ubuntu 16 和 Kubernetes 的人都會面臨的問題。
假設他以某種方式更新了 systemd 或其他東西，但在 4.16 之前的 Linux 核心中，情況甚至更有趣 - 當你刪除 C 組時，它們會在內核中洩漏，並且實際上並沒有被刪除。 因此，在這台機器上工作一個月後，將無法查看爐灶的記憶體統計資料。 我們取出一個文件，在程式中滾動它，一個文件滾動了15秒，因為核心需要很長時間來計算其內部的一百萬個C組，這些C組似乎被刪除了，但沒有——它們正在洩漏。
諸如此類的小事，到處還有很多。 這並不是大公司有時在非常重的負載下可能面臨的問題——不，這是日常事務。 人們可以這樣生活幾個月——他們安裝了 Kubernetes，部署了應用程式——這似乎有效。 對許多人來說，這是正常的。 他們甚至不知道該應用程式會因某種原因崩潰，他們不會收到警報，但對他們來說這是常態。 以前，我們生活在沒有監控的虛擬機器上，現在我們搬到了 Kubernetes，同樣沒有監控——有什麼區別？
問題是，當我們在冰上行走時，除非提前測量，否則我們永遠不知道它的厚度。 很多人走路都不用擔心，因為他們以前也走路過。
在我看來，操作任何系統的細微差別和複雜性都是為了確保冰的厚度恰好足以解決我們的問題。 這就是我們正在談論的。
在我看來，在 IT 領域，有太多「我會幸運」的方法。 許多人安裝軟體並使用軟體庫是希望自己能幸運。 總的來說，很多人都是幸運的。 這可能就是它起作用的原因。
— 從我的悲觀評估來看，它看起來是這樣的：當風險很高，並且應用程式必須工作時，那麼需要Flaunt 的支持，也許來自Red Hat，或者你需要自己的專門針對Kubernetes 的內部團隊，這些團隊已經準備好了來完成它。
德米特里: 客觀來說是這樣的。 獨自進入小團隊的 Kubernetes 故事涉及許多風險。
我們需要容器嗎？
— 您能告訴我們 Kubernetes 在俄羅斯的普及程度嗎？
德米特里: 我沒有這個數據，也不知道其他人有沒有。 我們說：“Kubernetes，Kubernetes”，但還有另一種看待這個問題的方式。 我也不知道容器的普及程度如何，但我從網路上的報道中知道一個數字，70%的容器是由 Kubernetes 編排的。 它是世界各地相當大樣本的可靠來源。
那麼另一個問題——我們需要容器嗎？ 我個人的感覺以及Flant公司的整體立場是，Kubernetes是事實上的標準。
除了 Kubernetes 之外什麼都沒有。
這絕對是基礎設施管理領域的遊戲規則改變者。 絕對的 - 就是這樣，不再有 Ansible、Chef、虛擬機器、Terraform。 我不是說舊的集體農莊方法。 Kubernetes 是絕對的改變者，現在也只能這樣了。
顯然，對某些人來說需要幾年的時間，而對其他人來說需要幾十年的時間才能意識到這一點。 我毫不懷疑，除了 Kubernetes 和這個新面貌之外，什麼都沒有：我們不再破壞作業系統，而是使用 基礎設施即程式碼，只是不是用程式碼，而是用 yml - 一種聲明式描述的基礎設施。 我有一種感覺，永遠都會這樣。
——也就是說，那些還沒有轉向 Kubernetes 的公司肯定會轉向它，或者被遺忘。 我理解你的意思正確嗎？
德米特里: 這也不完全正確。 例如，如果我們有運行一個DNS伺服器的任務，那麼它可以運行在FreeBSD 4.10上，並且可以完美工作20年。 只要工作就夠了。 也許20年後有些東西需要更新一次。 如果我們談論的是我們推出的格式的軟體，並且它實際上可以運行很多年而沒有任何更新，沒有進行任何更改，那麼當然就不會有 Kubernetes。 那裡不需要他。
與 CI/CD 相關的一切——無論哪裡需要持續交付，哪裡需要更新版本，進行主動更改，哪裡需要建立容錯能力——只有 Kubernetes。
關於微服務
- 在這裡我有一點不和諧。 要使用 Kubernetes，您需要外部或內部支援 - 這是第一點。 其次，當我們剛開始開發時，我們是一家小型新創公司，我們還什麼都沒有，Kubernetes 或微服務架構的開發通常可能很複雜，而且在經濟上並不總是合理的。 我對你的觀點很感興趣——新創公司是否需要立即從頭開始為 Kubernetes 編寫，或者他們仍然可以編寫一個整體，然後只轉向 Kubernetes？
德米特里: 很酷的問題。 我有一個關於微服務的演講 我多次遇到有人試圖用顯微鏡釘釘子。 這種方法本身是正確的；我們自己就是這樣設計我們的內部軟體的。 但當你這樣做的時候，你需要清楚地了解你在做什麼。 關於微服務，我最討厭的字是「微」。 從歷史上看，這個詞起源於那裡，出於某種原因，人們認為微非常小，不到一毫米，就像微米一樣。 這是錯誤的。
例如，有一個由 300 人編寫的巨石，每個參與開發的人都知道那裡存在問題，應該將其分解為微塊 - 大約 10 個塊，每個塊由 30 人編寫在最低版本中。 這很重要、必要而且很酷。 但是，當我們遇到一家新創公司時，每次我都會尋找 Corvalol，其中 3 個非常酷且有才華的人跪下編寫了 60 個微服務。
在我看來，這已經被討論了數千次——我們得到了一種或另一種形式的分佈式整體。 這在經濟上是不合理的，總的來說，一切都很困難。 我已經看到很多次了，這真的讓我很受傷，所以我繼續談論它。
對於最初的問題，以下事實之間存在衝突：一方面，Kubernetes 使用起來很可怕，因為不清楚什麼可能會在那裡崩潰或不起作用，另一方面，很明顯一切都在那裡除了Kubernetes 之外，什麼都不會存在。 回答 - 權衡帶來的好處，你可以解決的任務量。 這是天平的一邊。 另一方面，存在與停機或回應時間減少、可用性水準下降（效能指標下降）相關的風險。
就是這樣——要么我們行動迅速，Kubernetes 使我們能夠更快更好地完成許多事情，要么我們使用可靠的、經過時間考驗的解決方案，但行動要慢得多。 這是每個企業都必須做出的選擇。 你可以把它想像成叢林中的一條小路——當你第一次行走時，你可能會遇到一條蛇、一隻老虎或一隻瘋狂的獾，當你走了10次時，你就已經走過了這條路，遠離了樹枝和行走更容易。 每次，路都變得更寬。 然後是柏油路，再後來是美麗的林蔭大道。
Kubernetes 並沒有停滯不前。 再次提問：Kubernetes，一方面是4-5個二進位文件，另一方面，它是整個生態系統。 這是我們機器上的作業系統。 這是什麼？ Ubuntu 還是 Curios？ 這是 Linux 內核，一堆附加元件。 這裡發生了所有這些事情，一條毒蛇被扔到了路上，那裡豎起了柵欄。 Kubernetes 正在快速、動態地發展，風險量、未知量每個月都在減少，因此，這些規模正在重新平衡。
在回答新創公司應該做什麼的問題時，我會說 - 來到 Flaunt，支付 150 萬盧布並獲得交鑰匙 DevOps 輕鬆服務。 如果您是一家擁有少數開發人員的小型新創公司，那麼這很有效。 您將獲得解決所有問題的交鑰匙解決方案，而不是僱用自己的 DevOps（他們此時需要學習如何解決您的問題並支付薪水）。 是的，有一些缺點。 我們作為外包商，不可能如此投入並快速回應變化。 但我們有很多專業知識和現成的實踐。 我們保證在任何情況下我們一定會很快弄清楚並讓任何 Kubernetes 起死回生。
我強烈建議外包給新創公司和成熟企業，其規模可以讓您專門組建 10 人的團隊來運營，否則就沒有意義。 將其外包絕對是有意義的。
關於亞馬遜和谷歌
— 來自 Amazon 或 Google 的解決方案的主機是否可以被視為外包？
德米特里: 是的，當然，這解決了很多問題。 但同樣存在細微差別。 您仍然需要了解如何使用它。 例如，亞馬遜AWS的工作中有一千件小事：負載平衡器需要預熱或必須提前寫一個請求“夥計們，我們將收到流量，為我們預熱負載平衡器！” 您需要了解這些細微差別。
當你求助於專門從事這方面工作的人時，你幾乎可以解決所有典型的問題。 我們現在有 40 名工程師，到今年年底可能會達到 60 名 - 我們肯定遇到過所有這些事情。 即使我們在某個專案中再次遇到這個問題，我們也會很快地互相詢問並知道如何解決。
也許答案是——當然，託管故事會讓某些部分變得更容易。 問題是您是否準備好信任這些託管服務商以及他們是否會解決您的問題。 亞馬遜和谷歌做得很好。 對於我們所有的情況 - 完全正確。 我們沒有更多積極的經驗。 我們嘗試使用的所有其他雲都會產生很多問題 - Ager，以及俄羅斯的所有雲，以及不同實作中的各種 OpenStack：Headster、Overage - 無論你想要什麼。 它們都會造成你不想解決的問題。
因此，答案是肯定的，但事實上，成熟的託管解決方案並不多。
誰需要 Kubernetes？
— 然而，誰需要 Kubernetes？ 誰應該已經轉向 Kubernetes，誰是專門針對 Kubernetes 的典型 Flaunt 用戶端？
德米特里：這是一個有趣的問題，因為現在，隨著 Kubernetes 的出現，很多人來找我們：“夥計們，我們知道你們在做 Kubernetes，為我們做吧！” 我們回答他們：“先生們，我們不做 Kubernetes，我們做產品以及與之相關的一切。” 因為目前如果不完成所有 CI/CD 和整個故事就不可能製造出產品。 每個人都擺脫了這樣的劃分：我們先發展再發展，然後再剝削。
我們的客戶期望不同的事情，但每個人都在等待他們遇到某些問題的奇蹟，現在 - 跳！ — Kubernetes 將解決這些問題。 人們相信奇蹟。 在他們的心中，他們明白不會有奇蹟，但在他們的靈魂中，他們希望 - 如果這個 Kubernetes 現在能為我們解決一切，那會怎樣，他們對此談論得太多了！ 突然他現在——打噴嚏！ - 還有一個靈丹妙藥，打噴嚏！ - 我們擁有 100% 的正常運行時間，所有開發人員都可以將任何進入生產環境的內容發布 50 次，而且不會崩潰。 總的來說，這是一個奇蹟！
當這樣的人來找我們時，我們會說：“抱歉，奇蹟是不存在的。” 為了保持健康，您需要良好的飲食和運動。 要擁有可靠的產品，就需要可靠地製造它。 為了有一個方便的 CI/CD，你需要把它做成這樣。 這需要做很多工作。
回答誰需要 Kubernetes 的問題——沒有人需要 Kubernetes。
有些人錯誤地認為他們需要 Kubernetes。 人們需要，他們迫切需要停止思考、研究並對所有基礎設施問題和運行應用程式的問題感興趣。 他們希望應用程式能夠正常運作和部署。 對他們來說，Kubernetes 希望他們不再聽到「我們躺在那裡」或「我們無法推出」或其他什麼的故事。
技術總監通常會來找我們。 他們問他兩件事：一方面，給我們功能，另一方面，穩定性。 我們建議你自己承擔並去做。 靈丹妙藥，或者更確切地說是鍍銀的，是你將不再思考這些問題並浪費時間。 您將有專門的人員來關閉此問題。
我們或任何其他人需要 Kubernetes 的說法是不正確的。
管理員確實需要 Kubernetes，因為它是一個非常有趣的玩具，您可以玩耍和修補。 說實話——每個人都喜歡玩具。 我們都是某個地方的孩子，當我們看到新的東西時，我們就想玩它。 對某些人來說，這在政府中是不被鼓勵的，因為他們已經玩夠了，並且已經累到了他們根本不想玩的程度。 但這並不是任何人都完全失去的。 例如，如果我已經厭倦了系統管理和DevOps領域的玩具很長一段時間，那麼我仍然喜歡這些玩具，我仍然會買一些新的。 所有人，無論怎樣，仍然想要某種玩具。
無需玩弄製作。 無論我明確建議不要做什麼，以及我現在看到的一切：“哦，一個新玩具！” ——他們跑去買，買了然後說：“我們現在把它帶到學校，給我們所有的朋友看。” 不要這樣做。 我很抱歉，我的孩子剛剛長大，我經常在孩子身上看到一些東西，在自己身上註意到它，然後將其推廣給其他人。
最終的答案是：你不需要 Kubernetes。 你需要解決你的問題。
您可以實現的目標是：
- 刺棒不掉落；
- 即使他想摔倒，我們也能提前知道，並且可以在裡面放一些東西；
- 我們可以按照業務需要的速度進行更改，並且可以方便地進行更改，不會給我們帶來任何問題。
有兩個真正的需求：可靠性和推出的活力/靈活性。 目前正在做某種IT專案的每個人，無論從事何種業務——緩世軟體，誰明白這一點，就需要解決這些需求。 Kubernetes 透過正確的方法、正確的理解和足夠的經驗可以讓您解決這些問題。
關於無伺服器
— 如果你把目光放得更遠一些，那麼試圖解決基礎設施不存在令人頭疼的問題，隨著部署的速度和應用程式更改的速度，新的解決方案就會出現，例如無伺服器。 您是否覺得這個方向有任何潛力，或者說，對 Kubernetes 和類似解決方案是否有危險？
德米特里：這裡需要再次聲明，我不是一個預言家，會展望未來並說－事情會是這樣的！ 雖然我只是做了同樣的事情。 我看著我的腳，發現那裡有很多問題，例如晶體管如何在電腦中工作。 很有趣，對吧？ 我們在 CPU 中遇到了一些錯誤。
讓無伺服器變得可靠、廉價、高效和方便，解決所有生態系統問題。 在這裡，我同意伊隆馬斯克的觀點，即需要第二顆行星來為人類創造容錯能力。 雖然我不知道他在說什麼，但我知道我還沒準備好親自飛往火星，明天也不會發生。
對於無伺服器來說，很明顯這是一件意識形態上正確的事情，就像人類的容錯能力一樣——擁有兩個行星比一個更好。 但現在該怎麼辦呢？ 如果你集中精力的話，派出一支探險隊不是問題。 派幾次探險隊，安置幾千人，我想也是現實的。 但要讓它完全容錯，讓一半的人類生活在那裡，在我看來現在是不可能的，不被考慮。
一對一的無伺服器：這件事很酷，但距離 2019 年的問題還很遠。 距離 2030 年越來越近——讓我們拭目以待吧。 我毫不懷疑我們會活下去，我們一定會活下去（睡前重複一遍），但現在我們需要解決其他問題。 這就像相信童話裡的小馬彩虹。 是的，有百分之幾的案例得到了解決，而且解決得很完美，但主觀上來說，Serverless 就是彩虹……對我來說，這個話題太遙遠了，太難理解了。 我還沒準備好說話。 2019 年，你無法用 Serverless 編寫單一應用程式。
Kubernetes 將如何發展
— 當我們邁向這個可能美好的遙遠未來時，您認為 Kubernetes 及其周圍的生態系統將如何發展？
德米特里: 這個問題我想了很多，也有明確的答案。 第一個是有狀態的──畢竟無狀態比較容易做到。 Kubernetes 最初在這方面投入了更多，這一切都是從它開始的。 無狀態在 Kubernetes 中幾乎可以完美運行，沒有什麼可抱怨的。 仍然存在許多問題，或者更確切地說，存在細微差別。 那裡的一切都對我們來說已經很有效，但那就是我們。 至少還需要幾年時間才能讓每個人都受益。 這不是計算出來的指標，而是我腦中的感覺。
簡而言之，有狀態的應用程式應該而且將會發展得非常強勁，因為我們所有的應用程式都儲存狀態；沒有無狀態的應用程式。 這是一種幻覺；你總是需要某種資料庫和其他東西。 Statefull 是為了理順所有可能的事情，修復所有錯誤，改善當前面臨的所有問題 - 讓我們稱之為採用。
未知的程度、未解決的問題的程度、遇到某事的機率程度都會顯著下降。 這是一個重要的故事。 和操作員 - 與管理邏輯、控制邏輯的編碼相關的所有內容，以便獲得簡單的服務：MySQL 簡單服務、RabbitMQ 簡單服務、Memcache 簡單服務 - 一般來說，我們需要保證所有這些元件都能正常工作盒子。 這正好解決了我們想要一個資料庫，但我們不想管理它，或者我們想要 Kubernetes，但我們不想管理它的痛苦。
這種或另一種形式的運營商發展故事將在未來幾年中發揮重要作用。
我認為易用性應該會大大增加——盒子會變得越來越黑，越來越可靠，旋鈕也越來越簡單。
我曾經在 YouTube 的《週六夜現場》上聽過一段 80 年代艾薩克·阿西莫夫的老採訪——一個像《Urgant》這樣的節目，只是很有趣。 他們向他詢問計算機的未來。 他說，未來就是簡單，就像收音機一樣。 無線電接收器原本是個複雜的東西。 為了捕捉電波，你必須轉動旋鈕 15 分鐘，轉動串桿，並且大致了解一切是如何運作的，以了解無線電波傳輸的物理原理。 結果，收音機就只剩下一個旋鈕了。
現在2019年有什麼電台？ 在車裡，無線電接收器找到所有的電波和電台名稱。 一百年來，過程的物理原理沒有改變，但易用性卻改變了。 現在，不僅是現在，早在 100 年，當阿齊莫夫接受採訪時，每個人都使用收音機，但沒有人考慮它是如何運作的。 它總是有效的——這是理所當然的。
阿齊莫夫隨後表示，計算機也是如此—— 易用性將會提高。 1980 年，您必須接受如何按下電腦上的按鈕的培訓，但未來情況將不再如此。
我有一種感覺，有了 Kubernetes 和基礎設施，易用性也會大大提高。 在我看來，這是顯而易見的——它就在表面上。
工程師該怎麼辦？
— 那麼支援 Kubernetes 的工程師和系統管理員會發生什麼事？
德米特里：1C出現後，會計師怎麼了？ 差不多。 在此之前，他們依靠的是紙質材料——現在是在程序中。 勞動生產力提高了幾個數量級，但勞動本身並沒有消失。 如果以前需要 10 名工程師才能擰緊一個燈泡，現在只需 XNUMX 名工程師就足夠了。
在我看來，軟體數量和任務數量現在的成長速度比新的 DevOps 出現的速度還要快，而且效率也在提高。 目前市場存在一定的短缺，而且這種短缺將持續很長一段時間。 後來，一切都會恢復到某種常態，工作效率會提高，Serverless 會越來越多，一個神經元會附加到 Kubernetes 上，它會根據需要準確地選擇所有資源，一般來說會一切事情都應該自己做——那個人只是走開，不要干涉。
但仍需要有人做出決定。 顯然，此人的資格和專業水準更高。 如今，在會計部門，你不需要10名員工記賬，這樣他們的手就不會累。 這根本沒有必要。 許多文件由電子文件管理系統自動掃描和識別。 一位聰明的總會計師就夠了，他已經具備了更高的技能和良好的理解力。
一般來說，這是所有行業都要走的路。 汽車也是如此：以前，一輛車配備一名機械師和三名司機。 如今，駕駛汽車是我們每天都參與的簡單過程。 沒有人認為汽車是複雜的東西。
DevOps 或系統工程不會消失——高水準的工作和效率將會提高。
— 我也會聽到一個有趣的想法，工作其實會增加。
德米特里: 當然，百分之百！ 因為我們寫的軟體數量不斷增加。 我們用軟體解決的問題數量不斷增加。 工作量越來越大。 現在 DevOps 市場嚴重過熱。 這可以從薪資預期中看出。 從好的角度來說，不講細節，應該有初級想要X，中階想要1,5X，高級想要2X。 現在，如果你看看莫斯科 DevOps 薪資市場，初級員工想要的薪資是 X 到 3 倍，高階員工想要的薪資是 X 到 3 倍。
沒有人知道它要花多少錢。 薪資水平是由你的信心來衡量的——老實說，這是一個完全瘋人院，一個極度過熱的市場。
當然，這種情況很快就會改變——應該會出現一定程度的飽和。 軟體開發的情況並非如此——儘管每個人都需要開發人員，每個人都需要優秀的開發人員，但市場知道誰值多少錢——這個行業已經穩定下來。 如今 DevOps 的情況並非如此。
——從我聽到的情況來看，我的結論是，現在的系統管理員不必太擔心，但是時候提升自己的技能了，並為明天的工作量會更多，但資質會更高這一事實做好準備。
德米特里: 百分之百。 總的來說，我們生活在2019年，生活的規則是這樣的： 終身學習－我們一生都在學習。 在我看來，現在每個人都已經知道並感受到了這一點，但僅僅知道還不夠——你必須這樣做。 每一天我們都必須改變。 如果我們不這樣做，那麼我們遲早會被邊緣化。
做好 180 度急轉彎的準備。 我不排除某些事情發生根本性變化、新事物被發明的情況——它會發生。 跳！ - 我們現在的行為有所不同。 重要的是要為此做好準備並且不要擔心。 也許明天我所做的一切都會變得不必要——沒什麼，我已經研究了一輩子，並準備好學習其他東西。 這不是一個問題。 沒有必要害怕工作保障，但你需要做好不斷學習新事物的準備。
願望和一分鐘廣告
- 你有什麼願望嗎？
德米特里: 是的，我有幾個願望。
第一和商業 - 訂閱 。 親愛的讀者，請訪問 YouTube 並訂閱我們的頻道。 大約一個月後，我們將開始積極擴展視訊服務，我們將有很多關於 Kubernetes 的教育內容，開放且多樣化：從實用的東西，一直到實驗室，再到深入的基礎理論以及如何在現場使用 Kubernetes。原則和模式的層次。
第二個商業願望－去 並放上星星，因為我們以它們為食。 如果你不給我們星星，我們就沒有東西吃。 這就像電腦遊戲中的法力。 我們做了一些事情，我們做了，我們嘗試，有人說這些自行車很糟糕，有人說一切都是完全錯誤的，但我們繼續並絕對誠實地行事。 我們發現問題、解決問題並分享我們的經驗。 因此，給我們一顆星星，它不會離開你，而是會來到我們身邊，因為我們以它們為食。
第三，重要的、不再是商業性的願望—— 別再相信童話故事。 你們是專業人士。 DevOps是一個非常認真負責的職業。 別再在工作場所玩了。 讓它為你點擊，你就會明白它。 想像一下，您來到醫院，醫生正在為您進行實驗。 我知道這可能會冒犯某人，但很可能這不是關於您，而是關於其他人。 告訴其他人也停下來。 這確實毀了我們所有人的生活——許多人開始將維運、管理員和 DevOps 視為再次破壞某些東西的傢伙。 這被「打破」的最常見原因是我們去玩，並沒有冷漠地意識到事情就是這樣，事情就是這樣。
這並不意味著您不應該進行實驗。 我們需要嘗試，我們自己做。 老實說，我們自己有時也會玩遊戲——這當然是非常糟糕的，但人類對我們來說並不陌生。 讓我們宣布 2019 年是認真、深思熟慮的實驗的一年，而不是製作遊戲的一年。 大概是這樣。
- 非常感謝！
德米特里：謝謝 Vitaly 抽出時間接受我們的採訪。 親愛的讀者，如果您突然想到這裡，非常感謝您。 我希望我們至少能帶給您一些想法。
在訪談中，德米特里談到了werf的問題。 現在，這是一把通用瑞士刀，幾乎可以解決所有問題。 但情況並非總是如此。 在 在節日裡 Dmitry Stolyarov 將向您詳細介紹該工具。 在報告中 將會有一切：Kubernetes 的問題和隱藏的細微差別、解決這些困難的選項以及 werf 目前的詳細實現。 27月28日至XNUMX日加入我們，我們將創造完美的工具。
來源： www.habr.com