🥇Nola exekutatu Istio Kubernetes erabiliz produkzioan. 1. zatia

Zer da Istio? Hau Service mesh deritzona da, sarean abstrakzio geruza bat gehitzen duen teknologia. Klusterreko trafiko osoa edo zati bat atzematen dugu eta horrekin eragiketa multzo jakin bat egiten dugu. Zein? Esate baterako, bideratze adimenduna egiten dugu, edo etengailuaren ikuspegia inplementatzen dugu, "kanariar inplementazioa" antola dezakegu, trafikoa partzialki zerbitzuaren bertsio berri batera aldatuz edo kanpoko interakzioak muga ditzakegu eta klusterretik bidaia guztiak kontrola ditzakegu. kanpoko sarea. Posible da politika-arauak ezartzea mikrozerbitzu ezberdinen arteko bidaiak kontrolatzeko. Azkenik, sareko interakzio-mapa osoa lor dezakegu eta metrika-bilduma bateratua aplikazioetarako guztiz gardena izan dadin.

Lan-mekanismoari buruz irakur dezakezu dokumentazio ofiziala. Istio tresna benetan indartsua da, zeregin eta arazo asko konpontzeko aukera ematen duena. Artikulu honetan, Istiorekin hastean sortu ohi diren galdera nagusiei erantzun nahi diet. Horrek azkarrago aurre egiten lagunduko dizu.

Eragiketa printzipioa

Istio bi eremu nagusi ditu: kontrol-planoa eta datu-planoa. Kontrol-planoak gainerakoen funtzionamendu zuzena ziurtatzen duten osagai nagusiak ditu. Egungo bertsioan (1.0) kontrol-hegazkinak hiru osagai nagusi ditu: Pilotoa, Nahasgailua, Ziudadela. Ez dugu Ziudadela kontuan hartuko, zerbitzuen arteko elkarrekiko TLS bermatzeko ziurtagiriak sortzea beharrezkoa da. Ikus ditzagun Pilot eta Mixer-en gailua eta helburua gertutik.

Pilot da klusterrean dugunari buruzko informazio guztia banatzen duen kontrol-osagai nagusia: zerbitzuak, haien amaiera-puntuak eta bideratze-arauak (adibidez, Canary inplementatzeko arauak edo etengailuen arauak).

Mixer aukerako kontrol-planoko osagai bat da, sareko interakzioari buruzko neurketak, erregistroak eta edozein informazio biltzeko gaitasuna ematen duena. Politika-arauak betetzen direla eta tasa-mugak betetzen direla ere kontrolatzen du.

Datu-planoa sidecar proxy edukiontziak erabiliz inplementatzen da. Indartsua erabiltzen da lehenespenez. mandataria proxy. Beste inplementazio batekin ordezkatu daiteke, adibidez, nginx (nginmesh).

Istio aplikazioetarako guztiz gardena izan dadin, injekzio sistema automatiko bat dago. Azken inplementazioa Kubernetes 1.9+ bertsioetarako egokia da (mutazio onarpen webhook). Kubernetes 1.7, 1.8 bertsioetarako posible da Initializer erabiltzea.

Sidecar edukiontziak GRPC protokoloaren bidez konektatzen dira Pilot-era, eta horrek klusterrean gertatzen diren aldaketetarako push eredua optimizatzeko aukera ematen du. GRPC Envoy-en 1.6 bertsioaz geroztik erabiltzen da, Istio-n 0.8 bertsioaz geroztik erabiltzen da eta pilotu-agentea da - abiarazte-aukerak konfiguratzen dituen envoy-en gaineko golang bilgarri bat.

Pilot eta Mixer guztiz estaturik gabeko osagaiak dira, egoera guztiak memorian gordetzen dira. Horien konfigurazioa Kubernetes Custom Resources moduan ezartzen da, eta etcd-en gordetzen dira.
Istio-agenteak Pilotuaren helbidea lortzen du eta GRPC korronte bat irekitzen dio.

Esan bezala, Istio-k funtzionaltasun guztiak aplikazioetarako guztiz gardenak ezartzen ditu. Ikus dezagun nola. Algoritmoa hau da:

