hvað ? Þetta er svokallað Service mesh, tækni sem bætir lag af abstrakt yfir netið. Við hlerum alla eða hluta umferðarinnar í klasanum og framkvæmum ákveðnar aðgerðir með honum. Hver þeirra? Til dæmis gerum við snjalla leið, eða við innleiðum aflrofa nálgunina, við getum skipulagt „kanarí-dreifingu“, skipt um umferð að hluta yfir í nýja útgáfu af þjónustunni, eða við getum takmarkað ytri samskipti og stjórnað öllum ferðum frá þyrpingunni til ytra net. Hægt er að setja stefnureglur til að stjórna ferðum milli mismunandi örþjónustu. Að lokum getum við fengið allt netsamskiptakortið og gert sameinað safn mæligilda algjörlega gagnsætt fyrir forritum.
Þú getur lesið um gangverk vinnu í . Istio er virkilega öflugt tól sem gerir þér kleift að leysa mörg verkefni og vandamál. Í þessari grein langar mig að svara helstu spurningum sem venjulega vakna þegar byrjað er með Istio. Þetta mun hjálpa þér að takast á við það hraðar.
Meginreglan um rekstur
Istio samanstendur af tveimur meginsvæðum - stjórnunarplaninu og gagnaplaninu. Stjórnvélin inniheldur helstu þætti sem tryggja rétta virkni restarinnar. Í núverandi útgáfu (1.0) hefur stjórnvélin þrjá meginþætti: Pilot, Mixer, Citadel. Við munum ekki íhuga Citadel, það er nauðsynlegt til að búa til vottorð til að tryggja gagnkvæmt TLS á milli þjónustu. Við skulum skoða nánar tækið og tilgang Pilot og Mixer.
Pilot er aðalstýringarhlutinn sem dreifir öllum upplýsingum um það sem við höfum í klasanum - þjónustur, endapunkta þeirra og leiðarreglur (til dæmis reglur um uppsetningu á Kanarí eða aflrofareglur).
Blandari er valfrjáls stjórnplanshluti sem veitir möguleika á að safna mælingum, annálum og öllum upplýsingum um netsamskipti. Hann fylgist einnig með því að farið sé að reglum stefnunnar og farið sé eftir takmörkunum.
Gagnaplanið er útfært með umboðsgámum hliðarvagns. Kraftmikill er notaður sjálfgefið. . Það er hægt að skipta út fyrir aðra útfærslu, eins og nginx (nginmesh).
Til þess að Istio virki algjörlega gegnsætt fyrir forritum er sjálfvirkt innspýtingarkerfi. Nýjasta útfærslan hentar fyrir Kubernetes 1.9+ útgáfur (stökkbreytingaraðgangsvefhook). Fyrir Kubernetes útgáfur 1.7, 1.8 er hægt að nota Initializer.
Hliðvagnagámar eru tengdir við Pilot með því að nota GRPC samskiptareglur, sem gerir þér kleift að fínstilla þrýstilíkanið fyrir breytingar sem eiga sér stað í klasanum. GRPC hefur verið notað í Envoy síðan útgáfa 1.6, í Istio hefur það verið notað síðan útgáfa 0.8 og er pilot-agent - golang wrapper over envoy sem stillir ræsingarvalkosti.
Pilot og Mixer eru algjörlega ríkisfangslausir hlutir, allt ástand er geymt í minni. Stillingin fyrir þá er sett í formi Kubernetes Custom Resources, sem eru geymdar í etcd.
Istio-agent fær heimilisfang flugmannsins og opnar GRPC straum að því.
Eins og ég sagði útfærir Istio alla virkni algjörlega gagnsæ fyrir forritum. Við skulum sjá hvernig. Reikniritið er þetta:
- Innleiðing nýrrar útgáfu af þjónustunni.
- Það fer eftir innspýtingaraðferð hliðvagnsgáma, istio-init gámnum og istio-agent ílátinu (senvoy) er bætt við á því stigi sem stillingin er beitt, eða þeim er nú þegar hægt að setja handvirkt inn í lýsinguna á Kubernetes Pod einingunni.
- istio-init gámurinn er forskrift sem beitir iptables reglum á pod. Það eru tveir möguleikar til að stilla umferð til að pakka inn í istio-agent ílát: notaðu iptables tilvísunarreglur, eða . Þegar þetta er skrifað er sjálfgefin nálgun með tilvísunarreglum. Í istio-init er hægt að stilla hvaða umferð á að stöðva og senda á istio-agent. Til dæmis, til að stöðva alla komandi og alla útleið, þarftu að stilla færibreyturnar
-iи-bí merkingu*. Þú getur tilgreint sérstakar hafnir til að stöðva. Til að stöðva ekki tiltekið undirnet geturðu tilgreint það með fánanum-x. - Eftir að frumgámarnir hafa verið keyrðir eru þeir helstu ræstir, þar á meðal flugstjórinn (senvoy). Það tengist flugmanninum sem þegar hefur verið dreift í gegnum GRPC og fær upplýsingar um alla núverandi þjónustu og leiðarstefnur í klasanum. Samkvæmt gögnunum sem berast, stillir hann klasana og úthlutar þeim beint á endapunkta forrita okkar í Kubernetes klasanum. Það er líka nauðsynlegt að hafa í huga mikilvægan punkt: sendifulltrúi stillir hlustendur (IP, gáttapör) á virkan hátt sem það byrjar að hlusta á. Þess vegna, þegar beiðnir koma inn í hólfið, er vísað áfram með því að nota redirect iptables reglurnar í hliðarvagninum, getur sendimaður nú þegar unnið úr þessum tengingum og skilið hvar á að umgangast frekar. Einnig á þessu stigi eru upplýsingar sendar til blöndunartækisins, sem við munum skoða síðar, og rekjaspönn send.
Fyrir vikið fáum við heilt net af umboðsþjónum sendiboða sem við getum stillt frá einum stað (Pilot). Allar inn- og útleiðbeiðnir fara í gegnum sendifulltrúa. Þar að auki er aðeins TCP umferð stöðvuð. Þetta þýðir að Kubernetes þjónustu IP er leyst með því að nota kube-dns yfir UDP án þess að breytast. Síðan, eftir úrlausnina, er útsendingarbeiðnin stöðvuð og unnin af sendifulltrúa, sem ákveður nú þegar til hvaða endapunkt beiðnin á að senda (eða ekki send, ef um er að ræða aðgangsreglur eða aflrofa reikniritsins).
Við komumst að Pilot, nú þurfum við að skilja hvernig Mixer virkar og hvers vegna það er þörf. Þú getur lesið opinber skjöl fyrir það .
Blandari í núverandi mynd samanstendur af tveimur hlutum: istio-fjarmælingum, istio-stefnu (fyrir útgáfu 0.8 var það einn istio-blöndunarþáttur). Báðir eru þeir blöndunartæki, sem hver ber ábyrgð á sínu verkefni. Istio fjarmæling fær upplýsingar um hver fer hvert og með hvaða breytum frá hliðarvagna Report gámum í gegnum GRPC. Istio-policy tekur við stöðvabeiðnum til að sannreyna að stefnureglur séu uppfylltar. Regluathuganir eru að sjálfsögðu ekki framkvæmdar fyrir hverja beiðni heldur eru þær vistaðar á viðskiptavininum (í hliðarvagninum) í ákveðinn tíma. Skýrsluávísanir eru sendar sem lotubeiðnir. Við skulum sjá hvernig á að stilla og hvaða breytur ætti að senda aðeins síðar.
Blandarinn á að vera mjög fáanlegur hluti sem tryggir samfellda vinnu við samsetningu og úrvinnslu fjarmælingagagna. Kerfið fæst í kjölfarið sem fjölþrepa biðminni. Upphaflega eru gögn sett í biðminni á hliðarvagnahlið gáma, síðan á blöndunarhliðinni og síðan send í svokallaða blöndunarbakka. Þar af leiðandi, ef einhver af kerfisíhlutunum bilar, vex biðminni og er skolaður eftir að kerfið er endurheimt. Blöndunarbakendarnir eru endapunktar til að senda fjarmælingagögn: statsd, newrelic, osfrv. Þú getur skrifað þinn eigin bakenda, það er frekar einfalt og við munum sjá hvernig á að gera það.
Til að draga saman er kerfið til að vinna með istio-telemetry sem hér segir.
- Þjónusta 1 sendir beiðni til þjónustu 2.
- Þegar farið er út af þjónustu 1 er beiðnin vafin inn í eigin hliðarvagn.
- Sidecar sendimaður fylgist með því hvernig beiðnin fer í þjónustu 2 og útbýr nauðsynlegar upplýsingar.
- Sendir það síðan í istio-telemetry með því að nota Report request.
- Istio-telemetry ákvarðar hvort senda eigi skýrsluna til bakendanna, til hvaða og hvaða gögn eigi að senda.
- Istio-telemetry sendir skýrslugögn til bakendans ef þörf krefur.
Nú skulum við sjá hvernig á að dreifa Istio í kerfinu, sem samanstendur aðeins af aðalhlutunum (Pilot og sidecar envoy).
Fyrst skulum við skoða helstu stillingar (mesh) sem Pilot les:
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
Allir helstu stjórnhlutar (stjórnplan) verða staðsettir í nafnrými istio-kerfinu í Kubernetes.
Að minnsta kosti þurfum við aðeins að senda Pilot. Fyrir þetta notum við
Og við munum stilla innspýtingarhlið ílátsins handvirkt.
Init gámur:
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
Og hliðarvagn:
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
Til þess að allt geti byrjað með góðum árangri þarftu að búa til þjónustureikning, ClusterRole, ClusterRoleBinding, CRD for Pilot, lýsingar á þeim má finna .
Þar af leiðandi ætti þjónustan sem við sprautum hliðarvagni með sendifulltrúa að byrja með góðum árangri, fá allar uppgötvun frá flugmanninum og vinna úr beiðnum.
Það er mikilvægt að skilja að allir íhlutir stjórnborðs eru ríkisfangslaus forrit og hægt er að stækka þær lárétt án vandkvæða. Öll gögn eru geymd í etcd í formi sérsniðinna lýsinga á Kubernetes auðlindum.
Einnig, Istio (enn í tilraunaskyni) hefur getu til að keyra utan þyrpingarinnar og getu til að horfa á og flækja þjónustuuppgötvun á milli nokkurra Kubernetes þyrpinga. Þú getur lesið meira um þetta .
Fyrir uppsetningu með mörgum þyrpingum skaltu vera meðvitaður um eftirfarandi takmarkanir:
- Pod CIDR og Service CIDR verða að vera einstök fyrir alla klasa og mega ekki skarast.
- Allir CIDR Pods verða að vera aðgengilegir frá hvaða CIDR Pod sem er á milli klasa.
- Allir Kubernetes API netþjónar verða að vera aðgengilegir hver öðrum.
Þetta eru fyrstu upplýsingarnar til að hjálpa þér að byrja með Istio. Hins vegar eru enn margar gildrur. Til dæmis, eiginleikar við að beina utanaðkomandi umferð (utan þyrpingarinnar), aðferðir við að kemba hliðarvagna, sniðgreiningu, setja upp blöndunartæki og skrifa sérsniðið blöndunartæki, setja upp rakningarkerfi og rekstur þess með sendiboði.
Allt þetta munum við íhuga í eftirfarandi ritum. Spyrðu spurninga þinna, ég mun reyna að ná þeim.
Heimild: www.habr.com