ką ? Tai yra vadinamasis paslaugų tinklelis, technologija, kuri tinkle prideda abstrakcijos sluoksnį. Perimame visą klasterio srautą arba jo dalį ir atliekame su juo tam tikrą operacijų rinkinį. Kuris? Pavyzdžiui, atliekame išmanųjį maršruto parinkimą arba įdiegiame grandinės pertraukiklio metodą, galime organizuoti „kanarėlių diegimą“, iš dalies perjungdami srautą į naują paslaugos versiją arba galime apriboti išorines sąveikas ir valdyti visas keliones iš klasterio į išorinis tinklas. Galima nustatyti politikos taisykles, skirtas valdyti keliones tarp skirtingų mikropaslaugų. Galiausiai galime gauti visą tinklo sąveikos žemėlapį ir padaryti vieningą metrikų rinkinį visiškai skaidrią programoms.
Apie veikimo mechanizmą galite perskaityti . Istio yra tikrai galingas įrankis, leidžiantis išspręsti daugybę užduočių ir problemų. Šiame straipsnyje norėčiau atsakyti į pagrindinius klausimus, kurie dažniausiai kyla pradedant dirbti su Istio. Tai padės greičiau susitvarkyti.
Veikimo principas
Istio susideda iš dviejų pagrindinių sričių – valdymo plokštumos ir duomenų plokštumos. Valdymo plokštumoje yra pagrindiniai komponentai, užtikrinantys tinkamą likusių dalių veikimą. Dabartinėje versijoje (1.0) valdymo plokštumą sudaro trys pagrindiniai komponentai: Pilot, Mixer, Citadel. Citadelės nesvarstysime, reikia sugeneruoti sertifikatus, kad būtų užtikrintas abipusis TLS tarp paslaugų. Pažvelkime atidžiau į „Pilot and Mixer“ įrenginį ir paskirtį.
Pilotas yra pagrindinis valdymo komponentas, paskirstantis visą informaciją apie tai, ką turime klasteryje – paslaugas, jų galutinius taškus ir maršruto parinkimo taisykles (pavyzdžiui, Kanarų diegimo arba grandinės pertraukiklio taisykles).
Maišytuvas yra pasirenkamas valdymo plokštumos komponentas, suteikiantis galimybę rinkti metrikas, žurnalus ir bet kokią informaciją apie tinklo sąveiką. Jis taip pat stebi, kaip laikomasi politikos taisyklių ir normų ribų.
Duomenų plokštuma yra įgyvendinta naudojant šoninių priekabų tarpinio serverio konteinerius. Pagal numatytuosius nustatymus naudojamas galingas. . Jį galima pakeisti kitu įgyvendinimu, pvz., nginx (nginmesh).
Kad „Istio“ veiktų visiškai skaidriai, yra automatinė įpurškimo sistema. Naujausias diegimas tinka Kubernetes 1.9 ir naujesnėms versijoms (mutacinės prieigos žiniatinklio kabliukas). Kubernetes 1.7, 1.8 versijoms galima naudoti inicijavimo priemonę.
Šoniniai konteineriai yra prijungti prie „Pilot“ naudojant GRPC protokolą, kuris leidžia optimizuoti „push“ modelį klasteryje vykstantiems pokyčiams. GRPC buvo naudojamas Envoy nuo 1.6 versijos, Istio jis buvo naudojamas nuo 0.8 versijos ir yra bandomasis agentas - golang wrapper over envoy, kuris konfigūruoja paleidimo parinktis.
Pilot ir Mixer yra visiškai be būsenos komponentai, visa būsena saugoma atmintyje. Jų konfigūracija nustatoma kaip Kubernetes pasirinktiniai ištekliai, kurie saugomi etcd.
„Istio-agent“ gauna piloto adresą ir atidaro jam GRPC srautą.
Kaip jau sakiau, „Istio“ įgyvendina visas funkcijas, visiškai skaidrias programoms. Pažiūrėkime kaip. Algoritmas yra toks:
- Diegiama nauja paslaugos versija.
- Priklausomai nuo šoninio priekabos konteinerio įpurškimo metodo, konteineris istio-init ir istio-agent konteineris (pasiuntinys) pridedami konfigūracijos taikymo etape arba jau gali būti rankiniu būdu įterpti į Kubernetes Pod objekto aprašymą.
- Konteineris istio-init yra scenarijus, kuris podui taiko iptables taisykles. Yra dvi parinktys, kaip sukonfigūruoti srautą, kad jis būtų suvyniotas į „istio-agent“ konteinerį: naudoti „iptables“ peradresavimo taisykles arba . Rašymo metu numatytasis metodas yra su peradresavimo taisyklėmis. In stio-init galima sukonfigūruoti, kuris srautas turi būti perimtas ir siunčiamas į istio-agent. Pavyzdžiui, norėdami perimti visą įeinantį ir išeinantį srautą, turite nustatyti parametrus
-iи-bį prasmę*. Galite nurodyti konkrečius perimtus prievadus. Kad nebūtų perimtas konkretus potinklis, galite jį nurodyti naudodami vėliavėlę-x. - Atlikus init konteinerius, paleidžiami pagrindiniai, įskaitant pilotą-agentą (pasiuntinį). Jis prisijungia prie jau įdiegto piloto per GRPC ir gauna informaciją apie visas esamas paslaugas ir maršruto parinkimo strategijas klasteryje. Pagal gautus duomenis jis sukonfigūruoja grupes ir tiesiogiai priskiria jas mūsų taikomųjų programų galiniams taškams Kubernetes klasteryje. Taip pat būtina atkreipti dėmesį į svarbų dalyką: pasiuntinys dinamiškai sukonfigūruoja klausytojus (IP, prievadų poras), kurių pradeda klausytis. Todėl, kai užklausos patenka į podėlį, yra peradresuojamos naudojant redirect iptables taisykles šoninėje priekaboje, pasiuntinys jau gali sėkmingai apdoroti šiuos ryšius ir suprasti, kur toliau perduoti srautą. Taip pat šiame etape į maišytuvą siunčiama informacija, kurią peržiūrėsime vėliau, ir siunčiami sekimo intervalai.
Dėl to gauname visą tinklą envoy proxy serverių, kuriuos galime konfigūruoti iš vieno taško (Pilot). Visos įeinančios ir išeinančios užklausos siunčiamos per pasiuntinį. Be to, perimamas tik TCP srautas. Tai reiškia, kad Kubernetes paslaugos IP yra išspręstas naudojant kube-dns per UDP nekeičiant. Tada, po sprendimo, siunčiama užklausa yra perimama ir apdorojama pasiuntinio, kuris jau nusprendžia, į kurį galinį tašką užklausa turi būti siunčiama (arba nesiunčiama, jei tai yra prieigos politika arba algoritmo grandinės pertraukiklis).
Mes supratome „Pilot“, dabar turime suprasti, kaip veikia „Mixer“ ir kodėl jis reikalingas. Galite perskaityti oficialius jo dokumentus .
Maišytuvas savo dabartine forma susideda iš dviejų komponentų: istio-telemetrijos, istio-politikos (prieš 0.8 versiją tai buvo vienas istio-mixer komponentas). Abu jie yra maišytuvai, kurių kiekvienas yra atsakingas už savo užduotį. Istio telemetrija informaciją apie tai, kas kur važiuoja ir su kokiais parametrais gauna iš šoninių priekabų Report konteinerių per GRPC. „Istio-policy“ priima patikrinimo užklausas, kad patikrintų, ar laikomasi politikos taisyklių. Politikos patikrinimai, žinoma, atliekami ne kiekvienai užklausai, o tam tikrą laiką saugomi kliento talpykloje (šoninėje priekaboje). Ataskaitų patikrinimai siunčiami kaip paketinės užklausos. Pažiūrėkime, kaip sukonfigūruoti ir kokius parametrus reikia siųsti šiek tiek vėliau.
Maišytuvas turėtų būti labai prieinamas komponentas, užtikrinantis nenutrūkstamą telemetrijos duomenų surinkimo ir apdorojimo darbą. Sistema gaunama kaip kelių lygių buferis. Iš pradžių duomenys buferizuojami konteinerių šoninėje priekaboje, tada maišytuvo pusėje, o tada siunčiami į vadinamuosius maišytuvus. Dėl to, jei kuris nors sistemos komponentas sugenda, buferis didėja ir išplaunamas atkūrus sistemą. Maišytuvo užpakalinės programos yra telemetrijos duomenų siuntimo galiniai taškai: statsd, newrelic ir kt. Galite parašyti savo backend'ą, tai gana paprasta, o mes pažiūrėsime, kaip tai padaryti.
Apibendrinant galima pasakyti, kad darbo su istio-telemetrija schema yra tokia.
- 1 tarnyba siunčia užklausą 2 tarnybai.
- Išėjus iš 1 tarnybos, prašymas įvyniojamas į savo šoninę priekabą.
- Priekabos pasiuntinys stebi, kaip užklausa patenka į 2 servisą ir paruošia reikiamą informaciją.
- Tada siunčia jį į istio-telemetriją naudodamas ataskaitos užklausą.
- Istio-telemetrija nustato, ar ši ataskaita turi būti siunčiama į backends, į kurią ir kokius duomenis reikia siųsti.
- „Istio-telemetrija“ siunčia ataskaitos duomenis į užpakalinę programą, jei reikia.
Dabar pažiūrėkime, kaip įdiegti „Istio“ sistemoje, kurią sudaro tik pagrindiniai komponentai (pilotas ir šoninio priekabos pasiuntinys).
Pirmiausia pažvelkime į pagrindinę konfigūraciją (tinklelį), kurią skaito Pilot:
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
Visi pagrindiniai valdymo komponentai (valdymo plokštuma) bus Kubernetes vardų erdvės istio sistemoje.
Mums tereikia įdiegti „Pilot“. Tam naudosime
Ir mes rankiniu būdu sukonfigūruosime konteinerio įpurškimo šoninę priekabą.
Pradinis konteineris:
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
Ir šoninė priekaba:
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
Kad viskas prasidėtų sėkmingai, reikia susikurti ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, kurių aprašymus rasite .
Dėl to tarnyba, į kurią įleidžiame priekabą su pasiuntiniu, turėtų prasidėti sėkmingai, gauti visus atradimus iš piloto ir apdoroti užklausas.
Svarbu suprasti, kad visi valdymo plokštumos komponentai yra programos be būsenos ir gali būti be problemų keičiamos horizontaliai. Visi duomenys yra saugomi etcd tinkintų Kubernetes išteklių aprašymų forma.
Be to, „Istio“ (vis dar eksperimentinė) turi galimybę veikti už klasterio ribų ir galimybę stebėti bei aptikti paslaugų atradimą tarp kelių „Kubernetes“ grupių. Daugiau apie tai galite paskaityti .
Įdiegę kelias grupes, atkreipkite dėmesį į šiuos apribojimus:
- Pod CIDR ir paslaugos CIDR turi būti unikalūs visose grupėse ir neturi persidengti.
- Visi CIDR Pod turi būti pasiekiami iš bet kurių CIDR Pod tarp grupių.
- Visi Kubernetes API serveriai turi būti pasiekiami vienas kitam.
Tai pradinė informacija, kuri padės jums pradėti dirbti su Istio. Tačiau vis dar yra daug spąstų. Pavyzdžiui, išorinio srauto nukreipimo (už klasterio ribų) ypatybės, šalutinių priekabų derinimo būdai, profiliavimas, maišytuvo nustatymas ir pasirinktinio maišytuvo užpakalinės programos rašymas, sekimo mechanizmo nustatymas ir jo veikimas naudojant pasiuntinį.
Visa tai apsvarstysime tolesniuose leidiniuose. Užduokite klausimus, pasistengsiu juos atsakyti.
Šaltinis: www.habr.com