{"id":56259,"date":"2020-02-08T00:00:00","date_gmt":"2020-02-07T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih"},"modified":"2020-02-18T14:04:30","modified_gmt":"2020-02-18T11:04:30","slug":"rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"Kubernetes-Knoten: viele kleine oder wenige gro\u00dfe?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-Knoten:
\nBei der Erstellung eines Kubernetes-Clusters k\u00f6nnen Fragen auftreten: Wie viele Arbeitsknoten sollten eingerichtet werden und welchen Typ? Was ist besser f\u00fcr ein On-Premise-Cluster: einige leistungsstarke Server kaufen oder ein Dutzend \u00e4lterer Maschinen in Ihrem Rechenzentrum nutzen? Und in der Cloud, sollte man acht Einzelkern- oder zwei Quad-Core-Instanzen w\u00e4hlen? <\/p>\n

Die Antworten auf diese Fragen finden Sie im Artikel von Daniel Weibler, Software-Ingenieur und Lehrer des Ausbildungsprojekts Learnk8s<\/a><\/noindex> in der \u00dcbersetzung des Teams Kubernetes aaS von Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Die Kapazit\u00e4t des Clusters<\/h2>\n

\nInsgesamt kann ein Kubernetes-Cluster als gro\u00dfer \"Superknoten\" betrachtet werden. Die gesamte Rechenleistung ist die Summe der Kapazit\u00e4ten aller beteiligten Knoten. <\/p>\n

Es gibt mehrere M\u00f6glichkeiten, die gew\u00fcnschte Kapazit\u00e4t des Clusters zu erreichen. Zum Beispiel ben\u00f6tigen wir einen Cluster mit einer Gesamtkapazit\u00e4t von 8 Prozessorkernen und 32 GB RAM, da der Satz an Anwendungen so viele Ressourcen ben\u00f6tigt. Dann k\u00f6nnte man zwei Knoten mit 16 GB RAM oder vier Knoten mit 8 GB RAM installieren, zwei Quad-Core-Prozessoren oder vier Dual-Core-Prozessoren.<\/p>\n

Hier sind nur zwei m\u00f6gliche M\u00f6glichkeiten, einen Cluster zu erstellen:<\/p>\n

\"Kubernetes-Knoten:
\nBeide Optionen bieten einen Cluster mit der gleichen Kapazit\u00e4t, aber in der Konfiguration unten gibt es vier kleinere Knoten, w\u00e4hrend in der Konfiguration oben zwei gr\u00f6\u00dfere Knoten stehen. <\/p>\n

Welche Option ist besser?<\/h3>\n

\nUm diese Frage zu beantworten, betrachten wir die Vorteile beider Optionen. Wir haben sie in einer Tabelle zusammengefasst.<\/p>\n

Einige gro\u00dfe Knoten<\/p>\n

Viele kleine Knoten<\/p>\n

Einfache Verwaltung des Clusters (wenn On-Premise)<\/p>\n

Reibungslose Automatisierung der Skalierung<\/p>\n

Kosteng\u00fcnstiger (wenn On-Premise) <\/p>\n

Die Preise unterscheiden sich kaum (in der Cloud) <\/p>\n

Ressourcenintensive Anwendungen k\u00f6nnen ausgef\u00fchrt werden <\/p>\n

Vollwertige Replikation<\/p>\n

Ressourcen werden effizienter genutzt (weniger Overhead f\u00fcr System-Daemons)
\nH\u00f6here Fehlertoleranz des Clusters<\/p>\n

Bitte beachten Sie, dass wir hier nur \u00fcber Arbeitsknoten sprechen. Die Wahl der Anzahl und Gr\u00f6\u00dfe der Master-Knoten ist ein ganz anderes Thema.<\/p>\n

Lassen Sie uns also jeden Punkt aus der Tabelle n\u00e4her betrachten.<\/p>\n

Erste Option: mehrere gro\u00dfe Knoten<\/h2>\n

