په تولید کې د Kubernetes په کارولو سره د اسټیو چلولو څرنګوالی. برخه 1

څه اسټیټو؟ دا تش په نامه خدمت میش دی، یوه ټیکنالوژي چې په شبکه کې د خلاصون یو پرت اضافه کوي. موږ په کلستر کې د ټرافیک ټول یا برخه مداخله کوو او د هغې سره د عملیاتو یو ټاکلی سیټ ترسره کوو. کم یو ؟ د مثال په توګه، موږ سمارټ روټینګ کوو، یا موږ د سرکټ بریکر طریقه پلي کوو، موږ کولی شو د "کینري ځای پرځای کول" تنظیم کړو، په جزوي توګه د خدماتو نوې نسخه ته ټرافیک بدل کړو، یا موږ کولی شو بهرنۍ تعاملات محدود کړو او د کلستر څخه ټول سفرونه کنټرول کړو. بهرنۍ شبکه. دا ممکنه ده چې د مختلف مایکرو خدماتو تر مینځ سفرونو کنټرول لپاره د پالیسۍ مقررات تنظیم کړئ. په نهایت کې ، موږ کولی شو د ټولې شبکې متقابل عمل نقشه ترلاسه کړو او د میټریک متحد ټولګه په بشپړ ډول غوښتنلیکونو ته شفافه کړو.

تاسو کولی شئ د کار میکانیزم په اړه ولولئ رسمي اسناد. اسټیو واقعیا یو پیاوړی وسیله ده چې تاسو ته اجازه درکوي ډیری دندې او ستونزې حل کړئ. پدې مقاله کې ، زه غواړم هغه اصلي پوښتنو ته ځواب ووایم چې معمولا راپورته کیږي کله چې د اسټیو سره پیل کیږي. دا به تاسو سره په چټکۍ سره معامله کولو کې مرسته وکړي.

دا څنګه کار کوي

اسټیو دوه اصلي ساحې لري - د کنټرول الوتکه او د معلوماتو الوتکه. د کنټرول الوتکه اصلي برخې لري چې د پاتې کیدو سم عملیات یقیني کوي. په اوسنۍ نسخه کې (1.0) د کنټرول الوتکه درې اصلي برخې لري: پیلوټ، مکسر، سیټاډیل. موږ به Citadel په پام کې ونیسو، د خدماتو ترمنځ د متقابل TLS ډاډ ترلاسه کولو لپاره د سندونو تولید ته اړتیا ده. راځئ چې د پیلوټ او مکسر وسیله او هدف ته نږدې وګورو.

پیلوټ د کنټرول اصلي برخه ده چې د هغه څه په اړه چې موږ یې په کلستر کې لرو ټول معلومات توزیع کوي - خدمات ، د دوی پای ټکي او د روټینګ قواعد (د مثال په توګه ، د کانري پلي کولو قواعد یا د سرکټ بریکر قواعد).

مکسر د اختیاري کنټرول الوتکې برخه ده چې د میټریکونو ، لاګونو او د شبکې متقابل عمل په اړه هر ډول معلوماتو راټولولو وړتیا چمتو کوي. هغه د پالیسۍ مقرراتو او د نرخ محدودیتونو اطاعت هم څاري.

د معلوماتو الوتکه د سایډ کار پراکسي کانټینرونو په کارولو سره پلي کیږي. ځواکمن د ډیفالټ لخوا کارول کیږي. سفیر پراکسي. دا د بل تطبیق لخوا بدل کیدی شي، لکه نګینکس (نګینمیش).

د دې لپاره چې اسټیو غوښتنلیکونو ته په بشپړ ډول شفاف کار وکړي ، د انجیکشن اتوماتیک سیسټم شتون لري. وروستی تطبیق د Kubernetes 1.9+ نسخو لپاره مناسب دی (متقابل داخلې ویب هک). د Kubernetes 1.7، 1.8 نسخو لپاره دا ممکنه ده چې د ابتکار کار واخلئ.

د سایډ کار کانټینرونه د GRPC پروتوکول په کارولو سره پیلوټ سره وصل شوي ، کوم چې تاسو ته اجازه درکوي په کلستر کې د بدلونونو لپاره د فشار ماډل اصلاح کړئ. GRPC د 1.6 نسخه راهیسې په Envoy کې کارول شوی، په Istio کې دا د 0.8 نسخه راهیسې کارول شوی او یو پیلوټ-ایجنټ دی - د ګولنګ ریپر د سفیر په اړه چې د لانچ اختیارونه تنظیموي.

پیلوټ او مکسر په بشپړ ډول بې حالته اجزا دي، ټول حالت په حافظه کې ساتل کیږي. د دوی لپاره ترتیب د Kubernetes ګمرکي سرچینو په بڼه ترتیب شوی، کوم چې په etcd کې زیرمه شوي.
اسټیو ایجنټ د پیلوټ پته ترلاسه کوي او هغې ته د GRPC جریان پرانیزي.

لکه څنګه چې ما وویل، Istio ټول فعالیت په بشپړ ډول د غوښتنلیکونو لپاره شفاف پلي کوي. راځئ وګورو چې څنګه. الګوریتم دا دی:

