Pinterest'te kubernetes platformu oluşturma

Yıllar geçtikçe Pinterest'in 300 milyon kullanıcısı, 200 milyardan fazla panoda 4 milyardan fazla pin oluşturdu. Portal, bu kullanıcı ordusuna ve geniş içerik tabanına hizmet etmek için, birkaç CPU tarafından yönetilebilen mikro hizmetlerden, tüm bir sanal makine filosunda çalışan dev monolitlere kadar binlerce hizmet geliştirdi. Ve sonra şirketin gözünün k8'lere düştüğü an geldi. "Küp" Pinterest'te neden güzel görünüyordu? Bunu yakın zamanda yayınlanan bir makalenin çevirisinden öğreneceksiniz. blog Pinterest mühendisliği.

Pinterest'te kubernetes platformu oluşturma

Yani yüz milyonlarca kullanıcı ve yüz milyarlarca pin. Bu kullanıcı ordusuna ve geniş içerik tabanına hizmet etmek için, birkaç CPU tarafından yönetilebilen mikro hizmetlerden, tüm sanal makine filolarında çalışan dev monolitlere kadar binlerce hizmet geliştirdik. Ayrıca CPU, bellek veya G/Ç erişimi gerektirebilecek çeşitli çerçevelerimiz de mevcuttur.

Bu araç yelpazesinin bakımını yaparken geliştirme ekibi bir takım zorluklarla karşı karşıyadır:

  • Mühendislerin bir üretim ortamını çalıştırmasının tek tip bir yolu yoktur. Durum bilgisi olmayan hizmetler, Durum bilgisi olan hizmetler ve aktif olarak geliştirilmekte olan projeler tamamen farklı teknoloji yığınlarına dayanmaktadır. Bu, mühendisler için tam bir eğitim kursunun oluşturulmasına yol açtı ve aynı zamanda altyapı ekibimizin işini ciddi şekilde zorlaştırdı.
  • Kendi sanal makine filosuna sahip geliştiriciler, şirket içi yöneticiler üzerinde büyük bir yük oluşturur. Sonuç olarak, işletim sistemini veya AMI'yi güncellemek gibi basit işlemler haftalar ve aylar alır. Bu, görünüşte kesinlikle günlük durumlarda artan iş yüküne yol açar.
  • Mevcut çözümlere ek olarak küresel altyapı yönetimi araçları oluşturmanın zorlukları. Sanal makinelerin sahiplerini bulmanın kolay olmaması durumu daha da karmaşık hale getiriyor. Yani bu kapasitenin güvenli bir şekilde altyapımızın diğer bölümlerinde faaliyet gösterecek şekilde çıkarılıp çıkarılamayacağını bilmiyoruz.

Konteyner düzenleme sistemleri, iş yükü yönetimini birleştirmenin bir yoludur. Projeye dahil olan tüm kaynaklar tek bir merkezi sistem tarafından yönetildiğinden, geliştirme hızının artmasına ve altyapı yönetiminin basitleştirilmesine kapı açıyorlar.

Pinterest'te kubernetes platformu oluşturma

Şekil 1: Altyapı öncelikleri (güvenilirlik, geliştirici üretkenliği ve verimliliği).

Pinterest'teki Bulut Yönetim Platformu ekibi, 8 yılında K2017'leri keşfetti. 2017'nin ilk yarısında API ve tüm web sunucularımız da dahil olmak üzere üretim yeteneklerimizin çoğunu belgelemiştik. Daha sonra konteyner çözümlerini düzenlemek, kümeler oluşturmak ve onlarla çalışmak için çeşitli sistemlerin kapsamlı bir değerlendirmesini yaptık. 2017 yılının sonlarına doğru Kubernetes kullanmaya karar verdik. Oldukça esnekti ve geliştirici topluluğunda geniş çapta destekleniyordu.

Bugüne kadar Kops'u temel alan kendi küme önyükleme araçlarımızı oluşturduk ve ağ oluşturma, güvenlik, ölçümler, günlük kaydı, kimlik yönetimi ve trafik gibi mevcut altyapı bileşenlerini Kubernetes'e taşıdık. Ayrıca kaynağımız için karmaşıklığı geliştiricilerden gizlenen bir iş yükü modelleme sistemi de uyguladık. Artık kümenin istikrarını sağlamaya, ölçeklendirmeye ve yeni müşteriler bağlamaya odaklandık.

