🥇نحوه اجرای Istio با استفاده از Kubernetes در تولید. قسمت 1

چه شده است ایستیو? این به اصطلاح مش سرویس است، فناوری که لایه ای از انتزاع را بر روی شبکه اضافه می کند. ما تمام یا بخشی از ترافیک در خوشه را رهگیری می کنیم و مجموعه خاصی از عملیات را با آن انجام می دهیم. کدام یک؟ به عنوان مثال، ما مسیریابی هوشمند انجام می دهیم، یا رویکرد قطع کننده مدار را اجرا می کنیم، می توانیم "استقرار قناری" را سازماندهی کنیم، تا حدی ترافیک را به نسخه جدیدی از سرویس تغییر دهیم، یا می توانیم تعاملات خارجی را محدود کنیم و همه سفرها را از خوشه به سمت کنترل کنیم. شبکه خارجی تنظیم قوانین سیاست برای کنترل سفرهای بین میکروسرویس های مختلف امکان پذیر است. در نهایت، می‌توانیم کل نقشه تعامل شبکه را دریافت کنیم و مجموعه یکپارچه معیارها را برای برنامه‌ها کاملاً شفاف کنیم.

در مورد مکانیسم کار می توانید مطالعه کنید اسناد رسمی. Istio یک ابزار واقعا قدرتمند است که به شما امکان می دهد بسیاری از کارها و مشکلات را حل کنید. در این مقاله می‌خواهم به سوالات اصلی که معمولاً هنگام شروع کار با ایستیو پیش می‌آیند پاسخ دهم. این به شما کمک می کند سریعتر با آن مقابله کنید.

اصل عمل

ایستیو از دو ناحیه اصلی تشکیل شده است - صفحه کنترل و صفحه داده. صفحه کنترل شامل اجزای اصلی است که عملکرد صحیح بقیه را تضمین می کند. در نسخه فعلی (1.0) هواپیمای کنترل دارای سه جزء اصلی است: خلبان، میکسر، سیتادل. ما Citadel را در نظر نخواهیم گرفت، برای اطمینان از TLS متقابل بین خدمات، به تولید گواهینامه نیاز است. بیایید نگاهی دقیق تر به دستگاه و هدف Pilot and Mixer بیندازیم.

Pilot جزء اصلی کنترلی است که تمام اطلاعات را در مورد آنچه ما در خوشه داریم - سرویس ها، نقاط پایانی آنها و قوانین مسیریابی (به عنوان مثال، قوانین برای استقرار Canary یا قوانین قطع کننده مدار) توزیع می کند.

Mixer یک جزء کنترل اختیاری است که توانایی جمع‌آوری معیارها، گزارش‌ها و هرگونه اطلاعات در مورد تعامل شبکه را فراهم می‌کند. او همچنین بر رعایت قوانین سیاست و رعایت محدودیت های نرخ نظارت می کند.

صفحه داده با استفاده از کانتینرهای پراکسی sidecar پیاده سازی می شود. قدرتمند به طور پیش فرض استفاده می شود. نماینده نماینده. می توان آن را با پیاده سازی دیگری مانند nginx (nginmesh) جایگزین کرد.

برای اینکه ایستیو کاملاً شفاف برای برنامه ها کار کند، یک سیستم تزریق خودکار وجود دارد. آخرین پیاده‌سازی برای نسخه‌های Kubernetes 1.9+ (وب هوک پذیرش جهش) مناسب است. برای Kubernetes نسخه 1.7، 1.8 امکان استفاده از Initializer وجود دارد.

ظروف جانبی با استفاده از پروتکل GRPC به Pilot متصل می شوند که به شما امکان می دهد مدل فشار را برای تغییرات رخ داده در خوشه بهینه کنید. GRPC از نسخه 1.6 در Envoy استفاده شده است، در Istio از نسخه 0.8 استفاده شده است و یک عامل خلبان است - یک پوشش گلانگ روی فرستاده که گزینه های راه اندازی را پیکربندی می کند.

Pilot و Mixer اجزای کاملاً بدون حالت هستند، همه حالت ها در حافظه نگهداری می شوند. پیکربندی برای آنها در قالب منابع سفارشی Kubernetes تنظیم شده است که در etcd ذخیره می شوند.
Istio-agent آدرس خلبان را دریافت می کند و یک جریان GRPC را برای آن باز می کند.

