پيداوار ۾ ڪبرنيٽس استعمال ڪندي Istio کي ڪيئن هلائڻ. حصو 1

ڇا استيو؟ هي نام نهاد سروس ميش آهي، هڪ ٽيڪنالاجي جيڪا نيٽ ورڪ تي تجريد جي هڪ پرت شامل ڪري ٿي. اسان ڪلستر ۾ ٽريفڪ جو سڄو يا حصو روڪيون ٿا ۽ ان سان آپريشن جو هڪ خاص سيٽ انجام ڏيون ٿا. ڪهڙو؟ مثال طور، اسان سمارٽ روٽنگ ڪندا آهيون، يا اسان سرڪٽ بريڪر اپروچ تي عمل ڪندا آهيون، اسان ”ڪينري ڊيپلائيمينٽ“ کي منظم ڪري سگهون ٿا، جزوي طور تي ٽريفڪ کي سروس جي نئين ورزن ڏانهن تبديل ڪري سگهون ٿا، يا اسان ٻاهرين ڳالهين کي محدود ڪري سگھون ٿا ۽ ڪلسٽر کان ڪلستر تائين سڀني سفرن کي ڪنٽرول ڪري سگهون ٿا. خارجي نيٽ ورڪ. اهو ممڪن آهي ته مختلف microservices جي وچ ۾ دورن کي ڪنٽرول ڪرڻ لاءِ پاليسي قاعدا مقرر ڪرڻ. آخرڪار، اسان حاصل ڪري سگھون ٿا پوري نيٽ ورڪ رابطي جو نقشو ۽ ميٽرڪس جي گڏيل مجموعي کي مڪمل طور تي ايپليڪيشنن لاءِ شفاف بڻائي سگھون ٿا.

توهان ڪم جي ميکانيزم جي باري ۾ پڙهي سگهو ٿا سرڪاري دستاويز. Istio هڪ واقعي طاقتور اوزار آهي جيڪو توهان کي ڪيترن ئي ڪمن ۽ مسئلن کي حل ڪرڻ جي اجازت ڏئي ٿو. هن آرٽيڪل ۾، آئون انهن بنيادي سوالن جو جواب ڏيڻ چاهيان ٿو جيڪي عام طور تي پيدا ٿين ٿا جڏهن Istio سان شروع ٿئي ٿي. اهو توهان کي تيزيء سان معاملو ڪرڻ ۾ مدد ڏيندو.

ڪيئن اهو ڪم

Istio ٻن مکيه علائقن تي مشتمل آهي - ڪنٽرول جهاز ۽ ڊيٽا جهاز. ڪنٽرول جهاز ۾ مکيه اجزاء شامل آهن جيڪي باقي جي صحيح آپريشن کي يقيني بڻائين. موجوده ورزن ۾ (1.0) ڪنٽرول جهاز جا ٽي مکيه حصا آهن: پائلٽ، ميڪر، قلعو. اسان Citadel تي غور نه ڪنداسين، خدمتن جي وچ ۾ باہمي TLS کي يقيني بڻائڻ لاء سرٽيفڪيٽ پيدا ڪرڻ جي ضرورت آهي. اچو ته ڊوائيس ۽ پائلٽ ۽ ميڪر جي مقصد تي وڌيڪ نظر رکون.

پائلٽ مکيه ڪنٽرول جزو آهي جيڪو ورهائي ٿو سڀني معلومات جي باري ۾ جيڪو اسان وٽ ڪلستر ۾ آهي - خدمتون، انهن جي آخري پوائنٽن ۽ رستي جي ضابطن (مثال طور، ڪينري جي مقرري يا سرڪٽ برڪر جي ضابطن لاء ضابطا).

مکسر هڪ اختياري ڪنٽرول جهاز جو حصو آهي جيڪو ميٽرڪس، لاگز، ۽ نيٽ ورڪ رابطي جي باري ۾ ڪا به معلومات گڏ ڪرڻ جي صلاحيت فراهم ڪري ٿو. هو پاليسي قاعدن جي تعميل ۽ شرح جي حدن جي تعميل جي نگراني پڻ ڪندو آهي.

ڊيٽا جهاز کي لاڳو ڪيو ويو آهي سائڊ ڪار پراکسي ڪنٽينرز استعمال ڪندي. ڊفالٽ طور طاقتور استعمال ڪيو ويندو آهي. سفير پراکسي. ان کي تبديل ڪري سگھجي ٿو ٻئي عمل سان، جهڙوڪ nginx (nginmesh).