\nDie extremste Variante ist ein einzelner Arbeitsknoten f\u00fcr die gesamte Cluster-Kapazit\u00e4t. In dem obigen Beispiel w\u00fcrde dies ein Arbeitsknoten mit 16 CPU-Kernen und 16 GB RAM sein.<\/p>\n

Vorteile <\/h3>\n

\nVorteil Nr. 1. Einfachere Verwaltung<\/b>
\nEs ist einfacher, mehrere Maschinen zu verwalten als einen ganzen Park. Updates und Fixes schneller anzuwenden und die Synchronisierung ist einfacher. Auch die Anzahl der Ausf\u00e4lle in absoluten Zahlen ist geringer.<\/p>\n

Bitte beachten Sie, dass alles, was bisher gesagt wurde, f\u00fcr eigene Hardware und Server gilt, nicht f\u00fcr Cloud-Instanzen.<\/p><\/blockquote>\n

\nIn der Cloud ist die Situation anders. Dort ist der Cloud-Anbieter f\u00fcr die Verwaltung verantwortlich. Somit unterscheidet sich die Verwaltung von zehn Knoten in der Cloud nicht wesentlich von der Verwaltung eines einzelnen Knotens.<\/p>\n

Die Traffic-Routing und Lastverteilung zwischen Pods in der Cloud erfolgt automatisch<\/a><\/noindex>: Der aus dem Internet kommende Traffic wird an den Hauptlastenausgleichsanschluss geleitet, der den Traffic an den Port eines der Knoten weiterleitet (der Service NodePort gibt einen Port im Bereich von 30000-32767 in jedem Knoten des Clusters frei). Die von kube-proxy festgelegten Regeln leiten den Traffic vom Knoten an den Pod weiter. So sieht das f\u00fcr zehn Pods auf zwei Knoten aus:<\/p>\n

\"Kubernetes-Knoten:
\nPlus Nummer 2. Niedrigere Kosten pro Knoten<\/b>
\nEin leistungsstarker Server ist teurer, aber der Preisanstieg ist nicht unbedingt linear. Mit anderen Worten, ein zehnkerniger Server mit 10 GB RAM ist in der Regel g\u00fcnstiger als zehn einst\u00fcckige Server mit der gleichen Menge an RAM.<\/p>\n

Bitte beachten Sie jedoch, dass diese Regel in der Regel nicht f\u00fcr Cloud-Dienste gilt. In den aktuellen Preismodellen aller gro\u00dfen Cloud-Anbieter steigen die Preise linear mit der Erh\u00f6hung der Kapazit\u00e4t.<\/p><\/blockquote>\n

\nSomit l\u00e4sst sich in der Cloud normalerweise nicht bei leistungsstarken Servern sparen.<\/p>\n

Plus Nummer 3. Ressourcenintensive Anwendungen k\u00f6nnen betrieben werden<\/b>
\nEinige Anwendungen ben\u00f6tigen leistungsstarke Server im Cluster. Zum Beispiel, wenn ein maschinelles Lernsystem 8 GB RAM ben\u00f6tigt, k\u00f6nnen Sie es nicht auf Knoten mit 1 GB starten, sondern nur, wenn mindestens ein gro\u00dfer Arbeitsknoten vorhanden ist.<\/p>\n

Nachteile <\/h3>\n

\nNachteil Nr. 1. Viele Pods auf einem Knoten<\/b>
\nWenn dieselbe Aufgabe mit weniger Knoten ausgef\u00fchrt wird, werden auf jedem von ihnen selbstverst\u00e4ndlich mehr Pods vorhanden sein.<\/p>\n

Das k\u00f6nnte zum Problem werden.<\/p>\n

Der Grund daf\u00fcr ist, dass jedes Modul einige Overheadkosten f\u00fcr die Container-Laufzeitumgebung (zum Beispiel Docker) sowie f\u00fcr kubelet und cAdvisor verursacht.<\/p>\n

Zum Beispiel \u00fcberpr\u00fcft kubelet regelm\u00e4\u00dfig die Lebensf\u00e4higkeit aller Container auf dem Knoten \u2013 je mehr Container, desto mehr Arbeit hat kubelet.<\/p>\n

