Adım Viktor Yagofarov ve DomClick'te Ops (operasyon) ekibinde teknik geliştirme yöneticisi olarak Kubernetes platformunu geliştiriyorum. Dev <-> Ops süreçlerimizin yapısından, Rusya'nın en büyük k8s kümelerinden birini çalıştırmanın özelliklerinden ve ekibimizin uyguladığı DevOps/SRE uygulamalarından bahsetmek istiyorum.
Operasyon Ekibi
Operasyon ekibinde şu anda 15 kişi bulunuyor. Bunlardan üçü ofisten sorumlu, ikisi farklı bir saat diliminde çalışıyor ve geceleri de dahil olmak üzere müsait durumdalar. Böylece, Ops'tan bir kişi her zaman monitörde bulunur ve her türlü karmaşıklıktaki olaya müdahale etmeye hazırdır. Ruhumuzu koruyan ve herkese yeterince uyuma ve boş zamanlarını sadece bilgisayarda geçirme fırsatı veren gece vardiyalarımız yok.
Herkesin farklı yetkinlikleri vardır: ağ uzmanları, DBA'lar, ELK yığın uzmanları, Kubernetes yöneticileri/geliştiricileri, izleme, sanallaştırma, donanım uzmanları vb. Herkesi birleştiren bir şey vardır; herkes bir dereceye kadar herhangi birimizin yerini alabilir: örneğin, k8s kümesine yeni düğümler eklemek, PostgreSQL'i güncellemek, bir CI/CD + Ansible işlem hattı yazmak, Python/Bash/Go'da bir şeyi otomatikleştirmek, donanımı bağlamak Veri merkezi. Herhangi bir alandaki güçlü yeterlilikler, faaliyet yönünüzü değiştirmenizi ve başka bir alanda gelişmeye başlamanızı engellemez. Mesela PostgreSQL uzmanı olarak bir şirkete katıldım ve artık asıl sorumluluk alanım Kubernetes kümeleri. Takımda her boy memnuniyetle karşılanır ve kaldıraç duygusu çok gelişmiştir.
Bu arada avlanıyoruz. Adaylarda aranan şartlar oldukça standart. Şahsen benim için bir kişinin takıma uyması, çatışmaması, aynı zamanda bakış açısını nasıl savunacağını bilmesi, gelişmek istemesi ve yeni bir şey yapmaktan korkmaması, fikirlerini sunması önemlidir. Ayrıca, betik dillerinde programlama becerileri, Linux'un temelleri ve İngilizce bilgisi gereklidir. Bir kişinin sahtekarlık durumunda sorunun çözümünü Google'da 10 dakika içinde değil, 10 saniyede bulabilmesi için İngilizceye ihtiyaç vardır. Artık Linux konusunda derin bilgiye sahip uzman bulmak çok zor: Komik ama her üç adaydan ikisi “Yük Ortalaması Nedir?” sorusuna cevap veremiyor. Neyden yapılmış?" ve "C programından bir çekirdek dökümü nasıl oluşturulur?" sorusu süper insanlar veya dinozorlar dünyasından bir şey olarak kabul edilir. Buna katlanmak zorundayız, çünkü genellikle insanların diğer becerileri de oldukça gelişmiştir, ancak Linux'u öğreteceğiz. "Neden bir DevOps mühendisinin modern bulut dünyasında tüm bunları bilmesi gerekiyor" sorusunun cevabı makalenin kapsamı dışında bırakılmalıdır, ancak üç kelimeyle: tüm bunlara ihtiyaç vardır.
Takım Araçları
Araçlar ekibi otomasyonda önemli bir rol oynar. Ana görevleri geliştiriciler için uygun grafik ve CLI araçları oluşturmaktır. Örneğin, dahili geliştirmemiz Confer, bir uygulamayı yalnızca birkaç fare tıklamasıyla kelimenin tam anlamıyla Kubernetes'e sunmanıza, kaynaklarını, kasadaki anahtarları vb. yapılandırmanıza olanak tanır. Daha önce Jenkins + Helm 2 vardı, ancak kopyala-yapıştır işlemini ortadan kaldırmak ve yazılım yaşam döngüsüne tekdüzelik getirmek için kendi aracımı geliştirmem gerekiyordu.
Ops ekibi, geliştiriciler için işlem hatları yazmaz ancak yazılarında herhangi bir sorunla ilgili tavsiyelerde bulunabilir (bazı kişilerin hala Helm 3'ü vardır).
DevOps
DevOps'a gelince, bunu şöyle görüyoruz:
Geliştirme ekipleri kodu yazar ve bunu geliştiriciye Confer -> qa/stage -> prod aracılığıyla dağıtır. Kodun yavaşlamamasını ve hata içermemesini sağlama sorumluluğu Geliştirme ve Operasyon ekiplerine aittir. Gündüz, Ops ekibinden görevli kişi bir olaya öncelikle uygulamasıyla müdahale etmeli, akşam ve gece ise görevli yönetici (Ops), biliyorsa görevdeki geliştiriciyi uyandırmalıdır. sorunun altyapıda olmadığından emin olun. İzlemedeki tüm ölçümler ve uyarılar otomatik veya yarı otomatik olarak görünür.
Ops'un sorumluluk alanı, uygulamanın üretime geçtiği andan itibaren başlar, ancak Dev'in sorumluluğu burada bitmiyor; biz de aynı şeyi yapıyoruz ve aynı gemideyiz.
Geliştiriciler, bir yönetici mikro hizmeti (örneğin, Go arka uç + HTML5) yazma konusunda yardıma ihtiyaç duymaları durumunda yöneticilere tavsiyelerde bulunur ve yöneticiler, geliştiricilere herhangi bir altyapı sorunu veya k8s ile ilgili sorunlar hakkında tavsiyelerde bulunur.
Bu arada, kesinlikle bir monolitimiz yok, yalnızca mikro hizmetlerimiz var. Sayıyla ölçülürse, prod k900s kümesinde şu ana kadar sayıları 1000 ile 8 arasında dalgalanıyor dağıtımları. Kapsüllerin sayısı 1700 ile 2000 arasında dalgalanıyor. Ürün kümesinde şu anda yaklaşık 2000 kapsül bulunuyor.
Gereksiz mikro hizmetleri izleyip yarı otomatik olarak devre dışı bıraktığımız için kesin rakam veremiyorum. K8'ler gereksiz varlıkları takip etmemize yardımcı oluyor Bu da çok fazla kaynak ve para tasarrufu sağlar.
Büyük resim
İzleme
İyi yapılandırılmış ve bilgilendirici izleme, büyük bir kümelenmenin işleyişinde temel taşı haline gelir. Henüz tüm izleme ihtiyaçlarının %100'ünü karşılayacak evrensel bir çözüm bulamadık, dolayısıyla bu ortamda periyodik olarak farklı özel çözümler yaratıyoruz.
- Zabbix. Öncelikle altyapının genel durumunu izlemeyi amaçlayan eski güzel izleme. İşleme, bellek, diskler, ağ vb. açısından bir düğümün ne zaman öldüğünü bize bildirir. Doğaüstü bir şey yok, ancak aynı zamanda ayrı bir DaemonSet aracımız var, bunun yardımıyla örneğin kümedeki DNS durumunu izliyoruz: aptal çekirdek bölmelerini arıyoruz, harici ana bilgisayarların kullanılabilirliğini kontrol ediyoruz. Görünüşe göre bununla neden uğraşıyorsunuz, ancak büyük hacimli trafikte bu bileşen ciddi bir başarısızlık noktasıdır. Daha önce ben zaten , bir kümedeki DNS performansıyla nasıl mücadele ettiğimi.
- Prometheus Operatörü. Farklı ihracatçılardan oluşan bir küme, kümenin tüm bileşenlerine ilişkin geniş bir genel bakış sunar. Daha sonra tüm bunları Grafana'daki büyük kontrol panellerinde görselleştiriyoruz ve uyarılar için alarm yöneticisini kullanıyoruz.
Bizim için bir başka yararlı araç da şuydu: . Bunu, bir takımın başka bir takımın Giriş yollarıyla çakıştığı ve bunun 50 kat hatayla sonuçlandığı bir durumla birkaç kez karşılaştığımızda yazdık. Artık üretime geçmeden önce geliştiriciler kimsenin etkilenmeyeceğini kontrol ediyor ve ekibim için bu, Girişlerle ilgili sorunların ilk teşhisi için iyi bir araç. İlk başta yöneticiler için yazılmış olması ve oldukça "beceriksiz" görünmesi komikti, ancak geliştirme ekipleri araca aşık olduktan sonra çok değişti ve "bir yöneticinin yöneticiler için web yüzü yaptığı" gibi görünmeye başladı. ” Yakında bu aracı terk edeceğiz ve bu tür durumlar, boru hattı kullanıma sunulmadan önce bile doğrulanacak.
Cube'daki ekip kaynakları
Örneklere geçmeden önce kaynakları nasıl ayırdığımızı açıklamakta fayda var. mikro hizmetler.
Hangi ekiplerin ve hangi miktarlarda kullandıklarını anlamak ресурсы (işlemci, bellek, yerel SSD), her komutun kendisine ait olmasını sağlarız ad ekiplerin ihtiyaçlarını daha önce tartışarak "Küp"te işlemci, bellek ve disk açısından maksimum yeteneklerini sınırladı. Buna göre, genel olarak tek bir komut, binlerce çekirdek ve terabaytlık bellek ayırarak tüm kümenin dağıtımını engellemez. Ad alanına erişim AD aracılığıyla sağlanır (RBAC kullanıyoruz). Ad alanları ve bunların sınırları, bir çekme isteği yoluyla GIT deposuna eklenir ve ardından her şey otomatik olarak Ansible işlem hattı aracılığıyla kullanıma sunulur.
Kaynakların bir ekibe tahsis edilmesine bir örnek:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
İstekler ve sınırlar
Küp" Talep et garantili ayrılmış kaynakların sayısıdır pod (bir veya daha fazla liman işçisi konteyneri) bir kümede. Limit, garanti edilmeyen maksimum değerdir. Grafiklerde, bazı ekiplerin tüm uygulamaları için nasıl çok fazla istek belirlediğini ve kendi ad alanları altındaki tüm istekler zaten "harcanmış" olduğundan uygulamayı "Küp"e dağıtamadıklarını sıklıkla görebilirsiniz.
Bu durumdan çıkmanın doğru yolu, gerçek kaynak tüketimine bakıp bunu talep edilen miktarla (Talep) karşılaştırmaktır.
Yukarıdaki ekran görüntülerinde "İstenen" CPU'ların gerçek iş parçacığı sayısıyla eşleştirildiğini ve Limitlerin gerçek CPU iş parçacığı sayısını aşabileceğini görebilirsiniz =)
Şimdi bazı ad alanlarına ayrıntılı olarak bakalım (ben ad alanı kube-system'i seçtim - "Küp"ün bileşenleri için sistem ad alanı) ve gerçekte kullanılan işlemci zamanı ve belleğin istenen zamana oranını görelim:
Sistem hizmetleri için gerçekte kullanılandan çok daha fazla bellek ve CPU'nun ayrıldığı açıktır. Kube sistemi söz konusu olduğunda bu haklı: nginx giriş denetleyicisi veya nodelocaldn'ler zirve noktalarında CPU'ya çarptı ve çok fazla RAM tüketti, bu yüzden burada böyle bir rezerv haklı. Ayrıca son 3 saatlik grafiklere güvenemeyiz: Geniş bir zaman dilimine ait geçmiş metrikleri görmek arzu edilir.
Bir “tavsiye” sistemi geliştirildi. Örneğin, burada hangi kaynakların "sınırları" (izin verilen üst çubuk) yükseltmenin daha iyi olacağını görebilirsiniz, böylece "kısma" meydana gelmez: bir kaynağın ayrılan zaman diliminde CPU veya belleği zaten harcadığı an ve “donmuş” hale gelene kadar bekliyor:
İşte onların iştahını kesmesi gereken baklalar:
Hakkında kısma + kaynak izleme, birden fazla makale yazabilirsiniz, bu nedenle yorumlarda sorular sorun. Birkaç kelimeyle, bu tür metrikleri otomatikleştirme görevinin çok zor olduğunu ve çok fazla zaman gerektirdiğini ve “window” işlevleri ve “CTE” Prometheus / VictoriaMetrics (bu terimler tırnak içindedir, çünkü neredeyse PromQL'de buna benzer bir şey yoktur ve korkutucu sorguları birkaç metin ekranına bölmeniz ve bunları optimize etmeniz gerekir).
Sonuç olarak, geliştiriciler Cube'da ad alanlarını izlemeye yönelik araçlara sahip ve hangi uygulamaların kaynaklarının nerede ve ne zaman "kesilebileceğini" ve tüm gece boyunca CPU'nun tamamının hangi sunuculara verilebileceğini kendileri seçebiliyorlar.
Metodolojiler
Şu anda olduğu gibi şirkette modaya, DevOps'a uyuyoruz ve İBBS-uygulayıcı Bir şirketin tüm altyapı için 1000 mikro hizmeti, yaklaşık 350 geliştiricisi ve 15 yöneticisi varsa, "modaya uygun" olmanız gerekir: tüm bu "baswords"ün arkasında her şeyi ve herkesi otomatikleştirmeye yönelik acil bir ihtiyaç vardır ve yöneticiler bir darboğaz olmamalıdır süreçlerde.
Ops olarak geliştiricilere hizmet yanıt oranları ve hatalara ilişkin çeşitli metrikler ve gösterge tabloları sağlıyoruz.
Aşağıdaki gibi metodolojileri kullanıyoruz: , и bunları bir araya getirerek. Kontrol panellerinin sayısını en aza indirmeye çalışıyoruz, böylece hangi hizmetin şu anda kötü durumda olduğunu (örneğin saniye başına yanıt kodları, yüzde 99'luk dilimde yanıt süresi) vb. bir bakışta görebilirsiniz. Genel gösterge tabloları için bazı yeni metrikler gerekli hale geldiğinde bunları hemen çizip ekliyoruz.
Bir aydır grafik çizmiyorum. Bu muhtemelen iyi bir işarettir: Bu, “isteklerin” çoğunun zaten gerçekleştiği anlamına gelir. Hafta boyunca günde en az bir kez yeni bir grafik çizdiğim oldu.
Ortaya çıkan sonuç değerlidir çünkü geliştiriciler artık yöneticilere "bazı tür ölçümlere nereden bakılacakları" sorularıyla nadiren başvuruyorlar.
Внедрение Hizmet Ağı Çok yakında ve herkes için hayatı çok daha kolay hale getirecek, Tools'daki meslektaşlarımız halihazırda "Sağlıklı bir kişinin Istio'su" soyut uygulamasını uygulamaya çok yakın: her HTTP(ler) isteğinin yaşam döngüsü izlemede görünür olacak ve hizmetler arası (sadece değil) etkileşim sırasında "her şeyin hangi aşamada bozulduğunu" anlamak her zaman mümkün olacaktır. DomClick merkezinden gelen haberlere abone olun. =)
Kubernetes altyapı desteği
Geçmişte, yamalı sürümü kullanıyoruz Kubesprey — Kubernetes'in dağıtımı, genişletilmesi ve güncellenmesi için uygun rol. Bir noktada ana şubeden kubeadm olmayan kurulumlara yönelik destek kesildi ve kubeadm'e geçiş süreci önerilmedi. Sonuç olarak, Güney Köprüsü şirketi kendi çatalını yaptı (kubeadm desteği ve kritik sorunlara hızlı çözüm).
Tüm k8 kümelerini güncelleme süreci şuna benzer:
- almak Kubesprey Güney Köprüsü'nden, konumuza bakın Merjim.
- Güncellemeyi şuraya yayınlıyoruz: stres- “Küp”.
- Güncellemeyi her seferinde bir düğüm olarak yayınlıyoruz (Ansible'da bu "seri: 1") dev- “Küp”.
- Güncelliyoruz Prod Cumartesi akşamı her seferinde bir düğüm.
Gelecekte değiştirilmesi planlanıyor Kubesprey daha hızlı bir şey için ve şuraya gidin: kubeadm.
Toplamda üç “Küpümüz” var: Stres, Geliştirme ve Üretim. Bir tane daha başlatmayı planlıyoruz (sıcak bekleme) İkinci veri merkezinde Prod-“Cube”. stres и dev “sanal makinelerde” (Stres için oVirt ve Dev için VMWare bulutu) yaşayın. Prod- "Cube" "çıplak metal" üzerinde yaşıyor: bunlar 32 CPU iş parçacığına, 64-128 GB belleğe ve 300 GB SSD RAID 10'a sahip aynı düğümlerdir - toplamda 50 adet vardır. Üç "ince" düğüm "ustalara" adanmıştır Prod- “Küba”: 16 GB bellek, 12 CPU iş parçacığı.
Satışlarda “çıplak metal” kullanmayı tercih ediyoruz ve gereksiz katmanlardan kaçınıyoruz. OpenStack: "gürültülü komşulara" ve CPU'ya ihtiyacımız yok zaman çalmak. Ve şirket içi OpenStack durumunda yönetimin karmaşıklığı yaklaşık iki katına çıkar.
CI/CD "Cubic" ve diğer altyapı bileşenleri için ayrı bir GIT sunucusu olan Helm 3'ü kullanıyoruz (Helm 2'den oldukça sancılı bir geçiş oldu, ancak seçeneklerden çok memnunuz) atom), Jenkins, Ansible ve Docker. Özellik dallarını ve tek bir depodan farklı ortamlara dağıtımı seviyoruz.
Sonuç
Genel anlamda DomClick'te bir operasyon mühendisinin bakış açısından DevOps süreci böyle görünüyor. Makalenin beklediğimden daha az teknik olduğu ortaya çıktı: bu nedenle Habré'deki DomClick haberlerini takip edin: Kubernetes hakkında daha fazla "sert" makale ve daha fazlası olacak.
Kaynak: habr.com