URUS 公司嘗試了不同形式的 Kubernetes：在裸機、Google Cloud 中獨立部署，然後將其平台轉移到 Mail.ru Cloud Solutions (MCS) 雲端。 Igor Shishkin 講述了他們如何選擇新的雲端提供者以及如何在創紀錄的兩小時內遷移到該提供者（），URUS 高級系統管理員。
URUS 有什麼作用？
改善城市環境品質的方法有很多，其中之一就是環境友善。 這正是 URUS（智慧數位服務公司）正在致力於的事情。 他們在這裡實施解決方案，幫助企業監控重要的環境指標並減少對環境的負面影響。 感測器收集空氣成分、噪音水平和其他參數的數據，然後將其發送到統一的 URUS-Ekomon 平台進行分析並提出建議。
URUS 的內部運作原理
URUS 的典型客戶是位於住宅區或住宅區附近的公司。 這可以是工廠、港口、火車站或任何其他設施。 如果我們的客戶已經收到警告，因環境污染被罰款，或者想要減少噪音，減少有害排放量，他來找我們，我們已經為他提供了現成的環境監測解決方案。
硫化氫濃度監測圖顯示附近工廠夜間定期排放
我們在 URUS 使用的設備包含多個感測器，這些感測器收集有關某些氣體含量、噪音水平和其他數據的信息，以評估環境狀況。 感測器的確切數量始終由具體任務決定。
根據測量的具體情況，帶有感測器的設備可以放置在建築物的牆壁、電線桿和其他任意位置。 每個這樣的設備收集資訊、聚合資訊並將其傳送到資料接收網關。 在那裡，我們保存資料以供長期存儲，並對其進行預處理以供後續分析。 我們得到的分析結果最簡單的例子是空氣品質指數，也稱為 AQI。
同時，許多其他服務也在我們的平台上運行，但它們主要是服務性質的。 例如，如果任何監控參數（例如二氧化碳含量）超過允許值，通知服務就會向客戶端發送通知。
我們如何儲存資料。 裸機上 Kubernetes 的故事
URUS環境監測專案有多個資料倉儲。 在其中，我們保留「原始」資料——我們直接從裝置本身接收到的資料。 該儲存是一個“磁帶”，就像舊的盒式磁帶一樣，具有所有指標的歷史記錄。 第二種類型的儲存用於預處理數據- 來自設備的數據，其中包含有關感測器之間的連接和設備本身的讀數、與組織、位置等的隸屬關係的元數據。這些資訊可讓您動態評估特定指標的表現在一定時間內會改變。 除此之外，我們使用「原始」資料儲存作為備份和還原預處理資料（如果出現這種需要）。
幾年前，當我們尋求解決儲存問題時，我們有兩個平台選擇：Kubernetes 和 OpenStack。 但由於後者看起來相當可怕（只要看看它的架構就可以確信這一點），我們選擇了 Kubernetes。 支持它的另一個論點是相對簡單的軟體控制，能夠根據資源更靈活地削減硬體節點。
在掌握 Kubernetes 本身的同時，我們也研究了儲存資料的方法，同時我們將 Kubernetes 中的所有儲存都保留在我們自己的硬體上，我們獲得了出色的專業知識。 我們當時的一切都生活在 Kubernetes 上：有狀態儲存、監控系統、CI/CD。 Kubernetes 已成為我們的一體化平台。
但我們希望將 Kubernetes 作為一項服務來使用，而不是參與其支援和開發。 另外，我們不喜歡在裸機上維護它的成本，而且我們需要不斷開發！ 例如，首要任務之一是將 Kubernetes Ingress 控制器整合到我們組織的網路基礎設施中。 這是一項繁瑣的任務，特別是考慮到當時還沒有準備好用於程序化資源管理（例如 DNS 記錄或 IP 位址分配）的資源。 後來我們開始嘗試外部資料儲存。 我們從未抽出時間來實施 PVC 控制器，但即便如此，我們仍然清楚這是一個需要專門專家的大範圍工作。
切換到 Google Cloud Platform 是一個臨時解決方案
我們意識到這種情況無法持續下去，並將我們的資料從裸機轉移到 Google Cloud Platform。 事實上，當時俄羅斯公司並沒有太多有趣的選擇：除了Google雲端平台之外，只有亞馬遜提供類似的服務，但我們仍然選擇了Google的解決方案。 那麼在我們看來，它在經濟上更有利可圖，更接近上游，更不用說谷歌本身就是生產中的一種PoC Kubernetes。
隨著我們客戶群的成長，第一個主要問題出現了。 當我們需要儲存個人資料時，我們面臨一個選擇：要么與Google合作並違反俄羅斯法律，要么在俄羅斯聯邦尋找替代方案。 總的來說，這個選擇是可以預見的。 🙂
我們如何看待理想的雲端服務
在搜尋開始時，我們已經知道我們想從未來的雲端供應商那裡得到什麼。 我們正在尋找什麼服務：
- 快速靈活。 這樣我們就可以隨時快速新增節點或部署某些東西。
- 便宜。 我們非常擔心財務問題，因為我們的資源有限。 我們已經知道我們想要使用 Kubernetes，現在的任務是最大限度地降低其成本，以提高或至少保持使用解決方案的效率。
- 自動的。 我們計劃透過 API 使用該服務，無需經理和電話，也無需在緊急模式下手動啟動數十個節點。 由於我們的大多數流程都是自動化的，因此我們對雲端服務的期望也是如此。
- 伺服器位於俄羅斯聯邦。 當然，我們計劃遵守俄羅斯立法和 152-FZ。
當時，俄羅斯的 Kubernetes aaS 提供者很少，在選擇提供者時，對我們來說重要的是不要妥協我們的優先事項。 Mail.ru 雲端解決方案團隊是我們開始合作並仍在合作的團隊，他們為我們提供了完全自動化的服務，提供API 支援和方便的控制面板，其中包括Horizon - 借助它，我們可以快速提升任意數量的節點。
我們如何在兩小時內成功遷移到 MCS
在這樣的過程中，很多企業都會遇到困難和挫折，但我們沒有。 我們很幸運：由於在遷移開始之前我們已經在 Kubernetes 上工作，我們只需更正三個檔案並在新的雲端平台 MCS 上啟動我們的服務。 讓我提醒您，那時我們終於離開了裸機並住在 Google Cloud Platform 上。 因此，移動本身花費的時間不超過兩個小時，再加上從我們的設備複製資料所花費的時間（大約一個小時）。 當時我們已經在使用 Spinnaker（一種用於持續交付的多雲 CD 服務）。 我們也很快將其添加到新集群中並繼續照常工作。
由於開發流程和 CI/CD 的自動化，URUS 的 Kubernetes 由一位專家（那就是我）負責處理。 在某個階段，另一位系統管理員與我一起工作，但後來發現我們已經自動化了所有主要例程，並且我們的主要產品的任務越來越多，因此將資源用於此是有意義的。
我們從雲端提供者那裡得到了我們所期望的，因為我們不抱任何幻想地開始了合作。 如果發生任何事件，它們大多是技術性的，並且可以輕鬆地用服務的相對新鮮度來解釋。 最主要的是MCS團隊快速消除缺點並快速回覆Messenger中的問題。
如果我將我的體驗與 Google Cloud Platform 進行比較，在他們的情況下，我甚至不知道反饋按鈕在哪裡，因為根本不需要它。 如果確實出現任何問題，Google也會單方面發出通知。 但就 MCS 而言，我認為最大的優勢是他們盡可能接近俄羅斯客戶——無論是在地理上還是在精神上。
我們如何看待未來的雲端合作
現在我們的工作與 Kubernetes 緊密相關，從基礎設施任務的角度來看它完全適合我們。 因此，我們不打算從它遷移到任何地方，儘管我們不斷引入新的實踐和服務來簡化日常任務並自動化新任務，提高服務的穩定性和可靠性......我們現在推出Chaos Monkey 服務（具體來說是，我們使用chaoskube，但這並沒有改變概念：），它最初是由Netflix創建的。 Chaos Monkey 做了一件簡單的事：它在隨機時間刪除一個隨機 Kubernetes pod。 這對於我們的服務在實例數量為 n-1 的情況下正常運作是必要的，因此我們訓練自己為任何問題做好準備。
現在，我認為使用第三方解決方案（相同的雲端平台）是年輕公司唯一正確的選擇。 通常，在他們的旅程開始時，他們的人力和財力資源都有限，並且建立和維護自己的雲端或資料中心過於昂貴且勞動密集。 雲端供應商可以讓您最大限度地降低這些成本；您可以從他們那裡快速獲取此時此刻運行服務所需的資源，並在事後為這些資源付費。 至於URUS公司，我們目前仍將忠於雲端中的Kubernetes。 但誰知道呢，我們可能必須擴大地域，或實施基於某些特定設備的解決方案。 或者，消耗的資源量可能會證明在裸機上使用 Kubernetes 是合理的，就像過去的美好時光一樣。 🙂
我們從使用雲端服務中學到了什麼
我們開始在裸機上使用 Kubernetes，即使在那裡它也以自己的方式表現良好。 但它的優勢恰恰是作為雲端中的 aaS 組件展現出來的。 如果你設定一個目標並盡可能地自動化一切，你將能夠避免供應商鎖定，並且在雲端提供者之間移動將需要幾個小時，而神經細胞將留在我們身邊。 我們可以建議其他公司：如果您想推出自己的（雲端）服務，但資源有限且開發速度最快，請立即開始租用雲端資源，並在《富比士》報道您之後建立您的資料中心。
來源： www.habr.com