što ? Ovo je takozvani Service mesh, tehnologija koja dodaje sloj apstrakcije preko mreže. Presretamo cijeli ili dio prometa u klasteru i s njim izvodimo određeni skup operacija. Koji? Na primjer, radimo pametno usmjeravanje, ili implementiramo pristup prekidača, možemo organizirati "canary implementaciju", djelomično prebacujući promet na novu verziju usluge, ili možemo ograničiti vanjske interakcije i kontrolirati sva putovanja od klastera do vanjska mreža. Moguće je postaviti pravila pravila za kontrolu putovanja između različitih mikroservisa. Konačno, možemo dobiti cijelu mapu mrežne interakcije i učiniti objedinjenu zbirku metrika potpuno transparentnom za aplikacije.
O mehanizmu rada možete pročitati u . Istio je stvarno moćan alat koji vam omogućuje rješavanje mnogih zadataka i problema. U ovom članku želio bih odgovoriti na glavna pitanja koja se obično javljaju kada počnete koristiti Istio. To će vam pomoći da se brže nosite s tim.
Princip rada
Istio se sastoji od dva glavna područja - kontrolne ravnine i podatkovne ravnine. Kontrolna ravnina sadrži glavne komponente koje osiguravaju ispravan rad ostatka. U trenutnoj verziji (1.0) upravljačka ravnina ima tri glavne komponente: Pilot, Mikser, Citadela. Nećemo razmatrati Citadel, potrebno je generirati certifikate kako bi se osigurao međusobni TLS između usluga. Pogledajmo pobliže uređaj i svrhu Pilota i Miksera.
Pilot je glavna kontrolna komponenta koja distribuira sve informacije o tome što imamo u klasteru - usluge, njihove krajnje točke i pravila usmjeravanja (na primjer, pravila za Canary implementaciju ili pravila za prekidače).
Mikser je izborna komponenta kontrolne ravnine koja pruža mogućnost prikupljanja metrike, zapisa i svih informacija o mrežnoj interakciji. Također nadzire usklađenost s pravilima Politike i usklađenost s ograničenjima stopa.
Podatkovna ravnina implementirana je pomoću bočnih proxy spremnika. Snažan se koristi prema zadanim postavkama. . Može se zamijeniti drugom implementacijom, kao što je nginx (nginmesh).
Kako bi Istio radio potpuno transparentno za aplikacije, tu je sustav automatskog ubrizgavanja. Najnovija implementacija prikladna je za verzije Kubernetesa 1.9+ (mutacijski mrežni dojavnik). Za Kubernetes verzije 1.7, 1.8 moguće je koristiti Initializer.
Sidecar kontejneri povezani su s Pilotom pomoću GRPC protokola, koji vam omogućuje optimizaciju push modela za promjene koje se događaju u klasteru. GRPC se koristi u Envoyu od verzije 1.6, u Istiu se koristi od verzije 0.8 i pilot je agent - golang omotač preko envoya koji konfigurira opcije pokretanja.
Pilot i Mixer su komponente bez stanja, sva stanja se čuvaju u memoriji. Konfiguracija za njih postavljena je u obliku Kubernetes Custom Resources, koji su pohranjeni u itd.
Istio-agent dobiva adresu pilota i otvara joj GRPC tok.
Kao što sam rekao, Istio implementira sve funkcionalnosti potpuno transparentne za aplikacije. Da vidimo kako. Algoritam je ovaj:
- Uvođenje nove verzije usluge.
- Ovisno o pristupu ubacivanja spremnika bočne prikolice, spremnik istio-init i spremnik istio-agent (envoy) dodaju se u fazi primjene konfiguracije ili se već mogu ručno umetnuti u opis entiteta Kubernetes Pod.
- Spremnik istio-init je skripta koja primjenjuje pravila iptables na pod. Postoje dvije opcije za konfiguriranje prometa tako da bude omotan u spremnik istio-agenta: korištenje iptables pravila preusmjeravanja ili . U vrijeme pisanja, zadani pristup je s pravilima preusmjeravanja. U istio-init-u moguće je konfigurirati koji promet treba presresti i poslati istio-agentu. Na primjer, da biste presreli sav dolazni i sav odlazni promet, morate postaviti parametre
-iи-bu vrijednosti*. Možete odrediti određene portove za presretanje. Kako ne biste presreli određenu podmrežu, možete je odrediti pomoću zastavice-x. - Nakon što se init spremnici izvrše, pokreću se glavni, uključujući pilot-agenta (izaslanika). Povezuje se s već implementiranim Pilotom putem GRPC-a i prima informacije o svim postojećim uslugama i politikama usmjeravanja u klasteru. Prema dobivenim podacima konfigurira klastere i izravno ih dodjeljuje krajnjim točkama naših aplikacija u Kubernetes klasteru. Također je potrebno napomenuti važnu točku: envoy dinamički konfigurira slušatelje (IP, parovi portova) koje počinje slušati. Stoga, kada zahtjevi uđu u pod, preusmjeravaju se korištenjem pravila za preusmjeravanje iptables u sidecar-u, envoy već može uspješno obraditi te veze i razumjeti gdje dalje proxy promet. Također u ovoj fazi, informacije se šalju u Mixer, što ćemo pogledati kasnije, i šalju se rasponi praćenja.
Kao rezultat toga, dobivamo cijelu mrežu envoy proxy poslužitelja koje možemo konfigurirati s jedne točke (Pilot). Svi dolazni i odlazni zahtjevi prolaze kroz envoy. Štoviše, presreće se samo TCP promet. To znači da se IP usluge Kubernetes rješava korištenjem kube-dns preko UDP-a bez promjene. Zatim, nakon rješavanja, odlazni zahtjev presreće i obrađuje izaslanik, koji već odlučuje na koju krajnju točku zahtjev treba poslati (ili ne poslati, u slučaju politika pristupa ili prekidača algoritma).
Shvatili smo Pilot, sada moramo razumjeti kako radi Mixer i zašto je potreban. Možete pročitati službenu dokumentaciju za to .
Mixer se u sadašnjem obliku sastoji od dvije komponente: istio-telemetrija, istio-policy (prije verzije 0.8 to je bila jedna komponenta istio-mixer). Obojica su mikseri, od kojih je svaki odgovoran za svoj zadatak. Istio telemetrija prima informacije o tome tko kamo ide i s kojim parametrima iz bočnih kontejnera izvješća putem GRPC-a. Istio-policy prihvaća zahtjeve za provjeru kako bi potvrdio da su pravila pravila zadovoljena. Provjere pravila se, naravno, ne provode za svaki zahtjev, već se predmemoriraju na klijentu (u prikolici) na određeno vrijeme. Provjere izvješća šalju se kao paketni zahtjevi. Pogledajmo kako konfigurirati i koje parametre treba poslati malo kasnije.
Mixer bi trebao biti visokodostupna komponenta koja osigurava nesmetan rad na sklapanju i obradi telemetrijskih podataka. Sustav se dobiva kao rezultat kao međuspremnik na više razina. U početku se podaci spremaju u međuspremnik na bočnoj strani kontejnera, zatim na strani miksera, a zatim se šalju u takozvane pozadine miksera. Kao rezultat toga, ako bilo koja komponenta sustava zakaže, međuspremnik raste i ispire se nakon oporavka sustava. Pozadine miksera krajnje su točke za slanje telemetrijskih podataka: statsd, newrelic itd. Možete napisati vlastitu pozadinu, prilično je jednostavno, a vidjet ćemo kako to učiniti.
Ukratko, shema za rad s istio-telemetrijom je sljedeća.
- Servis 1 šalje zahtjev servisu 2.
- Prilikom napuštanja usluge 1, zahtjev je zamotan u svoju prikolicu.
- Sidecar Envoy prati kako zahtjev ide servisu 2 i priprema potrebne informacije.
- Zatim ga šalje istio-telemetriji pomoću zahtjeva za izvješće.
- Istio-telemetrija određuje treba li ovo Izvješće slati backend-ovima, na koje i koje podatke treba slati.
- Istio-telemetry šalje podatke Izvješća u pozadinu ako je potrebno.
Sada da vidimo kako implementirati Istio u sustav koji se sastoji samo od glavnih komponenti (Pilot i sidecar envoy).
Prvo, pogledajmo glavnu konfiguraciju (mrežu) koju Pilot čita:
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
Sve glavne kontrolne komponente (kontrolna ravnina) bit će smještene u imenskom prostoru istio-sustava u Kubernetesu.
U najmanju ruku, samo trebamo implementirati Pilot. Za ovo ćemo koristiti
A mi ćemo ručno konfigurirati bočnu prikolicu za ubrizgavanje spremnika.
Početni spremnik:
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
I prikolica:
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
Kako bi sve uspješno krenulo potrebno je kreirati ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot čije opise možete pronaći .
Kao rezultat toga, usluga u koju ubacujemo prikolicu s izaslanikom trebala bi se uspješno pokrenuti, primiti sva otkrića od pilota i obraditi zahtjeve.
Važno je razumjeti da su sve komponente kontrolne ravnine aplikacije bez statusa i mogu se vodoravno skalirati bez problema. Svi podaci pohranjuju se u etcd u obliku prilagođenih opisa Kubernetes resursa.
Također, Istio (još uvijek eksperimentalno) ima mogućnost pokretanja izvan klastera i mogućnost promatranja i petljanja otkrivanja usluga između nekoliko Kubernetes klastera. Možete pročitati više o ovome .
Za instalaciju s više klastera imajte na umu sljedeća ograničenja:
- Pod CIDR i CIDR usluge moraju biti jedinstveni u svim klasterima i ne smiju se preklapati.
- Sve CIDR jedinice moraju biti dostupne iz bilo koje CIDR jedinice između klastera.
- Svi Kubernetes API poslužitelji moraju biti međusobno dostupni.
Ovo su početne informacije koje će vam pomoći da počnete koristiti Istio. Međutim, još uvijek postoje mnoge zamke. Na primjer, značajke usmjeravanja vanjskog prometa (izvan klastera), pristupi otklanjanju pogrešaka sporednih prikolica, profiliranje, postavljanje miksera i pisanje prilagođene pozadine miksera, postavljanje mehanizma praćenja i njegov rad pomoću envoya.
Sve ovo ćemo razmotriti u sljedećim publikacijama. Postavite svoja pitanja, pokušat ću ih pokriti.
Izvor: www.habr.com