{"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-Arbeitsknoten: viele kleine oder einige gro\u00dfe?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-Arbeitsknoten:
\nBei der Erstellung eines Kubernetes-Clusters k\u00f6nnen Fragen aufkommen: Wie viele Arbeitsknoten sollten konfiguriert werden und welcher Typ ist am besten geeignet? Was ist f\u00fcr ein On-Premise-Cluster besser: den Kauf mehrerer leistungsstarker Server oder die Nutzung von zehn alten Maschinen in Ihrem Rechenzentrum? Und in der Cloud: besser acht Ein-Kern-Instanzen oder zwei Vier-Kern-Instanzen? <\/p>\n

Die Antworten auf diese Fragen finden Sie im Artikel von Daniel Weibel, Softwareingenieur und Dozent beim Bildungsprojekt Learnk8s<\/a><\/noindex> im \u00dcbersetzungsteam Kubernetes aaS von Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Clusterkapazit\u00e4t<\/h2>\n

\nIm Allgemeinen kann man ein Kubernetes-Cluster als gro\u00dfen \"Superknoten\" betrachten. Die gesamte Rechenleistung ist die Summe der Kapazit\u00e4ten aller einzelnen Knoten. <\/p>\n

Es gibt verschiedene M\u00f6glichkeiten, die gew\u00fcnschte Zielkapazit\u00e4t des Clusters zu erreichen. Wenn wir beispielsweise ein Cluster mit einer Gesamtkapazit\u00e4t von 8 Prozessorkernen und 32 GB RAM ben\u00f6tigen, weil die Anwendungsanforderungen dies erfordern, dann k\u00f6nnten wir 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 Ans\u00e4tze zur Erstellung eines Clusters:<\/p>\n

\"Kubernetes-Arbeitsknoten:
\nBeide Optionen bieten einen Cluster mit derselben Kapazit\u00e4t, aber in der unteren Konfiguration sind vier kleinere Knoten installiert, w\u00e4hrend in der oberen Konfiguration zwei gr\u00f6\u00dfere Knoten vorhanden sind. <\/p>\n

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

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

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

Viele kleine Knoten<\/p>\n

Einfachere Verwaltung des Clusters (wenn er lokal ist)<\/p>\n

Sanfte automatische Skalierung<\/p>\n

G\u00fcnstiger (wenn lokal) <\/p>\n

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

Ressourcenintensive Anwendungen k\u00f6nnen gestartet werden <\/p>\n

Vollst\u00e4ndige Replikation<\/p>\n

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

Bitte beachten Sie, dass wir nur \u00fcber Arbeitsknoten sprechen. Die Wahl der Anzahl und Gr\u00f6\u00dfe der Hauptknoten ist ein v\u00f6llig anderes Thema.<\/p>\n

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

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

\nDie extremste Variante w\u00e4re ein Arbeitsknoten f\u00fcr die gesamte Kapazit\u00e4t des Clusters. Im obigen Beispiel w\u00e4re das ein Arbeitsknoten mit 16 CPU-Kernen und 16 GB RAM.<\/p>\n

Vorteile <\/h3>\n

\nVorteil Nr. 1. Einfachere Verwaltung<\/b>
\nEs ist einfacher, mehrere Maschinen zu verwalten als eine ganze Flotte. Updates und Patches lassen sich schneller anwenden und die Synchronisierung ist unkomplizierter. Auch die absolute Anzahl der Ausf\u00e4lle ist geringer.<\/p>\n

Bitte beachten Sie, dass sich alles oben Gesagte auf die eigene Hardware, die eigenen Server und nicht auf Cloud-Instanzen bezieht.<\/p><\/blockquote>\n

\nIm Cloud-Umfeld ist die Situation anders. Hier \u00fcbernimmt der Cloud-Dienstleister das Management. So unterscheidet sich die Verwaltung von zehn Knoten in der Cloud nicht wesentlich von der Verwaltung eines einzelnen Knotens.<\/p>\n

Die Verkehrslenkung und Lastverteilung zwischen Pods in der Cloud erfolgt automatisch<\/a><\/noindex>: Der Verkehr, der aus dem Internet kommt, wird an den Hauptlastenausgleicher weitergeleitet, der den Verkehr an den Port eines der Knoten weiterleitet (der NodePort-Dienst legt den Port im Bereich von 30000-32767 an jedem Knoten des Clusters fest). Die von kube-proxy festgelegten Regeln leiten den Verkehr vom Knoten zum Pod um. So sieht das f\u00fcr zehn Pods auf zwei Knoten aus:<\/p>\n

\"Kubernetes-Arbeitsknoten:
\nVorteil Nr. 2. Geringere Kosten pro Knoten<\/b>
\nLeistungsstarke Server sind teurer, jedoch ist der Preisanstieg nicht unbedingt linear. Mit anderen Worten, ein Server mit 10 Kernen und 10 GB RAM ist in der Regel g\u00fcnstiger als zehn Einzelkern-Server mit der gleichen Menge an RAM.<\/p>\n

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

\nDaher l\u00e4sst sich in der Cloud in der Regel nicht durch leistungsst\u00e4rkere Server Geld sparen.<\/p>\n

Vorteil Nr. 3. Ressourcenschonende Anwendungen k\u00f6nnen gestartet werden.<\/b>
\nEinige Anwendungen ben\u00f6tigen leistungsstarke Server im Cluster. Zum Beispiel, wenn ein Machine Learning-System 8 GB RAM ben\u00f6tigt, k\u00f6nnen Sie es nicht auf Knoten mit 1 GB ausf\u00fchren, sondern nur mit mindestens einem gro\u00dfen Arbeitsknoten.<\/p>\n

Nachteile <\/h3>\n

\nMinus Nr. 1. Viele Pods pro Knoten<\/b>
\nWenn dieselbe Aufgabe auf einer geringeren Anzahl von Knoten ausgef\u00fchrt wird, wird es nat\u00fcrlich mehr Pods auf jedem von ihnen geben.<\/p>\n

Das kann problematisch werden.<\/p>\n

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

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

CAdvisor sammelt Nutzungsstatistiken aller Container auf einem Knoten, und kubelet fragt diese Informationen regelm\u00e4\u00dfig ab und stellt sie \u00fcber die API zur Verf\u00fcgung. Wiederum gilt: Je mehr Container es gibt, desto mehr Arbeit entsteht 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 beeintr\u00e4chtigen.<\/p>\n

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

Nachteil Nr. 2: Einschr\u00e4nkung bei der Replikation<\/b>
\nEine zu geringe Anzahl von Knoten schr\u00e4nkt die effektive Replikationsstufe von Anwendungen ein. Wenn Sie beispielsweise eine hochverf\u00fcgbare Anwendung mit f\u00fcnf Replikaten haben, aber nur zwei Knoten, reduziert sich die effektive Replikationsstufe der Anwendung auf zwei.<\/p>\n

F\u00fcnf Replikate k\u00f6nnen nur auf zwei Knoten verteilt werden, und wenn einer davon ausf\u00e4llt, werden sofort mehrere Replikate au\u00dfer Betrieb genommen.<\/p>\n

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

Daher k\u00f6nnen die Anforderungen an hohe Verf\u00fcgbarkeit eine bestimmte Mindestanzahl von Knoten im Cluster erforderlich machen.<\/p>\n

Nachteil Nr. 3. Schlimmere Auswirkungen eines Ausfalls<\/b>
\nBei einer geringen Anzahl von Knoten hat jeder Ausfall gravierendere Konsequenzen. Wenn Sie nur zwei Knoten haben und einer davon ausf\u00e4llt, verschwinden 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 Knoten gibt, k\u00f6nnte nicht gen\u00fcgend freie Kapazit\u00e4t vorhanden sein. Infolgedessen werden einige Ihrer Anwendungen nicht verf\u00fcgbar sein, bis Sie den ausgefallenen Knoten wiederhergestellt haben.<\/p>\n

Daher gilt: Je mehr Knoten vorhanden sind, desto geringer ist der Einfluss von Hardware-Ausf\u00e4llen.<\/p>\n

Nachteil Nr. 4. Gr\u00f6\u00dfere Schritte bei der automatischen Skalierung<\/b>
\nIn Kubernetes gibt es ein automatisches Skalierungssystem f\u00fcr die Cloud-Infrastruktur, das es erm\u00f6glicht, Knoten je nach aktuellem Bedarf automatisch hinzuzuf\u00fcgen oder zu entfernen. Bei gr\u00f6\u00dferen Knoten wird die Skalierung steiler und unbeholfener. Zum Beispiel erh\u00f6ht das Hinzuf\u00fcgen eines zus\u00e4tzlichen Knotens bei zwei Knoten die Kapazit\u00e4t des Clusters sofort um 50 %. Sie m\u00fcssen auch f\u00fcr diese Ressourcen zahlen, selbst wenn Sie sie nicht ben\u00f6tigen.<\/p>\n

Wenn Sie also planen, die automatische Skalierung des Clusters zu nutzen, ist es sinnvoll, weniger Knoten zu haben, da das Skalieren dadurch flexibler und kosteng\u00fcnstiger wird.<\/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 gegenteiliger Variante mit wenigen gro\u00dfen Knoten.<\/p>\n

Vorteile<\/h3>\n

\nVorteil Nr. 1. Geringere Auswirkungen bei einem Ausfall<\/b>
\nJe mehr Knoten, desto weniger Pods auf jedem Knoten. Zum Beispiel, wenn Sie hundert Module auf zehn Knoten haben, wird es im Durchschnitt zehn Module pro Knoten geben.<\/p>\n

Das bedeutet, wenn einer der Knoten ausf\u00e4llt, verlieren Sie nur 10 % der Arbeitslast. Es besteht die M\u00f6glichkeit, dass nur eine geringe Anzahl von Replikaten betroffen ist und die Anwendungen insgesamt weiterhin funktionieren.<\/p>\n

Zudem werden die verbleibenden Knoten wahrscheinlich gen\u00fcgend Ressourcen f\u00fcr die Arbeitslast des ausgefallenen Knotens haben, sodass Kubernetes die Pods problemlos neu planen kann und Ihre Anwendungen relativ schnell wieder funktionst\u00fcchtig sind.<\/p>\n

Vorteil Nr. 2. Gute Replikation<\/b>
\nWenn gen\u00fcgend Knoten vorhanden sind, kann der Kubernetes-Planer alle Replikate auf verschiedene Knoten verteilen. So wird im Falle eines Knotenfehlers nur eine Replik betroffen sein, und die Anwendung bleibt verf\u00fcgbar.<\/p>\n

Nachteile <\/h3>\n

\nNachteil Nr. 1. Schwieriger zu verwalten<\/b>
\nEine gro\u00dfe Anzahl von Knoten ist schwieriger zu verwalten. Zum Beispiel muss jeder Kubernetes-Knoten mit allen anderen kommunizieren, was bedeutet, dass die Anzahl der Verbindungen quadratisch w\u00e4chst, und all diese Verbindungen m\u00fcssen \u00fcberwacht werden.<\/p>\n

Der Knoten-Controller im Kubernetes-Controller-Manager \u00fcberpr\u00fcft regelm\u00e4\u00dfig die Betriebsbereitschaft aller Knoten im Cluster \u2013 je mehr Knoten, desto h\u00f6her die Last auf dem Controller.<\/p>\n

Auch die Last auf der etcd-Datenbank steigt \u2013 jeder Kubelet und Kube-Proxy ruft Watcher<\/a><\/noindex> f\u00fcr etcd (\u00fcber die API) auf, der Updates des Objekts an etcd \u00fcbertragen muss.<\/p>\n

Insgesamt belastet jeder Arbeitsknoten die Systemkomponenten der Master-Knoten zus\u00e4tzlich.<\/p>\n

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

Um eine gro\u00dfe Anzahl von Arbeitsknoten zu verwalten, sollten leistungsf\u00e4higere Master-Knoten ausgew\u00e4hlt werden. Beispielsweise installiert kube-up automatisch<\/a><\/noindex> die richtige VM-Gr\u00f6\u00dfe f\u00fcr den Master-Knoten je nach Anzahl der Arbeitsknoten. Das bedeutet, je mehr Arbeitsknoten vorhanden sind, desto leistungsst\u00e4rker m\u00fcssen die Master-Knoten sein. <\/p>\n

Um diese spezifischen Probleme zu l\u00f6sen, gibt es spezielle Entwicklungen wie Virtual Kubelet<\/a><\/noindex>. Dieses System erm\u00f6glicht es, die 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-Daemons aus \u2013 dazu geh\u00f6ren die Containerlaufzeit (zum Beispiel Docker), kube-proxy und kubelet, einschlie\u00dflich cAdvisor. Gemeinsam ben\u00f6tigen sie eine gewisse feste Menge an Ressourcen.<\/p>\n

Wenn Sie viele kleine Knoten haben, ist der Anteil dieser Overheadkosten pro Knoten h\u00f6her. Nehmen wir an, alle System-Daemons eines Knotens verbrauchen zusammen 0,1 CPU-Kerne und 0,1 GB Speicher. Wenn Sie einen zehnekernigen Knoten mit 10 GB Speicher haben, verbrauchen die Daemons 1 % der Clusterkapazit\u00e4t. Im Gegensatz dazu w\u00fcrden auf zehn einst\u00f6ckigen Knoten mit 1 GB Speicher die Daemons 10 % der Clusterkapazit\u00e4t beanspruchen.<\/p>\n

Je weniger Knoten vorhanden sind, desto effizienter wird die Infrastruktur genutzt.<\/p>\n

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

Beispielsweise ben\u00f6tigt jeder Pod 0,75 GB RAM. Wenn Sie zehn Knoten haben und jeder 1 GB RAM hat, k\u00f6nnen zehn Pods gestartet werden \u2014 sodass auf jedem Knoten am Ende 0,25 GB ungenutzter RAM verbleiben.<\/p>\n

Das bedeutet, dass 25 % des gesamten Speichers im Cluster unn\u00f6tig verschwendet werden.<\/p>\n

Auf einem gro\u00dfen Knoten mit 10 GB RAM k\u00f6nnen Sie 13 solcher Module starten \u2014 und es bleibt nur ein ungenutztes Fragment von 0,25 GB.<\/p>\n

In diesem Fall wird lediglich 2,5 % des Speichers verschwendet.<\/p>\n

So werden die Ressourcen auf gro\u00dfen Knoten effizienter genutzt.<\/p>\n

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

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

Wenn eine Anwendung beispielsweise 10 GB RAM ben\u00f6tigt, ist die Wahl gro\u00dfer Knoten offensichtlich. Wenn die Anwendung jedoch eine zehnfache Replikation f\u00fcr hohe Verf\u00fcgbarkeit erfordert, sollten Sie nicht das Risiko eingehen, die Replikate nur auf zwei Knoten zu verteilen \u2014 im Cluster sollten mindestens zehn Knoten vorhanden sein.<\/p>\n

In Zwischenf\u00e4llen treffen Sie Entscheidungen basierend auf den Vor- und Nachteilen jeder Option. Einige Argumente k\u00f6nnten relevanter f\u00fcr Ihre Situation sein als andere.<\/p>\n

Es ist nicht notwendig, alle Knoten in der gleichen Gr\u00f6\u00dfe zu haben. Nichts hindert Sie daran, zun\u00e4chst mit Knoten gleicher Gr\u00f6\u00dfe zu experimentieren und anschlie\u00dfend Knoten unterschiedlicher Gr\u00f6\u00dfe hinzuzuf\u00fcgen, um sie im Cluster zu kombinieren. Die Arbeitsknoten eines Kubernetes-Clusters k\u00f6nnen v\u00f6llig heterogen sein. Sie k\u00f6nnen also die Vorteile beider Ans\u00e4tze kombinieren.<\/p>\n

Es gibt kein universelles Rezept, da jede Situation ihre eigenen Nuancen hat, und nur die Produktionsumgebung kann die Wahrheit zeigen.<\/p>\n

Die \u00dcbersetzung wurde vom Team der Cloud-Plattform erstellt. Mail.ru Cloud L\u00f6sungen<\/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-Worker-Nodes: viele kleine oder wenige gro\u00dfe? | ProHoster","description":"Bei der Erstellung eines Kubernetes-Clusters k\u00f6nnen Fragen aufkommen: Wie viele Worker-Nodes sollten eingerichtet werden und welchen Typ? Was ist besser f\u00fcr ein On-Premise-Cluster: mehrere leistungsstarke Server zu kaufen oder ein Dutzend \u00e4lterer Maschinen in Ihrem Rechenzentrum zu nutzen? Und in der Cloud, sollten es acht Ein-Kern-Instanzen oder zwei Vier-Kern-Instanzen sein? Antworten auf diese Fragen finden Sie im Artikel von Daniel Weibel, Software-Ingenieur und Dozent.","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 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","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"},"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}]}}