{"id":54987,"date":"2020-01-09T00:00:00","date_gmt":"2020-01-08T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery"},"modified":"2020-02-18T14:03:03","modified_gmt":"2020-02-18T11:03:03","slug":"istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","title":{"rendered":"Istio Circuit Breaker: defekte Container deaktivieren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Feiertage sind vorbei, und wir sind zur\u00fcck mit unserem zweiten Beitrag in der Reihe \u00fcber Istio Service Mesh.<\/p>\n

\"Istio
\n
\nDas heutige Thema \u2013 Circuit Breaker, was auf Deutsch \u201eautomatischer Schalter\u201c bedeutet, umgangssprachlich auch als \u201eSchutzschalter\u201c bekannt. In Istio schaltet dieser Schalter jedoch keine \u00fcberlastete oder kurzgeschlossene Leitung ab, sondern deaktiviert defekte Container.
\n<\/a><\/noindex><\/p>\n

So sollte es idealerweise funktionieren<\/h3>\n

\nWenn Microservices von Kubernetes verwaltet werden, zum Beispiel im Rahmen der OpenShift-Plattform, skalieren sie automatisch je nach Last nach oben oder unten. Da Microservices in Pods arbeiten, kann es an einem Endpunkt mehrere Instanzen eines containerisierten Microservices geben, und Kubernetes routet die Anfragen und balanciert die Last zwischen ihnen. Und \u2013 im Idealfall \u2013 sollte alles perfekt funktionieren.<\/p>\n

Wir wissen, dass Mikrodienste klein und fl\u00fcchtig sind. Diese Fl\u00fcchtigkeit, die hier bedeutet, dass sie einfach entstehen und verschwinden, wird oft untersch\u00e4tzt. Die Geburt und der Tod eines Mikrodienstes in einem Pod sind ganz normale Vorg\u00e4nge. OpenShift und Kubernetes meistern dies gut, und alles funktioniert wunderbar \u2013 zumindest in der Theorie.<\/p>\n

Wie funktioniert das wirklich?<\/h3>\n

\nStellen Sie sich jetzt vor, dass ein konkreter Mikrodienst, sprich ein Container, ausgefallen ist: Entweder antwortet er nicht (Fehler 503) oder \u2013 was schlimmer ist \u2013 er reagiert, jedoch viel zu langsam. Mit anderen Worten, er hat kleine St\u00f6rungen oder antwortet nicht auf Anfragen, wird aber nicht automatisch aus dem Pool entfernt. Was sollten Sie in diesem Fall tun? Den Versuch wiederholen? Ihn aus dem Routing-Schema entfernen? Und was bedeutet \"zu langsam\" \u2013 wie viel ist das in Zahlen und wer legt diese fest? Vielleicht sollten wir ihm einfach eine Pause geben und es sp\u00e4ter erneut versuchen? Wenn ja, wie viel sp\u00e4ter?<\/p>\n

Was ist Pool Ejection in Istio?<\/h3>\n

\nUnd hier kommt Istio ins Spiel mit seinen Circuit Breaker-Schutzmechanismen, die fehlerhafte Container vor\u00fcbergehend aus dem Ressourcenpool f\u00fcr Routing und Lastverteilung entfernen und somit die Pool Ejection-Prozedur umsetzen.<\/p>\n

Durch die Anwendung einer Outlier-Detection-Strategie erkennt Istio pod-Instanzen, die aus der Reihe fallen, und entfernt sie f\u00fcr eine festgelegte Zeitspanne aus dem Ressourcenpool, die als 'Sleep Window' bezeichnet wird. <\/p>\n

Um zu demonstrieren, wie dies in Kubernetes auf der OpenShift-Plattform funktioniert, beginnen wir mit einem Screenshot von normal laufenden Microservices aus einem Beispiel im Repository Red Hat Developer Demos<\/a><\/noindex>. Hier haben wir zwei Pods, v1 und v2, in denen jeweils ein Container l\u00e4uft. Wenn die Routingregeln von Istio nicht angewendet werden, nutzt Kubernetes standardm\u00e4\u00dfig eine gleichm\u00e4\u00dfig verteilte zyklische Routingstrategie:<\/p>\n

\"Istio<\/p>\n

Bereiten wir uns auf einen Ausfall vor<\/h3>\n

\nBevor wir die Pool Ejection durchf\u00fchren, m\u00fcssen wir eine Routingregel f\u00fcr Istio erstellen. Angenommen, wir m\u00f6chten die Anfragen im Verh\u00e4ltnis 50\/50 zwischen den Pods verteilen. Au\u00dferdem erh\u00f6hen wir die Anzahl der Container in v2 von einem auf zwei, so:<\/p>\n

oc scale deployment recommendation-v2 --replicas=2 -n tutorial\n<\/code><\/pre>\n
\nJetzt erstellen wir eine Routing-Regel, damit der Verkehr im Verh\u00e4ltnis 50\/50 zwischen den Pods verteilt wird.<\/p>\n
\"Istio
\nSo sieht das Ergebnis dieser Regel aus:<\/p>\n
\"Istio
\nMan k\u00f6nnte anmerken, dass auf diesem Screenshot nicht 50\/50, sondern 14:9 zu sehen ist, aber im Laufe der Zeit wird sich die Situation ausgleichen.<\/p>\n
Wir verursachen einen Fehler.<\/h3>\n
\nJetzt bringen wir einen der beiden v2-Container au\u00dfer Gefecht, sodass wir einen funktionierenden v1-Container, einen funktionierenden v2-Container und einen defekten v2-Container haben: <\/p>\n
\"Istio<\/p>\n
Wir beheben den Fehler.<\/h3>\n
\nAlso, wir haben einen defekten Container, und es ist Zeit f\u00fcr die Poolaussto\u00dfung. Mit einer sehr einfachen Konfiguration werden wir diesen fehlerhaften Container f\u00fcr 15 Sekunden aus allen Routing-Schemata ausschlie\u00dfen, in der Hoffnung, dass er sich entweder selbst repariert (oder neu gestartet wird oder die Leistung wiederherstellt). So sieht diese Konfiguration aus und die Ergebnisse ihrer Ausf\u00fchrung:<\/p>\n
\"Istio
\n\"Istio
\nWie man sehen kann, wird der defekte v2-Container bei der Anfrage-Routing nicht mehr verwendet, da er aus dem Pool entfernt wurde. Nach 15 Sekunden kehrt er jedoch automatisch in den Pool zur\u00fcck. Tats\u00e4chlich haben wir gerade gezeigt, wie die Poolaussto\u00dfung funktioniert.<\/p>\n
Beginnen wir mit dem Aufbau der Architektur.<\/h3>\n
\nDie Pool-Ejektion in Verbindung mit den \u00dcberwachungsm\u00f6glichkeiten von Istio erm\u00f6glicht den Aufbau eines Frameworks zur automatischen Ersetzung defekter Container, um Ausfallzeiten und St\u00f6rungen zu minimieren oder sogar ganz zu vermeiden.
\n\u2003
\nNASA hat ein bekanntes Motto \u2013 Failure Is Not an Option, das von Flight Director Gene Kranz<\/a><\/noindex>verbreitet wurde. Auf Deutsch l\u00e4sst es sich mit \u201eMisserfolg ist keine Option\u201c \u00fcbersetzen. Der Sinn dahinter ist, dass alles zum Funktionieren gebracht werden kann, solange gen\u00fcgend Entschlossenheit vorhanden ist. In der Realit\u00e4t jedoch sind Ausf\u00e4lle nicht nur wahrscheinlich, sie sind unvermeidlich, \u00fcberall und in allem. Wie geht man also mit ihnen um, wenn es um Mikrodienste geht? Unserer Meinung nach sollte man besser nicht auf Willenskraft setzen, sondern auf die M\u00f6glichkeiten von Containern. Kubernetes<\/a><\/noindex>, Red Hat OpenShift<\/a><\/noindex>, und Istio<\/a><\/noindex>.<\/p>\n
Istio implementiert, wie bereits erw\u00e4hnt, das sich im physischen Bereich bestens bew\u00e4hrte Konzept von automatischen Schutzschaltern. W\u00e4hrend ein elektrischer Schutzschalter den fehlerhaften Teil eines Stromkreises trennt, unterbricht der Software-Circuit Breaker in Istio die Verbindung zwischen dem Anfragefluss und dem problematischen Container, wenn mit dem Endpunkt etwas nicht stimmt, z. B. wenn der Server ausf\u00e4llt oder anf\u00e4ngt zu stottern.<\/p>\n
Im zweiten Fall gibt es nur noch mehr Probleme, da die Verz\u00f6gerungen eines Containers nicht nur Kaskadeneffekte in den damit verbundenen Diensten verursachen und so die Gesamtleistung des Systems beeintr\u00e4chtigen, sondern auch Wiederholungsanfragen an den bereits langsam laufenden Dienst hervorrufen, was die Situation weiter versch\u00e4rft.<\/p>\n
Circuit Breaker in der Theorie<\/h3>\n
\nCircuit Breaker \u2013 ist ein Proxy, der den Datenfluss zu einem Endpunkt \u00fcberwacht. Wenn dieser Endpunkt nicht mehr funktioniert oder \u2013 je nach den festgelegten Einstellungen \u2013 anf\u00e4ngt, langsam zu reagieren, trennt der Proxy die Verbindung zum Container. Der Datenverkehr wird anschlie\u00dfend auf andere Container umgeleitet, ganz einfach zur Lastverteilung. Die Verbindung bleibt f\u00fcr ein gegebenes Zeitfenster, sagen wir zwei Minuten, offen (open) und wird dann als halb-offen (half-open) betrachtet. Ein Versuch, die n\u00e4chste Anfrage zu senden, bestimmt den weiteren Zustand der Verbindung. Wenn mit dem Dienst alles in Ordnung ist, wird die Verbindung wieder aktiv und geschlossen (closed). Sollte jedoch weiterhin ein Problem mit dem Dienst bestehen, wird die Verbindung erneut getrennt und das Zeitfenster beginnt von vorn. So sieht ein vereinfachtes Diagramm des Zustandswechsels eines Circuit Breaker aus:<\/p>\n
\"Istio
\nEs ist wichtig zu beachten, dass dies alles auf der Ebene der sogenannten Systemarchitektur geschieht. Daher m\u00fcssen Sie irgendwann Ihre Anwendungen anweisen, mit dem Circuit Breaker zu arbeiten. Dies kann bedeuten, dass sie im Falle eines Fehlers einen Standardwert zur\u00fcckgeben oder, wenn m\u00f6glich, die Existenz des Dienstes ignorieren. Daf\u00fcr wird das Bulkhead-Muster verwendet, aber das w\u00fcrde den Rahmen dieses Artikels sprengen.<\/p>\n
Circuit Breaker in der Praxis<\/h3>\n
\nZum Beispiel werden wir auf OpenShift zwei Versionen unseres Mikrodienstes f\u00fcr Empfehlungen starten. Version 1 wird normal funktionieren, w\u00e4hrend wir in v2 eine Verz\u00f6gerung einbauen, um Verz\u00f6gerungen auf dem Server zu simulieren. Zur Anzeige der Ergebnisse verwenden wir das Tool siege<\/a><\/noindex>:<\/p>\n
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io\n<\/code><\/pre>\n
\n\"Istio
\nAlles scheint zu funktionieren, aber zu welchem Preis? Auf den ersten Blick haben wir eine Verf\u00fcgbarkeit von 100 %, aber beachten Sie \u2013 die maximale Transaktionsdauer betr\u00e4gt ganze 12 Sekunden. Das ist offensichtlich ein Engpass, den wir beheben m\u00fcssen.<\/p>\n
Um das zu erreichen, werden wir mit Hilfe von Istio die Anfragen an langsame Container ausschlie\u00dfen. So sieht die entsprechende Konfiguration mit dem Circuit Breaker aus:<\/p>\n
\"Istio
\nDie letzte Zeile mit dem Parameter httpMaxRequestsPerConnection signalisiert, dass die Verbindung getrennt werden sollte, wenn versucht wird, eine weitere \u2013 zweite \u2013 Verbindung zus\u00e4tzlich zu der bereits bestehenden herzustellen. Da unser Container einen throttling Service simuliert, werden solche Situationen gelegentlich auftreten, und dann wird Istio einen Fehler 503 zur\u00fcckgeben, w\u00e4hrend siege Folgendes anzeigen wird:<\/p>\n
\"Istio<\/p>\n
Okay, wir haben einen Circuit Breaker, und was nun?<\/h3>\n
\nAlso haben wir eine automatische Deaktivierung implementiert, ohne den Quellcode der Dienste selbst zu ber\u00fchren. Mit dem Circuit Breaker und dem oben beschriebenen Verfahren zur Pool-Auswurfung k\u00f6nnen wir leistungsstarke Container aus dem Ressourcenpool entfernen, bis sie wieder einsatzbereit sind, und deren Zustand in regelm\u00e4\u00dfigen Abst\u00e4nden \u00fcberpr\u00fcfen \u2013 in unserem Beispiel alle zwei Minuten (Parameter sleepWindow).<\/p>\n
Bitte beachten Sie, dass die F\u00e4higkeit der Anwendung, auf den Fehler 503 zu reagieren, weiterhin im Quellcode der Anwendung festgelegt ist. Es gibt viele Strategien zur Arbeit mit einem Circuit Breaker, die je nach Situation angewandt werden.<\/p>\n
Im n\u00e4chsten Beitrag:<\/b> Wir sprechen \u00fcber die Traceroute- und \u00dcberwachungsfunktionen, die bereits in Istio integriert sind oder einfach hinzugef\u00fcgt werden k\u00f6nnen, sowie dar\u00fcber, wie man absichtlich Fehler in das System einf\u00fchrt.
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u0438 \u0437\u0430\u0432\u0435\u0440\u0448\u0438\u043b\u0438\u0441\u044c, \u0438 \u043c\u044b \u0432\u043e\u0437\u0432\u0440\u0430\u0449\u0430\u0435\u043c\u0441\u044f \u0441 \u043d\u0430\u0448\u0438\u043c \u0432\u0442\u043e\u0440\u044b\u043c \u043f\u043e\u0441\u0442\u043e\u043c \u0438\u0437 \u0441\u0435\u0440\u0438\u0438 \u043f\u043e Istio Service Mesh. \u0421\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u044f\u044f \u0442\u0435\u043c\u0430 \u2013 Circuit Breaker, \u0447\u0442\u043e \u0432 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0435 \u043d\u0430 \u0440\u0443\u0441\u0441\u043a\u0438\u0439 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043e\u0437\u043d\u0430\u0447\u0430\u0435\u0442 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0432\u044b\u043a\u043b\u044e\u0447\u0430\u0442\u0435\u043b\u044c\u00bb, \u0432 \u043f\u0440\u043e\u0441\u0442\u043e\u0440\u0435\u0447\u0438\u0438 \u2013 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442 \u0437\u0430\u0449\u0438\u0442\u044b\u00bb. \u0422\u043e\u043b\u044c\u043a\u043e \u0432 Istio \u044d\u0442\u043e\u0442 \u0430\u0432\u0442\u043e\u043c\u0430\u0442 \u043e\u0442\u043a\u043b\u044e\u0447\u0430\u0435\u0442 \u043d\u0435 \u043a\u043e\u0440\u043e\u0442\u043d\u0443\u0432\u0448\u0443\u044e \u0438\u043b\u0438 \u043f\u0435\u0440\u0435\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u0443\u044e \u0446\u0435\u043f\u044c, \u0430 \u043d\u0435\u0438\u0441\u043f\u0440\u0430\u0432\u043d\u044b\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b. \u041a\u0430\u043a \u044d\u0442\u043e \u0434\u043e\u043b\u0436\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0432 \u0438\u0434\u0435\u0430\u043b\u0435 \u041a\u043e\u0433\u0434\u0430 […]<\/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-54987","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\udd47Istio Circuit Breaker: Fehlerhafte Container ausschalten | ProHoster","description":"Die Feiertage sind vorbei und wir kehren mit unserem zweiten Beitrag aus der Serie \u00fcber das Istio Service Mesh zur\u00fcck. Heute dreht sich alles um den Circuit Breaker, was auf Deutsch \"Sicherung\" bedeutet. In Istio sorgt dieser Circuit Breaker daf\u00fcr, dass nicht defekte oder \u00fcberlastete Schaltkreise, sondern fehlerhafte Container abgeschaltet werden. So sollte es idealerweise funktionieren.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","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\udd47Istio Circuit Breaker: \u043e\u0442\u043a\u043b\u044e\u0447\u0430\u0435\u043c \u043d\u0435\u0438\u0441\u043f\u0440\u0430\u0432\u043d\u044b\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b | ProHoster","og:description":"\u041f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u0438 \u0437\u0430\u0432\u0435\u0440\u0448\u0438\u043b\u0438\u0441\u044c, \u0438 \u043c\u044b \u0432\u043e\u0437\u0432\u0440\u0430\u0449\u0430\u0435\u043c\u0441\u044f \u0441 \u043d\u0430\u0448\u0438\u043c \u0432\u0442\u043e\u0440\u044b\u043c \u043f\u043e\u0441\u0442\u043e\u043c \u0438\u0437 \u0441\u0435\u0440\u0438\u0438 \u043f\u043e Istio Service Mesh. \u0421\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u044f\u044f \u0442\u0435\u043c\u0430 \u2013 Circuit Breaker, \u0447\u0442\u043e \u0432 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0435 \u043d\u0430 \u0440\u0443\u0441\u0441\u043a\u0438\u0439 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043e\u0437\u043d\u0430\u0447\u0430\u0435\u0442 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u0432\u044b\u043a\u043b\u044e\u0447\u0430\u0442\u0435\u043b\u044c\u00bb, \u0432 \u043f\u0440\u043e\u0441\u0442\u043e\u0440\u0435\u0447\u0438\u0438 \u2013 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442 \u0437\u0430\u0449\u0438\u0442\u044b\u00bb. \u0422\u043e\u043b\u044c\u043a\u043e \u0432 Istio \u044d\u0442\u043e\u0442 \u0430\u0432\u0442\u043e\u043c\u0430\u0442 \u043e\u0442\u043a\u043b\u044e\u0447\u0430\u0435\u0442 \u043d\u0435 \u043a\u043e\u0440\u043e\u0442\u043d\u0443\u0432\u0448\u0443\u044e \u0438\u043b\u0438 \u043f\u0435\u0440\u0435\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u0443\u044e \u0446\u0435\u043f\u044c, \u0430 \u043d\u0435\u0438\u0441\u043f\u0440\u0430\u0432\u043d\u044b\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b. \u041a\u0430\u043a \u044d\u0442\u043e \u0434\u043e\u043b\u0436\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0432 \u0438\u0434\u0435\u0430\u043b\u0435 \u041a\u043e\u0433\u0434\u0430","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/istio-circuit-breaker-otklyuchaem-neispravnye-kontejnery","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-01-08T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:03+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"54987","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":"2026-01-24 13:26:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:54:34","updated":"2026-01-24 13:26:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/54987","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=54987"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/54987\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=54987"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=54987"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=54987"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}