Zerbitzuaren bertsio berri bat zabaltzea.
Sidecar edukiontzia injektatzeko ikuspegiaren arabera, istio-init edukiontzia eta istio-agent edukiontzia (envoy) gehitzen dira konfigurazioa aplikatzeko fasean, edo dagoeneko eskuz txerta daitezke Kubernetes Pod entitatearen deskribapenean.
Istio-init edukiontzia pod-ean iptables arauak aplikatzen dituen script bat da. Istio-agent edukiontzi batean biltzeko trafikoa konfiguratzeko bi aukera daude: iptables birbideratzeko arauak erabili edo TPROXY. Idazteko unean, ikuspegi lehenetsia birbideratzeko arauekin da. Istio-init-en, posible da konfiguratu zein trafiko atzeman behar den eta istio-agentera bidali. Adibidez, sarrerako eta irteerako trafiko guztia atzemateko, parametroak ezarri behar dituzu -i и -b esanahian sartu *. Atzemateko ataka zehatzak zehaztu ditzakezu. Azpisare zehatz bat ez atzemateko, bandera erabiliz zehaztu dezakezu -x.
Hasierako edukiontziak exekutatu ondoren, nagusiak abiarazten dira, pilotu-agentea (envoy) barne. Dagoeneko zabaldutako Pilot-era konektatzen da GRPC bidez eta klusterrean dauden zerbitzu eta bideratze-politikei buruzko informazioa jasotzen du. Jasotako datuen arabera, klusterrak konfiguratzen ditu eta zuzenean esleitzen dizkie Kubernetes klusterreko gure aplikazioen amaierako puntuei. Puntu garrantzitsu bat ere kontuan hartu behar da: envoy-ek modu dinamikoan konfiguratzen ditu entzuten hasten diren entzuleak (IP, ataka bikoteak). Hori dela eta, eskaerak podan sartzen direnean, sidecar-eko birbideratzeko iptables arauak erabiliz birbideratzen direnean, envoy-ek konexio hauek arrakastaz prozesatu ditzake eta trafikoa gehiago proxy non egin uler dezake. Etapa honetan ere, informazioa Nahasgailura bidaltzen da, geroago aztertuko duguna, eta trazadura-tarteak bidaltzen dira.

Ondorioz, envoy proxy zerbitzarien sare oso bat lortzen dugu, puntu batetik (Pilot) konfigura dezakeguna. Sarrerako eta irteerako eskaera guztiak envoy bidez pasatzen dira. Gainera, TCP trafikoa bakarrik atzematen da. Horrek esan nahi du Kubernetes zerbitzuaren IPa kube-dns erabiliz konpontzen dela UDPren bidez, aldatu gabe. Ondoren, ebatzi ondoren, irteerako eskaera atzematen eta prozesatzen du envoyak, eta hark erabakitzen du dagoeneko eskaera zein amaierara bidali behar den (edo ez bidali, sarbide-politiken edo algoritmoaren etengailuaren kasuan).

Pilot asmatu genuen, orain Mixer nola funtzionatzen duen eta zergatik behar den ulertu behar dugu. Dokumentazio ofiziala irakur dezakezu Hemen.

Mixer bere egungo forman bi osagai ditu: istio-telemetria, istio-politika (0.8 bertsioaren aurretik istio-nahastailearen osagai bat zen). Biak ala biak nahasgailuak dira, bakoitza bere zereginaz arduratzen dena. Istio telemetriak nora doan eta zer parametrorekin doan informazioa jasotzen du sidecar Report edukiontzietatik GRPC bidez. Istio-policy-k Egiaztatu eskaerak onartzen ditu Politika-arauak betetzen direla egiaztatzeko. Poilicy egiaztapenak, noski, ez dira eskaera guztietan egiten, baina bezeroan (sidecar-ean) cachean gordetzen dira denbora jakin baterako. Txostenen egiaztapenak sorta-eskaera gisa bidaltzen dira. Ikus dezagun nola konfiguratu eta zer parametro bidali behar diren pixka bat geroago.