Istio لاء ايپليڪيشنن کي مڪمل طور تي شفاف ڪم ڪرڻ لاء، اتي هڪ خودڪار انجڻ سسٽم آهي. جديد نفاذ ڪبرنيٽس 1.9+ ورزن لاءِ موزون آهي (ميوٽيشنل ايڊميشن ويب هِڪ). ڪبرنيٽس ورزن 1.7، 1.8 لاءِ اهو ممڪن آهي استعمال ڪرڻ شروع ڪندڙ.

سائڊ ڪار ڪنٽينر GRPC پروٽوڪول استعمال ڪندي پائلٽ سان ڳنڍيل آهن، جيڪو توهان کي ڪلستر ۾ ٿيندڙ تبديلين لاءِ پش ماڊل کي بهتر ڪرڻ جي اجازت ڏئي ٿو. GRPC نسخو 1.6 کان وٺي اينوائي ۾ استعمال ڪيو ويو آهي، Istio ۾ اهو نسخو 0.8 کان استعمال ڪيو ويو آهي ۽ هڪ پائلٽ-ايجنٽ آهي - هڪ گولنگ ريپر اوور ايلچي جيڪو لانچ جي اختيارن کي ترتيب ڏئي ٿو.

پائلٽ ۽ ميڪر مڪمل طور تي رياستي اجزاء آهن، سڀني رياستن کي ياداشت ۾ رکيو ويندو آهي. انھن لاءِ ترتيب ڏنل آھي Kubernetes Custom Resources جي صورت ۾، جيڪي وغيره ۾ محفوظ ٿيل آھن.
Istio-agent پائلٽ جو پتو حاصل ڪري ٿو ۽ ان ڏانهن GRPC وهڪرو کولي ٿو.

جيئن مون چيو، Istio سڀني ڪارڪردگي کي لاڳو ڪري ٿو مڪمل طور تي ايپليڪيشنن کي شفاف. اچو ته ڏسو ڪيئن. الگورتھم ھي آھي:

1. خدمت جي نئين ورزن کي ترتيب ڏيڻ.
2. سائڊ ڪار ڪنٽينر جي انجڻ جي طريقي تي منحصر ڪري ٿو، istio-init ڪنٽينر ۽ istio-agent ڪنٽينر (Envoy) ترتيب ڏيڻ جي اسٽيج تي شامل ڪيا ويا آهن، يا اهي اڳ ۾ ئي دستي طور تي Kubernetes Pod اداري جي وضاحت ۾ داخل ڪري سگھجن ٿيون.
3. istio-init ڪنٽينر هڪ اسڪرپٽ آهي جيڪو پوڊ تي iptables ضابطن کي لاڳو ڪري ٿو. ٽريفڪ کي ترتيب ڏيڻ لاءِ ٻه آپشن آھن ھڪڙي istio-agent ڪنٽينر ۾ لپيٽڻ لاءِ: استعمال ڪريو iptables redirect قاعدا، يا TPROXY. لکڻ جي وقت تي، ڊفالٽ طريقو آهي ريڊائريڪٽ قاعدن سان. istio-init ۾، اهو ترتيب ڏيڻ ممڪن آهي ته ڪهڙي ٽرئفڪ کي روڪيو وڃي ۽ istio-agent ڏانهن موڪليو وڃي. مثال طور، سڀني ايندڙ ۽ سڀ نڪرڻ واري ٽرئفڪ کي روڪڻ لاء، توهان کي پيٽرولر مقرر ڪرڻ جي ضرورت آهي -i и -b معنيٰ ۾ *. توهان مداخلت ڪرڻ لاء مخصوص بندرگاهن جي وضاحت ڪري سگهو ٿا. ڪنهن مخصوص سبٽ کي مداخلت نه ڪرڻ لاء، توهان پرچم استعمال ڪندي وضاحت ڪري سگهو ٿا -x.
4. انٽ ڪنٽينرز تي عمل ٿيڻ کان پوءِ، مکيه شروع ڪيا ويندا آهن، جن ۾ پائلٽ-ايجنٽ (ايمانداري) شامل آهن. اهو GRPC ذريعي اڳ ۾ ئي مقرر ٿيل پائلٽ سان ڳنڍيندو آهي ۽ ڪلستر ۾ موجود سڀني خدمتن ۽ روٽنگ پاليسين بابت معلومات حاصل ڪري ٿو. حاصل ڪيل انگن اکرن موجب، هو ڪلستر کي ترتيب ڏئي ٿو ۽ انهن کي سڌو سنئون اسان جي ايپليڪيشنن جي آخري پوائنٽن کي Kubernetes ڪلستر ۾ تفويض ڪري ٿو. اهو پڻ ضروري آهي ته هڪ اهم نقطو نوٽ ڪيو وڃي: ايلچي متحرڪ طور تي ٻڌندڙن کي ترتيب ڏئي ٿو (IP، پورٽ جوڙو) جيڪو اهو ٻڌڻ شروع ڪري ٿو. تنهن ڪري، جڏهن درخواستون پوڊ ۾ داخل ٿين ٿيون، سائڊ ڪار ۾ ريڊريٽ iptables ضابطن کي استعمال ڪندي ريڊائريٽ ڪيون وينديون آهن، سفير اڳ ۾ ئي انهن ڪنيڪشن کي ڪاميابيءَ سان پروسيس ڪري سگهي ٿو ۽ سمجهي سگهي ٿو ته ڪٿي ٽريفڪ کي اڳتي وڌائڻ لاءِ. انهي اسٽيج تي پڻ، معلومات موڪلي وئي آهي ميڪر ڏانهن، جنهن کي اسين بعد ۾ ڏسنداسين، ۽ ٽريڪنگ اسپن موڪليا ويندا آهن.

