پروڈکشن میں کبرنیٹس کا استعمال کرتے ہوئے اسٹیو کو کیسے چلایا جائے۔ حصہ 1

کیا ہے Istio? یہ نام نہاد سروس میش ہے، ایک ایسی ٹیکنالوجی جو نیٹ ورک پر تجرید کی ایک تہہ ڈالتی ہے۔ ہم کلسٹر میں ٹریفک کے تمام یا کچھ حصے کو روکتے ہیں اور اس کے ساتھ آپریشنز کا ایک مخصوص سیٹ انجام دیتے ہیں۔ کونسا؟ مثال کے طور پر، ہم سمارٹ روٹنگ کرتے ہیں، یا ہم سرکٹ بریکر اپروچ کو لاگو کرتے ہیں، ہم "کینری تعیناتی" کو منظم کر سکتے ہیں، ٹریفک کو جزوی طور پر سروس کے نئے ورژن میں تبدیل کر سکتے ہیں، یا ہم بیرونی تعاملات کو محدود کر سکتے ہیں اور کلسٹر سے لے کر تمام ٹرپس کو کنٹرول کر سکتے ہیں۔ بیرونی نیٹ ورک. مختلف مائیکرو سروسز کے درمیان دوروں کو کنٹرول کرنے کے لیے پالیسی کے اصولوں کو ترتیب دینا ممکن ہے۔ آخر میں، ہم پورے نیٹ ورک کے تعامل کا نقشہ حاصل کر سکتے ہیں اور میٹرکس کے متحد مجموعہ کو ایپلی کیشنز کے لیے مکمل طور پر شفاف بنا سکتے ہیں۔

آپ کام کے طریقہ کار کے بارے میں پڑھ سکتے ہیں۔ سرکاری دستاویزات. Istio واقعی ایک طاقتور ٹول ہے جو آپ کو بہت سے کاموں اور مسائل کو حل کرنے کی اجازت دیتا ہے۔ اس آرٹیکل میں، میں ان اہم سوالات کا جواب دینا چاہوں گا جو عام طور پر اسٹیو کے ساتھ شروع کرنے پر پیدا ہوتے ہیں۔ اس سے آپ کو اس سے تیزی سے نمٹنے میں مدد ملے گی۔

آپریشن کا اصول

Istio دو اہم علاقوں پر مشتمل ہے - کنٹرول ہوائی جہاز اور ڈیٹا ہوائی جہاز۔ کنٹرول ہوائی جہاز میں اہم اجزاء ہوتے ہیں جو باقی کے درست آپریشن کو یقینی بناتے ہیں۔ موجودہ ورژن (1.0) میں کنٹرول طیارے کے تین اہم اجزاء ہیں: پائلٹ، مکسر، سیٹاڈیل۔ ہم Citadel پر غور نہیں کریں گے، خدمات کے درمیان باہمی TLS کو یقینی بنانے کے لیے سرٹیفکیٹ تیار کرنے کی ضرورت ہے۔ آئیے پائلٹ اور مکسر کے ڈیوائس اور مقصد پر گہری نظر ڈالتے ہیں۔

پائلٹ مرکزی کنٹرول کا جزو ہے جو کلسٹر میں ہمارے پاس موجود تمام معلومات کو تقسیم کرتا ہے - خدمات، ان کے اختتامی مقامات اور روٹنگ کے اصول (مثال کے طور پر، کینری تعیناتی کے اصول یا سرکٹ بریکر کے اصول)۔

مکسر ایک اختیاری کنٹرول جہاز کا جزو ہے جو میٹرکس، لاگز، اور نیٹ ورک کے تعامل کے بارے میں کوئی بھی معلومات جمع کرنے کی صلاحیت فراہم کرتا ہے۔ وہ پالیسی کے قواعد کی تعمیل اور شرح کی حدود کی تعمیل پر بھی نظر رکھتا ہے۔

سائڈ کار پراکسی کنٹینرز کا استعمال کرتے ہوئے ڈیٹا پلین کو لاگو کیا جاتا ہے۔ طاقتور بطور ڈیفالٹ استعمال ہوتا ہے۔ ایلچی پراکسی. اسے کسی اور نفاذ سے تبدیل کیا جا سکتا ہے، جیسے nginx (nginmesh)۔

اسٹیو کے لیے ایپلی کیشنز کے لیے مکمل طور پر شفاف کام کرنے کے لیے، ایک خودکار انجیکشن سسٹم موجود ہے۔ تازہ ترین نفاذ Kubernetes 1.9+ ورژن (میوٹیشنل ایڈمشن ویب ہُک) کے لیے موزوں ہے۔ Kubernetes کے ورژن 1.7، 1.8 کے لیے Initializer کا استعمال ممکن ہے۔

