Wat ? Dit is de zogenaamde Service mesh, een technologie die een abstractielaag over het netwerk heen legt. We onderscheppen het verkeer in het cluster geheel of gedeeltelijk en voeren er een bepaalde set handelingen mee uit. Welke? We doen bijvoorbeeld aan slimme routering, of we implementeren de aanpak van stroomonderbrekers, we kunnen “canary deployment” organiseren, verkeer gedeeltelijk overzetten naar een nieuwe versie van de dienst, of we kunnen externe interacties beperken en alle ritten van het cluster naar de extern netwerk. Het is mogelijk om beleidsregels in te stellen om trips tussen verschillende microservices te regelen. Ten slotte kunnen we de volledige netwerkinteractiekaart krijgen en de uniforme verzameling statistieken volledig transparant maken voor applicaties.
U kunt lezen over het werkingsmechanisme in . Istio is een echt krachtige tool waarmee je veel taken en problemen kunt oplossen. In dit artikel wil ik de belangrijkste vragen beantwoorden die meestal opkomen als je aan de slag gaat met Istio. Dit zal je helpen om er sneller mee om te gaan.
Werking
Istio bestaat uit twee hoofdgebieden: het besturingsvlak en het gegevensvlak. Het besturingsvlak bevat de belangrijkste componenten die zorgen voor de juiste werking van de rest. In de huidige versie (1.0) heeft het besturingsvlak drie hoofdcomponenten: Pilot, Mixer, Citadel. We zullen Citadel niet overwegen, het is nodig om certificaten te genereren om wederzijdse TLS tussen services te garanderen. Laten we het apparaat en het doel van Pilot en Mixer eens nader bekijken.
Pilot is de belangrijkste besturingscomponent die alle informatie verspreidt over wat we in het cluster hebben - services, hun eindpunten en routeringsregels (bijvoorbeeld regels voor Canary-implementatie of regels voor stroomonderbrekers).
Mixer is een optionele besturingsvlakcomponent die de mogelijkheid biedt om metrische gegevens, logboeken en alle informatie over netwerkinteractie te verzamelen. Ook ziet hij toe op de naleving van de Beleidsregels en de naleving van tarieflimieten.
Het gegevensvlak wordt geïmplementeerd met behulp van sidecar proxy-containers. Krachtig wordt standaard gebruikt. . Het kan worden vervangen door een andere implementatie, zoals nginx (nginmesh).
Om Istio volledig transparant te laten werken voor toepassingen, is er een automatisch injectiesysteem. De nieuwste implementatie is geschikt voor Kubernetes 1.9+ versies (mutational Admission webhook). Voor Kubernetes versies 1.7, 1.8 is het mogelijk om de Initializer te gebruiken.
Sidecar-containers zijn via het GRPC-protocol verbonden met Pilot, waarmee u het pushmodel kunt optimaliseren voor wijzigingen die zich in het cluster voordoen. GRPC wordt gebruikt in Envoy sinds versie 1.6, in Istio wordt het gebruikt sinds versie 0.8 en is het een pilot-agent - een golang wrapper over gezant die startopties configureert.
Pilot en Mixer zijn volledig stateless componenten, alle status wordt in het geheugen bewaard. De configuratie voor hen wordt ingesteld in de vorm van Kubernetes Custom Resources, die worden opgeslagen in etcd.
Istio-agent krijgt het adres van de piloot en opent er een GRPC-stream naar.
Zoals ik al zei, implementeert Istio alle functionaliteit volledig transparant voor applicaties. Laten we eens kijken hoe. Het algoritme is dit:
- Een nieuwe versie van de service implementeren.
- Afhankelijk van de aanpak voor het injecteren van zijspancontainers, worden de istio-init-container en de istio-agent-container (gezant) toegevoegd tijdens het toepassen van de configuratie, of kunnen ze al handmatig worden ingevoegd in de beschrijving van de Kubernetes Pod-entiteit.
- De istio-init-container is een script dat de iptables-regels toepast op de pod. Er zijn twee opties voor het configureren van verkeer dat in een istio-agent-container moet worden verpakt: gebruik iptables-omleidingsregels of . Op het moment van schrijven is de standaardbenadering met omleidingsregels. In istio-init is het mogelijk om te configureren welk verkeer moet worden onderschept en naar istio-agent moet worden gestuurd. Om bijvoorbeeld al het inkomende en uitgaande verkeer te onderscheppen, moet u de parameters instellen
-iи-bin betekenis*. U kunt specifieke poorten specificeren om te onderscheppen. Om een specifiek subnet niet te onderscheppen, kunt u dit specificeren met behulp van de vlag-x. - Nadat de init-containers zijn uitgevoerd, worden de belangrijkste gelanceerd, inclusief de piloot-agent (gezant). Het maakt verbinding met de reeds geïmplementeerde Pilot via GRPC en ontvangt informatie over alle bestaande services en routeringsbeleid in het cluster. Aan de hand van de ontvangen data configureert hij de clusters en wijst deze direct toe aan de endpoints van onze applicaties in het Kubernetes-cluster. Het is ook noodzakelijk om een belangrijk punt op te merken: gezant configureert dynamisch luisteraars (IP, poortparen) waarnaar het begint te luisteren. Daarom, wanneer verzoeken de pod binnenkomen en worden omgeleid met behulp van de omleidings-iptables-regels in de sidecar, kan gezant deze verbindingen al met succes verwerken en begrijpen waar het verkeer verder moet worden geproxyeerd. Ook in dit stadium wordt er informatie naar de Mixer gestuurd, die we later zullen bekijken, en worden traceerbereiken verzonden.
Hierdoor krijgen we een heel netwerk van gezant-proxyservers die we vanuit één punt (Pilot) kunnen configureren. Alle inkomende en uitgaande verzoeken gaan via gezant. Bovendien wordt alleen TCP-verkeer onderschept. Dit betekent dat het IP-adres van de Kubernetes-service wordt opgelost met behulp van kube-dns via UDP zonder te wijzigen. Vervolgens, na het oplossen, wordt het uitgaande verzoek onderschept en verwerkt door de gezant, die al beslist naar welk eindpunt het verzoek moet worden verzonden (of niet verzonden, in het geval van toegangsbeleid of de stroomonderbreker van het algoritme).
We hebben Pilot ontdekt, nu moeten we begrijpen hoe Mixer werkt en waarom het nodig is. U kunt de officiële documentatie ervoor lezen .
Mixer in zijn huidige vorm bestaat uit twee componenten: istio-telemetrie, istio-policy (vóór versie 0.8 was het één istio-mixer-component). Beiden zijn mixers, die elk verantwoordelijk zijn voor hun eigen taak. Istio-telemetrie ontvangt informatie over wie waar naartoe gaat en met welke parameters uit sidecar Report-containers via GRPC. Istio-policy accepteert controleverzoeken om te controleren of aan de beleidsregels wordt voldaan. Poilicy-checks worden natuurlijk niet voor elk verzoek uitgevoerd, maar worden voor een bepaalde tijd op de client (in het zijspan) gecached. Rapportcontroles worden verzonden als batchaanvragen. Laten we eens kijken hoe te configureren en welke parameters iets later moeten worden verzonden.
De Mixer wordt verondersteld een zeer beschikbare component te zijn die zorgt voor ononderbroken werk aan de assemblage en verwerking van telemetriegegevens. Het systeem wordt als resultaat verkregen als een buffer met meerdere niveaus. In eerste instantie wordt data gebufferd aan de zijspanzijde van containers, vervolgens aan de mixerzijde en vervolgens naar de zogenaamde mixer-backends gestuurd. Als gevolg hiervan, als een van de systeemcomponenten uitvalt, groeit de buffer en wordt deze leeggemaakt nadat het systeem is hersteld. Mixer-backends zijn eindpunten voor het verzenden van telemetriegegevens: statsd, newrelic, etc. U kunt uw eigen backend schrijven, het is vrij eenvoudig, en we zullen zien hoe we het moeten doen.
Samenvattend is het schema voor het werken met istio-telemetrie als volgt.
- Dienst 1 stuurt een verzoek naar dienst 2.
- Bij het verlaten van dienst 1 wordt de aanvraag in een eigen zijspan gewikkeld.
- Zijspangezant monitort hoe de aanvraag naar dienst 2 gaat en bereidt de nodige informatie voor.
- Stuurt het vervolgens naar istio-telemetrie met behulp van een rapportverzoek.
- Istio-telemetrie bepaalt of dit rapport naar de backends moet worden gestuurd, naar welke en welke gegevens moeten worden verzonden.
- Istio-telemetrie verzendt indien nodig rapportgegevens naar de backend.
Laten we nu eens kijken hoe Istio in het systeem kan worden geïmplementeerd, dat alleen uit de hoofdcomponenten bestaat (piloot en zijspangezant).
Laten we eerst eens kijken naar de hoofdconfiguratie (mesh) die Pilot leest:
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 belangrijke besturingscomponenten (besturingsvlak) bevinden zich in het naamruimte istio-systeem in Kubernetes.
We hoeven minimaal alleen Pilot in te zetten. Hiervoor gebruiken we
En we zullen het injecterende zijspan van de container handmatig configureren.
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
En zijspan:
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
Om alles succesvol te laten starten, moet u een ServiceAccount, ClusterRole, ClusterRoleBinding, CRD voor Pilot maken, waarvan de beschrijvingen te vinden zijn .
Als gevolg hiervan zou de service waarin we zijspan met gezant injecteren, succesvol moeten starten, alle ontdekkingen van de piloot ontvangen en verzoeken verwerken.
Het is belangrijk om te begrijpen dat alle componenten van het besturingsvlak stateless applicaties zijn en zonder problemen horizontaal kunnen worden geschaald. Alle gegevens worden opgeslagen in etcd in de vorm van aangepaste beschrijvingen van Kubernetes-bronnen.
Istio (nog steeds experimenteel) heeft ook de mogelijkheid om buiten het cluster te draaien en de mogelijkheid om service-ontdekking tussen verschillende Kubernetes-clusters te bekijken en te bekijken. U kunt hier meer over lezen .
Houd bij een installatie met meerdere clusters rekening met de volgende beperkingen:
- Pod-CIDR en Service-CIDR moeten uniek zijn in alle clusters en mogen elkaar niet overlappen.
- Alle CIDR-pods moeten toegankelijk zijn vanaf alle CIDR-pods tussen clusters.
- Alle Kubernetes API-servers moeten voor elkaar toegankelijk zijn.
Dit is de eerste informatie om u op weg te helpen met Istio. Er zijn echter nog veel valkuilen. Bijvoorbeeld functies voor het routeren van extern verkeer (buiten het cluster), benaderingen voor het debuggen van sidecars, profilering, het opzetten van een mixer en het schrijven van een aangepaste mixer-backend, het opzetten van een traceermechanisme en de werking ervan met behulp van envoy.
Dit alles zullen we in de volgende publicaties bespreken. Stel uw vragen, ik zal proberen ze te behandelen.
Bron: www.habr.com