![6 zabawnych błędów systemowych w działaniu Kubernetes [i ich rozwiązanie]](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Przez lata wykorzystania Kubernetesa w produkcji zebraliśmy wiele ciekawych historii o tym, jak błędy w różnych komponentach systemu prowadziły do nieprzyjemnych i/lub niezrozumiałych konsekwencji wpływających na działanie kontenerów i podów. W tym artykule wybraliśmy niektóre z najpopularniejszych i najbardziej interesujących. Nawet jeśli nigdy nie będziesz miał szczęścia spotkać się z takimi sytuacjami, czytanie takich krótkich kryminałów – zwłaszcza „z pierwszej ręki” – jest zawsze interesujące, prawda?..
Historia 1. Zawieszenie Supercronic i Docker
Na jednym z klastrów okresowo otrzymywaliśmy zawieszonego Dockera, który zakłócał normalne funkcjonowanie klastra. Jednocześnie w logach Dockera zaobserwowano co następuje:
level=error msg="containerd: start init process" error="exit status 2: "runtime/cgo: pthread_create failed: No space left on device
SIGABRT: abort
PC=0x7f31b811a428 m=0
goroutine 0 [idle]:
goroutine 1 [running]:
runtime.systemstack_switch() /usr/local/go/src/runtime/asm_amd64.s:252 fp=0xc420026768 sp=0xc420026760
runtime.main() /usr/local/go/src/runtime/proc.go:127 +0x6c fp=0xc4200267c0 sp=0xc420026768
runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200267c8 sp=0xc4200267c0
goroutine 17 [syscall, locked to thread]:
runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1
…
To, co nas najbardziej interesuje w tym błędzie, to komunikat: pthread_create failed: No space left on device. Szybkie badanie wyjaśnił, że Docker nie mógł rozwidlić procesu i dlatego okresowo się zawieszał.
W monitorowaniu następujący obraz odpowiada temu, co się dzieje:
Podobną sytuację obserwuje się w innych węzłach:
W tych samych węzłach widzimy:
root@kube-node-1 ~ # ps auxfww | grep curl -c
19782
root@kube-node-1 ~ # ps auxfww | grep curl | head
root 16688 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 17398 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 16852 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 9473 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 4664 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 30571 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 24113 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 16475 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 7176 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>
root 1090 0.0 0.0 0 0 ? Z Feb06 0:00 | _ [curl] <defunct>Okazało się, że takie zachowanie jest konsekwencją pracy kapsuły (narzędzie Go, którego używamy do uruchamiania zadań cron w podach):
_ docker-containerd-shim 833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 /var/run/docker/libcontainerd/833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 docker-runc
| _ /usr/local/bin/supercronic -json /crontabs/cron
| _ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true
| | _ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true -no-pidfile
| _ [newrelic-daemon] <defunct>
| _ [curl] <defunct>
| _ [curl] <defunct>
| _ [curl] <defunct>
…Problem polega na tym, że gdy zadanie jest uruchamiane w trybie supercronic, proces jest przez nie uruchamiany nie można zakończyć poprawnie, zamieniając się .
Operacja: Mówiąc ściślej, procesy są tworzone przez zadania cron, ale supercronic nie jest systemem init i nie może „adoptować” procesów, które uruchomiły jego dzieci. Kiedy zostaną zgłoszone sygnały SIGHUP lub SIGTERM, nie są one przekazywane do procesów potomnych, co powoduje, że procesy potomne nie kończą się i pozostają w statusie zombie. Więcej na ten temat można przeczytać m.in .
Istnieje kilka sposobów rozwiązania problemów:
- Jako tymczasowe obejście - zwiększ liczbę PID w systemie w jednym momencie:
/proc/sys/kernel/pid_max (since Linux 2.5.34) This file specifies the value at which PIDs wrap around (i.e., the value in this file is one greater than the maximum PID). PIDs greater than this value are not allo‐ cated; thus, the value in this file also acts as a system-wide limit on the total number of processes and threads. The default value for this file, 32768, results in the same range of PIDs as on earlier kernels - Lub uruchamiaj zadania w supercronic nie bezpośrednio, ale używając tego samego , który jest w stanie poprawnie zakończyć procesy i nie powodować spadków zombie.
Historia 2. „Zombie” podczas usuwania grupy c
Kubelet zaczął zużywać dużo procesora:
Nikomu się to nie spodoba, więc się uzbroiliśmy i zaczął walczyć z problemem. Wyniki dochodzenia były następujące:
- Kubelet spędza ponad jedną trzecią czasu swojego procesora na pobieraniu danych pamięci ze wszystkich grup:
- Na liście mailingowej twórców jądra możesz znaleźć . W skrócie sprawa sprowadza się do tego: różne pliki tmpfs i inne podobne rzeczy nie są całkowicie usuwane z systemu przy usuwaniu grupy cgroup, tzw zambi. Prędzej czy później zostaną one usunięte z pamięci podręcznej strony, ale pamięci na serwerze jest dużo i kernel nie widzi sensu tracić czasu na ich usuwanie. Dlatego ciągle się gromadzą. Dlaczego tak się w ogóle dzieje? Jest to serwer z zadaniami cron, który stale tworzy nowe zadania, a wraz z nimi nowe pody. W ten sposób tworzone są nowe grupy cgroup dla znajdujących się w nich kontenerów, które wkrótce zostaną usunięte.
- Dlaczego cAdvisor w kubelecie marnuje tyle czasu? Łatwo to zobaczyć przy najprostszym wykonaniu
time cat /sys/fs/cgroup/memory/memory.stat. Jeśli na zdrowej maszynie operacja zajmuje 0,01 sekundy, to na problematycznym cron02 zajmuje to 1,2 sekundy. Rzecz w tym, że cAdvisor, który bardzo wolno odczytuje dane z sysfs, stara się uwzględnić pamięć wykorzystywaną w cgroupach zombie. - Aby wymusić usunięcie zombie, próbowaliśmy wyczyścić pamięć podręczną zgodnie z zaleceniami LKML:
sync; echo 3 > /proc/sys/vm/drop_caches, - ale jądro okazało się bardziej skomplikowane i rozbiło samochód.
Co robić? Problem jest w trakcie naprawiania (i opis patrz ) aktualizacja jądra Linuksa do wersji 4.16.
Historia 3. Systemd i jego wierzchowiec
Ponownie kubelet zużywa zbyt wiele zasobów w niektórych węzłach, ale tym razem zużywa za dużo pamięci:
Okazało się, że występuje problem w systemie używanym w Ubuntu 16.04 i występuje on podczas zarządzania mocowaniami utworzonymi dla połączenia subPath z ConfigMap lub sekretów. Po zakończeniu pracy kapsuły usługa systemowa i jej podłączenie usługi pozostają w systemie. Z biegiem czasu gromadzi się ich ogromna liczba. Są nawet problemy w tym temacie:
- ;
- .
... z których ostatni odnosi się do PR w systemd: (problem w systemie - ).
Problem nie występuje już w Ubuntu 18.04, ale jeśli chcesz nadal korzystać z Ubuntu 16.04, nasze obejście tego tematu może okazać się przydatne.
Dlatego stworzyliśmy następujący DaemonSet:
---
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
labels:
app: systemd-slices-cleaner
name: systemd-slices-cleaner
namespace: kube-system
spec:
updateStrategy:
type: RollingUpdate
selector:
matchLabels:
app: systemd-slices-cleaner
template:
metadata:
labels:
app: systemd-slices-cleaner
spec:
containers:
- command:
- /usr/local/bin/supercronic
- -json
- /app/crontab
Image: private-registry.org/systemd-slices-cleaner/systemd-slices-cleaner:v0.1.0
imagePullPolicy: Always
name: systemd-slices-cleaner
resources: {}
securityContext:
privileged: true
volumeMounts:
- name: systemd
mountPath: /run/systemd/private
- name: docker
mountPath: /run/docker.sock
- name: systemd-etc
mountPath: /etc/systemd
- name: systemd-run
mountPath: /run/systemd/system/
- name: lsb-release
mountPath: /etc/lsb-release-host
imagePullSecrets:
- name: antiopa-registry
priorityClassName: cluster-low
tolerations:
- operator: Exists
volumes:
- name: systemd
hostPath:
path: /run/systemd/private
- name: docker
hostPath:
path: /run/docker.sock
- name: systemd-etc
hostPath:
path: /etc/systemd
- name: systemd-run
hostPath:
path: /run/systemd/system/
- name: lsb-release
hostPath:
path: /etc/lsb-release... i używa następującego skryptu:
#!/bin/bash
# we will work only on xenial
hostrelease="/etc/lsb-release-host"
test -f ${hostrelease} && grep xenial ${hostrelease} > /dev/null || exit 0
# sleeping max 30 minutes to dispense load on kube-nodes
sleep $((RANDOM % 1800))
stoppedCount=0
# counting actual subpath units in systemd
countBefore=$(systemctl list-units | grep subpath | grep "run-" | wc -l)
# let's go check each unit
for unit in $(systemctl list-units | grep subpath | grep "run-" | awk '{print $1}'); do
# finding description file for unit (to find out docker container, who born this unit)
DropFile=$(systemctl status ${unit} | grep Drop | awk -F': ' '{print $2}')
# reading uuid for docker container from description file
DockerContainerId=$(cat ${DropFile}/50-Description.conf | awk '{print $5}' | cut -d/ -f6)
# checking container status (running or not)
checkFlag=$(docker ps | grep -c ${DockerContainerId})
# if container not running, we will stop unit
if [[ ${checkFlag} -eq 0 ]]; then
echo "Stopping unit ${unit}"
# stoping unit in action
systemctl stop $unit
# just counter for logs
((stoppedCount++))
# logging current progress
echo "Stopped ${stoppedCount} systemd units out of ${countBefore}"
fi
done... i kursuje co 5 minut przy użyciu wspomnianego wcześniej supercronica. Jego plik Dockerfile wygląda następująco:
FROM ubuntu:16.04
COPY rootfs /
WORKDIR /app
RUN apt-get update &&
apt-get upgrade -y &&
apt-get install -y gnupg curl apt-transport-https software-properties-common wget
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable" &&
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - &&
apt-get update &&
apt-get install -y docker-ce=17.03.0*
RUN wget https://github.com/aptible/supercronic/releases/download/v0.1.6/supercronic-linux-amd64 -O
/usr/local/bin/supercronic && chmod +x /usr/local/bin/supercronic
ENTRYPOINT ["/bin/bash", "-c", "/usr/local/bin/supercronic -json /app/crontab"]Historia 4. Konkurencyjność przy planowaniu podów
Zauważono, że: jeśli mamy kapsułę umieszczoną na węźle i jej obraz jest pompowany przez bardzo długi czas, to kolejny kapsuła, który „uderzył” w ten sam węzeł, po prostu nie zaczyna pobierać obrazu nowego zasobnika. Zamiast tego czeka, aż zostanie pobrany obraz poprzedniego zasobnika. W rezultacie pod, który był już zaplanowany i którego obraz można było pobrać w ciągu minuty, otrzyma status containerCreating.
Wydarzenia będą wyglądać mniej więcej tak:
Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"Okazuje się, że pojedynczy obraz z powolnego rejestru może zablokować wdrożenie na węzeł.
Niestety nie ma wielu wyjść z tej sytuacji:
- Spróbuj użyć rejestru Docker bezpośrednio w klastrze lub bezpośrednio z klastrem (na przykład GitLab Registry, Nexus itp.);
- Użyj narzędzi takich jak .
Historia 5. Węzły zawieszają się z powodu braku pamięci
Podczas działania różnych aplikacji spotkaliśmy się też z sytuacją, w której węzeł całkowicie przestał być dostępny: SSH nie odpowiada, wszystkie demony monitorujące odpadają, a potem w logach nie ma już nic (lub prawie nic) anomalii.
Opowiem Wam na zdjęciach na przykładzie jednego węzła, w którym funkcjonowało MongoDB.
Tak wygląda szczyt do Wypadki:
I tak - później Wypadki:
W monitoringu też następuje gwałtowny skok, przy którym węzeł przestaje być dostępny:
Zatem ze zrzutów ekranu jasno wynika, że:
- Pamięć RAM w maszynie dobiega końca;
- Następuje gwałtowny skok zużycia pamięci RAM, po którym dostęp do całej maszyny zostaje nagle wyłączony;
- Do Mongo pojawia się duże zadanie, które zmusza proces DBMS do użycia większej ilości pamięci i aktywnego odczytu z dysku.
Okazuje się, że jeśli w Linuksie zabraknie wolnej pamięci (następuje presja pamięci) i nie nastąpi zamiana, wówczas do Kiedy nadejdzie zabójca OOM, może pojawić się problem znalezienia równowagi między wrzuceniem stron do pamięci podręcznej stron a zapisaniem ich z powrotem na dysk. Robi to za pomocą kswapd, który odważnie zwalnia jak najwięcej stron pamięci do późniejszej dystrybucji.
Niestety, przy dużym obciążeniu wejść/wyjść w połączeniu z małą ilością wolnej pamięci, kswapd staje się wąskim gardłem całego systemu, bo są z tym związani wszystko alokacje (błędy stron) stron pamięci w systemie. Może to trwać bardzo długo, jeśli procesy nie chcą już używać pamięci, ale są unieruchomione na samym skraju otchłani zabójców OOM.
Naturalnym pytaniem jest: dlaczego zabójca OOM pojawia się tak późno? W swojej obecnej wersji zabójca OOM jest wyjątkowo głupi: zabije proces tylko wtedy, gdy próba przydzielenia strony pamięci nie powiedzie się, tj. jeśli błąd strony się nie powiedzie. Nie dzieje się to przez dłuższy czas, bo kswapd dzielnie zwalnia strony pamięci, zrzucając pamięć podręczną stron (właściwie cały dyskowy I/O w systemie) z powrotem na dysk. Bardziej szczegółowo, z opisem kroków niezbędnych do wyeliminowania takich problemów w jądrze, możesz przeczytać .
To zachowanie z jądrem Linuksa 4.6+.
Historia 6. Pody utknęły w stanie Oczekujące
W niektórych klastrach, w których działa naprawdę wiele strąków, zaczęliśmy zauważać, że większość z nich „wisi” bardzo długo w stanie Pending, chociaż same kontenery Dockera działają już w węzłach i można z nimi pracować ręcznie.
Jednocześnie w describe nie ma w tym niczego złego:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 1m default-scheduler Successfully assigned sphinx-0 to ss-dev-kub07
Normal SuccessfulAttachVolume 1m attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
Normal SuccessfulMountVolume 1m kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "sphinx-config"
Normal SuccessfulMountVolume 1m kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "default-token-fzcsf"
Normal SuccessfulMountVolume 49s (x2 over 51s) kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b"
Normal Pulled 43s kubelet, ss-dev-kub07 Container image "registry.example.com/infra/sphinx-exporter/sphinx-indexer:v1" already present on machine
Normal Created 43s kubelet, ss-dev-kub07 Created container
Normal Started 43s kubelet, ss-dev-kub07 Started container
Normal Pulled 43s kubelet, ss-dev-kub07 Container image "registry.example.com/infra/sphinx/sphinx:v1" already present on machine
Normal Created 42s kubelet, ss-dev-kub07 Created container
Normal Started 42s kubelet, ss-dev-kub07 Started containerPo chwili grzebania założyliśmy, że kubelet po prostu nie ma czasu na wysyłanie wszystkich informacji o stanie podów i testach żywotności/gotowości do serwera API.
Po przestudiowaniu pomocy znaleźliśmy następujące parametry:
--kube-api-qps - QPS to use while talking with kubernetes apiserver (default 5)
--kube-api-burst - Burst to use while talking with kubernetes apiserver (default 10)
--event-qps - If > 0, limit event creations per second to this value. If 0, unlimited. (default 5)
--event-burst - Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10)
--registry-qps - If > 0, limit registry pull QPS to this value.
--registry-burst - Maximum size of bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10)Jak widać, wartości domyślne są dość małe, a w 90% pokrywają wszystkie potrzeby... Jednak w naszym przypadku to nie wystarczyło. Dlatego ustalamy następujące wartości:
--event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40... i zrestartowaliśmy kubelety, po czym na wykresach wywołań serwera API zobaczyliśmy następujący obrazek:
... i tak, wszystko zaczęło latać!
PS
Za pomoc w zbieraniu błędów i przygotowaniu tego artykułu wyrażam głęboką wdzięczność licznym inżynierom naszej firmy, a zwłaszcza mojemu koledze z naszego zespołu badawczo-rozwojowego Andreyowi Klimentyevowi ().
PPS
Przeczytaj także na naszym blogu:
- «".
- Pętla porad i wskazówek Kubernetes:
- «";
- «";
- «";
- «".
Źródło: www.habr.com