URUS şirketi Kubernetes'i farklı biçimlerde denedi: Google Cloud'da çıplak donanım üzerinde bağımsız dağıtım ve ardından platformunu Mail.ru Bulut Çözümleri (MCS) bulutuna aktardı. Igor Shishkin, yeni bir bulut sağlayıcısını nasıl seçtiklerini ve ona iki saat gibi rekor bir sürede nasıl geçmeyi başardıklarını anlatıyor (URUS'ta kıdemli sistem yöneticisi.
URUS ne yapar?
Kentsel çevrenin kalitesini artırmanın birçok yolu vardır ve bunlardan biri de onu çevre dostu hale getirmektir. URUS - Akıllı Dijital Hizmetler şirketinin üzerinde çalıştığı şey tam olarak budur. Burada işletmelerin önemli çevresel göstergeleri izlemelerine ve çevre üzerindeki olumsuz etkilerini azaltmalarına yardımcı olan çözümleri uyguluyorlar. Sensörler hava bileşimi, gürültü seviyesi ve diğer parametrelere ilişkin verileri topluyor ve ardından bunları analiz ve önerilerde bulunmak üzere birleşik URUS-Ekomon platformuna gönderiyor.
URUS içeriden nasıl çalışır?
URUS'un tipik bir müşterisi, bir yerleşim bölgesinde veya yakınında bulunan bir şirkettir. Bu bir fabrika, liman, demiryolu deposu veya başka herhangi bir tesis olabilir. Müşterimiz zaten uyarı aldıysa, çevre kirliliği nedeniyle ceza aldıysa veya daha az gürültü yapmak, zararlı emisyon miktarını azaltmak istiyorsa bize geliyor ve biz de ona zaten çevre izleme konusunda hazır bir çözüm sunuyoruz.
H2S konsantrasyonu izleme grafiği, yakındaki bir tesisten kaynaklanan düzenli gece emisyonlarını gösterir
URUS'ta kullandığımız cihazlar, çevresel durumu değerlendirmek için belirli gazların içeriği, gürültü seviyeleri ve diğer veriler hakkında bilgi toplayan çeşitli sensörler içerir. Sensörlerin kesin sayısı her zaman özel göreve göre belirlenir.
Ölçümlerin özelliklerine bağlı olarak sensörlü cihazlar binaların duvarlarına, direklere ve diğer isteğe bağlı yerlere yerleştirilebilir. Bu tür cihazların her biri bilgileri toplar, bir araya getirir ve veri alan ağ geçidine gönderir. Burada verileri uzun süreli depolama için kaydediyoruz ve sonraki analiz için ön işleme tabi tutuyoruz. Analiz sonucunda elde ettiğimiz sonuçların en basit örneği AQI olarak da bilinen hava kalitesi indeksidir.
Buna paralel olarak platformumuzda birçok başka hizmet de faaliyet göstermektedir, ancak bunlar çoğunlukla hizmet niteliğindedir. Örneğin, izlenen parametrelerden herhangi birinin (örneğin, CO2 içeriği) izin verilen değeri aşması durumunda bildirim hizmeti istemcilere bildirim gönderir.
Verileri nasıl saklıyoruz? Kubernetes'in çıplak donanımdaki hikayesi
URUS çevresel izleme projesinde çeşitli veri ambarları bulunmaktadır. Birinde doğrudan cihazlardan aldığımız “ham” verileri saklıyoruz. Bu depolama, eski kasetlerde olduğu gibi, tüm göstergelerin geçmişine sahip "manyetik" bir banttır. İkinci depolama türü, önceden işlenmiş veriler için kullanılır - sensörler arasındaki bağlantılar ve cihazların kendi okumaları, kuruluşlarla ilişkiler, konumlar vb. hakkındaki meta verilerle zenginleştirilmiş cihazlardan gelen veriler. Bu bilgi, belirli bir göstergenin nasıl olduğunu dinamik olarak değerlendirmenize olanak tanır. belirli bir süre içinde değişti. "Ham" veri depolamayı, diğer şeylerin yanı sıra, yedekleme olarak ve ihtiyaç duyulması halinde önceden işlenmiş verileri geri yüklemek için kullanıyoruz.
Birkaç yıl önce depolama sorunumuzu çözmeye çalışırken iki platform seçeneğimiz vardı: Kubernetes ve OpenStack. Ancak ikincisi oldukça canavarca göründüğü için (buna ikna olmak için sadece mimarisine bakın), Kubernetes'te karar kıldık. Onun lehine olan bir başka argüman da nispeten basit yazılım kontrolü, donanım düğümlerini bile kaynaklara göre daha esnek bir şekilde kesebilme yeteneğiydi.
Kubernetes'te uzmanlaşmaya paralel olarak veri depolamanın yollarını da araştırdık, Kubernetes'teki tüm depolamamızı kendi donanımımızda tutarken mükemmel bir uzmanlık elde ettik. O zamanlar Kubernetes'te yaşadığımız her şey: durum bilgisi olan depolama, izleme sistemi, CI/CD. Kubernetes bizim için hepsi bir arada bir platform haline geldi.
Ancak biz Kubernetes'le bir hizmet olarak çalışmak, onun desteği ve geliştirilmesiyle uğraşmak istemedik. Ayrıca, onu çıplak donanımda tutmanın bize maliyetinin ne kadar olduğunu da beğenmedik ve sürekli olarak gelişmeye ihtiyacımız vardı! Örneğin ilk görevlerden biri Kubernetes Ingress denetleyicilerini kuruluşumuzun ağ altyapısına entegre etmekti. Bu, özellikle o dönemde DNS kayıtları veya IP adreslerinin tahsisi gibi programatik kaynak yönetimi için hiçbir şeyin hazır olmadığı göz önüne alındığında, hantal bir iştir. Daha sonra harici veri depolamayı denemeye başladık. PVC kontrolörünü hayata geçirmeyi hiçbir zaman başaramadık, ancak o zaman bile bunun özel uzmanlar gerektiren geniş bir çalışma alanı olduğu açıkça ortaya çıktı.
Google Cloud Platform'a geçiş geçici bir çözümdür
Bunun devam edemeyeceğini fark ettik ve verilerimizi yalın donanımdan Google Cloud Platform'a taşıdık. Aslında o zamanlar bir Rus şirketi için çok fazla ilgi çekici seçenek yoktu: Google Cloud Platform dışında yalnızca Amazon benzer bir hizmet sunuyordu, ancak biz yine de Google'ın çözümünde karar kıldık. O zaman bize ekonomik olarak daha karlı, Upstream'e daha yakın göründü, Google'ın kendisinin Üretimdeki bir tür PoC Kubernetes olduğu gerçeğinden bahsetmiyorum bile.
Müşteri tabanımız büyüdükçe ufukta ilk büyük sorun belirdi. Kişisel verileri saklamamız gerektiğinde bir seçimle karşı karşıya kaldık: Ya Google ile çalışıp Rusya yasalarını ihlal edeceğiz ya da Rusya Federasyonu'nda bir alternatif arıyoruz. Seçim genel olarak öngörülebilirdi. 🙂
İdeal bulut hizmetini nasıl gördük?
Aramanın başlangıcında geleceğin bulut sağlayıcısından ne almak istediğimizi zaten biliyorduk. Hangi hizmeti arıyorduk:
- Hızlı ve esnek. Öyle ki, istediğimiz zaman hızlı bir şekilde yeni bir düğüm ekleyebilir veya bir şeyi konuşlandırabiliriz.
- Ucuz. Kaynaklarımız kısıtlı olduğu için mali konulardan çok endişeliydik. Kubernetes ile çalışmak istediğimizi zaten biliyorduk ve şimdi görev, bu çözümü kullanmanın verimliliğini artırmak veya en azından korumak için maliyetini en aza indirmekti.
- Otomatik. Yöneticiler ve telefon görüşmeleri veya acil durum modunda birkaç düzine düğümü manuel olarak yükseltmemiz gereken durumlar olmadan API aracılığıyla hizmetle çalışmayı planladık. Süreçlerimizin çoğu otomatik olduğundan bulut hizmetinden de aynısını bekliyorduk.
- Rusya Federasyonu'ndaki sunucularla. Elbette Rus mevzuatına ve aynı 152-FZ'ye uymayı planladık.
O zamanlar Rusya'da az sayıda Kubernetes aaS sağlayıcısı vardı ve sağlayıcı seçerken önceliklerimizden taviz vermemek bizim için önemliydi. Birlikte çalışmaya başladığımız ve hala işbirliği içinde olduğumuz Mail.ru Bulut Çözümleri ekibi, bize API desteği ve Horizon'u içeren kullanışlı bir kontrol paneli ile tam otomatik bir hizmet sağladı; bununla isteğe bağlı sayıda düğümü hızlı bir şekilde yükseltebildik.
İki saat içinde MCS'ye geçmeyi nasıl başardık?
Bu tür hamlelerde birçok şirket zorluklarla ve aksiliklerle karşı karşıya kalıyor ama bizim durumumuzda böyle bir durum olmadı. Şanslıydık: Geçiş başlamadan önce zaten Kubernetes üzerinde çalıştığımızdan, yalnızca üç dosyayı düzelttik ve hizmetlerimizi yeni bulut platformu MCS'de başlattık. O zamana kadar nihayet çıplak metali bırakıp Google Cloud Platform'da yaşamaya başladığımızı hatırlatmama izin verin. Bu nedenle, taşıma işlemi iki saatten fazla sürmedi, ayrıca cihazlarımızdan veri kopyalamak için biraz daha fazla zaman (yaklaşık bir saat) harcandı. O zamanlar zaten Spinnaker'ı (Sürekli Teslimat için çoklu bulut CD hizmeti) kullanıyorduk. Biz de hızlı bir şekilde yeni kümeye ekledik ve her zamanki gibi çalışmaya devam ettik.
Geliştirme süreçlerinin ve CI/CD'nin otomasyonu sayesinde, URUS'ta Kubernetes tek bir uzman tarafından yönetiliyor (ve o da benim). Bir aşamada başka bir sistem yöneticisi benimle çalıştı, ancak daha sonra tüm ana rutini zaten otomatikleştirdiğimiz ve ana ürünümüzde giderek daha fazla görev olduğu ve kaynakları buna yönlendirmenin mantıklı olduğu ortaya çıktı.
Yanılsama olmadan işbirliğine başladığımızdan beri bulut sağlayıcısından beklediğimizi aldık. Herhangi bir olay yaşandıysa da bunlar çoğunlukla teknikti ve hizmetin göreceli tazeliğiyle kolaylıkla açıklanabilecek olaylardı. Önemli olan MCS ekibinin eksiklikleri hızlı bir şekilde ortadan kaldırması ve mesajlaşma programlarındaki sorulara hızlı bir şekilde yanıt vermesidir.
Deneyimimi Google Cloud Platform ile karşılaştırırsam, onların durumunda geri bildirim düğmesinin nerede olduğunu bile bilmiyordum çünkü buna gerek yoktu. Ve herhangi bir sorun meydana gelirse, Google tek taraflı olarak bildirim gönderiyordu. Ancak MCS söz konusu olduğunda, bence en büyük avantaj, Rus müşterilerine hem coğrafi hem de zihinsel olarak mümkün olduğunca yakın olmalarıdır.
Gelecekte bulutlarla çalışmayı nasıl görüyoruz?
Artık çalışmalarımız Kubernetes ile yakından bağlantılı ve altyapı görevleri açısından bize tamamen uyuyor. Bu nedenle, rutin görevleri basitleştirmek ve yenilerini otomatikleştirmek, hizmetlerin istikrarını ve güvenilirliğini artırmak için sürekli olarak yeni uygulamalar ve hizmetler tanıtıyor olsak da, buradan hiçbir yere geçmeyi planlamıyoruz... Şimdi Kaos Maymunu hizmetini başlatıyoruz (özellikle , Chaoskube kullanıyoruz ancak bu, orijinal olarak Netflix tarafından oluşturulan konsepti değiştirmiyor: ). Kaos Maymunu basit bir şey yapar: rastgele bir Kubernetes bölmesini rastgele bir zamanda siler. Bu, hizmetimizin n-1 örnek sayısıyla normal şekilde çalışması için gereklidir, bu nedenle kendimizi herhangi bir soruna hazırlıklı olmak üzere eğitiriz.
Artık genç şirketler için üçüncü taraf çözümlerin (aynı bulut platformlarının) kullanımını tek doğru şey olarak görüyorum. Genellikle yolculuklarının başlangıcında hem insani hem de finansal kaynaklar sınırlıdır ve kendi bulut veya veri merkezlerini oluşturmak ve sürdürmek çok pahalı ve emek yoğundur. Bulut sağlayıcıları bu maliyetleri en aza indirmenize olanak tanır; hizmetlerin burada ve şimdi çalışması için gerekli kaynakları onlardan hızlı bir şekilde elde edebilir ve bu kaynaklar için ödeme yaptıktan sonra ödeme yapabilirsiniz. URUS şirketine gelince, şimdilik buluttaki Kubernetes'e sadık kalacağız. Ancak kim bilir, coğrafi olarak genişlememiz veya bazı spesifik ekipmanlara dayalı çözümler uygulamamız gerekebilir. Veya belki de tüketilen kaynak miktarı, eski güzel günlerde olduğu gibi kendi Kubernet'lerinizi çıplak metal üzerinde haklı çıkaracaktır. 🙂
Bulut hizmetleriyle çalışmaktan öğrendiklerimiz
Kubernetes'i çıplak metalde kullanmaya başladık ve orada bile kendi çapında iyiydi. Ancak güçlü yönleri tam olarak buluttaki bir aaS bileşeni olarak ortaya çıktı. Bir hedef belirler ve her şeyi mümkün olduğu kadar otomatikleştirirseniz, satıcıya bağımlı kalmayı önlemiş olursunuz ve bulut sağlayıcılar arasında geçiş yapmak birkaç saat sürecektir ve sinir hücrelerimiz bizimle kalacaktır. Diğer şirketlere tavsiyelerde bulunabiliriz: Sınırlı kaynaklara ve maksimum geliştirme hızına sahip olarak kendi (bulut) hizmetinizi başlatmak istiyorsanız, hemen bulut kaynaklarını kiralayarak başlayın ve Forbes sizin hakkınızda yazdıktan sonra veri merkezinizi oluşturun.
Kaynak: habr.com