سائڈ کار کنٹینرز GRPC پروٹوکول کا استعمال کرتے ہوئے پائلٹ سے منسلک ہوتے ہیں، جو آپ کو کلسٹر میں ہونے والی تبدیلیوں کے لیے پش ماڈل کو بہتر بنانے کی اجازت دیتا ہے۔ جی آر پی سی کو ایلچی میں ورژن 1.6 سے استعمال کیا جا رہا ہے، اسٹیو میں اسے ورژن 0.8 سے استعمال کیا جا رہا ہے اور یہ ایک پائلٹ ایجنٹ ہے - ایلچی پر ایک گولانگ ریپر جو لانچ کے اختیارات کو ترتیب دیتا ہے۔

پائلٹ اور مکسر مکمل طور پر سٹیٹ لیس اجزاء ہیں، تمام سٹیٹ کو میموری میں رکھا جاتا ہے۔ ان کے لیے کنفیگریشن Kubernetes Custom Resources کی شکل میں ترتیب دی گئی ہے، جو etcd میں محفوظ ہیں۔
Istio-agent کو پائلٹ کا پتہ ملتا ہے اور اس پر GRPC کا سلسلہ کھولتا ہے۔

جیسا کہ میں نے کہا، Istio ایپلی کیشنز کے لیے مکمل طور پر شفاف تمام فعالیت کو نافذ کرتا ہے۔ آئیے دیکھتے ہیں کہ کیسے۔ الگورتھم یہ ہے:

1. سروس کا نیا ورژن تعینات کرنا۔
2. سائڈکار کنٹینر انجیکشن کے نقطہ نظر پر منحصر ہے، کنفیگریشن کو لاگو کرنے کے مرحلے پر istio-init کنٹینر اور istio-agent کنٹینر (Envoy) کو شامل کیا جاتا ہے، یا انہیں پہلے سے ہی Kubernetes Pod entity کی تفصیل میں دستی طور پر داخل کیا جا سکتا ہے۔
3. istio-init کنٹینر ایک اسکرپٹ ہے جو پوڈ پر iptables کے قواعد کا اطلاق کرتا ہے۔ istio-agent کے کنٹینر میں لپیٹے جانے کے لیے ٹریفک کو ترتیب دینے کے لیے دو اختیارات ہیں: iptables ری ڈائریکٹ قوانین کا استعمال کریں، یا TPROXY. لکھنے کے وقت، پہلے سے طے شدہ نقطہ نظر ری ڈائریکٹ قواعد کے ساتھ ہے۔ istio-init میں، یہ ترتیب دینا ممکن ہے کہ کس ٹریفک کو روکا جائے اور istio-agent کو بھیجا جائے۔ مثال کے طور پر، تمام آنے والی اور جانے والی تمام ٹریفک کو روکنے کے لیے، آپ کو پیرامیٹرز سیٹ کرنے کی ضرورت ہے۔ -i и -b معنی میں *. آپ مداخلت کرنے کے لیے مخصوص بندرگاہوں کی وضاحت کر سکتے ہیں۔ کسی مخصوص ذیلی نیٹ کو روکنے کے لیے، آپ اسے جھنڈے کا استعمال کرتے ہوئے بتا سکتے ہیں۔ -x.
4. init کنٹینرز پر عمل درآمد کے بعد، اہم کو لانچ کیا جاتا ہے، بشمول پائلٹ-ایجنٹ (ایلچی)۔ یہ GRPC کے ذریعے پہلے سے تعینات پائلٹ سے جڑتا ہے اور کلسٹر میں موجود تمام خدمات اور روٹنگ پالیسیوں کے بارے میں معلومات حاصل کرتا ہے۔ موصول ہونے والے اعداد و شمار کے مطابق، وہ کلسٹرز کو کنفیگر کرتا ہے اور انہیں براہ راست ہماری ایپلی کیشنز کے اینڈ پوائنٹس کو کبرنیٹس کلسٹر میں تفویض کرتا ہے۔ ایک اہم نکتہ کو نوٹ کرنا بھی ضروری ہے: ایلچی متحرک طور پر سامعین (آئی پی، پورٹ پیئرز) کو ترتیب دیتا ہے جسے وہ سننا شروع کر دیتا ہے۔ اس لیے، جب درخواستیں پوڈ میں داخل ہوتی ہیں، سائڈ کار میں ری ڈائریکٹ iptables کے قواعد کا استعمال کرتے ہوئے ری ڈائریکٹ کی جاتی ہیں، ایلچی پہلے ہی ان کنکشنز کو کامیابی سے پروسیس کر سکتا ہے اور سمجھ سکتا ہے کہ ٹریفک کو مزید پراکسی کہاں سے لانا ہے۔ اس مرحلے پر بھی، معلومات مکسر کو بھیجی جاتی ہیں، جسے ہم بعد میں دیکھیں گے، اور ٹریسنگ اسپین بھیجے جاتے ہیں۔