همانطور که گفتم، ایستیو تمام عملکردها را کاملاً شفاف برای برنامه ها پیاده سازی می کند. بیایید ببینیم چگونه. الگوریتم این است:

استقرار یک نسخه جدید از سرویس.
بسته به رویکرد تزریق کانتینر کناری، ظرف istio-init و ظرف istio-عامل (فرستاده) در مرحله اعمال پیکربندی اضافه می شوند، یا می توان آنها را قبلاً به صورت دستی در توضیحات موجودیت Kubernetes Pod درج کرد.
ظرف istio-init یک اسکریپت است که قوانین iptables را در پاد اعمال می کند. دو گزینه برای پیکربندی ترافیک در یک کانتینر istio-agent وجود دارد: استفاده از قوانین تغییر مسیر iptables، یا TPROXY. در زمان نگارش، رویکرد پیش فرض با قوانین تغییر مسیر است. در istio-init، می توان پیکربندی کرد که کدام ترافیک باید رهگیری شود و به istio-agent ارسال شود. به عنوان مثال، برای رهگیری تمام ترافیک ورودی و خروجی، باید پارامترها را تنظیم کنید -i и -b به معنا *. می توانید پورت های خاصی را برای رهگیری مشخص کنید. برای اینکه زیرشبکه خاصی را رهگیری نکنید، می توانید آن را با استفاده از پرچم مشخص کنید -x.
پس از اجرای کانتینرهای اولیه، کانتینرهای اصلی از جمله خلبان-عامل (فرستاده) راه اندازی می شوند. از طریق GRPC به Pilot از قبل مستقر شده متصل می شود و اطلاعاتی در مورد تمام خدمات موجود و سیاست های مسیریابی در خوشه دریافت می کند. با توجه به داده های دریافتی، او خوشه ها را پیکربندی می کند و آنها را مستقیماً به نقاط انتهایی برنامه های ما در خوشه Kubernetes اختصاص می دهد. همچنین لازم است به یک نکته مهم توجه کنید: envoy به صورت پویا شنوندگان (IP، جفت پورت) را که شروع به گوش دادن می کند پیکربندی می کند. بنابراین، هنگامی که درخواست‌ها وارد پاد می‌شوند و با استفاده از قوانین iptables تغییر مسیر در سایدکار هدایت می‌شوند، فرستاده می‌تواند قبلاً این اتصالات را با موفقیت پردازش کند و بفهمد که کجا باید ترافیک را بیشتر پراکسی کند. همچنین در این مرحله اطلاعاتی به Mixer ارسال می شود که در ادامه به بررسی آن خواهیم پرداخت و بازه های ردیابی ارسال می شود.

در نتیجه، ما یک شبکه کامل از سرورهای پروکسی فرستاده را دریافت می کنیم که می توانیم از یک نقطه پیکربندی کنیم (Pilot). تمام درخواست های ورودی و خروجی از طریق فرستاده انجام می شود. علاوه بر این، فقط ترافیک TCP رهگیری می شود. این بدان معنی است که IP سرویس Kubernetes با استفاده از kube-dns روی UDP بدون تغییر حل می شود. سپس، پس از حل و فصل، درخواست خروجی توسط فرستاده رهگیری و پردازش می‌شود، که از قبل تصمیم می‌گیرد درخواست به کدام نقطه پایانی ارسال شود (در مورد سیاست‌های دسترسی یا قطع کننده مدار الگوریتم).

ما Pilot را فهمیدیم، اکنون باید بفهمیم که Mixer چگونه کار می کند و چرا به آن نیاز است. می توانید اسناد رسمی آن را بخوانید اینجا.

