{"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":"Beste Praktiken f\u00fcr Kubernetes. Organisation von Kubernetes mit Namensr\u00e4umen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Beste Praktiken f\u00fcr Kubernetes. Erstellen kleiner Container<\/a><\/noindex><\/p>\n

Wenn Sie anfangen, immer mehr Kubernetes-Services zu erstellen, werden die anfangs einfachen Aufgaben komplizierter. Zum Beispiel k\u00f6nnen Entwicklerteams keine Dienste oder Deployments mit demselben Namen erstellen. Wenn Sie Tausende von Pods haben, wird allein das Auflisten viel 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 betrachten, wie Namespaces die Verwaltung von Kubernetes-Ressourcen erleichtern. Was ist also ein Namespace? Ein Namespace kann als virtueller Cluster innerhalb Ihres Kubernetes-Clusters angesehen werden. Sie k\u00f6nnen mehrere voneinander isolierte Namespaces innerhalb eines einzigen Kubernetes-Clusters haben. Diese k\u00f6nnen Ihnen und Ihren Teams wirklich bei der Organisation, Sicherheit und sogar der Systemleistung helfen.<\/p>\n

\"Beste
\n
\nIn den meisten Kubernetes-Distributionen kommt der Cluster \"out of the box\" mit einem Namespace namens \u201edefault\u201c. Es gibt tats\u00e4chlich drei Namespaces, mit denen Kubernetes arbeitet: default, kube-system und kube-public. Der Kube-public wird derzeit nicht sehr h\u00e4ufig genutzt.<\/a><\/noindex><\/p>\n

\"Beste
\n
\nEs ist eine gute Idee, den Namespace kube nicht anzufassen, insbesondere in einem so verwalteten System wie Google Kubernetes Engine. Es verwendet den Namespace \u201edefault\u201c als Ort, an dem Ihre Dienste und Anwendungen erstellt werden. Es gibt dort absolut nichts Besonderes, au\u00dfer dass Kubernetes \u201eout of the box\u201c darauf eingestellt ist und Sie ihn nicht l\u00f6schen k\u00f6nnen. Dies ist ideal f\u00fcr den Einstieg und Systeme mit geringer Leistung, aber ich w\u00fcrde nicht empfehlen, den Default-Namespace in gro\u00dfen Produktionssystemen zu verwenden. In letzterem Fall kann ein Entwicklerteam leicht den Code eines anderen Teams \u00fcberschreiben und die Arbeit des anderen Teams st\u00f6ren, ohne es zu merken.<\/p>\n

Daher sollten Sie mehrere Namespaces erstellen und diese zur Segmentierung Ihrer Dienste in verwaltbare 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 sie wie jede andere Kubernetes-Ressource.<\/p>\n

\"Beste
\n
\nAlle Namespaces k\u00f6nnen mit dem Befehl $ kubectl get namespace angezeigt werden. <\/p>\n

\"Beste
\n
\nNach der Ausf\u00fchrung sehen Sie drei integrierte Namespaces und einen neuen Namespace mit dem Namen \u201etest\u201c. Betrachten wir eine einfache YAML-Datei, die zur Erstellung eines Pods bestimmt ist. Dabei f\u00e4llt auf, dass es keine Erw\u00e4hnung des Namespaces gibt.<\/p>\n

\"Beste
\n
\nWenn Sie kubectl verwenden, um diese Datei auszuf\u00fchren, wird ein Modul mypod im aktuellen aktiven Namespace erstellt. Dies wird der Standardnamespace sein, bis Sie ihn \u00e4ndern. Es gibt zwei M\u00f6glichkeiten, Kubernetes anzugeben, in welchem Namespace Sie Ihre Ressource erstellen m\u00f6chten. Die erste M\u00f6glichkeit ist die Verwendung des Namespace-Flags bei der Erstellung der Ressource. <\/p>\n

\"Beste
\n
\nDie zweite M\u00f6glichkeit besteht darin, den Namespace in der YAML-Deklaration anzugeben.<\/p>\n

\"Beste
\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, schl\u00e4gt der Befehl fehl. Wenn Sie jetzt versuchen, Ihren Pod zu finden, werden Sie damit kein Gl\u00fcck haben. <\/p>\n

\"Beste
\n
\nDas passiert, weil alle Befehle au\u00dferhalb des aktuellen aktiven Namespaces ausgef\u00fchrt werden. Um Ihren Pod zu finden, m\u00fcssen Sie das Namespace-Flag verwenden, aber das wird schnell m\u00fchsam, insbesondere wenn Sie Entwickler in einer Gruppe sind, die ihren eigenen Namespace verwendet und dieses Flag nicht f\u00fcr jeden einzelnen Befehl verwenden m\u00f6chte. Lassen Sie uns sehen, wie wir das beheben k\u00f6nnen.<\/p>\n

\"Beste
\n
\nOut of the box tr\u00e4gt Ihr aktiver Namespace den Namen default. Wenn Sie keinen Namespace im YAML der Ressource angeben, verwenden alle Kubernetes-Befehle diesen aktiven default namespace. Leider kann der Versuch, den aktiven Namespace mit kubectl zu verwalten, fehlschlagen. Es gibt jedoch ein sehr gutes Tool namens Kubens, das diesen Prozess erheblich vereinfacht. Wenn Sie den Befehl kubens ausf\u00fchren, sehen Sie alle Namespaces mit dem hervorgehobenen aktiven Namespace. <\/p>\n

\"Beste
\n
\nUm den aktiven Namespace auf den Namespace test umzuschalten, f\u00fchren Sie einfach den Befehl $ kubens test aus. Wenn Sie danach erneut den Befehl $ kubens eingeben, sehen Sie, dass jetzt der neue aktive Namespace \u2013 test \u2013 hervorgehoben ist.<\/p>\n

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

\"Beste
\n
\nSo sind die Namespaces untereinander verborgen, aber nicht isoliert. Ein Dienst aus einem Namespace kann relativ einfach mit einem Dienst in einem anderen Namespace kommunizieren, was h\u00e4ufig sehr n\u00fctzlich ist. Die M\u00f6glichkeit zur Kommunikation zwischen verschiedenen Namespaces bedeutet, dass der Dienst Ihrer Entwickler mit dem Dienst eines anderen Entwicklungsteams in einem anderen Namespace interagieren kann.<\/p>\n

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

\"Beste
\n
\nGl\u00fccklicherweise ist dies leicht zu umgehen, indem Sie die voll ausgeschriebene Form der DNS-Adresse verwenden. Dienste in Kubernetes exponieren ihre Endpunkte unter Verwendung einer gemeinsamen DNS-Vorlage. Das sieht ungef\u00e4hr so aus:<\/p>\n

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

\"Beste
\n
\nWenn Sie jedoch auf einen Dienst in einem anderen Namespace zugreifen m\u00fcssen, verwenden Sie einfach den Dienstnamen plus den Namespace-Namen:<\/p>\n

\"Beste
\n
\nWenn Sie beispielsweise auf die Datenbank des Dienstes im Test-Namespace zugreifen m\u00f6chten, k\u00f6nnen Sie die Adresse database.test verwenden.<\/p>\n

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

\"Beste
\n
\nWenn Sie wirklich isolieren und den Zugriff auf einen Namespace einschr\u00e4nken m\u00f6chten, erm\u00f6glicht Kubernetes dies durch die Kubernetes Network Policies. Dar\u00fcber werde ich in der n\u00e4chsten Folge sprechen. <\/p>\n

Ich bekomme h\u00e4ufig die Frage, wie viele Namespaces erstellt werden sollen und zu welchem Zweck. Was ist also ein verwalteter Datenausschnitt?<\/p>\n

Wenn Sie zu viele Namensr\u00e4ume erstellen, stehen sie Ihnen einfach im Weg. Sind es jedoch zu wenige, verlieren Sie alle Vorteile einer solchen L\u00f6sung. Ich denke, es gibt vier grundlegende Phasen, die jedes Unternehmen bei der Erstellung seiner Organisationsstruktur durchl\u00e4uft. Je nach Entwicklungsphase, in der sich Ihr Projekt oder Unternehmen befindet, k\u00f6nnen Sie die entsprechende Strategie zur Erstellung von Namensr\u00e4umen \u00fcbernehmen.<\/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 Prod-Dienste im Namensraum 'default' zu starten. Nat\u00fcrlich k\u00f6nnen Sie f\u00fcr mehr Spielraum auch 2 Namensr\u00e4ume verwenden \u2013 getrennt f\u00fcr Prod und Dev. Wahrscheinlich testen Sie Ihre Entwicklung auf einem lokalen Computer mit etwas wie Minikube. <\/p>\n

Angenommen, die Bedingungen haben sich ge\u00e4ndert und jetzt haben Sie ein schnell wachsendes Team, das gleichzeitig an mehr als 10 Mikrodiensten arbeitet. Der Zeitpunkt kommt, an dem Sie mehrere Cluster oder Namensr\u00e4ume verwenden m\u00fcssen, getrennt f\u00fcr Prod und Dev. Sie k\u00f6nnen das Team in mehrere Untergruppen aufteilen, sodass jede ihre eigenen Mikrodienste hat und jedes dieser Teams seinen eigenen Namensraum ausw\u00e4hlen kann, um den Entwicklungs- und Ver\u00f6ffentlichungsprozess zu erleichtern.<\/p>\n

\"Beste
\n
\nW\u00e4hrend jedes Teammitglied ein Verst\u00e4ndnis daf\u00fcr entwickelt, wie das System insgesamt funktioniert, wird es immer schwieriger, jede \u00c4nderung mit allen 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 \u00fcberhaupt nicht, wer an was konkret arbeitet. Teams kommunizieren \u00fcber Servicevertr\u00e4ge oder verwenden eine Service-Mesh-Technologie, die \u00fcber dem Netzwerk eine Abstraktionsebene wie das Konfigurationstool Istio hinzuf\u00fcgt. Es ist schlichtweg unm\u00f6glich, den gesamten Stack lokal zu starten. Ich empfehle dringend, in Kubernetes eine kontinuierliche Bereitstellungsplattform (CD) wie Spinnaker zu verwenden. Damit kommt der Zeitpunkt, an dem jedes Team definitiv seinen eigenen Namensraum ben\u00f6tigt. Jedes Team kann sogar mehrere Namensr\u00e4ume f\u00fcr die Entwicklungs- und Produktionsumgebung ausw\u00e4hlen. <\/p>\n

Schlie\u00dflich gibt es gro\u00dfe Unternehmensunternehmen, in denen eine Entwicklergruppe nicht einmal von der Existenz anderer Gruppen wei\u00df. Ein solches 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 Tools zu nutzen, von denen ich zuvor gesprochen habe.<\/p>\n

\"Beste
\n
\nProgrammierer sollten Dienste nicht manuell bereitstellen und sollten keinen Zugriff auf Namensr\u00e4ume haben, die sie nicht betreffen. An diesem Punkt ist es sinnvoll, mehrere Cluster zu haben, um den \u00abSprengradius\u00bb schlecht konfigurierter Anwendungen zu verringern, sowie um die Abrechnungs- und Ressourcenmanagementprozesse zu vereinfachen.<\/p>\n

So erm\u00f6glicht die richtige Nutzung von Namensr\u00e4umen durch Ihre Organisation, Kubernetes verwaltbarer, kontrollierbarer, sicherer und flexibler zu gestalten.<\/p>\n

Beste Praktiken f\u00fcr Kubernetes. \u00dcberpr\u00fcfen der Lebensf\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 Freunden empfehlen, Cloud-VPS f\u00fcr Entwickler ab 4,99 $<\/a><\/noindex>, ein einzigartiges \u00c4quivalent zu Einsteigerservern, das wir f\u00fcr Sie entwickelt haben:<\/b> Die ganze Wahrheit \u00fcber VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt?<\/a><\/noindex> (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verf\u00fcgbar).<\/p>\n

Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so g\u00fcnstig?<\/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, wie man eine Unternehmensinfrastruktur der Klasse C mit Dell R730xd E5-2650 v4-Servern f\u00fcr 9000 Euro im Preis-Leistungs-Verh\u00e4ltnis 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\udd47Beste Kubernetes-Praktiken. Organisation von Kubernetes mit Namensr\u00e4umen | ProHoster","description":"Die besten Kubernetes-Praktiken.","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.","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","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\/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}]}}