Kas ir ? Šī ir tā sauktā Service mesh — tehnoloģija, kas tīklā pievieno abstrakcijas slāni. Mēs pārtveram visu klastera trafiku vai tās daļu un veicam ar to noteiktu darbību kopumu. Kurš? Piemēram, mēs veicam viedo maršrutēšanu vai ieviešam ķēdes pārtraucēja pieeju, varam organizēt “kanārijputnu izvietošanu”, daļēji pārslēdzot trafiku uz jaunu pakalpojuma versiju, vai arī varam ierobežot ārējo mijiedarbību un kontrolēt visus braucienus no klastera uz ārējais tīkls. Ir iespējams iestatīt politikas noteikumus, lai kontrolētu braucienus starp dažādiem mikropakalpojumiem. Visbeidzot, mēs varam iegūt visu tīkla mijiedarbības karti un padarīt vienoto metrikas kolekciju pilnībā pārskatāmu lietojumprogrammām.
Jūs varat lasīt par darbības mehānismu . Istio ir patiešām spēcīgs rīks, kas ļauj atrisināt daudzus uzdevumus un problēmas. Šajā rakstā es vēlos atbildēt uz galvenajiem jautājumiem, kas parasti rodas, uzsākot darbu ar Istio. Tas palīdzēs ātrāk tikt galā ar to.
Kā tas darbojas
Istio sastāv no divām galvenajām zonām – vadības plaknes un datu plaknes. Vadības plaknē ir galvenās sastāvdaļas, kas nodrošina pārējo pareizu darbību. Pašreizējā versijā (1.0) vadības plaknei ir trīs galvenie komponenti: Pilots, Mikseris, Citadele. Mēs Citadeli neuzskatīsim, ir nepieciešams ģenerēt sertifikātus, lai nodrošinātu savstarpēju TLS starp pakalpojumiem. Sīkāk apskatīsim Pilot and Mixer ierīci un mērķi.
Pilots ir galvenais vadības komponents, kas izplata visu informāciju par to, kas mums ir klasterī - pakalpojumiem, to galapunktiem un maršrutēšanas noteikumiem (piemēram, noteikumi Kanāriju izvietošanai vai ķēdes pārtraucēja noteikumi).
Mikseris ir izvēles vadības plaknes komponents, kas nodrošina iespēju apkopot metriku, žurnālus un jebkādu informāciju par tīkla mijiedarbību. Viņš arī uzrauga atbilstību politikas noteikumiem un likmju ierobežojumu ievērošanu.
Datu plakne tiek realizēta, izmantojot blakusvāģa starpniekservera konteinerus. Jaudīgs tiek izmantots pēc noklusējuma. . To var aizstāt ar citu ieviešanu, piemēram, nginx (nginmesh).
Lai Istio darbotos pilnīgi caurspīdīgi lietojumprogrammām, ir automātiska iesmidzināšanas sistēma. Jaunākā ieviešana ir piemērota Kubernetes 1.9+ versijām (mutācijas piekļuves tīmekļa aizķere). Kubernetes versijām 1.7, 1.8 ir iespējams izmantot inicializatoru.
Blakusvāģu konteineri ir savienoti ar Pilot, izmantojot GRPC protokolu, kas ļauj optimizēt push modeli klasterī notiekošām izmaiņām. GRPC ir izmantots Envoy kopš versijas 1.6, Istio tas ir izmantots kopš versijas 0.8 un ir pilotaģents - golang wrapper over envoy, kas konfigurē palaišanas opcijas.
Pilots un mikseris ir pilnīgi bezvalsts komponenti, viss stāvoklis tiek saglabāts atmiņā. To konfigurācija ir iestatīta Kubernetes pielāgoto resursu veidā, kas tiek glabāti utt.
Istio-agent iegūst pilota adresi un atver tam GRPC straumi.
Kā jau teicu, Istio ievieš visas lietojumprogrammām pilnīgi pārredzamas funkcijas. Paskatīsimies, kā. Algoritms ir šāds:
- Jaunas pakalpojuma versijas izvietošana.
- Atkarībā no blakusvāģa konteinera iesmidzināšanas pieejas istio-init konteiners un istio-agent konteiners (sūtnis) tiek pievienoti konfigurācijas pielietošanas stadijā, vai arī tos jau var manuāli ievietot Kubernetes Pod entītijas aprakstā.
- Konteiners istio-init ir skripts, kas aplikācijai piemēro iptables noteikumus. Ir divas iespējas, kā konfigurēt trafiku iesaiņošanai istio-agent konteinerā: izmantojiet iptables novirzīšanas noteikumus vai . Rakstīšanas laikā noklusējuma pieeja ir ar novirzīšanas noteikumiem. In istio-init ir iespējams konfigurēt, kura trafika jāpārtver un jānosūta uz istio-agent. Piemēram, lai pārtvertu visu ienākošo un visu izejošo trafiku, ir jāiestata parametri
-iи-bnozīmē*. Varat norādīt konkrētus portus, ko pārtvert. Lai nepārtvertu noteiktu apakštīklu, varat to norādīt, izmantojot karogu-x. - Pēc init konteineru izpildes tiek palaisti galvenie, ieskaitot pilotu aģentu (sūtni). Tas savienojas ar jau izvietoto Pilot, izmantojot GRPC, un saņem informāciju par visiem klasterī esošajiem pakalpojumiem un maršrutēšanas politikām. Saskaņā ar saņemtajiem datiem viņš konfigurē klasterus un piešķir tos tieši mūsu lietojumprogrammu galapunktiem Kubernetes klasterī. Ir arī jāņem vērā svarīgs punkts: sūtnis dinamiski konfigurē klausītājus (IP, portu pārus), kurus tas sāk klausīties. Tāpēc, kad pieprasījumi tiek ievadīti podā un tiek novirzīti, izmantojot redirect iptables noteikumus blakusvāģī, sūtnis jau var veiksmīgi apstrādāt šos savienojumus un saprast, kur tālāk nodrošināt trafiku. Arī šajā posmā uz Mikseri tiek nosūtīta informācija, kuru mēs apskatīsim vēlāk, un tiek nosūtīti izsekošanas laidumi.
Rezultātā mēs iegūstam veselu sūtņa starpniekserveru tīklu, ko varam konfigurēt no viena punkta (Pilot). Visi ienākošie un izejošie pieprasījumi tiek nosūtīti caur sūtni. Turklāt tiek pārtverts tikai TCP trafiks. Tas nozīmē, ka Kubernetes pakalpojuma IP adrese tiek atrisināta, izmantojot kube-dns, izmantojot UDP, nemainot. Pēc tam pēc atrisināšanas izejošo pieprasījumu pārtver un apstrādā sūtnis, kurš jau izlemj, uz kuru galapunktu pieprasījums ir jānosūta (vai nenosūta, piekļuves politiku vai algoritma ķēdes pārtraucēja gadījumā).
Mēs izdomājām Pilot, tagad mums ir jāsaprot, kā Mixer darbojas un kāpēc tas ir vajadzīgs. Jūs varat izlasīt tā oficiālo dokumentāciju .
Maisītājs pašreizējā formā sastāv no diviem komponentiem: istio-telemetrija, istio-policy (pirms versijas 0.8 tas bija viens istio-mixer komponents). Abi ir mikseri, no kuriem katrs ir atbildīgs par savu uzdevumu. Istio telemetrija saņem informāciju par to, kurš kurp dodas un ar kādiem parametriem no blakusvāģa Report konteineriem caur GRPC. Istio-policy pieņem pārbaudes pieprasījumus, lai pārbaudītu, vai politikas noteikumi ir izpildīti. Politikas pārbaudes, protams, netiek veiktas katram pieprasījumam, bet tiek saglabātas klienta kešatmiņā (blakusvāģī) uz noteiktu laiku. Pārskatu pārbaudes tiek nosūtītas kā pakešu pieprasījumi. Apskatīsim, kā konfigurēt un kādus parametrus vajadzētu nosūtīt nedaudz vēlāk.
Maisītājam ir jābūt ļoti pieejamam komponentam, kas nodrošina nepārtrauktu darbu pie telemetrijas datu montāžas un apstrādes. Rezultātā sistēma tiek iegūta kā daudzlīmeņu buferis. Sākotnēji dati tiek buferēti konteineru blakusvāģa pusē, pēc tam maisītāja pusē un pēc tam tiek nosūtīti uz tā sauktajām miksera aizmugures sistēmām. Rezultātā, ja kāds no sistēmas komponentiem neizdodas, buferis palielinās un tiek izskalots pēc sistēmas atjaunošanas. Mikseru aizmugursistēmas ir galapunkti telemetrijas datu nosūtīšanai: statsd, newrelic utt. Jūs varat uzrakstīt savu aizmugursistēmu, tas ir diezgan vienkārši, un mēs redzēsim, kā to izdarīt.
Rezumējot, shēma darbam ar istio-telemetriju ir šāda.
- 1. pakalpojums nosūta pieprasījumu pakalpojumam 2.
- Izejot no 1. dienesta, pieprasījums tiek iesaiņots savā blakusvāģī.
- Blakusvāģu sūtnis uzrauga, kā pieprasījums nonāk 2. servisā un sagatavo nepieciešamo informāciju.
- Pēc tam nosūta to uz istio-telemetriju, izmantojot ziņojuma pieprasījumu.
- Istio-telemetrija nosaka, vai šis pārskats ir jānosūta uz aizmugursistēmām, uz kurām un kādi dati jānosūta.
- Istio-telemetrija vajadzības gadījumā nosūta atskaites datus aizmugursistēmai.
Tagad redzēsim, kā Istio izvietot sistēmā, kas sastāv tikai no galvenajām sastāvdaļām (Pilots un blakusvāģa sūtnis).
Vispirms apskatīsim galveno konfigurāciju (sietu), ko izlasa 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
Visas galvenās vadības sastāvdaļas (vadības plakne) atradīsies Kubernetes nosaukumtelpas istio-sistēmā.
Mums vismaz ir jāizvieto tikai Pilot. Šim nolūkam mēs izmantosim
Un mēs manuāli konfigurēsim konteinera injicēšanas blakusvāģi.
Init konteiners:
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
Un blakusvāģis:
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
Lai viss sāktos veiksmīgi, jāizveido ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, kuru aprakstus var atrast .
Rezultātā dienestam, kurā iepludinām blakusvāģi ar sūtni, vajadzētu veiksmīgi startēt, saņemt no pilota visus atklājumus un apstrādāt pieprasījumus.
Ir svarīgi saprast, ka visas vadības plaknes sastāvdaļas ir bezvalsts lietojumprogrammas, un tās var bez problēmām mērogot horizontāli. Visi dati tiek glabāti etcd pielāgotu Kubernetes resursu aprakstu veidā.
Arī Istio (joprojām eksperimentāls) ir iespēja darboties ārpus klastera un iespēja skatīties un izjaukt pakalpojumu atklāšanu starp vairākiem Kubernetes klasteriem. Jūs varat lasīt vairāk par šo .
Vairāku klasteru instalēšanai ņemiet vērā šādus ierobežojumus:
- Pod CIDR un pakalpojuma CIDR ir jābūt unikāliem visās kopās, un tie nedrīkst pārklāties.
- Visām CIDR pods ir jābūt pieejamām no jebkura CIDR pods starp klasteriem.
- Visiem Kubernetes API serveriem jābūt savstarpēji pieejamiem.
Šī ir sākotnējā informācija, kas palīdzēs jums sākt darbu ar Istio. Tomēr joprojām ir daudz nepilnību. Piemēram, ārējās trafika maršrutēšanas iespējas (ārpus klastera), pieejas blakusvāģu atkļūdošanai, profilēšana, miksera iestatīšana un pielāgotas miksera aizmugures rakstīšana, izsekošanas mehānisma iestatīšana un tā darbība, izmantojot sūtni.
To visu mēs apsvērsim turpmākajās publikācijās. Uzdodiet savus jautājumus, es centīšos tos aptvert.
Avots: www.habr.com