[Marianpol]

Piszę magisterkę, w której dokonuję porównania kontenerowych środowisk uruchomieniowych CRI-O z containerd.io w oparciu o Kubernetesa.

Podstawą moich badań jest nginx z domyślną konfiguracją w różnych konfiguracjach ilości podów jak i przydzielonych limitów CPU, na który puszczam ruch i obserwuję całkowitą ilość zapytań oraz średnie opóźnienie odpowiedzi.
Sprawdzam również ile taki jeden pod średnio zużywa CPU przy określonej ilości zapytań na sekundę.
Dodatkowo chciałem sprawdzić po jakim czasie i ile podów zostanie uruchomione przez HPA do obsługi danej ilości zapytań.

Zastanawiam się jakie metryki mógłbym jeszcze obserwować, aby zapełnić trochę miejsce w pracy. Myślałem nad puszczaniem ruchu HTTPS i podobnym schematem działania, ale nie wiem czy ma to sens w przypadku wybranych przeze mnie metryk.

Co jeszcze mógłbym sprawdzić w oparciu o moje środowisko z K8s i nginx? Nie chciałbym za dużo implementować, bo ani ja nie chcę się męczyć, ani promotor nie wymaga żadnych cudów. Dodatkowo jestem ograniczony czasowo, bo mega mi się nie chciało tego robić, ale już niedługo drugie terminy obron, a chciałbym jednak skończyć tą magisterkę, obronić i w końcu zamknąć etap edukacji.

#programowanie #programista15k #studbaza #studia #devops

[y.....l]

@Marianpol: Nie konfiguruj limitów cpu w kubernetesie bo cię zmiecie z planszy i jest to Imo antypattern i powoduje miliardy problemów.

[I.....t]

@Marianpol: Może jakieś parametry autoskalowania przy niskim/wysokim obciążeniu CPU, możesz tez sprawdzić jakiś loadbalancer i jak zachowuje się jak szkalujesz pody, jak rozgłaszanie nowych workerow idzie

[Marianpol]

@yggdrasil: Zastosowałem limit, aby wymusić dystrybucję obciążenia na inne pody, ale okazuje się, zrobiłem to bez sensu, bo domyślny Service ma round robin i ruch jest rozdzielany na wszystkie pody w miarę równomiernie. Dodatkowo, tak jak mówisz, jest to antipattern, więc ustawię tylko request cpu na żądaną przeze mnie wartość.

@Igbt: W sumie jest trochę ingress controllerów na rynku to rzeczywiście mógłbym zobaczyć jak sobie radzą. Co do autoskalowania to

[some_ONE]

ale okazuje się, zrobiłem to bez sensu, bo domyślny Service ma round robin i ruch jest rozdzielany na wszystkie pody w miarę równomiernie.

@Marianpol: Domyślnie (czyli kube-proxy w trybie iptables) to akurat nie ma round robin. Procentowo masz taką samą szansę że ruch trafi do każdego z podów, ale RR to nie jest. Może się okazać że np. 10 kolejnych requestów trafi do tego samego poda.

[some_ONE]

możesz tez sprawdzić jakiś loadbalancer i jak zachowuje się jak szkalujesz pody, jak rozgłaszanie nowych workerow idzie

@Igbt: A wybrany runtime ma na to w ogóle jakiś wpływ?

@Marianpol: Może jakieś testy zużycia pamięci albo czasu wstawania nowych podów? Myślę, że na to akurat wybrany runtime może mieć wpływ.

[I.....t]

@some_ONE: szczerze mówiąc to wątpię, ale ilość operacji IO może być rożna, wiec do magisterki jak znalazł (⌐ ͡■ ͜ʖ ͡■)

[Marianpol]

@some_ONE: Fakt, jednak domyślnie ruch idzie randomowo - trafiłem na zły temat na stacku, ale szczerze, przy pracy tego kalibru, wymaganiach i moich chęciach ma to marginalne znaczenie.

A wybrany runtime ma na to w ogóle jakiś wpływ?

W sumie to jest praca badawcza, więc nawet jak środowisko nie ma wpływu to nikt nie broni mi tego sprawdzić, a zawsze to będą jakieś inne metryki i scenariusz. Poza tym wątpię, aby