Kaj je ? To je tako imenovana Service Mesh, tehnologija, ki doda plast abstrakcije v omrežje. V gruči prestrežemo ves ali del prometa in z njim izvajamo določen niz operacij. Kateri? Na primer, naredimo pametno usmerjanje ali implementiramo pristop odklopnika, lahko organiziramo "kanarčkovo uvajanje", delno preklopimo promet na novo različico storitve, ali pa lahko omejimo zunanje interakcije in nadzorujemo vsa potovanja iz gruče v zunanje omrežje. Možno je nastaviti pravila pravilnika za nadzor potovanj med različnimi mikro storitvami. Končno lahko dobimo celoten zemljevid omrežne interakcije in naredimo enotno zbirko meritev popolnoma pregledno za aplikacije.
O mehanizmu delovanja si lahko preberete v . Istio je res zmogljivo orodje, ki vam omogoča reševanje številnih nalog in težav. V tem članku bi rad odgovoril na glavna vprašanja, ki se običajno pojavijo, ko začnete uporabljati Istio. Tako se boste hitreje spopadli s tem.
Princip delovanja
Istio je sestavljen iz dveh glavnih območij - nadzorne ravnine in podatkovne ravnine. Krmilna ravnina vsebuje glavne komponente, ki zagotavljajo pravilno delovanje ostalih. V trenutni različici (1.0) ima krmilna ravnina tri glavne komponente: Pilot, Mixer, Citadel. Citadel ne bomo upoštevali, potrebno je ustvariti certifikate za zagotavljanje medsebojnega TLS med storitvami. Oglejmo si podrobneje napravo in namen Pilota in Mešalnika.
Pilot je glavna nadzorna komponenta, ki distribuira vse informacije o tem, kaj imamo v gruči – storitve, njihove končne točke in pravila usmerjanja (na primer pravila za uvedbo Canary ali pravila za odklopnike).
Mešalnik je izbirna komponenta nadzorne ravnine, ki omogoča zbiranje meritev, dnevnikov in vseh informacij o omrežni interakciji. Prav tako spremlja skladnost s pravili politike in skladnost z omejitvami tečajev.
Podatkovna ravnina je implementirana s pomožnimi vsebniki sidecar. Privzeto se uporablja Powerful. . Lahko se nadomesti z drugo izvedbo, kot je nginx (nginmesh).
Da Istio deluje popolnoma pregledno za aplikacije, je na voljo sistem samodejnega vbrizgavanja. Najnovejša izvedba je primerna za različice Kubernetes 1.9+ (mutacijski sprejemni spletni kavelj). Za Kubernetes različice 1.7, 1.8 je mogoče uporabiti inicializator.
Zabojniki Sidecar so povezani s Pilotom s pomočjo protokola GRPC, ki vam omogoča optimizacijo potisnega modela za spremembe, ki se pojavljajo v gruči. GRPC se uporablja v Envoy od različice 1.6, v Istiu pa se uporablja od različice 0.8 in je pilot-agent - golang ovoj nad envoy, ki konfigurira možnosti zagona.
Pilot in Mixer sta komponenti brez stanja, vsa stanja so shranjena v pomnilniku. Konfiguracija zanje je nastavljena v obliki Kubernetes Custom Resources, ki so shranjeni v etcd.
Istio-agent dobi naslov pilota in mu odpre tok GRPC.
Kot sem rekel, Istio implementira vse funkcionalnosti popolnoma pregledno za aplikacije. Poglejmo, kako. Algoritem je naslednji:
- Uvajanje nove različice storitve.
- Odvisno od pristopa vbrizgavanja vsebnika bočne prikolice sta vsebnik istio-init in vsebnik istio-agent (odposlanec) dodana na stopnji uporabe konfiguracije ali pa ju je mogoče že ročno vstaviti v opis entitete Kubernetes Pod.
- Vsebnik istio-init je skript, ki uveljavi pravila iptables za pod. Obstajata dve možnosti za konfiguracijo prometa, ki bo ovit v vsebnik istio-agent: uporabite pravila preusmeritve iptables ali . V času pisanja je privzeti pristop s pravili preusmeritve. V istio-init je mogoče konfigurirati, kateri promet naj se prestreže in pošlje istio-agentu. Na primer, če želite prestreči ves dohodni in ves odhodni promet, morate nastaviti parametre
-iи-bv pomen*. Določite lahko posebna vrata za prestrezanje. Da ne bi prestregli določenega podomrežja, ga lahko določite z zastavico-x. - Po izvedbi init vsebnikov se zaženejo glavni, vključno s pilotnim agentom (odposlancem). Povezuje se z že nameščenim pilotom preko GRPC in prejema informacije o vseh obstoječih storitvah in politikah usmerjanja v gruči. Glede na prejete podatke konfigurira gruče in jih dodeli neposredno končnim točkam naših aplikacij v gruči Kubernetes. Upoštevati je treba tudi pomembno točko: envoy dinamično konfigurira poslušalce (IP, pari vrat), ki jih začne poslušati. Ko torej zahteve vstopijo v pod, so preusmerjene z uporabo pravil za preusmeritev iptables v stranski prikolici, lahko envoy že uspešno obdela te povezave in razume, kam naj še posreduje promet. Tudi na tej stopnji se informacije pošljejo mešalniku, ki si ga bomo ogledali pozneje, in pošljejo se razponi sledenja.
Kot rezultat dobimo celotno mrežo proxy strežnikov envoy, ki jih lahko konfiguriramo iz ene točke (Pilot). Vse dohodne in odhodne zahteve gredo skozi odposlanca. Poleg tega je prestrežen le promet TCP. To pomeni, da je IP storitve Kubernetes razrešen z uporabo kube-dns prek UDP brez spreminjanja. Potem, po razrešitvi, odhodno zahtevo prestreže in obdela envoy, ki se že odloči, kateri končni točki naj bo zahteva poslana (ali ne poslana, v primeru politik dostopa ali odklopnika algoritma).
Pilot smo razumeli, zdaj moramo razumeti, kako deluje Mixer in zakaj je potreben. Zanj lahko preberete uradno dokumentacijo .
Mešalnik v trenutni obliki je sestavljen iz dveh komponent: istio-telemetrija, istio-policy (pred različico 0.8 je bila ena komponenta istio-mixer). Oba sta mešalnika, vsaka za svojo nalogo. Istio telemetrija prejme informacije o tem, kdo gre kam in s kakšnimi parametri iz vsebnikov stranskih poročil prek GRPC. Istio-policy sprejema zahteve za preverjanje, da preveri, ali so pravila pravilnika izpolnjena. Preverjanja pravilnika se seveda ne izvajajo za vsako zahtevo, ampak so za določen čas predpomnjena na odjemalcu (v stranski prikolici). Pregledi poročil se pošljejo kot paketne zahteve. Poglejmo, kako konfigurirati in katere parametre je treba poslati malo kasneje.
Mixer naj bi bil visoko razpoložljiva komponenta, ki zagotavlja nemoteno delo pri sestavljanju in obdelavi telemetričnih podatkov. Sistem dobimo kot rezultat večnivojskega medpomnilnika. Sprva se podatki shranijo v medpomnilnik na stranski strani zabojnikov, nato na strani mešalnika, nato pa se pošljejo v tako imenovana zaledja mešalnika. Posledično, če katera od komponent sistema odpove, se vmesni pomnilnik poveča in se po obnovitvi sistema izprazni. Zaledja mešalnika so končne točke za pošiljanje telemetričnih podatkov: statsd, newrelic itd. Lahko napišete svoje lastno zaledje, je precej preprosto, in videli bomo, kako to narediti.
Če povzamem, shema za delo z istio-telemetrijo je naslednja.
- Storitev 1 pošlje zahtevo storitvi 2.
- Ko zapusti storitev 1, je zahteva zavita v svojo prikolico.
- Sidecar Envoy spremlja, kako gre zahteva do storitve 2, in pripravlja potrebne informacije.
- Nato ga pošlje istio-telemetriji z uporabo zahteve za poročilo.
- Istio-telemetrija določa, ali naj se to poročilo pošlje zaledju, katerim in kateri podatki naj se pošljejo.
- Istio-telemetrija po potrebi pošlje podatke poročila v zaledje.
Zdaj pa poglejmo, kako namestiti Istio v sistem, ki je sestavljen samo iz glavnih komponent (Pilot in sidecar envoy).
Najprej si poglejmo glavno konfiguracijo (mrežo), ki jo Pilot bere:
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
Vse glavne nadzorne komponente (nadzorna ravnina) se bodo nahajale v imenskem prostoru istio-system v Kubernetesu.
Najmanj moramo samo razmestiti Pilot. Za to uporabljamo
Ročno bomo konfigurirali stransko prikolico posode za vbrizgavanje.
Začetni vsebnik:
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
In 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
Da se bo vse skupaj uspešno začelo, morate ustvariti ServiceAccount, ClusterRole, ClusterRoleBinding, CRD za Pilot, katerih opise najdete .
Posledično bi se morala storitev, v katero vbrizgamo stransko prikolico z odposlancem, uspešno zagnati, prejeti vsa odkritja pilota in obdelati zahteve.
Pomembno je razumeti, da so vse komponente nadzorne ravnine aplikacije brez stanja in jih je mogoče brez težav vodoravno prilagoditi. Vsi podatki so shranjeni v etcd v obliki prilagojenih opisov virov Kubernetes.
Prav tako ima Istio (še vedno eksperimentalno) možnost izvajanja zunaj gruče ter možnost opazovanja in brskanja po odkrivanju storitev med več gručami Kubernetes. Več o tem si lahko preberete .
Za namestitev z več gručami upoštevajte naslednje omejitve:
- Pod CIDR in storitveni CIDR morata biti edinstvena v vseh gručah in se ne smeta prekrivati.
- Vsi Podi CIDR morajo biti dostopni iz katerega koli Poda CIDR med gručami.
- Vsi strežniki Kubernetes API morajo biti dostopni drug drugemu.
To so začetne informacije, ki vam bodo pomagale začeti uporabljati Istio. Vendar pa je še vedno veliko pasti. Na primer funkcije usmerjanja zunanjega prometa (zunaj gruče), pristopi k odpravljanju napak stranskih prikolic, profiliranje, nastavitev mešalnika in pisanje zaledja mešalnika po meri, nastavitev mehanizma sledenja in njegovo delovanje z uporabo envoyja.
Vse to bomo obravnavali v naslednjih publikacijah. Postavite svoja vprašanja, poskušal jih bom pokriti.
Vir: www.habr.com