1. د خدماتو نوې نسخه ځای په ځای کول.
2. د سایډ کار کانټینر انجیکشن طریقې پورې اړه لري ، د istio-init کانټینر او istio-Agent کانټینر (Envoy) د تشکیلاتو پلي کولو مرحله کې اضافه شوي ، یا دوی دمخه د کوبرنیټس پوډ ادارې توضیحاتو کې په لاسي ډول داخل کیدی شي.
3. د istio-init کانټینر یو سکریپټ دی چې په پوډ کې د iptables قواعد پلي کوي. د ټرافیک تنظیم کولو لپاره دوه اختیارونه شتون لري چې په istio-agent کانټینر کې وتړل شي: د iptables د لارښوونې قواعد وکاروئ، یا TPROXY. د لیکلو په وخت کې، ډیفالټ طریقه د لارښوونې قواعدو سره ده. په istio-init کې، دا ممکنه ده چې دا تنظیم کړئ چې کوم ټرافیک باید ودرول شي او istio-agent ته واستول شي. د مثال په توګه، د ټولو راتلونکو او ټولو وتلو ټرافیک د مخنیوي لپاره، تاسو اړتیا لرئ چې پیرامیټونه تنظیم کړئ -i и -b په معنی *. تاسو کولی شئ د مداخلې لپاره ځانګړي بندرونه مشخص کړئ. د دې لپاره چې یو ځانګړي فرعي شبکې مداخله ونه کړئ، تاسو کولی شئ دا د بیرغ په کارولو سره مشخص کړئ -x.
4. وروسته له دې چې init کانټینرونه اعدام شي، اصلي یې پیل شوي، په شمول د پیلوټ ایجنټ (استازو). دا د GRPC له لارې دمخه ګمارل شوي پیلوټ سره وصل کیږي او په کلستر کې د ټولو موجوده خدماتو او روټینګ پالیسیو په اړه معلومات ترلاسه کوي. د ترلاسه شویو معلوماتو له مخې، هغه کلسترونه تنظیموي او په مستقیم ډول یې د Kubernetes کلستر کې زموږ د غوښتنلیکونو پای ته رسوي. دا هم اړینه ده چې یو مهم ټکي ته پام وکړئ: سفیر په متحرک ډول اوریدونکي تنظیموي (IP، پورټ جوړه) چې دا اوریدل پیل کوي. له همدې امله، کله چې غوښتنې پوډ ته ننوځي، په سایډ کار کې د ریډیریټ iptables قواعدو په کارولو سره لیږل کیږي، سفیر کولی شي دمخه دا اړیکې په بریالیتوب سره پروسس کړي او پوه شي چې چیرې ټرافيک نور پراکسي کړي. همدارنګه پدې مرحله کې، معلومات مکسر ته لیږل کیږي، کوم چې موږ به وروسته وګورو، او د تعقیب سپانونه لیږل کیږي.

د پایلې په توګه، موږ د سفیر پراکسي سرورونو ټوله شبکه ترلاسه کوو چې موږ کولی شو له یوې نقطې (پائلټ) څخه تنظیم کړو. ټولې داخلي او بهرنۍ غوښتنې د استازي له لارې تیریږي. سربیره پردې ، یوازې د TCP ترافیک مداخله کیږي. دا پدې مانا ده چې د Kubernetes خدمت IP د بدلولو پرته د UDP په اړه د kube-dns په کارولو سره حل کیږي. بیا، د حل وروسته، بهر ته تلونکې غوښتنه د سفیر لخوا مداخله او پروسس کیږي، کوم چې دمخه پریکړه کوي چې غوښتنه باید کوم پای ته واستول شي (یا نه لیږل کیږي، د لاسرسي پالیسیو یا د الګوریتم سرکټ بریکر په صورت کې).

موږ پیلوټ معلوم کړ، اوس موږ باید پوه شو چې مکسر څنګه کار کوي او ولې ورته اړتیا ده. تاسو کولی شئ د دې لپاره رسمي اسناد ولولئ دلته.

مکسر په خپل اوسنۍ بڼه کې دوه برخې لري: istio-telemetry، istio-policy (د 0.8 نسخه مخکې دا د اسټیو مکسر یوه برخه وه). دا دواړه مخلوطونکي دي، چې هر یو یې د خپل کار مسولیت لري. اسټیو ټیلی میټری د GRPC له لارې د سایډ کار راپور کانټینرونو څخه څوک چیرته ځي او د کوم پیرامیټونو سره معلومات ترلاسه کوي. اسټیو پالیسي د چیک غوښتنې مني ترڅو تصدیق کړي چې د پالیسۍ مقررات راضي دي. د پالیسۍ چکونه، البته، د هرې غوښتنې لپاره نه ترسره کیږي، مګر د یو ټاکلي وخت لپاره په پیرودونکي (سایډ کار کې) کې ساتل کیږي. د راپور چکونه د بست غوښتنې په توګه لیږل کیږي. راځئ وګورو چې څنګه تنظیم کول او کوم پیرامیټونه باید لږ وروسته واستول شي.

