كيفية تشغيل Istio باستخدام Kubernetes في الإنتاج. الجزء 1

ما هو Istio؟ هذا هو ما يسمى شبكة الخدمة ، وهي تقنية تضيف طبقة من التجريد عبر الشبكة. نعترض كل أو جزء من حركة المرور في الكتلة ونقوم بتنفيذ مجموعة معينة من العمليات معها. أيها؟ على سبيل المثال ، نقوم بالتوجيه الذكي ، أو ننفذ نهج قاطع الدائرة ، يمكننا تنظيم "النشر الكناري" ، أو تحويل حركة المرور جزئيًا إلى إصدار جديد من الخدمة ، أو يمكننا تقييد التفاعلات الخارجية والتحكم في جميع الرحلات من المجموعة إلى شبكة خارجية. من الممكن وضع قواعد السياسة للتحكم في الرحلات بين الخدمات المصغرة المختلفة. أخيرًا ، يمكننا الحصول على خريطة تفاعل الشبكة بالكامل وجعل المجموعة الموحدة من المقاييس شفافة تمامًا للتطبيقات.

يمكنك أن تقرأ عن آلية العمل في الوثائق الرسمية. Istio هي أداة قوية حقًا تتيح لك حل العديد من المهام والمشكلات. في هذه المقالة ، أود أن أجيب على الأسئلة الرئيسية التي تظهر عادة عند البدء في Istio. سيساعدك هذا على التعامل معها بشكل أسرع.

كيف يعمل

يتكون Istio من منطقتين رئيسيتين - مستوى التحكم ومستوى البيانات. يحتوي مستوى التحكم على المكونات الرئيسية التي تضمن التشغيل الصحيح للباقي. في الإصدار الحالي (1.0) ، يتكون مستوى التحكم من ثلاثة مكونات رئيسية: Pilot ، Mixer ، Citadel. لن نفكر في Citadel ، هناك حاجة لإنشاء شهادات لضمان TLS المتبادل بين الخدمات. دعونا نلقي نظرة فاحصة على الجهاز والغرض من Pilot and Mixer.

الطيار هو عنصر التحكم الرئيسي الذي يوزع جميع المعلومات حول ما لدينا في المجموعة - الخدمات ونقاط النهاية وقواعد التوجيه (على سبيل المثال ، قواعد نشر Canary أو قواعد قاطع الدائرة).

Mixer هو مكون مستوى تحكم اختياري يوفر القدرة على جمع المقاييس والسجلات وأي معلومات حول تفاعل الشبكة. كما أنه يراقب الامتثال لقواعد السياسة والامتثال لحدود الأسعار.

يتم تنفيذ مستوى البيانات باستخدام حاويات الوكيل الجانبي. يتم استخدام Powerful بشكل افتراضي. وكيل المبعوث. يمكن استبداله بتطبيق آخر ، مثل nginx (nginmesh).

لكي يعمل Istio بشكل شفاف تمامًا مع التطبيقات ، هناك نظام حقن تلقائي. أحدث تطبيق مناسب لإصدارات Kubernetes 1.9+ (خطاف ويب للقبول الطفري). بالنسبة للإصدارات 1.7 و 1.8 من Kubernetes ، من الممكن استخدام المُهيئ.

يتم توصيل حاويات Sidecar بـ Pilot باستخدام بروتوكول GRPC ، والذي يسمح لك بتحسين نموذج الدفع للتغييرات التي تحدث في المجموعة. تم استخدام GRPC في Envoy منذ الإصدار 1.6 ، في Istio تم استخدامه منذ الإصدار 0.8 وهو وكيل تجريبي - غلاف golang فوق المبعوث الذي يقوم بتكوين خيارات الإطلاق.

يعد Pilot و Mixer مكونين عديمي الحالة تمامًا ، ويتم الاحتفاظ بجميع الحالات في الذاكرة. يتم تعيين التكوين الخاص بهم في شكل Kubernetes Custom Resources ، والتي يتم تخزينها في etcd.
يحصل وكيل Istio على عنوان Pilot ويفتح تدفق GRPC إليه.

كما قلت ، يقوم Istio بتنفيذ جميع الوظائف بشكل شفاف تمامًا للتطبيقات. دعونا نرى كيف. الخوارزمية هي:

