 Cześć, moja nazwa jest Maciek Prytel i jestem software engineer na Google. Uwielbiam się w autoskalaeru klaski jako części GKE i jako członkowie poprzednich w komunii OpenSource za trochę więcej niż 6 lat. W GKE uwielbiam się w autoskalaeru klaski w tysiącach i tysiącach klasów i oczekiwania klasyków z naszych klasykowców, wczoraj z bardzo małych klasyków, do 15 tysiącach klasyków. Chciałem się zrozumieć kilka z naszych doświadczeń z tymi tymi. W tym rozmówiemy o wystarczającym klaski w autoskalaeru klaski. Będę rozmawiać o metrykach, logach i innych toolach, które myślę, są używane tutaj. Nie zaskoczyłem się za dużo na kosztu optymizacji, a nie zaskoczyłem, jak klaski w autoskalaeru klaski pracują. Byłem zakończony z klaski w latach, i zapytałem rekordów z klasyków klaski, które są na YouTube. Dzisiaj zacznę z 3 części. Zacznę z klaski w autoskalaeru klaski. Będę zakończony z klaski, które myślę, są relevantne z perspektywem zrozumieć, co może się wytrzymać i wytrzymać. Będę zakończony z klasyków klaski, które myślę, są najważniejsze z perspektywem monitorowania i klaski w autoskalaeru klaski. Będę zakończony z klasyków klaski, które myślę, są najważniejsze. I jak te klasyków klaski mogą być użyte do zorganizacji. Zacznę. Chcę zacząć z bardzo szybkiej, nie wiem, misji. Problemy, które będę w tym interesuje, jest problemy, że wszystkie klasyków mogą skazować. Myślę, że to jest naprawdę najważniejsze z klasyków klaski w autoskalaeru. Jeśli nie ma wystarczających znoty w klasyków, nie można skazować, kiedy chcesz skończyć do zorganizacji klaski, a nie ma wystarczających znoty w klasyków klaski, to nie ma wystarczających znoty w klasyków klaski. I to jest problem, który musi być zakończony. Będę zakończony z tego problemu i zrozumieć to. I więc, kilka ważnych rzeczy o tym, jak klasyków klaski w autoskalaeru skazują. Pierwszym, klasyków klaski w autoskalaeru jest wreszcie reagujące do zorganizacji klasyków klaski. To jest to, co trwa w autoskalaeru. I kiedy się widzi, to zorganizacja klaski będzie zorganizować, jak wiele klasyków wioski są potrzebne do zorganizacji klasyków. I to będzie zorganizacja do zorganizacji klasyków i zorganizacja, że te klasyków są tworzone. Natomiast nie jest naprawdę zainteresowane w zacząć klasyków w żadnym sposób, zamiast tylko skazując to. Nie jest inicializacja klasyków, nie jest zorganizacja klasyków, nie jest zorganizacja, i nie jest im rozgrzybowany W jednym zionie, mamy klasyków w autoskalaeru. Tylko jedno zionie wardsyli się w jednym zionie. krowa, ale po drugie, klaska autoskala jest w porządku podczas tych dobrych api, a krowa podczas api, które nie są standardowe, nie są naprawdę skończone, lub nawet bardzo podobne, między tymi krowami. Klaska autoskala jest często podczas sceny używające konceptualnie podobne krowy podczas konceptów lub grupy krowy, jak AWS, ASGs, GC, Managing Instance Groups, Azure, VMSS i tak dalej. To są aktywalne na wielu krowach, natomiast są znakowe differencesy w api i nie jest naprawdę wymienione, że krowa podczas klaska autoskala jest w porządku podczas mechanizmu, więc podczas krowy podczas klaska autoskala i kuberneta api to jest bardzo zakończone na every installation. Krowy podczas api i krowy podczas klaska autoskala podczas krowy podczas klaska autoskala to jest bardzo zakończone. Właśnie krowy podczas klaska autoskala to jest bardzo znakująca partia krowy podczas klaska autoskala. Niestety to znaczy, że w praktyce dużo problemów będzie wgłówni w różnych krowach. i wiele metry, które mogą wyglądać dosyć zrównowicie. Próbuję spróbować to wydać. I może są jakieś problemy, które są specyficzne do pewnych kluczy, które nie pokazują się w innych kluczach. I też są jakieś problemy, które są właściwie całkowicie spokojne przez wiele kluczy, ale mogą wyglądać dosyć zrównowicie. Więc jednym przykładem, które mam tutaj, jest API QPS Quarta Exhaustion. To jest bardzo ważna problemy dla kluczy autoskalerów. I to, co jest z tym, jest, że te kluczy wyglądają się zrównowicie. I z względu na to, jak mało kluczy, jak mało kluczy podróży integracji, co jest w kluczach autoskalerów, to będzie różnego rodzaju kluczy, różnego numeru kluczy, które zrównowicie skończą te problemy. Nie myślę, że jest jedyny dobry sposób do monitorowania w środku kluczy autoskalerów, natomiast to jest coś, o którym zrozumiałam, co podróżujesz na swoim kluczach podróży, jak mało, jak jest możliwe. Inny drugi temat, który myślę, jest często całkowicie różny z różnych kluczy, jest nienaktywna sorty behavioru kluczy autoskalerów, rzeczy jak skalabilność czy skala latensy. To będzie zrównowało dłużej czasu, żeby budować WM w różnych environmentach. Ale specjalnie skalabilność jest tak zrównowała na koszt i optimizacją, co jest zrobione na kluczy autoskalerów na poziomie kluczy autoskalerów, że to będzie potencjalnie zrównowicie wg kluczy autoskalerów. Oficjalnie kluczy autoskalerów opuszczają 1 tysiące noty, to co mówimy w opuszczalnej opozycji. W praktyce, jestem bardzo zaufany, jest dużo, dużo większych kluczy autoskalerów w GKE, bez żadnej znificy optymizacji do opuszczalnej logii autoskalerów. I jeszcze jedna rzecz, co chciałem wyrazić, jest jak wyrazić kluczy autoskalerów. Kluczy autoskalerów jest używany przez lekarz lekcji, więc można wyrazić mnóstwo replików w jednym kluczy kluczy, jedynym z nich będzie aktywna i drugi z nich będzie załatwić. Obawiam się, że to, jeśli jest możliwe. I kluczy autoskalerów jest przede wszystkim statyna. To może być rozpoczęte bezpiecznie. Natomiast, jest jakiś zrób na statu skala, który istnieje, że żadny rozpoczęt potencjalnie będzie załatwić kilka minut. I też, to trzeba regenerować wszystkie kluczy, więc to jest jakby wzajemny w terms start-up time. Więc okazjonalny rozpoczęt jest fajny. Aby rozpocząć to za dużo, to będzie problem. I dwa scenariusze, które będziecie zobaczyć w szczególności, jest kluczy autoskalerów, próbujące opłacić na górę. To jest rani-con. Co się dzieje, będzie się odwrócić, będzie się rozpocząć sobie, przed tym, to jest wreszcie rano. Aby rozpocząć, będzie się odwrócić opłacę na górę. Więc będzie się rozpocząć sobie, ale nie będzie się opłacić. To było znalazło w prace i znalazło to descriptions, które będą poprzednicy, to naprawdę jest okazjonalny. Tutaj, ch Councillors to, co jestboną, czy sąb, czy sąb i czy sąb, czy sąb, czy sąb po prostu ranoinko. To jest składnik. I to jest do tego, jestb, czy sąb, czy sąb, Przerabiamy klasera autoskalera z tym, by używać klaserów pdb lub zabezpiecznych anotacji klasera autoskalera. To będzie zabezpieczna klasera autoskalera, ale nie jest 100% bóledny. Są inne mechanizmy, które mogą zacząć. Wydaje mi się, że podpryjemcja jest jednym ze względem, gdzie system warstwa zawsze będzie mieć większą priorytę i może podpryjemować klaser autoskaler. Wreszcie, jest solucja, którą używamy w GKE, w której rekomenduję w niebezpiecznych environmentach, w których mamy dostęp do kontrolnego planu, jest po prostu zabezpieczna klasera autoskalera z kontrolnego planu VMS. To naprawdę jest częścią tej skazji, więc to ma sens konceptualnie, że zabezpieczna klasera autoskalera z tym, i to po prostu będzie całkowicie zabezpieczna, jaki są te odpowiednień w odwiedzeniu wytrzym Stanley Uwecki. Wreszcie, myślę, że to nie jest naprawdę bardzo niesamowite, ale chciałbym rekomendować kontrolę na GKE przez przednie],,znięcie. I dwaegej elementy, chciałbym wyzwyczaić tutaj. To są klaser autoskaleri. Od razu są bardzo zlożne bez dépendu, które są dla innych sesi, thresholds or scaled down timers are very commonly tweaked and there isn't much that can go wrong. However, some flags aren't really used that often and have some significant side effects. I am going to particularly mention ignore taint flag here. I could really spend half an hour talking about exactly how it changes internal behavior of cluster autoscaler. And I've seen so many issues caused by these flags. I'm just going to warn you against this and if you want to use it, I would suggest testing it in some sort of staging environment. And of course, things work differently at scale. Especially with things like autoscaler, adding one node and adding a thousand nodes may take a very different amount of time and it's always worth testing. All right, so with this, let me move on to the tools that I think are useful for running and monitoring cluster autoscaler. And the first are going to be metrics. And I think if there is one thing I'd like you to remember from this presentation, it's really going to be this slide. As I said already, the job of cluster autoscaler is to make sure that all the pods are schedulable. And so I think the best way to monitor that it's achieving this job is to monitor the number of pending pods. If there are any pods that are pending for a really long time, that just means that the job of cluster autoscaler is not being done. It doesn't necessarily mean the problem is in autoscaler itself, however it means it's not really achieving its task. And I think autoscaler is a good place to start debugging such issues. There is, I think, a very convenient metric for this. Kubernetes scheduler has a pending podmetrics that I think is ideal here. Actually cluster autoscaler has its own metric, but that essentially gives you the same number. But I just prefer using a metric provided by other component, because then if there is a problem with autoscaler, you will still have a metric coming from scheduler. And so I think if you just want a single alert for cluster autoscaler, I think that's the best one. I would also recommend maybe alerting on the fact that cluster autoscaler is running. I don't necessarily have a slide for this, because I think exactly how you monitor this depends heavily on how you run it. If you run it on control plane or on your nodes, you may want to use a different metric, but that's also something useful. And there are many more cluster autoscaler metrics, however, I'm just going to focus on, I think, four maybe, other metrics, and I'm just going to use three graphs as I go through different issues that I think are most useful for debugging. And so in addition to pending pods, what I think is a super useful graph for any sort of debugging, is a graph that just shows you nodes in the cluster by different state. There is a cluster autoscaler metric for that. And on the same graph just have a rate of scale up and scale down by cluster autoscaler. I'm going to show this graph in a second, and hopefully I will be able to convince you that it is a really great, very useful graph. And I think it's also useful looking for different metrics that report the error rates of cluster autoscaler. I think failed scale ups total is in a particularly useful one. If your scale ups are failing, there is likely an issue that may require attention. The errors total metric is also there, but it's more noisy because it's going to capture sort of random 500, one of transient errors that you get from crowd provider. And so I found this one to be much more noisy and such sort of less useful, but it's definitely also something worth looking at if there is an issue. And so I mentioned the graph that shows both the nodes and cluster autoscaler activity and that's this graph here. And I just want to go through how a typical scale up looks like. This is basically what you'd expect if your scale up goes perfectly well. So on the bottom graph I have the number of pending pods. I have been splitting these different cues in scheduler. I don't think that's really strictly necessary. It's useful sometimes for catching if an issue is in cluster autoscaler or scheduler itself. It's possible that the sort of nodes are there, but the pods get stuck in scheduler. But I'm not really going to focus on this. So if you just aggregate all of those cues together, that's also fine. So what we see here is basically the number of pending pods go up. And in response we can see the scale up rate in cluster autoscaler to also go up. That's the bold line on the top graph. And as the scale up happens, we can see more nodes, like the number of nodes is increasing. And initially those new nodes are on this graph, they are red. So that means that they are unregistered. So those are VMs that are already there on cloud provider site. However they don't yet have a corresponding node object in Kubernetes. So the VM is maybe spinning up. The operating system is starting up. The kubelet is initializing and so on. It all takes time. But we see the VMs are already there. There is this small yellow window where the VMs are not started. That means that the node object is already there. However, it's not yet ready. So the status condition shows that the node isn't ready yet. And this is basically how every scale up is going to look like. You're going to first see those unregistered nodes, then you're going to see not started nodes and finally you're going to have ready nodes that are just going to be able to run your pods. And I'm going to show how distinguishing those different stages of node lifecycle is going to be helpful later on when I get to some issues. I'm also going to quickly cover how a scale down would look like on the same graph. I don't have pending pods this time because if cluster autoscale is scaling down that probably means that there aren't any. But we can see here the rate of scale down going up again and that's the bold line and then the number of nodes is decreasing. So that's pretty obvious but one thing that's very useful and I think that's commonly used by me or seen by me in many issues is that the lack of the scale down activity by cluster autoscaler can be very telling here. So sometimes there are other ways that the number of nodes can change. Someone may resize their node group manually or maybe there is some sort of upgrade mechanism that can delete nodes. There can be other things than cluster autoscaler that can delete nodes and just looking at this graph would tell you immediately that the number of nodes have decreased without autoscaler intervention if there is a fall in the number of nodes but there is no scale down rate increasing. So this is why I find this useful to just filter out issues that aren't really escalated to autoscaler. One thing I wanted to mention is Kubernetes events. So cluster autoscaler write Kubernetes events on ports, nodes and cluster autoscaler status config map in kube system. The config map basically will give you an event log of all the actions taken by autoscaler and the port events can tell you why cluster autoscaler is not scaling up even if certain port is pending or it can show you that cluster autoscaler in fact has triggered a scale up specifically because this port was pending. I think it's quite useful for debugging, especially those problems where cluster autoscaler is not scaling up when you think it should be and it's definitely much easier and faster than going to the logs. The logs are sort of to me the last resort if nothing else has helped if there is no events, if there is no metrics then I would go to logs. I think they are very verbose and sometimes hard to understand so I wouldn't recommend starting there and if you have to read the logs I think two main suggestions I would have. So firstly cluster autoscaler runs in loops and each loop is essentially independent so cluster autoscaler will reconcile state of the cluster it will look for any pending ports it will see if they would maybe be able to schedule on the nodes that are already booting up and if nodes is going to trigger a scale up and it's just going to run those loops over and over and over so if you're debugging an issue I would just focus on a single loop I have the log lines on the slide for graping but I would just focus on a single loop and just try to debug it there because it's just going to repeat over and over there isn't that much point reading it equal and then in some loop the scale up will happen the first time autoscaler note this is a pending port it will trigger a scale up and then for a number of following loops what's going to happen is it will see that there are nodes already spinning up and it will just do nothing waiting for those so you always want to debug the loop where the actual decision was made and so the very first thing I do whenever I look at logs if I'm going to look for this final scale up plan log there are the logs associated with scale up that's just the one I like using it's going to be there whenever there is a scale up so I think it's quite useful so with this let me quickly move on to showing how I would use those metrics and events to debug some common issues and the first one I have is any sort of cloud provider error so what we see here basically cluster autoscaler notices pending ports we see there is a number of pending ports so an alert on this would detect the problem and it's trying to scale up and it's basically nothing is happening it's just repeatedly trying and failing and if we look at the failed scale up graph we see those scale ups are indeed failing and there is a reason there so that just makes it pretty obvious what the problem is in this case I just run out of quota for I think CPUs in my project I can see what the quota is but I already know it's a quota exhaustion issue so I can just go to logs now and probably find that quite easily and the thing with this is actually another thing I wanted to quickly show up is how cluster autoscaler retries the scale up periodically however those periods are increasing this is because cluster autoscaler uses an exponential backoff mechanism so it will start by retrying very often but it will over time retry less and less until it hits the maximum backoff duration of half hour and so this is kind of common in issues everything in that graph would look the same for any other sort of cloud provider side issue so it may be that the cloud provider is out of stock and there is no quota issue it would look the same it's just that the label on the metric would be different or that there may be some sort of IP space exhaustion issue for example there is any number of things that can go wrong on cloud provider side one thing is that the labels on the failed scale up metric depend on the particular cloud provider implementation giving a structured information about what the error is and that often ends up I think just with regex on error messages that are specific to a given cloud provider so the level of detail you get may be different depending on what error a given provider recognizes right another issue that is I think literally the most common type of issue is that the nodes are failing to start it's different, we're not getting an error when we make an API call to cloud provider the VMs are actually getting created and you can see this in the graph here cluster auto scale is trying to scale up and then we see those red unregistered nodes so the VMs are there they are getting created, it's just that they are unable to join Kubernetes cluster and we see in this case the scale ups are failing because of 15 minute time out so basically cluster auto scale will give 15 min to register and if it fails to do so it assumes there is some sort of a problem and it's going to delete that VM and retry later on this usually happens because of networking issues but there can be any number of reasons I produced this particular graph by just creating a firewall rule that prevented Kubelet from reaching API server this is a very common issue but there can be any number of other issues image pooling problems are also quite common really anything can go wrong on the node site another one I wanted to quickly show up was no option to scale up so this is what I also mentioned earlier when talking about events cluster auto scaler may not even try to scale up because it doesn't think the pod will be able to schedule on any of the nodes which one can create I think the most simple case or most simple reason for this is if your pod has a node selektor but there is no node group that has the matching label cluster auto scaler will not scale up because there is no point at least as far as auto scaler is concerned and then it will write an event on the pod so if you just cube cut describe the pod there will be a node trigger scale up event it's going to have a message one thing about reading those messages it says I think one node didn't match node selektor in this case because we reusing schedule error messages but this really should be read as one node group was not scaled up because nodes in that node group would not match the node selektor so I only had one node group there and it didn't have the node selektor I needed and I think that's what I wanted to discuss I'm happy to take any questions now