نتيجي طور، اسان کي اينووي پراکسي سرورز جو هڪ سڄو نيٽ ورڪ ملي ٿو جيڪو اسان هڪ نقطي (پائلٽ) کان ترتيب ڏئي سگهون ٿا. سڀئي اندرون ۽ ٻاهر نڪرڻ واريون درخواستون ايلچي ذريعي وڃن ٿيون. ان کان علاوه، صرف TCP ٽرئفڪ کي روڪيو ويو آهي. هن جو مطلب آهي ته Kubernetes سروس IP حل ڪيو ويو آهي kube-dns استعمال ڪندي UDP تي بغير تبديل ڪرڻ جي. ان کان پوء، حل ٿيڻ کان پوء، ٻاهر نڪرندڙ درخواست کي مداخلت ڪئي وئي آهي ۽ عملدار طرفان عمل ڪيو ويندو آهي، جيڪو اڳ ۾ ئي فيصلو ڪري ٿو ته درخواست ڪهڙي آخري نقطي ڏانهن موڪليو وڃي (يا نه موڪليو ويو، رسائي جي پاليسين جي صورت ۾ يا الگورتھم جي سرڪٽ برڪر).

اسان پائلٽ جو اندازو لڳايو، هاڻي اسان کي سمجهڻ جي ضرورت آهي ته ميڪر ڪيئن ڪم ڪري ٿو ۽ اهو ڇو ضروري آهي. توهان ان لاء سرڪاري دستاويز پڙهي سگهو ٿا هتي.

هن جي موجوده شڪل ۾ ميڪر ٻن حصن تي مشتمل آهي: istio-telemetry، istio-policy (ورجن 0.8 کان اڳ اهو هڪ istio-mixer جزو هو). انهن ٻنهي کي ملائيندڙ آهن، جن مان هر هڪ پنهنجي ڪم لاء ذميوار آهي. Istio ٽيليميٽري معلومات حاصل ڪري ٿي ته ڪير ڪٿي وڃي ٿو ۽ ڪهڙي پيرا ميٽرز سان سائڊ ڪار رپورٽ ڪنٽينرز کان GRPC ذريعي. Istio-policy قبول ڪري ٿي چيڪ درخواستن جي تصديق ڪرڻ لاءِ ته پاليسي قاعدا مطمئن آهن. پاليسي چيڪ، يقينا، هر درخواست لاء نه ڪيا ويا آهن، پر ڪلائنٽ تي ڪيش ٿيل آهن (سائيڊ ڪار ۾) هڪ خاص وقت لاءِ. رپورٽ چيڪ موڪليا ويا آهن بيچ درخواستن جي طور تي. اچو ته ڏسو ته ڪيئن ترتيب ڏيڻ ۽ ڪهڙي پيٽرولن کي ٿوري دير کان پوء موڪليو وڃي.