1. نشر نسخة جديدة من الخدمة.
2. اعتمادًا على نهج حقن الحاوية الجانبية ، تتم إضافة حاوية istio-init و حاوية عامل istio (المبعوث) في مرحلة تطبيق التكوين ، أو يمكن بالفعل إدراجها يدويًا في وصف كيان Kubernetes Pod.
3. الحاوية istio-init هي برنامج نصي يطبق قواعد iptables على الحاوية. يوجد خياران لتكوين حركة المرور ليتم تغليفها في حاوية عامل استثمار: استخدام قواعد إعادة توجيه iptables ، أو TPROXY. في وقت كتابة هذا التقرير ، كان الأسلوب الافتراضي هو قواعد إعادة التوجيه. في البداية ، من الممكن تكوين حركة المرور التي يجب اعتراضها وإرسالها إلى الوكيل. على سبيل المثال ، لاعتراض كل حركة المرور الواردة والصادرة ، تحتاج إلى ضبط المعلمات -i и -b في المعنى *. يمكنك تحديد منافذ معينة لاعتراضها. من أجل عدم اعتراض شبكة فرعية معينة ، يمكنك تحديدها باستخدام العلم -x.
4. بعد تنفيذ حاويات init ، يتم إطلاق الحاويات الرئيسية ، بما في ذلك الوكيل التجريبي (المبعوث). يتصل بالطيار المنشور بالفعل عبر GRPC ويتلقى معلومات حول جميع الخدمات الحالية وسياسات التوجيه في المجموعة. وفقًا للبيانات الواردة ، يقوم بتكوين المجموعات وتعيينها مباشرة إلى نقاط النهاية لتطبيقاتنا في مجموعة Kubernetes. من الضروري أيضًا ملاحظة نقطة مهمة: يقوم المبعوث بتكوين المستمعين ديناميكيًا (IP ، أزواج المنافذ) التي يبدأ الاستماع إليها. لذلك ، عند إدخال الطلبات إلى pod ، تتم إعادة توجيهها باستخدام قواعد iptables لإعادة التوجيه في sidecar ، يمكن للمبعوث بالفعل معالجة هذه الاتصالات بنجاح وفهم مكان وكيل إضافي لحركة المرور. في هذه المرحلة أيضًا ، يتم إرسال المعلومات إلى Mixer ، والتي سننظر فيها لاحقًا ، ويتم إرسال فترات التتبع.

نتيجة لذلك ، نحصل على شبكة كاملة من خوادم بروكسي المبعوث التي يمكننا تكوينها من نقطة واحدة (طيار). تمر جميع الطلبات الواردة والصادرة من خلال المبعوث. علاوة على ذلك ، يتم اعتراض حركة مرور TCP فقط. هذا يعني أن عنوان IP لخدمة Kubernetes يتم حله باستخدام kube-dns عبر UDP دون تغيير. بعد ذلك ، بعد الحل ، يتم اعتراض الطلب الصادر ومعالجته بواسطة المبعوث ، والذي يقرر بالفعل نقطة النهاية التي يجب إرسال الطلب إليها (أو عدم إرسالها ، في حالة سياسات الوصول أو قاطع الدائرة للخوارزمية).

اكتشفنا Pilot ، والآن نحتاج إلى فهم كيفية عمل Mixer وسبب الحاجة إليه. يمكنك قراءة الوثائق الرسمية لذلك هنا.

يتكون الخلاط في شكله الحالي من مكونين: القياس عن بعد ، سياسة istio (قبل الإصدار 0.8 كان مكونًا واحدًا للخلاط). كلاهما خلاطات ، كل منهما مسؤول عن مهمته الخاصة. يتلقى القياس عن بعد Istio معلومات حول من يذهب وأين ومع المعلمات من حاويات التقارير الجانبية عبر GRPC. يقبل Istio-policy طلبات التحقق للتحقق من استيفاء قواعد السياسة. وبطبيعة الحال ، لا يتم إجراء عمليات التحقق من Poilicy لكل طلب ، ولكن يتم تخزينها مؤقتًا على العميل (في السيارة الجانبية) لفترة معينة. يتم إرسال عمليات التحقق من التقارير كطلبات مجمعة. دعونا نرى كيفية التكوين وما هي المعلمات التي يجب إرسالها بعد ذلك بقليل.