مکسر داسې انګیرل کیږي چې په لوړه کچه شتون لري چې د ټیل میټري ډیټا پروسس کولو او تنظیم کولو کې بې بنسټه کار تضمینوي. سیسټم د څو کچې بفر په پایله کې ترلاسه کیږي. په پیل کې، ډاټا د کانټینرونو د سایډ کار اړخ کې بفر کیږي، بیا د مکسر اړخ ته، او بیا د مکسر بیکینډونو ته لیږل کیږي. د پایلې په توګه، که چیرې د سیسټم کومه برخه ناکامه شي، بفر وده کوي او د سیسټم له رغولو وروسته فلش کیږي. د مکسر بیکینډونه د ټیلی میټری ډیټا لیږلو لپاره پای ټکي دي: statsd، نیوریلیک، او نور. تاسو کولی شئ خپل پس منظر ولیکئ، دا خورا ساده دی، او موږ به وګورو چې دا څنګه وکړو.

د لنډیز لپاره، د istio-telemetry سره د کار کولو سکیم په لاندې ډول دی.

1. خدمت 1 خدمت 2 ته غوښتنه لیږي.
2. کله چې خدمت 1 پریږدئ ، غوښتنه په خپل سایډ کار کې پوښل کیږي.
3. د سایډکار سفیر څارنه کوي چې څنګه غوښتنه 2 خدمت ته ځي او اړین معلومات چمتو کوي.
4. بیا یې د راپور غوښتنې په کارولو سره istio-telemetry ته لیږي.
5. Istio-telemetry ټاکي چې ایا دا راپور باید شالید ته واستول شي، کوم او کوم معلومات باید واستول شي.
6. Istio-telemetry د اړتیا په صورت کې د راپور ډیټا بیکینډ ته لیږي.

اوس راځئ وګورو چې څنګه په سیسټم کې اسټیو ځای په ځای کړئ ، یوازې اصلي برخې پکې شاملې دي (پائلټ او د سایډ کار استازي).

لومړی، راځئ چې اصلي ترتیب (میش) وګورو چې پیلوټ یې لوستل:

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

د کنټرول ټولې اصلي برخې (کنټرول الوتکه) به په کوبرنیټس کې د نوم ځای اسټیو سیسټم کې موقعیت ولري.

لږترلږه، موږ یوازې د پیلوټ ځای پرځای کولو ته اړتیا لرو. د دې لپاره موږ به وکاروو داسې ترتیب.

او موږ به په لاسي ډول د کانټینر انجیکشن سایډ کار تنظیم کړو.

د پیل کانټینر:

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

د دې لپاره چې هرڅه په بریالیتوب سره پیل شي، تاسو اړتیا لرئ د خدماتو حساب، کلستر رول، کلستر رول باینډنګ، د پیلوټ لپاره CRD جوړ کړئ، چې توضیحات یې موندلی شي. دلته.

د پایلې په توګه، هغه خدمت چې موږ د سفیر سره سایډ کار انجیکشن کوو باید په بریالیتوب سره پیل شي، د پیلوټ څخه ټولې موندنې ترلاسه کړي او غوښتنې پروسس کړي.

دا مهمه ده چې پوه شئ چې د کنټرول الوتکې ټولې برخې بې ریاسته غوښتنلیکونه دي او پرته له کومې ستونزې په افقی ډول اندازه کیدی شي. ټول معلومات په etcd کې د Kubernetes سرچینو د دودیز توضیحاتو په بڼه ساتل کیږي.

همچنان ، اسټیو (اوس هم تجربه لرونکی) د کلسټر څخه بهر د چلولو وړتیا لري او د څو کوبرنیټس کلسترونو ترمینځ د خدماتو کشف د لیدو او ناکامولو وړتیا لري. تاسو کولی شئ پدې اړه نور ولولئ دلته.

د څو کلستر نصبولو لپاره، د لاندې محدودیتونو څخه خبر اوسئ:

1. د پوډ CIDR او د خدماتو CIDR باید په ټولو کلسترونو کې ځانګړي وي او باید یوځای نشي.
2. ټول CIDR پوډونه باید د کلسترونو ترمینځ د هر CIDR پوډونو څخه د لاسرسي وړ وي.
3. ټول Kubernetes API سرورونه باید یو بل ته د لاسرسي وړ وي.

دا لومړني معلومات دي چې تاسو سره د اسټیو سره پیل کولو کې مرسته کوي. په هرصورت، لاهم ډیری نیمګړتیاوې شتون لري. د مثال په توګه، د بهرنۍ ټرافیک روټینګ ځانګړتیاوې (د کلستر څخه بهر)، د سایډکارونو ډیبګ کولو ته تګ راتګ، پروفایل کول، د مکسر ترتیب کول او د ګمرک مکسر بیکینډ لیکل، د تعقیب میکانیزم ترتیب کول او د انوان په کارولو سره د هغې عملیات.
دا ټول به موږ په لاندې خپرونو کې په پام کې ونیسو. خپلې پوښتنې وپوښتئ، زه به یې د پوښښ هڅه وکړم.

سرچینه: www.habr.com