نتیجے کے طور پر، ہمیں ایلچی پراکسی سرورز کا ایک پورا نیٹ ورک ملتا ہے جسے ہم ایک نقطہ (پائلٹ) سے ترتیب دے سکتے ہیں۔ تمام ان باؤنڈ اور آؤٹ باؤنڈ درخواستیں ایلچی کے ذریعے جاتی ہیں۔ مزید یہ کہ صرف TCP ٹریفک کو روکا جاتا ہے۔ اس کا مطلب ہے کہ Kubernetes سروس IP کو تبدیل کیے بغیر UDP پر kube-dns کا استعمال کرتے ہوئے حل کیا جاتا ہے۔ پھر، حل کے بعد، سبکدوش ہونے والی درخواست کو ایلچی کے ذریعے روکا جاتا ہے اور اس پر کارروائی کی جاتی ہے، جو پہلے ہی یہ فیصلہ کرتا ہے کہ درخواست کس اینڈ پوائنٹ کو بھیجی جائے (یا نہیں بھیجی جائے، رسائی کی پالیسیوں یا الگورتھم کے سرکٹ بریکر کی صورت میں)۔

ہم نے پائلٹ کا پتہ لگایا، اب ہمیں یہ سمجھنے کی ضرورت ہے کہ مکسر کیسے کام کرتا ہے اور اس کی ضرورت کیوں ہے۔ آپ اس کے لیے سرکاری دستاویزات پڑھ سکتے ہیں۔ یہاں.

اپنی موجودہ شکل میں مکسر دو اجزاء پر مشتمل ہے: istio-telemetry، istio-policy (ورژن 0.8 سے پہلے یہ ایک istio-mixer جزو تھا)۔ یہ دونوں مکسرز ہیں، جن میں سے ہر ایک اپنے اپنے کام کا ذمہ دار ہے۔ Istio ٹیلی میٹری GRPC کے ذریعے سائڈ کار رپورٹ کنٹینرز سے کون کہاں اور کن پیرامیٹرز کے ساتھ جاتا ہے اس بارے میں معلومات حاصل کرتا ہے۔ Istio-policy اس بات کی تصدیق کے لیے چیک کی درخواستوں کو قبول کرتی ہے کہ پالیسی کے قواعد مطمئن ہیں۔ پالیسی چیک، یقیناً، ہر درخواست کے لیے نہیں کیے جاتے، لیکن ایک خاص وقت کے لیے کلائنٹ (سائیڈ کار میں) پر کیش کیے جاتے ہیں۔ رپورٹ کے چیک بیچ کی درخواستوں کے طور پر بھیجے جاتے ہیں۔ آئیے دیکھتے ہیں کہ کنفیگر کرنے کا طریقہ اور کیا پیرامیٹرز تھوڑی دیر بعد بھیجے جائیں۔

مکسر کو ایک انتہائی دستیاب جزو سمجھا جاتا ہے جو ٹیلی میٹری ڈیٹا کی اسمبلی اور پروسیسنگ پر بلاتعطل کام کو یقینی بناتا ہے۔ نظام ملٹی لیول بفر کے نتیجے میں حاصل کیا جاتا ہے۔ ابتدائی طور پر، ڈیٹا کو کنٹینرز کے سائڈ کار سائیڈ پر بفر کیا جاتا ہے، پھر مکسر سائیڈ پر، اور پھر نام نہاد مکسر بیک اینڈز کو بھیجا جاتا ہے۔ نتیجے کے طور پر، اگر سسٹم کے اجزاء میں سے کوئی ناکام ہوجاتا ہے، تو بفر بڑھتا ہے اور سسٹم کو بحال کرنے کے بعد فلش ہوجاتا ہے۔ مکسر بیک اینڈز ٹیلی میٹری ڈیٹا بھیجنے کے لیے اختتامی نقطہ ہیں: statsd، newrelic، وغیرہ۔ آپ اپنا بیک اینڈ خود لکھ سکتے ہیں، یہ بہت آسان ہے، اور ہم دیکھیں گے کہ اسے کیسے کرنا ہے۔

