Hvad er ? Dette er det såkaldte Service mesh, en teknologi, der tilføjer et lag af abstraktion over netværket. Vi opsnapper hele eller dele af trafikken i klyngen og udfører et bestemt sæt operationer med den. Hvilken en? For eksempel laver vi smart routing, eller vi implementerer strømafbrydertilgangen, vi kan organisere "kanarie-udrulning", delvist skifte trafik til en ny version af tjenesten, eller vi kan begrænse eksterne interaktioner og kontrollere alle ture fra klyngen til klyngen. eksternt netværk. Det er muligt at sætte politiske regler for at kontrollere ture mellem forskellige mikrotjenester. Endelig kan vi få hele netværksinteraktionskortet og gøre den forenede samling af metrics fuldstændig gennemsigtig for applikationer.
Du kan læse om arbejdsmekanismen i . Istio er et virkelig kraftfuldt værktøj, der giver dig mulighed for at løse mange opgaver og problemer. I denne artikel vil jeg gerne svare på de vigtigste spørgsmål, der normalt opstår, når man kommer i gang med Istio. Dette vil hjælpe dig med at håndtere det hurtigere.
Virkemåde
Istio består af to hovedområder - kontrolplanet og dataplanet. Kontrolplanet indeholder hovedkomponenterne, der sikrer den korrekte drift af resten. I den nuværende version (1.0) har kontrolplanet tre hovedkomponenter: Pilot, Mixer, Citadel. Vi vil ikke overveje Citadel, det er nødvendigt at generere certifikater for at sikre gensidig TLS mellem tjenester. Lad os se nærmere på enheden og formålet med Pilot og Mixer.
Pilot er hovedkontrolkomponenten, der distribuerer al information om, hvad vi har i klyngen - tjenester, deres endepunkter og routingregler (f.eks. regler for Canary-udrulning eller strømafbryderregler).
Mixer er en valgfri kontrolplankomponent, der giver mulighed for at indsamle metrikker, logfiler og enhver information om netværksinteraktion. Han overvåger også overholdelse af politikregler og overholdelse af satsgrænser.
Dataplanet implementeres ved hjælp af sidevogn proxy-containere. Powerful bruges som standard. . Det kan erstattes af en anden implementering, såsom nginx (nginmesh).
For at Istio kan arbejde fuldstændig transparent for applikationer, er der et automatisk indsprøjtningssystem. Den seneste implementering er velegnet til Kubernetes 1.9+ versioner (mutationsadgangswebhook). For Kubernetes versioner 1.7, 1.8 er det muligt at bruge Initializer.
Sidevognscontainere er forbundet til Pilot ved hjælp af GRPC-protokollen, som giver dig mulighed for at optimere push-modellen for ændringer, der sker i klyngen. GRPC har været brugt i Envoy siden version 1.6, i Istio har det været brugt siden version 0.8 og er en pilot-agent - en golang wrapper over envoy, der konfigurerer lanceringsmuligheder.
Pilot og Mixer er fuldstændig statsløse komponenter, alle tilstande gemmes i hukommelsen. Konfigurationen for dem er sat i form af Kubernetes Custom Resources, som er gemt i etcd.
Istio-agent får pilotens adresse og åbner en GRPC-stream til den.
Som sagt implementerer Istio al funktionalitet fuldstændig transparent for applikationer. Lad os se hvordan. Algoritmen er denne:
- Implementering af en ny version af tjenesten.
- Afhængigt af tilgangen til indsprøjtning af sidevognsbeholdere tilføjes istio-init-beholderen og istio-agent-beholderen (udsending) på tidspunktet for anvendelse af konfigurationen, eller de kan allerede indsættes manuelt i beskrivelsen af Kubernetes Pod-enheden.
- istio-init-beholderen er et script, der anvender iptables-reglerne på poden. Der er to muligheder for at konfigurere trafik til at blive pakket i en istio-agent container: brug iptables omdirigeringsregler, eller . I skrivende stund er standardtilgangen med omdirigeringsregler. I istio-init er det muligt at konfigurere hvilken trafik der skal opsnappes og sendes til istio-agent. For eksempel, for at opsnappe al indgående og al udgående trafik, skal du indstille parametrene
-iи-bi betydning*. Du kan angive specifikke porte, der skal opsnappes. For ikke at opsnappe et specifikt undernet, kan du angive det ved hjælp af flaget-x. - Efter at init-beholderne er udført, lanceres de vigtigste, inklusive pilot-agenten (udsending). Den opretter forbindelse til den allerede installerede pilot via GRPC og modtager information om alle eksisterende tjenester og routingpolitikker i klyngen. Ifølge de modtagne data konfigurerer han klyngerne og tildeler dem direkte til slutpunkterne for vores applikationer i Kubernetes-klyngen. Det er også nødvendigt at bemærke et vigtigt punkt: envoy konfigurerer dynamisk lyttere (IP, portpar), som den begynder at lytte til. Derfor, når anmodninger kommer ind i pod'en, omdirigeres ved hjælp af redirect iptables-reglerne i sidevognen, kan envoy allerede behandle disse forbindelser med succes og forstå, hvor trafikken skal videregives. Også på dette trin sendes information til Mixeren, som vi vil se på senere, og sporingsspænd sendes.
Som et resultat får vi et helt netværk af envoy proxy-servere, som vi kan konfigurere fra ét punkt (Pilot). Alle indgående og udgående anmodninger går gennem envoy. Desuden opfanges kun TCP-trafik. Dette betyder, at Kubernetes service IP løses ved hjælp af kube-dns over UDP uden at ændre sig. Derefter, efter beslutningen, bliver den udgående anmodning opfanget og behandlet af envoy, som allerede beslutter, hvilket endepunkt anmodningen skal sendes til (eller ikke sendes i tilfælde af adgangspolitikker eller algoritmens afbryder).
Vi fandt ud af Pilot, nu skal vi forstå, hvordan Mixer fungerer, og hvorfor det er nødvendigt. Du kan læse den officielle dokumentation for det .
Mixer i sin nuværende form består af to komponenter: istio-telemetri, istio-policy (før version 0.8 var det en istio-mixer-komponent). Begge er mixere, som hver især er ansvarlige for sin egen opgave. Istio telemetri modtager information om, hvem der går hvorhen og med hvilke parametre fra sidevognsrapportcontainere via GRPC. Istio-policy accepterer check-anmodninger for at bekræfte, at politikreglerne er opfyldt. Poilicy-tjek udføres naturligvis ikke for hver anmodning, men cachelagres på klienten (i sidevognen) i et bestemt tidsrum. Rapporttjek sendes som batchanmodninger. Lad os se, hvordan man konfigurerer, og hvilke parametre der skal sendes lidt senere.
Mixeren formodes at være en meget tilgængelig komponent, der sikrer uafbrudt arbejde med samling og behandling af telemetridata. Systemet opnås som et resultat som en multi-level buffer. Indledningsvis bufres data på sidevognssiden af containere, derefter på mixersiden og sendes derefter til de såkaldte mixer-backends. Som et resultat, hvis nogen af systemkomponenterne fejler, vokser bufferen og tømmes, efter at systemet er gendannet. Mixer-backends er endepunkter til afsendelse af telemetridata: statsd, newrelic osv. Du kan skrive din egen backend, det er ret simpelt, og vi vil se, hvordan du gør det.
For at opsummere er skemaet for at arbejde med istio-telemetri som følger.
- Service 1 sender en anmodning til service 2.
- Ved afgang af tjeneste 1 pakkes anmodningen ind i egen sidevogn.
- Sidecar envoy overvåger, hvordan anmodningen går til service 2 og forbereder de nødvendige oplysninger.
- Sender det derefter til istio-telemetri ved hjælp af en rapportanmodning.
- Istio-telemetri bestemmer, om denne rapport skal sendes til backends, til hvilke og hvilke data der skal sendes.
- Istio-telemetri sender rapportdata til backend, hvis det er nødvendigt.
Lad os nu se, hvordan Istio implementeres i systemet, der kun består af hovedkomponenterne (pilot og sidevognsudsending).
Lad os først se på hovedkonfigurationen (mesh), som Pilot læser:
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
Alle de vigtigste kontrolkomponenter (kontrolplan) vil være placeret i navneområdet istio-systemet i Kubernetes.
Som minimum behøver vi kun at indsætte Pilot. Til dette bruger vi
Og vi vil manuelt konfigurere containerens indsprøjtningssidevogn.
Init container:
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
Og sidevogn:
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
For at alt kan starte med succes, skal du oprette en ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, hvis beskrivelser kan findes .
Som et resultat heraf skulle den service, som vi injicerer sidevogn med envoy i, starte med succes, modtage al opdagelse fra piloten og behandle anmodninger.
Det er vigtigt at forstå, at alle kontrolplankomponenter er statsløse applikationer og kan skaleres vandret uden problemer. Alle data gemmes i etcd i form af brugerdefinerede beskrivelser af Kubernetes-ressourcer.
Desuden har Istio (stadig eksperimentel) evnen til at køre uden for klyngen og evnen til at se og fumle serviceopdagelse mellem flere Kubernetes-klynger. Du kan læse mere om dette .
For en multi-cluster installation skal du være opmærksom på følgende begrænsninger:
- Pod CIDR og Service CIDR skal være unikke på tværs af alle klynger og må ikke overlappe.
- Alle CIDR Pods skal være tilgængelige fra alle CIDR Pods mellem klynger.
- Alle Kubernetes API-servere skal være tilgængelige for hinanden.
Dette er den første information, der hjælper dig med at komme i gang med Istio. Der er dog stadig mange faldgruber. For eksempel funktioner i at dirigere ekstern trafik (uden for klyngen), tilgange til fejlretning af sidevogne, profilering, opsætning af en mixer og skrivning af en brugerdefineret mixer-backend, opsætning af en sporingsmekanisme og dens betjening ved hjælp af envoy.
Alt dette vil vi overveje i de følgende publikationer. Stil dine spørgsmål, jeg vil forsøge at dække dem.
Kilde: www.habr.com