CAdvisor sammelt Statistiken \u00fcber die Ressourcennutzung aller Container auf einem Knoten, w\u00e4hrend kubelet regelm\u00e4\u00dfig diese Informationen abruft und sie \u00fcber die API bereitstellt. Je mehr Container vorhanden sind, desto mehr Arbeit gibt es sowohl f\u00fcr cAdvisor als auch f\u00fcr kubelet.<\/p>\n

Wenn die Anzahl der Module steigt, kann dies das System verlangsamen und sogar dessen Zuverl\u00e4ssigkeit gef\u00e4hrden.<\/p>\n

\"Kubernetes-Knoten:
\nIm Kubernetes-Repository haben einige beschwert<\/a><\/noindex>, dass die Knoten zwischen den Status Ready\/NotReady springen, da die regelm\u00e4\u00dfigen Pr\u00fcfungen von kubelet f\u00fcr alle Container auf dem Knoten zu viel Zeit in Anspruch nehmen.
\nAus diesem Grund Es wird empfohlen, nicht mehr als 110 Pods auf einem Knoten zu platzieren.<\/a><\/noindex>. Je nach Leistung des Knotens k\u00f6nnen Sie mehr Pods pro Knoten betreiben, aber es ist schwer vorherzusagen, ob Probleme auftreten oder ob alles reibungslos funktioniert. Es ist ratsam, die Funktion im Voraus zu testen. <\/p>\n

Nachteil Nr. 2. Einschr\u00e4nkung bei der Replikation<\/b>
\nEine zu geringe Anzahl von Knoten schr\u00e4nkt den effektiven Replikationsgrad von Anwendungen ein. Wenn Sie beispielsweise eine Hochverf\u00fcgbarkeitsanwendung mit f\u00fcnf Replikaten haben, aber nur zwei Knoten verf\u00fcgbar sind, reduziert sich der effektive Replikationsgrad der Anwendung auf zwei.<\/p>\n

F\u00fcnf Replikate k\u00f6nnen nur auf zwei Knoten verteilt werden, und wenn einer von ihnen ausf\u00e4llt, fallen sofort mehrere Replikate aus.<\/p>\n

Wenn Sie f\u00fcnf oder mehr Knoten haben, wird jede Replik auf einem separaten Knoten ausgef\u00fchrt, und der Ausfall eines Knotens hat h\u00f6chstens Auswirkungen auf eine Replik.<\/p>\n

Daraus folgt, dass die Anforderungen an die Hochverf\u00fcgbarkeit eine bestimmte Mindestanzahl von Knoten im Cluster erfordern k\u00f6nnen.<\/p>\n

Nachteil Nr. 3. Schwerwiegendere Folgen eines Ausfalls<\/b>
\nBei einer geringen Anzahl von Knoten hat jeder Ausfall schwerwiegendere Auswirkungen. Wenn Sie beispielsweise nur zwei Knoten haben und einer davon ausf\u00e4llt, verschwindet sofort die H\u00e4lfte Ihrer Module.<\/p>\n

Nat\u00fcrlich wird Kubernetes die Arbeitslast von dem ausgefallenen Knoten auf andere verschieben. Aber wenn es nur wenige gibt, k\u00f6nnte der verf\u00fcgbare Platz nicht ausreichen. Infolgedessen werden einige Ihrer Anwendungen nicht verf\u00fcgbar sein, bis Sie den ausgefallenen Knoten wiederhergestellt haben.<\/p>\n

Je mehr Knoten vorhanden sind, desto weniger Einfluss haben Hardwareausf\u00e4lle.<\/p>\n