خلاصہ کرنے کے لیے، istio-telemetry کے ساتھ کام کرنے کی اسکیم مندرجہ ذیل ہے۔

1. سروس 1 سروس 2 کو ایک درخواست بھیجتی ہے۔
2. سروس 1 سے نکلتے وقت، درخواست اس کی اپنی سائڈ کار میں لپیٹی جاتی ہے۔
3. سائڈ کار ایلچی نگرانی کرتا ہے کہ درخواست سروس 2 تک کیسے جاتی ہے اور ضروری معلومات تیار کرتا ہے۔
4. پھر رپورٹ کی درخواست کا استعمال کرتے ہوئے اسے istio-telemetry کو بھیجتا ہے۔
5. اسٹیو ٹیلی میٹری اس بات کا تعین کرتی ہے کہ آیا یہ رپورٹ بیک اینڈ کو بھیجی جانی چاہیے، کس کو اور کون سا ڈیٹا بھیجا جانا چاہیے۔
6. اگر ضرورت ہو تو Istio-telemetry رپورٹ کا ڈیٹا بیک اینڈ کو بھیجتی ہے۔

اب آئیے دیکھتے ہیں کہ سسٹم میں Istio کو کیسے تعینات کیا جائے، جس میں صرف اہم اجزاء (پائلٹ اور سائڈ کار ایلچی) شامل ہوں۔

سب سے پہلے، آئیے اس مین کنفیگریشن (میش) کو دیکھتے ہیں جسے پائلٹ پڑھتا ہے:

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-system میں واقع ہوں گے۔

کم از کم، ہمیں صرف پائلٹ تعینات کرنے کی ضرورت ہے۔ اس کے لیے ہم استعمال کرتے ہیں۔ اس طرح کی ترتیب.

اور ہم کنٹینر کے انجیکشن سائڈ کار کو دستی طور پر ترتیب دیں گے۔

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 بنانے کی ضرورت ہے، جس کی تفصیل مل سکتی ہے۔ یہاں.

نتیجے کے طور پر، جس سروس میں ہم ایلچی کے ساتھ سائڈ کار لگاتے ہیں وہ کامیابی کے ساتھ شروع ہونی چاہیے، پائلٹ سے تمام دریافتیں وصول کریں اور درخواستوں پر کارروائی کریں۔

یہ سمجھنا ضروری ہے کہ کنٹرول طیارے کے تمام اجزاء اسٹیٹ لیس ایپلی کیشنز ہیں اور بغیر کسی پریشانی کے افقی طور پر اسکیل کیے جا سکتے ہیں۔ تمام ڈیٹا کوبرنیٹس وسائل کی حسب ضرورت وضاحتوں کی شکل میں etcd میں محفوظ کیا جاتا ہے۔

اس کے علاوہ، Istio (اب بھی تجرباتی) کلسٹر سے باہر چلانے کی صلاحیت رکھتا ہے اور کئی Kubernetes کلسٹرز کے درمیان سروس کی دریافت کو دیکھنے اور اسے پھنسانے کی صلاحیت رکھتا ہے۔ آپ اس بارے میں مزید پڑھ سکتے ہیں۔ یہاں.

ملٹی کلسٹر کی تنصیب کے لیے، درج ذیل حدود سے آگاہ رہیں:

1. Pod CIDR اور Service CIDR تمام کلسٹرز میں منفرد ہونا چاہیے اور اوورلیپ نہیں ہونا چاہیے۔
2. تمام CIDR پوڈز کو کلسٹرز کے درمیان کسی بھی CIDR پوڈ سے قابل رسائی ہونا چاہیے۔
3. تمام Kubernetes API سرورز کو ایک دوسرے کے لیے قابل رسائی ہونا چاہیے۔

Istio کے ساتھ شروع کرنے میں آپ کی مدد کرنے کے لیے یہ ابتدائی معلومات ہے۔ تاہم، اب بھی بہت سے نقصانات ہیں. مثال کے طور پر، بیرونی ٹریفک کو روٹ کرنے کی خصوصیات (کلسٹر سے باہر)، سائیڈ کارز کو ڈیبگ کرنے تک رسائی، پروفائلنگ، مکسر ترتیب دینا اور کسٹم مکسر بیک اینڈ لکھنا، ٹریسنگ میکانزم ترتیب دینا اور ایلچی کا استعمال کرتے ہوئے اس کا آپریشن۔
یہ سب ہم مندرجہ ذیل اشاعتوں میں غور کریں گے۔ اپنے سوالات پوچھیں، میں ان کا احاطہ کرنے کی کوشش کروں گا۔

ماخذ: www.habr.com