مکسر هڪ انتهائي دستياب جزو هجڻ گهرجي، جيڪو ٽيليميٽري ڊيٽا جي اسيمبلي ۽ پروسيسنگ تي اڻ رڪاوٽ ڪم کي يقيني بڻائي ٿو. سسٽم حاصل ڪئي وئي آهي نتيجي ۾ هڪ گھڻ-سطح بفر جي طور تي. شروعات ۾، ڊيٽا ڪنٽينرز جي سائڊ ڪار واري پاسي تي بفر ڪئي وئي آهي، پوء ميڪر پاسي تي، ۽ پوء نام نهاد ميڪر جي پس منظر ڏانهن موڪليو ويو. نتيجي طور، جيڪڏهن سسٽم جو ڪو به حصو ناڪام ٿئي ٿو، بفر وڌندو آهي ۽ سسٽم بحال ٿيڻ کان پوء ڦهليل آهي. Mixer backends ٽيليميٽري ڊيٽا موڪلڻ لاء آخري پوائنٽون آهن: statsd، newrelic، وغيره. توھان پنھنجو پس منظر لکي سگھو ٿا، اھو بلڪل سادو آھي، ۽ اسين ڏسنداسين ته اھو ڪيئن ڪجي.

اختصار ڪرڻ لاء، istio-telemetry سان ڪم ڪرڻ لاء اسڪيم هيٺ ڏنل آهي.

1. خدمت 1 خدمت 2 ڏانهن درخواست موڪلي ٿو.
2. جڏهن خدمت 1 ڇڏيندي، درخواست پنهنجي سائڊ ڪار ۾ لپي وئي آهي.
3. سائڊڪر سفير مانيٽر ڪري ٿو ته ڪيئن درخواست سروس 2 ڏانهن وڃي ٿي ۽ ضروري معلومات تيار ڪري ٿي.
4. پوء ان کي موڪلي ٿو istio-telemetry استعمال ڪندي رپورٽ جي درخواست.
5. Istio-telemetry اهو طئي ڪري ٿو ته ڇا هن رپورٽ کي واپس موڪليو وڃي، جنهن ڏانهن ۽ ڪهڙي ڊيٽا کي موڪليو وڃي.
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 for Pilot، جنهن جا تفصيل ڳولي سگهجن ٿا. هتي.

نتيجي طور، خدمت جنهن ۾ اسان سفير سان سائڊ ڪار داخل ڪريون ٿا، ڪاميابيءَ سان شروع ٿيڻ گهرجي، پائلٽ کان سڀ دريافتون حاصل ڪرڻ ۽ درخواستن تي عمل ڪرڻ گهرجي.

اهو سمجهڻ ضروري آهي ته ڪنٽرول جهاز جا سڀئي حصا بي رياست ايپليڪيشنون آهن ۽ افقي طور تي بغير ڪنهن مسئلن جي ماپ ڪري سگهجن ٿيون. سڀ ڊيٽا وغيره ۾ ذخيرو ٿيل آهي ڪبرنيٽس وسيلن جي ڪسٽم وضاحتن جي صورت ۾.

پڻ، Istio (اڃا تائين تجرباتي) ڪلستر کان ٻاهر هلڻ جي صلاحيت آهي ۽ ڪيترن ئي ڪبرنيٽس ڪلستر جي وچ ۾ سروس دريافت کي ڏسڻ ۽ ڦهلائڻ جي صلاحيت آهي. توھان ھن بابت وڌيڪ پڙھي سگھو ٿا هتي.

گھڻن ڪلستر جي تنصيب لاءِ، ھيٺين حدن کان آگاهه رھو:

1. پوڊ CIDR ۽ سروس CIDR سڀني ڪلسٽرن ۾ منفرد هجڻ گهرجي ۽ اوورليپ نه ٿيڻ گهرجي.
2. سڀئي CIDR پوڊز کي ڪلستر جي وچ ۾ ڪنهن به CIDR پوڊس کان رسائي هجڻ گهرجي.
3. سڀ Kubernetes API سرورز هڪ ٻئي تائين پهچ هجڻ گهرجن.

ھيءَ ابتدائي معلومات آھي توھان جي مدد ڪرڻ لاءِ Istio سان شروع ڪرڻ ۾. تنهن هوندي به، اتي اڃا به ڪيترائي pitfalls آهن. مثال طور، خارجي ٽريفڪ کي روٽ ڪرڻ جون خاصيتون (ڪلسٽر کان ٻاهر)، سائڊ ڪارز کي ڊيبگ ڪرڻ لاءِ طريقا، پروفائلنگ، هڪ ميڪر کي ترتيب ڏيڻ ۽ ڪسٽم ميڪر پس منظر لکڻ، ٽريسنگ ميڪانيزم قائم ڪرڻ ۽ ان جي آپريشن کي ايلچي استعمال ڪندي.
هي سڀ اسان هيٺ ڏنل اشاعتن ۾ غور ڪنداسين. پنھنجا سوال پڇو، مان انھن کي ڍڪڻ جي ڪوشش ڪندس.

جو ذريعو: www.habr.com