Kubernetes: Pinterest Yolu

Mühendislerimizin seveceği bir platform olarak Kubernetes'i Pinterest ölçeğinde kullanmaya başlamak birçok zorluğu da beraberinde getirdi.

Büyük bir şirket olarak altyapı araçlarına büyük yatırım yaptık. Örnekler arasında, sertifika işleme ve anahtar dağıtımını yöneten güvenlik araçları, trafik kontrol bileşenleri, hizmet keşif sistemleri, görünürlük bileşenleri ve günlük ve ölçüm gönderme bileşenleri yer alır. Tüm bunların bir nedeni vardı: Normal deneme yanılma yolunu izledik ve bu nedenle eski tekerleği yeni bir platformda yeniden icat etmek yerine tüm bu ekipmanı Kubernetes'teki yeni altyapıya entegre etmek istedik. Bu yaklaşım, tüm uygulama desteğinin zaten mevcut olması ve sıfırdan oluşturulması gerekmemesi nedeniyle geçişi genel olarak basitleştirdi.

Öte yandan Kubernetes'in kendisindeki yük tahmin modelleri (dağıtımlar, işler ve Daemon setleri gibi) projemiz için yeterli değil. Bu kullanılabilirlik sorunları Kubernetes'e geçişin önünde büyük engeller oluşturuyor. Örneğin, hizmet geliştiricilerinin eksik veya yanlış oturum açma ayarlarından şikayetçi olduklarını duyduk. Aynı spesifikasyon ve görevle yüzlerce kopya oluşturulduğunda şablon motorlarının yanlış kullanımıyla da karşılaştık, bu da kabus gibi hata ayıklama sorunlarına yol açtı.

Aynı kümede farklı sürümleri korumak da çok zordu. Tüm sorunları, hataları ve güncellemeleri ile aynı çalışma zamanı ortamının birden fazla sürümünde aynı anda çalışmanız gerekiyorsa, müşteri desteğinin karmaşıklığını bir düşünün.

Pinterest Kullanıcı Özellikleri ve Denetleyicileri

Mühendislerimizin Kubernetes'i uygulamasını kolaylaştırmak ve altyapımızı basitleştirip hızlandırmak için kendi özel kaynak tanımlarımızı (CRD'ler) geliştirdik.

CRD'ler aşağıdaki işlevleri sağlar:

  1. Farklı yerel Kubernetes kaynaklarının tek bir iş yükü olarak çalışacak şekilde birleştirilmesi. Örneğin, PinterestService kaynağı bir dağıtım, bir oturum açma hizmeti ve bir yapılandırma haritası içerir. Bu, geliştiricilerin DNS kurulumu konusunda endişelenmemelerini sağlar.
  2. Gerekli uygulama desteğini uygulayın. CRD denetleyicisi gerekli tüm init konteynerlerini, ortam değişkenlerini ve pod spesifikasyonlarını uygularken, kullanıcının yalnızca iş mantığına göre konteyner spesifikasyonuna odaklanması gerekir. Bu, geliştiriciler için temelde farklı bir konfor düzeyi sağlar.
  3. CRD denetleyicileri ayrıca yerel kaynakların yaşam döngüsünü yönetir ve hata ayıklama kullanılabilirliğini artırır. Bu, istenen ve gerçek spesifikasyonların mutabakatını, CRD durumunun güncellenmesini ve olay günlüklerinin tutulmasını ve daha fazlasını içerir. CRD olmadan geliştiriciler birden fazla kaynağı yönetmek zorunda kalacak ve bu da yalnızca hata olasılığını artıracaktır.

Aşağıda, denetleyicimiz tarafından yönetilen bir Pinterest Hizmeti ve dahili kaynak örneği verilmiştir:

Pinterest'te kubernetes platformu oluşturma

