🥇Ինչպես գործարկել Istio-ն՝ օգտագործելով Kubernetes-ը արտադրության մեջ: Մաս 1

Ինչ է Իստիո? Սա, այսպես կոչված, Service mesh-ն է, տեխնոլոգիա, որն ավելացնում է աբստրակցիայի շերտ ցանցի վրա: Մենք ընդհատում ենք կլաստերի ամբողջ տրաֆիկը կամ դրա մի մասը և կատարում դրա հետ որոշակի գործողություններ: Որ մեկը? Օրինակ՝ մենք կատարում ենք խելացի երթուղիներ, կամ իրականացնում ենք անջատիչի մոտեցումը, կարող ենք կազմակերպել «կանարների տեղակայում»՝ մասամբ փոխարկելով երթևեկությունը ծառայության նոր տարբերակի, կամ կարող ենք սահմանափակել արտաքին փոխազդեցությունները և վերահսկել բոլոր ուղևորությունները կլաստերից դեպի տարածք: արտաքին ցանց. Հնարավոր է սահմանել քաղաքականության կանոններ՝ տարբեր միկրոծառայությունների միջև ուղևորությունները վերահսկելու համար: Վերջապես, մենք կարող ենք ստանալ ամբողջ ցանցի փոխազդեցության քարտեզը և չափումների միասնական հավաքածուն լիովին թափանցիկ դարձնել հավելվածների համար:

Աշխատանքի մեխանիզմի մասին կարող եք կարդալ պաշտոնական փաստաթղթեր. Istio-ն իսկապես հզոր գործիք է, որը թույլ է տալիս լուծել բազմաթիվ խնդիրներ և խնդիրներ: Այս հոդվածում ես կցանկանայի պատասխանել հիմնական հարցերին, որոնք սովորաբար առաջանում են Istio-ով սկսելիս: Սա կօգնի ձեզ ավելի արագ հաղթահարել դրա հետ:

Principle շահագործման

Իստիոն բաղկացած է երկու հիմնական տարածքից՝ կառավարման հարթությունից և տվյալների հարթությունից: Կառավարման ինքնաթիռը պարունակում է հիմնական բաղադրիչները, որոնք ապահովում են մնացածի ճիշտ աշխատանքը: Ընթացիկ տարբերակում (1.0) կառավարման ինքնաթիռն ունի երեք հիմնական բաղադրիչ՝ օդաչու, խառնիչ, միջնաբերդ: Մենք չենք դիտարկի Citadel-ը, այն անհրաժեշտ է սերտիֆիկատներ ստեղծել՝ ծառայությունների միջև փոխադարձ TLS ապահովելու համար: Եկեք մանրամասն նայենք Pilot and Mixer-ի սարքին և նպատակին:

Pilot-ը կառավարման հիմնական բաղադրիչն է, որը բաշխում է ամբողջ տեղեկատվությունը այն մասին, թե ինչ ունենք կլաստերում՝ ծառայություններ, դրանց վերջնակետեր և երթուղային կանոններ (օրինակ՝ Canary-ի տեղակայման կանոններ կամ անջատիչի կանոններ):

Mixer-ը կամընտիր կառավարման հարթության բաղադրիչ է, որն ապահովում է չափումներ, տեղեկամատյաններ և ցանցային փոխգործակցության մասին ցանկացած տեղեկատվություն հավաքելու հնարավորություն: Նա նաև վերահսկում է քաղաքականության կանոնների պահպանումը և դրույքաչափերի սահմանաչափերի պահպանումը:

Տվյալների հարթությունն իրականացվում է՝ օգտագործելով sidecar proxy բեռնարկղեր: Հզոր օգտագործվում է լռելյայն: բանագնաց վստահված անձ. Այն կարող է փոխարինվել մեկ այլ իրականացմամբ, ինչպիսին է nginx-ը (nginmesh):

