Ey Habr!
Exness platform ekibini temsil ediyoruz. Daha önce meslektaşlarımız bu konuda bir makale yazmıştı. . Bugün hizmetleri Kubernetes'e taşıma deneyimimizi paylaşmak istiyoruz.
Başlangıç olarak, neyin tartışılacağını daha iyi anlamanız için size bazı rakamlar sunuyoruz:
- Geliştirme departmanımız, kendi kendine yeten QA, DevOps ve Scrum süreçlerine sahip 100'dan fazla farklı ekip dahil olmak üzere 10'den fazla kişiden oluşmaktadır. Geliştirme yığını - Python, PHP, C++, Java ve Golang.
- Test ve üretim ortamlarının boyutu her biri yaklaşık 2000 konteynerdir. Rancher v1.6'yı kendi sanallaştırmalarında ve VMware altında çalıştırıyorlar.
Motivasyon
Dedikleri gibi, hiçbir şey sonsuza kadar sürmez ve Rancher çok uzun zaman önce 1.6 sürümüne yönelik desteğin sona erdiğini duyurdu. Evet, üç yıldan fazla bir süre içinde onu nasıl hazırlayacağımızı ve ortaya çıkan sorunları nasıl çözeceğimizi öğrendik, ancak giderek daha fazla asla düzeltilemeyecek sorunlarla karşı karşıya kalıyoruz. Rancher 1.6 ayrıca hakların verilmesi için kemikleşmiş bir sisteme sahiptir; burada ya hemen hemen her şeyi yapabilirsiniz ya da hiçbir şey yapamazsınız.
Tescilli sanallaştırma, veri depolama ve güvenliği üzerinde daha fazla kontrol sağlamasına rağmen, şirketin sürekli büyümesi, proje sayısı ve bunlara yönelik gereksinimler göz önüne alındığında kabul edilmesi zor olan işletme maliyetlerini zorunlu kılıyordu.
IaC standartlarını takip etmek ve gerekirse herhangi bir coğrafi konumda, satıcı bağımlılığı olmadan hızlı bir şekilde kapasite elde etmek ve aynı zamanda bundan hızla vazgeçebilmek istedik.
İlk Adımlar
Her şeyden önce, ekiplerin daha hızlı bir geliştirme döngüsüne sahip olmalarını sağlayacak ve güç sağlayan platformla etkileşime ilişkin operasyonel maliyetleri en aza indirecek modern teknolojilere ve çözümlere güvenmek istedik.
Elbette aklımıza ilk gelen Kubernetes oldu ama biz heyecanlanmadık ve doğru seçim olup olmadığını görmek için biraz araştırma yaptık. Yalnızca açık kaynaklı çözümleri değerlendirdik ve adil olmayan bir savaşta Kubernetes kayıtsız şartsız kazandı.
Daha sonra küme oluşturmak için bir araç seçme sorunu geldi. En popüler çözümleri karşılaştırdık: kops, kubespray, kubeadm.
Başlangıçta kubeadm bize çok karmaşık bir yol gibi göründü, bir tür "bisiklet" mucidi gibi görünüyordu ve kops yeterince esnekliğe sahip değildi.
Ve kazanan:
Herkesin aynı "kümeyi" paylaştığı önceki kaynak yönetimi modelimize kabaca benzer bir şeyi yeniden oluşturmaya çalışarak kendi sanallaştırmamız ve AWS'mizle denemeler yapmaya başladık. Ve şimdi, birkaçı AWS'de bulunan 10 küçük sanal makineden oluşan ilk kümemize sahibiz. Ekipleri oraya taşımaya çalıştık, her şey "iyi" görünüyordu ve hikaye tamamlanabilirdi ama...
İlk Sorunlar
Ansible, kubespray'in üzerine inşa edildiği şeydir, IaC'yi takip etmenize izin veren bir araç değildir: düğümleri devreye alırken/devre dışı bırakırken, bir şeyler sürekli ters gitti ve bir tür müdahale gerekliydi ve farklı işletim sistemleri kullanıldığında, taktik kitabı farklı davrandı. . Kümedeki takımların ve düğümlerin sayısı arttıkça, taktik kitabının tamamlanmasının giderek daha uzun sürdüğünü fark etmeye başladık ve sonuç olarak rekorumuz 3,5 saat oldu, peki ya sizinki? 🙂
Görünüşe göre kubespray sadece Ansible ve ilk bakışta her şey açık, ama:
Yolculuğun başlangıcında görev yalnızca AWS'de ve sanallaştırmada kapasiteleri başlatmaktı, ancak daha sonra çoğu zaman olduğu gibi gereksinimler değişti.
Bunun ışığında, kümelerin çok uzak olduğu ve farklı sağlayıcılar tarafından yönetildiği durumlarda, kaynakları tek bir düzenleme sisteminde birleştirmeye yönelik eski modelimizin uygun olmadığı ortaya çıktı.
Üstelik. Tüm ekipler aynı küme içinde çalıştığında, NodeSelector'ların yanlış takıldığı çeşitli hizmetler başka bir ekibin "yabancı" ana bilgisayarına uçabilir ve oradaki kaynakları kullanabilir ve eğer kusur ayarlanmışsa, bir veya başka bir hizmetin çalışmadığına dair sürekli talepler olabiliyordu. İnsan faktörü nedeniyle doğru şekilde dağıtılmıyor. Diğer bir sorun ise, özellikle hizmetlerin düğümler arasında dağıtılmasındaki sorunlar göz önüne alındığında, maliyetin hesaplanmasıydı.
Çalışanlara hakların verilmesi ayrı bir hikayeydi: Her takım kümenin "başında" olmak ve onu tamamen yönetmek istiyordu, bu da takımlar temelde birbirlerinden bağımsız olduğu için tam bir çöküşe neden olabilirdi.
Ne yapmalı?
Yukarıdakileri ve ekiplerin daha bağımsız olma isteklerini dikkate alarak basit bir sonuca vardık: bir ekip - bir küme.
Böylece ikinci bir tane daha aldık:
Ve sonra üçüncü küme:
Sonra düşünmeye başladık: Diyelim ki bir yıl içinde takımlarımızın birden fazla kümesi olacak? Örneğin farklı coğrafi bölgelerde mi yoksa farklı sağlayıcıların kontrolü altında mı? Ve bazıları, bazı testler için hızlı bir şekilde geçici bir kümeyi dağıtabilmek isteyecektir.
Tam Kubernet'ler gelecek! Bunun bir tür MultiKubernetes olduğu ortaya çıktı.
Aynı zamanda, hepimizin bir şekilde tüm bu kümelerin bakımını yapması, onlara erişimi kolayca yönetebilmesi, yenilerini oluşturabilmesi ve eskilerini manuel müdahale olmadan hizmetten çıkarabilmesi gerekecek.
Kubernetes dünyasındaki yolculuğumuzun başlangıcından bu yana biraz zaman geçti ve mevcut çözümleri yeniden incelemeye karar verdik. Piyasada zaten mevcut olduğu ortaya çıktı - Rancher 2.2.
Araştırmamızın ilk aşamasında Rancher Labs, sürüm 2'nin ilk sürümünü zaten yapmıştı, ancak birkaç parametreyle veya resmi HELM Tablosu kullanılarak harici bağımlılıkları olmayan bir konteynerin başlatılmasıyla çok hızlı bir şekilde yükseltilebilmesine rağmen, kaba görünüyordu Bize göre bu karara güvenip güvenemeyeceğimizi, geliştirilip geliştirilmeyeceğini veya hızla terk edilip edilemeyeceğini bilmiyorduk. Kullanıcı arayüzündeki küme = tıklamalar paradigması da bize uymadı ve oldukça dar odaklı bir araç olduğu için RKE'ye bağlı kalmak istemedik.
Sürüm Rancher 2.2 zaten daha kullanışlı bir görünüme sahipti ve öncekilerle birlikte, birçok harici sağlayıcıyla entegrasyon, hakların ve kubeconfig dosyalarının tek bir dağıtım noktası, kubectl başlatılması gibi kutudan çıkan bir dizi ilginç özelliğe sahipti. kullanıcı arayüzündeki haklarınızı içeren resim, iç içe ad alanları, diğer adıyla projeler.
Ayrıca Rancher 2'nin etrafında zaten oluşturulmuş bir topluluk vardı ve bunu yönetmek için HashiCorp Terraform adında bir sağlayıcı oluşturuldu ve bu da her şeyi bir araya getirmemize yardımcı oldu.
Ne oldu
Sonuç olarak, Rancher'ı çalıştıran, diğer tüm kümelerin yanı sıra ona bağlı birçok kümenin erişebildiği küçük bir küme elde ettik; bunlardan herhangi birine erişim, ldap dizinine bir kullanıcı eklemek kadar basit bir şekilde verilebiliyor. nerede bulunduğu ve hangi sağlayıcının kaynaklarını kullandığı.
Gitlab-ci ve Terraform kullanılarak, bulut sağlayıcılarda veya kendi altyapımızda herhangi bir konfigürasyonun kümesini oluşturup bunları Rancher'a bağlamanıza olanak tanıyan bir sistem oluşturuldu. Tüm bunlar, her kümenin bir depo tarafından tanımlandığı ve durumunun sürümlendirildiği IaC tarzında yapılır. Aynı zamanda çoğu modül harici depolardan bağlanır, böylece geriye yalnızca değişkenleri iletmek veya örnekler için özel yapılandırmanızı tanımlamak kalır; bu da kod tekrarı yüzdesinin azaltılmasına yardımcı olur.
Elbette yolculuğumuz henüz bitmedi ve önümüzde hâlâ birçok ilginç görev var; örneğin herhangi bir kümenin günlükleri ve ölçümleriyle tek bir çalışma noktası, hizmet ağı, çoklu kümedeki yükleri yönetmek için gitop'lar ve çok daha fazlası. Deneyimimizi ilginç bulacağınızı umuyoruz!
Makale Platform Mühendisleri A. Antipov, A. Ganush tarafından yazılmıştır.
Kaynak: habr.com