Bu hikaye, konteynerleri bir üretim ortamında, özellikle de Kubernetes'te nasıl kullandığımızla ilgilidir. Makale, konteynerlerden metrikler ve günlükler toplamanın yanı sıra görseller oluşturmaya ayrılmıştır.

B2B ve B2C için çevrimiçi ticaret ve fintech ürünlerine yönelik hizmetler geliştiren fintech şirketi Exness'teyiz. Ar-Ge'mizde birçok farklı ekip var, geliştirme departmanımızda 100'den fazla çalışan var.

Geliştiricilerimizin kod toplayıp çalıştıracağı platformdan sorumlu ekibi temsil ediyoruz. Özellikle uygulamalardaki ölçümleri, günlükleri ve olayları toplamak, depolamak ve raporlamaktan sorumluyuz. Şu anda bir üretim ortamında yaklaşık üç bin Docker konteyneri işletiyoruz, 50 TB büyük veri depolama alanımızı sürdürüyoruz ve altyapımız etrafında oluşturulan mimari çözümler sunuyoruz: Kubernetes, Rancher ve çeşitli genel bulut sağlayıcıları. 

Motivasyonumuz

Ne yanıyor? Kimse cevap veremez. Ocak nerede? Bunu anlamak zor. Ne zaman alev aldı? Öğrenebilirsin ama hemen değil. 

Neden bazı konteynerler ayaktayken bazıları düşüyor? Hangi konteyner suçlanacaktı? Sonuçta kapların dışı aynı ama her birinin içinde kendi Neo var.

Geliştiricilerimiz yetenekli adamlardır. Şirkete kâr getiren iyi hizmetler yaparlar. Ancak uygulamalara sahip kaplar yoldan çıktığında başarısızlıklar olur. Bir konteyner çok fazla CPU tüketiyor, diğeri ağı tüketiyor, üçüncüsü I/O işlemlerini tüketiyor ve dördüncüsünün soketlerle ne yaptığı tamamen belirsiz. Hepsi düşer ve gemi batar. 

aracılar

İçeride neler olduğunu anlamak için ajanları doğrudan konteynerlere yerleştirmeye karar verdik.

Bu ajanlar kapları birbirlerini kırmayacak şekilde tutan kısıtlayıcı programlardır. Temsilciler standartlaştırılmıştır ve bu, konteynerlere hizmet verme konusunda standartlaştırılmış bir yaklaşıma olanak tanır. 

Bizim durumumuzda aracıların günlükleri standart formatta, etiketlenmiş ve daraltılmış olarak sağlaması gerekir. Ayrıca bize iş uygulaması perspektifinden genişletilebilen standartlaştırılmış ölçümler sağlamalıdırlar.

Aracılar aynı zamanda farklı görüntüleri destekleyen farklı düzenleme sistemlerinde (Debian, Alpine, Centos vb.) çalışabilen işletme ve bakım yardımcı programları anlamına da gelir.

Son olarak aracıların Docker dosyalarını içeren basit CI/CD'yi desteklemesi gerekir. Aksi takdirde gemi parçalanacak çünkü konteynerler “çarpık” raylar boyunca teslim edilmeye başlanacak.

Süreç oluşturun ve görüntü cihazını hedefleyin

Her şeyi standart ve yönetilebilir tutmak için bir tür standart oluşturma sürecinin izlenmesi gerekir. Bu nedenle kapları kaplara göre toplamaya karar verdik - bu özyinelemedir.

Burada kaplar katı hatlarla temsil edilmektedir. Aynı zamanda "hayat ahududu gibi görünmesin" diye içlerine dağıtım kitleri koymaya karar verdiler. Bunun neden yapıldığını aşağıda açıklayacağız.
 
Sonuç, belirli dağıtım sürümlerine ve belirli komut dosyası sürümlerine referans veren, sürüme özel bir kapsayıcı olan bir oluşturma aracıdır.

Bunu nasıl kullanırız? Konteyner içeren bir Docker Hub'ımız var. Dışa bağımlılıklardan kurtulmak için sistemimize yansıtıyoruz. Sonuç sarı renkle işaretlenmiş bir kaptır. İhtiyacımız olan tüm dağıtımları ve scriptleri konteynere yüklemek için bir şablon oluşturuyoruz. Bundan sonra kullanıma hazır bir görüntü oluşturuyoruz: geliştiriciler kodu ve kendi özel bağımlılıklarından bazılarını buna koyuyorlar. 

Bu yaklaşımın iyi tarafı nedir? 

