{"id":91199,"date":"2020-08-10T01:42:03","date_gmt":"2020-08-09T23:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov"},"modified":"2020-08-10T01:42:03","modified_gmt":"2020-08-09T23:42:03","slug":"kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","title":{"rendered":"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Mijn naam is Viktor Yagofarov, en ik ben verantwoordelijk voor de ontwikkeling van het Kubernetes-platform bij het bedrijf DomKlik als technisch directeur van de ontwikkelingsafdeling binnen het Ops-team (operaties). Ik wil u vertellen over de werking van onze Dev  Ops-processen, de bijzonderheden van het beheer van een van de grootste k8s-clusters in Rusland, en over de DevOps\/SRE-praktijken die ons team toepast.<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/6c908104c734b36cc7a960fbe4d65e3f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>Ops-team<\/h4>\n<p>\nMomenteel werken er 15 mensen in het Ops-team. Drie van hen zijn verantwoordelijk voor kantoor, twee werken in een andere tijdzone en zijn ook 's nachts beschikbaar. Zo is er altijd iemand van Ops bij het scherm en klaar om te reageren op een incident van welke complexiteit dan ook. We hebben geen nachtdiensten, wat onze geest gezond houdt en ons in staat stelt om uit te rusten en ons vrije tijd niet alleen achter de computer door te brengen.<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/47051db273f116df376e64bad67c6f37.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIedereen heeft verschillende competenties: netwerkengineers, DBA's, specialisten op het ELK-stapel, Kubernetes-beheerders\/ontwikkelaars, monitoring-, virtualisatie- en hardware-experts, enzovoort. Wat ons verenigt is het feit dat iedereen in bepaalde mate elk van ons kan vervangen: bijvoorbeeld nieuwe knooppunten in het k8s-cluster introduceren, PostgreSQL bijwerken, een CI\/CD-pipeline + Ansible schrijven, iets automatiseren met Python\/Bash\/Go, hardware aansluiten in een datacenter. Sterke competenties in een bepaald gebied belemmeren niet de mogelijkheid om van richting te veranderen en te beginnen met het ontwikkelen in een ander gebied. Bijvoorbeeld, ik begon bij het bedrijf als PostgreSQL-specialist, en nu is mijn belangrijkste verantwoordelijkheidsgebied Kubernetes-clusters. Groei binnen het team wordt alleen aangemoedigd en de teamgeest is sterk ontwikkeld.<\/p>\n<p>Overigens, we zijn op zoek naar mensen. De vereisten voor kandidaten zijn vrij standaard. Persoonlijk vind ik het belangrijk dat iemand in het team past, niet conflictueus is, maar ook zijn of haar standpunt kan verdedigen, zich wil ontwikkelen en niet bang is om iets nieuws te proberen, en idee\u00ebn kan aandragen. Daarnaast zijn programmeerkennis in scripttalen, basiskennis van Linux en de Engelse taal verplicht. Engels is nodig zodat iemand bij een probleem snel een oplossing kan googelen binnen 10 seconden in plaats van 10 minuten. Het is tegenwoordig moeilijk om specialisten met diepgaande Linux-kennis te vinden: het is grappig, maar twee van de drie kandidaten kunnen de vraag<\/p>\n<h4>Team Tools<\/h4>\n<p>\nHet Tools-team speelt een aanzienlijke rol in automatisering. Hun hoofdtaken zijn het ontwikkelen van gebruiksvriendelijke grafische en CLI-tools voor ontwikkelaars. Bijvoorbeeld, onze interne tool Confer maakt het mogelijk om met slechts een paar muisklikken een applicatie naar Kubernetes te implementeren, de middelen, sleutels uit de vault enz. in te stellen. Voorheen gebruikten we Jenkins + Helm 2, maar we moesten onze eigen tool ontwikkelen om copy-paste te vermijden en uniformiteit in de softwarelevenscyclus te brengen.<\/p>\n<p>Het Ops-team schrijft geen pipelines voor ontwikkelaars, maar kan hen adviseren over allerlei vragen rondom het schrijven hiervan (sommigen hebben nog steeds Helm 3).<\/p>\n<h4>DevOps<\/h4>\n<p>\nWat betreft DevOps, zien wij dit als volgt:<\/p>\n<p>De Dev-teams schrijven code en implementeren deze via Confer in dev -&gt; qa\/stage -&gt; prod. De verantwoordelijkheid ervoor dat de code niet traag is of fouten geeft, ligt bij de Dev- en Ops-teams. Tijdens kantooruren moet de teamleider van Ops in de eerste plaats reageren op een incident met zijn applicatie, en in de avond en nacht moet de beheerder (Ops) de ontwikkelaar wakker maken als hij zeker weet dat het probleem niet in de infrastructuur ligt. Alle metrics en alerts in de monitoring verschijnen automatisch of semi-automatisch.<\/p>\n<p>De verantwoordelijkheid van Ops begint zodra de applicatie in productie wordt uitgerold, maar de verantwoordelijkheid van Dev eindigt hier niet - we doen hetzelfde werk en zitten in hetzelfde schuitje.<\/p>\n<p>Ontwikkelaars adviseren systeembeheerders wanneer hulp nodig is bij het schrijven van een admin-microservice (bijvoorbeeld, Go backend + HTML5), en systeembeheerders adviseren ontwikkelaars over infrastructuurkwesties of zaken gerelateerd aan k8s.<\/p>\n<p>Overigens hebben we helemaal geen monoliet, alleen microservices. Hun aantal schommelt momenteel tussen de 900 en 1000 in de prod k8s-cluster, als we meten op basis van aantal. <i>deployments<\/i>Het aantal pods schommelt tussen de 1700 en 2000. Het aantal pods in de prod-cluster ligt momenteel rond de 2000.<\/p>\n<p>Ik kan geen exacte cijfers geven, omdat we onnodige microservices volgen en deze in een semi-automatische modus verwijderen. Om onnodige entiteiten in k8s te volgen, helpt ons <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Nastradamus\/useless-operator\">useless-operator<\/a><\/noindex>, wat echt kosten en middelen bespaart.<\/p>\n<h2> Resourcebeheer <\/h2>\n<p><\/p>\n<h4> Monitoring <\/h4>\n<p>\nEen goed gestructureerde en informatieve monitoring wordt de hoeksteen van het beheren van een grote cluster. Tot nu toe hebben we geen universele oplossing gevonden die 100 % van alle monitoringwensen dekt, dus maken we af en toe verschillende op maat gemaakte oplossingen in deze omgeving.<\/p>\n<ul>\n<li><b>Zabbix<\/b>. Goede oude monitoring, die in de eerste plaats bedoeld is voor het volgen van de algemene toestand van de infrastructuur. Het vertelt ons wanneer een node faalt op CPU, geheugen, schijven, netwerk, enzovoort. Niets bovennatuurlijks, maar we hebben ook een aparte DaemonSet van agents waarmee we bijvoorbeeld de toestand van DNS in de cluster monitoren: we zoeken naar traagheid bij de pods van coredns en controleren de beschikbaarheid van externe hosts. Het lijkt misschien overbodig, maar bij grote hoeveelheden verkeer is dit component een serieus knelpunt. Eerder heb ik al <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/domclick\/blog\/495450\/\">beschreven<\/a><\/noindex>, hoe ik de DNS-prestaties in de cluster heb aangepakt.<\/li>\n<li><b>Prometheus Operator<\/b>. Een set verschillende exporters biedt een goed overzicht van alle componenten van de cluster. Vervolgens visualiseren we dit alles op grote dashboards in Grafana, en voor waarschuwingen gebruiken we alertmanager.\n<\/li>\n<\/ul>\n<p>\nEen andere nuttige tool voor ons is <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Nastradamus\/list-ingress\">list-ingress<\/a><\/noindex>. We wrote it after encountering several situations where one team's Ingress paths were overlapping with another's, leading to 50x errors. Now, before deploying to production, developers check that they won't affect anyone else, and for my team, it's a good tool for initial diagnostics of Ingress issues. Interestingly, it was initially created for admins and looked quite 'rudimentary', but after it became popular with development teams, it transformed significantly and no longer resembled 'an admin's web interface for admins'. Soon we will phase out this tool, and similar situations will be validated even before the pipeline is released.<\/p>\n<h4>Team Resources in 'Kube'<\/h4>\n<p>\nBefore diving into examples, it's worth explaining how we allocate resources for <i>microservices<\/i>.<\/p>\n<p>To understand which teams and in what quantities utilize their <i>resources<\/i> (CPU, memory, local SSD), we allocate a specific <i>namespace<\/i> in 'Kube' and limit its maximum capabilities regarding CPU, memory, and disk, having previously discussed the teams' needs. Accordingly, one team generally will not block the entire cluster for deployment by allocating thousands of cores and terabytes of memory to themselves. Access within the namespace is granted through AD (we use RBAC). Namespaces and their limits are added through a pull request in the GIT repository, and then everything is automatically deployed through the Ansible pipeline.<\/p>\n<p>Example of resource allocation for a team:<\/p>\n<pre><code class=\"go\">namespaces:\n\n  chat-team:\n    pods: 23\n    limits:\n      cpu: 11\n      memory: 20Gi\n    requests:\n      cpu: 11\n      memory: 20Gi\n<\/code><\/pre>\n<p><\/p>\n<h4>Requests and Limits<\/h4>\n<p>\nIn 'Kube' <i>Request<\/i> \u2014 is the amount of resources guaranteed to be reserved for <i>pod<\/i> (one or more Docker containers) in the cluster. Limit is an unguaranteed maximum. It is often observed in charts how some team set too many requests for all their applications and cannot deploy an application in 'Kube', as all requests in their namespace have already been 'spent'.<\/p>\n<p>The correct way out of such situations: to monitor actual resource consumption and compare it with the requested amount (Request).<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/417373d4421064f28d57a03b6bb5bf94.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/3168ad6dc8b159059b21e1177e145376.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn the screenshots above, it\u2019s evident that the 'requested' (Requested) CPU matches the actual number of threads, while Limits may exceed the actual number of CPU threads =)<\/p>\n<p>Laten we nu eens gedetailleerd bekijken hoe een namespace werkt (ik heb gekozen voor de namespace kube-system \u2014 de systeemnamespace voor de componenten van \u00abKube\u00bb) en de verhouding van werkelijk gebruikt CPU-tijd en geheugen ten opzichte van het gevraagde bekijken:<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/ed6160de5397b8cd39cbae172d4bb872.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet is duidelijk dat er veel meer geheugen en CPU is gereserveerd voor systeemdiensten dan werkelijk wordt gebruikt. In het geval van kube-system is dit gerechtvaardigd: het is voorgekomen dat de nginx ingress controller of nodelocaldns op hun piek tegen de CPU-limiet aanliepen en veel RAM verbruikten, dus om die reden is er zo'n reserve gerechtvaardigd. Bovendien kunnen we niet alleen vertrouwen op grafieken van de afgelopen 3 uur: het is wenselijk om historische statistieken over een langere periode te bekijken.<\/p>\n<p>Er is een systeem van \u00abaanbevelingen\u00bb ontwikkeld. Hier kun je bijvoorbeeld zien welke resources het beste \u00ablimieten\u00bb (de bovenste toegestane grens) kunnen krijgen om \u00abthrottling\u00bb te voorkomen: het moment waarop CPU of geheugen al is verbruikt over de toegewezen tijdsperiode en wacht tot het weer \u00abontdooid\u00bb wordt:<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/f23aece10a585e6847bcacfe947031d1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn hier zijn de pods die hun verlangens zouden moeten matigen:<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/1ec9996ce6355aeba603008d51aac209.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOver <i>throttling<\/i> + het monitoren van resources is een onderwerp waar je meerdere artikelen over kunt schrijven, dus stel je vragen in de reacties. Kortom, de uitdaging om dergelijke metrics te automatiseren is behoorlijk complex en vereist veel tijd en acrobatiek met \u00abwindow\u00bb-functies en \u00abCTE\u00bb Prometheus \/ VictoriaMetrics (deze termen zijn tussen aanhalingstekens gezet, omdat er in PromQL bijna niets dergelijks is, en je moet enorme queries maken van meerdere schermen tekst en deze optimaliseren).<\/p>\n<p>Uiteindelijk hebben developers tools om hun namespaces in \u00abKube\u00bb te monitoren, en ze kunnen zelf kiezen waar en wanneer ze resources van welke applicaties kunnen \u00abknippen\u00bb, en welke pods de hele nacht alle CPU mogen gebruiken.<\/p>\n<h4>Methodologie\u00ebn<\/h4>\n<p>\nIn het bedrijf, zoals het nu is <i>in de mode<\/i>, volgen we DevOps- en <i>SRE<\/i>-praktijken. Wanneer er in het bedrijf 1000 microservices zijn, ongeveer 350 ontwikkelaars en 15 admins voor de hele infrastructuur, moet je \u00abin de mode\u00bb zijn: achter al deze \u00abbuzzwords\u00bb schuilt een dringende behoefte aan automatisering van alles en nog wat, en admins mogen geen knelpunt in de processen zijn.<\/p>\n<p>Als Ops bieden we verschillende metrics en dashboards voor ontwikkelaars aan, gerelateerd aan de responstijd van services en hun fouten.<\/p>\n<p>We gebruiken methodologie\u00ebn zoals: <noindex><a rel=\"nofollow\" href=\"https:\/\/thenewstack.io\/monitoring-microservices-red-method\/\">RED<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/usemethod.html\">USE<\/a><\/noindex> en <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/forepaas\/distributed-monitoring-101-the-four-golden-signals-305bbbc33d35\">Golden Signals<\/a><\/noindex>, door ze samen te combineren. We proberen het aantal dashboards te minimaliseren, zodat in \u00e9\u00e9n oogopslag duidelijk is welke service momenteel degradeert (bijvoorbeeld de responscodes per seconde, responstijd op het 99e percentiel), enzovoort. Zodra er nieuwe metrics nodig zijn voor de gezamenlijke dashboards, tekenen en voegen we ze onmiddellijk toe.<\/p>\n<p><i>Ik heb al een maand geen grafieken getekend. Misschien is dat een goed teken: dat betekent dat de meeste 'verlangens' al zijn gerealiseerd. Het is wel eens gebeurd dat ik in een week tenminste \u00e9\u00e9n keer per dag een nieuwe grafiek tekende.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/574f1b4d2be78fb779f1771bffac51dd.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/6ab2aa05f912839b14bdbcf84faaeb3a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet resultaat is waardevol omdat de ontwikkelaars nu vrij zeldzaam bij de beheerders komen met de vraag 'waar kan ik een bepaalde metric bekijken'.<\/p>\n<p>Implementatie <i>Service Mesh<\/i> is dichtbij en zou het leven voor iedereen aanzienlijk moeten vergemakkelijken. Collega's van Tools zijn al dicht bij de implementatie van een abstracte 'gezonde Istio': de levenscyclus van elke HTTP(s)-aanroep zal zichtbaar zijn in de monitoring, en je kunt altijd begrijpen 'op welk moment alles stuk ging' tijdens de tussenservice (en niet alleen) interactie. Abonneer je op het nieuws van het bedrijfshub van DomClick. =)<\/p>\n<h2>Ondersteuning voor Kubernetes-infrastructuur<\/h2>\n<p>\nHistorisch gezien gebruiken we een gepatchte versie <i>Kubespray<\/i> - Ansible-rol voor het inrichten, uitbreiden en updaten van Kubernetes. Op een bepaald moment werd de ondersteuning voor non-kubeadm installaties uit de hoofdvertakking gehaald, en er werd geen proces voorgesteld voor de overstap naar kubeadm. Uiteindelijk heeft het bedrijf Southbridge zijn eigen fork gemaakt (met ondersteuning voor kubeadm en snelle fixes voor kritieke problemen). <\/p>\n<p>Het proces voor het updaten van alle k8s-clusters verloopt als volgt:<\/p>\n<ul>\n<li>We nemen <i>Kubespray<\/i> van Southbridge, controleren deze met onze vertakking, en mergen.<\/li>\n<li>We voeren de update uit in <i>Stress<\/i>-'Cube'.<\/li>\n<li>We voeren de update uit per node (in Ansible is dat 'serial: 1') in <i>Dev<\/i>-'Cube'.<\/li>\n<li>We updaten <i>Prod<\/i> op zaterdagavond per node.<\/li>\n<\/ul>\n<p>\nIn de toekomst zijn er plannen om <i>Kubespray<\/i> te vervangen door iets sneller en over te schakelen naar <i>kubeadm<\/i>.<\/p>\n<p>In totaal hebben we drie 'Cubes': Stress, Dev en Prod. We zijn van plan nog een te lanceren (<i>hot standby<\/i>) Prod-'Cube' in de tweede datacenter. <i>Stress<\/i> en <i>Dev<\/i> leiden een leven in 'virtuele machines' (oVirt voor Stress en VMWare cloud voor Dev). <i>Prod<\/i>-'Cube' draait op 'bare metal': dit zijn identieke nodes met 32 CPU-threads, 64-128 GB RAM en 300 GB SSD RAID 10 \u2014 in totaal 50 stuks. Drie 'dunne' nodes zijn gereserveerd voor de 'masters' van <i>Prod<\/i>-'Cube': 16 GB RAM, 12 CPU-threads.<\/p>\n<p>Voor de productie geven we de voorkeur aan het gebruik van 'bare metal' en vermijden we extra lagen zoals <i>OpenStack<\/i>: we hebben geen 'luidruchtige buren' nodig en CPU <i>steal time<\/i>. En de complexiteit van het beheer neemt ongeveer twee keer zoveel toe in het geval van in-house OpenStack.<\/p>\n<p>Voor CI\/CD gebruiken we een aparte GIT-server voor \u00abKubernetes\u00bb en andere infrastructuurcomponenten, Helm 3 (overgestapt van Helm 2 met enige moeite, maar we zijn erg blij met de optie <i>atomic<\/i>), Jenkins, Ansible en Docker. We houden van feature branches en het uitrollen naar verschillende omgevingen vanuit \u00e9\u00e9n repository.<\/p>\n<h3>Conclusie<\/h3>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: hoe gerust te slapen terwijl je een cluster met 1000 microservices beheert\" src=\"\/wp-content\/uploads\/2020\/08\/34ddcd1f275c63c1ad821218d16b5abb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nZo ziet het DevOps-proces van de operationele ingenieur eruit bij het bedrijf DomClick. Het artikel is minder technisch geworden dan ik had verwacht: volg daarom het nieuws van DomClick op Habr: er komen meer 'hardcore' artikelen over Kubernetes en meer.<br \/>\n<br \/>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/domclick\/blog\/501122\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0412\u0438\u043a\u0442\u043e\u0440 \u042f\u0433\u043e\u0444\u0430\u0440\u043e\u0432, \u0438 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c Kubernetes-\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0432 \u0434\u043e\u043b\u0436\u043d\u043e\u0441\u0442\u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops (\u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f). \u042f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e\u0431 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0435 \u043d\u0430\u0448\u0438\u0445 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432 Dev &lt;-&gt; Ops, \u043e\u0431 \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u044f\u0445 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u043e\u0434\u043d\u043e\u0433\u043e \u0438\u0437 \u0441\u0430\u043c\u044b\u0445 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 k8s-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432 \u0432 \u0420\u043e\u0441\u0441\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e DevOps\/SRE-\u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0435\u0442 \u043d\u0430\u0448\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430. \u041a\u043e\u043c\u0430\u043d\u0434\u0430 Ops \u0412 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91200,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91199","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0412\u0438\u043a\u0442\u043e\u0440 \u042f\u0433\u043e\u0444\u0430\u0440\u043e\u0432, \u0438 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c Kubernetes-\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0432 \u0434\u043e\u043b\u0436\u043d\u043e\u0441\u0442\u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops (\u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f).\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Kubernetes \u0432 \u0414\u043e\u043c\u041a\u043b\u0438\u043a: \u043a\u0430\u043a \u0441\u043f\u0430\u0442\u044c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e, \u0443\u043f\u0440\u0430\u0432\u043b\u044f\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u043c \u043d\u0430 1000 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0412\u0438\u043a\u0442\u043e\u0440 \u042f\u0433\u043e\u0444\u0430\u0440\u043e\u0432, \u0438 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c Kubernetes-\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0432 \u0434\u043e\u043b\u0436\u043d\u043e\u0441\u0442\u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops (\u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f).\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-09T23:42:03+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-09T23:42:03+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Kubernetes bij DomClick: hoe je rustig kunt slapen terwijl je een cluster van 1000 microservices beheert | ProHoster","description":"Mijn naam is Viktor Yagofarov, en ik ben verantwoordelijk voor de ontwikkeling van het Kubernetes-platform bij het bedrijf DomClick als technisch teamleider in het Ops-team (operatie).","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Kubernetes \u0432 \u0414\u043e\u043c\u041a\u043b\u0438\u043a: \u043a\u0430\u043a \u0441\u043f\u0430\u0442\u044c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e, \u0443\u043f\u0440\u0430\u0432\u043b\u044f\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u043c \u043d\u0430 1000 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 | ProHoster","og:description":"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0412\u0438\u043a\u0442\u043e\u0440 \u042f\u0433\u043e\u0444\u0430\u0440\u043e\u0432, \u0438 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c Kubernetes-\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0432 \u0434\u043e\u043b\u0436\u043d\u043e\u0441\u0442\u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops (\u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f).","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-09T23:42:03+00:00","article:modified_time":"2020-08-09T23:42:03+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91199","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:32:23","updated":"2022-09-28 06:43:59","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/91199","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=91199"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/91199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/91200"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=91199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=91199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=91199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}