Yukarıda görebileceğiniz gibi, özel bir kapsayıcıyı desteklemek için güvenlik, görünürlük ve ağ trafiği sağlamak üzere bir init kapsayıcıyı ve çeşitli eklentileri entegre etmemiz gerekir. Buna ek olarak, kimlik, kaynak tüketimi ve çöp toplama işlemlerini izlemek için birden fazla ortam değişkeninin izlenmesinin yanı sıra, toplu işlere yönelik yapılandırma haritası şablonları oluşturduk ve PVC şablonları için destek uyguladık.

Geliştiricilerin, bırakın yapılandırmaların bakımını ve hata ayıklamasını, CRD desteği olmadan bu yapılandırma dosyalarını elle yazmak isteyeceğini hayal etmek bile zor.

Uygulama dağıtımı iş akışı

Pinterest'te kubernetes platformu oluşturma

Yukarıdaki resimde Pinterest özel kaynağının Kubernetes kümesine nasıl dağıtılacağı gösterilmektedir:

  1. Geliştiriciler Kubernetes kümemizle CLI ve kullanıcı arayüzü aracılığıyla etkileşime girer.
  2. CLI/UI araçları, iş akışı yapılandırması YAML dosyalarını ve diğer derleme özelliklerini (aynı sürüm kimliği) Artifactory'den alır ve ardından bunları İş Gönderim Hizmetine gönderir. Bu adım, kümeye yalnızca üretim sürümlerinin teslim edilmesini sağlar.
  3. JSS, Kubernetes dahil çeşitli platformlar için bir ağ geçididir. Burada kullanıcının kimliği doğrulanıyor, kotalar veriliyor ve CRD'mizin yapılandırması kısmen kontrol ediliyor.
  4. JSS tarafında CRD kontrol edildikten sonra bilgiler k8s platformu API'sine gönderilir.
  5. CRD denetleyicimiz tüm kullanıcı kaynaklarındaki olayları izler. Konteynerli kullanıcı uygulamalarının yeterli altyapı desteğine sahip olmasını sağlamak için CR'leri yerel k8s kaynaklarına dönüştürür, gerekli modülleri ekler, uygun ortam değişkenlerini ayarlar ve diğer destek çalışmalarını gerçekleştirir.
  6. CRD denetleyicisi daha sonra alınan verileri Kubernetes API'sine aktararak zamanlayıcı tarafından işlenebilmesini ve üretime alınabilmesini sağlar.

Dikkat: Dağıtımın bu yayın öncesi iş akışı, yeni k8s platformunun ilk kullanıcıları için oluşturuldu. Şu anda bu süreci yeni CI/CD'mizle tamamen entegre olacak şekilde geliştirme sürecindeyiz. Bu, Kubernetes ile ilgili her şeyi size anlatamayacağımız anlamına gelir. Deneyimlerimizi ve ekibin bu yöndeki ilerlemesini bir sonraki blog gönderimiz olan "Pinterest için bir CI/CD platformu oluşturma"da paylaşmayı sabırsızlıkla bekliyoruz.

Özel kaynak türleri

Pinterest'in özel ihtiyaçlarını temel alarak farklı iş akışlarına uyacak şekilde aşağıdaki CRD'leri geliştirdik:

  • PinterestService, uzun süredir çalışan durum bilgisi olmayan hizmetlerdir. Temel sistemlerimizin çoğu bu tür hizmetlere dayanmaktadır.
  • PinterestJobSet tam döngülü toplu işleri modeller. Pinterest'teki yaygın bir senaryo, birden fazla işin, diğer benzer süreçlerden bağımsız olarak aynı kapsayıcıları paralel olarak çalıştırmasıdır.
  • PinterestCronJob, küçük periyodik yüklerle birlikte yaygın olarak kullanılır. Bu, güvenlikten, trafikten, günlüklerden ve ölçümlerden sorumlu olan Pinterest destek mekanizmalarıyla yerel cron çalışmasına yönelik bir sarmalayıcıdır.
  • PinterestDaemon, altyapı Daemon'larını içerir. Kümelerimize daha fazla destek ekledikçe bu aile büyümeye devam ediyor.
  • PinterestTrainingJob, Tensorflow ve Pytorch işlemlerini kapsayacak şekilde genişletilerek diğer tüm CRD'lerle aynı düzeyde çalışma zamanı desteği sağlar. Pinterest, Tensorflow ve diğer makine öğrenimi sistemlerini aktif olarak kullandığından, bunların etrafında ayrı bir CRD oluşturmak için bir nedenimiz vardı.

