Not. tercüme: GitLab'da Kubernetes'in benimsenmesi, şirketin büyümesine katkıda bulunan iki ana faktörden biri olarak kabul ediliyor. Ancak yakın zamana kadar GitLab.com çevrimiçi hizmetinin altyapısı sanal makineler üzerine kuruluydu ve yaklaşık bir yıl önce K8'lere geçişi henüz tamamlanmadı. Bunun nasıl gerçekleştiği ve projeye katılan mühendislerin ne gibi sonuçlar çıkardıkları hakkında bir GitLab SRE mühendisi tarafından yazılan yakın tarihli bir makalenin çevirisini sunmaktan mutluluk duyuyoruz.
Yaklaşık bir yıldır altyapı bölümümüz GitLab.com'da çalışan tüm hizmetleri Kubernetes'e taşıyor. Bu süre zarfında yalnızca hizmetlerin Kubernetes'e taşınmasıyla ilgili değil, aynı zamanda geçiş sırasında hibrit dağıtımın yönetilmesiyle ilgili zorluklarla da karşılaştık. Öğrendiğimiz değerli dersler bu makalede tartışılacaktır.
GitLab.com'un en başından beri sunucuları sanal makinelerde bulutta çalışıyordu. Bu sanal makineler Chef tarafından yönetilir ve bizim sistemimiz kullanılarak kurulur. . Uygulamanın güncellenmesi gerektiğinde sunucu filosunun bir CI hattı kullanılarak koordineli ve sıralı bir şekilde güncellenmesinden oluşur. Bu yöntem - yavaş ve biraz da olsa - GitLab.com'un çevrimdışı kullanıcılarla aynı kurulum ve yapılandırma uygulamalarını kullanmasını sağlar (kendi kendine yönetilen) Bunun için Linux paketlerimizi kullanarak GitLab kurulumları.
Bu yöntemi kullanıyoruz çünkü topluluğun sıradan üyelerinin GitLab kopyalarını kurarken ve yapılandırırken yaşadığı tüm üzüntüleri ve sevinçleri deneyimlemek son derece önemli. Bu yaklaşım bir süre işe yaradı ancak GitLab'daki proje sayısı 10 milyonu aştığında artık ölçeklendirme ve dağıtım ihtiyaçlarımızı karşılamadığını fark ettik.
Kubernetes'e ve bulut tabanlı GitLab'a ilk adımlar
Proje 2017 yılında oluşturuldu GitLab'ı bulut dağıtımına hazırlamak ve kullanıcıların GitLab'ı Kubernetes kümelerine yüklemesine olanak sağlamak. O zamanlar GitLab'ı Kubernetes'e taşımanın SaaS platformunun ölçeklenebilirliğini artıracağını, dağıtımları basitleştireceğini ve bilgi işlem kaynaklarının verimliliğini artıracağını biliyorduk. Aynı zamanda uygulamamızın birçok işlevi, sanal makinelerden geçişi yavaşlatan monte edilmiş NFS bölümlerine bağlıydı.
Bulut yereline ve Kubernetes'e doğru ilerleme, mühendislerimizin kademeli bir geçiş planlamasına olanak tanıdı; bu sırada, yeni özellikler geliştirmeye devam ederken uygulamanın bazı ağ depolama bağımlılıklarından vazgeçtik. 2019 yazında geçişi planlamaya başladığımızdan bu yana bu sınırlamaların çoğu çözüldü ve GitLab.com'u Kubernetes'e taşıma süreci artık iyi bir şekilde devam ediyor!
Kubernetes'te GitLab.com'un özellikleri
GitLab.com için tüm uygulama trafiğini yöneten tek bir bölgesel GKE kümesi kullanıyoruz. (Zaten zor olan) geçişin karmaşıklığını en aza indirmek için, yerel depolamaya veya NFS'ye dayanmayan hizmetlere odaklanıyoruz. GitLab.com ağırlıklı olarak yekpare bir Rails kod tabanı kullanıyor ve trafiği iş yükü özelliklerine göre kendi düğüm havuzlarında izole edilmiş farklı uç noktalara yönlendiriyoruz.
Ön uç durumunda, bu türler web, API, Git SSH/HTTPS ve Kayıt Defterine yönelik isteklere bölünmüştür. Arka uç durumunda, kuyruktaki işleri çeşitli özelliklere göre böleriz. çeşitli iş yükleri için Hizmet Düzeyi Hedefleri (SLO'lar) belirlememize olanak tanır.
Bu GitLab.com hizmetlerinin tümü, değiştirilmemiş bir GitLab Helm grafiği kullanılarak yapılandırılmıştır. Yapılandırma, hizmetleri yavaş yavaş kümeye taşırken seçici olarak etkinleştirilebilen alt çizelgelerde gerçekleştirilir. Redis, Postgres, GitLab Pages ve Gitaly gibi bazı durum bilgisi olan hizmetlerimizi geçişe dahil etmemeye karar vermiş olsak da Kubernetes'i kullanmak, Chef'in şu anda yönettiği VM sayısını radikal bir şekilde azaltmamıza olanak tanıyor.
Kubernetes Yapılandırması Görünürlüğü ve Yönetimi
Tüm ayarlar GitLab'ın kendisi tarafından yönetilir. Bunun için Terraform ve Helm tabanlı üç konfigürasyon projesi kullanılmaktadır. GitLab'ı çalıştırmak için mümkün olduğunca GitLab'ın kendisini kullanmaya çalışıyoruz, ancak operasyonel görevler için ayrı bir GitLab kurulumumuz var. Bu, GitLab.com dağıtımlarını ve güncellemelerini gerçekleştirirken GitLab.com'un kullanılabilirliğine bağımlı olmadığınızdan emin olmak için gereklidir.
Kubernetes kümesine yönelik işlem hatlarımız ayrı bir GitLab kurulumunda çalışsa da kod depolarının aşağıdaki adreslerde herkese açık olan yansımaları vardır:
- — GitLab Helm grafiği için GitLab.com yapılandırma çerçevesi;
- - GitLab uygulamasıyla doğrudan ilişkili olmayan hizmetlere ilişkin yapılandırmaları içerir. Bunlar, günlük kaydı ve küme izleme için yapılandırmaların yanı sıra PlantUML gibi entegre araçları içerir;
- — Kubernetes ve eski VM altyapısı için Terraform yapılandırması. Burada kümenin kendisi, düğüm havuzları, hizmet hesapları ve IP adresi rezervasyonları da dahil olmak üzere kümeyi çalıştırmak için gereken tüm kaynakları yapılandırırsınız.
Değişiklikler yapıldığında genel görünüm gösterilir. SRE'nin kümede değişiklik yapmadan önce analiz ettiği ayrıntılı farka bir bağlantı ile.
SRE için bağlantı, üretim için kullanılan ve erişimin kısıtlı olduğu GitLab kurulumunda ayrıntılı bir farklılığa yol açar. Bu, çalışanların ve topluluğun (yalnızca SRE'lere açık olan) operasyonel projeye erişimi olmadan önerilen yapılandırma değişikliklerini görüntülemesine olanak tanır. Kod için genel bir GitLab örneğini CI ardışık düzenleri için özel bir örnekle birleştirerek, yapılandırma güncellemeleri için GitLab.com'dan bağımsızlığı garantilerken tek bir iş akışını sürdürüyoruz.
Taşıma sırasında öğrendiklerimiz
Taşıma sırasında Kubernetes'teki yeni geçişler ve dağıtımlara uyguladığımız deneyimler kazanıldı.
1. Erişilebilirlik bölgeleri arasındaki trafik nedeniyle artan maliyetler
GitLab.com'daki Git deposu filosu için günlük çıkış istatistikleri (günlük bayt)
Google ağını bölgelere ayırıyor. Bunlar da erişilebilirlik bölgelerine (AZ) bölünmüştür. Git barındırma büyük miktarda veriyle ilişkilidir, bu nedenle ağ çıkışını kontrol etmek bizim için önemlidir. Dahili trafik için çıkış, yalnızca aynı kullanılabilirlik alanı içinde kalması durumunda ücretsizdir. Bu yazının yazıldığı an itibarıyla, tipik bir iş gününde yaklaşık 100 TB veri sunuyoruz (ve bu yalnızca Git depoları içindir). Eski VM tabanlı topolojimizde aynı sanal makinelerde bulunan hizmetler artık farklı Kubernetes bölmelerinde çalışıyor. Bu, daha önce sanal makinede yerel olan trafiğin bir kısmının potansiyel olarak kullanılabilirlik bölgelerinin dışına çıkabileceği anlamına gelir.
Bölgesel GKE kümeleri, yedeklilik için birden fazla Erişilebilirlik Alanını yaymanıza olanak tanır. Olasılığı değerlendiriyoruz Büyük miktarda trafik oluşturan hizmetler için. Bu, küme düzeyinde artıklığı korurken çıkış maliyetlerini azaltacaktır.
2. Sınırlar, kaynak istekleri ve ölçeklendirme
Registry.gitlab.com'da üretim trafiğini işleyen kopyaların sayısı. Trafik ~15:00 UTC'de zirveye çıkar.
Geçiş hikayemiz, ilk hizmetimiz olan GitLab Container Registry'yi Kubernetes'e taşıdığımız Ağustos 2019'da başladı. Görev açısından kritik, yüksek trafiğe sahip bu hizmet, çok az dış bağımlılığı olan durum bilgisi olmayan bir uygulama olduğundan, ilk geçiş için iyi bir seçimdi. Karşılaştığımız ilk sorun, düğümlerdeki bellek eksikliğinden dolayı çok sayıda bölmenin çıkarılmasıydı. Bu nedenle istekleri ve limitleri değiştirmek zorunda kaldık.
Bellek tüketiminin zamanla arttığı bir uygulama durumunda, istekler için düşük değerlerin (her kapsül için bellek ayırma) kullanımda "cömer" bir katı sınırla birleştiğinde doygunluğa yol açtığı keşfedildi. (doyma) düğümler ve yüksek düzeyde tahliye. Bu sorunla başa çıkmak için . Bu, düğümlerdeki baskıyı kaldırdı ve bölmelerin, düğüm üzerinde çok fazla baskı oluşturmayan bir yaşam döngüsüne sahip olmasını sağladı. Artık geçişlere cömert (ve neredeyse aynı) istek ve sınır değerleriyle başlıyoruz ve bunları gerektiği gibi ayarlıyoruz.
3. Metrikler ve günlükler
Altyapı bölümü, kurulu sistemlerde gecikmeye, hata oranlarına ve doygunluğa odaklanır. (SLO) ile bağlantılı .
Geçtiğimiz yıl, altyapı bölümündeki en önemli olaylardan biri, TİG'lerin izlenmesi ve onlarla çalışma konusundaki gelişmeler oldu. SLO'lar, geçiş sırasında yakından takip ettiğimiz bireysel hizmetler için hedefler belirlememize olanak sağladı. Ancak bu gelişmiş gözlemlenebilirliğe rağmen, ölçümleri ve uyarıları kullanarak sorunları anında görmek her zaman mümkün olmuyor. Örneğin, gecikme ve hata oranlarına odaklandığımızdan, geçişi yapılan bir hizmetin tüm kullanım durumlarını tam olarak kapsamıyoruz.
Bu sorun, bazı iş yüklerinin kümeye taşınmasından hemen sonra keşfedildi. İstek sayısının az olduğu ancak çok özel yapılandırma bağımlılıkları olan işlevleri kontrol etmek zorunda kaldığımızda bu durum özellikle akut hale geldi. Geçişten alınan en önemli derslerden biri, izleme sırasında yalnızca metriklerin değil, aynı zamanda günlüklerin ve "uzun kuyruğun" da dikkate alınması gerektiğiydi. (bu ... Hakkında grafikte - yakl. çeviri.) hatalar. Artık her geçiş için günlük sorgularının ayrıntılı bir listesini ekliyoruz (günlük sorguları) ve sorun çıkması durumunda bir vardiyadan diğerine aktarılabilecek net geri alma prosedürlerini planlayın.
Aynı isteklerin eski VM altyapısında ve yeni Kubernetes tabanlı altyapıda paralel olarak sunulması benzersiz bir zorluk teşkil ediyordu. Kaldırma ve kaydırma geçişinden farklı olarak (uygulamaların “olduğu gibi” yeni bir altyapıya hızlı aktarımı; daha fazla ayrıntı okunabilir, örneğin, - yaklaşık. çeviri.)"Eski" VM'ler ve Kubernetes üzerinde paralel çalışma, izleme araçlarının her iki ortamla uyumlu olmasını ve metrikleri tek bir görünümde birleştirebilmesini gerektirir. Geçiş döneminde tutarlı gözlemlenebilirlik elde etmek için aynı kontrol panellerini ve günlük sorgularını kullanmamız önemlidir.
4. Trafiği yeni bir kümeye geçirme
GitLab.com için sunucuların bir kısmı şuraya ayrılmıştır: . Canary Park şirket içi projelerimize hizmet vermektedir ve ayrıca . Ancak öncelikle altyapı ve uygulamada yapılan değişiklikleri test etmek için tasarlanmıştır. Geçirilen ilk hizmet, sınırlı miktarda dahili trafiği kabul ederek başladı ve tüm trafiği kümeye göndermeden önce SLO'ların karşılandığından emin olmak için bu yöntemi kullanmaya devam ediyoruz.
Geçiş durumunda bu, dahili projelere yönelik isteklerin önce Kubernetes'e gönderildiği ve ardından HAProxy aracılığıyla arka ucun ağırlığını değiştirerek trafiğin geri kalanını yavaş yavaş kümeye aktardığımız anlamına gelir. VM'den Kubernetes'e geçiş sırasında, eski ve yeni altyapı arasındaki trafiği yönlendirmenin kolay bir yoluna sahip olmanın ve buna bağlı olarak eski altyapıyı geçişten sonraki ilk birkaç gün içinde geri almaya hazır tutmanın çok faydalı olduğu ortaya çıktı.
5. Baklaların rezerv kapasiteleri ve kullanımları
Hemen hemen şu sorun tespit edildi: Kayıt Defteri hizmetine yönelik bölmeler hızlı bir şekilde başladı, ancak Sidekiq için bölmelerin başlatılması XNUMX saat sürdü. . Sidekiq kapsüllerinin uzun başlatma süresi, işleri hızlı bir şekilde işlemesi ve hızlı bir şekilde ölçeklendirmesi gereken çalışanlar için iş yüklerini Kubernetes'e taşımaya başladığımızda sorun haline geldi.
Bu durumda alınan ders, Kubernetes'in Yatay Kapsül Otomatik Ölçekleyicisi (HPA) trafik artışını iyi yönetirken, iş yüklerinin özelliklerini dikkate almanın ve bölmelere yedek kapasite ayırmanın (özellikle talep eşit olmayan şekilde dağıtıldığında) önemli olduğuydu. Bizim durumumuzda, işlerde ani bir artış oldu, bu da hızlı ölçeklendirmeye yol açtı ve bu da, düğüm havuzunu ölçeklendirmeye zaman bulamadan CPU kaynaklarının doygunluğuna yol açtı.
Her zaman bir kümeden olabildiğince fazlasını sıkıştırma eğilimi vardır, ancak başlangıçta performans sorunlarıyla karşılaştığımızdan, şimdi cömert bir kapsül bütçesiyle başlıyoruz ve daha sonra SLO'ları yakından takip ederek bu bütçeyi azaltıyoruz. Sidekiq hizmeti için kapsüllerin başlatılması önemli ölçüde hızlandı ve artık ortalama 40 saniye sürüyor. hem GitLab.com'u hem de resmi GitLab Helm grafiğiyle çalışan, kendi kendini yöneten kurulum kullanıcılarımızı kazandı.
Sonuç
Her hizmeti taşıdıktan sonra üretimde Kubernetes kullanmanın avantajlarından memnun kaldık: daha hızlı ve daha güvenli uygulama dağıtımı, ölçeklendirme ve daha verimli kaynak tahsisi. Üstelik geçişin avantajları GitLab.com hizmetinin ötesine geçiyor. Resmi Helm haritasındaki her iyileştirme, kullanıcılarına fayda sağlar.
Umarım Kubernetes'e geçiş maceralarımızın hikayesini beğenmişsinizdir. Tüm yeni hizmetleri kümeye taşımaya devam ediyoruz. Ek bilgileri aşağıdaki yayınlarda bulabilirsiniz:
- «";
- «";
- .
çevirmenden PS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Kaynak: habr.com