{"id":32766,"date":"2019-10-31T21:48:48","date_gmt":"2019-10-31T18:48:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1\/"},"modified":"2019-10-31T21:48:48","modified_gmt":"2019-10-31T18:48:48","slug":"kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","title":{"rendered":"Wie man Istio mit Kubernetes in der Produktion startet. Teil 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Was ist Istio<\/a><\/noindex>? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e. \u041c\u044b \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u044b\u0432\u0430\u0435\u043c \u0432\u0435\u0441\u044c \u0438\u043b\u0438 \u0447\u0430\u0441\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u043c \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043d\u0430\u0431\u043e\u0440 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0441 \u043d\u0438\u043c. \u041a\u0430\u043a\u043e\u0439 \u0438\u043c\u0435\u043d\u043d\u043e? \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u0435\u043b\u0430\u0435\u043c \u0443\u043c\u043d\u044b\u0439 \u0440\u043e\u0443\u0442\u0438\u043d\u0433, \u0438\u043b\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434 circuit breaker, \u043c\u043e\u0436\u0435\u043c \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u044b\u0432\u0430\u0442\u044c \u00abcanary deployment\u00bb, \u0447\u0430\u0441\u0442\u0438\u0447\u043d\u043e \u043f\u0435\u0440\u0435\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0440\u0430\u0444\u0438\u043a \u043d\u0430 \u043d\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0441\u0435\u0440\u0432\u0438\u0441\u0430, \u0430 \u043c\u043e\u0436\u0435\u043c \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0438\u0432\u0430\u0442\u044c \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0438 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u043f\u043e\u0445\u043e\u0434\u044b \u0438\u0437 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0432\u043e \u0432\u043d\u0435\u0448\u043d\u044e\u044e \u0441\u0435\u0442\u044c. \u0415\u0441\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0437\u0430\u0434\u0430\u0432\u0430\u0442\u044c policy \u043f\u0440\u0430\u0432\u0438\u043b\u0430 \u0434\u043b\u044f \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f \u043f\u043e\u0445\u043e\u0434\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0440\u0430\u0437\u043d\u044b\u043c\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u0430\u043c\u0438. \u041d\u0430\u043a\u043e\u043d\u0435\u0446, \u043c\u044b \u043c\u043e\u0436\u0435\u043c \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0432\u0441\u044e \u043a\u0430\u0440\u0442\u0443 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u043f\u043e \u0441\u0435\u0442\u0438 \u0438 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0443\u043d\u0438\u0444\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0441\u0431\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e \u0434\u043b\u044f \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439.<\/p>\n

\u00dcber den Mechanismus der Funktionsweise kann man in offiziellen Dokumentation<\/a><\/noindex>. Istio ist tats\u00e4chlich ein leistungsstarkes Werkzeug, das viele Aufgaben und Probleme l\u00f6sen kann. In diesem Artikel m\u00f6chte ich auf die h\u00e4ufigsten Fragen eingehen, die in der Anfangsphase der Arbeit mit Istio auftreten. Das wird Ihnen helfen, schneller damit zurechtzukommen.<\/p>\n

\"Wie
\n<\/a><\/noindex><\/p>\n

Funktionsweise<\/h3>\n

\nIstio besteht aus zwei Hauptbereichen \u2013 Control Plane und Data Plane. Die Control Plane enth\u00e4lt die wichtigsten Komponenten, die den reibungslosen Betrieb der anderen gew\u00e4hrleisten. In der aktuellen Version (1.0) hat die Control Plane drei Hauptkomponenten: Pilot, Mixer, Citadel. Citadel werden wir nicht n\u00e4her betrachten, da es f\u00fcr die Generierung von Zertifikaten zum Schutz der gegenseitigen TLS-Authentifizierung zwischen Diensten erforderlich ist. Lassen Sie uns die Struktur und den Zweck von Pilot und Mixer genauer ansehen.<\/p>\n

\"Wie
\n
\nPilot ist die Hauptsteuerkomponente, die alle Informationen \u00fcber unsere Ressourcen im Cluster \u2013 die Dienste, deren Endpoints und Routing-Regeln (zum Beispiel Regeln f\u00fcr Canary Deployment oder Circuit Breaker-Regeln) \u2013 verbreitet.<\/p>\n

Mixer ist eine optionale Komponente der Control Plane, die die M\u00f6glichkeit bietet, Metriken, Protokolle und jede Art von Informationen \u00fcber die Netzwerkinteraktion zu sammeln. Au\u00dferdem \u00fcberwacht er die Einhaltung von Policy-Regeln und das Einhalten von Ratenbegrenzungen.<\/p>\n

Die Data Plane wird durch Sidecar-Proxy-Container implementiert. Standardm\u00e4\u00dfig wird der leistungsstarke Proxy-Server Envoy<\/a><\/noindex>verwendet. Er kann durch eine andere Implementierung, wie z.B. Nginx (nginmesh), ersetzt werden.<\/p>\n

Damit Istio vollst\u00e4ndig transparent f\u00fcr Anwendungen funktioniert, gibt es ein automatisches Injektionssystem. Die letzte Implementierung ist f\u00fcr Kubernetes-Versionen 1.9+ geeignet (mutational admission webhook). F\u00fcr Kubernetes-Versionen 1.7 und 1.8 besteht die M\u00f6glichkeit, Initializer zu verwenden.<\/p>\n

Sidecar-Container verbinden sich \u00fcber den GRPC-Protokoll mit Pilot, was es erm\u00f6glicht, das Push-Modell von \u00c4nderungen im Cluster zu optimieren. GRPC begann ab Version 1.6 in Envoy verwendet zu werden und wird in Istio seit Version 0.8 eingesetzt und stellt die pilot-agent \u2013 eine Golang-H\u00fclle \u00fcber Envoy, die die Startparameter konfiguriert.<\/p>\n

Pilot und Mixer sind vollst\u00e4ndig stateless Komponenten, alle Zust\u00e4nde werden im Speicher gehalten. Die Konfiguration f\u00fcr sie wird in Form von Kubernetes Custom Resources definiert, die in etcd gespeichert werden.
\nIstio-agent erh\u00e4lt die Adresse von Pilot und \u00f6ffnet einen GRPC-Stream zu ihm. <\/p>\n

Wie bereits erw\u00e4hnt, implementiert Istio die gesamte Funktionalit\u00e4t vollst\u00e4ndig transparent f\u00fcr Anwendungen. Lassen Sie uns verstehen, wie. Der Algorithmus ist folgender:<\/p>\n

    \n
  1. Wir setzen eine neue Version des Dienstes ein.<\/li>\n
  2. Je nach Ansatz des Injecting wird der istio-init Container sowie der istio-agent Container (envoy) w\u00e4hrend der Konfigurationsanwendung hinzugef\u00fcgt, oder sie k\u00f6nnen bereits manuell in die Beschreibung der Kubernetes Pod-Entit\u00e4t eingef\u00fcgt worden sein.<\/li>\n
  3. Der istio-init Container ist ein Skript, das iptables-Regeln f\u00fcr den Pod anwendet. Es gibt zwei Optionen zur Konfiguration der Umleitung des Traffics zum istio-agent Container: entweder redirect iptables-Regeln verwenden, oder TPROXY<\/a><\/noindex>. Zum Zeitpunkt des Schreibens wird standardm\u00e4\u00dfig der Ansatz mit redirect-Regeln verwendet. Im istio-init gibt es die M\u00f6glichkeit festzulegen, welcher Traffic abgefangen und zum istio-agent geleitet werden soll. Zum Beispiel, um gesamten eingehenden und gesamten ausgehenden Traffic abzufangen, m\u00fcssen die Parameter -i<\/code> und -b<\/code> auf den Wert *<\/code>. Bestimmte Ports, die abgefangen werden sollen, k\u00f6nnen angegeben werden. Um ein bestimmtes Subnetz nicht abzufangen, kann dies mit der Option -x<\/code>.<\/li>\n
  4. Nach der Ausf\u00fchrung der Init-Container werden die Hauptcontainer gestartet, einschlie\u00dflich des pilot-agent (envoy). Dieser verbindet sich \u00fcber GRPC mit dem bereits bereitgestellten Pilot und erh\u00e4lt Informationen \u00fcber alle bestehenden Dienste und Routing-Politiken im Cluster. Basierend auf diesen Daten konfiguriert er Cluster und tr\u00e4gt die Endpunkte unserer Anwendungen im Kubernetes-Cluster ein. Ein wichtiger Punkt ist auch, dass envoy dynamisch Listenereinstellungen (IP-Paar, Port) konfiguriert, die er zu lauschen beginnt. Wenn also Anfragen in den Pod gelangen, werden sie durch Umleitung mit iptables-Regeln in den Sidecar geleitet, kann envoy diese Verbindungen erfolgreich verarbeiten und verstehen, wohin der Traffic weitergeleitet werden muss. Zu diesem Zeitpunkt werden auch Informationen an den Mixer gesendet, den wir sp\u00e4ter betrachten werden, sowie die \u00dcbertragung von Tracing-Spans.<\/li>\n<\/ol>\n

    \nAm Ende erhalten wir ein Netzwerk von envoy Proxy-Servern, die wir von einem einzigen Punkt (Pilot) aus konfigurieren k\u00f6nnen. Alle eingehenden und ausgehenden Anfragen laufen \u00fcber envoy. Dabei wird nur TCP-Traffic abgefangen. Das bedeutet, dass die Kubernetes-Service-IP mittels kube-dns \u00fcber UDP ohne Ver\u00e4nderung aufgel\u00f6st wird. Erst nach der Aufl\u00f6sung erfolgt die Abfangung der ausgehenden Anfrage und deren Verarbeitung durch envoy, der dann entscheidet, an welchen Endpunkt die Anfrage gesendet werden soll (oder ob sie nicht gesendet werden soll, im Falle von Zugriffsrichtlinien oder der Aktivierung eines Circuit-Breaker-Algorithmus).<\/p>\n

    Wir haben uns mit Pilot besch\u00e4ftigt, jetzt m\u00fcssen wir verstehen, wie Mixer funktioniert und wof\u00fcr er gebraucht wird. Die offizielle Dokumentation dazu kann gelesen werden. hier<\/a><\/noindex>.<\/p>\n

    Der Mixer besteht in seiner aktuellen Form aus zwei Komponenten: istio-telemetry und istio-policy (bis zur Version 0.8 war dies eine einzige Komponente, istio-mixer). Beide stellen eine Art Mixer dar, wobei jeder f\u00fcr seine spezifische Aufgabe verantwortlich ist. Istio telemetry empf\u00e4ngt \u00fcber GRPC von den Sidecar-Containern Berichtsinformationen dar\u00fcber, wer wohin geht und mit welchen Parametern. Istio-policy erh\u00e4lt Check-Anfragen zur \u00dcberpr\u00fcfung der Einhaltung von Policy-Regeln. Policy-Pr\u00fcfungen werden nat\u00fcrlich nicht f\u00fcr jede Anfrage durchgef\u00fchrt, sondern auf dem Client (im Sidecar) f\u00fcr eine bestimmte Zeit zwischengespeichert. Berichtskontrollen werden in Batchanfragen gesendet. Wie man diese konfiguriert und welche Parameter gesendet werden m\u00fcssen, werden wir gleich sehen. <\/p>\n

    Der Mixer wird als hochverf\u00fcgbare Komponente betrachtet, die den kontinuierlichen Betrieb der Sammlung und Verarbeitung von Telemetriedaten sicherstellt. Am Ende ergibt sich ein mehrschichtiger Puffer. Zun\u00e4chst werden die Daten auf der Seite der Sidecar-Container zwischengespeichert, dann auf der Seite des Mixers und schlie\u00dflich an die sogenannten Mixer-Backends gesendet. Wenn einer der Systemkomponenten ausf\u00e4llt, w\u00e4chst der Puffer, und nach der Wiederherstellung des Systems wird er geleert. Die Mixer-Backends sind Endpunkte f\u00fcr den Versand von Telemetriedaten: statsd, newrelic usw. Man kann ein eigenes Backend schreiben, das ist relativ einfach, und wir werden sehen, wie das geht.<\/p>\n

    \"Wie
    \n
    \nZusammengefasst ist das Schema der Arbeit mit istio-telemetry wie folgt.<\/p>\n

      \n
    1. Dienst 1 sendet eine Anfrage an Dienst 2.<\/li>\n
    2. Beim Verlassen von Dienst 1 wird die Anfrage in seinen eigenen Sidecar gewickelt.<\/li>\n
    3. Der Sidecar Envoy \u00fcberwacht, wie die Anfrage zu Dienst 2 verl\u00e4uft und bereitet die ben\u00f6tigten Informationen vor.<\/li>\n
    4. Dann sendet er diese Informationen an istio-telemetry mit Hilfe einer Berichtsanfrage.<\/li>\n
    5. Istio-telemetry bestimmt, ob dieser Bericht an die Backends gesendet werden muss, an welche genau und welche Daten gesendet werden m\u00fcssen.<\/li>\n
    6. Istio-telemetry sendet Berichtsdaten an das Backend, wenn dies erforderlich ist.<\/li>\n<\/ol>\n

      \nNun schauen wir uns an, wie man ein Istio-System bereitstellt, das nur aus den Hauptkomponenten (Pilot und Sidecar Envoy) besteht.<\/p>\n

      Zun\u00e4chst betrachten wir die grundlegende Konfiguration (Mesh), die der Pilot liest:<\/p>\n

      apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: istio\n  namespace: istio-system\n  labels:\n    app: istio\n    service: istio\ndata:\n  mesh: |-\n\n    # Derzeit aktivieren wir das Senden von Tracing-Informationen nicht (Pilot konfiguriert die Envoys so, dass das Senden nicht erfolgt)\n    enableTracing: false\n\n    # Momentan geben wir keine Mixer-Endpunkte an, damit die Sidecar-Container keine Informationen dorthin senden\n    #mixerCheckServer: istio-policy.istio-system:15004\n    #mixerReportServer: istio-telemetry.istio-system:15004\n\n    # Wir setzen ein zeitliches Intervall, in dem der Envoy den Pilot erneut abfragt (das gilt f\u00fcr die alte Version des Envoy-Proxys)\n    rdsRefreshDelay: 5s\n\n    # Standardkonfiguration f\u00fcr den Envoy Sidecar\n    defaultConfig:\n      # \u00e4hnlich wie rdsRefreshDelay\n      discoveryRefreshDelay: 5s\n\n      # Beibehalten der Standardeinstellungen (Pfad zur Konfiguration und zum Envoy-Bin\u00e4rdatei)\n      configPath: \"\/etc\/istio\/proxy\"\n      binaryPath: \"\/usr\/local\/bin\/envoy\"\n\n      # Standardname des gestarteten Sidecar-Containers (wird z.B. in Dienstnamen beim Senden von Tracing-Spans verwendet)\n      serviceCluster: istio-proxy\n\n      # Zeit, die der Envoy wartet, bevor er alle bestehenden Verbindungen zwangsweise schlie\u00dft\n      drainDuration: 45s\n      parentShutdownDuration: 1m0s\n\n      # Standardm\u00e4\u00dfig werden REDIRECT-Regeln von iptables verwendet. Kann auf TPROXY ge\u00e4ndert werden.\n      #interceptionMode: REDIRECT\n\n      # Port, an dem das Admin-Panel jedes Sidecar-Containers (Envoy) ausgef\u00fchrt wird\n      proxyAdminPort: 15000\n\n      # Adresse, an die die Traces \u00fcber das Zipkin-Protokoll gesendet werden (anfangs haben wir das Senden selbst deaktiviert, daher wird dieses Feld derzeit nicht verwendet)\n      zipkinAddress: tracing-collector.tracing:9411\n\n      # statsd-Adresse zum Senden von Metriken der Envoy-Container (deaktiviert)\n      # statsdUdpAddress: aggregator:8126\n\n      # Unterst\u00fctzung f\u00fcr Mutual TLS wird deaktiviert\n      controlPlaneAuthPolicy: NONE\n\n      # Adresse, an der der istio-pilot lauscht, um Informationen \u00fcber die Service-Entdeckung an alle Sidecar-Container zu \u00fcbertragen\n      discoveryAddress: istio-pilot.istio-system:15007\n<\/code><\/pre>\n
      \nAlle wichtigen Steuerungskomponenten (Control Plane) platzieren wir im Namespace istio-system in Kubernetes.<\/p>\n
      Mindestens m\u00fcssen wir nur den Pilot bereitstellen. Daf\u00fcr verwenden wir diese Konfiguration.<\/a><\/noindex><\/p>\n
      Und konfigurieren manuell das Injizieren des Sidecar-Containers.<\/p>\n
      Init-Container:<\/p>\n
      initContainers:\n - name: istio-init\n   args:\n   - -p\n   - \"15001\"\n   - -u\n   - \"1337\"\n   - -m\n   - REDIRECT\n   - -i\n   - '*'\n   - -b\n   - '*'\n   - -d\n   - \"\"\n   image: istio\/proxy_init:1.0.0\n   imagePullPolicy: IfNotPresent\n   resources:\n     limits:\n       memory: 128Mi\n   securityContext:\n     capabilities:\n       add:\n       - NET_ADMIN\n<\/code><\/pre>\n
      \nUnd Sidecar:<\/p>\n
             name: istio-proxy\n       args:\n         - \"bash\"\n         - \"-c\"\n         - |\n           exec \/usr\/local\/bin\/pilot-agent proxy sidecar \n           --configPath \n           \/etc\/istio\/proxy \n           --binaryPath \n           \/usr\/local\/bin\/envoy \n           --serviceCluster \n           service-name \n           --drainDuration \n           45s \n           --parentShutdownDuration \n           1m0s \n           --discoveryAddress \n           istio-pilot.istio-system:15007 \n           --discoveryRefreshDelay \n           1s \n           --connectTimeout \n           10s \n           --proxyAdminPort \n           \"15000\" \n           --controlPlaneAuthPolicy \n           NONE\n         env:\n         - name: POD_NAME\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.name\n         - name: POD_NAMESPACE\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.namespace\n         - name: INSTANCE_IP\n           valueFrom:\n             fieldRef:\n               fieldPath: status.podIP\n         - name: ISTIO_META_POD_NAME\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.name\n         - name: ISTIO_META_INTERCEPTION_MODE\n           value: REDIRECT\n         image: istio\/proxyv2:1.0.0\n         imagePullPolicy: IfNotPresent\n         resources:\n           requests:\n             cpu: 100m\n             memory: 128Mi\n           limits:\n             memory: 2048Mi\n         securityContext:\n           privileged: false\n           readOnlyRootFilesystem: true\n           runAsUser: 1337\n         volumeMounts:\n         - mountPath: \/etc\/istio\/proxy\n           name: istio-envoy\n<\/code><\/pre>\n
      \nUm alles erfolgreich zu starten, muss ein ServiceAccount, ClusterRole, ClusterRoleBinding und CRD f\u00fcr Pilot eingerichtet werden, deren Beschreibungen zu finden sind. hier<\/a><\/noindex>. <\/p>\n
      Schlie\u00dflich muss der Dienst, in den wir den Sidecar mit envoy injizieren, erfolgreich gestartet werden, um alle Entdeckungen von Pilot zu erhalten und Anfragen zu bearbeiten.<\/p>\n
      Es ist wichtig zu verstehen, dass alle Komponenten des Control Plane zustandslose Anwendungen sind und problemlos horizontal skaliert werden k\u00f6nnen. Alle Daten liegen in etcd in Form von benutzerdefinierten Kubernetes-Ressourcebeschreibungen vor.<\/p>\n
      Au\u00dferdem hat Istio (noch experimentell) die M\u00f6glichkeit, au\u00dferhalb des Clusters zu laufen und Service Discovery zwischen mehreren Kubernetes-Clustern zu betrachten und zu teilen. Mehr dazu kann man lesen. hier<\/a><\/noindex>.<\/p>\n
      Bei der Multicluster-Installation sind die folgenden Einschr\u00e4nkungen zu beachten:<\/p>\n
        \n
      1. Pod CIDR und Service CIDR m\u00fcssen \u00fcber alle Cluster einzigartig sein und d\u00fcrfen sich nicht \u00fcberschneiden.<\/li>\n
      2. Alle Pod CIDR m\u00fcssen von allen Pod CIDR zwischen den Clustern erreichbar sein.<\/li>\n
      3. Alle Kubernetes API-Server m\u00fcssen einander erreichbar sein.<\/li>\n<\/ol>\n
        \nDies sind die grundlegenden Informationen, die Ihnen den Einstieg in Istio erleichtern. Allerdings gibt es noch viele weitere Fallstricke. Zum Beispiel die Besonderheiten des Routings von externem Verkehr (au\u00dferhalb des Clusters), Ans\u00e4tze zur Fehlersuche bei Sidecars, Profiling, Konfiguration des Mixers und die Erstellung einer benutzerdefinierten Mixer-Backend, Konfiguration von Tracing-Mechanismen und deren Funktion mit envoy.
        \nAll dies werden wir in den n\u00e4chsten Ver\u00f6ffentlichungen behandeln. Stellen Sie Ihre Fragen, ich werde versuchen, sie zu beantworten.
        \n
        Quelle:         habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
        \u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 Istio? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e. \u041c\u044b \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u044b\u0432\u0430\u0435\u043c \u0432\u0435\u0441\u044c \u0438\u043b\u0438 \u0447\u0430\u0441\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u043c \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043d\u0430\u0431\u043e\u0440 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0441 \u043d\u0438\u043c. \u041a\u0430\u043a\u043e\u0439 \u0438\u043c\u0435\u043d\u043d\u043e? \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u0435\u043b\u0430\u0435\u043c \u0443\u043c\u043d\u044b\u0439 \u0440\u043e\u0443\u0442\u0438\u043d\u0433, \u0438\u043b\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434 circuit breaker, \u043c\u043e\u0436\u0435\u043c \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u044b\u0432\u0430\u0442\u044c \u00abcanary deployment\u00bb, \u0447\u0430\u0441\u0442\u0438\u0447\u043d\u043e \u043f\u0435\u0440\u0435\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0440\u0430\u0444\u0438\u043a \u043d\u0430 \u043d\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0441\u0435\u0440\u0432\u0438\u0441\u0430, \u0430 \u043c\u043e\u0436\u0435\u043c \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0438\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24545,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32766","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\udd47Wie man Istio mit Kubernetes in der Produktion startet. Teil 1 | ProHoster","description":"Was ist Istio? Es handelt sich um ein sogenanntes Service-Mesh, eine Technologie, die eine Abstraktionsschicht \u00fcber das Netzwerk hinzuf\u00fcgt.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","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\u041a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c Istio, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f Kubernetes \u0432 production. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 Istio? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","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":"2019-10-31T18:48:48+00:00","article:modified_time":"2019-10-31T18:48:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32766","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-21 12:27:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:53:24","updated":"2026-01-21 12:27: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\/32766","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=32766"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32766\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/24545"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=32766"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=32766"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=32766"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}