Nachteil Nr. 4. Gr\u00f6\u00dfere Schritte beim automatischen Skalieren<\/b>
\nIn Kubernetes gibt es ein System zur automatischen Skalierung von Clustern f\u00fcr Cloud-Infrastrukturen, das es erm\u00f6glicht, Knoten je nach aktuellen Bed\u00fcrfnissen automatisch hinzuzuf\u00fcgen oder zu entfernen. Mit gr\u00f6\u00dferen Knoten wird die automatisierte Skalierung jedoch drastischer und ungeschickter. Wenn Sie beispielsweise zwei Knoten haben, erh\u00f6ht das Hinzuf\u00fcgen eines zus\u00e4tzlichen Knotens die Kapazit\u00e4t des Clusters sofort um 50%. Sie m\u00fcssen jedoch auch f\u00fcr diese Ressourcen bezahlen, selbst wenn Sie sie nicht ben\u00f6tigen.<\/p>\n

Wenn Sie also planen, die automatische Skalierung des Clusters zu nutzen, gilt: Je kleiner die Knoten, desto flexibler und kosteneffizienter wird die Skalierung.<\/p>\n

Schauen wir uns nun die Vor- und Nachteile einer gro\u00dfen Anzahl kleiner Knoten an.<\/p>\n

Zweite Option: Viele kleine Knoten<\/h2>\n

\nDie Vorteile dieses Ansatzes ergeben sich im Wesentlichen aus den Nachteilen der gegenteiligen Variante mit wenigen gro\u00dfen Knoten.<\/p>\n

Vorteile<\/h3>\n

\nPlus Punkt Nr. 1. Geringere Auswirkungen bei Ausf\u00e4llen<\/b>
\nJe mehr Knoten vorhanden sind, desto weniger Pods sind auf jedem Knoten. Wenn Sie beispielsweise hundert Module auf zehn Knoten haben, haben Sie im Durchschnitt zehn Module auf jedem Knoten.<\/p>\n

Wenn also einer der Knoten ausf\u00e4llt, verlieren Sie lediglich 10% der Arbeitslast. Es ist wahrscheinlich, dass nur eine geringe Anzahl von Replikaten betroffen ist, w\u00e4hrend die Anwendungen insgesamt weiterhin funktionsf\u00e4hig bleiben.<\/p>\n

Dar\u00fcber hinaus werden auf den verbleibenden Knoten wahrscheinlich gen\u00fcgend Ressourcen f\u00fcr die Arbeitslast des ausgefallenen Knotens vorhanden sein, sodass Kubernetes die Pods problemlos umplanen kann und Ihre Anwendungen relativ schnell wieder betriebsbereit sind.<\/p>\n

Plus Punkt Nr. 2. Gute Replikation<\/b>
\nWenn gen\u00fcgend Knoten vorhanden sind, kann der Kubernetes-Planer jedem Replikat unterschiedliche Knoten zuweisen. Dadurch wird im Falle eines Knotenfehlers nur eine Replikat betroffen sein, w\u00e4hrend die Anwendung weiterhin verf\u00fcgbar bleibt.<\/p>\n

Nachteile <\/h3>\n

\nMinus Punkt Nr. 1. Schwierigeres Management<\/b>
\nEine gr\u00f6\u00dfere Anzahl von Knoten ist schwieriger zu verwalten. Jeder Kubernetes-Knoten muss beispielsweise mit allen anderen Knoten interagieren, sodass die Anzahl der Verbindungen quadratisch w\u00e4chst, und all diese Verbindungen m\u00fcssen \u00fcberwacht werden.<\/p>\n

Der Knotencontroller im Kubernetes-Controller-Manager \u00fcberpr\u00fcft regelm\u00e4\u00dfig alle Knoten im Cluster auf ihre Funktionsf\u00e4higkeit - je mehr Knoten vorhanden sind, desto h\u00f6her ist die Belastung f\u00fcr den Controller.<\/p>\n

Die Belastung f\u00fcr die Datenbank etcd steigt ebenfalls - jeder Kubelet und Kube-Proxy ruft watcher<\/a><\/noindex> f\u00fcr etcd (\u00fcber die API), an die etcd Updates von Objekten \u00fcbertragen muss.<\/p>\n

Im Allgemeinen verursacht jeder Arbeitsknoten zus\u00e4tzliche Belastungen f\u00fcr die Systemkomponenten der Masterknoten.<\/p>\n

