Čo je ? Ide o takzvanú Service mesh, technológiu, ktorá pridáva vrstvu abstrakcie cez sieť. Zachytávame celú alebo časť prevádzky v klastri a vykonávame s ňou určitý súbor operácií. Ktorý? Robíme napríklad smart routing alebo implementujeme ističový prístup, vieme zorganizovať „kanárske nasadenie“, čiastočné prepnutie prevádzky na novú verziu služby alebo vieme obmedziť externé interakcie a kontrolovať všetky výlety z klastra do externá sieť. Je možné nastaviť pravidlá politiky na riadenie ciest medzi rôznymi mikroslužbami. Nakoniec môžeme získať celú mapu sieťových interakcií a úplne sprehľadniť jednotnú kolekciu metrík pre aplikácie.
O mechanizme práce si môžete prečítať v . Istio je skutočne mocný nástroj, ktorý vám umožní vyriešiť množstvo úloh a problémov. V tomto článku by som rád odpovedal na hlavné otázky, ktoré sa zvyčajne vynárajú, keď začínate s Istio. To vám pomôže rýchlejšie sa s tým vysporiadať.
Princíp činnosti
Istio pozostáva z dvoch hlavných oblastí – riadiacej roviny a dátovej roviny. Riadiaca rovina obsahuje hlavné komponenty, ktoré zabezpečujú správnu činnosť zvyšku. V aktuálnej verzii (1.0) má riadiaca rovina tri hlavné komponenty: Pilot, Mixer, Citadel. Citadel nebudeme zvažovať, je potrebné vygenerovať certifikáty na zabezpečenie vzájomného TLS medzi službami. Pozrime sa bližšie na zariadenie a účel programu Pilot a Mixer.
Pilot je hlavný riadiaci komponent, ktorý distribuuje všetky informácie o tom, čo máme v klastri – služby, ich koncové body a pravidlá smerovania (napríklad pravidlá pre nasadenie Canary alebo pravidlá ističov).
Mixer je voliteľný komponent riadiacej roviny, ktorý poskytuje možnosť zhromažďovať metriky, protokoly a akékoľvek informácie o interakcii so sieťou. Taktiež monitoruje dodržiavanie pravidiel politiky a dodržiavanie limitov sadzieb.
Dátová rovina je implementovaná pomocou kontajnerov proxy postranných vozíkov. Predvolene sa používa možnosť Výkonný. . Môže byť nahradený inou implementáciou, ako je nginx (nginmesh).
Aby Istio fungovalo úplne transparentne pre aplikácie, existuje automatický vstrekovací systém. Najnovšia implementácia je vhodná pre verzie Kubernetes 1.9+ (webhook s mutáciou). Pre Kubernetes verzie 1.7, 1.8 je možné použiť Inicializátor.
Sidecar kontajnery sú pripojené k Pilot pomocou protokolu GRPC, ktorý vám umožňuje optimalizovať push model pre zmeny vyskytujúce sa v klastri. GRPC sa používa v Envoy od verzie 1.6, v Istio sa používa od verzie 0.8 a je to pilot-agent – golang wrapper over envoy, ktorý konfiguruje možnosti spustenia.
Pilot a Mixer sú úplne bezstavové komponenty, všetky stavy sú uložené v pamäti. Konfigurácia pre nich je nastavená vo forme Kubernetes Custom Resources, ktoré sú uložené v etcd.
Istio-agent získa adresu pilota a otvorí mu GRPC stream.
Ako som povedal, Istio implementuje všetky funkcie úplne transparentné pre aplikácie. Pozrime sa ako. Algoritmus je tento:
- Nasadenie novej verzie služby.
- V závislosti od prístupu vstrekovania kontajnera postranného vozíka sa kontajner istio-init a kontajner istio-agent (envoy) pridajú vo fáze aplikácie konfigurácie alebo ich už možno manuálne vložiť do popisu entity Kubernetes Pod.
- Kontajner istio-init je skript, ktorý aplikuje pravidlá iptables na modul. Existujú dve možnosti konfigurácie prenosu, ktorý sa má zabaliť do kontajnera istio-agent: použite pravidlá presmerovania iptables alebo . V čase písania tohto článku je predvolený prístup s pravidlami presmerovania. V istio-init je možné nakonfigurovať, ktorá prevádzka má byť zachytená a odoslaná istio-agentovi. Napríklad, aby ste mohli zachytiť všetku prichádzajúcu a všetku odchádzajúcu prevádzku, musíte nastaviť parametre
-iи-bdo významu*. Môžete zadať konkrétne porty, ktoré sa majú zachytiť. Aby ste nezachytili konkrétnu podsieť, môžete ju zadať pomocou príznaku-x. - Po vykonaní init kontajnerov sa spustia hlavné, vrátane pilota-agenta (vyslanec). Cez GRPC sa pripája k už nasadenému Pilotu a dostáva informácie o všetkých existujúcich službách a politikách smerovania v klastri. Podľa prijatých údajov nakonfiguruje klastre a priradí ich priamo ku koncovým bodom našich aplikácií v klastri Kubernetes. Je tiež potrebné poznamenať dôležitý bod: envoy dynamicky konfiguruje poslucháčov (IP, páry portov), ktoré začne počúvať. Preto, keď požiadavky vstúpia do pod, sú presmerované pomocou pravidiel presmerovania iptables v postrannom vozíku, vyslanec už môže úspešne spracovať tieto pripojenia a pochopiť, kde ďalej proxy prevádzkovať. Aj v tejto fáze sa informácie odošlú do mixéra, na ktorý sa pozrieme neskôr, a odošlú sa rozsahy sledovania.
Výsledkom je, že získame celú sieť vyslaných proxy serverov, ktoré môžeme konfigurovať z jedného bodu (pilot). Všetky prichádzajúce a odchádzajúce požiadavky prechádzajú cez vyslanca. Okrem toho je zachytená iba prevádzka TCP. To znamená, že IP služby Kubernetes sa rieši pomocou kube-dns cez UDP bez zmeny. Potom, po vyriešení, odchádzajúca požiadavka je zachytená a spracovaná vyslancom, ktorý už rozhodne, na ktorý koncový bod má byť požiadavka zaslaná (alebo nie odoslaná, v prípade prístupových politík alebo ističa algoritmu).
Prišli sme na Pilot, teraz musíme pochopiť, ako Mixer funguje a prečo je to potrebné. Môžete si prečítať oficiálnu dokumentáciu .
Mixer v súčasnej podobe pozostáva z dvoch komponentov: istio-telemetry, istio-policy (pred verziou 0.8 to bol jeden komponent istio-mixer). Obaja sú miešači, z ktorých každý je zodpovedný za svoju vlastnú úlohu. Telemetria Istio prijíma informácie o tom, kto kam a s akými parametrami ide, z kontajnerov Sidecar Report cez GRPC. Istio-policy akceptuje požiadavky na kontrolu na overenie, či sú splnené pravidlá politiky. Kontroly zásad sa, samozrejme, nevykonávajú pri každej požiadavke, ale sú na určitý čas uložené v pamäti klienta (v postrannom vozíku). Kontroly výkazov sa odosielajú ako dávkové požiadavky. Pozrime sa, ako nakonfigurovať a aké parametre by sa mali odoslať o niečo neskôr.
Mixer má byť vysoko dostupný komponent, ktorý zabezpečuje nepretržitú prácu na zostavovaní a spracovaní telemetrických dát. Systém sa získa ako viacúrovňová vyrovnávacia pamäť. Spočiatku sa údaje ukladajú do vyrovnávacej pamäte na strane postranného vozíka kontajnerov, potom na strane mixéra a potom sa odosielajú do takzvaných koncových zariadení mixéra. V dôsledku toho, ak niektorý zo systémových komponentov zlyhá, vyrovnávacia pamäť sa zväčší a po obnovení systému sa vyprázdni. Backendy mixéra sú koncové body na odosielanie telemetrických údajov: statsd, newrelic atď. Môžete si napísať svoj vlastný backend, je to celkom jednoduché a uvidíme, ako na to.
Aby sme to zhrnuli, schéma práce s istio-telemetriou je nasledovná.
- Služba 1 odošle požiadavku službe 2.
- Pri odchode zo služby 1 sa požiadavka zabalí do vlastného postranného vozíka.
- Vyslanec postranného vozíka sleduje, ako žiadosť prechádza do služby 2 a pripravuje potrebné informácie.
- Potom ho odošle do itio-telemetrie pomocou požiadavky na správu.
- Istio-telemetria určuje, či má byť táto správa odoslaná do backendov, do ktorých a aké údaje sa majú posielať.
- Istio-telemetria v prípade potreby odosiela údaje správy do backendu.
Teraz sa pozrime, ako nasadiť Istio do systému, pozostávajúceho len z hlavných komponentov (Pilot a vyslanec sajdkáry).
Najprv sa pozrime na hlavnú konfiguráciu (sieť), ktorú Pilot číta:
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
Všetky hlavné ovládacie komponenty (riadiaca rovina) budú umiestnené v mennom priestore istio-system v Kubernetes.
Minimálne potrebujeme nasadiť len Pilota. Na to používame
A ručne nakonfigurujeme vstrekovaciu sajdkáru kontajnera.
Počiatočný kontajner:
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
A postranný vozík:
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
Aby sa všetko úspešne rozbehlo, musíte si vytvoriť ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, ktorých popisy nájdete .
Výsledkom je, že služba, do ktorej vstrekneme postranný vozík s vyslancom, by sa mala úspešne spustiť, získať všetky zistenia od pilota a spracovať požiadavky.
Je dôležité pochopiť, že všetky komponenty riadiacej roviny sú bezstavové aplikácie a možno ich horizontálne škálovať bez problémov. Všetky údaje sú uložené v etcd vo forme vlastných popisov zdrojov Kubernetes.
Istio (stále experimentálne) má tiež schopnosť bežať mimo klastra a schopnosť sledovať a tápať pri objavovaní služieb medzi niekoľkými klastrami Kubernetes. Môžete si o tom prečítať viac .
Pri inštalácii s viacerými klastrami majte na pamäti nasledujúce obmedzenia:
- Pod CIDR a Service CIDR musia byť jedinečné vo všetkých klastroch a nesmú sa prekrývať.
- Všetky moduly CIDR musia byť prístupné zo všetkých modulov CIDR medzi klastrami.
- Všetky servery Kubernetes API musia byť navzájom prístupné.
Toto sú počiatočné informácie, ktoré vám pomôžu začať s Istio. Stále však existuje veľa nástrah. Napríklad funkcie smerovania externej prevádzky (mimo klastra), prístupy k ladeniu postranných vozíkov, profilovanie, nastavenie mixéra a napísanie vlastného backendu mixéra, nastavenie mechanizmu sledovania a jeho fungovanie pomocou envoy.
To všetko zvážime v nasledujúcich publikáciách. Pýtajte sa, pokúsim sa ich pokryť.
Zdroj: hab.com