Որպեսզի Istio-ն լիովին թափանցիկ աշխատի հավելվածների համար, կա ավտոմատ ներարկման համակարգ: Վերջին ներդրումը հարմար է Kubernetes 1.9+ տարբերակների համար (mutational admission webhook): Kubernetes 1.7, 1.8 տարբերակների համար հնարավոր է օգտագործել Initializer-ը:

Sidecar կոնտեյներները միացված են Pilot-ին՝ օգտագործելով GRPC արձանագրությունը, որը թույլ է տալիս օպտիմալացնել push մոդելը կլաստերում տեղի ունեցող փոփոխությունների համար: GRPC-ն օգտագործվել է Envoy-ում 1.6 տարբերակից, Istio-ում այն օգտագործվել է 0.8 տարբերակից և հանդիսանում է օդաչու-գործակալ.

Pilot-ը և Mixer-ը լիովին քաղաքացիություն չունեցող բաղադրիչներ են, բոլոր վիճակը պահվում է հիշողության մեջ: Նրանց համար կոնֆիգուրացիան դրված է Kubernetes Custom Resources-ի տեսքով, որոնք պահվում են etcd-ում:
Istio-agent-ը ստանում է օդաչուի հասցեն և բացում է GRPC հոսք դեպի այն:

Ինչպես ասացի, Istio-ն իրականացնում է բոլոր գործառույթները հավելվածների համար լիովին թափանցիկ: Տեսնենք, թե ինչպես: Ալգորիթմը հետևյալն է.

Ծառայության նոր տարբերակի տեղակայում:
Կախված կողային բեռնարկղերի ներարկման մոտեցումից, istio-init կոնտեյները և istio-agent բեռնարկղը (պատվիրակ) ավելացվում են կազմաձևման կիրառման փուլում, կամ դրանք արդեն կարող են ձեռքով տեղադրվել Kubernetes Pod էության նկարագրության մեջ:
istio-init կոնտեյները սկրիպտ է, որը կիրառում է iptables-ի կանոնները pod-ում: Գոյություն ունեն երկու տարբերակ՝ երթևեկությունը կարգավորելու համար, որպեսզի այն փաթաթվի istio-agent կոնտեյներով. օգտագործեք iptables վերահղման կանոնները, կամ TPROXY. Գրելու պահին լռելյայն մոտեցումը վերահղման կանոններով է: istio-init-ում հնարավոր է կարգավորել, թե որ երթևեկը պետք է ընդհատվի և ուղարկվի istio-agent-ին: Օրինակ, բոլոր մուտքային և ելքային տրաֆիկները գաղտնալսելու համար անհրաժեշտ է սահմանել պարամետրերը -i и -b իմաստի մեջ *. Դուք կարող եք նշել հատուկ նավահանգիստներ, որոնք պետք է ընդհատեն: Որպեսզի չկատարեք որոշակի ենթացանց, դուք կարող եք նշել այն՝ օգտագործելով դրոշը -x.
Մեկնարկային բեռնարկղերը գործարկվելուց հետո գործարկվում են հիմնականները, ներառյալ օդաչու-գործակալը (պատգամավորը): Այն միանում է արդեն տեղակայված Pilot-ին GRPC-ի միջոցով և ստանում տեղեկատվություն կլաստերի բոլոր առկա ծառայությունների և երթուղային քաղաքականության մասին: Ստացված տվյալների համաձայն՝ նա կարգավորում է կլաստերները և դրանք ուղղակիորեն վերագրում է Kubernetes կլաստերի մեր հավելվածների վերջնակետերին։ Հարկ է նաև նշել մի կարևոր կետ. envoy-ը դինամիկ կերպով կարգավորում է ունկնդիրներին (IP, նավահանգիստների զույգեր), որոնց նա սկսում է լսել: Հետևաբար, երբ հարցումները մտնում են պատիճ, դրանք վերահղվում են՝ օգտագործելով վերահղման iptables կանոնները կողային սայլում, բանագնացը արդեն կարող է հաջողությամբ մշակել այդ կապերը և հասկանալ, թե որտեղ պետք է հետագայում վստահել տրաֆիկին: Նաև այս փուլում տեղեկատվությունը ուղարկվում է Mixer-ին, որը մենք կանդրադառնանք ավելի ուշ, և հետագծման միջակայքերը ուղարկվում են:

