Not tercüme: Bu, şirketin mühendislik blogundaki halka açık bir otopsi metninin çevirisidir . Kubernetes kümesindeki bağlantıyla ilgili, bazı üretim hizmetlerinde kısmi kesintilere yol açan bir sorunu anlatıyor.
Bu makale, ölüm sonrası işlemler hakkında biraz daha fazla bilgi edinmek veya gelecekte bazı olası DNS sorunlarını önlemek isteyenler için yararlı olabilir.
Bu DNS değil
DNS olamaz
Bu DNS'ti
Preply'deki ölüm sonrası işlemler ve süreçler hakkında biraz
Otopsi, üretimdeki bir arızayı veya bir olayı tanımlar. Otopsi, olayların zaman çizelgesini, kullanıcı etkisini, temel nedeni, gerçekleştirilen eylemleri ve öğrenilen dersleri içerir.
Haftalık pizza toplantılarında teknik ekiple çeşitli bilgiler paylaşıyoruz. Bu tür toplantıların en önemli kısımlarından biri, çoğunlukla slaytlı bir sunumun ve olayın daha derinlemesine bir analizinin eşlik ettiği otopsilerdir. Otopsilerden sonra alkışlamasak da "suçlamama" kültürünü geliştirmeye çalışıyoruz (). Otopsi yazmanın ve sunmanın bize (ve başkalarına) gelecekte benzer olayları önlemede yardımcı olabileceğine inanıyoruz, bu yüzden bunları paylaşıyoruz.
Bir olaya karışan kişiler, ceza veya intikam korkusu olmadan ayrıntılı olarak konuşabileceklerini hissetmelidir. Suçlama yok! Otopsi yazmak bir ceza değil, tüm şirket için bir öğrenme fırsatıdır.
Kubernetes'te DNS ile ilgili sorunlar. Ölüm sonrası
Tarih: 28.02.2020
Yazarlar: Amet U., Andrey S., Igor K., Alexey P.
Başlık: bitmiş
Kısaca: Kubernetes kümesindeki bazı hizmetler için DNS'nin kısmi kullanılamaması (26 dakika)
Darbe: A, B ve C hizmetleri için 15000 olay kaybedildi
Ana neden: Kube-proxy, eski bir girişi bağlantı tablosundan doğru şekilde kaldıramadı, bu nedenle bazı hizmetler hâlâ var olmayan bölmelere bağlanmaya çalışıyordu
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...Tetiklemek: Kubernetes kümesindeki yükün düşük olması nedeniyle CoreDNS-otomatik ölçekleyici, dağıtımdaki bölme sayısını üçten ikiye düşürdü
Çözüm: Uygulamanın bir sonraki dağıtımı yeni düğümlerin oluşturulmasını başlattı, CoreDNS-autoscaler kümeye hizmet etmek için daha fazla bölme ekledi ve bu da bağlantı tablosunun yeniden yazılmasına neden oldu
Tespit etme: Prometheus izleme, A, B ve C hizmetleri için çok sayıda 5xx hatası tespit etti ve görevli mühendislere çağrı başlattı
Kibana'daki 5xx hataları
Etkinlik
Eylem
Tip
sorumlu
Görev
CoreDNS için otomatik ölçekleyiciyi devre dışı bırakın
önlenmiş
Amet U.
DEVOPS-695
Önbelleğe alma DNS sunucusu ayarlama
azaltmak
Maksimum V.
DEVOPS-665
Conntrack izlemeyi ayarlama
önlenmiş
Amet U.
DEVOPS-674
Dersler öğrenildi
Ne iyi gitti:
- İzleme iyi çalıştı. Yanıt hızlı ve düzenliydi
- Düğümlerde herhangi bir sınıra ulaşmadık
Yanlış olan neydi:
- Hala bilinmeyen gerçek kök neden, buna benzer bağlantıda
- Tüm eylemler temel nedeni değil yalnızca sonuçları düzeltir (hata)
- Er ya da geç DNS ile sorun yaşayabileceğimizi biliyorduk ancak görevlere öncelik vermedik
Şanslı olduğumuz yer:
- Bir sonraki dağıtım, bağlantı tablosunun üzerine yazan CoreDNS-autoscaler tarafından tetiklendi
- Bu hata yalnızca bazı hizmetleri etkiledi
Zaman Çizelgesi (EET)
Zaman
Eylem
22:13
CoreDNS-otomatik ölçekleyici, bölme sayısını üçten ikiye düşürdü
22:18
Görevli mühendisler izleme sisteminden çağrı almaya başladı
22:21
Görevli mühendisler hataların nedenini bulmaya başladı.
22:39
Görevli mühendisler en son hizmetlerden birini önceki sürüme geri döndürmeye başladı
22:40
5xx hatalarının görünmesi durduruldu, durum stabil hale geldi
- Tespit süresi: 4 dakika
- Eylemden önceki süre: 21 dakika
- Düzeltme zamanı: 1 dakika
ek bilgi
- CoreDNS günlükleri:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - Kibana (kesilmiş), Grafana (kesilmiş) ile bağlantılar
CPU kullanımını en aza indirmek için Linux çekirdeği conntrack adı verilen bir şey kullanır. Kısacası bu, özel bir tabloda saklanan NAT kayıtlarının listesini içeren bir yardımcı programdır. Bir sonraki paket daha önce olduğu gibi aynı bölmeden aynı bölmeye ulaştığında, son IP adresi yeniden hesaplanmayacak ancak bağlantı tablosundan alınacaktır.
Conntrack nasıl çalışır?
sonuçlar
Bu, bazı yararlı bağlantıların bulunduğu postmortemlerimizden birinin örneğiydi. Bu makalede özellikle diğer şirketlerin işine yarayabilecek bilgileri paylaşıyoruz. Bu yüzden hata yapmaktan korkmuyoruz ve bu yüzden otopsilerimizden birini kamuoyuna açıklıyoruz. İşte bazı daha ilginç kamuya açık otopsiler:
- Git Laboratuvarı:
- Dropbox:
- Spotify:
- Diğer pek çok kişi ve depo
- Ayrıca SRE Kitabı ile kamuya açık ölüm sonrası
Kaynak: habr.com