{"id":94262,"date":"2020-09-14T19:42:34","date_gmt":"2020-09-14T17:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod"},"modified":"2020-09-14T19:42:34","modified_gmt":"2020-09-14T17:42:34","slug":"kak-poluchit-dostup-k-resursam-kubernetes-pod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","title":{"rendered":"Hoe toegang te krijgen tot de resources van Kubernetes Pod","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Hoe toegang te krijgen tot de resources van Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/3d6760d512ef456daad121f7d1ddbcf8.jpg\" style=\"display:block;margin: 0 auto;\" \/><noindex><a rel=\"nofollow\" href=\"https:\/\/www.deviantart.com\/tohad\/art\/The-Reward-549720998\"><i>De Beloning door Tohad<\/i><\/a><\/noindex><\/p>\n<p>Aan het begin van het werken met Kubernetes wordt vaak vergeten om de resources van containers in te stellen. In deze fase is het voldoende om ervoor te zorgen dat het Docker-image functioneert en uitgerold kan worden in het Kubernetes-cluster.<\/p>\n<p>Later moet de applicatie worden uitgerold in een productiecluster samen met andere applicaties. Hiervoor moeten resources aan de container worden toegewezen en moet worden gecontroleerd of deze voldoende zijn voor het starten en functioneren van de applicatie, zonder dat dit problemen veroorzaakt bij andere draaiende applicaties.<\/p>\n<p>Opdracht <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Kubernetes aaS van Mail.ru<\/a><\/noindex> heeft het artikel over containerresources (CPU &amp; MEM), aanvragen en resource-beperkingen vertaald. U zult leren welke voordelen deze instellingen bieden en wat er gebeurt als u ze niet instelt.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Rekenkracht<\/h2>\n<p>\nWe hebben twee soorten resources met de volgende eenheden:<\/p>\n<ul>\n<li>Centraal processor (CPU) \u2014 cores;<\/li>\n<li>Geheugen (MEM) \u2014 bytes.<\/li>\n<\/ul>\n<p>\nResources worden aangegeven voor elke container. In het volgende YAML-bestand van de Pod ziet u de sectie resources, die de aangevraagde en maximale resources bevat:<\/p>\n<ul>\n<li>Aangevraagde resources van de Pod = som van de aangevraagde resources van alle containers;<\/li>\n<li>Maximale resources van de Pod = som van de maximale resources van alle containers.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"plaintext\">apiVersion: v1\nkind: Pod\nmetadata:\n  name: backend-pod-name\n  labels:\n    application: backend\nspec:\n  containers:\n    - name: main-container\n      image: my-backend\n      tag: v1\n      ports:\n      - containerPort: 8080\n      resources:\n        requests:\n          cpu: 0.2 # GEVRAAGDE CPU: 200m cores\n          memory: \"1Gi\" # GEVRAAGDE GEHEUGEN: 1Gi\n        limits:\n          cpu: 1 # MAX CPU GEBRUIK: 1 core\n          memory: \"1Gi\" # MAX GEHEUGEN GEBRUIK: 1Gi\n    - name: other-container\n      image: other-app\n      tag: v1\n      ports:\n      - containerPort: 8000\n      resources:\n        requests:\n          cpu: \"200m\" # GEVRAAGDE CPU: 200m cores\n          memory: \"0.5Gi\" # GEVRAAGDE GEHEUGEN: 0.5Gi\n        limits:\n          cpu: 1 # MAX CPU GEBRUIK: 1 core\n          memory: \"1Gi\" # MAX GEHEUGEN GEBRUIK: 1Gi<\/code><\/pre>\n<p>Voorbeeld van aangevraagde en maximale resources<\/p>\n<p>Veld <code>resources.requested<\/code> uit de specificatie van de Pod \u2014 een van de elementen die worden gebruikt om de juiste node te vinden. Hierop kan de uitrol van de Pod worden gepland. Hoe vindt men de geschikte node?<\/p>\n<p>Kubernetes bestaat uit verschillende componenten, waaronder een hoofd node of master-node (Kubernetes Control Plane). In de master-node draaien verschillende processen: kube-apiserver, kube-controller-manager en kube-scheduler. <\/p>\n<p>Het kube-scheduler proces is verantwoordelijk voor het bekijken van nieuw gemaakte modules en het zoeken naar mogelijke werk-nodes die voldoen aan alle aanvragen van de modules, inclusief het aantal aangevraagde resources. De lijst van nodes die door kube-scheduler zijn gevonden, wordt gerangschikt. De Pod wordt gepland op de node met de hoogste score.<\/p>\n<p><img decoding=\"async\" alt=\"Hoe toegang te krijgen tot de resources van Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/b489991a3cbbd5359c99701886d488e5.jpg\" style=\"display:block;margin: 0 auto;\" \/>Waar wordt de paarse Pod geplaatst?<\/p>\n<p>Op de afbeelding is te zien dat de kube-scheduler een nieuwe paarse Pod moet inplannen. De Kubernetes-cluster bevat twee knooppunten: A en B. Zoals te zien is, kan de kube-scheduler de Pod niet op knooppunt A inplannen - de beschikbare (niet aangevraagde) middelen komen niet overeen met de vereisten van de paarse Pod. De door de paarse Pod aangevraagde 1 GB geheugen past niet op knooppunt A, omdat er slechts 0,5 GB beschikbaar is. Maar knooppunt B heeft voldoende middelen. Uiteindelijk besluit de kube-scheduler dat de bestemming van de paarse Pod knooppunt B is.<\/p>\n<p>Nu weten we hoe de aangevraagde middelen van invloed zijn op de keuze van een knooppunt voor het starten van een Pod. Maar hoe zijn de limieten van invloed?<\/p>\n<p>Limieten van middelen zijn de grenzen die CPU\/MEM niet mogen overschrijden. Echter, CPU-middelen zijn flexibel, dus containers die de limiet van CPU bereiken, zullen niet leiden tot het afsluiten van de Pod. In plaats daarvan vindt er CPU-throttling plaats. Als de limiet voor het gebruik van MEM wordt bereikt, wordt de container gestopt door OOM-Killer en opnieuw opgestart als dit is toegestaan door de RestartPolicy-instelling.<\/p>\n<h2>Aangevraagde en limietmiddelen in detail<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Hoe toegang te krijgen tot de resources van Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/22e672100940e8895ae42a56a681111f.jpg\" style=\"display:block;margin: 0 auto;\" \/>De relatie tussen middelen in Docker en Kubernetes<\/p>\n<p>De beste manier om uit te leggen hoe aangevraagde en limieten middelen werken, is door de relatie tussen Kubernetes en Docker voor te stellen. In de afbeelding hierboven kun je zien hoe de velden van Kubernetes en de opstartvlaggen van Docker met elkaar verbonden zijn.<\/p>\n<h2>Geheugen: aanvraag en limiet<\/h2>\n<p><\/p>\n<pre><code class=\"plaintext\">containers:\n...\n resources:\n   requests:\n     memory: \"0.5Gi\"\n   limits:\n     memory: \"1Gi\"\n<\/code><\/pre>\n<p>\nZoals hierboven vermeld, wordt geheugen gemeten in bytes. Gebaseerd op <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-resources-containers\/#meaning-of-memory\">de Kubernetes-documentatie<\/a><\/noindex>, kunnen we geheugen opgeven als een getal. Gewoonlijk is het een geheel getal, zoals 2678 \u2013 dat is 2678 bytes. Je kunt ook suffixen gebruiken <code>G<\/code> en <code>Gi<\/code>, belangrijk is om te onthouden dat ze niet gelijkwaardig zijn. De eerste is decimaal, de tweede is binair. Bijvoorbeeld, genoemd in de k8s-documentatie: <code>128974848<\/code>, <code>129e6<\/code>, <code>129M<\/code>, <code>123Mi<\/code> \u2013 ze zijn praktisch gelijkwaardig.<\/p>\n<p>De Kubernetes-parameter <code>limits.memory<\/code> komt overeen met de vlag <code>--memory<\/code> uit Docker. In het geval van <code>request.memory<\/code> is de pijl voor Docker niet aanwezig, omdat Docker dit veld niet gebruikt. Je zou je kunnen afvragen of dit \u00fcberhaupt nodig is? Ja, dat is het. Zoals ik al zei, het veld is belangrijk voor Kubernetes. Op basis van de informatie hierin beslist de kube-scheduler op welk knooppunt de Pod moet worden ingepland.<\/p>\n<p><strong>Wat gebeurt er als je niet genoeg geheugen voor de aanvraag instelt?<\/strong><\/p>\n<p>Als de container de grenzen van het aangevraagde geheugen bereikt, wordt de Pod in een groep Pods geplaatst die worden gestopt bij gebrek aan geheugen op het knooppunt.<\/p>\n<p><strong>Wat gebeurt er als ik een te lage geheugengrens instel?<\/strong><\/p>\n<p>Als de container de geheugengrens overschrijdt, wordt deze be\u00ebindigd wegens OOM-Killed. En deze zal opnieuw worden opgestart, indien mogelijk op basis van RestartPolicy, waarbij de standaardwaarde is - <code>Altijd<\/code>.<\/p>\n<p><strong>Wat gebeurt er als er geen gevraagde geheugenwaarde wordt opgegeven?<\/strong><\/p>\n<p>Kubernetes neemt de geheugengrens en stelt deze in als standaardwaarde.<\/p>\n<p><strong>Wat kan er gebeuren als de geheugengrens niet wordt opgegeven?<\/strong><\/p>\n<p>De container heeft geen beperkingen, hij kan zoveel geheugen gebruiken als hij wil. Als hij echter alle beschikbare geheugen op de node begint te gebruiken, wordt hij door OOM be\u00ebindigd. Daarna zal de container opnieuw worden opgestart, indien mogelijk op basis van de RestartPolicy.<\/p>\n<p><strong>Wat gebeurt er als er geen geheugenlimieten worden opgegeven?<\/strong><\/p>\n<p>Dit is het slechtste scenario: de planner weet niet hoeveel middelen de container nodig heeft, en dit kan ernstige problemen op de node veroorzaken. In dit geval is het goed om standaardlimieten in de namespace te hebben (geconfigureerd met LimitRange). Er zijn geen standaardlimieten - de Pod heeft geen beperkingen, hij kan zoveel geheugen gebruiken als hij wil.<\/p>\n<p>Als het gevraagde geheugen groter is dan de node kan bieden, zal de Pod niet worden gepland. Het is belangrijk om te onthouden dat <code>Requests.memory<\/code> geen minimumwaarde is. Dit beschrijft de hoeveelheid geheugen die nodig is voor een continue werking van de container. <\/p>\n<p>Over het algemeen wordt aanbevolen om dezelfde waarde in te stellen voor <code>request.memory<\/code> en <code>limit.memory<\/code>. Hierdoor zal Kubernetes de Pod niet plannen op een node die voldoende geheugen heeft om de Pod te draaien, maar niet genoeg om deze daadwerkelijk te kunnen uitvoeren. Houd in gedachten: bij het plannen van de Pod houdt Kubernetes alleen rekening met <code>requests.memory<\/code>, met behulp van 1 bit, gelijk aan 0, <code>limits.memory<\/code> wordt niet meegerekend.<\/p>\n<h2>CPU: verzoek en limiet<\/h2>\n<p><\/p>\n<pre><code class=\"plaintext\">containers:\n...\n resources:\n   requests:\n     cpu: 1\n   limits:\n     cpu: \"1200m\"\n<\/code><\/pre>\n<p>\nMet CPU is het iets complexer. Terugkijkend naar de afbeelding van de relatie tussen Kubernetes en Docker, kan men opmerken dat <code>request.cpu<\/code> overeenkomt met <code>--cpu-shares<\/code>, terwijl <code>limit.cpu<\/code> komt overeen met de vlag <code>cpus<\/code> in Docker.<\/p>\n<p>De CPU die Kubernetes aanvraagt, wordt vermenigvuldigd met 1024 - de verhouding van CPU-cycli. Als je 1 volledige kern wilt aanvragen, moet je toevoegen <code>cpu: 1<\/code>, zoals hierboven getoond. <\/p>\n<p>Een verzoek om een volledige kern (verhouding = 1024) betekent niet dat uw container deze zal krijgen. Als uw hostcomputer slechts \u00e9\u00e9n kern heeft en u meer dan \u00e9\u00e9n container gebruikt, moeten alle containers de beschikbare CPU gezamenlijk gebruiken. Hoe gebeurt dit? Laten we naar de afbeelding kijken.<\/p>\n<p><img decoding=\"async\" alt=\"Hoe toegang te krijgen tot de resources van Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/7f4b20642708ef3a7e773d7900161267.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nCPU-aanroep - systeem met \u00e9\u00e9n kern<\/p>\n<p>Stel je voor dat je een host-systeem hebt met \u00e9\u00e9n kern waarop containers draaien. Moeder (Kubernetes) heeft een taart (CPU) gebakken en wil deze delen tussen de kinderen (containers). Drie kinderen willen elk een hele taart (verhouding = 1024), terwijl een ander kind de helft van de taart wil (512). Moeder wil eerlijk zijn en maakt een eenvoudige berekening.<\/p>\n<pre><code class=\"plaintext\"># \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u043e\u0432 \u0445\u043e\u0442\u044f\u0442 \u0434\u0435\u0442\u0438?\n# 3 \u0440\u0435\u0431\u0435\u043d\u043a\u0430 \u0445\u043e\u0442\u044f\u0442 \u043f\u043e \u0446\u0435\u043b\u043e\u043c\u0443 \u043f\u0438\u0440\u043e\u0433\u0443 \u0438 \u0435\u0449\u0435 \u043e\u0434\u0438\u043d \u0445\u043e\u0447\u0435\u0442 \u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0443 \u043f\u0438\u0440\u043e\u0433\u0430\ncakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5\n# \u0412\u044b\u0440\u0430\u0436\u0435\u043d\u0438\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f \u0442\u0430\u043a:\n3 (\u0440\u0435\u0431\u0435\u043d\u043a\u0430\/\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430) * 1 (\u0446\u0435\u043b\u044b\u0439 \u043f\u0438\u0440\u043e\u0433\/\u043f\u043e\u043b\u043d\u043e\u0435 \u044f\u0434\u0440\u043e) + 1 (\u0440\u0435\u0431\u0435\u043d\u043e\u043a\/\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440) * 0.5 (\u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0430 \u043f\u0438\u0440\u043e\u0433\u0430\/\u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0430 \u044f\u0434\u0440\u0430)\n# \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u043e\u0432 \u0438\u0441\u043f\u0435\u0447\u0435\u043d\u043e?\navailableCakesNumber = 1\n# \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u0430 (\u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e) \u0434\u0435\u0442\u0438 \u0440\u0435\u0430\u043b\u044c\u043d\u043e \u043c\u043e\u0433\u0443\u0442 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c?\nnewMaxRequest = 1 \/ 3.5 =~ 28%<\/code><\/pre>\n<p>\nOp basis van de berekening krijgen de drie kinderen elk 28% van de kern, en niet de hele kern. Het vierde kind krijgt 14% van de volledige kern en niet de helft. Maar het zal anders zijn als je een meerkernig systeem hebt.<\/p>\n<p><img decoding=\"async\" alt=\"Hoe toegang te krijgen tot de resources van Kubernetes Pod\" src=\"\/wp-content\/uploads\/2020\/09\/7bf71d97add9adcf7cf0260941526590.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nCPU-aanroep - meerkernig (4) systeem<\/p>\n<p>In de afbeelding hierboven kunnen we zien dat drie kinderen een hele taart willen en \u00e9\u00e9n de helft. Aangezien moeder vier taarten heeft gebakken, krijgt elk van haar kinderen zoveel als ze willen. In een meerkernig systeem zijn de processorresources verdeeld over alle beschikbare kernen. Als de container is beperkt tot minder dan \u00e9\u00e9n volledige CPU-kern, kan deze nog steeds 100% ervan gebruiken. <\/p>\n<p>De bovenstaande berekeningen zijn vereenvoudigd om te begrijpen hoe CPU wordt verdeeld tussen containers. Natuurlijk zijn er naast de containers ook andere processen die CPU-resources gebruiken. Wanneer processen in \u00e9\u00e9n container inactief zijn, kunnen andere zijn resources gebruiken. <code>CPU: \"200m\"<\/code> overeenkomt met <code>CPU: 0,2<\/code>, wat ongeveer 20% van \u00e9\u00e9n kern betekent.<\/p>\n<p>Laten we nu praten over <code>limit.cpu<\/code>. De CPU die Kubernetes beperkt, wordt vermenigvuldigd met 100. Het resultaat is de hoeveelheid tijd die de container elke 100 \u00b5s kan gebruiken (<code>cpu-period<\/code>). <\/p>\n<p><code>limit.cpu<\/code> komt overeen met de Docker-vlag <code>--cpus<\/code>. Dit is een nieuwe combinatie van oude <code>--cpu-period<\/code> en <code>--cpu-quota<\/code>. Door deze in te stellen, geven we aan hoeveel beschikbare CPU-resources de container maximaal kan gebruiken voordat throttling begint:<\/p>\n<ul>\n<li><strong>cpus<\/strong> \u2014 combinatie <code>cpu-period<\/code> en <code>cpu-quota. cpus = 1.5<\/code> is gelijk aan het instellen van <code>cpu-period = 100000<\/code> en <code>cpu-quota = 150000<\/code>;<\/li>\n<li><strong>cpu-period<\/strong> \u2014 periode <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Completely_Fair_Scheduler\">CPU CFS-scheduler<\/a><\/noindex>, standaard 100 microseconden;<\/li>\n<li><strong>cpu-quota<\/strong> \u2014 het aantal microseconden binnen <code>cpu-period<\/code>, waarmee de container is beperkt.<\/li>\n<\/ul>\n<p>\n<strong>Wat gebeurt er als je te weinig gevraagde CPU instelt?<\/strong><\/p>\n<p>Als de container meer nodig heeft dan is ingesteld, zal het CPU van andere processen afpakken.<\/p>\n<p><strong>Wat gebeurt er als je een onvoldoende CPU-limiet instelt?<\/strong><\/p>\n<p>Omdat CPU een regelbare hulpbron is, zal throttling in werking treden.<\/p>\n<p><strong>Wat gebeurt er als je geen CPU-aanroep opgeeft?<\/strong><\/p>\n<p>Net als bij geheugen geldt dat de aanvraag gelijk is aan de limiet.<\/p>\n<p><strong>Wat gebeurt er als je geen CPU-limiet opgeeft?<\/strong><\/p>\n<p>De container zal zoveel CPU gebruiken als het nodig heeft. Als in de naamruimte een standaard CPU-beleid (LimitRange) is gedefinieerd, wordt deze limiet ook voor de container gebruikt.<\/p>\n<p><strong>Wat gebeurt er als er noch een aanvraag, noch een limiet voor de CPU wordt opgegeven?<\/strong><\/p>\n<p>Net als bij geheugen is dit het slechtste scenario. De scheduler weet niet hoeveel middelen je container nodig heeft, wat ernstige problemen op de node kan veroorzaken. Om dit te voorkomen, moeten er standaardlimieten voor naamruimten (LimitRange) worden ingesteld.<\/p>\n<p>Vergeet niet: als je meer CPU aanvraagt dan de nodes kunnen bieden, zal de Pod niet worden gepland. <code>Requests.cpu<\/code> \u2014 dit is geen minimumwaarde, maar een waarde die voldoende is om de Pod te starten en zonder uitval te laten functioneren. Als de applicatie geen complexe berekeningen uitvoert, is het beste om <code>request.cpu &lt;= 1<\/code> en zoveel replica's te draaien als nodig is.<\/p>\n<h2>De ideale hoeveelheid gevraagde of gelimiteerde middelen<\/h2>\n<p>\nWe hebben geleerd over het beperken van rekenkundige middelen. Nu is het tijd om de vraag te beantwoorden: \"Hoeveel middelen heeft mijn Pod nodig om de applicatie zonder problemen uit te voeren? Wat is de ideale hoeveelheid?\". <\/p>\n<p>Helaas zijn er geen eenduidige antwoorden op deze vragen. Als je niet weet hoe je applicatie werkt, hoeveel CPU of geheugen het nodig heeft, is het beste om de applicatie veel geheugen en CPU te geven en vervolgens prestatietests uit te voeren.<\/p>\n<p>Naast prestatietests, let een week lang op het gedrag van de applicatie in de monitoring. Als uit de grafieken blijkt dat je applicatie minder middelen verbruikt dan je hebt aangevraagd, kun je de hoeveelheid gevraagde CPU of geheugen verlagen.<\/p>\n<p>Ter illustratie, kijk naar dit <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/grafana\/dashboards\/7187\">Grafana-dashboard<\/a><\/noindex>. Het toont het verschil tussen de gevraagde middelen of de limiet van middelen en het huidige gebruik van middelen.<\/p>\n<h2>Conclusie<\/h2>\n<p>\nResource requests and limits help maintain the functioning of a Kubernetes cluster. Properly configuring limits minimizes costs and keeps applications running consistently.<\/p>\n<p>In short, keep several points in mind:<\/p>\n<ol>\n<li>Requested resources are the configuration considered during startup (when Kubernetes plans the placement of the application). In contrast, resource limits are crucial during operation\u2014when the application is already running on a node.<\/li>\n<li>Compared to memory, CPU is a manageable resource. In case of CPU shortage, your Pod will not terminate; throttling will kick in.<\/li>\n<li>Requested resources and resource limits are not minimum and maximum values! By defining requested resources, you ensure that the application will run smoothly.<\/li>\n<li>A good practice is to set the memory request equal to the memory limit.<\/li>\n<li>It's good to set the requested <code>CPU &lt;=1<\/code>, if the application does not perform complex calculations.<\/li>\n<li>If you request more resources than are available on the node, the Pod will never be scheduled on that node.<\/li>\n<li>To determine the correct amount of requested resources\/limits, use load testing and monitoring.<\/li>\n<\/ol>\n<p>\nI hope this article helps you understand the core concept of resource limits. And you can apply this knowledge in your work.<\/p>\n<p>Veel succes!<\/p>\n<p><strong>Wat verder te lezen:<\/strong><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/500504\/\">SRE Observability: namespaces and metric structure<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/blog\/poleznye-instrumenty-dlya-kubernetes\">90+ nuttige tools voor Kubernetes: implementatie, beheer, monitoring, beveiliging en meer<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tele.click\/k8s_mail\">Onze kanaal Rondom Kubernetes op Telegram<\/a><\/noindex>.<\/li>\n<\/ol>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/516014\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>The Reward by Tohad \u0412 \u043d\u0430\u0447\u0430\u043b\u0435 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 Kubernetes \u043e\u0431\u044b\u0447\u043d\u043e \u0437\u0430\u0431\u044b\u0432\u0430\u044e\u0442 \u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0435 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432. \u041d\u0430 \u044d\u0442\u043e\u043c \u044d\u0442\u0430\u043f\u0435 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u043e\u0431\u0440\u0430\u0437 Docker \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0438 \u0435\u0433\u043e \u043c\u043e\u0436\u043d\u043e \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u041d\u043e \u043f\u043e\u0437\u0434\u043d\u0435\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u043c\u0438. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u043d\u0443\u0436\u043d\u043e \u0432\u044b\u0434\u0435\u043b\u0438\u0442\u044c \u0440\u0435\u0441\u0443\u0440\u0441\u044b \u0434\u043b\u044f \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 \u0438 \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94263,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94262","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=\"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\/kak-poluchit-dostup-k-resursam-kubernetes-pod\" \/>\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\udd47\u041a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u043c Kubernetes Pod | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod\" \/>\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-09-14T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-09-14T17:42:34+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\udd47How to access Kubernetes Pod resources | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","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\udd47\u041a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u043c Kubernetes Pod | ProHoster","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","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-09-14T17:42:34+00:00","article:modified_time":"2020-09-14T17:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94262","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 11:30:27","updated":"2022-10-02 18:20:09","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\/94262","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=94262"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/94262\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/94263"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=94262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=94262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=94262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}