Mixer oso erabilgarri dagoen osagaia omen da, telemetria datuen muntaketa eta prozesamenduan etenik gabeko lana ziurtatzen duena. Sistema maila anitzeko buffer gisa lortzen da. Hasieran, datuak ontzien alboko aldean gordetzen dira, gero nahasgailuaren aldean, eta gero nahasgailuen backend deritzonetara bidaltzen dira. Ondorioz, sistemaren osagairen batek huts egiten badu, buffer-a hazten da eta garbitu egiten da sistema leheneratu ondoren. Mixer backendak telemetria datuak bidaltzeko amaierako puntuak dira: statsd, newrelic, etab. Zure backend-a idatzi dezakezu, nahiko erraza da, eta ikusiko dugu nola egin.

Laburbilduz, istio-telemetria lantzeko eskema hau da.

1. zerbitzuak eskaera 2. zerbitzura bidaltzen du.
1. zerbitzutik irtetean, eskaera bere sidecar batean biltzen da.
Sidecar envoy eskaera 2 zerbitzura nola doan kontrolatzen du eta beharrezko informazioa prestatzen du.
Ondoren, istio-telemetria-ra bidaltzen du Txosten eskaera bat erabiliz.
Istio-telemetriak zehazten du Txosten hau backendetara bidali behar den ala ez, nori eta zer datu bidali behar diren.
Istio-telemetry-k Txostenaren datuak backend-era bidaltzen ditu behar izanez gero.

Orain ikus dezagun Istio sisteman nola zabaldu, osagai nagusiez soilik osatuta (Pilot eta sidecar envoy).

Lehenik eta behin, ikus dezagun Pilot-ek irakurtzen duen konfigurazio nagusia (sare):

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

Kontrol-osagai nagusi guztiak (kontrol-planoa) Kubernetes-en istio-sisteman kokatuko dira.

Gutxienez, Pilot bakarrik zabaldu behar dugu. Horretarako erabiltzen dugu halako konfigurazio bat.

Eta eskuz konfiguratuko dugu edukiontziaren alboko injektatzailea.

Hasierako edukiontzia:

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

Eta 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

Dena behar bezala hasteko, ServiceAccount, ClusterRole, ClusterRoleBinding, CRD Pilot-erako sortu behar duzu, zeinen deskribapenak aurki daitezke. Hemen.

Ondorioz, envoyarekin sidecar injektatzen dugun zerbitzua arrakastaz hasi beharko litzateke, pilotuaren aurkikuntza guztiak jaso eta eskaerak prozesatu.

Garrantzitsua da ulertzea kontrol-planoaren osagai guztiak estaturik gabeko aplikazioak direla eta horizontalki eskala daitezkeela arazorik gabe. Datu guztiak etcd-n gordetzen dira Kubernetes baliabideen deskribapen pertsonalizatuen moduan.

Gainera, Istiok (oraindik esperimentala) klusteretik kanpo exekutatzeko gaitasuna du eta Kubernetes klusterren artean zerbitzuen aurkikuntza ikusi eta asmatzeko gaitasuna du. Honi buruz gehiago irakur dezakezu Hemen.

Kluster anitzeko instalazioetarako, kontuan izan muga hauek:

Pod CIDR eta Service CIDR bakarrak izan behar dute kluster guztietan eta ez dute gainjarri behar.
Klusterren arteko CIDR Pods guztiak eskura izan behar dira.
Kubernetes API zerbitzari guztiek elkarren artean eskuragarri egon behar dute.

Hau da Istiorekin hasten laguntzeko hasierako informazioa. Hala ere, oraindik ere hutsune asko daude. Adibidez, kanpoko trafikoa bideratzeko (klusterretik kanpo), sidecar-ak arazketarako planteamenduak, profilak egitea, nahastailea konfiguratzea eta nahastaile pertsonalizatua idaztea, trazatzeko mekanismoa konfiguratzea eta bere funtzionamendua envoy erabiliz.
Hori guztia hurrengo argitalpenetan kontuan hartuko dugu. Egin zure galderak, horiek estaltzen saiatuko naiz.

Iturria: www.habr.com

Nola exekutatu Istio Kubernetes erabiliz ekoizpenean. 1. zatia

Eragiketa printzipioa

Gehitu iruzkin berria Idatzi