五月底 召開了該主題的線上會議 。 我們原則上討論了容器、Kubernetes 和編排、選擇基礎架構的標準等等。 與會者分享了自己的實踐案例。
參與者：
- Evgeniy Potapov，ITSumma 首席執行官。 超過一半的客戶已經轉向或希望轉向 Kubernetes。
- Dmitry Stolyarov，「Flant」首席技術官。 擁有 10 多年容器系統工作經驗。
- Denis Remchukov（又名 Eric Oldmann），argotech.io 首席營運官，前 RAO UES 成員。 他承諾將談論「血腥」企業中的案例。
- 費多羅夫斯基 (Andrey Fedorovsky)，「News360.com」首席技術官在被另一位玩家收購該公司後，他負責許多 ML 和 AI 項目和基礎設施。
- Ivan Kruglov，系統工程師，前 Booking.com。同一個人親手用 Kubernetes 做了很多事。
主題：
- 參與者對容器和編排（Docker、Kubernetes等）的見解； 在實踐中嘗試過或分析過什麼。
- 案例：該公司多年來一直在製定基礎設施發展計劃。 如何決定是否建置（或遷移目前）基礎架構到容器和 Kuber？
- 雲端原生世界的問題，缺少什麼，讓我們想像明天會發生什麼。
接下來是個有趣的討論，與會者的意見各不相同，引起了很多評論，我想和大家分享一下。 吃 ，下面是討論的摘要。
Kubernetes 已經成為標準還是偉大的行銷？
「我們在還沒有人知道的時候就開始研究它（Kubernetes。-編輯）。 即使他不在，我們也來找他。 我們之前就想要它」- 德米特里·斯托利亞羅夫
照片來自 Reddit.com
5-10 年前，工具數量龐大，而且沒有統一的標準。 每六個月就會出現一種新產品，甚至不只一種。 首先是 Vagrant，然後是 Salt、Chef、Puppet…「然後每六個月重建一次基礎設施。 您有五名管理員，他們經常忙於重寫配置，」Andrey Fedorovsky 回憶道。 他認為 Docker 和 Kubernetes 已經「排擠」了其餘的。 Docker 在過去五年成為了標準，Kubernetes 在過去兩年成為了標準。 這對這個行業來說是件好事。.
德米特里·斯托利亞羅夫 (Dmitry Stolyarov) 和他的團隊非常喜歡庫伯。 在這樣的工具出現之前，他們就想要它，並且在無人知曉的情況下才找到它。 目前，出於方便的原因，如果他們知道不會與客戶一起實施 Kubernetes，他們就不會接受該客戶。 同時，德米特里表示，該公司有「許多關於重塑可怕遺產的巨大成功故事」。
Kubernetes 不僅僅是容器編排，它還是一個組態管理系統，具有開發的 API、網路元件、L3 平衡和入口控制器，這使得管理資源、擴展和從基礎設施的較低層進行抽象變得相對容易。
不幸的是，在我們的生活中，我們必須為一切付出代價。 正如 Ivan Kruglov 所認為的那樣，這筆稅收很大，尤其是當我們談論一家擁有發達基礎設施的公司向 Kubernetes 過渡時。 他可以自由地在擁有傳統基礎設施的公司和 Kuber 工作。 主要是了解公司和市場的特徵。 但是，對於 Evgeny Potapov 來說，他將 Kubernetes 推廣到任何容器編排工具，這樣的問題就不會出現。
Evgeniy 與 1990 世紀 XNUMX 年代的情況進行了類比，當時物件導向程式設計作為一種複雜應用程式程式設計方式出現。 當時，爭論仍在繼續，並且出現了支持 OOP 的新工具。 然後，微服務作為擺脫單一概念的一種方式出現。 這反過來又導致了容器和容器管理工具的出現。 他認為：“我認為我們很快就會迎來這樣一個時刻，即不存在是否值得編寫小型微服務應用程式的問題，它將默認被編寫為微服務。” 同樣，Docker 和 Kubernetes 最終將成為標準解決方案，無需選擇。
無狀態資料庫的問題
Photo by
如今，在 Kubernetes 中運行資料庫的方法有很多。 甚至如何有條件地將與 I/O 磁碟一起工作的部分與資料庫的應用程式部分分開。 未來資料庫有沒有可能會發生很大的變化，以至於它們會被裝在一個盒子裡交付，其中一部分將透過Docker 和Kubernetes 來編排，而在基礎設施的另一部分中，將透過單獨的軟體提供存儲部分？ 作為產品，底座會改變嗎？
這種描述與隊列管理類似，但對傳統資料庫中資訊的可靠性和同步性的要求要高得多，Andrey 認為。 普通資料庫的快取命中率維持在99%。 如果一個工作線程宕機，就會啟動一個新的工作線程，並且快取會從頭開始「預熱」。 在快取預熱之前，工作執行緒工作緩慢，這意味著它無法載入使用者負載。 當沒有用戶負載時，快取不會預熱。 這是一個惡性循環。
德米特里從根本上不同意——法定人數和分片解決了問題。 但安德烈堅持認為，該解決方案並不適合所有人。 在某些情況下，仲裁是合適的，但它會為網路帶來額外的負載。 NoSQL 資料庫並非適用於所有情況。
聚會參與者分為兩個陣營。
Denis 和 Andrey 認為，寫入磁碟的所有操作（資料庫等）在目前的 Kuber 生態系統中都是不可能完成的。 在 Kubernetes 中無法維持生產資料的完整性和一致性。 這是一個基本特徵。 解決方案：混合基礎設施。
即使是像 MongoDB 和 Cassandra 這樣的現代雲端原生資料庫，或是像 Kafka 或 RabbitMQ 這樣的訊息佇列，也需要 Kubernetes 以外的持久資料儲存。
Evgeniy 反對道：“庫貝拉的基地是一個近乎俄羅斯或近乎企業的傷害，這與俄羅斯沒有採用雲端技術有關。” 西方的中小型公司都是雲端。 Amazon RDS 資料庫比自己修改 Kubernetes 更容易使用。 在俄羅斯，他們在「本地」使用 Kuber，並在試圖擺脫動物園時將基地轉移到它。
Dmitry 也不同意 Kubernetes 中不能保留任何資料庫的說法：「Base 與 Base 不同。 如果你推送一個巨大的關聯式資料庫，那麼在任何情況下都不會。 如果你推動一些小的、雲原生的東西，為半短暫的生活做好心理準備，一切都會好起來的。” Dmitry 也提到，資料庫管理工具還沒有為 Docker 或 Kuber 做好準備，因此出現了很大的困難。
反過來，Ivan 確信，即使我們從有狀態和無狀態的概念中抽像出來，Kubernetes 中的企業解決方案生態系統還沒有準備好。 對於 Kuber，很難維持立法和監管要求。 例如，不可能製定需要嚴格的伺服器身分保證（甚至包括插入伺服器的硬體）的身份提供解決方案。 這個領域正在發展，但還沒有解決方案。
與會者無法達成一致，因此本部分不得出任何結論。 讓我們舉幾個實際的例子。
案例 1. 基地位於庫貝拉以外的「大型監管機構」的網路安全
對於成熟的網路安全系統，容器和編排的使用使得抵禦攻擊和入侵成為可能。 例如，在一個大型監管機構中，Denis 和他的團隊將協調器與訓練有素的 SIEM 服務相結合，即時分析日誌並確定攻擊、駭客攻擊或故障的過程。 如果發生攻擊、試圖放置某些東西，或發生勒索軟體病毒入侵，它會透過協調器以比被感染或攻擊者攻擊它們的速度更快的速度拾取包含應用程式的容器。
案例2. Booking.com資料庫部分遷移至Kubernetes
在Booking.com中，主資料庫是具有非同步複製功能的MySQL－有一個主資料庫和一個完整的從資料庫層次結構。 當伊凡離開公司時，啟動了一個轉移奴隸的項目，這些奴隸可能會被「槍殺」並造成一定的傷害。
除了主基地之外，還有一個帶有自寫編排的Cassandra安裝，這是在Kuber進入主流之前就寫的。 這方面沒有問題，但在本地SSD上卻是持久的。 由於高延遲問題，即使在同一資料中心內，也不會使用遠端儲存。
第三類資料庫是Booking.com搜尋服務，其中每個服務節點都是資料庫。 嘗試將搜尋服務轉移到Kuber失敗了，因為每個節點都有60-80GB的本地存儲，很難「提升」和「預熱」。
結果，搜尋引擎並沒有轉移到 Kubernetes，Ivan 認為近期不會有新的嘗試。 MySQL資料庫被轉移了一半：只有Slave，它們不怕被「槍殺」。 卡桑德拉已經完美地適應了。
基礎設施選擇是一項沒有通用解決方案的任務
Photo by
假設我們有一家新公司，或者一家部分基礎設施是按照舊方式建造的公司。 它制定了多年的基礎設施發展計劃。 如何決定是否在容器和 Kuber 上建置基礎架構？
爭取納秒的公司被排除在討論之外。 健康的保守主義在可靠性方面得到了回報，但仍然有一些公司應該考慮新的方法。
Ivan：「我現在肯定會在雲端創辦一家公司，只是因為它更快，」儘管不一定更便宜。 隨著創投主義的發展，新創企業在資金上已經沒有什麼大問題了，主要任務是征服市場。
伊凡認為 目前基礎設施的發展是一個選擇標準。 如果過去進行過重大投資並且有效，那麼就沒有必要重做。 如果基礎設施尚未開發，且工具、安全和監控存在問題，那麼考慮分散式基礎設施是有意義的。
稅是無論如何都要繳的，而伊凡會繳那些讓他以後少繳的稅。 」因為僅僅因為我搭乘的是別人正在運行的火車，我就會比搭乘另一輛我必須自己加油的火車走得更遠。「伊万說。 當公司是新公司的時候，延遲要求是幾十毫秒，那麼伊万就會把目光投向今天「包裝」經典資料庫的「運營商」。 他們提出了一個複製鏈，該複製鏈會在發生故障轉移等情況下自行切換...
對於擁有幾台伺服器的小公司來說，Kubera 毫無意義，」Andrey 說。 但如果它計劃成長到數百台伺服器或更多，那麼它就需要自動化和資源管理系統。 90%的情況都是值得的。 而且，無論負載和資源水平如何。 對每個人來說，從新創公司到擁有數百萬受眾的大公司，逐漸專注於容器編排產品都是有意義的。 「是的，這確實是未來，」安德烈確信。
丹尼斯概述了兩個主要標準 - 可擴展性和運作穩定性。 他將選擇最適合該任務的工具。 「它可能是組裝在你膝蓋上的無名產品，上面有 Nutanix 社群版。 這可以是 Kuber 上應用程式形式的第二行，後端有一個資料庫，該資料庫被複製並指定了 RTO 和 RPO 參數」（復原時間/點目標 - 約。).
葉夫根尼發現了人員方面可能存在的問題。 目前，市場上懂「膽」的高素質專家並不多。 確實，如果所選的技術是陳舊的，那麼除了對生活感到無聊和厭倦的中年人之外，很難僱用任何人。 儘管其他與會者認為這是人員訓練的問題。
如果我們提出選擇的問題：在公有雲中啟動一家使用 Amazon RDS 資料庫的小公司，或者在「本地」使用 Kubernetes 資料庫的小公司，那麼儘管存在一些缺點，Amazon RDS 成為了參與者的選擇。
既然大多數聚會聽眾都不是來自「血腥」企業，那麼 分散式解決方案是我們應該努力的方向。 資料儲存系統必須是分散式的、可靠的，並且產生以毫秒為單位（最多數十毫秒）的延遲“，安德烈總結道。
評估 Kubernetes 使用情況
聽眾 Anton Zhbankov 向 Kubernetes 的辯護者提出了一個陷阱問題：你們是如何選擇並進行可行性研究的？ 例如，為什麼選擇 Kubernetes，為什麼不選擇虛擬機器？
Photo by
德米特里和伊凡回答了。 在這兩種情況下，透過反覆試驗，做出了一系列決定，最終參與者都來到了 Kubernetes。 現在，企業開始獨立開發適合轉移到 Kuber 的軟體。 我們不是在談論經典的第三方系統，例如1C。 當開發人員需要快速發布版本並進行不間斷的持續改進時，Kubernetes 會提供協助。
Andrey 的團隊嘗試建立一個基於虛擬機器的可擴展叢集。 節點像多米諾骨牌一樣倒下，有時會導致群集崩潰。 「理論上，你可以完成它並用手支撐它，但這很乏味。 如果市場上有解決方案可以讓您開箱即用，那麼我們很樂意採用。 結果我們就換了，」安德烈說。
這種分析和計算是有標準的，但沒有人能說它們在實際運行的硬體上有多準確。 對於計算來說，了解每個工具和生態系統也很重要，但這是不可能的。
等待我們的是什麼
Photo by
隨著技術的發展，越來越多不同的部件出現，然後發生相變，出現了一個供應商，他已經賺到了足夠的錢，可以將所有東西整合到一個工具中。
您認為 Linux 世界會出現像 Ubuntu 這樣的工具嗎？ 也許單一容器化和編排工具將包括 Kuber。 這將使建立本地雲端變得容易。
Ivan 給出了答案：“Google 現在正在構建 Anthos - 這是他們部署雲端的打包產品，包括 Kuber、Service Mesh、監控 - 本地微服務所需的所有硬體。” 我們幾乎就在未來。”
Denis 也提到 Nutanix 和 VMWare 以及 vRealize Suite 產品，無需容器化即可應付類似任務。
德米特里分享了他的觀點，減少「痛苦」和減稅是我們可以期待改進的兩個領域。
總結討論，我們強調現代基礎設施的以下問題：
- 三名參與者立即發現了 Stateful 的一個問題。
- 各種安全支援問題，包括 Docker 最終可能會出現多個版本的 Python、應用程式伺服器和元件。
超支，最好在單獨的會議上討論。
編排是一個複雜的生態系統，這是一個學習挑戰。
該行業的一個常見問題是工具的濫用。其餘的結論由你決定。 仍然有一種感覺，Docker+Kubernetes 組合要成為系統的「中心」部分並不容易。 例如作業系統是先安裝在硬體上的，容器和編排就更不用說了。 也許在未來，作業系統和容器將與雲端管理軟體合併。
Photo by我想藉此機會向我的母親問好並提醒您我們有一個 Facebook 群組 ， 渠道 以及來自各種技術部落格的有趣出版物。 還有我的頻道 ，我在這裡談論管理產品公司的開發。
來源： www.habr.com