{"id":82223,"date":"2020-05-20T13:42:34","date_gmt":"2020-05-20T11:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen"},"modified":"2020-05-20T13:42:34","modified_gmt":"2020-05-20T11:42:34","slug":"luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","title":{"rendered":"Best Practices f\u00fcr Kubernetes. Organisation von Kubernetes mit Namespaces","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Best Practices f\u00fcr Kubernetes. Erstellung kleiner Container<\/a><\/noindex><\/p>\n

Mit der zunehmenden Erstellung von Kubernetes-Services werden anfangs einfache Aufgaben immer komplexer. Zum Beispiel k\u00f6nnen Entwicklerteams keine Dienste oder Deployments mit demselben Namen erstellen. Wenn Sie Tausende von Pods haben, wird allein das Auflisten eine Menge Zeit in Anspruch nehmen, ganz zu schweigen von der ordnungsgem\u00e4\u00dfen Verwaltung. Und das ist nur die Spitze des Eisbergs.<\/p>\n

Lassen Sie uns untersuchen, wie Namespaces die Verwaltung von Kubernetes-Ressourcen erleichtern. Was ist ein Namespace? Ein Namespace kann als virtueller Cluster innerhalb Ihres Kubernetes-Clusters betrachtet werden. Sie k\u00f6nnen mehrere voneinander isolierte Namespaces innerhalb eines Clusters haben. Diese k\u00f6nnen Ihnen und Ihren Teams tats\u00e4chlich bei der Organisation, Sicherheit und sogar der Systemleistung helfen.<\/p>\n

\"Best
\n
\nIn den meisten Kubernetes-Distributionen wird der Cluster standardm\u00e4\u00dfig mit einem Namespace namens \u201edefault\u201c geliefert. Es gibt tats\u00e4chlich drei Namespaces, mit denen Kubernetes umgeht: default, kube-system und kube-public. Aktuell wird kube-public nicht allzu h\u00e4ufig verwendet.<\/a><\/noindex><\/p>\n

\"Best
\n
\nEs ist ratsam, den Namespace kube unber\u00fchrt zu lassen, insbesondere in einem verwalteten System wie Google Kubernetes Engine. Dieses nutzt den Namespace \"default\" als Ort, an dem Ihre Dienste und Anwendungen erstellt werden. Es gibt nichts Besonderes daran, au\u00dfer dass Kubernetes standardm\u00e4\u00dfig darauf eingestellt ist, ihn zu verwenden, und Sie ihn nicht l\u00f6schen k\u00f6nnen. Dies ist ideal f\u00fcr den Einstieg und Systeme mit geringer Leistung, doch in gr\u00f6\u00dferen Produktionsumgebungen w\u00fcrde ich empfehlen, den Standard-Namespace nicht zu verwenden. In letzterem Fall k\u00f6nnte ein Entwicklerteam den Code eines anderen Teams leicht \u00fcberschreiben und die Arbeit eines anderen Teams beeintr\u00e4chtigen, ohne es zu merken.<\/p>\n

Deshalb sollte man mehrere Namespaces erstellen und diese zur Segmentierung Ihrer Dienste in verwaltete Einheiten nutzen. Ein Namespace kann mit einem einzigen Befehl erstellt werden. Wenn Sie einen Namespace mit dem Namen \"test\" erstellen m\u00f6chten, verwenden Sie den Befehl $ kubectl create namespace test oder erstellen Sie einfach eine YAML-Datei und verwenden Sie diese wie jede andere Kubernetes-Ressource.<\/p>\n

\"Best
\n
\nUm alle Namespaces anzuzeigen, k\u00f6nnen Sie den Befehl $ kubectl get namespace verwenden. <\/p>\n

\"Best
\n
\nNach der Ausf\u00fchrung sehen Sie drei integrierte Namespaces sowie einen neuen Namespace mit dem Namen \u201etest\u201c. Lassen Sie uns eine einfache YAML-Datei betrachten, die zur Erstellung eines Pods dient. Es ist anzumerken, dass darin kein Hinweis auf den Namespace enthalten ist.<\/p>\n

\"Best
\n
\nWenn Sie kubectl verwenden, um diese Datei auszuf\u00fchren, wird das Modul mypod im derzeit aktiven Namespace erstellt. Dies ist der Standard-Namespace, bis Sie ihn \u00e4ndern. Es gibt zwei M\u00f6glichkeiten, Kubernetes anzugeben, in welchem Namespace Sie Ihre Ressource erstellen m\u00f6chten. Der erste Weg ist die Verwendung des Namespace-Flags beim Erstellen der Ressource. <\/p>\n

\"Best
\n
\nDer zweite Weg besteht darin, den Namespace in der YAML-Deklaration anzugeben.<\/p>\n

\"Best
\n
\nWenn Sie den Namespace in YAML angeben, wird die Ressource immer in diesem Namespace erstellt. Wenn Sie versuchen, einen anderen Namespace mit dem Namespace-Flag zu verwenden, wird der Befehl mit einem Fehler beendet. Jetzt, wenn Sie versuchen, Ihren Pod zu finden, werden Sie ihn nicht finden k\u00f6nnen. <\/p>\n

\"Best
\n
\nDies geschieht, weil alle Befehle au\u00dferhalb des derzeit aktiven Namensraums ausgef\u00fchrt werden. Um Ihren Pod zu finden, m\u00fcssen Sie das Namensraum-Flag verwenden, was jedoch schnell l\u00e4stig werden kann, insbesondere wenn Sie als Entwickler in einer Gruppe arbeiten, die ihren eigenen Namensraum verwendet und nicht f\u00fcr jeden einzelnen Befehl ein solches Flag nutzen m\u00f6chte. Lassen Sie uns anschauen, wie wir das beheben k\u00f6nnen.<\/p>\n

\"Best
\n
\nStandardm\u00e4\u00dfig tr\u00e4gt Ihr aktiver Namensraum den Namen default. Wenn Sie das Namensraum im YAML-Ressourcen nicht angeben, verwenden alle Kubernetes-Befehle diesen aktiven Standardnamensraum. Leider kann der Versuch, das aktive Namensraum \u00fcber kubectl zu verwalten, fehlschlagen. Es gibt jedoch ein sehr n\u00fctzliches Tool namens Kubens, das diesen Prozess erheblich vereinfacht. Wenn Sie den Befehl kubens ausf\u00fchren, sehen Sie alle Namensr\u00e4ume mit dem hervorgehobenen aktiven Namensraum. <\/p>\n

\"Best
\n
\nUm den aktiven Namespace auf den Namespace test zu wechseln, f\u00fchren Sie einfach den Befehl $ kubens test aus. Wenn Sie danach erneut den Befehl $ kubens eingeben, wird angezeigt, dass jetzt der neue aktive Namespace \u2013 test \u2013 zugewiesen ist.<\/p>\n

\"Best
\n
\nDas bedeutet, dass Sie kein Namespace-Flag ben\u00f6tigen, um das Pod im Namespace test zu sehen.<\/p>\n

\"Best
\n
\nNamespace sind somit voneinander verborgen, aber nicht voneinander isoliert. Ein Dienst aus einem Namespace kann recht einfach mit einem Dienst in einem anderen Namespace kommunizieren, was oft sehr n\u00fctzlich ist. Die M\u00f6glichkeit der Kommunikation zwischen verschiedenen Namespaces erm\u00f6glicht es, dass der Dienst Ihrer Entwickler mit dem Dienst eines anderen Entwicklungsteams in einem anderen Namespace interagiert.<\/p>\n

Normalerweise, wenn Ihre Anwendung auf einen Kubernetes-Dienst zugreifen m\u00f6chte, verwenden Sie den integrierten DNS-Dienst zur Dienstentdeckung und geben einfach den Namen des Dienstes an Ihre Anwendung weiter. Dabei k\u00f6nnen Sie jedoch einen Dienst mit demselben Namen in mehreren Namespaces erstellen, was nicht zul\u00e4ssig ist. <\/p>\n

\"Best
\n
\nGl\u00fccklicherweise l\u00e4sst sich das leicht umgehen, indem man die erweiterte Form der DNS-Adresse verwendet. Dienste in Kubernetes stellen ihre Endpunkte mithilfe eines allgemeinen DNS-Musters bereit. Das sieht etwa so aus:<\/p>\n

\"Best
\n
\nIn der Regel ben\u00f6tigen Sie einfach den Namen des Dienstes, und das DNS bestimmt automatisch die vollst\u00e4ndige Adresse. <\/p>\n

\"Best
\n
\nWenn Sie jedoch auf einen Dienst in einem anderen Namensraum zugreifen m\u00f6chten, verwenden Sie einfach den Dienstnamen plus den Namen des Namensraums:<\/p>\n

\"Best
\n
\nWenn Sie beispielsweise eine Verbindung zur Datenbank eines Dienstes im Test-Namensraum herstellen m\u00f6chten, k\u00f6nnen Sie die Adresse database.test verwenden.<\/p>\n

\"Best
\n
\nWenn Sie hingegen auf die Datenbank des Dienstes im Namensraum prod zugreifen m\u00f6chten, verwenden Sie database.prod.<\/p>\n

\"Best
\n
\nWenn Sie den Zugriff auf einen Namensraum wirklich isolieren und einschr\u00e4nken m\u00f6chten, erm\u00f6glicht Kubernetes dies mit Kubernetes-Netzwerkrichtlinien. Dar\u00fcber werde ich in der n\u00e4chsten Reihe berichten. <\/p>\n

Ich bekomme oft die Frage, wie viele Namensr\u00e4ume man erstellen sollte und zu welchen Zwecken. Was genau ist ein verwalteter Datenfragment?<\/p>\n

Wenn Sie zu viele Namensr\u00e4ume erstellen, werden sie Sie nur behindern. Wenn es zu wenig sind, verlieren Sie alle Vorteile dieser L\u00f6sung. Ich denke, dass jede Firma vier grundlegende Phasen durchl\u00e4uft, wenn sie ihre Organisationsstruktur aufbaut. Je nach Entwicklungsstand Ihres Projekts oder Unternehmens k\u00f6nnen Sie eine geeignete Strategie zur Erstellung von Namensr\u00e4umen anwenden.<\/p>\n

Stellen Sie sich vor, Sie sind Teil eines kleinen Teams, das an der Entwicklung von 5-10 Mikrodiensten arbeitet, und Sie k\u00f6nnen alle Entwickler problemlos in einem Raum versammeln. In dieser Situation macht es Sinn, alle Produktionsdienste im Standard-Namensraum zu betreiben. Nat\u00fcrlich k\u00f6nnen Sie f\u00fcr mehr Flexibilit\u00e4t zwei Namensr\u00e4ume verwenden \u2013 einen f\u00fcr Produktion und einen f\u00fcr Entwicklung. Wahrscheinlich testen Sie Ihre Entwicklung auch lokal auf Ihrem Computer mit etwas wie Minikube. <\/p>\n

Angenommen, die Rahmenbedingungen haben sich ge\u00e4ndert und Sie haben jetzt ein schnell wachsendes Team, das gleichzeitig an mehr als 10 Mikrodiensten arbeitet. Es kommt der Zeitpunkt, an dem Sie mehrere Cluster oder Namensr\u00e4ume ben\u00f6tigen, sowohl f\u00fcr Prod als auch f\u00fcr Dev. Sie k\u00f6nnen das Team in mehrere Untergruppen aufteilen, sodass jede Gruppe ihre eigenen Mikrodienste hat und jede dieser Gruppen ihren eigenen Namensraum w\u00e4hlen kann, um den Entwicklungs- und Release-Prozess zu erleichtern.<\/p>\n

\"Best
\n
\nW\u00e4hrend jedes Teammitglied ein besseres Verst\u00e4ndnis daf\u00fcr entwickelt, wie das System insgesamt funktioniert, wird es immer schwieriger, jede \u00c4nderung mit den anderen Entwicklern abzustimmen. Es wird zunehmend komplizierter, den gesamten Stack auf Ihrem lokalen Computer zum Laufen zu bringen. <\/p>\n

In gro\u00dfen Unternehmen wissen die Entwickler oft nicht, wer genau an was arbeitet. Teams kommunizieren \u00fcber Servicevertr\u00e4ge oder nutzen Technologien wie Service Mesh, die eine Abstraktionsschicht \u00fcber dem Netzwerk hinzuf\u00fcgen, \u00e4hnlich wie das Konfigurationstool Istio. Es ist praktisch unm\u00f6glich, den gesamten Stack lokal auszuf\u00fchren. Ich empfehle dringend, in Kubernetes eine Continuous Delivery (CD)-Plattform wie Spinnaker zu verwenden. Jeder Zeitpunkt, an dem jede Gruppe definitiv ihren eigenen Namensraum ben\u00f6tigt, ist entscheidend. Jede Gruppe kann sogar mehrere Namensr\u00e4ume f\u00fcr die Entwicklungs- und Produktionsumgebung ausw\u00e4hlen. <\/p>\n

Schlie\u00dflich gibt es gro\u00dfe Unternehmen, in denen eine Entwicklergruppe nicht einmal \u00fcber die Existenz anderer Gruppen Bescheid wei\u00df. Solch ein Unternehmen kann sogar externe Entwickler einstellen, die \u00fcber gut dokumentierte APIs interagieren. In jeder dieser Gruppen gibt es mehrere Teams und mehrere Mikrodienste. In diesem Fall ist es notwendig, alle Werkzeuge zu verwenden, \u00fcber die ich zuvor gesprochen habe.<\/p>\n

\"Best
\n
\nEntwickler sollten Dienste nicht manuell bereitstellen und keinen Zugriff auf Namespaces haben, die f\u00fcr sie irrelevant sind. In dieser Phase ist es sinnvoll, mehrere Cluster zu verwenden, um den \"Explosionradius\" schlecht konfigurierter Anwendungen zu reduzieren sowie um die Abrechnungs- und Ressourcenmanagementprozesse zu erleichtern.<\/p>\n

Durch die richtige Nutzung der Namespaces in Ihrer Organisation wird Kubernetes kontrollierbarer, sicherer und flexibler.<\/p>\n

Best Practices f\u00fcr Kubernetes. \u00dcberpr\u00fcfung der Betriebsf\u00e4higkeit von Kubernetes mit Readiness- und Liveness-Tests<\/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":"

\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 \u041f\u043e \u043c\u0435\u0440\u0435 \u0442\u043e\u0433\u043e \u043a\u0430\u043a \u0432\u044b \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u0442\u0435 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0438 \u0431\u043e\u043b\u044c\u0448\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 Kubernetes, \u043f\u0440\u043e\u0441\u0442\u044b\u0435 \u043f\u043e \u043d\u0430\u0447\u0430\u043b\u0443 \u0437\u0430\u0434\u0430\u0447\u0438 \u043d\u0430\u0447\u0438\u043d\u0430\u044e\u0442 \u0443\u0441\u043b\u043e\u0436\u043d\u044f\u0442\u044c\u0441\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u043d\u0435 \u043c\u043e\u0433\u0443\u0442 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0436\u0431\u044b \u0438\u043b\u0438 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u043f\u043e\u0434 \u043e\u0434\u043d\u0438\u043c \u0438 \u0442\u0435\u043c \u0436\u0435 \u0438\u043c\u0435\u043d\u0435\u043c. \u0415\u0441\u043b\u0438 \u0443 \u0432\u0430\u0441 \u0442\u044b\u0441\u044f\u0447\u0438 \u043f\u043e\u0434\u043e\u0432, \u0438\u0445 \u043f\u0440\u043e\u0441\u0442\u043e\u0435 \u043f\u0435\u0440\u0435\u0447\u0438\u0441\u043b\u0435\u043d\u0438\u0435 \u0437\u0430\u0439\u043c\u0435\u0442 \u043a\u0443\u0447\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438, \u043d\u0435 \u0433\u043e\u0432\u043e\u0440\u044f \u043e \u0442\u043e\u043c, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82224,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82223","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\udd47 Beste Kubernetes-Praktiken. Organisation von Kubernetes mit Namespaces | ProHoster","description":"Beste Kubernetes-Praktiken. Erstellen Sie kleine Container. Wenn Sie beginnen, immer mehr Kubernetes-Dienste zu erstellen, wird das, was anfangs einfach schien, zunehmend komplizierter. Zum Beispiel k\u00f6nnen Entwicklerteams keine Dienste oder Deployments mit demselben Namen erstellen. Bei Tausenden von Pods kann es viel Zeit in Anspruch nehmen, sie einfach aufzulisten, ganz zu schweigen davon, dass...","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","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. \u041e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f Kubernetes \u0441 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e\u043c \u0438\u043c\u0435\u043d | ProHoster","og:description":"\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 \u041f\u043e \u043c\u0435\u0440\u0435 \u0442\u043e\u0433\u043e \u043a\u0430\u043a \u0432\u044b \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u0442\u0435 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 \u0438 \u0431\u043e\u043b\u044c\u0448\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 Kubernetes, \u043f\u0440\u043e\u0441\u0442\u044b\u0435 \u043f\u043e \u043d\u0430\u0447\u0430\u043b\u0443 \u0437\u0430\u0434\u0430\u0447\u0438 \u043d\u0430\u0447\u0438\u043d\u0430\u044e\u0442 \u0443\u0441\u043b\u043e\u0436\u043d\u044f\u0442\u044c\u0441\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432 \u043d\u0435 \u043c\u043e\u0433\u0443\u0442 \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0436\u0431\u044b \u0438\u043b\u0438 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u043f\u043e\u0434 \u043e\u0434\u043d\u0438\u043c \u0438 \u0442\u0435\u043c \u0436\u0435 \u0438\u043c\u0435\u043d\u0435\u043c. \u0415\u0441\u043b\u0438 \u0443 \u0432\u0430\u0441 \u0442\u044b\u0441\u044f\u0447\u0438 \u043f\u043e\u0434\u043e\u0432, \u0438\u0445 \u043f\u0440\u043e\u0441\u0442\u043e\u0435 \u043f\u0435\u0440\u0435\u0447\u0438\u0441\u043b\u0435\u043d\u0438\u0435 \u0437\u0430\u0439\u043c\u0435\u0442 \u043a\u0443\u0447\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438, \u043d\u0435 \u0433\u043e\u0432\u043e\u0440\u044f \u043e \u0442\u043e\u043c,","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-organizacziya-kubernetes-s-prostranstvom-imen","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:34+00:00","article:modified_time":"2020-05-20T11:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82223","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:29","updated":"2022-09-29 19:27:31"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/82223","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=82223"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/82223\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/82224"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=82223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=82223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=82223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}