• İlk olarak, derleme araçlarının tam sürüm kontrolü - derleme kapsayıcısı, komut dosyası ve dağıtım sürümleri. 
• İkinci olarak standardizasyonu sağladık: şablonları, ara ve kullanıma hazır görselleri de aynı şekilde oluşturuyoruz. 
• Üçüncüsü, konteynerler bize taşınabilirlik sağlıyor. Bugün Gitlab kullanıyoruz, yarın ise TeamCity veya Jenkins'e geçiş yapacağız ve aynı şekilde konteynerlerimizi çalıştırabileceğiz. 
• Dördüncüsü, bağımlılıkları en aza indirmek. Dağıtım kitlerini konteynere koymamız tesadüf değildi, çünkü bu, bunları her seferinde İnternet'ten indirmekten kaçınmamızı sağlıyor. 
• Beşincisi, oluşturma hızı arttı - görüntülerin yerel kopyalarının varlığı, yerel bir görüntü olduğu için indirme sırasında zaman kaybetmekten kaçınmanıza olanak tanır. 

Yani kontrollü ve esnek bir montaj süreci yakaladık. Tam sürümlü kapsayıcılar oluşturmak için aynı araçları kullanırız. 

Oluşturma prosedürümüz nasıl çalışır?

Montaj tek komutla başlatılır, işlem resimde gerçekleştirilir (kırmızıyla vurgulanmıştır). Geliştiricinin bir Docker dosyası var (sarı renkle vurgulanmış), değişkenleri değerlerle değiştirerek onu oluşturuyoruz. Ve yol boyunca üstbilgileri ve altbilgileri ekliyoruz; bunlar bizim aracılarımızdır. 

Başlık, karşılık gelen görsellerden dağıtımları ekler. Altbilgi, hizmetlerimizi içeriye yükler, iş yükünün başlatılmasını, günlüğe kaydetmeyi ve diğer aracıları yapılandırır, giriş noktasının yerini alır vb. 

Uzun süre bir denetçi kurup kurmamamız gerektiğini düşündük. Sonunda ona ihtiyacımız olduğuna karar verdik. S6'yı seçtik. Denetleyici, konteyner yönetimini sağlar: ana işlem çökerse ona bağlanmanıza olanak tanır ve konteyneri yeniden oluşturmadan manuel olarak yönetmenizi sağlar. Günlükler ve ölçümler, kapsayıcının içinde çalışan işlemlerdir. Onların da bir şekilde kontrol edilmesi gerekiyor ve bunu da bir amir yardımıyla yapıyoruz. Son olarak S6 temizlik, sinyal işleme ve diğer görevleri üstleniyor.

Farklı orkestrasyon sistemleri kullandığımız için, konteynerin inşa edilip çalıştırıldıktan sonra hangi ortamda bulunduğunu anlaması ve duruma göre hareket etmesi gerekiyor. Örneğin:
Bu, tek bir görüntü oluşturmamıza ve onu farklı düzenleme sistemlerinde çalıştırmamıza olanak tanır ve bu düzenleme sisteminin özellikleri dikkate alınarak başlatılacaktır.

 

Aynı konteyner için Docker ve Kubernetes'te farklı süreç ağaçları elde ediyoruz:

Yük S6'nın denetimi altında yürütülür. Toplayıcıya ve olaylara dikkat edin; bunlar günlüklerden ve ölçümlerden sorumlu temsilcilerimizdir. Kubernetes'te bunlara sahip değil ancak Docker'da var. Neden? 

“Pod”un (bundan sonra Kubernetes pod olarak anılacaktır) özelliklerine bakarsak, olay konteynerinin, metrikleri ve günlükleri toplama işlevini yerine getiren ayrı bir toplayıcı konteynere sahip olan bir bölmede yürütüldüğünü göreceğiz. Kubernetes'in yeteneklerini kullanabiliriz: konteynerleri tek bir bölmede, tek bir işlemde ve/veya ağ alanında çalıştırmak. Aslında temsilcilerinizi tanıtın ve bazı işlevleri yerine getirin. Ve aynı konteyner Docker'da başlatılırsa, çıktıyla aynı yetenekleri alacaktır, yani aracılar dahili olarak başlatılacağı için günlükleri ve ölçümleri sunabilecektir. 

Metrikler ve günlükler

Ölçümleri ve günlükleri sunmak karmaşık bir iştir. Kararının birkaç yönü var.
Altyapı, logların toplu teslimi için değil, yükün yürütülmesi için oluşturulmuştur. Yani bu işlemin minimum konteyner kaynağı gereksinimi ile gerçekleştirilmesi gerekmektedir. Geliştiricilerimize yardımcı olmaya çalışıyoruz: "Bir Docker Hub kapsayıcısı alın, çalıştırın ve günlükleri teslim edebiliriz." 