Ayrıca yakında veri ambarları ve diğer durum bilgisi olan sistemlere uyarlanacak olan PinterestStatefulSet üzerinde de çalışıyoruz.

Çalışma zamanı desteği

Bir uygulama podu Kubernetes'te çalıştığında kendisini tanımlamak için otomatik olarak bir sertifika alır. Bu sertifika, gizli depolamaya erişmek veya mTLS aracılığıyla diğer hizmetlerle iletişim kurmak için kullanılır. Bu arada Container Init Yapılandırıcı ve Daemon, konteynerli uygulamayı çalıştırmadan önce gerekli tüm bağımlılıkları indirecektir. Her şey hazır olduğunda, trafik sepeti ve Daemon, modülün IP adresini Zookeeper'ımıza kaydedecek, böylece müşteriler onu keşfedebilecek. Ağ modülü uygulama başlatılmadan önce yapılandırıldığı için tüm bunlar işe yarayacaktır.

Yukarıdakiler iş yükleri için çalışma zamanı desteğinin tipik örnekleridir. Diğer iş yükü türleri biraz farklı destek gerektirebilir, ancak bunların hepsi bölme düzeyinde yardımcı programlar, düğüm düzeyinde veya sanal makine düzeyindeki Daemon'lar biçiminde gelir. Tüm bunların yönetim altyapısı içinde dağıtılmasını ve uygulamalar arasında tutarlı olmasını sağlıyoruz; bu da sonuçta teknik çalışma ve müşteri desteği açısından yükü önemli ölçüde azaltıyor.

Test ve Kalite Güvencesi

Mevcut Kubernetes test altyapısının üzerine uçtan uca bir test hattı oluşturduk. Bu testler tüm kümelerimiz için geçerlidir. Ürün grubumuzun bir parçası olmadan önce boru hattımız birçok revizyondan geçti.

Test sistemlerine ek olarak sistem bileşenlerinin durumunu, kaynak tüketimini ve diğer önemli göstergeleri sürekli izleyen, yalnızca insan müdahalesinin gerekli olduğu durumlarda bizi bilgilendiren izleme ve uyarı sistemlerimiz bulunmaktadır.

alternatifleri

Mutasyon erişim denetleyicileri ve şablon sistemleri gibi özel kaynaklara yönelik bazı alternatiflere baktık. Ancak bunların hepsi önemli operasyonel zorluklarla karşı karşıya olduğundan CRD yolunu seçtik.

Sepetleri, ortam değişkenlerini ve diğer çalışma zamanı desteğini tanıtmak için mutasyonel bir kabul denetleyicisi kullanıldı. Ancak CRD'de bu tür sorunların ortaya çıkmadığı kaynak bağlama ve yaşam döngüsü yönetimi gibi çeşitli sorunlarla karşı karşıya kaldı.

Not: Helm grafikleri gibi şablon sistemleri de benzer konfigürasyonlara sahip uygulamaları çalıştırmak için yaygın olarak kullanılır. Ancak iş uygulamalarımız şablonlarla yönetilemeyecek kadar çeşitlidir. Ayrıca sürekli dağıtım sırasında şablonları kullanırken çok fazla hata olacaktır.

Yaklaşan çalışma

Şu anda tüm kümelerimizde karışık bir yükle uğraşıyoruz. Farklı tür ve büyüklükteki bu tür süreçleri desteklemek için aşağıdaki alanlarda çalışıyoruz:

  • Bir küme koleksiyonu, ölçeklenebilirlik ve kararlılık için büyük uygulamaları farklı kümelere dağıtır.
  • Uygulama bağlantısı ve SLA'lar oluşturmak için küme kararlılığının, ölçeklenebilirliğinin ve görünürlüğünün sağlanması.
  • Kaynakları ve kotaları, uygulamaların birbiriyle çakışmayacağı ve kümenin ölçeğinin bizim tarafımızdan kontrol edileceği şekilde yönetmek.
  • Kubernetes'te uygulamaları desteklemek ve dağıtmak için yeni bir CI/CD platformu.

Kaynak: habr.com

Yorum ekle