Milyen ? Ez az úgynevezett Service mesh, egy olyan technológia, amely egy absztrakciós réteget ad a hálózathoz. Elfogjuk a klaszter forgalmát vagy annak egy részét, és végrehajtunk vele bizonyos műveleteket. Melyik? Például intelligens útválasztást végzünk, vagy megvalósítjuk a megszakítós megközelítést, megszervezhetjük a „kanári telepítést”, részben átállítva a forgalmat a szolgáltatás új verziójára, vagy korlátozhatjuk a külső interakciókat, és ellenőrizhetjük az összes utat a klasztertől a külső hálózat. Lehetőség van házirendszabályok beállítására a különböző mikroszolgáltatások közötti utazások szabályozására. Végül megkaphatjuk a teljes hálózati interakciós térképet, és az egységes mérőszámgyűjteményt teljesen átláthatóvá tehetjük az alkalmazások számára.
A működési mechanizmusról itt olvashat . Az Istio egy igazán hatékony eszköz, amellyel számos feladatot és problémát megoldhat. Ebben a cikkben azokra a fő kérdésekre szeretnék választ adni, amelyek általában felmerülnek az Istio használatának megkezdésekor. Ez segít gyorsabban kezelni.
Működési elv
Az Istio két fő területből áll - a vezérlősíkból és az adatsíkból. A vezérlősík azokat a fő összetevőket tartalmazza, amelyek biztosítják a többi helyes működését. A jelenlegi verzióban (1.0) a vezérlősíknak három fő összetevője van: Pilot, Mixer, Citadella. A Citadelt nem vesszük figyelembe, tanúsítványok generálására van szükség a szolgáltatások közötti kölcsönös TLS biztosításához. Nézzük meg közelebbről a Pilot and Mixer eszközét és célját.
A Pilot a fő vezérlőelem, amely a fürtben található összes információt elosztja – szolgáltatások, végpontjaik és útválasztási szabályok (például a Canary-telepítési szabályok vagy a megszakítók szabályai).
A Mixer egy opcionális vezérlősík-összetevő, amely lehetővé teszi metrikák, naplók és a hálózati interakcióval kapcsolatos információk összegyűjtését. Felügyeli továbbá a szabályzati szabályok betartását és a díjhatárok betartását.
Az adatsík oldalkocsis proxy konténerek segítségével valósul meg. A Powerful alapértelmezés szerint használatos. . Helyettesíthető egy másik megvalósítással, például az nginx-szel (nginmesh).
Annak érdekében, hogy az Istio teljesen átláthatóan működjön az alkalmazások számára, van egy automatikus befecskendező rendszer. A legújabb megvalósítás a Kubernetes 1.9+ verzióihoz (mutációs beléptető webhook) alkalmas. A Kubernetes 1.7-es, 1.8-as verzióihoz lehetséges az Initializer használata.
Az oldalkocsis konténerek a GRPC protokoll segítségével csatlakoznak a Pilothoz, amely lehetővé teszi a push modell optimalizálását a fürtben bekövetkező változásokhoz. A GRPC-t az 1.6-os verzió óta használják az Envoy-ban, az Istio-ban a 0.8-as verzió óta használják, és egy pilot-agent - egy golang wrapper over envoy, amely konfigurálja az indítási beállításokat.
A Pilot és a Mixer teljesen állapot nélküli komponensek, minden állapot a memóriában tárolódik. Ezek konfigurációja Kubernetes egyéni erőforrások formájában van beállítva, amelyeket az etcd-ben tárolnak.
Az Istio-agent megkapja a Pilot címét, és megnyit egy GRPC adatfolyamot.
Mint mondtam, az Istio minden funkciót teljesen átlátható az alkalmazások számára. Lássuk hogyan. Az algoritmus a következő:
- A szolgáltatás új verziójának üzembe helyezése.
- Az oldalkocsis konténer befecskendezési megközelítésétől függően az istio-init konténer és az istio-agent tartály (küldött) a konfiguráció alkalmazásának szakaszában kerül hozzáadásra, vagy már manuálisan is beilleszthetők a Kubernetes Pod entitás leírásába.
- Az istio-init tároló egy olyan szkript, amely az iptables szabályokat alkalmazza a podra. Két lehetőség van a forgalom istio-agent tárolóba csomagolásának beállítására: iptables átirányítási szabályok használata, vagy . A cikk írásakor az alapértelmezett megközelítés átirányítási szabályokkal történik. Az istio-initben beállítható, hogy melyik forgalmat kell elfogni és elküldeni az istio-agentnek. Például az összes bejövő és kimenő forgalom lehallgatásához be kell állítania a paramétereket
-iи-bjelentésbe*. Megadhat konkrét portokat az elfogáshoz. Egy adott alhálózat elfogásának elkerülése érdekében a zászló segítségével megadhatja azt-x. - Az init konténerek végrehajtása után elindulnak a fő konténerek, köztük a pilóta-ügynök (küldött). A GRPC-n keresztül csatlakozik a már telepített Pilothoz, és információkat kap a fürt összes meglévő szolgáltatásáról és útválasztási szabályzatáról. A kapott adatok szerint konfigurálja a fürtöket, és közvetlenül hozzárendeli azokat a Kubernetes-fürtben lévő alkalmazásaink végpontjaihoz. Fontos megjegyezni egy fontos pontot is: az envoy dinamikusan konfigurálja azokat a hallgatókat (IP, port párok), amelyeket elkezd hallgatni. Ezért amikor a kérelmek belépnek a podba, és az oldalkocsiban lévő redirect iptables szabályok segítségével átirányítják őket, a küldött már sikeresen feldolgozhatja ezeket a kapcsolatokat, és megértheti, hogy hol kell tovább proxyzni a forgalmat. Ebben a szakaszban is elküldik az információkat a Mixernek, amelyet később megnézünk, és elküldik a nyomkövetési tartományokat.
Ennek eredményeként az envoy proxy szerverek teljes hálózatát kapjuk, amelyet egy pontról (Pilot) tudunk konfigurálni. Minden bejövő és kimenő kérés küldötten keresztül történik. Sőt, csak a TCP forgalmat fogják el. Ez azt jelenti, hogy a Kubernetes szolgáltatás IP-címe változtatás nélkül a kube-dns segítségével történik UDP-n keresztül. Ezután a feloldás után a kimenő kérelmet lefogja és feldolgozza a küldött, amely már eldönti, hogy a kérést melyik végpontra kell elküldeni (hozzáférési szabályzatok vagy az algoritmus megszakítója esetén nem).
Kitaláltuk a Pilotot, most meg kell értenünk, hogyan működik a Mixer, és miért van rá szükség. Elolvashatja a hivatalos dokumentációt .
A Mixer jelenlegi formájában két komponensből áll: istio-telemetria, istio-policy (a 0.8-as verzió előtt ez egy istio-mixer komponens volt). Mindkettő keverő, mindegyik felelős a saját feladatáért. Az Istio telemetria információkat kap arról, hogy ki hová megy és milyen paraméterekkel az oldalkocsis Report konténerekből a GRPC-n keresztül. Az Istio-policy elfogadja az ellenőrzési kéréseket annak ellenőrzésére, hogy teljesülnek-e a szabályzat szabályai. A politikaellenőrzést természetesen nem minden kérésre hajtják végre, hanem egy bizonyos ideig gyorsítótárazzák az ügyfélen (az oldalkocsiban). A jelentésellenőrzéseket a rendszer kötegelt kérésként küldi el. Nézzük meg, hogyan kell beállítani, és milyen paramétereket kell elküldeni egy kicsit később.
A Mixernek nagy rendelkezésre állású alkatrésznek kell lennie, amely biztosítja a telemetriai adatok összeállításának és feldolgozásának megszakítás nélküli munkáját. Ennek eredményeként a rendszer többszintű pufferként jön létre. Az adatok kezdetben a konténerek oldalkocsi oldalán, majd a keverőoldalon kerülnek pufferelésre, majd az úgynevezett mixer háttérrendszerekbe kerülnek. Ennek eredményeként, ha a rendszerelemek bármelyike meghibásodik, a puffer növekszik, és a rendszer visszaállítása után kiürül. A mixer háttérrendszerek a telemetriai adatok küldésének végpontjai: statsd, newrelic stb. Írhatsz saját backendet, ez elég egyszerű, majd meglátjuk, hogyan kell csinálni.
Összefoglalva, az isztio-telemetriával való munka séma a következő.
- Az 1. szolgáltatás kérést küld a 2. szolgáltatásnak.
- Az 1. szolgálatból való kilépéskor a kérés a saját oldalkocsijába kerül.
- Az oldalkocsis küldött figyeli, hogyan jut el a kérés a 2. szervizhez, és előkészíti a szükséges információkat.
- Ezután jelentéskéréssel elküldi az istio-telemetriának.
- Az Istio-telemetria határozza meg, hogy ezt a jelentést el kell-e küldeni a háttérrendszereknek, melyikre és milyen adatokat kell elküldeni.
- Az Istio-telemetria szükség esetén jelentésadatokat küld a háttérrendszernek.
Most pedig nézzük meg, hogyan telepítsük az Istiót a csak a fő komponensekből (pilóta és oldalkocsis küldött) álló rendszerbe.
Először nézzük meg a fő konfigurációt (hálót), amelyet a Pilot olvas:
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
Az összes fő vezérlőelem (vezérlősík) a Kubernetes névtér-istio-rendszerében található.
Legalább csak a Pilotot kell telepítenünk. Erre használjuk
És manuálisan konfiguráljuk a tartály befecskendező oldalkocsiját.
Init konténer:
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
És oldalkocsi:
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
Ahhoz, hogy minden sikeresen elinduljon létre kell hozni egy ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot szolgáltatást, melyek leírása megtalálható .
Ennek eredményeként sikeresen be kell indulnia annak a szolgáltatásnak, amelybe az oldalkocsit küldöttséggel illesztjük, megkapja az összes felfedezést a pilótától és feldolgozza a kéréseket.
Fontos megérteni, hogy az összes vezérlősík-komponens állapot nélküli alkalmazás, és probléma nélkül vízszintesen skálázható. Minden adat az etcd-ben tárolódik a Kubernetes-erőforrások egyéni leírásaként.
Ezenkívül az Istio (még kísérleti jelleggel) képes a fürtön kívül is futni, és képes figyelni, illetve több Kubernetes-fürt közötti szolgáltatás-felderítést is megtakarítani. Erről bővebben olvashat .
Többfürtös telepítés esetén vegye figyelembe a következő korlátozásokat:
- A pod CIDR-nek és a szolgáltatási CIDR-nek egyedinek kell lennie az összes fürtben, és nem fedheti át egymást.
- Minden CIDR Pod-nak elérhetőnek kell lennie a fürtök közötti bármely CIDR Podból.
- Minden Kubernetes API-kiszolgálónak elérhetőnek kell lennie egymás számára.
Ez a kezdeti információ, amely segít az Istio használatának megkezdésében. Azonban még mindig sok a buktató. Például a külső forgalom irányításának jellemzői (a klaszteren kívül), az oldalkocsik hibakeresésének megközelítései, a profilalkotás, a keverő beállítása és az egyéni keverő háttérprogram írása, a nyomkövetési mechanizmus beállítása és működése az envoy használatával.
Mindezt megvizsgáljuk a következő kiadványokban. Tedd fel kérdéseidet, megpróbálom megválaszolni őket.
Forrás: will.com