Mimari, geçici test ortamlarını orkestre etmek için özel bir TestRun kaynak tanımını izleyen bir Kubernetes Operatörü gerektirir. Bir pipeline bir test yürütmesini tetiklediğinde, denetçi, uygun boyutlarda podlar sağlamak için Prometheus metriklerinden takımın geçmiş kaynak tüketim desenlerini analiz eder.
apiVersion: testing.company.io/v1 kind: TestRun metadata: name: api-regression-suite spec: testType: api parallelism: 20 resources: requests: cpu: "500m" memory: "1Gi" isolation: namespaceTemplate: "test-${uuid}" networkPolicy: deny-all tracing: enabled: true samplingRate: 0.1
Her test takımı, bir testin veritabanı kapsülleyicileri veya sahte hizmetlerinin başka bir test ile çelişmemesini sağlamak için, çapraz namespace iletişimini engelleyen NetworkPolicies ile donatılmış izole bir namespace alır. Gözlemlenebilirlik için, test çalıştırıcısının yanında çalışan bir yan konteyner, test kodunu değiştirmeden ağ aramalarını ve dosya sistemi işlemlerini yakalayan, eBPF probaları kullanarak, çekirdek düzeyinde OpenTelemetry izlerini otomatik olarak enjekte eder. Gecikmeyi azaltmak için, izleme verileri, merkezi Jaeger toplayıcısına asenkron olarak iletmeden önce span'ları tamponlayan ve sıkıştıran bir yerel düğüm ajanı aracılığıyla akar, böylece aletleme yükü her işlem başına elli milisaniyenin altında kalır.
Bir finansal teknoloji firması, kritik piyasa saatlerinde dağıtım darboğazlarına neden olan ve özellik yayınlarını ortalama iki gün geciktiren statik kırk sanal makinede sekiz saat süren regresyon takımından mücadele etti. Altyapı ekibi, testlerin paylaşılan veritabanlarını kirletmesi ve hataları ayıklamak için mühendislerin iki düzine makine arasında dağıtılmış olan günlükleri manuel olarak ilişkilendirmesi gerektiğinde sürekli ortam kayması sorunlarıyla karşılaştı, bu da olay başına dört saate kadar zaman tüketiyordu. Bu pipeline'ı modernize etmek için üç farklı yaklaşım değerlendirdik: statik VM havuzunu genişletmek, basitlik sunuyordu ancak izolasyon sorunlarını çözmedi ve yüksek bulut maliyetlerine yol açtı; bulut sağlayıcıdan talep üzerine örnekler kullanmak, esnekliği artırdı ancak iki dakikalık sağlama gecikmeleri getirdi, bu da kuyruk arka planlarını çoğalttı; ve özel denetleyicileri olan bir Kubernetes yerel test ağı uygulamak, otuz saniyeden daha kısa süre içinde izole namespace'ler oluşturulmasına olanak tanıdı.
Kubernetes yaklaşımını seçtik çünkü farklı test türleri için kaynak profilleri tanımlamamıza izin verdi, örneğin, görsel regresyon testleri için yalnızca GPU düğümleri ayırırken, API testlerini standart hesaplama örneklerinde tutma gibi. Uygulama, CI web kancası olaylarını izleyen bir TestRunner denetleyicisi oluşturmayı ve her namespace içinde, belirli test verileri ile doldurulmuş, ayrılmış PostgreSQL ve Redis yan konteynerleri sağlamayı içeriyordu. Dağıtım sonrası, ortalama yürütme süresi on bir dakikaya düştü, ortamla ilgili kararsız testlerin oranı yüzde doksan dört azaldı ve merkezi gözlemlenebilirlik platformu sayesinde mühendisler, bir API çağrısının on yedi mikroservis üzerinde beş saniye içinde izlenmesini sağladı.
Test verisi izolasyonunu, veritabanı durumlarının her test çalıştırmasından sonra sıfırlandığı geçici konteynerlerde nasıl ele alıyorsunuz?
Birçok aday, yalnızca test başına şema stratejileri ile ortak veritabanı örnekleri kullanmayı öneriyor ancak bu, ağ darboğazları oluşturur ve testlerin belirli uzantılar veya yapılandırmalar gerektirdiği durumlarda başarısız olur. Doğru yaklaşım, her test namespace'inin, harici kümelere ağ trafiği olmadan saniyeler içinde tam bir veritabanı kopyası almasını sağlamak için, nesne depolama alanında saklanan sıkıştırılmış hacim anlık görüntülerinden geçici veritabanı podlarını beslemek için init konteynerleri kullanmaktır. Son derece büyük veri setleri için, statik referans verilerinin salt okunur hacimler olarak monte edildiği ve işlem verilerinin fabrikalar kullanılarak dinamik olarak üretildiği, böylece bir test yürütme sırasında çökse bile, sonraki temizleme görevini karmaşık geri alma betikleri olmadan sadece namespace'i silmekle gerçekleştirebildiğiniz bir katmanlı strateji uygulamalısınız.
Aynı Kubernetes düğümünde CPU yoğun API testlerinin yanında hafif API testleri çalıştığında "gürültülü komşu" sorununu önlemek için hangi stratejiyi izliyorsunuz?
Adaylar genellikle Kubernetes planlama nüanslarını göz ardı eder ve yalnızca kopya sayılarını artırarak sonuçlanan kaynak rekabetine neden olurlar ve bu, Chrome örnekleri tüm mevcut CPU döngülerini tükettiğinde API testlerinde zaman aşımına yol açar. Düğüm etkileşim kuralları uygulamalısınız; bu, düğümleri iş yükü türleri ile etiketler ve özel örnekleri tarayıcı tabanlı testler için rezerve etmek amacıyla lekeler kullanırken, aynı zamanda her namespace içinde herhangi bir testin kendi adil payından fazla tüketmesini önlemek için kaynak kotası ve sınır aralıkları ayarlamalısınız. Ek olarak, Dikey Pod Autoscaler'ı öneri modu ile yapılandırmak, zaman içinde farklı test takımlarının gerçek kaynak ihtiyaçlarını belirlemeye yardımcı olur, bu da performans tutarlılığını tehlikeye atmadan etkin bir şekilde kutuya yerleştirmeye olanak tanır.
Testler yürütme tamamlandıktan hemen sonra sona eren kısa ömürlü podlarda hata ayıklama yeteneklerini nasıl sürdürüyorsunuz?
Yaygın bir hata, başarısız podların sonsuza kadar çalışmasını sağlamak olup, bu durum küme kaynaklarını tüketir ve kapsüllenmiş testlerin geçici doğasını ihlal eder. Bunun yerine, bitişten önce tüm pod durumunu, yığın dökümleri, iş parçacığı dökümleri ve ağ paket yakalamaları dahil olmak üzere, sona ermeden önce kalıcı bir hacim talebine kaydeden bir preStop yaşam döngüsü kancası uygulamalısınız; ayrıca günlükleri merkezi bir Loki ya da Elasticsearch örneğine agresif bir indeksleme ile boşaltmalısınız. Etkileşimli hata ayıklama için, mühendislerin test yürütmesi sona erdikten saatler veya günler sonra hata anındaki tam konteyner durumunu denetim yapabilmesi için tamamlanmış pod dosya sistemlerine bağlanan Kubernetes geçici hata ayıklama konteynerlerini kullanın.