من المفترض أن يكون Mixer مكونًا متوفرًا بدرجة عالية يضمن العمل دون انقطاع على تجميع بيانات القياس عن بُعد ومعالجتها. يتم الحصول على النظام كنتيجة كمخزن مؤقت متعدد المستويات. في البداية ، يتم تخزين البيانات مؤقتًا على الجانب الجانبي للحاويات ، ثم على جانب الخلاط ، ثم إرسالها إلى ما يسمى بالخلفيات الخلفية للخلاط. نتيجة لذلك ، في حالة فشل أي من مكونات النظام ، ينمو المخزن المؤقت ويتم مسحه بعد استعادة النظام. تعد خلفيات Mixer بمثابة نقاط نهاية لإرسال بيانات القياس عن بُعد: statsd و newrelic وما إلى ذلك. يمكنك كتابة الواجهة الخلفية الخاصة بك ، الأمر بسيط للغاية ، وسنرى كيفية القيام بذلك.

للتلخيص ، مخطط العمل مع القياس عن بعد هو كما يلي.

1. ترسل الخدمة 1 طلبًا إلى الخدمة 2.
2. عند مغادرة الخدمة 1 ، يتم تغليف الطلب في عربة جانبية خاصة به.
3. يراقب مبعوث Sidecar كيفية انتقال الطلب إلى الخدمة 2 وإعداد المعلومات اللازمة.
4. ثم يرسله إلى القياس عن بعد باستخدام طلب إبلاغ.
5. يحدد Istio-telemetry ما إذا كان يجب إرسال هذا التقرير إلى الخلفيات الخلفية وإلى أي بيانات يجب إرسالها.
6. Istio-telemetry يرسل بيانات التقرير إلى الخلفية إذا لزم الأمر.

الآن دعونا نرى كيفية نشر Istio في النظام ، الذي يتكون فقط من المكونات الرئيسية (المبعوث التجريبي والمبعوث الجانبي).

أولاً ، دعنا نلقي نظرة على التكوين الرئيسي (الشبكة) الذي يقرأه 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.

كحد أدنى ، نحتاج فقط إلى نشر 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 for Pilot ، يمكن العثور على أوصافه هنا.

نتيجة لذلك ، يجب أن تبدأ الخدمة التي نحقن فيها السيارة الجانبية مع المبعوث بنجاح ، وأن تتلقى كل الاكتشافات من الطلبات التجريبية والمعالجة.

من المهم أن نفهم أن جميع مكونات مستوى التحكم هي تطبيقات عديمة الحالة ويمكن تحجيمها أفقيًا دون مشاكل. يتم تخزين جميع البيانات في etcd في شكل أوصاف مخصصة لموارد Kubernetes.

أيضًا ، Istio (لا يزال تجريبيًا) لديه القدرة على الجري خارج المجموعة والقدرة على مشاهدة اكتشاف الخدمة والتحسس فيه بين عدة مجموعات Kubernetes. يمكنك قراءة المزيد عن هذا هنا.

للتثبيت متعدد المجموعات ، كن على دراية بالقيود التالية:

1. يجب أن يكون Pod CIDR و Service CIDR فريدًا عبر جميع المجموعات ويجب ألا يتداخل.
2. يجب أن يكون الوصول إلى جميع CIDR Pods من أي CIDR Pods بين المجموعات.
3. يجب أن تكون جميع خوادم Kubernetes API متاحة لبعضها البعض.

هذه هي المعلومات الأولية لمساعدتك على البدء في Istio. ومع ذلك ، لا يزال هناك الكثير من المزالق. على سبيل المثال ، ميزات توجيه حركة المرور الخارجية (خارج المجموعة) ، ومقاربات تصحيح أخطاء السيارات الجانبية ، والتنميط ، وإعداد الخلاط وكتابة خلفية خالط مخصصة ، وإعداد آلية تتبع وتشغيلها باستخدام المبعوث.
سنغطي كل هذا في المشاركات المستقبلية. اطرح أسئلتك ، سأحاول تغطيتها.

المصدر: www.habr.com