میکسر در شکل فعلی خود از دو جزء تشکیل شده است: istio-telemetry، istio-policy (قبل از نسخه 0.8 یک جزء istio-mixer بود). هر دوی آنها میکسر هستند که هر کدام وظیفه خود را بر عهده دارند. تله متری Istio اطلاعاتی در مورد اینکه چه کسی کجا و با چه پارامترهایی از کانتینرهای گزارش سایدکار از طریق GRPC می‌رود، دریافت می‌کند. Istio-policy درخواست های چک را می پذیرد تا تأیید کند که قوانین خط مشی مطابقت دارد. بررسی های سیاست البته برای هر درخواستی انجام نمی شود، بلکه برای مدت معینی روی مشتری (در سایدکار) ذخیره می شود. چک های گزارش به عنوان درخواست دسته ای ارسال می شوند. بیایید ببینیم که چگونه پیکربندی کنیم و چه پارامترهایی باید کمی بعد ارسال شوند.

Mixer قرار است یک جزء بسیار در دسترس باشد که کار بدون وقفه را در مونتاژ و پردازش داده های تله متری تضمین می کند. سیستم به عنوان یک بافر چند سطحی به دست می آید. در ابتدا، داده ها در سمت کناری کانتینرها، سپس در سمت میکسر بافر می شوند و سپس به اصطلاحاً پشتیبان میکسر ارسال می شوند. در نتیجه، اگر هر یک از اجزای سیستم از کار بیفتد، بافر رشد می کند و پس از بازیابی سیستم، پاک می شود. باطن های میکسر نقاط پایانی برای ارسال داده های تله متری هستند: statsd، newrelic و غیره. شما می توانید باطن خود را بنویسید، بسیار ساده است، و ما خواهیم دید که چگونه آن را انجام دهیم.

به طور خلاصه، طرح کار با istio-telemetry به شرح زیر است.

سرویس 1 درخواستی را به سرویس 2 ارسال می کند.
هنگام خروج از سرویس 1، درخواست در کناری خودش پیچیده می شود.
فرستاده سایدکار نحوه رفتن درخواست به سرویس 2 را نظارت می کند و اطلاعات لازم را آماده می کند.
سپس با استفاده از یک درخواست گزارش، آن را به istio-telemetry ارسال می کند.
Istio-telemetry تعیین می کند که آیا این گزارش باید به پشتیبان ها ارسال شود، به کدام و چه داده هایی باید ارسال شود.
Istio-telemetry داده های گزارش را در صورت نیاز به باطن ارسال می کند.

حال بیایید ببینیم که چگونه می توان ایستیو را در سیستم مستقر کرد که فقط از اجزای اصلی (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

تمام اجزای اصلی کنترل (صفحه کنترل) در فضای نام istio-system در Kubernetes قرار خواهند گرفت.

حداقل ما فقط باید Pilot را مستقر کنیم. برای این ما استفاده خواهیم کرد چنین پیکربندی

و ما به صورت دستی سایدکار تزریقی ظرف را پیکربندی می کنیم.

ظرف اولیه:

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 ذخیره می شوند.

همچنین، ایستیو (هنوز آزمایشی) توانایی اجرای خارج از خوشه و توانایی تماشا و کشف سرویس بین چندین خوشه Kubernetes را دارد. می توانید در این مورد بیشتر بخوانید اینجا.

برای نصب چند کلاستر، از محدودیت های زیر آگاه باشید:

Pod CIDR و Service CIDR باید در همه خوشه‌ها منحصربه‌فرد باشند و نباید همپوشانی داشته باشند.
همه CIDR Pods باید از هر CIDR Pods بین خوشه‌ها قابل دسترسی باشند.
همه سرورهای Kubernetes API باید برای یکدیگر قابل دسترسی باشند.

این اطلاعات اولیه برای کمک به شما در شروع کار با Istio است. با این حال، هنوز هم دام های زیادی وجود دارد. به عنوان مثال، ویژگی‌های مسیریابی ترافیک خارجی (خارج از خوشه)، رویکردهایی برای اشکال‌زدایی کارگاه‌های جانبی، پروفایل‌سازی، راه‌اندازی یک میکسر و نوشتن یک پایانه میکسر سفارشی، راه‌اندازی مکانیزم ردیابی و عملکرد آن با استفاده از envoy.
در پست های بعدی به همه این موارد خواهیم پرداخت. سوالات خود را بپرسید، سعی می کنم آنها را پوشش دهم.

منبع: www.habr.com

نحوه اجرای ایستیو با استفاده از Kubernetes در تولید. قسمت 1

اصل عمل

اضافه کردن نظر انصراف از پاسخ