Mikä on ? Tämä on niin kutsuttu palveluverkko, tekniikka, joka lisää verkon yli abstraktiokerroksen. Sieppaamme klusterin liikenteen kokonaan tai osan siitä ja suoritamme sen kanssa tiettyjä toimintoja. Kumpi? Teemme esimerkiksi älykästä reititystä tai toteutamme katkaisijalähestymistavan, voimme järjestää "kanaarin käyttöönoton", vaihtamalla liikenteen osittain uuteen palvelun versioon, tai voimme rajoittaa ulkoista vuorovaikutusta ja hallita kaikkia matkoja klusterista ulkoinen verkko. On mahdollista asettaa käytäntösääntöjä ohjaamaan matkoja eri mikropalvelujen välillä. Lopuksi voimme saada koko verkkovuorovaikutuskartan ja tehdä yhtenäisestä mittauskokoelmasta täysin läpinäkyvän sovelluksille.
Voit lukea työmekanismista . Istio on todella tehokas työkalu, jonka avulla voit ratkaista monia tehtäviä ja ongelmia. Tässä artikkelissa haluan vastata tärkeimpiin kysymyksiin, joita yleensä herää Istion käytön aloittamisen yhteydessä. Tämä auttaa sinua käsittelemään sitä nopeammin.
Toimintaperiaate
Istio koostuu kahdesta pääalueesta - ohjaustasosta ja datatasosta. Ohjaustaso sisältää pääkomponentit, jotka varmistavat muiden oikean toiminnan. Nykyisessä versiossa (1.0) ohjaustasossa on kolme pääkomponenttia: Pilot, Mixer, Citadel. Emme harkitse Citadelia, se on tarpeen luoda varmenteita palvelujen keskinäisen TLS:n varmistamiseksi. Katsotaanpa tarkemmin Pilotin ja Mixerin laitetta ja tarkoitusta.
Pilot on tärkein ohjauskomponentti, joka jakaa kaiken tiedon siitä, mitä meillä on klusterissa - palveluista, niiden päätepisteistä ja reitityssäännöistä (esimerkiksi Canaryn käyttöönoton säännöt tai katkaisijasäännöt).
Mixer on valinnainen ohjaustason komponentti, joka tarjoaa mahdollisuuden kerätä mittareita, lokeja ja kaikkea tietoa verkkovuorovaikutuksesta. Hän myös valvoo politiikan sääntöjen noudattamista ja korkorajojen noudattamista.
Datataso on toteutettu käyttämällä sivuvaunun välityspalvelinkonttia. Tehokas on oletuksena käytössä. . Se voidaan korvata toisella toteutuksella, kuten nginx (nginmesh).
Jotta Istio toimisi täysin läpinäkyvästi sovelluksille, on olemassa automaattinen ruiskutusjärjestelmä. Uusin toteutus sopii Kubernetes 1.9+ -versioille (mutaatioon pääsyn webhook). Kubernetesin versioille 1.7, 1.8 on mahdollista käyttää Initializeriä.
Sivuvaunukontit yhdistetään Pilotiin GRPC-protokollalla, jonka avulla voit optimoida push-mallin klusterissa tapahtuvia muutoksia varten. GRPC:tä on käytetty Envoyssa versiosta 1.6 lähtien, Istiossa sitä on käytetty versiosta 0.8 lähtien ja se on pilotti-agentti - golang wrapper over envoy, joka määrittää käynnistysasetukset.
Pilot ja Mixer ovat täysin tilattomia komponentteja, kaikki tila säilyy muistissa. Niiden kokoonpano määritetään Kubernetes Custom Resources -resurssien muodossa, jotka on tallennettu etcd:hen.
Istio-agentti saa Pilotin osoitteen ja avaa sille GRPC-virran.
Kuten sanoin, Istio toteuttaa kaikki toiminnot täysin läpinäkyvästi sovelluksille. Katsotaanpa miten. Algoritmi on tämä:
- Palvelun uuden version käyttöönotto.
- Sivuvaunukontin ruiskutusmenetelmästä riippuen istio-init-säiliö ja istio-agenttisäiliö (lähettilään) lisätään konfiguraation käyttöönottovaiheessa tai ne voidaan jo lisätä manuaalisesti Kubernetes Pod -kokonaisuuden kuvaukseen.
- Istio-init-säilö on komentosarja, joka soveltaa iptables-sääntöjä podiin. On kaksi vaihtoehtoa liikenteen määrittämiseksi käärittäväksi istio-agent-säilöön: käytä iptablesin uudelleenohjaussääntöjä tai . Kirjoitushetkellä oletusarvoinen lähestymistapa on uudelleenohjaussäännöt. Istio-initissä on mahdollista määrittää, mikä liikenne siepataan ja lähetetään istio-agentille. Esimerkiksi, jotta voit siepata kaiken saapuvan ja kaiken lähtevän liikenteen, sinun on asetettava parametrit
-iи-bmerkitykseen*. Voit määrittää tietyt portit siepattavaksi. Jotta et kaappaa tiettyä aliverkkoa, voit määrittää sen lipun avulla-x. - Kun aloituskontit on suoritettu, pääkontit laukaistaan, mukaan lukien pilotti-agentti (lähettiläs). Se muodostaa yhteyden jo käyttöön otettuun pilottiin GRPC:n kautta ja vastaanottaa tietoja kaikista klusterin olemassa olevista palveluista ja reitityskäytännöistä. Saatujen tietojen mukaan hän konfiguroi klusterit ja kohdistaa ne suoraan Kubernetes-klusterissa olevien sovelluksiemme päätepisteisiin. On myös tarpeen huomata tärkeä seikka: envoy määrittää dynaamisesti kuuntelijat (IP, porttiparit), joita se alkaa kuunnella. Siksi, kun pyynnöt saapuvat podiin, ohjataan uudelleen käyttämällä sivuvaunun redirect iptables -sääntöjä, lähettiläs voi jo onnistuneesti käsitellä nämä yhteydet ja ymmärtää, mihin liikennettä edelleen välitetään. Myös tässä vaiheessa Mixeriin lähetetään tietoja, joita tarkastelemme myöhemmin, ja jäljitysvälit lähetetään.
Tuloksena saamme koko verkoston envoy-välityspalvelimia, jotka voimme konfiguroida yhdestä pisteestä (Pilot). Kaikki saapuvat ja lähtevät pyynnöt kulkevat lähettilään kautta. Lisäksi vain TCP-liikenne siepataan. Tämä tarkoittaa, että Kubernetes-palvelun IP-osoite ratkaistaan kube-dns:n avulla UDP:n kautta muuttamatta. Sitten, ratkaisun jälkeen, lähtevän pyynnön sieppaa ja käsittelee lähettiläs, joka jo päättää, mihin päätepisteeseen pyyntö tulee lähettää (tai jättää lähettämättä, jos kyseessä ovat pääsykäytännöt tai algoritmin katkaisija).
Selvitimme Pilotin, nyt meidän on ymmärrettävä, miten Mixer toimii ja miksi sitä tarvitaan. Voit lukea sen viralliset asiakirjat .
Mixer nykymuodossaan koostuu kahdesta komponentista: istio-telemetriasta, istio-policysta (ennen versiota 0.8 se oli yksi istio-mikserikomponentti). Molemmat ovat sekoittimia, joista jokainen vastaa omasta tehtävästään. Istio-telemetria saa tietoa siitä, kuka menee minne ja millä parametreilla sivuvaunujen Raporttikonteista GRPC:n kautta. Istio-policy hyväksyy tarkistuspyynnöt varmistaakseen, että Käytäntösäännöt täyttyvät. Poliitiikkatarkastuksia ei tietenkään tehdä jokaiselle pyynnölle, vaan ne tallennetaan asiakkaan (sivuvaunun) välimuistiin tietyn ajan. Raporttien tarkistukset lähetetään eräpyyntöinä. Katsotaanpa, miten konfiguroidaan ja mitkä parametrit pitäisi lähettää hieman myöhemmin.
Mixerin oletetaan olevan erittäin saatavilla oleva komponentti, joka varmistaa keskeytymättömän työskentelyn telemetriatietojen kokoamisessa ja käsittelyssä. Järjestelmä saadaan tuloksena monitasoisena puskurina. Aluksi tiedot puskuroidaan konttien sivuvaunun puolelle, sitten sekoittimen puolelle ja lähetetään sitten niin sanotuille mikseritaustajärjestelmille. Tämän seurauksena, jos jokin järjestelmän komponenteista epäonnistuu, puskuri kasvaa ja huuhdellaan järjestelmän palauttamisen jälkeen. Mixer-taustaohjelmat ovat päätepisteitä telemetriatietojen lähettämiseen: statsd, newrelic jne. Voit kirjoittaa oman taustasi, se on melko yksinkertaista, ja katsotaan kuinka se tehdään.
Yhteenvetona voidaan todeta, että stio-telemetrian kanssa työskentelysuunnitelma on seuraava.
- Palvelu 1 lähettää pyynnön palvelulle 2.
- Palvelusta 1 poistuttaessa pyyntö kääritään omaan sivuvaunuonsa.
- Sivuvaunulähettiläs seuraa kuinka pyyntö menee palveluun 2 ja valmistelee tarvittavat tiedot.
- Sen jälkeen lähettää sen istio-telemetriaan raporttipyynnön avulla.
- Istio-telemetria määrittää, lähetetäänkö tämä raportti taustajärjestelmille, mihin ja mitä tietoja lähetetään.
- Istio-telemetria lähettää tarvittaessa raporttitiedot taustajärjestelmään.
Katsotaan nyt kuinka Istio otetaan käyttöön järjestelmään, joka koostuu vain pääkomponenteista (pilotti ja sivuvaunulähettiläs).
Katsotaanpa ensin pääkokoonpanoa (verkkoa), jonka Pilot lukee:
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
Kaikki tärkeimmät ohjauskomponentit (ohjaustaso) sijoitetaan Kubernetesin nimiavaruuden istio-järjestelmään.
Ainakin meidän tarvitsee vain ottaa Pilot käyttöön. Tätä varten käytämme
Ja konfiguroimme manuaalisesti säiliön ruiskutussivuvaunun.
Alkusäiliö:
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
Ja sivuvaunu:
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
Jotta kaikki käynnistyisi onnistuneesti, sinun on luotava ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, joiden kuvaukset löytyvät .
Tämän seurauksena palvelun, johon ruiskutamme sivuvaunuun lähettilään, pitäisi käynnistyä onnistuneesti, vastaanottaa kaikki löydöt lentäjältä ja käsitellä pyynnöt.
On tärkeää ymmärtää, että kaikki ohjaustason komponentit ovat tilattomia sovelluksia ja ne voidaan skaalata vaakasuunnassa ilman ongelmia. Kaikki tiedot tallennetaan etcd:hen Kubernetes-resurssien mukautettujen kuvausten muodossa.
Lisäksi Istiolla (vielä kokeellisessa) on kyky toimia klusterin ulkopuolella ja kyky katsella ja haparoida palveluiden löytämistä useiden Kubernetes-klusterien välillä. Voit lukea tästä lisää .
Ota huomioon seuraavat rajoitukset usean klusterin asennuksessa:
- Pod CIDR:n ja Service CIDR:n on oltava yksilöllinen kaikissa klustereissa, eivätkä ne saa mennä päällekkäin.
- Kaikkiin CIDR Podeihin on päästävä mistä tahansa klusterien välisestä CIDR Podista.
- Kaikkien Kubernetes API -palvelimien on oltava toistensa käytettävissä.
Tämä on alustava tieto, joka auttaa sinua pääsemään alkuun Istion kanssa. Sudenkuoppia on kuitenkin edelleen monia. Esimerkiksi ulkoisen liikenteen reitityksen ominaisuudet (klusterin ulkopuolella), lähestymistavat sivuvaunujen virheenkorjaukseen, profilointi, mikserin asettaminen ja mukautetun mikseritaustaohjelman kirjoittaminen, jäljitysmekanismin määrittäminen ja sen toiminta lähettilään avulla.
Kaikkea tätä tarkastelemme seuraavissa julkaisuissa. Esitä kysymyksiä, yritän kattaa ne.
Lähde: will.com