Kio ? Ĉi tio estas la tiel nomata Servo-maŝo, teknologio kiu aldonas tavolon de abstraktado super la reto. Ni kaptas ĉion aŭ parton de la trafiko en la areto kaj faras certan aron da operacioj kun ĝi. Kiu? Ekzemple, ni faras inteligentan vojigon, aŭ ni efektivigas la aliron de interrompilo, ni povas organizi "kanarian deplojon", parte ŝanĝante trafikon al nova versio de la servo, aŭ ni povas limigi eksterajn interagojn kaj kontroli ĉiujn vojaĝojn de la areto al la ekstera reto. Eblas agordi politikajn regulojn por kontroli vojaĝojn inter malsamaj mikroservoj. Fine, ni povas akiri la tutan retan interagan mapon kaj fari la unuigitan kolekton de metrikoj tute travidebla al aplikoj.
Vi povas legi pri la mekanismo de laboro en . Istio estas vere potenca ilo, kiu permesas vin solvi multajn taskojn kaj problemojn. En ĉi tiu artikolo, mi ŝatus respondi la ĉefajn demandojn, kiuj kutime aperas kiam mi komencas kun Istio. Ĉi tio helpos vin trakti ĝin pli rapide.
Kiel ĝi funkcias
Istio konsistas el du ĉefaj areoj - la kontrolaviadilo kaj la datenaviadilo. La kontrolaviadilo enhavas la ĉefajn komponantojn, kiuj certigas la ĝustan funkciadon de la resto. En la nuna versio (1.0) la kontrolaviadilo havas tri ĉefajn komponantojn: Piloto, Miksilo, Citadelo. Ni ne konsideros Citadelon, necesas generi atestojn por certigi reciprokan TLS inter servoj. Ni rigardu pli proksime al la aparato kaj celo de Piloto kaj Miksilo.
Piloto estas la ĉefa kontrolkomponento, kiu distribuas ĉiujn informojn pri tio, kion ni havas en la areto - servoj, iliaj finpunktoj kaj enrutaj reguloj (ekzemple, reguloj por Kanaria deplojo aŭ interrompaj reguloj).
Miksilo estas nedeviga kontrolebena komponento, kiu disponigas la kapablon kolekti metrikojn, protokolojn kaj ajnajn informojn pri retinterago. Li ankaŭ kontrolas observon kun Politikaj reguloj kaj observon kun tariflimoj.
La datenaviadilo estas efektivigita uzante kromĉarajn prokurujojn. Potenca estas uzata defaŭlte. . Ĝi povas esti anstataŭigita per alia efektivigo, kiel ekzemple nginx (nginmesh).
Por ke Istio funkciu tute travidebla al aplikoj, ekzistas aŭtomata injekta sistemo. La plej nova efektivigo taŭgas por versioj de Kubernetes 1.9+ (mutacia agnoska rethoko). Por Kubernetes-versioj 1.7, 1.8 eblas uzi la Inicialigilon.
Sidecar-ujoj estas konektitaj al Pilot per la GRPC-protokolo, kiu ebligas al vi optimumigi la puŝmodelon por ŝanĝoj okazantaj en la areto. GRPC estis uzita en Envoy ekde versio 1.6, en Istio ĝi estis uzita ekde versio 0.8 kaj estas pilot-agento - golang-envolvaĵo super sendito kiu agordas lanĉopciojn.
Piloto kaj Miksilo estas tute sennaciaj komponantoj, ĉiu stato estas konservita en memoro. La agordo por ili estas agordita en la formo de Kubernetes Propraj Rimedoj, kiuj estas konservitaj en ktpd.
Istio-agento ricevas la adreson de la Piloto kaj malfermas GRPC-rivereton al ĝi.
Kiel mi diris, Istio efektivigas ĉiujn funkciojn tute travideblajn al aplikaĵoj. Ni vidu kiel. La algoritmo estas jena:
- Deplojante novan version de la servo.
- Depende de la aliro de injekta ujo de sidecar, la ujo de istio-init kaj la ujo de istio-agento (sendito) estas aldonitaj en la stadio de aplikado de la agordo, aŭ ili jam povas esti permane enmetitaj en la priskribon de la Kubernetes Pod-unuo.
- La istio-init-ujo estas skripto kiu aplikas la iptables-regulojn al la pod. Estas du opcioj por agordi trafikon por esti envolvita en istio-agentujo: uzu regulojn pri redirektiloj de iptables, aŭ . En la momento de la skribado, la defaŭlta aliro estas kun alidirektaj reguloj. En istio-init, estas eble agordi kiun trafikon devus esti kaptita kaj sendita al istio-agent. Ekzemple, por kapti la tutan envenantan kaj elirantan trafikon, vi devas agordi la parametrojn
-iи-ben signifon*. Vi povas specifi specifajn havenojn por kapti. Por ne kapti specifan subreton, vi povas specifi ĝin uzante la flagon-x. - Post kiam la init-ujoj estas ekzekutitaj, la ĉefaj estas lanĉitaj, inkluzive de la piloto-agento (sendito). Ĝi konektas al la jam deplojita Piloto per GRPC kaj ricevas informojn pri ĉiuj ekzistantaj servoj kaj vojpolitikoj en la areto. Laŭ la ricevitaj datumoj, li agordas la aretojn kaj asignas ilin rekte al la finpunktoj de niaj aplikoj en la Kubernetes-grupo. Necesas ankaŭ noti gravan punkton: sendito dinamike agordas aŭskultantojn (IP, havenparoj), kiujn ĝi komencas aŭskulti. Sekve, kiam petoj eniras la podon, estas alidirektitaj uzante la regulojn de alidirekti iptables en la kromĉaro, sendito jam povas sukcese prilabori ĉi tiujn konektojn kaj kompreni kie plue prokuri la trafikon. Ankaŭ en ĉi tiu etapo, informoj estas senditaj al la Miksilo, kiun ni rigardos poste, kaj spurantaj intervaloj estas senditaj.
Kiel rezulto, ni ricevas tutan reton de senditaj prokurserviloj, kiujn ni povas agordi de unu punkto (Piloto). Ĉiuj enirantaj kaj elirantaj petoj trapasas senditon. Plie, nur TCP-trafiko estas kaptita. Ĉi tio signifas, ke Kubernetes-servo IP estas solvita per kube-dns super UDP sen ŝanĝi. Tiam, post la solvado, la eksiĝinta peto estas kaptita kaj prilaborita de sendito, kiu jam decidas al kiu finpunkto la peto estu sendita (aŭ ne sendita, en la kazo de alirpolitikoj aŭ la ŝaltilo de la algoritmo).
Ni eltrovis Pilot, nun ni devas kompreni kiel Mixer funkcias kaj kial ĝi bezonas. Vi povas legi la oficialan dokumentaron por ĝi .
Miksilo en ĝia nuna formo konsistas el du komponantoj: istio-telemetrio, istio-politiko (antaŭ versio 0.8 ĝi estis unu istio-miksilo-komponento). Ambaŭ estas miksiloj, ĉiu el kiuj respondecas pri sia propra tasko. Istio-telemetrio ricevas informojn pri kiu iras kien kaj kun kiaj parametroj de kromĉaraj Raportujoj per GRPC. Istio-policy akceptas Kontroli petojn por kontroli, ke Politikaj reguloj estas kontentigitaj. Poilicy-kontroloj kompreneble ne estas faritaj por ĉiu peto, sed estas konservitaj en la kliento (en la kromĉaro) dum certa tempo. Raportkontroloj estas senditaj kiel gruppetoj. Ni vidu kiel agordi kaj kiaj parametroj estu senditaj iom poste.
La Miksilo supozeble estas tre disponebla komponanto, kiu certigas seninterrompan laboron pri la muntado kaj prilaborado de telemetriaj datumoj. La sistemo estas akirita kiel rezulto kiel plurnivela bufro. Komence, datumoj estas bufritaj sur la flankoĉarflanko de ujoj, tiam sur la miksilo-flanko, kaj tiam senditaj al la tielnomitaj miksaĵbackends. Kiel rezulto, se iu el la sistemkomponentoj malsukcesas, la bufro kreskas kaj estas lavita post kiam la sistemo estas reestigita. Miksilaj backends estas finpunktoj por sendi telemetriajn datumojn: statsd, newrelic, ktp. Vi povas skribi vian propran backend, ĝi estas sufiĉe simpla, kaj ni vidos kiel fari ĝin.
Por resumi, la skemo por labori kun istio-telemetrio estas kiel sekvas.
- Servo 1 sendas peton al servo 2.
- Forlasante servon 1, la peto estas envolvita en sia propra kromĉaro.
- Sidecar-sendito kontrolas kiel la peto iras al servo 2 kaj preparas la necesajn informojn.
- Poste sendas ĝin al istio-telemetrio uzante Raportpeton.
- Istio-telemetrio determinas ĉu ĉi tiu Raporto devus esti sendita al la backends, al kiuj kaj kiaj datumoj devus esti senditaj.
- Istio-telemetrio sendas Raportajn datumojn al la backend se necese.
Nun ni vidu kiel disfaldi Istio en la sistemo, konsistanta nur el la ĉefaj komponantoj (Piloto kaj sidecar sendito).
Unue, ni rigardu la ĉefan agordon (maŝo), kiun Pilot legas:
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
Ĉiuj ĉefaj kontrolkomponentoj (kontrolebeno) estos lokitaj en la nomspaco istio-sistemo en Kubernetes.
Minimume, ni nur bezonas deploji Pilot. Por tio ni uzas
Kaj ni mane agordos la injektan kromĉaron de la ujo.
Init-ujo:
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
Kaj kromĉaro:
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
Por ke ĉio komenciĝu sukcese, vi devas krei ServiceAccount, ClusterRole, ClusterRoleBinding, CRD por Pilot, kies priskriboj troveblas .
Kiel rezulto, la servo en kiun ni injektas kromĉaron kun sendito devus komenci sukcese, ricevi ĉiujn malkovrojn de la piloto kaj procesi petojn.
Gravas kompreni, ke ĉiuj kontrolebenaj komponentoj estas sennaciaj aplikoj kaj povas esti horizontale skalitaj sen problemoj. Ĉiuj datumoj estas konservitaj en etcd en la formo de kutimaj priskriboj de Kubernetes-resursoj.
Ankaŭ, Istio (daŭre eksperimenta) havas la kapablon kuri ekster la areto kaj la kapablon rigardi kaj palpumi servomalkovron inter pluraj Kubernetes aretoj. Vi povas legi pli pri ĉi tio .
Por instalo de plurgrupo, konsciu la jenajn limojn:
- Pod CIDR kaj Service CIDR devas esti unikaj tra ĉiuj aretoj kaj ne devas interkovri.
- Ĉiuj CIDR Pods devas esti alireblaj de iuj CIDR Pods inter aretoj.
- Ĉiuj Kubernetes API-serviloj devas esti alireblaj unu por la alia.
Ĉi tio estas la komenca informo por helpi vin komenci kun Istio. Tamen, estas ankoraŭ multaj kaptiloj. Ekzemple, ecoj de vojigo de ekstera trafiko (ekster la areto), aliroj al senararigado de kromĉaroj, profilado, starigado de miksilo kaj skribado de kutima miksilo-backend, starigado de spurmekanismo kaj ĝia operacio uzante senditon.
Ĉion ĉi ni konsideros en la sekvaj eldonaĵoj. Demandu viajn demandojn, mi provos kovri ilin.
fonto: www.habr.com