Jeg skabte Kube Eagle - en Prometheus-eksportør. Det viste sig at være en fed ting, der hjælper til bedre at forstå ressourcerne i små og mellemstore klynger. I sidste ende sparede jeg hundredvis af dollars, fordi jeg valgte de rigtige maskintyper og konfigurerede applikationsressourcegrænser for arbejdsbelastninger.
Jeg vil fortælle dig om fordelene , men først vil jeg forklare, hvad der forårsagede balladen, og hvorfor overvågning af høj kvalitet var nødvendig.
Jeg administrerede flere klynger af 4-50 noder. Hver klynge indeholder op til 200 mikrotjenester og applikationer. For at gøre bedre brug af eksisterende hardware blev de fleste implementeringer konfigureret med burstable RAM og CPU-ressourcer. På denne måde kan pods tage tilgængelige ressourcer, hvis det er nødvendigt, og samtidig ikke forstyrre andre applikationer på denne node. Jamen, er det ikke fantastisk?
Og selvom klyngen forbrugte relativt lidt CPU (8 %) og RAM (40 %), havde vi konstant problemer med at pods blev foregrebet, når de forsøgte at allokere mere hukommelse, end der var tilgængelig på noden. Dengang havde vi kun ét dashboard til overvågning af Kubernetes-ressourcer. Sådan her:
Grafana dashboard kun med cAdvisor-metrics
Med sådan et panel er det ikke et problem at se noder, der spiser meget hukommelse og CPU. Problemet er at finde ud af, hvad årsagen er. For at holde poderne på plads kunne man selvfølgelig opsætte garanterede ressourcer på alle pods (ønskede ressourcer lig med grænsen). Men dette er ikke den smarteste brug af hardware. Klyngen havde flere hundrede gigabyte hukommelse, mens nogle noder sultede, mens andre havde 4-10 GB tilbage i reserve.
Det viser sig, at Kubernetes-planlæggeren fordelte arbejdsbelastninger ujævnt på tværs af tilgængelige ressourcer. Kubernetes-planlægningsprogrammet tager højde for forskellige konfigurationer: affinitets-, tinding- og tolerationsregler, nodevælgere, der kan begrænse de tilgængelige noder. Men i mit tilfælde var der ikke noget lignende, og pods blev planlagt afhængigt af de ønskede ressourcer på hver node.
Den node, der har flest ledige ressourcer, og som opfylder anmodningsbetingelserne, blev valgt til poden. Vi fandt ud af, at de anmodede ressourcer på noderne ikke matchede den faktiske brug, og det var her, Kube Eagle og dens ressourceovervågningsfunktioner kom til undsætning.
Jeg har næsten alle Kubernetes-klynger kun overvåget med и . Node Exporter giver statistik om I/O og disk-, CPU- og RAM-brug, mens Kube State Metrics viser Kubernetes-objektmålinger såsom anmodninger og CPU- og hukommelsesressourcegrænser.
Vi skal kombinere brugsmålingerne med anmodnings- og grænsemålingerne i Grafana, og så får vi alle oplysninger om problemet. Det lyder simpelt, men de to værktøjer navngiver faktisk etiketterne forskelligt, og nogle metrics har slet ikke nogen metadata-etiketter. Kube Eagle gør alt selv, og panelet ser sådan ud:
Vi formåede at løse mange problemer med ressourcer og spare udstyr:
- Nogle udviklere vidste ikke, hvor mange ressourcer mikrotjenester havde brug for (eller gad simpelthen ikke). Der var ingen måde for os at finde forkerte anmodninger om ressourcer - til dette skal vi kende forbrug plus anmodninger og grænser. Nu ser de Prometheus-metrics, overvåger faktisk brug og justerer anmodninger og grænser.
- JVM-applikationer tager så meget RAM, som de kan håndtere. Skraldesamleren frigiver kun hukommelse, når mere end 75 % bruges. Og da de fleste tjenester har burstable hukommelse, var den altid optaget af JVM. Derfor spiste alle disse Java-tjenester meget mere RAM end forventet.
- Nogle programmer anmodede om for meget hukommelse, og Kubernetes-planlæggeren gav ikke disse noder til andre programmer, selvom de faktisk var friere end andre noder. En udvikler tilføjede ved et uheld et ekstra ciffer i anmodningen og greb et stort stykke RAM: 20 GB i stedet for 2. Ingen lagde mærke til det. Applikationen havde 3 replikaer, så så mange som 3 noder blev påvirket.
- Vi introducerede ressourcegrænser, omplanerede pods med de korrekte anmodninger og fik en ideel balance mellem hardwarebrug på tværs af alle noder. Et par noder kunne have været lukket helt. Og så så vi, at vi havde de forkerte maskiner (CPU-orienteret, ikke hukommelsesorienteret). Vi ændrede typen og slettede flere noder.
Resultaterne af
Med sprængbare ressourcer i klyngen bruger du den tilgængelige hardware mere effektivt, men Kubernetes-planlægningsprogrammet planlægger pods baseret på anmodninger om ressourcer, og det er fyldt. For at slå to fluer med ét smæk: For at undgå problemer og bruge ressourcerne fuldt ud, har du brug for god overvågning. Det er derfor, det vil være nyttigt (Prometheus eksportør og Grafana dashboard).
Kilde: www.habr.com