{"id":82244,"date":"2020-05-20T13:42:45","date_gmt":"2020-05-20T11:42:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov"},"modified":"2020-05-20T13:42:45","modified_gmt":"2020-05-20T11:42:45","slug":"luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","title":{"rendered":"Best Practices f\u00fcr Kubernetes. Erstellung kleiner Container","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Best
\n
\nDer erste Schritt beim Bereitstellen in Kubernetes besteht darin, Ihre Anwendung in einem Container zu hosten. In dieser Reihe werden wir untersuchen, wie Sie ein kleines und sicheres Container-Image erstellen k\u00f6nnen.
\nDank Docker war es noch nie so einfach, Container-Images zu erstellen. Geben Sie das Basis-Image an, f\u00fcgen Sie Ihre \u00c4nderungen hinzu und erstellen Sie den Container.<\/p>\n

\"Best
\n
\nObwohl diese Methode ideal ist, um zu beginnen, kann die Verwendung von Standard-Basis-Images zu unsicherer Verwendung f\u00fchren, wenn gro\u00dfe Images mit Sicherheitsanf\u00e4lligkeiten gef\u00fcllt sind.<\/a><\/noindex><\/p>\n

Dar\u00fcber hinaus verwenden die meisten Docker-Images Debian oder Ubuntu als Basis-Image, und obwohl dies eine hervorragende Kompatibilit\u00e4t und leichte Anpassung erm\u00f6glicht (die Docker-Datei besteht aus nur zwei Codezeilen), k\u00f6nnen Basis-Images Hunderte von Megabyte an zus\u00e4tzlichem Overhead in Ihren Container hinzuf\u00fcgen. Zum Beispiel ben\u00f6tigt eine einfache node.js-Anwendung namens Go 'hello-world' etwa 700 Megabyte, w\u00e4hrend die Gr\u00f6\u00dfe Ihrer eigentlichen Anwendung nur wenige Megabyte betr\u00e4gt.<\/p>\n

\"Best
\n
\nDaher stellt die gesamte zus\u00e4tzliche Last eine reine Verschwendung digitaler Ressourcen dar und ist ein hervorragendes Versteck f\u00fcr Sicherheitsanf\u00e4lligkeiten und Fehler. Lassen Sie uns also zwei M\u00f6glichkeiten betrachten, um die Gr\u00f6\u00dfe des Container-Images zu reduzieren. <\/p>\n

Die erste M\u00f6glichkeit besteht darin, Basis-Images kleiner Gr\u00f6\u00dfe zu verwenden, die zweite darin, das Builder Pattern zu verwenden. Die Verwendung kleinerer Basis-Images ist wahrscheinlich der einfachste Weg, die Gr\u00f6\u00dfe Ihres Containers zu reduzieren. H\u00f6chstwahrscheinlich bietet die Programmiersprache oder der Technologie-Stack, den Sie verwenden, ein Original-Image der Anwendung, das wesentlich kleiner ist als das Standard-Image. Lassen Sie uns unseren node.js-Container genauer ansehen. <\/p>\n

\"Best
\n
\nStandardm\u00e4\u00dfig betr\u00e4gt die Gr\u00f6\u00dfe des Basis-Images node:8 in Docker 670 MB, w\u00e4hrend die Gr\u00f6\u00dfe von node:8-alpine nur 65 MB betr\u00e4gt, was bedeutet, dass es zehnmal kleiner ist. Mit dem kleineren Basisbild Alpine reduzieren Sie erheblich die Gr\u00f6\u00dfe Ihres Containers. Alpine ist eine kleine und leichtgewichtige Linux-Distribution, die bei Docker-Nutzern sehr beliebt ist, weil sie mit vielen Anwendungen kompatibel ist und gleichzeitig die Containergr\u00f6\u00dfe gering h\u00e4lt. Im Gegensatz zum Standard-Docker-Image \"node\" entfernt \"node:alpine\" viele Hilfsdateien und Programme und l\u00e4sst nur das, was zum Ausf\u00fchren Ihrer Anwendung erforderlich ist.<\/p>\n

Um zu einem kleineren Basis-Image zu wechseln, aktualisieren Sie einfach die Docker-Datei, um mit dem neuen Basis-Image zu beginnen:<\/p>\n

\"Best
\n
\nJetzt m\u00fcssen Sie im Gegensatz zum alten onbuild-Image Ihren Code in den Container kopieren und alle Abh\u00e4ngigkeiten installieren. Im neuen Docker-File beginnt der Container mit dem Image node:alpine, dann wird ein Verzeichnis f\u00fcr den Code erstellt, die Abh\u00e4ngigkeiten werden mit dem Paketmanager NPM installiert und schlie\u00dflich wird server.js gestartet.<\/p>\n

\"Best
\n
\nMit diesem Update erhalten Sie einen Container, der zehnmal kleiner ist. Wenn Ihre Programmiersprache oder Ihr Stack keine Funktion zur Reduzierung des Basis-Images bietet, verwenden Sie Alpine Linux. Dies erm\u00f6glicht Ihnen auch eine vollst\u00e4ndige Kontrolle \u00fcber den Inhalt des Containers. Die Verwendung von Basis-Images mit kleiner Gr\u00f6\u00dfe ist eine gro\u00dfartige M\u00f6glichkeit, kleine Container schnell zu erstellen. Aber Sie k\u00f6nnen noch mehr Einsparungen erzielen, indem Sie das Builder Pattern verwenden.<\/p>\n

\"Best
\n
\nIn interpretativen Sprachen wird der Quellcode zun\u00e4chst an den Interpreter \u00fcbergeben und dann direkt ausgef\u00fchrt. In kompilierbaren Sprachen wird der Quellcode zuvor in kompilierte Code umgewandelt. Dabei werden oft Werkzeuge verwendet, die tats\u00e4chlich nicht erforderlich sind, um den Code auszuf\u00fchren. Das bedeutet, dass Sie diese Werkzeuge vollst\u00e4ndig aus dem finalen Container entfernen k\u00f6nnen. Dazu kann das Builder Pattern verwendet werden.<\/p>\n

\"Best
\n
\nDer Code wird im ersten Container erstellt und kompiliert. Anschlie\u00dfend wird der kompilierte Code in den endg\u00fcltigen Container gepackt, ohne die f\u00fcr die Kompilierung dieses Codes erforderlichen Compiler und Tools. Lassen Sie uns diesen Prozess mit einer Go-Anwendung durchlaufen. Zun\u00e4chst wechseln wir vom onbuild-Image zu Alpine Linux.<\/p>\n

\"Best
\n
\nIm neuen Dockerfile beginnt der Container mit dem Image golang:alpine. Dann erstellt es ein Verzeichnis f\u00fcr den Code, kopiert den Quellcode hinein, kompiliert diesen Quellcode und f\u00fchrt die Anwendung aus. Dieser Container ist deutlich kleiner als der onbuild-Container, enth\u00e4lt jedoch immer noch den Compiler und andere Go-Tools, die wir eigentlich nicht ben\u00f6tigen. Lassen Sie uns daher einfach das kompilierte Programm extrahieren und in unseren eigenen Container verpacken.<\/p>\n

\"Best
\n
\nIn dieser Docker-Datei k\u00f6nnen Sie etwas Seltsames bemerken: Sie enth\u00e4lt zwei FROM-Zeilen. Der erste Abschnitt aus vier Zeilen sieht genau so aus wie die vorherige Docker-Datei, au\u00dfer dass er das Schl\u00fcsselwort AS verwendet, um diesem Schritt einen Namen zu geben. Im n\u00e4chsten Abschnitt gibt es eine neue FROM-Zeile, die es erm\u00f6glicht, ein neues Image zu starten, wobei wir statt des Images golang:alpine das Raw alpine Image als Basis verwenden.<\/p>\n

Raw Alpine Linux hat keine installierten SSL-Zertifikate, was die meisten API-Aufrufe \u00fcber HTTPS fehlerhaft macht. Lassen Sie uns also einige Root-Zertifikate der CA installieren.<\/p>\n

Und jetzt das Interessanteste: Um den kompilierten Code vom ersten Container in den zweiten zu kopieren, k\u00f6nnen wir einfach den Befehl COPY in Zeile 5 des zweiten Abschnitts verwenden. Dieser kopiert nur eine Anwendungsdatei und ber\u00fchrt nicht die Dienstprogramme von Go. Die neue mehrstufige Docker-Datei wird ein Container-Image von nur 12 Megabyte enthalten, w\u00e4hrend das Ausgangs-Container-Image 700 Megabyte gro\u00df war \u2013 das ist ein gro\u00dfer Unterschied!
\nDie Verwendung von kompakten Basis-Images und dem Builder Pattern sind hervorragende M\u00f6glichkeiten, Container mit deutlich reduzierter Gr\u00f6\u00dfe mit minimalem Aufwand zu erstellen.
\nJe nach Anwendungs-Stack k\u00f6nnten weitere Methoden zur Reduzierung der Image- und Containergr\u00f6\u00dfe existieren, jedoch, haben kleinere Container tats\u00e4chlich einen messbaren Vorteil? Lassen Sie uns zwei Aspekte betrachten, in denen kleine Container besonders effektiv sind \u2013 Leistung und Sicherheit.<\/p>\n

Um eine Leistungssteigerung zu bewerten, betrachten wir die Dauer des Containererstellungsprozesses, das Einf\u00fcgen in das Registry (Push) und das anschlie\u00dfende Abrufen davon (Pull). Sie werden feststellen, dass ein kleinerer Container einen unbestreitbaren Vorteil gegen\u00fcber einem gr\u00f6\u00dferen Container hat.<\/p>\n

\"Best
\n
\nDocker speichert die Schichten im Cache, sodass nachfolgende Builds sehr schnell ausgef\u00fchrt werden. In vielen CI-Systemen, die zum Erstellen und Testen von Containern verwendet werden, werden jedoch die Schichten nicht im Cache gespeichert, was zu einer erheblichen Zeitersparnis f\u00fchrt. Wie zu sehen ist, liegt die Build-Zeit f\u00fcr einen gro\u00dfen Container, je nach Leistung Ihrer Maschine, zwischen 34 und 54 Sekunden, w\u00e4hrend sie bei Verwendung eines durch das Builder-Muster optimierten Containers zwischen 23 und 28 Sekunden liegt. Bei solchen Vorg\u00e4ngen liegt der Leistungszuwachs bei 40-50%. Denken Sie also einfach daran, wie oft Sie Ihren Code erstellen und testen.<\/p>\n

Nachdem der Container erstellt wurde, m\u00fcssen Sie dessen Image (Push-Container-Image) in ein Container-Registry einf\u00fcgen, um es anschlie\u00dfend in Ihrem Kubernetes-Cluster zu verwenden. Ich empfehle, das Container-Registry von Google zu nutzen.<\/p>\n

\"Best
\n
\nMit Google Container Registry (GCR) zahlen Sie nur f\u00fcr den 'rohen' Speicher und die Netzwerknutzung, w\u00e4hrend keine zus\u00e4tzlichen Geb\u00fchren f\u00fcr die Verwaltung von Containern anfallen. Es ist vertraulich, sicher und sehr schnell. GCR verwendet zahlreiche Tricks, um den Pull-Vorgang zu beschleunigen. Wie Sie sehen, ben\u00f6tigt das Einf\u00fcgen eines Docker Container Images mit der Verwendung von go:onbuild, je nach Computerleistung, zwischen 15 und 48 Sekunden, w\u00e4hrend der gleiche Vorgang mit einem kleineren Container zwischen 14 und 16 Sekunden dauert. Bei weniger leistungsf\u00e4higen Maschinen erh\u00f6ht sich der Geschwindigkeitsvorteil dieses Vorgangs um das Dreifache. Bei gro\u00df dimensionierten Maschinen bleibt die Zeit ungef\u00e4hr gleich, da GCR einen globalen Cache f\u00fcr die gemeinsame Bilddatenbank nutzt, sodass Sie diese im Grunde nicht herunterladen m\u00fcssen. Bei einem Computer mit niedrigem CPU k\u00f6nnen die kleinen Container hier deutlich vorteilhafter sein.<\/p>\n

Wenn Sie GCR verwenden, empfehle ich dringend, Google Container Builder (GCB) als Teil Ihres Build-Systems zu integrieren.<\/p>\n

\"Best
\n
\nWie Sie sehen k\u00f6nnen, erm\u00f6glicht seine Verwendung deutlich bessere Ergebnisse bei der Verk\u00fcrzung der Build+Push-Dauer, als selbst bei leistungsstarken Maschinen \u2013 in diesem Fall wird der Prozess des Erstellens und Sendens von Containern an den Host fast um das Doppelte beschleunigt. Dar\u00fcber hinaus erhalten Sie jeden Tag 120 Minuten kostenlose Builds, was in den meisten F\u00e4llen den Anforderungen an die Erstellung von Containern entspricht. <\/p>\n

Als n\u00e4chstes kommt die wichtigste Leistungskennzahl \u2013 die Geschwindigkeit des Pullens oder Herunterladens von Containern. Wenn Sie sich nicht allzu sehr um die Zeit k\u00fcmmern, die f\u00fcr den Push-Vorgang ben\u00f6tigt wird, hat die Dauer des Pull-Vorgangs einen erheblichen Einfluss auf die Gesamtleistung des Systems. Angenommen, Sie haben einen Cluster aus drei Knoten und einer davon f\u00e4llt aus. Wenn Sie ein Management-System wie Google Kubernetes Engine verwenden, wird dieser ausgefallene Knoten automatisch durch einen neuen ersetzt. Dieser neue Knoten wird jedoch v\u00f6llig leer sein, und Sie m\u00fcssen alle Ihre Container dorthin ziehen, damit er mit der Arbeit beginnen kann. Wenn der Pull-Vorgang zu lange dauert, wird Ihr Cluster w\u00e4hrend dieser gesamten Zeit mit einer geringeren Leistung arbeiten.<\/p>\n

Es gibt viele F\u00e4lle, in denen so etwas passieren kann: das Hinzuf\u00fcgen eines neuen Knotens zum Cluster, das Aktualisieren von Knoten oder sogar der Wechsel zu einem neuen Container f\u00fcr das Deployment. Daher wird die Minimierung der Pull-Zeit zu einem entscheidenden Faktor. Unbestreitbar wird ein kleiner Container viel schneller heruntergeladen als ein gro\u00dfer. Wenn Sie mehrere Container in einem Kubernetes-Cluster verwenden, kann die Zeitersparnis erheblich sein.<\/p>\n

\"Best
\n
\nSehen Sie sich den folgenden Vergleich an: Der Pull-Vorgang bei der Arbeit mit kleinen Containern ben\u00f6tigt je nach Leistung des Ger\u00e4ts 4-9 mal weniger Zeit als derselbe Vorgang mit go:onbuild. Die Verwendung gemeinsamer Basis-Images kleiner Container beschleunigt erheblich die Zeit und Geschwindigkeit, mit der neue Kubernetes-Knoten bereitgestellt und ins Internet k\u00f6nnen.<\/p>\n

Lassen Sie uns das Thema Sicherheit betrachten. Man glaubt, dass kleinere Container viel sicherer sind als gro\u00dfe, da sie eine geringere Angriffsfl\u00e4che bieten. Ist das wirklich so? Eine der n\u00fctzlichsten Funktionen des Google Container Registry ist die M\u00f6glichkeit, Ihre Container automatisch auf Sicherheitsanf\u00e4lligkeiten zu scannen. Vor einigen Monaten habe ich sowohl Onbuild- als auch mehrstufige Container erstellt, also schauen wir mal, ob es dort verwundbare Stellen gibt. <\/p>\n

\"Best
\n
\nDas Ergebnis ist beeindruckend: In einem kleinen Container wurden nur 3 mittlere Sicherheitsanf\u00e4lligkeiten entdeckt, w\u00e4hrend im gro\u00dfen Container 16 kritische und 376 weitere Sicherheitsanf\u00e4lligkeiten gefunden wurden. Wenn wir die Inhalte des gro\u00dfen Containers betrachten, sehen wir, dass die meisten Sicherheitsprobleme nichts mit unserer Anwendung zu tun haben, sondern mit Programmen, die wir nicht einmal verwenden. Wenn also Leute von einer gro\u00dfen Angriffsfl\u00e4che sprechen, meinen sie genau das. <\/p>\n

\"Best
\n
\nDie Aussage ist klar: Erstellen Sie kleine Container, denn sie bieten echte Vorteile in Bezug auf die Leistung und Sicherheit Ihres Systems. <\/p>\n

Best Practices f\u00fcr Kubernetes. Organisation von Kubernetes mit Namespaces<\/a><\/noindex><\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Ein wenig Werbung \ud83d\ude42<\/h3>\n

\nDanke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? M\u00f6chten Sie mehr interessante Inhalte sehen? Unterst\u00fctzen Sie uns, indem Sie eine Bestellung aufgeben oder uns Ihren Freunden empfehlen. Cloud-VPS f\u00fcr Entwickler ab 4,99 $<\/a><\/noindex>, eine einzigartige Alternative zu Einsteiger-Servern, die wir f\u00fcr Sie entwickelt haben:<\/b> Alles \u00fcber VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt?<\/a><\/noindex> (Verf\u00fcgbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).<\/p>\n

Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis?<\/b> Nur bei uns 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB ab 199 $<\/a><\/noindex> in den Niederlanden! Dell R420 \u2014 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 ab 99 $!<\/b><\/b> Lesen Sie dar\u00fcber Wie man eine Unternehmenskosten-Infrastruktur mit Dell R730xd E5-2650 v4-Servern f\u00fcr ein paar Euro aufbaut?<\/a><\/noindex>
\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0435\u0440\u0432\u044b\u0439 \u0448\u0430\u0433 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes \u2013 \u044d\u0442\u043e \u0440\u0430\u0437\u043c\u0435\u0449\u0435\u043d\u0438\u0435 \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0431\u0440\u0430\u0437 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f Docker, \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u043e \u043d\u0430\u0441\u0442\u043e\u043b\u044c\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u044b\u043c. \u0423\u043a\u0430\u0436\u0438\u0442\u0435 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0434\u043e\u0431\u0430\u0432\u044c\u0442\u0435 \u0441\u0432\u043e\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438 \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u0438\u0435\u043c \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82245,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82244","post","type-post","status-publish","format-standard","has-post-thumbnail","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\udd47Best Practices f\u00fcr Kubernetes. Erstellung kleiner Container | ProHoster","description":"Der erste Schritt zur Bereitstellung in Kubernetes besteht darin, Ihre Anwendung in einem Container zu platzieren. In dieser Reihe werden wir sehen, wie man ein Abbild eines kleinen und sicheren Containers erstellen kann. Mit Docker war die Erstellung von Containerabbildern noch nie so einfach. Geben Sie ein Basisbild an, f\u00fcgen Sie Ihre \u00c4nderungen hinzu und erstellen Sie den Container. Obwohl diese Methode hervorragend geeignet ist, um zu beginnen,","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u0421\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 | ProHoster","og:description":"\u041f\u0435\u0440\u0432\u044b\u0439 \u0448\u0430\u0433 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes \u2013 \u044d\u0442\u043e \u0440\u0430\u0437\u043c\u0435\u0449\u0435\u043d\u0438\u0435 \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0431\u0440\u0430\u0437 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f Docker, \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u043e \u043d\u0430\u0441\u0442\u043e\u043b\u044c\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u044b\u043c. \u0423\u043a\u0430\u0436\u0438\u0442\u0435 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0434\u043e\u0431\u0430\u0432\u044c\u0442\u0435 \u0441\u0432\u043e\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438 \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u0438\u0435\u043c \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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-05-20T11:42:45+00:00","article:modified_time":"2020-05-20T11:42:45+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82244","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 15:41:28","updated":"2022-09-28 11:52:01"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/82244","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=82244"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/82244\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/82245"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=82244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=82244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=82244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}