Què és ? Es tracta de l'anomenada malla de servei, una tecnologia que afegeix una capa d'abstracció a la xarxa. Interceptem tot o part del trànsit del clúster i realitzem un determinat conjunt d'operacions amb ell. Quin? Per exemple, fem un enrutament intel·ligent, o implementem l'enfocament del disjuntor, podem organitzar el "desplegament canari", canviant parcialment el trànsit a una nova versió del servei, o podem limitar les interaccions externes i controlar tots els viatges del clúster al xarxa externa. És possible establir regles de polítiques per controlar els viatges entre diferents microserveis. Finalment, podem obtenir tot el mapa d'interacció de la xarxa i fer que la col·lecció unificada de mètriques sigui totalment transparent per a les aplicacions.
Podeu llegir sobre el mecanisme de treball a . Istio és una eina realment potent que us permet resoldre moltes tasques i problemes. En aquest article, m'agradaria respondre les principals preguntes que solen sorgir en començar amb Istio. Això us ajudarà a tractar-ho més ràpidament.
Com funciona?
Istio consta de dues àrees principals: el pla de control i el pla de dades. El pla de control conté els components principals que garanteixen el correcte funcionament de la resta. En la versió actual (1.0) el pla de control té tres components principals: Pilot, Mixer, Citadel. No tindrem en compte Citadel, cal generar certificats per garantir un TLS mutu entre serveis. Fem una ullada més de prop al dispositiu i la finalitat de Pilot and Mixer.
Pilot és el principal component de control que distribueix tota la informació sobre el que tenim al clúster: serveis, els seus punts finals i regles d'encaminament (per exemple, regles per al desplegament de Canary o regles d'interruptor).
El mesclador és un component opcional del pla de control que ofereix la possibilitat de recopilar mètriques, registres i qualsevol informació sobre la interacció de la xarxa. També supervisa el compliment de les normes de la política i el compliment dels límits de tarifes.
El pla de dades s'implementa mitjançant contenidors proxy sidecar. Potent s'utilitza per defecte. . Es pot substituir per una altra implementació, com nginx (nginmesh).
Perquè Istio funcioni completament transparent a les aplicacions, hi ha un sistema d'injecció automàtica. La darrera implementació és adequada per a les versions de Kubernetes 1.9+ (webhook d'admissió mutacional). Per a les versions de Kubernetes 1.7, 1.8 és possible utilitzar l'Initializer.
Els contenidors sidecar estan connectats a Pilot mitjançant el protocol GRPC, que us permet optimitzar el model push per als canvis que es produeixen al clúster. GRPC s'utilitza a Envoy des de la versió 1.6, a Istio s'utilitza des de la versió 0.8 i és un agent pilot: un embolcall de golang sobre l'envoy que configura les opcions de llançament.
Pilot i Mixer són components completament sense estat, tot l'estat es manté a la memòria. La seva configuració s'estableix en forma de recursos personalitzats de Kubernetes, que s'emmagatzemen a etcd.
Istio-agent obté l'adreça del pilot i li obre un flux GRPC.
Com he dit, Istio implementa tota la funcionalitat completament transparent per a les aplicacions. A veure com. L'algoritme és aquest:
- Implementació d'una nova versió del servei.
- Depenent de l'enfocament d'injecció de contenidors sidecar, el contenidor istio-init i el contenidor istio-agent (enviat) s'afegeixen en l'etapa d'aplicació de la configuració, o ja es poden inserir manualment a la descripció de l'entitat Kubernetes Pod.
- El contenidor istio-init és un script que aplica les regles d'iptables al pod. Hi ha dues opcions per configurar el trànsit perquè s'embolica en un contenidor d'agent istio: utilitzar regles de redirecció d'iptables o . En el moment d'escriure, l'enfocament predeterminat és amb regles de redirecció. A istio-init, és possible configurar quin trànsit s'ha d'interceptar i enviar a istio-agent. Per exemple, per interceptar tot el trànsit entrant i sortint, cal establir els paràmetres
-iи-ben sentit*. Podeu especificar ports específics per interceptar. Per no interceptar una subxarxa específica, podeu especificar-la mitjançant el senyalador-x. - Després d'executar els contenidors d'inici, es llancen els principals, inclòs el pilot-agent (enviat). Es connecta al Pilot ja desplegat mitjançant GRPC i rep informació sobre tots els serveis i polítiques d'encaminament existents al clúster. Segons les dades rebudes, configura els clústers i els assigna directament als endpoints de les nostres aplicacions al clúster Kubernetes. També cal tenir en compte un punt important: l'envoy configura dinàmicament els oients (IP, parells de ports) que comença a escoltar. Per tant, quan les sol·licituds entren al pod, es redirigien mitjançant les regles de redirecció iptables al sidecar, l'envoy ja pot processar aquestes connexions amb èxit i entendre on s'ha de proxy més el trànsit. També en aquesta etapa s'envia informació al Mesclador, que veurem més endavant, i s'envien els intervals de traça.
Com a resultat, obtenim tota una xarxa de servidors intermediaris d'envoy que podem configurar des d'un punt (Pilot). Totes les sol·licituds entrants i sortints passen per enviat. A més, només s'intercepta el trànsit TCP. Això vol dir que la IP del servei de Kubernetes es resol mitjançant kube-dns sobre UDP sense canviar. Després, després de la resolució, la sol·licitud de sortida és interceptada i processada per l'enviat, que ja decideix a quin punt final s'ha d'enviar la sol·licitud (o no enviada, en el cas de les polítiques d'accés o l'interruptor de l'algorisme).
Hem descobert Pilot, ara hem d'entendre com funciona Mixer i per què es necessita. Podeu llegir-ne la documentació oficial .
Mixer en la seva forma actual consta de dos components: istio-telemetria, istio-policy (abans de la versió 0.8 era un component istio-mesclador). Tots dos són mescladors, cadascun dels quals és responsable de la seva pròpia tasca. Istio telemetry rep informació sobre qui va a on i amb quins paràmetres dels contenidors d'informes sidecar via GRPC. Istio-policy accepta les sol·licituds de comprovació per verificar que es compleixen les regles de la política. Les comprovacions de Poilicy, per descomptat, no es realitzen per a totes les sol·licituds, sinó que s'emmagatzemen en memòria cau al client (al sidecar) durant un temps determinat. Les comprovacions d'informes s'envien com a sol·licituds per lots. Vegem com configurar i quins paràmetres s'han d'enviar una mica més tard.
Se suposa que el mesclador és un component d'alta disponibilitat que garanteix un treball ininterromput en el muntatge i el processament de dades de telemetria. El sistema s'obté com a resultat com un buffer multinivell. Inicialment, les dades s'emmagatzemen al costat del sidecar dels contenidors, després al costat del mesclador i després s'envien als anomenats backends del mesclador. Com a resultat, si algun dels components del sistema falla, la memòria intermèdia creix i s'esborra després de restaurar el sistema. Els backends del mesclador són punts finals per enviar dades de telemetria: statsd, newrelic, etc. Podeu escriure el vostre propi backend, és bastant senzill, i veurem com fer-ho.
En resum, l'esquema per treballar amb istio-telemetria és el següent.
- El servei 1 envia una sol·licitud al servei 2.
- En sortir del servei 1, la sol·licitud s'embolica al seu propi sidecar.
- Sidecar enviat supervisa com la sol·licitud va al servei 2 i prepara la informació necessària.
- A continuació, l'envia a istio-telemetry mitjançant una sol·licitud d'informe.
- Istio-telemetry determina si aquest informe s'ha d'enviar als backends, a quines i quines dades s'han d'enviar.
- Istio-telemetry envia dades de l'informe al backend si cal.
Vegem ara com desplegar Istio al sistema, format només pels components principals (pilot i sidecar enviat).
Primer, mirem la configuració principal (malla) que llegeix 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
Tots els components de control principals (pla de control) es trobaran a l'espai de noms istio-system a Kubernetes.
Com a mínim, només hem de desplegar Pilot. Per a això farem servir
I configurarem manualment el sidecar d'injecció del contenidor.
Contenidor d'inici:
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
I sidecar:
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
Per tal que tot comenci amb èxit, heu de crear un ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, les descripcions del qual es poden trobar .
Com a resultat, el servei al qual injectem sidecar amb enviat hauria de començar amb èxit, rebre tots els descobriments del pilot i processar les sol·licituds.
És important entendre que tots els components del pla de control són aplicacions sense estat i es poden escalar horitzontalment sense problemes. Totes les dades s'emmagatzemen a etcd en forma de descripcions personalitzades dels recursos de Kubernetes.
A més, Istio (encara experimental) té la capacitat d'executar-se fora del clúster i la capacitat de veure i buscar el descobriment de serveis entre diversos clústers de Kubernetes. Podeu llegir més sobre això .
Per a una instal·lació de diversos clústers, tingueu en compte les limitacions següents:
- Pod CIDR i Service CIDR han de ser únics en tots els clústers i no s'han de superposar.
- S'ha de poder accedir a tots els pods CIDR des de qualsevol pods CIDR entre clústers.
- Tots els servidors de l'API de Kubernetes han de ser accessibles entre ells.
Aquesta és la informació inicial per ajudar-vos a començar amb Istio. No obstant això, encara hi ha moltes trampes. Per exemple, característiques d'encaminament del trànsit extern (fora del clúster), enfocaments per depurar sidecars, perfilar, configurar un mesclador i escriure un backend de mesclador personalitzat, configurar un mecanisme de traça i el seu funcionament mitjançant Envoy.
Tot això ho tindrem en compte en les següents publicacions. Feu les vostres preguntes, intentaré cobrir-les.
Font: www.habr.com