{"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: Deaktivierung defekter Container","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

\"Istio
\n
\nDas heutige Thema ist der Circuit Breaker, der im elektrotechnischen Sinne ins Deutsche als \u201eautomatischer Schalter\u201c \u00fcbersetzt wird, umgangssprachlich als \u201eSchutzschalter\u201c. Nur dass dieser Schalter in Istio nicht einen kurzgeschlossenen oder \u00fcberlasteten Stromkreis abschaltet, sondern defekte Container.
\n<\/a><\/noindex><\/p>\n

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

\nWenn Mikrodienste von Kubernetes verwaltet werden, zum Beispiel innerhalb der OpenShift-Plattform, skalieren sie automatisch je nach Last nach oben oder unten. Da Mikrodienste in Pods arbeiten, k\u00f6nnen mehrere Instanzen eines containerisierten Mikrodienstes an einem Endpunkt vorhanden sein, und Kubernetes routet die Anfragen und lastet diese zwischen ihnen aus. Und - idealerweise - sollte das alles bestens funktionieren.<\/p>\n

Wir denken daran, dass Mikrodienste klein und fl\u00fcchtig sind. Diese Fl\u00fcchtigkeit, die hier die Einfachheit des Entstehens und Verschwindens bedeutet, wird oft untersch\u00e4tzt. Die Geburt und der Tod einer neuen Instanz des Mikrodienstes in einem Pod sind ganz normale Vorkommen, OpenShift und Kubernetes haben dies gut im Griff, und alles funktioniert gro\u00dfartig \u2013 aber wieder einmal nur in der Theorie.<\/p>\n

Wie funktioniert es tats\u00e4chlich<\/h3>\n

\nStellen Sie sich nun vor, dass eine bestimmte Instanz eines Mikrodienstes, also ein Container, ausgefallen ist: entweder antwortet er nicht (Fehler 503) oder - was unangenehmer ist - er reagiert, aber viel zu langsam. Mit anderen Worten, er hat kleine Aussetzer oder antwortet nicht auf Anfragen, wird aber dabei nicht automatisch aus dem Pool entfernt. Was soll in diesem Fall getan werden? Eine erneute Anfrage versuchen? Ihn aus dem Routing-Schema entfernen? Und was bedeutet \u201ezu langsam\u201c \u2013 wie viel ist das in Zahlen, und wer legt diese fest? Vielleicht 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 mit seinen Circuit Breakern ins Spiel, die defekte Container vor\u00fcbergehend aus dem Ressourcenpool f\u00fcr Routing und Lastenausgleich entfernen und das Verfahren der Pool Ejection umsetzen.<\/p>\n

Durch die Verwendung einer Ausrei\u00dfererkennung erkennt Istio fehlerhafte Pods, die aus der Allgemeinen Reihe herausfallen, und entfernt sie f\u00fcr eine bestimmte Zeit aus dem Ressourcenpool, die als \u201eSchlafzeit\u201c (sleep window) bezeichnet wird. <\/p>\n

Um zu zeigen, wie es in Kubernetes auf der OpenShift-Plattform funktioniert, beginnen wir mit einem Screenshot von ordnungsgem\u00e4\u00df funktionierenden Microdiensten aus dem 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 Istio-Routing-Regeln nicht verwendet werden, wendet Kubernetes standardm\u00e4\u00dfig eine gleichm\u00e4\u00dfig verteilte zyklische Weiterleitung an:<\/p>\n

\"Istio<\/p>\n

Vorbereiten auf den Ausfall<\/h3>\n

\nBevor wir Pool-Ejection durchf\u00fchren, m\u00fcssen wir eine Istio-Routing-Regel erstellen. Angenommen, wir m\u00f6chten die Anfragen zu je 50\/50 zwischen den Pods verteilen. Dar\u00fcber hinaus werden wir die Anzahl der Container v2 von eins auf zwei erh\u00f6hen, so:<\/p>\n

oc scale deployment recommendation-v2 --replicas=2 -n tutorial\n<\/code><\/pre>\n
\nJetzt legen wir eine Routing-Regel fest, um den Traffic zu je 50\/50 zwischen den Pods zu verteilen.<\/p>\n
\"Istio
\nSo sieht das Ergebnis dieser Regel aus:<\/p>\n
\"Istio
\nMan k\u00f6nnte bem\u00e4ngeln, 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
Einen Ausfall herbeif\u00fchren<\/h3>\n
\nJetzt nehmen wir einen der beiden Container v2 offline, sodass wir einen funktionierenden Container v1, einen funktionierenden Container v2 und einen defekten Container v2 haben: <\/p>\n
\"Istio<\/p>\n
Einen Ausfall beheben<\/h3>\n
\nAlso haben wir einen defekten Container, und es ist Zeit f\u00fcr Pool-Ejection. Mit einer sehr einfachen Konfiguration werden wir diesen defekten Container f\u00fcr 15 Sekunden aus allen Routing-Schemata ausschlie\u00dfen, in der Hoffnung, dass er selbst wieder funktionsf\u00e4hig wird (entweder durch einen Neustart oder durch Wiederherstellung der Leistung). So sieht diese Konfiguration aus und die Ergebnisse ihrer Anwendung:<\/p>\n
\"Istio
\n\"Istio
\nWie zu sehen ist, wird der defekte Container v2 bei der Weiterleitung von Anfragen 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 Pool-Ejection funktioniert.<\/p>\n
Beginnen mit dem Aufbau der Architektur<\/h3>\n
\nPool-Ejection in Kombination mit den \u00dcberwachungsm\u00f6glichkeiten von Istio erm\u00f6glicht es, ein Framework f\u00fcr die automatische Ersetzung defekter Container zu schaffen, um Ausfallzeiten und Fehler zu minimieren oder sogar ganz zu beseitigen.
\n\u2003
\nNASA hat einen einpr\u00e4gsamen Slogan \u2013 Failure Is Not an Option, der von dem Missionsleiter stammt. Gene Kranz<\/a><\/noindex>. Auf Deutsch k\u00f6nnte man sagen: \u201eNiederlage ist keine Option\u201c. Die Bedeutung hier ist, dass alles zum Funktionieren gebracht werden kann, wenn genug Wille vorhanden ist. In der realen Welt jedoch sind Ausf\u00e4lle nicht nur gelegentlich, sie sind unvermeidlich, \u00fcberall und in allem. Wie geht man also mit ihnen um, wenn es um Mikrodienste geht? Unserer Meinung nach sollte man sich nicht auf den Willen, sondern auf die M\u00f6glichkeiten von Containern verlassen. Kubernetes<\/a><\/noindex>, -Plattform bereitstellt. Weitere Informationen \u00fcber die Funktionsweise finden Sie<\/a><\/noindex>, und Istio<\/a><\/noindex>.<\/p>\n
Istio, wie bereits zuvor erw\u00e4hnt, implementiert ein bew\u00e4hrtes Konzept aus der physischen Welt: die automatischen Sicherungen. So wie eine elektrische Sicherung einen problematischen Abschnitt des Stromkreises trennt, unterbricht der programmatische Circuit Breaker in Istio die Verbindung zwischen dem Anfragefluss und dem problematischen Container, wenn mit dem Endpunkt etwas nicht stimmt, zum Beispiel wenn der Server ausgefallen ist oder langsam arbeitet.<\/p>\n
Im zweiten Fall sind die Probleme sogar noch gr\u00f6\u00dfer, da die Verz\u00f6gerungen eines Containers nicht nur Kaskadeneffekte in den darauf zugreifenden Diensten verursachen und somit die Gesamteffizienz des Systems mindern, sondern auch zu Wiederholungen von Anfragen an den ohnehin schon langsamen Dienst f\u00fchren, was die Situation nur versch\u00e4rft.<\/p>\n
Circuit Breaker in der Theorie<\/h3>\n
\nCircuit Breaker ist ein Proxy, der den Anfragefluss zum Endpunkt kontrolliert. Wenn dieser Endpunkt nicht mehr funktioniert oder \u2013 abh\u00e4ngig von den Einstellungen \u2013 anf\u00e4ngt, langsam zu werden, trennt der Proxy die Verbindung zum Container. Der Datenverkehr wird anschlie\u00dfend auf andere Container umgeleitet, einfach aus Gr\u00fcnden der Lastverteilung. Die Verbindung bleibt f\u00fcr ein festgelegtes Schlafintervall, sagen wir zwei Minuten, ge\u00f6ffnet (open) und wird danach als halb ge\u00f6ffnet (half-open) betrachtet. Der Versuch, die n\u00e4chste Anfrage zu senden, bestimmt den weiteren Zustand der Verbindung. Wenn alles mit dem Dienst in Ordnung ist, wird die Verbindung wieder in den Normalbetrieb \u00fcberf\u00fchrt und geschlossen (closed). Wenn jedoch weiterhin Probleme mit dem Dienst bestehen, wird die Verbindung unterbrochen und das Schlafintervall wird erneut aktiviert. So sieht ein vereinfachtes Diagramm der Zustands\u00e4nderungen eines Circuit Breakers aus:<\/p>\n
\"Istio
\nEs ist wichtig zu beachten, dass dies alles auf einer sogenannten Systemarchitekturebene geschieht. Daher m\u00fcssen Sie irgendwann Ihre Anwendungen darauf trainieren, mit Circuit Breaker zu arbeiten, indem Sie beispielsweise im Antwortwert einen Standardwert bereitstellen oder, wenn m\u00f6glich, die Existenz des Dienstes ignorieren. Daf\u00fcr wird das Bulkhead-Muster verwendet, aber das geht \u00fcber den Rahmen dieses Artikels hinaus.<\/p>\n
Circuit Breaker in der Praxis<\/h3>\n
\nWir werden 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. Zum Anzeigen der Ergebnisse wird das Tool verwendet siege<\/a><\/noindex>:<\/p>\n
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io\n<\/code><\/pre>\n
\n\"Istio
\nEs scheint alles zu funktionieren, aber zu welchem Preis? Auf den ersten Blick haben wir 100 % Verf\u00fcgbarkeit, aber schauen Sie genauer hin \u2013 die maximale Transaktionsdauer betr\u00e4gt ganze 12 Sekunden. Das ist eindeutig ein Engpass und muss aufgebrochen werden.<\/p>\n
Daf\u00fcr werden wir mit Istio die Zugriff auf langsame Container ausschlie\u00dfen. So sieht die entsprechende Konfiguration mit Circuit Breaker aus:<\/p>\n
\"Istio
\nDie letzte Zeile mit dem Parameter httpMaxRequestsPerConnection signalisiert, dass die Verbindung unterbrochen werden muss, wenn versucht wird, eine weitere \u2013 zweite \u2013 Verbindung zus\u00e4tzlich zur bereits bestehenden herzustellen. Da unser Container einen Bremservice simuliert, werden solche Situationen gelegentlich auftreten, und dann wird Istio einen Fehler 503 zur\u00fcckgeben, und das zeigt siege an:<\/p>\n
\"Istio<\/p>\n
Okay, wir haben einen Circuit Breaker, was nun?<\/h3>\n
\nSo haben wir eine automatische Abschaltung implementiert, ohne den Code der Dienste selbst zu ber\u00fchren. Mit Circuit Breaker und dem oben beschriebenen Verfahren zur Pool-Ausschluss k\u00f6nnen wir langsame Container aus dem Ressourcenpool entfernen, bis sie wieder in Ordnung sind, und ihren Zustand in festgelegten Zeitabst\u00e4nden \u00fcberpr\u00fcfen \u2013 in unserem Beispiel sind das zwei Minuten (Parameter sleepWindow).<\/p>\n
Beachten Sie, dass die F\u00e4higkeit der Anwendung, auf Fehler 503 zu reagieren, immer noch im Quellcode der Anwendung selbst festgelegt wird. Es gibt viele Strategien zur Arbeit mit Circuit Breaker, die je nach Situation angewendet werden.<\/p>\n
Im n\u00e4chsten Beitrag:<\/b> werden wir \u00fcber Tracing und Monitoring sprechen, die bereits in Istio integriert sind oder einfach hinzugef\u00fcgt werden k\u00f6nnen, sowie \u00fcber die absichtliche Fehlererzeugung im System.
\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: Deaktivieren fehlerhafter Container | ProHoster","description":"Die Feiertage sind vorbei, und wir kehren mit unserem zweiten Beitrag aus der Reihe \u00fcber Istio Service Mesh zur\u00fcck.","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.","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","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\/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}]}}