Çfarë është ? Kjo është e ashtuquajtura rrjetë e shërbimit, një teknologji që shton një shtresë abstraksioni në rrjet. Ne përgjojmë të gjithë ose një pjesë të trafikut në grup dhe kryejmë një grup të caktuar operacionesh me të. Cila? Për shembull, ne bëjmë rrugëzim inteligjent, ose zbatojmë qasjen e ndërprerësit, mund të organizojmë "vendosjen e kanarisë", duke kaluar pjesërisht trafikun në një version të ri të shërbimit, ose mund të kufizojmë ndërveprimet e jashtme dhe të kontrollojmë të gjitha udhëtimet nga grupi në rrjeti i jashtëm. Është e mundur të vendosen rregulla politikash për të kontrolluar udhëtimet ndërmjet mikroshërbimeve të ndryshme. Më në fund, ne mund të marrim të gjithë hartën e ndërveprimit të rrjetit dhe ta bëjmë koleksionin e unifikuar të metrikës plotësisht transparent për aplikacionet.
Ju mund të lexoni për mekanizmin e punës në . Istio është një mjet vërtet i fuqishëm që ju lejon të zgjidhni shumë detyra dhe probleme. Në këtë artikull, do të doja t'u përgjigjem pyetjeve kryesore që lindin zakonisht kur filloni me Istio. Kjo do t'ju ndihmojë ta përballoni atë më shpejt.
Parimi i operacionit
Istio përbëhet nga dy zona kryesore - rrafshi i kontrollit dhe rrafshi i të dhënave. Plani i kontrollit përmban përbërësit kryesorë që sigurojnë funksionimin e saktë të pjesës tjetër. Në versionin aktual (1.0) avioni i kontrollit ka tre komponentë kryesorë: Pilot, Mixer, Citadel. Ne nuk do ta konsiderojmë Citadel, është e nevojshme për të gjeneruar certifikata për të siguruar TLS të ndërsjellë midis shërbimeve. Le të hedhim një vështrim më të afërt në pajisjen dhe qëllimin e Pilot dhe Mixer.
Pilot është komponenti kryesor i kontrollit që shpërndan të gjithë informacionin rreth asaj që kemi në grup - shërbimet, pikat e tyre fundore dhe rregullat e rrugëzimit (për shembull, rregullat për vendosjen e Canary ose rregullat e ndërprerësit).
Mixer është një komponent opsional i planit të kontrollit që ofron aftësinë për të mbledhur metrikë, regjistra dhe çdo informacion rreth ndërveprimit të rrjetit. Ai gjithashtu monitoron pajtueshmërinë me rregullat e Politikës dhe pajtueshmërinë me kufijtë e tarifave.
Plani i të dhënave zbatohet duke përdorur kontejnerët proxy të kartës anësore. I fuqishëm përdoret si parazgjedhje. . Mund të zëvendësohet nga një implementim tjetër, siç është nginx (nginmesh).
Në mënyrë që Istio të funksionojë plotësisht transparente ndaj aplikacioneve, ekziston një sistem automatik i injektimit. Zbatimi i fundit është i përshtatshëm për versionet e Kubernetes 1.9+ (uebhook i pranimit mutacional). Për versionet 1.7, 1.8 të Kubernetes është e mundur të përdoret Initializer.
Kontejnerët anësore janë të lidhura me Pilot duke përdorur protokollin GRPC, i cili ju lejon të optimizoni modelin shtytës për ndryshimet që ndodhin në grup. GRPC është përdorur në Envoy që nga versioni 1.6, në Istio është përdorur që nga versioni 0.8 dhe është një agjent pilot - një mbështjellës golang mbi të dërguarin që konfiguron opsionet e nisjes.
Piloti dhe Mikseri janë komponentë plotësisht pa shtetësi, e gjithë gjendja ruhet në kujtesë. Konfigurimi për to është vendosur në formën e Kubernetes Custom Resources, të cilat ruhen në etcd.
Istio-agent merr adresën e Pilotit dhe hap një transmetim GRPC për të.
Siç thashë, Istio zbaton të gjithë funksionalitetin plotësisht transparent për aplikacionet. Le të shohim se si. Algoritmi është ky:
- Vendosja e një versioni të ri të shërbimit.
- Në varësi të qasjes së injektimit të kontejnerit anësor, kontejneri istio-init dhe kontejneri istio-agjent (i dërguari) shtohen në fazën e aplikimit të konfigurimit, ose ato tashmë mund të futen manualisht në përshkrimin e entitetit Kubernetes Pod.
- Kontejneri istio-init është një skript që zbaton rregullat iptables në pod. Ekzistojnë dy opsione për konfigurimin e trafikut që të mbështillet në një kontejner istio-agjent: përdorni rregullat e ridrejtimit iptables, ose . Në kohën e shkrimit, qasja e paracaktuar është me rregullat e ridrejtimit. Në istio-init, është e mundur të konfiguroni se cili trafik duhet të përgjohet dhe dërgohet te istio-agent. Për shembull, për të përgjuar të gjithë trafikun në hyrje dhe në dalje, duhet të vendosni parametrat
-iи-bnë kuptim*. Ju mund të specifikoni porte specifike për të përgjuar. Për të mos përgjuar një nënrrjet të caktuar, mund ta specifikoni duke përdorur flamurin-x. - Pasi të ekzekutohen kontejnerët fillestarë, lëshohen ato kryesore, përfshirë agjentin pilot (të dërguarin). Ai lidhet me Pilotin tashmë të vendosur nëpërmjet GRPC dhe merr informacion për të gjitha shërbimet ekzistuese dhe politikat e rrugëtimit në grup. Sipas të dhënave të marra, ai konfiguron grupimet dhe i cakton ato drejtpërdrejt në pikat fundore të aplikacioneve tona në grupimin Kubernetes. Është gjithashtu e nevojshme të theksohet një pikë e rëndësishme: i dërguari konfiguron në mënyrë dinamike dëgjuesit (IP, çifte portash) që fillon të dëgjojë. Prandaj, kur kërkesat hyjnë në pod, ridrejtohen duke përdorur rregullat e ridrejtimit iptables në karrigen anësore, i dërguari tashmë mund t'i përpunojë me sukses këto lidhje dhe të kuptojë se ku mund të përcaktojë më tej trafikun. Gjithashtu në këtë fazë, informacioni i dërgohet Mixer-it, të cilin do ta shikojmë më vonë dhe dërgohen hapësirat e gjurmimit.
Si rezultat, ne marrim një rrjet të tërë të serverëve proxy të dërguar që mund t'i konfigurojmë nga një pikë (Pilot). Të gjitha kërkesat hyrëse dhe dalëse kalojnë përmes të dërguarit. Për më tepër, vetëm trafiku TCP përgjohet. Kjo do të thotë që IP-ja e shërbimit Kubernetes zgjidhet duke përdorur kube-dns mbi UDP pa ndryshuar. Më pas, pas zgjidhjes, kërkesa dalëse përgjohet dhe përpunohet nga i dërguari, i cili tashmë vendos se në cilën pikë përfundimtare duhet të dërgohet kërkesa (ose të mos dërgohet, në rastin e politikave të aksesit ose ndërprerësit të qarkut të algoritmit).
Ne e kuptuam Pilotin, tani duhet të kuptojmë se si funksionon Mixer dhe pse është i nevojshëm. Ju mund të lexoni dokumentacionin zyrtar për të .
Mikseri në formën e tij aktuale përbëhet nga dy komponentë: istio-telemetria, istio-politika (para versionit 0.8 ishte një komponent istio-përzierës). Të dy janë mikser, secila prej të cilave është përgjegjëse për detyrën e vet. Telemetria Istio merr informacion se kush ku shkon dhe me çfarë parametrash nga kontejnerët e raportit të kartës anësore nëpërmjet GRPC. Istio-policy pranon kërkesat e Kontrollit për të verifikuar nëse rregullat e Politikës janë përmbushur. Kontrollet e politikave, natyrisht, nuk kryhen për çdo kërkesë, por ruhen te klienti (në karrigen anësore) për një kohë të caktuar. Kontrollet e raportit dërgohen si kërkesa grupore. Le të shohim se si të konfigurojmë dhe cilat parametra duhet të dërgohen pak më vonë.
Mixer supozohet të jetë një komponent shumë i disponueshëm që siguron punë të pandërprerë në montimin dhe përpunimin e të dhënave telemetrike. Sistemi është marrë si rezultat si një tampon me shumë nivele. Fillimisht, të dhënat futen në bufer në anën anësore të kontejnerëve, më pas në anën e mikserit dhe më pas dërgohen në të ashtuquajturat mbështetëse të mikserit. Si rezultat, nëse ndonjë nga komponentët e sistemit dështon, buferi rritet dhe shpërlahet pasi sistemi është restauruar. Backendet e mikserit janë pika fundore për dërgimin e të dhënave telemetrike: statsd, newrelic, etj. Ju mund të shkruani backend-in tuaj, është mjaft e thjeshtë, dhe ne do të shohim se si ta bëjmë atë.
Për ta përmbledhur, skema e punës me istio-telemetrinë është si më poshtë.
- Shërbimi 1 dërgon një kërkesë në shërbimin 2.
- Kur largoheni nga shërbimi 1, kërkesa mbështillet në karrigen e saj anësore.
- I dërguari anësor monitoron se si kërkesa shkon në shërbimin 2 dhe përgatit informacionin e nevojshëm.
- Më pas e dërgon atë në istio-telemetri duke përdorur një kërkesë Raporti.
- Istio-telemetria përcakton nëse ky Raport duhet të dërgohet në backend-et, ku dhe cilat të dhëna duhet të dërgohen.
- Istio-telemetry dërgon të dhënat e Raportit në backend nëse është e nevojshme.
Tani le të shohim se si të vendosim Istio në sistem, i përbërë vetëm nga komponentët kryesorë (Pilot dhe i dërguari i karriges anësore).
Së pari, le të shohim konfigurimin kryesor (rrjetën) që lexon 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
Të gjithë komponentët kryesorë të kontrollit (rrafshi i kontrollit) do të vendosen në istio-sistemin e hapësirës së emrave në Kubernetes.
Së paku, na duhet vetëm të vendosim Pilot. Për këtë përdorim
Dhe ne do të konfigurojmë manualisht kutinë anësore të injektimit të kontejnerit.
Kontejneri fillestar:
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
Dhe karroca anësore:
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
Në mënyrë që gjithçka të fillojë me sukses, ju duhet të krijoni një ServiceAccount, ClusterRole, ClusterRoleBinding, CRD për Pilot, përshkrimet e të cilave mund të gjenden .
Si rezultat, shërbimi në të cilin ne injektojmë karrocën anësore me të dërguarin duhet të fillojë me sukses, të marrë të gjitha zbulimet nga piloti dhe të përpunojë kërkesat.
Është e rëndësishme të kuptohet se të gjithë komponentët e planit të kontrollit janë aplikacione pa shtetësi dhe mund të shkallëzohen horizontalisht pa probleme. Të gjitha të dhënat ruhen në etcd në formën e përshkrimeve me porosi të burimeve të Kubernetes.
Gjithashtu, Istio (ende eksperimental) ka aftësinë për të kandiduar jashtë grupit dhe aftësinë për të parë dhe për të gjurmuar zbulimin e shërbimit midis disa grupimeve Kubernetes. Ju mund të lexoni më shumë për këtë .
Për një instalim me shumë grupe, kini parasysh kufizimet e mëposhtme:
- Pod CIDR dhe Service CIDR duhet të jenë unike në të gjitha grupimet dhe nuk duhet të mbivendosen.
- Të gjitha CIDR Pods duhet të jenë të aksesueshme nga çdo CIDR Pods midis grupimeve.
- Të gjithë serverët e Kubernetes API duhet të jenë të aksesueshëm për njëri-tjetrin.
Ky është informacioni fillestar për t'ju ndihmuar të filloni me Istio. Megjithatë, ka ende shumë gracka. Për shembull, veçoritë e drejtimit të trafikut të jashtëm (jashtë grupit), qasjet për korrigjimin e kornizave anësore, profilizimin, vendosjen e një mikseri dhe shkrimin e një fundi të personalizuar të mikserit, vendosjen e një mekanizmi gjurmues dhe funksionimin e tij duke përdorur të dërguarin.
Të gjitha këto do t'i shqyrtojmë në botimet e mëposhtme. Bëni pyetjet tuaja, unë do të përpiqem t'i mbuloj ato.
Burimi: www.habr.com