Co je ? Jedná se o takzvanou Service mesh, technologii, která po síti přidává vrstvu abstrakce. Zachycujeme veškerý nebo část provozu v clusteru a provádíme s ním určitou sadu operací. Který? Děláme například chytré směrování nebo implementujeme přístup jističů, můžeme zorganizovat „kanárkové nasazení“, částečné přepnutí provozu na novou verzi služby nebo můžeme omezit externí interakce a řídit všechny cesty z clusteru do externí síť. Je možné nastavit pravidla zásad pro řízení cest mezi různými mikroslužbami. Konečně můžeme získat celou mapu síťových interakcí a učinit jednotnou sbírku metrik zcela transparentní pro aplikace.
O mechanismu práce si můžete přečíst v . Istio je opravdu mocný nástroj, který vám umožní řešit mnoho úkolů a problémů. V tomto článku bych rád odpověděl na hlavní otázky, které obvykle vyvstávají, když začínáte s Istio. To vám pomůže se s tím rychleji vypořádat.
Princip činnosti
Istio se skládá ze dvou hlavních oblastí – řídicí roviny a datové roviny. Řídící rovina obsahuje hlavní komponenty, které zajišťují správnou funkci zbytku. V aktuální verzi (1.0) má řídicí rovina tři hlavní součásti: Pilot, Mixer, Citadel. Citadel nebudeme uvažovat, je potřeba vygenerovat certifikáty pro zajištění vzájemného TLS mezi službami. Pojďme se blíže podívat na zařízení a účel Pilot a Mixer.
Pilot je hlavní ovládací komponenta, která distribuuje všechny informace o tom, co v clusteru máme – služby, jejich koncové body a pravidla směrování (například pravidla pro nasazení Canary nebo pravidla pro jističe).
Mixer je volitelná komponenta řídicí roviny, která poskytuje možnost shromažďovat metriky, protokoly a jakékoli informace o síťové interakci. Sleduje také dodržování pravidel Politiky a dodržování limitů sazeb.
Datová rovina je implementována pomocí kontejnerů proxy postranních vozíků. Ve výchozím nastavení se používá Výkonný. . Může být nahrazen jinou implementací, jako je nginx (nginmesh).
Aby Istio fungovalo zcela transparentně pro aplikace, existuje automatický systém vstřikování. Nejnovější implementace je vhodná pro verze Kubernetes 1.9+ (webhook pro mutaci). Pro Kubernetes verze 1.7, 1.8 je možné použít Inicializátor.
Kontejnery postranních vozíků jsou připojeny k Pilotu pomocí protokolu GRPC, který vám umožňuje optimalizovat push model pro změny, ke kterým dochází v clusteru. GRPC se používá v Envoy od verze 1.6, v Istio se používá od verze 0.8 a je to pilot-agent - golang wrapper over envoy, který konfiguruje možnosti spuštění.
Pilot a Mixer jsou zcela bezstavové komponenty, všechny stavy jsou uchovávány v paměti. Konfigurace pro ně je nastavena ve formě Kubernetes Custom Resources, které jsou uloženy v etcd.
Istio-agent získá adresu pilota a otevře mu GRPC stream.
Jak jsem řekl, Istio implementuje všechny funkce zcela transparentní pro aplikace. Podívejme se jak. Algoritmus je tento:
- Nasazení nové verze služby.
- V závislosti na přístupu vstřikování kontejneru postranního vozíku se kontejner istio-init a kontejner istio-agent (envoy) přidají ve fázi aplikace konfigurace, nebo je lze již ručně vložit do popisu entity Kubernetes Pod.
- Kontejner istio-init je skript, který aplikuje pravidla iptables na pod. Existují dvě možnosti konfigurace provozu, který má být zabalen do kontejneru istio-agent: použijte pravidla přesměrování iptables nebo . V době psaní tohoto článku je výchozí přístup s pravidly přesměrování. V istio-init je možné nakonfigurovat, který provoz má být zachycen a odeslán do istio-agent. Chcete-li například zachytit veškerý příchozí a veškerý odchozí provoz, musíte nastavit parametry
-iи-bdo smyslu*. Můžete určit konkrétní porty, které se mají zachytit. Aby nedošlo k zachycení konkrétní podsítě, můžete ji zadat pomocí příznaku-x. - Po provedení init kontejnerů jsou spuštěny ty hlavní, včetně pilota-agenta (envoy). Připojuje se k již nasazenému Pilotu přes GRPC a přijímá informace o všech existujících službách a směrovacích zásadách v clusteru. Podle obdržených dat nakonfiguruje clustery a přiřadí je přímo ke koncovým bodům našich aplikací v clusteru Kubernetes. Je také nutné poznamenat důležitý bod: envoy dynamicky konfiguruje posluchače (IP, páry portů), které začne naslouchat. Když tedy požadavky vstoupí do podu, jsou přesměrovány pomocí pravidel přesměrování iptables v postranním vozíku, může vyslanec již úspěšně zpracovat tato připojení a pochopit, kde dále proxy provozovat. V této fázi jsou také odesílány informace do Mixeru, na který se podíváme později, a jsou odesílány trasovací úseky.
Výsledkem je, že získáme celou síť vyslaných proxy serverů, které můžeme konfigurovat z jednoho bodu (Pilot). Všechny příchozí a odchozí požadavky procházejí přes Envoy. Navíc je zachycován pouze provoz TCP. To znamená, že IP služby Kubernetes se řeší pomocí kube-dns přes UDP beze změny. Poté, po vyřešení, je odchozí požadavek zachycen a zpracován vyslancem, který již rozhoduje, na který koncový bod má být požadavek odeslán (nebo neodeslán, v případě přístupových politik nebo jističe algoritmu).
Přišli jsme na Pilota, teď musíme pochopit, jak Mixer funguje a proč je potřeba. Můžete si k němu přečíst oficiální dokumentaci .
Mixer se v současné podobě skládá ze dvou komponent: istio-telemetry, istio-policy (před verzí 0.8 to byla jedna komponenta istio-mixer). Oba jsou mixéry, z nichž každý je zodpovědný za svůj vlastní úkol. Telemetrie Istio přijímá informace o tom, kdo kam a s jakými parametry jede z kontejnerů sidecar Report přes GRPC. Istio-policy přijímá požadavky na kontrolu, aby ověřil, že jsou splněna pravidla zásad. Kontroly zásad se samozřejmě neprovádějí u každého požadavku, ale jsou po určitou dobu ukládány do mezipaměti klienta (v postranním vozíku). Kontroly sestav jsou odesílány jako dávkové požadavky. Podívejme se, jak nakonfigurovat a jaké parametry by měly být odeslány o něco později.
Mixer má být vysoce dostupnou komponentou, která zajišťuje nepřetržitou práci na sestavování a zpracování telemetrických dat. Systém je získán jako víceúrovňový buffer. Zpočátku jsou data ukládána do vyrovnávací paměti na straně postranního vozíku kontejnerů, poté na straně směšovače a poté odeslána do takzvaných backendů směšovače. Výsledkem je, že pokud některá ze součástí systému selže, vyrovnávací paměť se zvětší a po obnovení systému se vyprázdní. Backendy mixéru jsou koncové body pro odesílání telemetrických dat: statsd, newrelic atd. Můžete si napsat svůj vlastní backend, je to docela jednoduché a uvidíme, jak na to.
Abychom to shrnuli, schéma pro práci s istio-telemetrií je následující.
- Služba 1 odešle požadavek službě 2.
- Při odjezdu ze služby 1 je požadavek zabalen do vlastního postranního vozíku.
- Vyslanec postranního vozíku sleduje, jak žádost prochází službou 2, a připravuje potřebné informace.
- Poté jej odešle do istio-telemetrie pomocí požadavku na zprávu.
- Istio-telemetrie určuje, zda má být tato zpráva odeslána do backendů, na které a jaká data se mají odesílat.
- Istio-telemetry v případě potřeby odesílá data sestav do backendu.
Nyní se podívejme, jak Istio nasadit do systému, složeného pouze z hlavních komponent (Pilot a vyslanec sajdkáry).
Nejprve se podívejme na hlavní konfiguraci (síť), kterou Pilot čte:
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šechny hlavní ovládací komponenty (ovládací rovina) budou umístěny v jmenném prostoru istio-system v Kubernetes.
Minimálně potřebujeme nasadit pouze Pilota. K tomu používáme
A ručně nakonfigurujeme vstřikovací postranní vozík kontejneru.
Počáteční kontejner:
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 vše začalo úspěšně, je potřeba vytvořit ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, jejichž popisy naleznete .
Výsledkem je, že služba, do které vložíme postranní vozík s vyslancem, by se měla úspěšně spustit, přijmout všechna zjištění od pilota a zpracovat požadavky.
Je důležité pochopit, že všechny komponenty řídicí roviny jsou bezstavové aplikace a lze je bez problémů horizontálně škálovat. Všechna data jsou uložena v etcd ve formě vlastních popisů zdrojů Kubernetes.
Istio (stále experimentální) má také schopnost běžet mimo cluster a schopnost sledovat a tápavě vyhledávat služby mezi několika clustery Kubernetes. Můžete si o tom přečíst více .
U instalace s více clustery mějte na paměti následující omezení:
- Pod CIDR a Service CIDR musí být jedinečné napříč všemi clustery a nesmí se překrývat.
- Všechny CIDR Pody musí být přístupné ze všech CIDR Podů mezi clustery.
- Všechny servery Kubernetes API musí být vzájemně přístupné.
Toto jsou počáteční informace, které vám pomohou začít s Istio. Stále však existuje mnoho úskalí. Například funkce směrování externího provozu (mimo cluster), přístupy k ladění postranních vozíků, profilování, nastavení mixu a psaní vlastního backendu mixu, nastavení mechanismu sledování a jeho fungování pomocí envoy.
To vše budeme zvažovat v následujících publikacích. Ptejte se, pokusím se je pokrýt.
Zdroj: www.habr.com