\"Kubernetes-Knoten:
\nOffiziell unterst\u00fctzt Kubernetes Cluster mit bis zu 5000 Knoten.<\/a><\/noindex>In der Praxis k\u00f6nnen jedoch bereits 500 Knoten nicht triviale Probleme verursachen.<\/a><\/noindex>.<\/p>\n

Um eine gro\u00dfe Anzahl von Arbeitsknoten zu verwalten, sollten leistungsf\u00e4higere Masterknoten ausgew\u00e4hlt werden. Zum Beispiel installiert kube-up automatisch<\/a><\/noindex> die passende VM-Gr\u00f6\u00dfe f\u00fcr den Masterknoten abh\u00e4ngig von der Anzahl der Arbeitsknoten. Das bedeutet, je mehr Arbeitsknoten, desto leistungsf\u00e4higer m\u00fcssen die Masterknoten sein. <\/p>\n

Um diese spezifischen Probleme zu l\u00f6sen, gibt es spezielle Entwicklungen wie Virtual Kubelet.<\/a><\/noindex>Dieses System erm\u00f6glicht es, Einschr\u00e4nkungen zu umgehen und Cluster mit einer enormen Anzahl von Arbeitsknoten zu erstellen.<\/p>\n

Nachteil Nr. 2. H\u00f6here Overheadkosten.<\/b>
\nAuf jedem Arbeitsknoten f\u00fchrt Kubernetes eine Reihe von System-D\u00e4monen aus \u2013 dazu geh\u00f6ren die Container-Laufzeit (z. B. Docker), kube-proxy und kubelet, sowie cAdvisor. Gemeinsam verbrauchen sie eine bestimmte feste Menge an Ressourcen.<\/p>\n

Wenn Sie viele kleine Knoten haben, ist der Anteil dieser Overheadkosten auf jedem Knoten h\u00f6her. Stellen Sie sich beispielsweise vor, dass alle System-D\u00e4monen eines Knotens zusammen 0,1 CPU-Kerne und 0,1 GB Speicher verbrauchen. Wenn Sie einen zehnekernigen Knoten mit 10 GB Speicher haben, verbrauchen die D\u00e4monen 1% der Cluster-Kapazit\u00e4t. Auf der anderen Seite werden auf zehn ein Kernknoten mit je 1 GB Speicher die D\u00e4monen 10% der Cluster-Kapazit\u00e4t beanspruchen.<\/p>\n

Das bedeutet, je weniger Knoten, desto effizienter wird die Infrastruktur genutzt.<\/p>\n

Nachteil Nr. 3. Ineffiziente Ressourcennutzung.<\/b>
\nAuf kleinen Knoten kann es vorkommen, dass die verbleibenden Ressourcenausschnitte zu klein sind, um ihnen eine Arbeitslast zuzuweisen, weshalb sie ungenutzt bleiben.<\/p>\n

Beispielsweise ben\u00f6tigt jeder Pod 0,75 GB Speicher. Wenn Sie zehn Knoten haben und auf jedem 1 GB Speicher vorhanden ist, k\u00f6nnen zehn Pods gestartet werden \u2013 am Ende bleiben auf jedem Knoten 0,25 GB ungenutzter Speicher.<\/p>\n

Das bedeutet, dass 25% des Speichers des gesamten Clusters ungenutzt bleiben.<\/p>\n

Auf einem gro\u00dfen Knoten mit 10 GB Speicher k\u00f6nnen Sie 13 solcher Module starten \u2013 und es bleibt nur ein ungenutzter Abschnitt von 0,25 GB.<\/p>\n

In diesem Fall werden nur 2,5% des Speichers ungenutzt.<\/p>\n

So werden Ressourcen an gro\u00dfen Knoten optimal genutzt.<\/p>\n

Mehrere gro\u00dfe Knoten oder viele kleine?<\/h2>\n

\nWas ist also besser: mehrere gro\u00dfe Knoten im Cluster oder viele kleine? Wie immer gibt es keine eindeutige Antwort. Vieles h\u00e4ngt von der Art der Anwendung ab.<\/p>\n

