Przyp. tłum.: to jest tłumaczenie publicznego postmortemu z inżynieryjnego bloga firmy . Opisuje problem z conntrack w klastrze Kubernetes, który spowodował częściowy przestój niektórych usług produkcyjnych.
Ten artykuł może być przydatny dla tych, którzy chcą dowiedzieć się nieco więcej o postmortemach lub zapobiec potencjalnym problemom z DNS w przyszłości.
To nie jest DNS
Nie może to być DNS
To był DNS
Kilka słów o postmortemach i procesach w Preply
Postmortem opisuje awarię działania lub jakieś wydarzenie w produkcji. Postmortem zawiera chronologię wydarzeń, opis wpływu na użytkownika, przyczynę, działania i wyciągnięte wnioski.
Na cotygodniowych spotkaniach z pizzą, w gronie zespołu technicznego, dzielimy się różnymi informacjami. Jedną z najważniejszych części takich spotkań są postmortemy, które najczęściej są związane z prezentacją slajdów i głębszą analizą zaistniałego incydentu. Chociaż nie „klaszczemy” po postmortemach, staramy się rozwijać kulturę „bez winy” (). Wierzymy, że pisanie i prezentowanie postmortemów może pomóc nam (i nie tylko) w zapobieganiu podobnym incydentom w przyszłości, dlatego dzielimy się nimi.
Osoby zaangażowane w incydent powinny czuć, że mogą szczegółowo o nim opowiedzieć, nie obawiając się kary czy odwetu. Żadnych potępień! Pisanie postmortemu to nie kara, ale możliwość nauki dla całej firmy.
Problemy z DNS w Kubernetes. Postmortem
Data: 28.02.2020
Autorzy: Amet U., Andriej S., Igor K., Aleksiej P.
Status: Zakończony
Krótko: Częściowa niedostępność DNS (26 min) dla niektórych usług w klastrze Kubernetes
Wpływ: 15000 zdarzeń utracono dla usług A, B i C
Przyczyna: Kube-proxy nie mógł poprawnie usunąć starego wpisu z tabeli conntrack, dlatego niektóre usługi wciąż próbowały połączyć się z nieistniejącymi podami
E0228 20:13:53.795782 1 proxier.go:610] Nie udało się usunąć kube-system/kube-dns:dns endpoint connections, błąd: błąd podczas usuwania wpisów conntrack dla UDP peer {100.64.0.10, 100.110.33.231}, błąd: polecenie conntrack zwróciło: ...Trigger: Z powodu niskiego obciążenia w klastrze Kubernetes, CoreDNS-autoscaler zmniejszył liczbę podów w wdrożeniu z trzech do dwóch
Rozwiązanie: Kolejny deploy aplikacji spowodował utworzenie nowych węzłów, a CoreDNS-autoscaler dodał więcej podów do obsługi klastra, co spowodowało nadpisanie tabeli conntrack.
Wykrywanie: Monitoring Prometheus wykrył dużą liczbę błędów 5xx dla usług A, B i C oraz zainicjował wezwanie do dyżurnych inżynierów.
Błędy 5xx w Kibana
Działania
Akcja
Typ
Odpowiedzialny
Zadanie
Wyłącz autoskalera dla CoreDNS
zapobierz.
Amet U.
DEVOPS-695
Zainstalować serwer DNS z pamięcią podręczną
zmniejsz.
Max W.
DEVOPS-665
Skonfigurować monitoring conntrack
zapobierz.
Amet U.
DEVOPS-674
Wyciągnięte lekcje
Co poszło dobrze:
- Monitoring działał sprawnie. Reakcja była szybka i zorganizowana.
- Nie napotkaliśmy żadnych limitów na węzłach.
Co było nie tak:
- Wciąż nieznana rzeczywista przyczyna, wydaje się być w conntrack.
- Wszystkie działania naprawiają tylko skutki, a nie przyczynę (błąd).
- Wiedzieliśmy, że prędzej czy później możemy mieć problemy z DNS, ale nie nadaliśmy zadaniom priorytetu.
Gdzie mieliśmy szczęście:
- Kolejny deploy wyzwolił CoreDNS-autoscaler, który nadpisał tabelę conntrack.
- Ten błąd dotknął tylko część usług.
Chronologia (EET)
Czas
Akcja
22:13
CoreDNS-autoscaler zmniejszył liczbę podów z trzech do dwóch.
22:18
Dyżurni inżynierowie zaczęli otrzymywać wezwania od systemu monitorowania.
22:21
Dyżurni inżynierowie zaczęli ustalać przyczynę błędów.
22:39
Dyżurni inżynierowie zaczęli cofać jedną z ostatnich usług do poprzedniej wersji.
22:40
Błędy 5xx przestały się pojawiać, sytuacja się ustabilizowała.
- Czas do wykrycia: 4 min
- Czas do podjęcia działań: 21 min
- Czas do naprawy: 1 min
Dodatkowe informacje
- Logi 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' Zmniejszono zestaw replik coredns-6cbb6646c9 do 2. - Linki do Kibana (usunięto), Grafana (usunięto)
Aby zminimalizować wykorzystanie procesora, jądro Linux stosuje coś takiego jak conntrack. Krótko mówiąc, to narzędzie, które zawiera listę wpisów NAT, przechowywanych w specjalnej tabeli. Gdy następny pakiet przychodzi z tego samego podu do tego samego podu, końcowy adres IP nie będzie obliczany od nowa, lecz pobierany z tabeli conntrack.
Jak działa conntrack.
Podsumowanie
To był przykład jednego z naszych postmortem z przydatnymi linkami. W tym artykule dzielimy się informacjami, które mogą być pomocne innym firmom. Dlatego nie boimy się popełniać błędów i dlatego zrobiliśmy jedno z naszych postmortem publicznym. Oto kilka innych interesujących publicznych postmortemów:
- GitLab:
- Dropbox:
- Spotify:
- Wiele innych z i repozytorium
- Również publicznego postmortemu z SRE Book
Źródło: habr.com