İkinci husus, günlüklerin hacminin sınırlandırılmasıdır. Birkaç kapsayıcıda günlük hacminde bir artış meydana gelirse (uygulama bir döngüde yığın izlemesi çıkarır), CPU, iletişim kanalları ve günlük işleme sistemi üzerindeki yük artar ve bu, ana bilgisayarın bir sistem olarak çalışmasını etkiler. bütün ve diğer kapların ana bilgisayar üzerinde olması, bazen bu, ana bilgisayarın "düşmesine" yol açar. 

Üçüncü husus, mümkün olduğu kadar çok metrik toplama yöntemini kutudan çıktığı haliyle desteklemenin gerekli olmasıdır. Dosyaları okumaktan ve Prometheus uç noktasını yoklamaktan uygulamaya özel protokolleri kullanmaya kadar.

Ve son husus kaynak tüketimini en aza indirmektir.

Telegraf adında açık kaynaklı bir Go çözümü seçtik. Bu, 140'tan fazla giriş kanalı türünü (giriş eklentileri) ve 30 tür çıkış kanalını (çıkış eklentileri) destekleyen evrensel bir konektördür. Son halini verdik ve şimdi Kubernetes'i örnek alarak nasıl kullandığımızı anlatacağız. 

Bir geliştiricinin bir iş yükünü dağıttığını ve Kubernetes'in bir kapsül oluşturma isteği aldığını varsayalım. Bu noktada her pod için otomatik olarak Collector adında bir konteyner oluşturulur (mutasyon web kancasını kullanırız). Koleksiyoncu bizim acentemizdir. Başlangıçta bu konteyner kendisini Prometheus ve günlük toplama sistemi ile çalışacak şekilde yapılandırır.

• Bunu yapmak için bölme açıklamalarını kullanır ve içeriğine bağlı olarak örneğin bir Prometheus uç noktası oluşturur; 
• Pod spesifikasyonuna ve belirli kapsayıcı ayarlarına bağlı olarak günlüklerin nasıl teslim edileceğine karar verir.

Günlükleri Docker API'si aracılığıyla topluyoruz: geliştiricilerin bunları yalnızca stdout veya stderr'e koyması gerekiyor ve Collector bunu çözecektir. Olası ana bilgisayarın aşırı yüklenmesini önlemek için günlükler bir miktar gecikmeyle parçalar halinde toplanır. 

Ölçümler, kapsayıcılardaki iş yükü örnekleri (işlemler) genelinde toplanır. Her şey etiketlenir: ad alanı, altında vb. ve ardından Prometheus formatına dönüştürülür ve koleksiyon için uygun hale gelir (günlükler hariç). Ayrıca Kafka'ya günlükler, ölçümler ve olaylar gönderiyoruz ve ayrıca:

• Günlükler Graylog'da mevcuttur (görsel analiz için);
• Günlükler, metrikler ve olaylar, uzun süreli depolama için Clickhouse'a gönderilir.

AWS'de her şey tamamen aynı şekilde çalışıyor, yalnızca Graylog'u Kafka ile Cloudwatch ile değiştiriyoruz. Günlükleri oraya gönderiyoruz ve her şey çok uygun çıkıyor: hangi kümeye ve konteynere ait oldukları hemen anlaşılıyor. Aynı şey Google Stackdriver için de geçerlidir. Yani planımız hem yerinde Kafka ile hem de bulutta çalışıyor. 

Pod'lu Kubernetes'imiz yoksa şema biraz daha karmaşıktır ancak aynı prensiplerle çalışır.

Aynı işlemler konteynerin içinde yürütülür ve S6 kullanılarak düzenlenir. Aynı işlemlerin tümü aynı konteynerin içinde çalışıyor.

Bunun bir sonucu olarak,

Günlükleri ve ölçümleri toplama ve iletme seçenekleriyle birlikte görüntüleri oluşturmak ve başlatmak için eksiksiz bir çözüm oluşturduk:

• Görüntüleri birleştirmek için standartlaştırılmış bir yaklaşım geliştirdik ve buna dayanarak CI şablonları geliştirdik;
• Veri toplama aracıları Telegraf uzantılarımızdır. Bunları üretimde iyi bir şekilde test ettik;
• Kapsüllerdeki aracıları içeren kapsayıcıları uygulamak için mutasyon web kancasını kullanıyoruz; 
• Kubernetes/Rancher ekosistemine entegre edilmiştir;
• Aynı konteynerleri farklı orkestrasyon sistemlerinde çalıştırabilir ve beklediğimiz sonucu alabiliriz;
• Tamamen dinamik bir konteyner yönetimi yapılandırması oluşturuldu. 

Ortak yazar: İlya Prudnikov

Kaynak: habr.com