Was ist
Istio ? Dies ist das sogenannte Service-Mesh, eine Technologie, die eine Abstraktionsebene über das Netzwerk hinzufügt. Wir fangen den gesamten oder einen Teil des Datenverkehrs im Cluster ab und führen damit eine bestimmte Reihe von Vorgängen aus. Welcher genau? Zum Beispiel führen wir intelligentes Routing durch oder implementieren den Leistungsschalter-Ansatz. Wir können eine „kanarische Bereitstellung“ organisieren, den Verkehr teilweise auf eine neue Version des Dienstes umschalten, externe Interaktionen begrenzen und alle Fahrten vom Cluster zum externen Netzwerk steuern. Es ist möglich, Richtlinienregeln für die Steuerung von Kampagnen zwischen verschiedenen Microservices festzulegen. Schließlich können wir die gesamte Karte der Interaktion über das Netzwerk abrufen und die einheitliche Sammlung von Metriken für Anwendungen vollständig transparent machen.
Informationen zum Arbeitsmechanismus finden Sie in der
offiziellen Dokumentation . Istio ist ein wirklich mächtiges Werkzeug, das viele Probleme und Probleme lösen kann. In diesem Artikel möchte ich die grundlegenden Fragen beantworten, die normalerweise zu Beginn der Arbeit mit Istio auftreten. Dies wird Ihnen helfen, schneller damit umzugehen.
Arbeitsprinzip
Istio besteht aus zwei Hauptzonen - Steuerebene und Datenebene. Die Steuerebene enthält die Hauptkomponenten, die den korrekten Betrieb des Restes gewährleisten. In der aktuellen Version (1.0) besteht die Steuerebene aus drei Hauptkomponenten: Pilot, Mixer, Citadel. Wir werden Citadel nicht berücksichtigen. Es ist erforderlich, Zertifikate zu generieren, um die gegenseitige TLS zwischen den Diensten sicherzustellen. Schauen wir uns das Gerät und den Zweck von Pilot und Mixer genauer an.
Pilot ist die Hauptsteuerungskomponente, die alle Informationen über das, was wir im Cluster haben, verbreitet - Dienste, ihre Endpunkte und Routing-Regeln (z. B. Regeln für die kanarische Bereitstellung oder Regeln für Leistungsschalter).
Mixer - eine optionale Komponente der Steuerebene, mit der Metriken, Protokolle und Informationen zu Netzwerkinteraktionen erfasst werden können. Er überwacht auch die Einhaltung der Richtlinienregeln und die Einhaltung der Tariflimits.
Die Datenebene wird mithilfe von Sidecar-Proxy-Containern implementiert. Standardmäßig wird der leistungsstarke
Envoy-Proxy-Server verwendet . Es kann durch eine andere Implementierung ersetzt werden, z. B. nginx (nginmesh).
Damit Istio für Anwendungen vollständig transparent arbeitet, gibt es ein automatisches Injektionssystem. Die neueste Implementierung eignet sich für Versionen von Kubernetes 1.9+ (Mutation Admission Webhook). Für Kubernetes-Versionen 1.7, 1.8 ist es möglich, den Initializer zu verwenden.
Beiwagencontainer sind über das GRPC-Protokoll mit dem Piloten verbunden, wodurch das Modell zum Übertragen der im Cluster auftretenden Änderungen optimiert werden kann. GRPC wurde in Envoy seit Version 1.6 verwendet, in Istio seit Version 0.8 und ist ein Pilot-Agent - ein Wrapper auf Golang over Envoy, der Startparameter konfiguriert.
Pilot und Mixer sind vollständig zustandslose Komponenten, der gesamte Status wird gespeichert. Die Konfiguration für sie wird als Kubernetes Custom Resources angegeben, die in etcd gespeichert werden.
Istio-Agent empfängt die Pilotadresse und öffnet einen GRPC-Stream.
Wie gesagt, Istio implementiert alle Funktionen, die für Anwendungen vollständig transparent sind. Lassen Sie uns herausfinden, wie. Der Algorithmus ist wie folgt:
- Stellen Sie eine neue Version des Dienstes bereit.
- Abhängig vom Ansatz des Injizierens des Beiwagencontainers werden in der Phase der Konfigurationsanwendung ein Istio-Init-Container und ein Istio-Agent-Container (Gesandter) hinzugefügt oder können bereits manuell in die Pod-Beschreibung der Kubernetes-Entität eingefügt werden.
- Der istio-init-Container ist ein Skript, das die iptables-Regeln für den Herd anwendet. Es gibt zwei Optionen zum Einrichten des Traffic Wrapping im Istio-Agent-Container: Verwenden Sie die Redirect Iptables-Regeln oder TPROXY . Zum Zeitpunkt des Schreibens wird der Standardansatz mit Umleitungsregeln verwendet. In istio-init kann konfiguriert werden, welcher Datenverkehr abgefangen und an istio-agent weitergeleitet werden muss. Um beispielsweise den gesamten eingehenden und ausgehenden Datenverkehr abzufangen, müssen Sie die Parameter
-i und -b auf * . Sie können bestimmte Ports angeben, die abgefangen werden sollen. Um ein bestimmtes Subnetz nicht abzufangen, können Sie es mit dem Flag -x angeben. - Nach der Ausführung von Init-Containern werden die wichtigsten gestartet, einschließlich Pilot-Agent (Gesandter). Es stellt über GRPC eine Verbindung zum bereits bereitgestellten Piloten her und empfängt Informationen zu allen vorhandenen Diensten und Routing-Richtlinien im Cluster. Entsprechend den empfangenen Daten konfiguriert er die Cluster und weist ihnen direkt die Endpunkte unserer Anwendungen im Kubernetes-Cluster zu. Es ist auch erwähnenswert, dass der Gesandte die Listener (IP, Port-Paare), die er abhört, dynamisch einrichtet. Wenn Anforderungen in den Pod eingegeben werden, werden sie daher mithilfe der Regeln für die Umleitung von iptables im Beiwagen umgeleitet. Envoy kann diese Verbindungen bereits erfolgreich verarbeiten und verstehen, wo der Datenverkehr weiter weitergeleitet werden soll. Auch in dieser Phase werden Informationen an den Mixer gesendet, auf die wir später noch eingehen werden, und es werden Ablaufverfolgungsbereiche gesendet.
Als Ergebnis erhalten wir ein ganzes Netzwerk von Gesandten-Proxy-Servern, die wir von einem Punkt aus konfigurieren können (Pilot). Alle eingehenden und ausgehenden Anfragen werden vom Gesandten bearbeitet. Darüber hinaus wird nur TCP-Verkehr abgefangen. Dies bedeutet, dass die IP-Adresse des Kubernetes-Dienstes mithilfe von kube-dns über UDP aufgelöst wird, ohne dass Änderungen vorgenommen werden. Nach dem Auflösen wird die ausgehende Anforderung abgefangen und vom Gesandten verarbeitet, der bereits entscheidet, an welchen Endpunkt die Anforderung gesendet werden soll (oder nicht, im Fall von Zugriffsrichtlinien oder Auslösen von Leistungsschalteralgorithmen).
Wenn Pilot aussortiert ist, müssen Sie jetzt verstehen, wie der Mixer funktioniert und warum er benötigt wird. Die offizielle Dokumentation dazu finden Sie
hier .
Der Mixer in seiner aktuellen Form besteht aus zwei Komponenten: Istio-Telemetrie, Istio-Policy (vor Version 0.8 war er eine Komponente von Istio-Mixer). Beide sind Mischer, von denen jeder für seine Aufgabe verantwortlich ist. Istio Telemetry empfängt über GRPC vom Beiwagen Report Container Informationen darüber, wer wohin und mit welchen Parametern fährt. Istio-policy akzeptiert Überprüfungsanforderungen, um zu überprüfen, ob die Richtlinienregeln erfüllt sind. Poilicy-Checks werden natürlich nicht für jede Anfrage durchgeführt, sondern für eine bestimmte Zeit auf dem Client (im Beiwagen) zwischengespeichert. Berichtsprüfungen werden per Stapelanforderung gesendet. Wir werden etwas später sehen, wie Sie konfigurieren und welche Parameter Sie senden müssen.
Mixer soll eine hochverfügbare Komponente sein, die ununterbrochene Arbeit an der Erfassung und Verarbeitung von Telemetriedaten ermöglicht. Das System entpuppt sich als mehrstufiger Puffer. Zunächst werden die Daten auf der Seitenwagenseite der Container, dann auf der Mischerseite gepuffert und dann an die sogenannten Mischer-Backends gesendet. Wenn eine der Systemkomponenten ausfällt, wächst der Puffer und stürzt nach der Systemwiederherstellung ab. Mixer-Backends sind die Endpunkte für das Senden von Telemetriedaten: statsd, newrelic usw. Sie können Ihr Backend schreiben, es ist ganz einfach, und wir werden sehen, wie es geht.
Zusammenfassend ist das Arbeitsschema mit Istio-Telemetrie wie folgt.
- Dienst 1 sendet eine Anfrage an Dienst 2.
- Beim Verlassen von Service 1 wird die Anfrage in einen eigenen Beiwagen verpackt.
- Der Sidecar-Gesandte überwacht, wie die Anforderung für Service 2 weitergeleitet wird, und bereitet die erforderlichen Informationen vor.
- Anschließend wird es mithilfe der Berichtsanforderung an istio-telemetry gesendet.
- Istio-Telemetrie bestimmt, ob dieser Bericht an Backends gesendet werden soll, an welche Daten und welche Daten gesendet werden sollen.
- Istio-Telemetrie sendet bei Bedarf Berichtsdaten an das Backend.
Lassen Sie uns nun sehen, wie das Istio-System bereitgestellt wird, das nur aus den Hauptkomponenten besteht (Pilot und Beiwagen-Gesandter).
Schauen wir uns zunächst die Hauptkonfiguration (Mesh) an, die Pilot liest:
apiVersion: v1 kind: ConfigMap metadata: name: istio namespace: istio-system labels: app: istio service: istio data: mesh: |- # tracing (pilot envoy' , ) enableTracing: false # mixer endpoint', sidecar #mixerCheckServer: istio-policy.istio-system:15004 #mixerReportServer: istio-telemetry.istio-system:15004 # , envoy Pilot ( envoy proxy) rdsRefreshDelay: 5s # default envoy sidecar defaultConfig: # rdsRefreshDelay discoveryRefreshDelay: 5s # ( envoy) configPath: "/etc/istio/proxy" binaryPath: "/usr/local/bin/envoy" # sidecar (, , tracing span') serviceCluster: istio-proxy # , envoy , drainDuration: 45s parentShutdownDuration: 1m0s # REDIRECT iptables. TPROXY. #interceptionMode: REDIRECT # , admin sidecar (envoy) proxyAdminPort: 15000 # , trace' zipkin ( , ) zipkinAddress: tracing-collector.tracing:9411 # statsd envoy () # statsdUdpAddress: aggregator:8126 # Mutual TLS controlPlaneAuthPolicy: NONE # , istio-pilot , service discovery sidecar discoveryAddress: istio-pilot.istio-system:15007
Alle Hauptkomponenten der Steuerebene befinden sich im Namespace istio-system in Kubernetes.
Zumindest müssen wir nur Pilot bereitstellen. Dazu verwenden wir
diese Konfiguration.Und konfigurieren Sie den einspritzenden Beiwagen des Containers manuell.
Init Container:
initContainers: - name: istio-init args: - -p - "15001" - -u - "1337" - -m - REDIRECT - -i - '*' - -b - '*' - -d - "" image: istio/proxy_init:1.0.0 imagePullPolicy: IfNotPresent resources: limits: memory: 128Mi securityContext: capabilities: add: - NET_ADMIN
Und Beiwagen:
name: istio-proxy args: - "bash" - "-c" - | exec /usr/local/bin/pilot-agent proxy sidecar \ --configPath \ /etc/istio/proxy \ --binaryPath \ /usr/local/bin/envoy \ --serviceCluster \ service-name \ --drainDuration \ 45s \ --parentShutdownDuration \ 1m0s \ --discoveryAddress \ istio-pilot.istio-system:15007 \ --discoveryRefreshDelay \ 1s \ --connectTimeout \ 10s \ --proxyAdminPort \ "15000" \ --controlPlaneAuthPolicy \ NONE env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: INSTANCE_IP valueFrom: fieldRef: fieldPath: status.podIP - name: ISTIO_META_POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: ISTIO_META_INTERCEPTION_MODE value: REDIRECT image: istio/proxyv2:1.0.0 imagePullPolicy: IfNotPresent resources: requests: cpu: 100m memory: 128Mi limits: memory: 2048Mi securityContext: privileged: false readOnlyRootFilesystem: true runAsUser: 1337 volumeMounts: - mountPath: /etc/istio/proxy name: istio-envoy
Damit alles erfolgreich gestartet werden kann, benötigen Sie ServiceAccount, ClusterRole, ClusterRoleBinding und CRD for Pilot. Beschreibungen dazu finden Sie
hier .
Infolgedessen sollte der Dienst, in den wir den Beiwagen mit Gesandten injizieren, erfolgreich gestartet werden, alle Entdeckungen vom Piloten erhalten und die Anforderungen verarbeiten.
Es ist wichtig zu verstehen, dass alle Komponenten der Steuerebene zustandslose Anwendungen sind und problemlos horizontal skaliert werden können. Alle Daten sind in etcd als benutzerdefinierte Beschreibungen der Kubernetes-Ressourcen enthalten.
Istio hat auch (bisher experimentell) die Fähigkeit, außerhalb des Clusters zu laufen und die Serviceerkennung zwischen mehreren Kubernetes-Clustern zu überwachen und zu durchsuchen. Mehr dazu lesen Sie
hier .
Bei einer Installation mit mehreren Clustern sollten die folgenden Einschränkungen berücksichtigt werden:
- Pod CIDR und Service CIDR müssen über alle Cluster hinweg eindeutig sein und dürfen sich nicht überschneiden.
- Alle Pod-CIDRs müssen von allen Pod-CIDRs zwischen Clustern verfügbar sein.
- Alle Kubernetes-API-Server müssen für einander zugänglich sein.
Dies sind die ersten Informationen, die Ihnen den Einstieg in Istio erleichtern. Es gibt jedoch immer noch viele Fallstricke. Zum Beispiel Funktionen zum Weiterleiten von externem Datenverkehr (an die Außenseite des Clusters), zum Debuggen von Beiwagen, zur Profilerstellung, zum Einrichten eines Mixers und zum Schreiben eines benutzerdefinierten Mixer-Backends, zum Einrichten eines Ablaufverfolgungsmechanismus und dessen Betrieb mithilfe von Envoy.
Wir werden dies alles in den folgenden Veröffentlichungen betrachten. Stellen Sie Ihre Fragen, ich werde versuchen, sie zu behandeln.