Analiza działania oraz modyfikacja schedulerów usługi Kubernetes

Abstract

Rosnąca popularność rozwiązań chmurowych oraz usług opartych na kontenerach sprawia, że coraz więcej aplikacji jest uruchamianych w środowisku Kubernetes. Rezultatem takiej sytuacji jest potrzeba zaadresowania różnych wymagań odpowiednich dla typów aplikacji. Domyślna implementacja planisty usługi Kubernetes została stworzona z myślą o aplikacjach bezstanowych. Nie jest to jednak jedyny typ oprogramowania używanego na co dzień. Aplikacje stanowe, takie jak bazy danych, potrzebują dostępu do dysków, aby przechowywać swoje dane. Usługi oparte o sztuczną inteligencję lub uczenie maszynowe, wymagają uruchomienia wszystkich obiektów w danej warstwie sieci neuronowych, zanim zostaną uruchomione te z kolejnej warstwy. Największe korporacje świata pracują nad własnymi planistami tak aby mógł on wybrać optymalną strategię doboru Węzła na podstawie typu aplikacji. Jednak rozwiązania dla firm takich jak Apple, Dell czy Microsoft mogą nie mieć racji bytu dla mniejszych firm. Poniższa praca miała na celu zbadanie w jaki sposób można stworzyć nowego planistę i czy przynosi to pozytywne rezultaty dla czasu uruchomienia w stosunkowo niewielkim klastrze. Dzięki dostępności bibliotek klienckich usługi Kubernetes dla popularnych języków takich jak Golang czy Python, stworzenie własnej implementacji planisty nie stanowi poważniejszego wyzwania. Jednakże zaprogramowanie optymalnego procesu w zależności od typu obiektu oraz otrzymanie lepszych wyników niż domyślna implementacja jest problematyczne. Zaobserwowano zyski w czasie uruchomienia obiektów Pod w pewnych warunkach, lecz w ogólnym przypadku domyślny planista osiągał znacząco lepsze wyniki. Czas, który potrzeba poświęcić na usprawnienia Schedulera sprawia, że jest to nieopłacalne dla mniejszych klastrów.