Notatka tłumaczenie: To jest tłumaczenie publicznej sekcji zwłok z bloga inżynierskiego firmy . Opisuje problem z conntrack w klastrze Kubernetes, który doprowadził do częściowego przestoju niektórych usług produkcyjnych.
Ten artykuł może być przydatny dla tych, którzy chcą dowiedzieć się nieco więcej na temat sekcji zwłok lub zapobiec potencjalnym problemom z DNS w przyszłości.
To nie jest DNS
To nie może być DNS
To był DNS
Trochę o sekcjach zwłok i procesach w Preply
Sekcja zwłok opisuje awarię lub jakieś zdarzenie w produkcji. Sekcja zwłok obejmuje harmonogram zdarzeń, wpływ na użytkownika, pierwotną przyczynę, podjęte działania i wyciągnięte wnioski.
Na cotygodniowych spotkaniach z pizzą w gronie ekipy technicznej dzielimy się różnymi informacjami. Jedną z najważniejszych części takich spotkań są sekcje zwłok, którym najczęściej towarzyszy prezentacja ze slajdami i głębsza analiza zdarzenia. Mimo że nie klaskamy po sekcjach zwłok, staramy się rozwijać kulturę „bez winy” (). Wierzymy, że pisanie i prezentowanie sekcji zwłok może pomóc nam (i innym) zapobiec podobnym zdarzeniom w przyszłości, dlatego je udostępniamy.
Osoby biorące udział w zdarzeniu powinny mieć poczucie, że mogą wypowiadać się szczegółowo, bez obawy przed karą lub zemstą. Żadnej winy! Napisanie sekcji zwłok nie jest karą, ale szansą na naukę dla całej firmy.
Problemy z DNS w Kubernetesie. Sekcja zwłok
Дата: 28.02.2020
Autorzy: Amet U., Andrey S., Igor K., Alexey P.
Tytuł: Skończone
Pokrótce: Częściowa niedostępność DNS (26 min) dla niektórych usług w klastrze Kubernetes
Wpływ: 15000 XNUMX utraconych zdarzeń dla usług A, B i C
Pierwotna przyczyna: Kube-proxy nie był w stanie poprawnie usunąć starego wpisu z tabeli conntrack, więc niektóre usługi nadal próbowały połączyć się z nieistniejącymi podami
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: ...Spust: Ze względu na małe obciążenie wewnątrz klastra Kubernetes, autoskaler CoreDNS zmniejszył liczbę podów we wdrożeniu z trzech do dwóch
rozwiązanie: Kolejne wdrożenie aplikacji zapoczątkowało tworzenie nowych węzłów, CoreDNS-autoscaler dodał kolejne pody do obsługi klastra, co sprowokowało przepisanie tabeli conntrack
Wykrycie: Monitoring Prometheus wykrył dużą liczbę błędów 5xx dla usług A, B i C i zainicjował wezwanie dyżurnych inżynierów
Błędy 5xx w Kibanie
Działalność
efekt
Typ
Odpowiedzialny
Zadanie
Wyłącz automatyczne skalowanie dla CoreDNS
zapobiec
Amet U.
DEVOPS-695
Skonfiguruj buforujący serwer DNS
zmniejszenie
Maks W.
DEVOPS-665
Skonfiguruj monitorowanie Conntrack
zapobiec
Amet U.
DEVOPS-674
Zdobyta wiedza
Co poszło dobrze:
- Monitoring działał dobrze. Odpowiedź była szybka i zorganizowana
- Nie osiągnęliśmy żadnych limitów węzłów
Co było nie tak:
- Nadal nieznana prawdziwa przyczyna, podobna do w conntracku
- Wszystkie działania korygują jedynie konsekwencje, a nie pierwotną przyczynę (błąd)
- Wiedzieliśmy, że prędzej czy później możemy mieć problemy z DNS, ale nie ustalaliśmy priorytetów zadań
Gdzie mieliśmy szczęście:
- Następne wdrożenie zostało wywołane przez autoskaler CoreDNS, który nadpisał tabelę conntrack
- Ten błąd dotyczył tylko niektórych usług
Oś czasu (EET)
czas
efekt
22:13
Autoskaler CoreDNS zmniejszył liczbę podów z trzech do dwóch
22:18
Inżynierowie dyżurujący zaczęli odbierać telefony z systemu monitoringu
22:21
Dyżurujący inżynierowie zaczęli szukać przyczyny błędów.
22:39
Dyżurni inżynierowie rozpoczęli wycofywanie jednej z najnowszych usług do poprzedniej wersji
22:40
Błędy 5xx przestały się pojawiać, sytuacja się ustabilizowała
- Czas do wykrycia: 4 minut
- Czas przed akcją: 21 minut
- Czas naprawić: 1 minut
informacje dodatkowe
- Dzienniki CoreDNS:
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 - Linki do Kibana (wycięty), Grafana (wycięty)
Aby zminimalizować użycie procesora, jądro Linuksa używa czegoś, co nazywa się conntrack. Krótko mówiąc, jest to narzędzie zawierające listę rekordów NAT przechowywanych w specjalnej tabeli. Kiedy następny pakiet dotrze z tego samego poda do tego samego poda co poprzednio, końcowy adres IP nie zostanie przeliczony, ale zostanie pobrany z tabeli conntrack.
Jak działa Conntrack
Wyniki
To był przykład jednej z naszych sekcji zwłok z kilkoma przydatnymi linkami. W szczególności w tym artykule udostępniamy informacje, które mogą być przydatne dla innych firm. Dlatego nie boimy się popełniać błędów i dlatego upubliczniamy jedną z naszych sekcji zwłok. Oto kilka ciekawszych publicznych sekcji zwłok:
- GitLab:
- Dropbox:
- Spotify:
- Wiele innych z i repozytorium
- również publiczna sekcja zwłok z SRE Book
Źródło: www.habr.com