Wenn eine Anwendung beispielsweise 10 GB Speicher ben\u00f6tigt, liegt die Wahl auf gro\u00dfen Knoten nahe. Wenn die Anwendung jedoch eine zehnfache Replikation f\u00fcr hohe Verf\u00fcgbarkeit erfordert, sollte man nicht riskieren, die Replikate nur auf zwei Knoten zu verteilen \u2014 im Cluster sollten mindestens zehn Knoten vorhanden sein.<\/p>\n

In Zwischensituationen treffen Sie die Wahl nach den Vor- und Nachteilen jeder Option. M\u00f6glicherweise sind einige Argumente relevanter f\u00fcr Ihre Situation als andere.<\/p>\n

Es ist nicht unbedingt erforderlich, alle Knoten in der gleichen Gr\u00f6\u00dfe zu gestalten. Nichts hindert Sie daran, zun\u00e4chst mit Knoten derselben Gr\u00f6\u00dfe zu experimentieren und dann Knoten anderer Gr\u00f6\u00dfe hinzuzuf\u00fcgen, um sie im Cluster zu kombinieren. Die Arbeitsknoten eines Kubernetes-Clusters k\u00f6nnen vollst\u00e4ndig heterogen sein. Sie k\u00f6nnen also versuchen, die Vorteile beider Ans\u00e4tze zu vereinen.<\/p>\n

Ein einzelnes Rezept existiert nicht, und jede Situation hat ihre eigenen Nuancen, die nur die Produktion zeigen wird.<\/p>\n

Die \u00dcbersetzung wurde vom Team der Cloud-Plattform vorbereitet Mail.ru Cloud Solutions<\/a><\/noindex>.<\/i><\/p>\n

Mehr \u00fcber Kubernetes: 25 n\u00fctzliche Werkzeuge zur Verwaltung und Bereitstellung von Clustern<\/a><\/noindex>.<\/p>\n

Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 Kubernetes \u043c\u043e\u0433\u0443\u0442 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441\u044b: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u0443\u0437\u043b\u043e\u0432 \u0438 \u043a\u0430\u043a\u043e\u0433\u043e \u0442\u0438\u043f\u0430? \u0427\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 on-premise: \u043a\u0443\u043f\u0438\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u043e\u0449\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438\u043b\u0438 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u0434\u0435\u0441\u044f\u0442\u043e\u043a \u0441\u0442\u0430\u0440\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0432 \u0432\u0430\u0448\u0435\u043c \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0435? \u0410 \u0432 \u043e\u0431\u043b\u0430\u043a\u0435 \u043b\u0443\u0447\u0448\u0435 \u0432\u0437\u044f\u0442\u044c \u0432\u043e\u0441\u0435\u043c\u044c \u043e\u0434\u043d\u043e\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043b\u0438 \u0434\u0432\u0430 \u0447\u0435\u0442\u044b\u0440\u0435\u0445\u044a\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043d\u0441\u0442\u0430\u043d\u0441\u0430? \u041e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u044d\u0442\u0438 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u2014 \u0432 \u0441\u0442\u0430\u0442\u044c\u0435 \u0414\u0430\u043d\u0438\u044d\u043b\u044f \u0412\u0430\u0439\u0431\u0435\u043b\u044f, \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430-\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430 \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044f \u043e\u0431\u0443\u0447\u0430\u044e\u0449\u0435\u0433\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-56259","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kubernetes-Arbeitsknoten: viele kleine oder einige gro\u00dfe? | ProHoster","description":"Beim Erstellen eines Clusters.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\u0420\u0430\u0431\u043e\u0447\u0438\u0435 \u0443\u0437\u043b\u044b Kubernetes: \u043c\u043d\u043e\u0433\u043e \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445 \u0438\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u043e\u043b\u044c\u0448\u0438\u0445? | ProHoster","og:description":"\u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","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-02-07T21:00:00+00:00","article:modified_time":"2020-02-18T11:04:30+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"56259","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 19:28:23","updated":"2022-10-03 08:08:38","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/56259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}