Արդյունքում մենք ստանում ենք envoy proxy սերվերների մի ամբողջ ցանց, որը մենք կարող ենք կարգավորել մեկ կետից (Pilot): Բոլոր ներգնա և ելքային հարցումները անցնում են բանագնացի միջոցով: Ընդ որում, միայն TCP տրաֆիկն է գաղտնալսվում։ Սա նշանակում է, որ Kubernetes ծառայության IP-ն լուծվում է kube-dns-ի միջոցով UDP-ի միջոցով՝ առանց փոխելու: Այնուհետև, լուծումից հետո, ելքային հարցումը կալանվում և մշակվում է բանագնացի կողմից, որն արդեն որոշում է, թե որ վերջնակետին պետք է ուղարկվի հարցումը (կամ չուղարկվի, մուտքի քաղաքականության կամ ալգորիթմի անջատիչի դեպքում):

Մենք պարզեցինք Pilot-ը, այժմ մենք պետք է հասկանանք, թե ինչպես է աշխատում Mixer-ը և ինչու է այն անհրաժեշտ: Դուք կարող եք կարդալ դրա համար պաշտոնական փաստաթղթերը այստեղ.

Միքսերն իր ներկայիս տեսքով բաղկացած է երկու բաղադրիչից՝ istio-telemetry, istio-policy (մինչ 0.8 տարբերակը դա մեկ istio-mixer բաղադրիչ էր): Երկուսն էլ խառնիչներ են, որոնցից յուրաքանչյուրը պատասխանատու է իր առաջադրանքի համար։ Istio հեռաչափությունը GRPC-ի միջոցով ստանում է տեղեկատվություն այն մասին, թե ով որտեղ է գնում և ինչ պարամետրերով: Istio-policy-ն ընդունում է Ստուգման հարցումները՝ ստուգելու, որ քաղաքականության կանոնները բավարարված են: Քաղաքականության ստուգումները, իհարկե, չեն իրականացվում յուրաքանչյուր հարցման համար, այլ որոշակի ժամանակ պահվում են հաճախորդի վրա (կողմնակի մեքենայի մեջ): Հաշվետվությունների ստուգումները ուղարկվում են որպես խմբաքանակի հարցումներ: Տեսնենք, թե ինչպես կարգավորել և ինչ պարամետրեր պետք է ուղարկվեն մի փոքր ուշ:

Ենթադրվում է, որ Mixer-ը բարձր հասանելի բաղադրիչ է, որն ապահովում է անխափան աշխատանք հեռաչափական տվյալների հավաքման և մշակման վրա: Համակարգը ստացվում է արդյունքում որպես բազմաստիճան բուֆեր։ Սկզբում տվյալները բուֆերվում են բեռնարկղերի կողային մասում, այնուհետև խառնիչի կողմում, այնուհետև ուղարկվում են այսպես կոչված խառնիչի հետնամասեր: Արդյունքում, եթե համակարգի բաղադրիչներից որևէ մեկը ձախողվի, բուֆերը մեծանում է և լվացվում է համակարգի վերականգնումից հետո: Mixer backends-ը հեռաչափության տվյալներ ուղարկելու վերջնակետեր են՝ statsd, newrelic և այլն: Դուք կարող եք գրել ձեր սեփական backend-ը, դա բավականին պարզ է, և մենք կտեսնենք, թե ինչպես դա անել:

Ամփոփելու համար նշենք, որ istio-telemetry-ի հետ աշխատելու սխեման հետևյալն է.

Ծառայություն 1-ը հարցում է ուղարկում ծառայության 2-ին:
Ծառայությունից 1-ից հեռանալիս հարցումը փաթաթվում է իր կողային սայլի մեջ:
Sidecar բանագնացը վերահսկում է, թե ինչպես է հարցումը գնում ծառայության 2-ին և պատրաստում անհրաժեշտ տեղեկատվությունը:
Այնուհետև այն ուղարկում է istio-telemetry՝ օգտագործելով Report հարցումը:
Istio-telemetry-ն որոշում է, թե արդյոք այս Զեկույցը պետք է ուղարկվի backends, որին և ինչ տվյալներ պետք է ուղարկվեն:
Istio-telemetry-ն անհրաժեշտության դեպքում ուղարկում է հաշվետվության տվյալները backend-ին:

Այժմ տեսնենք, թե ինչպես պետք է տեղակայել Istio համակարգում, որը բաղկացած է միայն հիմնական բաղադրիչներից (Pilot և sidecar envoy):

Նախ, եկեք նայենք հիմնական կազմաձևին (ցանց), որը կարդում է 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

Բոլոր հիմնական կառավարման բաղադրիչները (կառավարման հարթությունը) կտեղակայվեն Kubernetes-ի անվանատարածք istio-համակարգում:

Նվազագույնը մեզ միայն պետք է տեղակայել Pilot-ը: Դրա համար մենք կօգտագործենք նման կոնֆիգուրացիա.

Եվ մենք ձեռքով կկազմաձևենք տարայի ներարկման կողային սյունը:

Init կոնտեյներ:

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

Եվ կողային մեքենա.

       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

Որպեսզի ամեն ինչ հաջող սկսվի, դուք պետք է ստեղծեք ServiceAccount, ClusterRole, ClusterRoleBinding, CRD Pilot-ի համար, որոնց նկարագրությունները կարելի է գտնել: այստեղ.

Արդյունքում, ծառայությունը, որին մենք բանագնացին ներարկում ենք կողային կառքը, պետք է հաջողությամբ սկսվի, օդաչուից ստանա բոլոր բացահայտումները և կատարի հարցումները:

Կարևոր է հասկանալ, որ կառավարման հարթության բոլոր բաղադրիչները քաղաքացիություն չունեցող հավելվածներ են և կարող են հորիզոնական մասշտաբվել առանց խնդիրների: Բոլոր տվյալները պահվում են etcd-ում՝ Kubernetes-ի ռեսուրսների հատուկ նկարագրությունների տեսքով:

Բացի այդ, Istio-ն (դեռևս փորձնական) ունի կլաստերի սահմաններից դուրս աշխատելու և մի քանի Kubernetes կլաստերների միջև սպասարկման հայտնաբերումը դիտելու և ցրելու հնարավորություն: Այս մասին կարող եք կարդալ ավելին այստեղ.

Բազմակի կլաստերային տեղադրման համար տեղյակ եղեք հետևյալ սահմանափակումների մասին.

Pod CIDR-ը և Service CIDR-ը պետք է եզակի լինեն բոլոր կլաստերներում և չպետք է համընկնեն:
Բոլոր CIDR Pods-ները պետք է հասանելի լինեն ցանկացած CIDR Pods-ից՝ կլաստերների միջև:
Բոլոր Kubernetes API սերվերները պետք է հասանելի լինեն միմյանց:

Սա նախնական տեղեկատվությունն է, որը կօգնի ձեզ սկսել Istio-ով: Այնուամենայնիվ, դեռ շատ որոգայթներ կան: Օրինակ՝ արտաքին երթևեկության երթուղման առանձնահատկությունները (կլաստերից դուրս), կողային վրիպազերծման մոտեցումները, պրոֆիլավորումը, խառնիչի տեղադրումը և հատուկ խառնիչի հետին պլան գրելը, հետագծման մեխանիզմի ստեղծումը և դրա գործարկումը envoy-ի միջոցով:
Այս ամենը մենք կքննարկենք հաջորդ հրապարակումներում։ Տվեք ձեր հարցերը, ես կփորձեմ դրանք լուսաբանել:

Source: www.habr.com

Ինչպես գործարկել Istio-ն՝ օգտագործելով Kubernetes-ը արտադրության մեջ: Մաս 1

Principle շահագործման

Добавить комментарий Չեղարկել պատասխանել